Opus는 판단만 하고, 실행과 대기는 기계와 하위 모델에 맡긴다

Opus 세션 하나가 처음부터 끝까지 카드 한 장의 요청 해석과 설계 채택, 검수, 완료 승인을 모두 맡는다. 이 역할을 카드 담당이라 부른다. 중간에 다른 Opus 관리자를 두지 않는다.

더 저렴한 하위 모델이 코드 수정과 시험 실행, 배포 대기를 맡는다. 하위 모델이 적은 완료 보고는 믿을 수 없다. 작업이 끝날 때마다 하위 세션이 검증 스크립트를 실행해 명령의 원출력과 변경분을 파일 하나로 묶는다. 담당은 보고문 대신 이 증거 파일만 읽고 판단한다.

직접 확인해야 하는 코드 구조나 화면 그림은 같은 세션의 작은 읽기 전용 하위 에이전트를 불러 살핀다. 큰 파일과 긴 로그가 담당의 본 대화에 누적되면 이후 호출마다 비용이 불어나기 때문이다.

비용과 판단력 두 기준을 모두 충족해야 한다

비싼 Opus 토큰 소비를 줄이면서 Opus의 업무 판단력도 온전히 지키는 데 목표를 둔다. 기계로 처리할 작업은 기계가 보조하고, 더 저렴한 모델을 적극 활용해도 좋다. 그렇다 해도 아래 두 기준 가운데 한쪽만 좋은 안은 채택하지 않는다.

• 비용: Opus의 「API 호출 횟수 × 그 시점의 대화 크기」 총합이 실제로 줄어야 한다. 부담이 다른 Opus 세션으로 이전될 뿐이면 줄어든 것이 아니다.
• 판단력: 지금 Opus가 하는 요청 해석, 설계 채택, 검수, 완료 승인의 질이 떨어지지 않아야 한다. 판단에 필요한 자료를 확인할 방법이 막히면 안 된다.

여섯 가지 전제는 바꾸지 않는다

1. 카드 한 장의 최종 책임은 Opus 카드 담당이 진다. 설계와 작업 검수 판단은 반드시 Opus가 한다.
2. Sol, Terra, Astra, Luna 같은 OpenAI 계열 모델은 여러 세션을 지휘하는 역할에 쓰지 않는다. 조사나 구현, 명령 실행처럼 맡은 일 하나는 수행할 수 있다.
3. Anthropic 모델은 구독 계정의 Claude Code 하니스 세션으로만 실행한다. 이 하니스에는 대화 도중에 하위 에이전트를 부르는 기능이 있다. 하위 에이전트가 도구를 실행해 얻은 출력은 부모 대화에 누적되지 않고, 결론만 부모 대화로 돌아온다.
4. 한 사람이나 소수 팀 규모에 맞춘다. 드문 예외까지 대비하느라 상태와 추상화를 복잡하게 만들 필요는 없다. 서버 코드는 고칠 수 있지만, CI 호스트와 배포 절차, 스키마 적용 순서는 리포마다 다르므로 서버 도구 하나로 일괄 처리하지 않는다.
5. 하위 모델의 완료 보고문은 검증 없이 신뢰할 수 없다.
6. 담당 세션의 대화는 25만 토큰 안팎에서 압축되도록 상한을 낮춘다.

아래 수치는 모두 2026년 11월 11일에 측정한 기록이다. 도구를 한 번 부를 때마다 API 호출이 한 번 일어나고, 그때까지 누적된 대화 전체가 다시 입력된다. 캐시가 유지되더라도 비용은 「호출 수 × 대화 크기」로 누적된다.

하루 동안 카드 담당 Opus 36개 세션이 295턴을 실행하며 입력 토큰 12.9억 개를 썼다. 세션을 시작할 때 기본으로 들어가는 지침만 7만 토큰이었고, 호출당 평균 대화 크기는 약 20만 토큰이었다. 전체 입력의 46.7%는 대화 크기가 25만 토큰을 초과한 상태에서 이뤄진 호출이 차지했다. 가벼운 프로필로 새 Opus 세션을 만들더라도 첫 호출 입력이 약 6만 토큰이다. 이 호출에는 캐시 쓰기 단가가 적용되는데, 이 단가는 캐시 읽기의 12.5배다.

