파블은 설계만, 코덱스가 짓는다 — 토큰 80% 절감 루프
두 구독을 묶어 비싼 모델은 판단만, 빌드는 병렬 빌더에 맡기는 오픈소스 스킬
고성능 모델의 토큰을 아끼는 가장 확실한 방법은 그 모델에게 코드를 안 쓰게 하는 것이다. 깃허브에 공개된 오픈소스 프로젝트 아키텍트 루프(architect-loop)는 이 발상을 그대로 구현했다. 클로드 파블(Claude Fable)은 설계·검수만 맡고, 실제 코딩과 리서치는 GPT-5.5 코덱스(Codex)가 병렬로 수행하는 교차 벤더 루프를 클로드 코드(Claude Code) 스킬 두 개로 묶었다. 제작자는 이 구조로 파블 토큰 사용을 80% 줄였다고 밝혔다.
무슨 일인가
최상위 모델은 똑똑하지만 비싸고, 사용량 한도도 빡빡하다. 아키텍트 루프는 API 키 없이 이미 결제 중인 정액 구독 두 개(클로드 유료 플랜 + 챗GPT 플랜)만으로 돌아가도록 설계됐다. 설치는 저장소를 받아 스크립트 하나 실행하고 코덱스 CLI를 설치하면 끝이며, MIT 라이선스로 공개돼 있다. 명령은 두 개다. /architect는 빌드 루프, /architect-research는 무엇을 만들지 정하기 전의 조사 루프다.
핵심 짚어보기
/architect 한 사이클의 구조가 핵심이다. 파블은 짧은 세션 하나에서 판단만 한다. 먼저 PR 하나 분량의 작업 조각을 명세하고, 합격 기준(게이트)을 문서로 못 박은 뒤, 작업을 파일 집합이 겹치지 않는 1~4개 레인으로 쪼갠다. 그러면 레인마다 코덱스 빌더가 각자의 깃 워크트리(worktree)에서 병렬로 코드를 짓는다. 빌더는 명세에 의문이 있으면 따져야 하고(무언 순응은 결함으로 간주), 선언한 파일만 건드릴 수 있으며, 샌드박스가 .git을 보호해 커밋 자체가 불가능하다.
검수도 흥미롭다. 파블은 빌더의 보고를 믿지 않고 게이트 명령을 직접 실행해 확인한 뒤, 테스트 통과 여부가 아니라 명세 의도에 맞는지 디프를 읽고 나서야 병합한다. 검수는 매번 새 세션에서 이뤄지는데, 같은 세션에서 자기 작업을 검토하는 것보다 교차 맥락 검토가 낫다는 판단에서다. 기억은 오직 저장소에만 남긴다. 핸드오프 문서, 게이트 폴더, 깃 히스토리가 전부고 '저장소에 없으면 일어나지 않은 일'로 취급한다.
1인기업 실전 적용 포인트
- 구독 한도가 빠듯하다면 역할 분리부터 시작하라. 비싼 모델에는 '명세 작성·결과 검수'만 시키고, 구현은 저렴한 모델·도구에 맡기는 것만으로 한도 체감이 달라진다.
- 전체 루프를 도입하지 않더라도 '합격 기준을 코드 작성 전에 파일로 고정'하는 습관은 오늘 바로 적용할 수 있다. 에이전트가 기준을 임의로 고치지 못하게 막는 것이 요점이다.
- 병렬 작업을 시킬 때는 이 프로젝트처럼 레인별 파일 집합을 겹치지 않게 선언시켜라. 멀티 에이전트 충돌의 대부분은 같은 파일을 동시에 만지는 데서 온다.
- 검수는 작업한 세션이 아닌 새 세션에서 시켜라. 컨텍스트를 비운 검토가 자기 합리화를 줄인다.
전망 / 주의점
두 구독을 동시에 유지해야 하고, 코덱스 CLI 버전 요구사항 등 설정 부담이 있다. 벤더 두 곳의 약관·한도 정책 변화에도 취약하다. 그럼에도 '모델별 단가에 맞춰 역할을 나눈다'는 설계는 구독 요금제 시대의 비용 최적화 전략으로 주목할 만하다. 별점 36개의 초기 프로젝트인 만큼 작은 작업부터 검증하며 쓰는 것이 안전하다.
출처: GitHub — DanMcInerney/architect-loop (https://github.com/DanMcInerney/architect-loop)