Claude가 일하고 Codex가 검수한다: 업무 에이전트를 둘로 나눈 이유
한 모델이 작업하고 다른 모델이 읽기 전용으로 검수하는 업무 에이전트를 직접 만들었습니다. 구조와 권한 등급, 아직 구현하지 못한 부분을 정리했습니다.
AI에게 일을 맡길 때 가장 불안한 지점은 "틀린 줄 모르고 넘어가는 것"입니다. 저희는 이 문제를 줄이려고 업무 에이전트를 둘로 나눴습니다. 하나는 일을 하고, 다른 하나는 그 결과를 검토합니다. 이 글은 그 구조를 실제로 만들며 정한 것과, 아직 만들지 못한 것을 적습니다.
저희가 로컬 컴퓨터에서 운영하는 개인 업무 에이전트의 설계 문서와 구현 기록입니다. 1차 버전(대화와 자동 검수)은 동작하고, 권한 정책과 승인 화면은 설계만 끝난 상태입니다. 어디까지가 구현이고 어디부터가 계획인지 본문에서 구분했습니다.
구성: 작업자 하나, 검수자 하나
화면은 휴대폰에서 쓰기 편한 채팅방 하나입니다. 메시지를 보내면 주작업자가 답하고, 답이 끝나면 검수자가 자동으로 그 답을 검토합니다.
| 역할 | 모델 | 실행 방식 | 권한 |
|---|---|---|---|
| 주작업자 | Claude | 명령줄에서 비대화형으로 호출 | 작업 폴더 안에서 읽기와 쓰기 |
| 검수자 | Codex | 명령줄에서 비대화형으로 호출 | 읽기 전용 |
메시지에 이름을 붙여 부르면 그 에이전트가 답하고, 이름을 붙이지 않으면 주작업자가 답합니다. 두 에이전트는 서로 다른 회사의 모델입니다. 작업한 모델과 다른 모델이 검토하면, 같은 방식으로 틀린 것을 그대로 통과시킬 가능성을 줄일 수 있습니다.
검수자를 읽기 전용으로 둔 이유
검수자가 결과를 직접 고칠 수 있으면, 검수자는 두 번째 작업자가 됩니다. 그러면 검수자가 만든 수정은 누가 검토하느냐는 문제가 다시 생깁니다. 그래서 검수자의 권한 프로필은 항상 읽기 전용으로 고정했습니다. 검수자는 문제점을 지적할 뿐, 파일을 바꾸지 못합니다.
이렇게 하면 역할이 섞이지 않습니다. 결과물을 바꾼 것은 언제나 주작업자이고, 기록을 보면 누가 무엇을 했는지 한 줄로 따라갈 수 있습니다.
검수 의견이 곧바로 명령이 되지 않게 했다
검수자의 지적을 주작업자에게 그대로 넘겨 고치게 하면 간단합니다. 하지만 검수자도 틀립니다. 틀린 지적이 자동으로 수정 명령이 되면, 멀쩡한 결과가 검수 때문에 나빠집니다.
그래서 검수 의견과 수정 실행 사이에 판정 단계를 두었습니다. 검수에서 나온 문제를 항목별로 나열하고, 사람이 각 항목을 "수정" 또는 "보류"로 정합니다. 선택이 끝나면 그 내용이 작업 요청문으로 만들어지고, 이 요청문을 전달해야 수정이 시작됩니다. 선택만으로는 아무것도 자동 전송되지 않습니다.
화면과 모델 사이에 한 층을 두었다
채팅 화면이 모델을 직접 부르지 않습니다. 가운데에 중계 층을 두고, 이 층이 아래 일을 맡습니다.
- 라우팅: 누구를 불렀는지 판단하고, 주작업자의 답이 끝나면 검수를 실행합니다.
- 정책: 에이전트마다 무엇을 할 수 있는지 정해 실행 옵션에 반영합니다.
- 기록: 실행 한 건마다 무엇을 읽고 무엇을 만들었는지 남깁니다.
- 대체 실행: 한 에이전트가 실패하면 다른 에이전트로 넘깁니다.
이 층을 둔 이유는 모델이 바뀌어도 규칙이 남게 하기 위해서입니다. 공용 규칙을 파일 하나에 적어 두고, 각 모델이 읽는 지침 파일로 옮겨 주는 방식입니다. 에이전트의 작업 폴더도 프로젝트 전체가 아니라 전용 폴더로 한정합니다.
행동을 세 등급으로 나눴다
에이전트가 할 수 있는 행동을 위험도에 따라 셋으로 나누었습니다.
| 등급 | 해당 행동 | 처리 |
|---|---|---|
| 자동 허용 | 읽기, 요약, 초안 작성, 작업 폴더 안의 산출물 생성과 수정 | 바로 실행하고 기록 |
| 승인 필수 | 메일 발송, 일정 생성, 공유 설정 변경, 작업 폴더 밖 쓰기, 파일 삭제 | 승인 요청을 띄우고 기다린 뒤 실행 |
| 금지 | 결제와 구매, 비밀번호와 카드 정보 처리, 시스템 전체에 영향을 주는 명령 | 거부하고 사유를 기록 |
기준은 "되돌릴 수 있는가"와 "밖으로 나가는가"입니다. 초안은 지우면 그만이지만, 보낸 메일은 되돌릴 수 없습니다.
어디까지 만들었나
솔직하게 구분하면 이렇습니다.
| 단계 | 내용 | 상태 |
|---|---|---|
| 1차 | 채팅 화면, 두 모델 연결, 호출 대상 판단, 자동 검수 | 동작함 |
| 2차 | 권한 정책, 승인 요청 화면, 실행 기록과 감사 기록, 대체 실행 | 설계 완료, 구현 전 |
| 3차 | 파일 도구, 메일 연동, 공용 스킬 | 계획 |
| 4차 | 외부 접속, 접근 인증, 사용량 집계 | 계획 |
지금의 1차 버전은 대화만 합니다. 파일과 메일 도구는 붙어 있지 않습니다. 메일 분류는 이 채팅 화면이 아니라, 지침 파일을 둔 단일 작업자 방식으로 따로 운영하고 있습니다. 그 결과는 안 읽은 메일 30일치를 AI로 분류한 기록에 있습니다.
만들면서 배운 것
- 권한부터 정하고 기능을 붙인다. 기능을 먼저 만들고 나중에 막으려 하면, 이미 열려 있는 길을 하나씩 찾아 닫아야 합니다.
- 검수는 권한이 아니라 의견이다. 검수자에게 쓰기 권한을 주는 순간 검수가 아니게 됩니다.
- 규칙은 모델 밖에 둔다. 규칙을 대화 속에 두면 세션이 끝날 때 사라집니다. 파일로 두면 모델을 바꿔도 남습니다.
- 기록이 없으면 믿을 근거가 없다. 무엇을 읽고 무엇을 만들었는지 남아 있어야 결과를 확인할 수 있습니다.
자동화를 시작하기 전에 문서로 정해 두어야 할 항목은 자동화를 시작하기 전에 정해야 할 다섯 가지에 따로 정리했습니다.