검수 턴에서 직접 고치고 기다리는 호출이 비용을 불렸다

다섯 세션에서 「검수 턴」 55개를 따로 집계했다. 하위 작업의 완료 알림을 받고 재개된 턴이다. 이 턴들의 도구 호출은 1,422회, 입력은 2.93억 토큰으로, 같은 다섯 세션 전체 입력의 약 57%였다. 검수 대상 변경의 크기는 파일 수 중앙값 7개(최대 41개), 줄 수 중앙값 221줄(최대 2,663줄)이었다. 검수 턴 하나의 호출 수 중앙값은 16회(최대 148회), 입력 중앙값은 285만 토큰이었다. 특히 입력이 많은 상위 8개 턴이 검수 입력의 55%를 차지했다. 이 8개 턴에서는 예외 없이 담당이 코드 수정부터 배포와 화면 확인까지 직접 처리했다.

검수 턴의 호출 1,422회를 용도에 따라 분류해 입력 토큰 비중을 구했다. 비중이 큰 순서대로 카드 도구가 14.2%(242회), 화면과 실행 확인이 11.5%(181회), 미분류 셸 명령이 11.3%(161회), 머지와 배포가 8.7%(108회), 변경 보기가 7.2%(104회)였다. 머지와 배포의 108회에는 상태 조회와 대기 61회, 승인 21회, 머지 14회가 포함된다. 그다음은 도구 검색 5.1%(75회), 워크트리 관리 약 5%(62회), 위임 4.7%(74회), 하위 기록 읽기 4.4%(60회), CI 조회 3.7%(59회), 스킬 조회 약 3%(54회), 시험을 직접 실행한 호출 2.5%(28회), 변경과 무관한 코드 읽기 2.2%(25회)였다. 위 갈래들과 중복되는 별도 집계도 있다. 작업 완료를 기다리는 셸 호출만 따로 세면 93회이고, 입력의 8.1%였다.

앞선 세 가지 대안은 효과가 절반에 그치거나, 실정에 맞지 않거나, 부담만 이전했다

대화 압축 상한만 낮추는 방안은 효과가 절반 이하에 그친다. 25만 토큰을 초과한 호출이 전체 입력의 46.7%에 불과하기 때문이다. 서버가 CI와 머지, 배포를 대행하는 방안은 리포마다 환경과 절차가 제각각이라 맞지 않는다. 두 번째 판(2판)은 카드 담당과 실무 세션 사이에 중간 Opus 관리자를 두었다. 그러나 중간 관리자가 검증 호출을 똑같이 수행하면서 비용 부담만 다른 Opus 세션으로 이전됐다.

하위 보고만 믿었다면 실제 결함 다섯 건을 놓쳤다

비용을 아끼겠다고 담당이 검증을 생략할 수도 없다. 하위 세션이 정상 통과라고 보고한 작업에서 담당이 직접 결함 다섯 건을 적발했기 때문이다.

• (가) 앱 시험 단언 실패: 하위 세션은 시험을 통과했다고 보고했으나, 담당이 CI를 조회해 단언 실패를 확인했다.
• (나) 계약 시험 8건 실패: 통과 보고와 달리, 같은 커밋의 CI를 조회해 8건 실패를 확인했다.
• (다) 글자 명암 대비 미달: 명암 대비를 보완했다고 보고했으나, 측정 로그 출력을 직접 읽어 기준 미달 수치가 남은 것을 찾았다.
• (라) 그림 배치 결함: 그림 경고가 0건이라고 보고했으나, 그림 파일을 직접 확인해 지나치게 긴 배치와 중복 상자를 발견했다.
• (마) 배포 필수 목록 누락: 빌드와 시험을 모두 통과했다는 보고와 달리, 코드 열람과 시험 실행 과정에서 배포 필수 목록의 새 항목 누락이 드러났다.

