AXIT에서 Claude와 Codex는 한 작업을 어떻게 나눠 맡을까?
송찬우 5분 분량
지난번 ‘Claude Code가 “수정했습니다”라고 하면, 정말 고친 걸까?’에서 에이전트의 보고 문장은 증거가 아니라고 썼었죠. 제품 안에서도 같은 문제가 그대로 나옵니다. AI 에이전트에게 일을 맡기는 업무 공간 AXIT의 구조를 나눠 정리하는 연재의 첫 편 ‘멀티 에이전트 시스템은 어떤 식으로 설계되어 있을까?’에서는 작업 하나에 계획, 실행, 감독, 검수 네 역할이 붙는다고 했습니다. 이번 편은 그중 판단하는 쪽 이야기입니다. 두 엔진이 한 작업을 나눠 맡을 때 누가 무엇을 확인하는지, 사람은 언제 부르는지까지 같이 정리했습니다.
판단하는 AI와 쓰는 AI를 나눴고, 쓰는 쪽은 한 번에 하나만 둡니다. Claude와 Codex가 함께 일할 때도 같아요. 둘이 같은 폴더를 동시에 고치는 일은 없고, 앞 차례가 끝나야 다음 차례가 옵니다. 사람은 되돌리기 어려운 단계에서만 부릅니다. 다만 이 장치들이 결과물 속 사실까지 확인해 주지는 않습니다. 그 한계도 끝에 같이 적겠습니다.
계획은 한 번 세우고, 실행은 오래 갑니다.
채널에서 일을 맡기면 요청을 받아 작업을 관리하는 서버인 컨트롤플레인이 AI 엔진을 한 번 불러 계획을 세웁니다. 실제 일은 일회용 워커 컨테이너에서 도는 CLI 에이전트가 맡아요. 실행하는 에이전트가 받는 지시문에는 푸시했다거나 PR을 열었다고 말하기 전에 실제 성공 출력을 확인하라는 내용이 포함돼 있습니다. 말로 끝내지 말고 출력으로 확인하라는 겁니다. 그래도 지시문만으로는 모자라서, 실행 바깥에 판단만 하는 호출을 둘 더 둡니다.
감독은 60초 침묵에만 끼어들고, 한 줄만 씁니다.
실행이 60초 넘게 조용하면 감독이 최근 작업 기록 8줄을 읽고 ‘정상:’이나 ‘주의:’로 시작하는 한 줄을 남깁니다. 실행은 멈추지 않아요. 오래 생각하느라 조용한 것일 수도 있어서, 점검이 끝나면 60초를 새로 잽니다. 작업 하나에 세 번까지, 워크스페이스마다 한 번에 하나만 돕니다. 질문 카드에 사람의 답을 기다리는 시간이나 실행할 자리가 나기를 기다리는 시간은 침묵으로 치지 않습니다. 사람을 기다리는 시간까지 에이전트의 침묵으로 적지 않으려는 거예요.
검수는 완료와 미완만 말합니다.
검수는 실행이 성공으로 끝났는데 완료를 보고하지 않은 단계가 남았거나, 완료 기준이 있을 때 돕니다. 요청과 완료 기준, 보고의 끝부분을 읽고 45초 안에 ‘완료’ 또는 ‘미완: 이유’로만 답해요. 미완이면 같은 작업 폴더에서 최대 두 번 이어서 돌립니다. 같은 이유가 연달아 나오면 진전이 없다고 보고 멈추고, 결과에 미완이라고 적습니다. 끝없이 다시 돌리는 것보다 멈춘 자리를 표시해 두는 편이 낫다고 봤습니다.
형식에 맞지 않는 답은 버립니다. 실행 기록에 섞인 지시문이 판정 행세를 하지 못하게 하려는 거예요. 반대로 판정 호출 자체가 실패하면 작업을 막지 않고 통과시킵니다. 판정이 없다는 이유로 끝난 일을 붙잡아 두지는 않습니다.
감독과 검수는 새 모델이 아닙니다. 워크스페이스의 주 엔진을 낮은 추론 수준으로 한 번 더 부를 뿐이에요. 10월 17일부터 28일까지 컨트롤플레인에서 Claude로 돈 감독, 검수 호출은 1,655번이었고, 한 번에 중앙값 5초였습니다.
두 엔진은 마지막 줄 한 줄로 일을 넘깁니다.
Claude와 Codex 자격이 모두 있는 워크스페이스에서는 역할을 나눕니다. Claude가 설계와 계획, 검수를 맡고 Codex가 명령 실행을 맡아요. 넘길 때는 답의 마지막 줄에 ‘Codex, <지시>’나 ‘Claude, <요청>’을 씁니다. 서버는 빈 줄을 뺀 마지막 두 줄에서만 이 줄을 찾습니다. 찾으면 떼어 내 다음 엔진의 입력에 넣고, 사람이 보는 결과에서는 지웁니다.
다음 엔진이 받는 건 앞 단계의 공개 요약과 그 지시뿐입니다. 공개 요약이 6,000자를 넘으면 앞 4,500자와 뒤 1,500자만 넘겨요. 한 순간에 폴더를 고치는 쪽은 언제나 하나입니다. 앞 엔진의 차례가 끝나야 다음 엔진이 시작합니다. 9월에 쓴 ‘에이전트를 여러 개 띄우면 정말 더 좋을까’의 결론, 쓰는 주체는 하나로 두고 판단만 나눈다는 원칙을 작업 하나 안에 그대로 넣은 셈입니다.
넘기기는 네 번까지, 멈추면 어디서 왜 멈췄는지 남깁니다.
넘기기는 작업당 네 번까지입니다. 한도에 닿거나 받을 엔진의 자격이 없으면, 넘기기를 끈 채 한 엔진이 같은 폴더에서 한 번 더 마무리합니다. 그래도 끝나지 않으면 일부 완료로 냅니다. 8월 18일에 받은 요청 뒤로는 일부 완료에 어디서 멈췄는지, 왜 멈췄는지, 이어서 해도 되는지를 꼭 적게 했어요. 사람이 다음 지시를 쓰려면 그 세 가지가 있어야 합니다.
사람은 되돌리기 어려운 단계에서만 부릅니다.
처음에는 모든 작업에 계획 승인을 걸었습니다. 8월 26일부터 9월 25일까지 한 달 동안 승인 대기 740건 중 183건(25%)이 아무도 누르지 않아 만료됐어요. 질문 카드도 483건 중 133건(28%)이 답을 받지 못했습니다. 답이 오면 빨랐습니다. 질문 답은 중앙값 1분 안, p90 22분이었어요. 대신 승인을 거친 작업은 시작까지 중앙값 1.6분이 걸렸고, 승인이 없으면 0.6분이었습니다. 이 숫자에는 스크립트 리허설과 워크숍 참가자의 작업이 섞여 있어서, 실제 사용자가 승인을 누르지 않는다는 뜻으로 읽을 수는 없습니다. 그래도 모든 작업에 승인을 거는 비용은 분명했어요.
9월 25일부터 계획 승인은 기본으로 끕니다. 대신 계획자가 실제로 실행할 위험 단계를 찾으면 계획 끝에 ‘CONFIRM [send]: 이유’ 꼴의 줄을 붙이고, 그때만 멈춥니다. 종류는 send, delete, payment, publish, bulk 다섯 가지예요. 표식을 ASCII 문자로 정한 건 계획을 다섯 개 언어로 쓰기 때문입니다. 작업 중 질문은 60초만 기다리고 추천안으로 먼저 갑니다. 나중에 사람이 다른 답을 고르면 같은 채널에 후속 작업을 하나 맡깁니다.
숙제도 남았습니다. 10월 5일부터 18일까지 저희 회사 워크스페이스에서 위험 표시로 멈춘 작업 156건 중 64건(41%)은 지시에 이미 그 동사가 들어 있었어요. 보내 달라고 해 놓고 보낼지 다시 질문을 받은 셈입니다. 그래서 시킨 일은 다시 묻지 않는 규칙을 만들어 봤는데, 처음에는 ‘배포 없이 PR만’이라는 지시까지 배포 지시로 읽었습니다. 켜기 전 검토에서 잡았고, 이 규칙은 아직 쓰지 않습니다. 묻는 횟수를 줄이는 일도 결국 지시를 제대로 읽는 문제로 돌아왔습니다.
에이전트가 무언가를 만들 땐 한도를 두 겹으로 둡니다.
AXIT에는 정해 둔 때나 조건이 오면 스스로 도는 작업인 마키가 있습니다. 비즈니스 요금제 이상에서 쓰는 기능이에요. 8월 1일 첫 실사용 요청이었던 ‘5분 뒤에 DM 보내줘’는 등록에 96초, 알림 한 통에 6분 넘게 걸렸습니다. 그래서 둘로 갈랐습니다. ‘알려줘’는 서버가 DM과 푸시로 바로 보내고 에이전트를 부르지 않아요. ‘해줘’만 에이전트가 돕니다. 서버가 여러 대여도 같은 분에 두 번 돌지 않게 먼저 표시한 서버만 발화하고, 직전 실행이 아직 돌고 있으면 다음 차례는 건너뜁니다.
예약해 둔 에이전트에서 무서운 건 돌지 않는 것보다 너무 많이 하는 쪽이었습니다. 9월 5일 워크숍에서 28명이 만든 5분 주기 마키 15개가 그날 크레딧의 43%를 썼어요. 지금은 에이전트가 채널과 마키를 직접 만들 수 있어서, ‘네 주제로 주간 보고 해줘’ 한마디에 폴더 1개, 채널 4개, 마키 4개가 섭니다. 그래서 시킨 사람이 못 하는 일은 에이전트도 못 하게 했고, 같은 이름은 새로 만들지 않고 다시 씁니다. 상한은 두 겹입니다. 작업 하나가 만들 수 있는 폴더는 3개, 채널은 10개이고, 그 바깥에 워크스페이스 하루 폴더 12개, 채널 40개 상한이 있습니다.
다만 검수는 보고만 봅니다.
검수는 에이전트의 보고만 읽기 때문에 결과물 속 숫자가 원본 자료와 맞는지는 알지 못합니다. 그래서 고친 건 판정 쪽이 아니라 입력 쪽이었어요. 첨부를 작업 폴더로 가져올 길을 열고, 지시문에 ‘지어내지 마라’와 ‘이렇게 가져와라’를 한 쌍으로 넣었습니다. 금지만 두면 갈 길이 없으니 가져오는 방법을 함께 적은 겁니다.
검수가 실제로 얼마나 자주 ‘미완’을 내는지도 아직 세어 보지 않았습니다. 그래서 이 장치들이 오류를 잡아 준다고 말할 단계는 아닙니다. 지금 말할 수 있는 건 판정의 형식과 횟수, 멈출 자리를 정해 두었다는 데까지입니다.
에이전트를 업무에 붙이는 팀이라면 이 순서를 참고할 만합니다. 판단 호출은 답 형식을 좁게 두고, 판정이 실패하면 막기보다 표시합니다. 다시 돌리기에는 상한과 진전 없음 판정을 둡니다. 엔진끼리는 차례로 넘기고, 넘기는 내용은 요약과 지시로 줄입니다. 사람을 부르는 자리는 계획 속 표식으로 정하고, 에이전트가 무언가를 만들 수 있게 했다면 상한부터 둡니다.
에이전트가 늘수록 검사의 질은 더 똑똑한 판정 모델 하나보다, 어디서 묻고 어디서 멈출지를 미리 정해 둔 자리에서 갈릴 듯싶습니다.