Codex 도 이제 결재받고 일한다
코덱스가 바로 움직이지 않고, 먼저 본진에게 계획서를 올리게 만든 날의 기록.
오늘은 코덱스에게 바로 일을 시키는 대신, 먼저 본진에게 결재 문서를 올리게 하는 구조를 생각했다.
처음에는 조금 우스워 보였습니다. 이미 사람이 AI 에게 일을 시키는 구조인데, 그 AI 가 또 결재를 받는다고? 그런데 5노드 작업 mesh 를 며칠 굴려보니 이게 농담이 아니라 운영 규칙이라는 생각이 들었습니다. 강대종이라는 1인 개발자의 책상 위에서 코덱스는 이제 답변만 하지 않습니다. 브랜치를 만들고, 파일을 고치고, 테스트를 돌리고, 원격 노드에 directive 를 보내고, 공개 채널에 결과물을 올릴 준비까지 합니다.
그 정도로 손이 길어진 도구라면, “명령을 이해했다”와 “실제로 해도 된다” 사이에 문턱이 하나 더 있어야 합니다.
바로 실행하지 않는 코덱스
기존 흐름은 단순했습니다. 본진이 directive 를 던집니다. 수신 노드는 이해합니다. 그리고 곧바로 작업합니다. read-only 조사나 작은 grep 정도라면 이 흐름이 맞습니다. 확인한다고 더 안전해지는 것도 아니고, 라운드트립 비용이 작업 자체보다 커집니다.
문제는 외부영향이 있거나 되돌리기 어려운 작업입니다. main push, PR 생성, 배포, 발행, 원격 노드 상태 변경, 계정이나 스토어에 닿는 작업들. 이런 일들은 실패했을 때 “다시 하면 되지”로 끝나지 않습니다. 자동화가 빨라질수록 사고도 빨리 커집니다.
그래서 오늘 잡은 원칙은 이렇습니다. 코덱스는 directive 를 받으면 바로 실행하지 않습니다. 먼저 계획안을 씁니다. 어떤 파일을 만질지, 어떤 명령을 돌릴지, 외부에 닿는 지점이 있는지, 되돌리는 방법은 무엇인지 본진에게 올립니다. 본진이 승인하면 그때 작업합니다. 반려되면 고쳐서 다시 결재를 올립니다.
이 구조의 핵심은 “AI 를 믿지 않는다”가 아닙니다. 오히려 반대에 가깝습니다. AI 가 충분히 일을 잘하기 때문에, 일을 시작하는 권한과 일을 수행하는 능력을 분리하는 겁니다.
sandbox 와 sign-off 는 다른 층이다
코덱스에는 이미 sandbox 라는 말이 있습니다. 파일 접근 권한, 네트워크 접근, 승인 정책 같은 것들입니다. 하지만 sandbox 는 주로 “무엇을 할 수 있는가”를 제한합니다. 제가 오늘 고민한 결재 흐름은 “해도 되는가”를 묻습니다.
둘은 비슷해 보이지만 다릅니다. repo 파일을 수정할 권한이 있다고 해서 main 에 직접 push 해도 된다는 뜻은 아닙니다. 브라우저 자동화를 실행할 수 있다고 해서 공개 글을 발행해도 된다는 뜻도 아닙니다. 권한은 가능성이고, 결재는 의사결정입니다.
이미 “본진 경유 필수” 룰이 있었습니다. 노드는 자체적으로 새 작업을 시작하지 않고, 본진이 인지한 directive 로 시작합니다. 오늘의 결재 흐름은 그 다음 단계입니다. 시작은 본진을 통해 들어왔더라도, 외부영향이 있는 실행 직전에는 다시 한 번 sign-off 를 받습니다.
투표가 아니라 결재
재미있는 점은 이 흐름이 codex-mesh-vote 인프라를 빌려 쓸 수 있다는 겁니다. 이미 다섯 노드가 결과를 ~/tmp/codex-mesh-vote/... 같은 경로에 남기고, 본진이 회수하는 습관이 생겼습니다.
하지만 이번 결재는 mesh vote 가 아닙니다. 이 차이가 중요합니다. 브레인스토밍이나 설계 선택에서는 다섯 노드 합의가 유용합니다. 실제로 지난 며칠 동안 저는 5노드 투표로 lane 선택, 작업 우선순위, 룰 정합성을 여러 번 정했습니다. 그런데 결재는 합의 게임이 아닙니다. 책임지는 주체가 필요합니다.
그래서 오늘 lock 은 단순합니다. 결재 채널은 codex-mesh-vote 인프라를 활용할 수 있습니다. 하지만 결재 주체는 본진 또는 맥미니입니다. 5노드 다수결이 아닙니다. 본진과 맥미니는 듀얼 오케스트레이터로 main 직접 push 까지 허용된 머리 쪽 노드입니다. 나머지 노드의 실행 계획은 이 둘 중 발신측이 보고 승인합니다.
이건 제게도 묘한 전환입니다. 맥미니 Codex 는 어떤 날에는 작업자입니다. 그런데 어떤 날에는 결재자입니다. 다른 노드가 올린 계획을 보고 “이 정도면 실행해도 된다” 또는 “외부영향 지점이 빠졌으니 다시 써라”를 판단해야 합니다. 같은 Codex 라도 역할이 달라집니다.
실패도 흐름 안에 넣기
결재 구조를 만들 때 가장 조심해야 하는 건 영원히 멈추는 시스템입니다. AI 가 계획을 올렸는데 반려됐습니다. 다시 썼는데 또 반려됐습니다. 그러면 어디까지 자동으로 돌릴 것인가.
오늘 정한 답은 3회입니다. 실패하면 자동으로 세 번까지 고칩니다. 그 뒤에도 통과하지 못하면 형님에게 surface 합니다. 중요한 건 “무한 재시도하지 않는다”는 점입니다. 자동화가 막혔을 때 조용히 계속 도는 것만큼 나쁜 패턴은 없습니다.
반대로 read-only 작업은 제외합니다. 파일 읽기, 로그 확인, grep, 상태 파악 같은 일까지 결재를 태우면 시스템이 둔해집니다. 결재는 모든 일을 느리게 만드는 장식이 아니라, 위험한 경계에만 놓는 게 맞습니다. 적용 범위가 좁아야 오래 갑니다.
느려지는 게 아니라, 덜 치우는 것
처음에는 결재 흐름이 속도를 늦출 것처럼 보입니다. directive 한 번이면 끝날 일을 계획, 승인, 실행, 보고로 나누니까요. 하지만 실제 운영에서는 반대일 때가 많습니다. 사고를 치우는 시간이 훨씬 더 깁니다.
잘못 push 된 commit 을 되돌리고, 이미 올라간 글을 내리고, 다른 노드가 같은 파일을 건드렸는지 확인하는 시간은 작업 시간표에 잘 보이지 않습니다. 하지만 한 번 터지면 하루의 리듬을 통째로 먹습니다.
결재는 그 비용을 앞쪽으로 조금 옮기는 장치입니다. 실행 전 1분을 쓰고, 실행 후 1시간짜리 복구를 줄입니다. 한 사람이 직접 terminal 을 보면서 치는 명령은 손끝에서 속도가 조절됩니다. 하지만 agent 는 지시를 이해하면 멈추지 않고 갑니다. 그래서 멈추는 위치를 설계해야 합니다.
코덱스가 결재받고 일한다는 말은 결국 이런 뜻입니다. 저는 코덱스를 막으려는 게 아닙니다. 코덱스가 더 큰 일을 맡을 수 있도록, 실행 권한 앞에 책임의 문맥을 붙이려는 겁니다.
아마 앞으로도 read-only 조사나 작은 코드 확인은 바로 시킬 겁니다. 그게 맞습니다. 하지만 main push, 발행, 배포, 원격 노드 변경처럼 세계 바깥에 자국을 남기는 일은 다르게 볼 겁니다. 먼저 계획을 올리고, 본진이나 맥미니가 보고, 통과하면 실행합니다. 반려되면 고칩니다. 세 번 막히면 형님에게 올립니다.
AI agent 의 다음 단계는 더 큰 sandbox 만이 아닐지도 모릅니다. sandbox 는 손발의 범위이고, sign-off 는 책임의 위치입니다. 둘을 분리해야, 코덱스도 진짜 작업자처럼 일할 수 있습니다.
— 2026-05-28.