다섯 가지 원리로 실행과 판단을 분리한다

• 관찰 기록만 읽기: 모델이 작성한 보고문은 믿지 않는다. 명령의 원출력, 종료 코드, 변경분, 검색 결과, CI 결론은 실행 시점의 기록이므로 Opus는 이 관찰 결과만 읽는다.
• 최종 판정은 Opus: 기계의 관찰 결과는 증거일 뿐이며, 그 증거가 사용자 요구사항을 충족하는지는 Opus가 판단한다.
• 단일 Opus 책임: 판단은 카드 담당 Opus 하나가 끝까지 맡는다. 스크립트가 중간 관리자 대신 부실한 완료를 막고 관찰 기록을 수집한다.
• 탐색과 판단 분리: 기계 검색이 호출부와 등록 파일의 원문을 찾아오면, Opus는 그 원문을 읽고 판단만 내린다. 설계 검토나 기계 검색으로 드러나지 않는 연결 확인은 작은 새 대화에서 수행한다.
• 대화 크기 보호: 담당의 도구를 제한하는 목적은 실행, 편집, 대기, 탐색을 하위 모델과 기계에 맡기는 데 있다. 담당이 판단 자료를 확인할 수단은 남겨 두면서, 큰 자료가 본 대화에 누적되는 현상만 막는다.

담당에게서 셸과 편집, 검색 도구를 빼려면 그 일을 대신 수행할 하위 역할이 있어야 한다. 조사원은 작업 전에 관련 코드 원문과 호출부 검색 결과, 실행할 시험 명령을 모아 오는 일회용 세션이다. 구현원은 확정된 명세에 따라 코드를 고치고 시험과 PR 작성까지 마치는 세션이다. 배달원은 검수를 통과한 커밋을 머지하고 배포와 배포 뒤 확인까지 마치는 일회용 세션이다. 눈은 담당 세션에서 필요할 때만 실행되는 읽기 전용 하위 에이전트로, 코드 구조나 그림 원본을 읽고 핵심 몇 줄만 돌려준다. 수습공은 구현원이 같은 원인으로 두 번 연속 실패했을 때만 직접 수정하는 일회용 Opus 세션이다.

카드 도구도 중간 턴에는 한 번만 부르고 마감 때 모은다

카드 도구는 검수 턴 입력의 14.2%(242회)를 차지했다. 별도 묶음 도구를 개발하기 전이라도 호출 규약으로 먼저 줄인다. 발주나 반려, 승인 같은 중간 턴에서는 상황판 갱신 한 번만 호출한다. 노트 작성, 확인 항목 보고, 첨부 등록은 작업 단위를 마감하는 턴에 한꺼번에 모아서 호출한다.

하위 세션이 검증 조건을 바꾸지 못하게 기준본 파일 하나로 고정한다

말로만 수정 범위와 검증 명령을 일러 주면, 하위 세션이 실패한 시험을 빼먹거나 지정하지 않은 파일을 수정해도 대조하기가 번거롭다. 담당은 작업 단위마다 기준본 파일을 하나 확정하고, 모든 하위 세션이 그 파일 경로를 공유하게 한다. 구현 과정에서 새로운 조건이 드러나 내용을 고쳐야 할 때도 담당만 이 파일을 수정한다.

기준본에는 다음 여섯 가지 항목을 적는다.

1. 작업 목적과 수정할 파일, 폴더 범위
2. 실행 가능한 검증 명령 문자열 목록. 시험과 빌드, 린트, 측정 명령을 적는다. 수치 기준이 있으면 기준에 못 미칠 때 0이 아닌 종료 코드로 끝나게 작성한다.
3. CI 완료를 기다리는 명령과 대기 시간 한도
4. 그림 같은 산출물 경로
5. 수정하지 않더라도 증거 꾸러미에 원문을 포함할 「함께 볼 파일」 목록
6. 이번 작업에만 필요한 배포 뒤 확인 명령 한두 줄

