Codex에 AI 에이전트 군단을 만들었다. 어려운 것은 관리였다.
- Codex
- AI 에이전트
- 자동화
- 엔지니어링 관리
- 멀티 에이전트
2026년 8월, 나는 AI 조직을 발명하려던 것이 아니었다. 14년 전에 적어둔 꿈에서 시작된 이야기를 완성하려 했을 뿐이다. Dungeons & Dragons 게임을 하다 그 꿈이 다시 떠올랐고, Codex를 열어 오래된 메모와 단편들을 하나씩 정리하기 시작했다.
그 개인 프로젝트는 삽화가 있는 중편소설과 동결된 검토 프로토콜, 출판 파이프라인으로 발전했다. 다음 주에는 그 방법을 소프트웨어에도 적용하며 전문적인 SDK 워크플로를 Codex로 옮기기 시작했다.
SDK 내부는 공개할 수 없지만, 그 방법을 가르쳐준 개인 프로젝트는 보여줄 수 있다. 핵심은 뛰어난 모델 하나가 아니다. 불완전한 모델들이 내가 전체 시스템을 머릿속에 담아두지 않아도 검사하고, 거부하고, 이어갈 수 있는 결과물을 만들어내는 방식에 관한 이야기다. 나는 이를 AI 에이전트 군단이라고 부른다. 하지만 그 실체는 범위가 제한된 역할, 별도의 검수·승인 절차, 지속 가능한 증거, 예산, 인간의 책임으로 구성된 운영 모델이다.
Codex 앱 이전: 터미널을 손으로 연결했다
나는 이미 터미널에서 Claude Code와 Codex CLI를 함께 집중적으로 사용하고 있었다. 둘 다 저장소를 보고, 도구를 실행하며, 실제 변경을 수행할 수 있었다. 문제는 조율이었다. Claude에는 Claude의 컨텍스트가 있고 Codex에는 Codex의 컨텍스트가 있었으며, 계획은 또 다른 곳에 있었다. 한 모델이 다른 모델의 결과에 이의를 제기하게 하려면 내가 직접 정보를 옮겨야 했다.
터미널 컨텍스트를 복원하고 세션 사이에서 응답을 전달하는 도구까지 만들었다. 제대로 작동했지만, 여전히 내가 메시지 버스이자 스케줄러, 권한 시스템, 실패 감시자였다.
2026년 8월, Codex 앱이 장기 실행 작업과 파일, 도구, 하위 에이전트, 눈에 보이는 핸드오프를 한 워크스페이스 안에 유지할 수 있다는 사실을 발견했다. 내가 역할과 스킬, 저장소 메모리, 규칙을 제공했다. 서로 다른 모델도 워크플로 안에 계속 둘 수 있었고, 이제 여러 터미널 창이 조직인 척할 필요가 없었다.
분리된 Claude Code와 Codex CLI 컨텍스트를 직접 만든 스크립트와 수동 인계로 연결했습니다.
Codex는 대화, 파일, 도구, 역할과 에이전트 협업을 한곳에 유지했습니다.
새 작업 컨텍스트, 전문 역할, 리포지토리 메모리, 독립 리뷰와 명시적 릴리스 게이트입니다.
도구가 바뀌었습니다. 더 중요한 변화는 머릿속의 조율을 명시적이고 검증 가능한 경계로 옮긴 것입니다.
중요한 변화는 인터페이스가 아니었다. 조율 자체를 프로젝트의 일부로 만들 수 있게 된 것이었다.
책은 나의 첫 실험실이었다
처음부터 에이전트에게 “책을 써라”라고 지시하지 않았다. 오래된 메모와 수많은 불확실성을 Codex에 가져왔다. 우리는 세계관과 인물의 동기, 빠진 장면, 이 이야기가 독자에게 어떤 감정을 남겨야 하는지를 함께 다듬었다. 저장소는 원고와 설정, 결정 사항, 시각적 정본, 제작 상태, 그리고 증거와 버전을 연결하는 Git 이력을 담은 공유 메모리가 되었다.
첫 완성 원고가 나오자 창작에서 가장 쓸모없는 질문을 그만 던졌다. 마음에 드는가?
대신 서로 다른 역할을 맡은 독립된 독자를 만들었다. 목표 독자, 상업 편집자, 연속성 비평가, 모호성 옹호자, 적대적이지만 공정한 회의론자, 그리고 더 좁은 분야의 전문가들이었다. 각자 다른 보고서나 내가 칭찬받길 바란 변경 사항은 보지 못한 채, 깨끗한 원고와 하나의 역할만 받았다.
GPT와 Claude 전반에서 동결된 프로토콜을 실행했다. 이전의 DeepSeek와 Mistral 감사는 같은 벤치마크에 표를 더하는 대신 별도의 증거 경로에 유지했다. 격리된 서로 다른 모델 계열이 동일한 실패 메커니즘을 찾아내는지 보고 싶었다.
유려한 비판 하나는 의견에 불과하다. 한 모델 계열 안에서 여러 번 실행한 결과는 서로 상관된 증거다. 서로 다른 모델 계열이 같은 인과적 빈틈을 찾아내고 내가 직접 확인할 수 있을 때, 다수결로 입증되는 것은 아니지만 근거는 더 강해진다.
새 버전이 테스트를 더 우호적으로 바꿨다는 이유만으로 “개선”되는 일이 없도록 프롬프트와 채점 구조를 동결했다. 원고를 바꾸기 전에는 의심되는 메커니즘과 개입, 예상 효과, 보호해야 할 특성, 되돌릴 조건을 기록했다.
이 과정을 통해 중편소설과 삽화, 제작 자료를 담은 290페이지짜리 검토 빌드가 나왔다. 자동 검사는 통과했지만, 여러 이미지에 명시적인 정본 잠금이 없어 릴리스 게이트는 실패했다. PDF는 완성본처럼 보였지만 기록된 상태는 그렇지 않았고, 나는 이를 무시하고 진행하지 않았다. 이제 해당 이미지는 잠겨 있지만 책 전체를 대상으로 한 새로운 실행은 여전히 필요하다.
그 실패에서 기분 좋은 통과 결과보다 더 많은 것을 배웠다.
다음에는 같은 방법을 소프트웨어에 적용했다
두 번째 개인 프로젝트는 공교롭게도 게임이지만, 핵심은 게임이 아니다. 에이전트가 실제 코드베이스를 변경하고, 비용이 큰 엔진을 실행하고, 동작과 시각적 결과를 검사하며, 불완전한 인프라를 견뎌야 하는 테스트 환경이 필요했다.
소프트웨어 테스트 프로젝트와 예정된 주인공의 콘셉트 아트입니다. 시각적 목표를 정의할 뿐, 현재 빌드가 이미 그 수준에 도달했다는 근거는 아닙니다.
첫 시도에서는 유능한 에이전트 하나가 기능을 해석하고, 설계하고, 구현하고, 테스트하고, 판정하게 했다. 빠르지만 설계는 허술했다. “컴파일된다”가 “작동한다”로, 다시 “더 좋아졌다”로, 마침내 “완료됐다”로 슬며시 바뀌었다. 이 네 가지는 서로 다른 주장이다.
역할을 분리했다. 관리자는 결과를 동결하고, 구현자는 코드를 변경하고, 실행 담당자는 증거를 만들고, QA는 동작상의 실패를 찾고, 시각 및 릴리스 검토자는 결과를 판정했다. 이제 제작자는 자신의 작업을 스스로 수용할 수 없었다.
이 구조는 이번 반복에서 코드 중심 검사들이 놓친 실패를 찾아냈다. 소스는 빌드되었고, 자동 동작 검사는 통과했으며, 캡처 파일도 존재했고, QA는 기술 증거 패킷을 검수해 통과 판정을 내렸다. 하지만 아트 검토자가 이미지를 열어본 뒤 거부했다. 하나는 거의 새까맸고, 핵심 기능은 모든 프레임 밖에 있었으며, 캡처 배율에서는 주인공을 알아볼 수 없었다.
구현은 좁게 정의된 기술 목표를 달성했다. 제품 결과는 수용할 수 없었다. 두 문장 모두 사실이었다.
이 실험은 병렬 처리에 관한 나의 첫 환상도 무너뜨렸다. 16 GB Mac에서 여러 에이전트 세션과 도구 실행이 Unity, 패키지 관리자, 라이선스 프로세스와 동시에 돌아갔다. 메모리 압력이 높아지다가 결국 기기가 멈췄다.
해결책은 더 강력한 프롬프트가 아니라 스케줄러였다. 무거운 쓰기 작업은 한 번에 하나만 실행하고, Unity가 동작 중일 때는 새 에이전트를 시작하지 않으며, 정말로 독립된 작성자에게는 별도의 워크트리를 제공했다. 엔진 실행 전에 저렴한 검사를 먼저 수행하고, 구현 시도 횟수에도 엄격한 한도를 두었다.
에이전트가 많다고 자율성이 저절로 커지는 것은 아니다. 현실의 제약 안에서 신뢰할 수 있게 진전하는 것이 중요하다.
이 패턴은 실제 업무에도 적용됐다
내 운영 환경의 SDK에는 이미 역할별 컨텍스트와 스킬, 규칙, 분리된 책임이 있었다. 둘째 주에는 그 워크플로를 Codex로 옮기기 시작했다. 비공개 결과는 성공을 주장하기에 아직 이르지만, 역할과 증거에 기반한 구조는 창작과 엔진 기반 작업, 전문 업무 전반에 적용할 수 있었다. 그리고 억지로 통과 결과를 만들어내는 대신 실패를 드러내는 경우가 많았다.
재사용 가능한 단위는 “작가 에이전트”나 “Unity 에이전트”가 아니었다. 그들을 둘러싼 조직 패턴이었다.
의미, 범위, 취향, 되돌리기 어려운 결정
범위가 명확한 결과 하나를 배정하고 예산을 관리
리서처 · 제작자 · 엔지니어
별도 작업으로 완료 판정을 반증하려고 시도
결정, 산출물, 매니페스트, 테스트, 인계
제작과 독립 검증은 서로 다른 일입니다. 근거는 리포지토리에 남고, 소유자는 가공되지 않은 운영 과정의 잡음이 아니라 결정을 받습니다.
소유자는 의미와 경계를 정의한다. 오케스트레이터는 범위가 제한된 작업 헌장을 만든다. 전문가는 결과물을 만들고, 별도의 검토자는 완료됐다는 주장이 틀렸음을 입증하려 하며, 저장소는 증거를 보관한다. 트레이드오프와 릴리스, 방향 전환, 정체되거나 충돌하는 작업이 발생하면 소유자가 다시 개입한다.
이것이 지금 내가 가장 많은 시간을 들여 설계하는 계층이다.
실제 자율성의 모습
나는 하루 종일 에이전트가 일하는 모습을 지켜보지 않는다. 평일 아침 업무를 시작하기 전에 책과 소프트웨어 테스트 환경을 위한 범위가 제한된 작업을 동결하고, 개인 작업 큐가 5~7시간 동안 사람의 개입 없이 실행되게 둔다. 업무 시간이 되면 컨텍스트를 전환해 평소 엔지니어링 책임을 수행하는 데 에이전트를 능동적으로 활용한다. 저장소와 작업 큐, 검토 주기는 서로 분리된 상태를 유지한다.
업무가 끝나면 개인 프로젝트 작업 시간에 무엇이 만들어졌는지 확인한다. 채팅의 연속이 아니라 결과물과 테스트, 거부된 주장, 의사결정 패킷을 살핀다. 저녁에는 빠르게 피드백을 받을 수 있는 작은 작업을 활용하고, 역할이나 프로세스를 조정한 뒤, 잠들기 전에는 아침까지 실행할 수 있는 긴 작업을 배정한다.
제품 자체도 중요하지만 지금은 도구의 역할도 한다. 나의 주된 실험 대상은 거의 모든 것을 이런 방식으로 개발하는 방법이다. 작업은 얼마나 오래 안전하게 실행될 수 있는지, 자율성은 어디에서 무너지는지, 어떤 증거가 밤새 살아남는지, 어떤 개입이 다음 작업 시간을 개선하는지 살핀다. 같은 하루 동안 내가 별도의 에이전트로 전문 업무를 능동적으로 처리하는 사이에도 개인 작업 큐는 계속 연산 자원을 소비할 수 있다. 이는 주의의 병렬화가 아니라 연산의 병렬화다. 그리고 토큰 소비량이 에이전트 하나가 질문 하나에 답하는 경우와 전혀 다른 이유이기도 하다.
덜 격식 있게 말하자면, 나는 도파민에 취해 지냈다. 끊임없이 눈에 보이는 진척이 생기니, 내가 없어도 계속 작동하는 시스템을 만드는 것이 목적이었는데도 잠들기가 놀라울 만큼 어려웠다.
처음이라면 무엇부터 만들 것인가
현재 여러 AI 채팅을 오가며 결론을 손으로 옮기고 있다면, 에이전트 열두 개부터 만들지 말라.
고통을 주는 워크플로 하나와 세 가지 역할로 시작하라.
- 관리자 — 결과 하나와 비목표, 수용 기준, 예산을 동결한다.
- 제작자 — 일관성을 갖춘 최소한의 변경이나 결과물을 만든다.
- 검토자 — 별도의 컨텍스트에서 결과를 확인하며 몰래 직접 수정할 수 없다.
목표와 결정, 증거를 저장소에 넣어라. 설득력 있는 상태 보고가 아니라 결과물을 요구하고, 검토자가 무엇을 확인했는지 인용하게 하며, 결과 하나를 달성하면 작업을 끝내라.
충돌이나 병목, 부족한 전문성 중 무엇을 해결하는 역할인지 명확히 말할 수 있을 때만 역할을 추가하라.
역할에는 배역이 아니라 계약이 필요하다
많은 멀티 에이전트 데모는 뛰어난 개발자와 꼼꼼한 테스터로 등장인물을 구성한다. 성격을 부여하면 프롬프트가 더 자연스러워질 수는 있다. 하지만 책임이 생기지는 않는다.
운영 역할에는 다섯 가지가 필요하다.
- 정의된 입력. 이 역할을 시작하기 전에 무엇이 준비되어 있어야 하는가?
- 범위가 제한된 출력. 어떤 결과물이나 판정을 반환해야 하는가?
- 명시적인 권한. 어떤 도구와 파일, 결정에 접근할 수 있는가?
- 금지된 행동. 방법을 알고 있더라도 다른 곳으로 넘겨야 하는 일은 무엇인가?
- 중단 조건. 작업은 언제 완료, 거부, 차단되거나 인간의 판단이 필요한 상태가 되는가?
“당신은 꼼꼼한 QA 엔지니어다”라는 지시보다 “읽기 전용 권한만 있으며, 발견한 문제를 직접 고칠 수 없고, 모든 실패를 동결된 기준에 연결해야 하며, ACCEPT, REJECT, NEEDS_OWNER_DECISION 중 하나만 반환할 수 있다”는 지시가 더 강하다.
모든 경계의 강도가 같지는 않다. 가능한 경우 파일 시스템 권한과 워크트리, 허용 목록에 든 도구, 리소스 잠금을 사용한다. Unity 잠금의 소유자는 정중한 프롬프트가 아니라 스케줄러다. 문서화된 지시는 더 약하며, 증거 검증 게이트나 인간의 결정 없이는 릴리스를 승인할 수 없다.
업무를 명확히 구성한 뒤에야 모델이 중요해진다. 아키텍처와 최종 검토는 최상위 모델에, 탐색은 더 빠른 모델에, 결정론적 작업은 더 저렴한 모델에, 적대적 검토는 다른 모델 계열에 라우팅할 수 있다. 역할은 이러한 교체에도 살아남아야 한다. 나는 Claude가 Codex에서 만든 계획에 이의를 제기하길 원할 때가 많지만, 이의를 제기하는 모델이 자신이 평가할 구현을 수정하는 것은 원하지 않는다.
컨텍스트는 쌓는 것이 아니라 조립해야 한다
끝없이 이어지는 하나의 대화는 결국 너무 많은 것을 기억하게 된다. 폐기된 요구사항, 원시 로그, 포기한 가설, 더는 존재하지 않는 버전에 대한 자신감 넘치는 요약까지 남는다.
이제 나는 지속 가능한 계층에서 조립한 새로운 실행 컨텍스트를 선호한다.
좋은 역할 프롬프트는 자기소개가 아닙니다. 지속되는 프로젝트 컨텍스트와 좁은 작업 계약 위에 놓이는 마지막 층입니다.
저장소는 조직의 기억이고, 대화는 그 기억을 다루는 인터페이스다.
프로젝트마다 목표, 결정 로그, 현재 반복 단계, 수용 기준, 비목표, 증거 디렉터리, 간결한 최종 핸드오프를 유지한다.
새 작업은 결과 하나에 필요한 내용을 읽고, 증거를 다시 기록한 뒤 종료한다. 운영 과정의 잔여물이 섞이지 않기 때문에 전략적 대화도 계속 유용하게 남는다. 하나의 거대한 컨텍스트보다는 덜 편리하지만 감사하기는 훨씬 쉽다.
비용 청구서가 알려준 병렬화의 진짜 의미
당시 Claude에는 월 약 $100를 지불했고, Codex는 약 $20인 ChatGPT 구독으로 시작했다. 이후 약 $100인 옵션으로 옮겼지만, 소프트웨어와 SDK 작업을 추가한 뒤 약 이틀 만에 주간 한도에 도달했다. 다음으로 표시된 업그레이드는 약 €200였다. 깔끔하게 비교할 수 있는 것처럼 꾸미지 않기 위해 기록 당시의 통화를 그대로 보존한다.
이는 가격 벤치마크가 아니라 2026년 8월의 사용 기록이다. 요금제와 허용량은 바뀌며, 나는 여러 프로젝트에서 장시간의 고강도 추론 워크플로를 실행하고 있었다. 둘째 주가 끝날 무렵에는 두 서비스 모두 잠시 예산을 소진했다.
유용한 교훈은 더 단순하다.
“병렬 실행은 지출 정책이다.”
고강도 검토자 다섯 명을 실행하는 것은 예산 결정이다. 모델과 추론 강도, 에이전트 수, 재시도, 작업 수명은 워크플로 계약에 포함되어야 한다.
현재 내가 사용하는 실전 규칙은 다음과 같다.
- 작업 하나, 결과 하나. 한 번의 반복을 끝낸 작업이 말없이 다음 반복을 시작하지 않는다.
- 제작과 수용을 분리한다. 누구도 자신의 과제를 직접 채점하지 않는다.
- 저렴한 증명부터 한다. 비용이 큰 빌드와 광범위한 검토 패널, 시각 검토 전에 정적 검사나 집중 검토자 하나를 먼저 활용한다.
- 증거에는 출처가 있다. 통과 결과는 특정 소스 버전과 명령, 관련 환경 및 구성, 변경 불가능한 출력에 귀속된다.
- 권한과 예산의 범위를 좁힌다. 검토자는 읽기 전용으로 유지하고, 모델과 런타임, 재시도, 시도 횟수를 제한하며, 되돌릴 수 없는 결정은 소유자에게 돌려보낸다.
- 실패하면 루프를 멈춘다. “입증되지 않음”과 상충하는 판정은 조용히 또 다른 시도를 시작하지 않고 소유자에게 돌아간다.
- 한 번에 프로세스 변수 하나만 바꾼다. 라우팅과 모델을 모두 바꿨다면 결과만 보고 어느 쪽이 효과가 있었는지 입증됐다고 생각하지 않는다.
목표는 모든 토큰을 최소화하는 것이 아니다. 의사결정을 바꾸는 곳에 비용이 큰 추론을 쓰는 것이다.
그래서 이 글이 스스로를 검토하게 했다
신뢰할 수 있는 에이전트 워크플로에 관한 글을 게시하면서 그 방법을 글 자체에 적용하지 않는 것은 터무니없게 느껴졌다. 그래서 동결된 스냅샷을 네 역할, 즉 사전 정보가 없는 독자, 기획 편집자, 팩트체크 담당자, 실무자에게 보냈고, GPT와 Claude에서 각각 한 번씩 실행했다. 내부 보고서 여덟 개 모두 revise를 반환했다.
합의, 위험, 취향 판단을 분리
수정, 유지, 검증 또는 기각
여덟 번의 검토가 여덟 개의 독립된 출처는 아닙니다. 서로 다른 모델 계열의 의견이 모이면 우선순위가 높아지지만, 확인과 저자의 판단을 대신하지는 않습니다.
두 모델 계열은 같은 과장된 주장에 이의를 제기했고, 제목과 이 섹션을 얼마나 남겨야 하는지를 두고는 의견이 엇갈렸다. 비공개 보고서는 이 글이 좋다는 사실을 입증하지 않는다. 내가 직접 확인할 수 있는 주장을 드러냈을 뿐이다. 파이프라인에는 편집하거나 게시할 권한이 없었으므로 결정과 책임은 내게 남았다.
여전히 인간의 몫인 것
책이 무엇을 의미하는지, 어떤 비판이 중요한지, 어떤 모호성을 보존할지, 제품 방향을 어떻게 정할지, SDK에 대한 책임을 누가 질지는 위임하지 않았다. 에이전트는 검사하고, 구현하고, 테스트하고, 이의를 제기할 수 있지만 책임까지 떠안을 수는 없다. 인간의 역할은 더 높은 단계로 이동하지만 사라지지는 않는다.
내 일은 갈수록 조직을 설계하는 일이 되고 있다. 컨텍스트가 어디에 존재할지 정하고, 충돌하는 권한을 분리하며, 증거와 예산을 정의하고, 시스템이 실제 결정을 마주했을 때 개입한다.
프롬프트 엔지니어링은 응답 하나를 개선할 수 있다. 조직 설계는 수개월 동안 쌓인 불완전한 응답을 유용하게 만들 수 있다.
나는 14년 전의 꿈과 터미널 창 사이를 연결하는 직접 만든 릴레이로 시작했다. 2주 뒤에는 모든 단계를 지켜보지 않아도 같은 조직 패턴이 책과 소프트웨어 실험, 전문 워크플로의 일부를 움직이고 있었다.
모델과 인터페이스, 요금제, 한도는 바뀔 것이다. 오래 남는 역량은 지능을 스스로 틀렸다고 말할 수 있는 조직으로 바꾸는 능력이다.
다음에는 이 설정의 기반이 되는 구체적인 템플릿, 즉 역할 계약과 작업 헌장, 증거 패킷, 어떤 작업에 어떤 모델을 쓸지 결정하는 규칙을 공개할 예정이다.