AI 위에 AI 현장소장 앉히기 — Threads 글이 가리키는 방법과 HC 환경 적용안
Threads 글이 말하는 "AI 위에 AI 현장소장"은 Matt Shumer가 매니저 루프(Manager Loop) 라고 이름 붙인 2세션 구조다. 한 세션(코디네이터)이 목표를 합의하고 체크리스트·단계(phase)를 관리하며 "다음 단계"를 넘기고, 다른 세션(임플리멘터)이 그 한 단계를 goal mode로 끝까지 수행해 증거와 함께 보고한다. 둘은 부모–자식(서브에이전트)이 아니라 완전히 별개 세션이다. HC 환경(Codex 0.146.0 + gpt-6-astra + goal mode 켜짐)에서 바로 시범 운영이 가능하다. 다만 Matt의 공식 가이드·설정 파일은 아직 미공개(2026-09-03 "준비 중")라서, 지금 만드는 것은 리뷰 본문을 근거로 한 재구성이다.
원문 핵심 문장(영어 그대로 인용):
"I'm calling this the Manager Loop: one agent keeps the project moving, while another does the work. I start by having the coordinator interview me until we agree on a goal. It turns that into a checklist of to-dos, then starts an implementer in a separate Codex session... a completely separate agent, not a sub-agent. The coordinator gives it a phase to complete, using goal mode to keep it working toward that phase's finish line, lets it work, and moves it on to the next phase when it's done. The implementer can bring in sub-agents as needed. Essentially, the coordinator takes over the job I'd been doing myself: keeping the work moving through the larger plan."
출처: Matt Shumer, My GPT-6 Astra Review (2026-09-03)
문제: GPT-6 Astra도 긴 프로젝트에서는 어느 지점부터 진척이 정체(plateau) 된다. 계속 일은 하는데 작은 세부에 빠져서 전체 프로젝트는 별로 좋아지지 않는다. Matt은 5가지 배치를 시도했고 마지막 것만 정체를 넘었다.
| 순서 | 시도 | 결과 | 배운 것 |
|---|---|---|---|
| 01 | 롱런(Long Runs) — 큰 요청 하나 주고 계속 돌리기 | 실패 | "끈기(persistence)와 방향(direction)은 별개 문제다. 모델을 계속 일하게 하는 것만으로는 큰 야망 중 다음에 무엇이 중요한지 알려주지 못한다." |
| 02 | 역할과 차선(Roles and Lanes) — 전문 분야별로 나눠 맡기기 | 부분 성공 | 조율·승인이 새 병목이 됨. 다만 "책무를 뚜렷히 나누는 것"의 가치는 확인. |
| 03 | CEO식 감독(CEO-style Supervision) — 감독 에이전트가 주기적으로 점검 | 거의 개선 없음 | 기대와 달리 효과 미미. |
| 04 | 적응형 조직(Adaptive Organization) — 코디네이터가 역할 구조를 바꿀 수 있게 | 가능성은 있었으나 한계 | 배치가 달라도 같은 정체에 도달. |
| 05 | 체크리스트 + 사람이 단계를 넘김(Checklists and Human-Led Phases) | 작동함 | 그런데 "내가 이 루프의 병목이었다." |
| → | 매니저 루프 = 05에서 사람이 하던 승인·다음 단계 지시를 코디네이터 에이전트에게 넘김 | 정체 돌파 | 두 세션, 서로 다른 책무. |
HC에게 중요한 대목: HC의 현재 작업 방식(메인 세션이 기획·검수, 서브에이전트가 실행, HC가 매 단계 판단)은 정확히 05단계다. 잘 작동하지만 HC가 병목이다. 매니저 루프는 그 병목을 에이전트로 옮기는 것이다.
"일을 굴리는" 쪽
"일을 하는" 쪽
임플리멘터는 코디네이터의 서브에이전트가 아니다.
| 항목 | 현황 | 의미 |
|---|---|---|
| Codex CLI | 0.146.0 (~/.local/bin/codex) | goal mode는 0.128.0(2026-04-30)부터, 2026-05-21 GA. 충족 |
| 기본 모델 | gpt-6-astra, reasoning low | Matt과 같은 모델. 단계 작업엔 effort 상향 권장(medium 이상) |
| goal mode | codex features list → goals stable true | 켜져 있음. ~/.codex/goals_1.sqlite 존재 |
| 멀티에이전트 | multi_agent stable true, [agents] enabled=true, 서브에이전트 모델 gpt-5.6-luna(effort max) | 켜져 있음. 동시 한도는 기본값(설정 미지정). 키 = agents.max_concurrent_threads_per_session(구버전 max_threads), 깊이 agents.max_depth(기본 1) |
| goal mode 비대화 실행 | codex exec는 goal 미지원(공식 문서·GitHub 토론 #21764) | 임플리멘터는 TUI 세션으로 띄워야 함 → tmux로 구동 |
| Claude Code 규칙 | 메인=기획·검수, 서브에이전트=실행(CLAUDE.md) | 05단계(사람이 단계 넘김) 형태. 서브에이전트 모델이라 컨텍스트가 메인에 쌓임 |
| 기존 자산 | /codex 스킬(SPEC→codex exec→검수), goal-setup 스킬(흐릿한 부탁→체크리스트), loop-design 스킬, tmux 환경(ct) | 코디네이터 인터뷰·체크리스트 단계는 이미 도구가 있음 |
| 직전 사고 | 2026-09-05~06 단일 세션 28시간·1,172턴으로 Max 한도 97% 소진 | Matt의 01단계(롱런) 함정과 같은 구조. 2세션 분리가 직접 대응책 |
| 안 | 구성 | 장점 | 단점 | 추천 |
|---|---|---|---|---|
| A. Codex 2세션(원본 그대로) | tmux 창 2개. 코디네이터=codex(gpt-6-astra), 임플리멘터=codex + /goal |
Matt 구조와 동일. 전부 ChatGPT 구독 토큰 | 코디네이터가 임플리멘터 창을 조종하는 연결(tmux send-keys·완료 마커) 직접 만들어야 함. Claude Code의 HC 규칙·메모리 미적용 | 2순위 |
| B. Claude Code 코디네이터 + Codex 임플리멘터 | 코디네이터=Claude Code 세션(기획·검수·HC 원칙 보유), 임플리멘터=Codex TUI /goal(tmux) 또는 codex exec |
HC의 기존 분업("Claude 계획·검수, Codex 실행", 2026-07-11 확정)을 그대로 확장. Claude 쿼터는 계획·검수만 쓰고 무거운 실행은 ChatGPT 쪽. 삭제 금지 등 원칙은 코디네이터가 지킴 | goal mode 쓰려면 tmux 조종 필요(첫 파일럿에서 검증). codex exec로 대신하면 goal의 "끝까지 지속"은 약해짐 |
1순위 |
| C. Claude Code 2세션 | 코디네이터=Claude Code, 임플리멘터=claude -p(헤드리스, --resume로 이어가기) |
도구 하나로 통일. 메모리·스킬 공유 | Claude Max 쿼터 이중 소모(어제 소진 사고 재현 위험). goal mode 상당 기능 없음(자체 루프 필요) | 3순위 |
~/Projects/manager-loop/<과제명>/ — GOAL.md(합의문), checklist.md, phases/phase-N.md(지시), done/phase-N.md(증거 보고), progress.md.impl에서 codex 실행(작업 폴더에서), /goal로 단계 1의 완료 기준을 목표로 등록. 코디네이터가 tmux send-keys로 단계 지시문을 보내고, done/phase-N.md의 마지막 줄 PHASE_DONE을 기다린다(파일 감시).너는 이 프로젝트의 코디네이터다. 직접 만들지 않는다.
1) 나와 인터뷰해서 목표·완료 기준·범위 밖을 합의하고 GOAL.md에 적는다. 합의 전에는 시작하지 않는다.
2) 목표를 checklist.md로 바꾸고 3~7개 단계(phase)로 묶는다. 각 단계에 "끝났다"의 증거(파일·명령·기대 출력)를 정한다.
3) 임플리멘터에게 한 번에 한 단계만 넘긴다. 지시문은 내가 요구한 것을 보존하는 범위에서 최소로 쓴다. 방법은 지정하지 않는다.
4) 임플리멘터가 done/phase-N.md에 PHASE_DONE을 쓰면 증거를 직접 확인한다. 통과면 checklist에 표시하고 다음 단계를 보낸다. 미통과면 빠진 것만 짧게 되돌린다.
5) 단계마다 progress.md에 완료율과 시각을 기록한다.
금지: 삭제, 범위 밖 작업 추가, 증거 없는 완료 처리, 임플리멘터 대신 직접 구현.# Phase N/M — <제목>
목표: <한 문장>
완료 기준(증거): <파일 경로 / 실행할 명령 / 기대 결과>
범위 밖: <이번에 손대지 않을 것>
보고: 끝나면 done/phase-N.md에 증거 목록을 적고 마지막 줄에 PHASE_DONE 이라고 쓴다.
서브에이전트: 독립된 부분 작업은 병렬로 나눠 맡겨도 된다.
금지: 파일 삭제, 범위 밖 변경.[agents]
enabled = true
max_concurrent_threads_per_session = 8 # 기본값보다 넉넉히. Matt은 16(일반)·96(과잉 실험)
max_depth = 1reasoning effort는 단계 작업 동안 medium 이상으로.
HC 원칙 그대로: "완료는 도구 결과로 확인한 것만." 임플리멘터의 "했다"는 증거 파일이 있어야 통과. 코디네이터가 재실행·재조회로 확인한 것만 체크한다.
codex exec로는 goal을 못 쓴다. 자동화하려면 tmux로 TUI를 조종해야 하고, 이 연결부가 첫 파일럿에서 가장 먼저 검증할 부분이다.~/Projects/manager-loop/에 폴더·지시문·tmux 연결 스크립트·체크리스트 대시보드(HTML)까지 만들어 첫 단계를 돌려본다. 첫 실행은 HC 입회.codex --version, codex features list, ~/.codex/config.toml (2026-09-06)