기준본에서는 배포할 노드 순서나 중단 조건 같은 리포 공통 절차를 생략한다. 그 절차는 배달원이 리포의 기존 배포 스킬에 맞춰 수행한다.

봉인 스크립트가 검증과 CI 대기를 대신하고, 미통과는 구현원이 한 번 고친다

시험이나 CI 확인을 거치지 않은 완료 보고가 제출되면 담당이 깨어나 명령 실행과 대기에 토큰을 소모한다. 어느 리포에서나 공통으로 실행하는 봉인 스크립트가 이 일을 대신한다. 스크립트는 기준본을 읽어 검증을 실행하고 모든 출력을 꾸러미 파일 하나로 묶는다. 부실한 완료를 막는 문지기 역할도 함께 맡는다. 용도에 따라 검수 봉인과 배포 봉인 두 가지로 실행한다.

검수 봉인은 구현원이 작업을 마칠 때 PR 대상 커밋을 기준으로 실행한다. 여기서는 배포 뒤 확인 명령을 실행하지 않는다. 꾸러미에는 다음 일곱 가지를 담는다.

1. 대상 커밋과 기준본 파일 해시, 실행한 곳과 시각, 커밋하지 않은 변경이 남았는지 여부
2. 검증 명령별 실행 문자열과 종료 코드, 원출력. 출력이 길면 일부만 남기고, 잘렸다는 표시와 전문 파일 경로를 함께 적는다.
3. 기준본 명령으로 한도 시간까지 직접 기다려 확인한 CI 결론과 그 CI가 실행된 커밋
4. 변경 목차, 바뀐 줄이 포함된 함수 전체까지 함께 담은 변경분(분량이 크면 쪽을 나눈다), 새로 생성된 파일 목록
5. 두 가지 기계 검색 원문. 첫째는 선언이나 내보내기 줄이 바뀐 이름을 리포 전체에서 참조하는 줄이고, 둘째는 시험용이 아닌 새 파일이 추가됐을 때 같은 폴더의 기존 파일들을 리포에서 참조하는 줄이다. 선언 줄 여부는 구문 분석기 없이 export, def, func, class, interface, type 같은 흔한 예약어로 거칠게 구분한다.
6. 기준본에 지정한 「함께 볼 파일」의 원문
7. 산출물 그림의 치수 표와 경로

검수 봉인은 꾸러미 맨 앞에 세 가지 판정 가운데 하나를 기록한다.

• 기계 통과: 네 가지 조건이 모두 맞을 때만 기록한다. 첫째, 커밋하지 않은 잔여물이 없다. 둘째, 모든 검증 명령이 종료 코드 0으로 끝났다. 셋째, 대상 커밋과 같은 커밋의 CI가 성공으로 확정됐다. 넷째, 기준본 해시가 발주 때 담당이 전달한 해시와 일치한다. 기계 통과는 최종 합격을 뜻하지 않으며, Opus 검수를 시작하는 최소 조건이다. 잘린 항목과 「눈으로 볼 것」 표시를 묶어 「Opus가 볼 것」으로 함께 표시한다.
• 미통과: 커밋하지 않은 잔여물이 남았거나, 검증 명령이 0이 아닌 코드로 끝났거나, CI가 실패한 상태다. 스크립트도 0이 아닌 코드로 종료한다. 이 실패는 구현원이 고칠 수 있으므로, 구현원은 세션을 끝내지 않고 스스로 한 번 고쳐 다시 봉인한다. 한 번 고친 뒤에도 미통과면 그 상태를 봉인해 끝내고 담당을 깨운다.
• 확인 미완료: 대기 시간 한도를 초과했거나, CI 결과를 읽을 수 없거나 상태를 알 수 없거나, CI가 실행된 커밋이 대상 커밋과 다르거나, 기준본 해시가 달라진 상태다. 사유를 함께 기록한다. 구현원이 고칠 문제가 아니므로 고치지 않고 즉시 봉인해 담당에게 전달한다.

권한이나 환경 제약에 막힌 구현원도 현재 상태를 봉인한 뒤 세션을 종료한다. 기준본을 임의로 고치거나 지정하지 않은 파일을 수정해서 통과시키면 안 된다. 범위 변경이 꼭 필요하면 사유를 적고 종료한다. 기준본을 고쳤거나 지정하지 않은 파일을 수정했다면, 꾸러미에 해시 불일치와 범위 외 수정 표시가 남으므로 담당이 확인할 수 있다. 서버 완료 문지기는 시범 단계에서 만들지 않는다. 하위 세션이 끝났을 때 꾸러미가 없거나 커밋이 다르면 담당을 깨우지 않고 되돌리는 장치인데, 시범 운영에서 봉인 없이 종료하는 사례가 잦을 때만 도입한다.

배포 봉인은 배달원이 배포를 마칠 때 실행한다. 앞 단계에서 확인한 검증 명령과 변경분은 생략하고 네 가지 항목만 담는다. 머지된 커밋, 노드에 실제로 반영된 커밋이나 빌드 식별자, 배포 뒤 확인 명령의 종료 코드와 원출력, 배포 뒤 그림의 치수다. 모두 정상이면 기계 통과를, 확인 명령이 실패하면 미통과를, 대기 한도를 초과하거나 상태를 알 수 없으면 확인 미완료를 기록한다.

코드 구조와 그림은 눈이 먼저 읽고, 필요할 때만 담당이 경로로 직접 연다

담당 세션이 코드 전문이나 그림 원본, 긴 로그를 직접 읽는 순간 대화 크기가 급증하고 이후 모든 호출 비용이 커진다. 눈 호출 여부를 담당의 짐작에만 맡겨 두어도 필요한 확인을 빠뜨리거나 눈을 과하게 부르기 쉽다. 따라서 눈을 부르는 시점을 규칙으로 미리 정한다.

구현 발주 전에 눈을 한 번 부르는 경우는 두 가지다. 하나는 구조를 변경하거나 새 개념을 추가하는 설계 작업이다. 이때는 원문 발췌만으로 판단하지 않고, 눈에게 코드 구조를 먼저 살피게 한다. 다른 하나는 조사원을 생략한 작은 작업으로, 눈 한 번으로 기준본을 정한다. 문구나 상수 값, 한 함수 안쪽만 고치는 단순 작업은 눈 없이 조사 꾸러미만으로 기준본을 확정한다.

검수 단계에서는 봉인 스크립트가 꾸러미 맨 앞에 「눈으로 볼 것」을 표시했을 때 눈을 부른다. 스크립트는 네 가지 조건 가운데 하나라도 해당하면 이 표시를 남긴다. 첫째, 시험용이 아닌 새 파일이 생겼다. 둘째, 함수 본문만 고친 경우를 빼고, 선언이나 내보내기 줄이 바뀐 이름을 변경분 외의 파일에서 참조한다. 셋째, 산출물 그림이 있다. 넷째, 기준본에 지정하지 않은 파일이 수정됐다. 화면 모양이 크게 바뀌는 작업은 세라피엘이 검수한다. 이 표시는 눈을 부르는 최소 기준일 뿐 상한은 아니다. 표시가 없더라도 함수 안쪽만 바뀌어 그 함수를 호출하는 곳에 영향을 줄 것 같으면 담당이 판단해 눈을 부를 수 있다.

반려한 작업을 다시 검수할 때는 직전 검수 이후 새로 생긴 표시가 있는지와, 반려 때 지적한 문제가 해소됐는지만 확인한다. 이미 검수했고 바뀌지 않은 항목은 다시 보지 않고, 수정한 부분과 그 영향만 살핀다. 반려 때 지적한 문제가 해소됐는지는 반드시 최신 증거로 확인해야 하며, 이 확인이 끝나야 검수를 마칠 수 있다. 그림을 봐야 판단할 수 있는 지적이면 수정된 그림을 눈이나 담당이 다시 확인하고, 기계 판정으로 확인되는 지적이면 그 결과를 읽는다.

눈에 과제를 줄 때는 사용자 요구사항과 검수 기준을 함께 전달한다. 눈은 판정 결과와 결정적인 원문 몇 줄(파일 경로와 줄 번호), 미처 확인하지 못한 범위만 간결하게 답한다. 파일 전문은 옮기지 않는다. 그림 원본과 긴 로그는 원칙상 눈이 읽는다. 그래도 눈의 해석이 사용자 요구와 맞는지 대조하거나 근거가 충분한지 직접 확인해야 할 때는, 담당이 필요한 그림이나 로그 구간, 코드 구간을 경로로 직접 읽는다. 눈이 가리킨 구간에 한정되지는 않지만, 파일 전체를 매번 읽지 않고 판단을 마무리하는 데 필요한 부분만 읽는다. 담당에게는 검색 도구가 없으므로, 눈이 대상 파일과 줄 번호를 찾아 알려 준다.

실측에서 나왔던 다섯 결함은 스크립트와 눈이 각각 찾아낸다

• (가)와 (나) CI 단언 실패와 계약 시험 실패: 봉인 스크립트가 CI가 끝날 때까지 기다려 미통과를 기록하면, 구현원이 스스로 한 번 수정한다. 그 수정으로 해결되면 Opus 호출은 0회이고, 해결되지 않으면 실패 원문이 담긴 꾸러미를 담당이 읽는다.
• (다) 글자 명암 대비 미달: 측정 명령이 기준에 못 미치면 0이 아닌 코드로 끝나게 작성해 미통과로 잡는다. 종료 코드로 판정하기 어려운 측정은 두 가지로 처리한다. 원출력이 잘리지 않도록 기준본의 「함께 볼 파일」에 등록하거나, 출력이 잘리면 「Opus가 볼 것」으로 표시해 눈이 전문을 읽게 한다.
• (라) 긴 그림과 중복 상자: 꾸러미의 치수 표에서 비율이 비정상인 그림이 먼저 드러난다. 산출물 그림이 있으므로 「눈으로 볼 것」 표시도 함께 붙어, 눈이나 세라피엘이 원본을 확인한다.
• (마) 배포 필수 목록 누락: 시험용이 아닌 새 파일이 생겼을 때 스크립트가 같은 폴더 기존 파일들의 참조 줄을 검색해 꾸러미에 담는다. 목록 파일에 기존 파일들은 있는데 새 파일만 빠진 상태가 원문으로 드러난다. 「눈으로 볼 것」 표시도 함께 기록된다.

하위 세션이 실행하거나 대기하는 동안 담당은 턴을 종료해 두므로 불필요한 대기 호출이 생기지 않는다.

1. 조사 발주: 담당이 조사원을 생성하고 턴을 끝낸다. 수정할 파일이 명확한 작은 작업은 조사원을 생략하고 눈 한 번으로 대신한다.
2. 기준본 확정과 구현 발주: 담당이 조사 꾸러미를 읽는다. 설계가 필요한 작업이면 눈을 한 번 부른다. 기준본을 확정한 뒤, 그 파일의 해시를 발주문에 적어 구현원을 생성한다.
3. 구현과 검수 봉인: 구현원이 코드를 수정하고 시험한 뒤 검수 봉인을 실행한다. 미통과가 나오면 스스로 한 번 고쳐 다시 봉인하며, 기계 통과가 기록되거나 04절에서 정한 종료 조건에 해당하면 세션을 마친다.
4. 검수와 일괄 반려: 담당이 검수 봉인 꾸러미를 읽는다. 「눈으로 볼 것」 표시가 있거나 추가 확인이 필요하면 눈을 불러 판단한다. 보완할 지적이 있으면 한꺼번에 모아서 반려한다.
5. 머지와 배포 승인: 검수를 통과하면 배달원을 생성한다. 배달원은 머지를 마치고 배포 대기 항목이 준비될 때까지 기다렸다가 담당을 깨운다. 담당은 대상 커밋을 확인해 배포 승인을 누른 뒤, 같은 배달원에게 이어서 진행하라고 지시한다. 현행 「재시작은 위임자가 트리거」 방침을 반영한 절차이며, 주인이 방침을 바꾸면 「그 커밋에 한한 1회 배포 허가」로 배달원에게 일임할 수도 있다.
6. 배포와 배포 봉인: 배달원이 배포를 마치고 배포 봉인을 실행해 꾸러미를 만든다. 일부만 배포됐거나, 반영된 대상이 다르거나, 정해진 절차에 없는 복구가 필요하면 즉시 멈추고 현재 상태를 봉인해 담당에게 전달한다.
7. 최종 확인과 일괄 마감: 담당이 배포 봉인 꾸러미를 읽고, 미뤄 두었던 노트 작성, 항목 보고, 첨부 등록을 한꺼번에 처리한 뒤 작업을 마감한다.

보통 작업 단위 하나를 기준으로 Opus 호출 예산을 추산했다. 이 작업은 파일 7개와 코드 220줄을 고치고, 평범한 수정 반려가 한 번 일어난다. 아래 숫자와 절감 비율은 모두 시범 운영에서 측정하기 전의 가설이므로 미리 확정된 값으로 약속하지 않는다.

2차 검수의 「눈 0회」는 평범한 코드 수정을 가정한 예시다. 직전 검수 이후 새 표시가 생겼거나 그림 결함이 해소됐는지 다시 확인해야 하면 눈 호출이 추가될 수 있다.

담당 대화는 세션 시작 때 주입되는 7만 토큰을 기본으로 하고, 꾸러미만 읽으면 작업 단위마다 2만~3만 토큰씩 늘어난다. 호출 21~24회에 평균 대화 9만~15만 토큰을 곱하면 담당 몫은 190만~360만 토큰이다. 눈은 한 번 부르면 5~10회의 호출이 일어나고, 대화 크기를 3만~6만 토큰으로 잡으면 한 번에 15만~60만 토큰이다. 눈의 첫 호출 입력 크기는 아직 확인하지 않았다.

담당과 눈(0~2회)을 합치면 작업 단위당 190만~480만 토큰이다. 현재는 검수 턴 1회 중앙값이 285만 토큰이고 직접 수습한 턴까지 포함하면 턴 평균이 533만 토큰이다. 단위당 턴 수를 서넛으로 잡으면 현재 소비량은 1,100만~1,900만 토큰 수준이다. 그러나 이 「단위당」 수치 역시 실측값이 아니다. 따라서 다음 계산은 시범 측정 전까지 가설로 둔다. 보통 작업의 비용이 3분의 1 안팎(약 3배 절감)으로 줄고, 호출 100회를 초과하던 직접 수습 턴이 사라져 그만큼 절감이 더해진다는 계산이다.

처음부터 도구를 많이 만들지 않고, 꼭 필요한 설정과 스크립트 하나만으로 시범 운영부터 해 본다.

1. 기술 확인: 프로필 설정에서 하니스 내장 도구(셸, 편집, 검색)를 제외할 수 있는지, 프로필별 대화 압축 상한을 지정할 수 있는지 먼저 확인한다. 눈의 첫 호출 크기가 얼마인지와 모델을 어떻게 고르는지도 함께 확인한다.
2. 설정과 지침 반영: 담당 프로필의 도구 제한과 도구 목록 고정, 압축 상한(25만 토큰)을 설정한다. 역할별 절차는 세션 시작 때 넣고, 카드 기록 규약을 적용한다.
3. 봉인 스크립트 작성: 검수 봉인과 배포 봉인 두 가지를 처리하는, 어느 리포에서나 쓰는 스크립트 하나를 만든다.
4. 시범 운영: 실제 카드 3~5장을 처음부터 끝까지 새 구조로 실행한다.
5. 후속 도구 결정: 시범 운영에서 측정한 숫자를 보고 카드 묶음 도구와 서버 완료 문지기를 만들지 정한다.

비용 총합과 결함을 잡아내는 정도를 함께 측정한다

시범 운영에서는 기존 카드와 시범 카드를 작업 단위와 난도별로 구분해 비교한다. 시작부터 마감까지 실행된 모든 Opus 세션과 모든 눈 호출을 합산하며, 캐시 읽기, 캐시 쓰기, 출력 토큰을 각각 분리해 집계한다. 저렴한 하위 모델의 토큰 사용량과 재작업 횟수도 별도로 센다.

단위당 Opus 호출 수와 평균 대화 크기도 기록한다. 눈 호출, 수습공 투입, 반려, 머지 뒤 재작업, 구현원의 봉인 없는 종료는 각각 횟수를 센다. 판단의 질이 유지되는지는 이렇게 확인한다. 운영에 반영하기 전에 회수할 수 있는 검증용 변경을 만들고, 목록 등록 누락 같은 결함을 일부러 넣어 실제로 잡아내는지 본다.

토의만으로는 더 알 수 없고 직접 실행해 측정해야 하는 항목이 세 가지 남는다. 첫째는 눈의 첫 호출 입력 크기와 실제 비용 단가다. 둘째는 기계 검색 원문과 「눈으로 볼 것」 표시의 조합이, 담당이 직접 탐색하던 때만큼 누락을 찾아내는지다. 셋째는 저렴한 모델이 봉인을 스스로 통과하는 비율과 수습공이 투입되는 빈도다.

여덟 판에 걸친 토의 경과 요약펼쳐 보기

두 번째 판(2판)의 중간 Opus 관리자 안은 검증 비용만 이전한다는 이유로 기각됐다. 이후 Carbon의 초안을 바탕으로 Fable, Astra, Carbon 세 모델이 세 바퀴(3판~8판)에 걸쳐 이견을 조율했다. 호출부 탐색은 기계 검색에 맡기고, 구조 확인과 그림 판독은 「눈」과 스크립트 표시로 처리하기로 했다. 눈의 해석을 재확인해야 하는 경우에만 담당이 경로로 직접 읽는 예외를 인정했다. 봉인 스크립트는 검수용과 배포용으로 구분했다. 대상 커밋의 CI 성공과 발주 해시 일치가 확인된 때만 「기계 통과」를 기록하며, 재검수 때는 반려 때 지적한 문제가 해소됐는지를 최신 증거로 다시 확인하도록 정했다.

1. (가) 중간 Opus 관리자를 두지 않고 갈지: 디렉터는 앞서 카드 담당과 실무 세션 사이에 중간 관리자를 두는 방향을 채택했다. 그러나 디렉터 자신이 지적했듯, 중간 관리자가 검증 호출을 똑같이 수행하므로 비용 부담만 다른 Opus로 이전된다. 이에 8판은 중간 Opus 관리자를 생략하고, 카드 담당 하나와 봉인 스크립트를 조합해 설계했다. 이 구조로 시범 운영을 시작할지 정해야 한다.
2. (나) 배포 승인을 담당이 직접 누를지 배달원에게 맡길지: 현행 방침대로라면 배달원이 배포 대기 상태까지 준비해 알린 뒤, 담당이 커밋을 확인하고 직접 배포 승인을 누른다(단위당 약 3호출). 다른 안을 택하면 검수를 통과할 때 「그 커밋에 한한 1회 배포 허가」를 부여해 배달원에게 배포 완료까지 일임한다. 두 안 가운데 어느 방식을 택할지 정해야 한다.