나는 이 글의 첫 초안 제목에 극단적인 승률 차이를 넣었다. 두 모델의 검수 성능이 크게 갈린다는 커뮤니티 표를 봤기 때문이다. 숫자는 강했고 내가 느낀 역할 차이도 그 표와 잘 맞았다. Claude는 계획과 검토에서 꼼꼼했고 Codex는 구현과 수정에서 손이 빨랐다는 체감이 있었다.
원자료를 확인하는 과정에서 멈췄다. 어떤 저장소를 썼는지, 성공을 무엇으로 판정했는지, 두 모델에 같은 도구와 지시를 줬는지 알 수 없었다. 시도별 기록도 찾지 못했다. 표를 만든 사람의 환경과 내 회사 POC 환경이 얼마나 비슷한지도 확인할 길이 없었다. 숫자를 본문에 남기면 출처가 없는 체감을 객관적인 모델 서열처럼 포장하게 된다. 그래서 승률과 관련 수치를 모두 버렸다.
수치를 지우고 나니 글에 남은 것은 내 체감 하나였다. 체감은 다음 실험의 가설로 쓸 수 있지만 다른 사람에게 같은 선택을 권할 증거는 아니다. 나는 Claude를 계획에 두고 Codex를 구현에 두는 현재 방식을 유지하되 다음 POC에서 두 도구를 역할별로 다시 보기로 했다. 모델 전체를 한 줄로 세우는 대신 내가 맡기는 일을 계획과 구현으로 나누고 각 결과에서 누락과 재작업을 기록하는 방식이다.
출처를 확인할 수 없는 승률을 버린 이유
모델 비교표를 읽을 때 숫자보다 먼저 확인할 항목이 있다. 과제가 무엇이었는지, 각 모델이 어떤 환경에서 일했는지, 누가 어떤 기준으로 성공을 판정했는지다. 검수 과제라는 이름만 같아도 결과는 크게 달라진다. 한 실험은 코드 버그를 찾는 일을 검수로 부르고 다른 실험은 요구사항 누락과 보안 위험까지 포함한다. 성공 기준이 다르면 같은 승률 표에 놓을 수 없다.
에이전트가 쓸 수 있는 도구도 결과를 바꾼다. 한쪽에는 테스트 실행 권한과 저장소 전체를 주고 다른 쪽에는 diff 일부만 주면 모델보다 환경을 비교하게 된다. 프롬프트의 완료 조건, 컨텍스트 길이, 기존 테스트 상태도 기록해야 한다. 공개된 표에 이 정보가 없으면 나는 그 숫자를 내 업무 판단에 쓰지 않는다.
표본 수가 보이더라도 과제 구성이 없으면 해석이 막힌다. 비슷한 버그만 반복했는지 서로 다른 난이도를 섞었는지에 따라 승률의 뜻이 달라진다. 모델 출력은 같은 입력에서도 흔들릴 수 있다. 한 번의 성공과 실패는 가능성을 보여 주지만 안정성을 말해 주지 않는다. Anthropic의 에이전트 평가 해설은 과제, 시도, 채점기와 전체 실행 기록을 구분하고 여러 시도로 결과의 변동을 확인하는 방식을 설명한다.
내가 봤던 승률표에는 이 구분을 검토할 자료가 없었다. 숫자의 진위를 판정할 자료도 없었다. 그래서 확인할 수 없는 숫자를 내 결론의 근거에서 뺐다. 출처가 다시 공개되면 과제와 판정 방식을 읽고 참고한다. 지금 단계에서 남길 문장은 “Claude와 Codex의 역할 차이를 체감했다” 정도다. 그 체감은 아래 평가표를 만들게 한 출발점으로만 쓴다.
모델보다 먼저 계획 과제와 구현 과제를 분리한다
“어느 모델이 더 좋은가”라는 질문은 내 업무에서 범위가 너무 넓다. 계획서는 요구사항을 찾고 모호한 문장을 줄여야 한다. 구현 작업은 정해진 범위 안에서 파일을 바꾸고 테스트를 통과해야 한다. 두 역할은 읽는 자료와 결과 형식이 다르다. 한 모델이 계획에서 놓친 조건을 구현 속도로 만회하기도 어렵다.
내 체감은 Claude가 계획과 검토에 잘 맞고 Codex가 구현과 수정에 잘 맞는다는 쪽이다. 이 판단을 평가하려면 현재 역할만 시켜서는 안 된다. Claude에 계획 과제만 주고 Codex에 구현 과제만 준 뒤 둘 다 잘했다고 적으면 기존 습관을 확인했을 뿐이다. 같은 계획 과제를 두 도구에 주고 같은 구현 과제도 두 도구에 줘야 역할별 차이를 볼 수 있다.
계획 과제에서는 실제 업무 요청서를 그대로 제공한다. 두 도구 모두 같은 입력 자료 목록, 독자, 제약과 질문 시간을 받는다. 결과 형식도 하나의 계획서 템플릿으로 고정한다. 나는 필수 항목 포함 여부, 모호한 조건을 질문으로 돌려보냈는지, 완료 기준을 검사 가능한 문장으로 썼는지 확인한다. 문장이 매끄러운지는 후순위다. 누락된 요구가 구현 단계에서 재작업을 만들 가능성을 먼저 본다.
구현 과제에는 두 도구 중 하나가 만든 계획을 그대로 쓰지 않는다. 계획 품질 차이가 구현 결과에 섞이기 때문이다. 사람이 검토해 고정한 하나의 계획서, 같은 저장소 상태, 같은 테스트 명령을 Claude와 Codex에 제공한다. 두 도구가 수정할 수 있는 파일 범위와 사용할 수 있는 도구도 맞춘다. 구현 평가는 기능 동작, 출력 형식, 변경 범위와 오류 처리를 기준으로 한다.
이 분리는 Claude로 계획하고 Codex로 구현할 때, 검수는 어디에 둘까에서 정리한 작업 흐름과 연결된다. 앞 글은 현재 내가 쓰는 운영 방식을 설명한다. 여기서는 그 방식이 다음 POC에서도 맞는지 확인하는 절차를 만든다. 운영 규칙과 평가 규칙을 따로 두면 지금의 습관을 영구적인 정답으로 착각할 가능성이 줄어든다.
같은 조건에서 두 도구를 역할별로 평가하는 법
다음 POC 한 건이면 평가를 시작하기에 충분하다. 한 번의 결과로 모델 서열을 만들 수는 없지만 내 작업 기록을 처음 남기는 데는 쓸 수 있다. 실제 업무를 그대로 쓰되 민감한 데이터는 샘플로 바꾼다. 계획 과제와 구현 과제를 분리하고 각 도구에 넘길 입력을 평가 전에 고정한다.
evaluation_case:
name: "자료를 내부 공유용 보고서 초안으로 변환"
role: "planning | implementation"
input_version: "고정한 요구사항과 샘플 자료의 버전"
environment:
repository_commit: "두 도구가 함께 시작할 커밋"
allowed_tools: "읽기, 편집, 테스트에 허용한 도구"
time_limit: "업무에서 허용할 작업 시간"
success_criteria:
machine_checks: "스키마, 테스트, 필수 섹션, 링크"
human_checks: "요구 충족, 원자료 일치, 바로 쓸 수 있는가"
record:
missing_requirements: "도구가 빠뜨린 조건"
failed_checks: "통과하지 못한 검사와 원인"
human_rework: "사람이 다시 고친 내용"
stopped_reason: "완료, 제한 시간, 권한 문제, 판단 필요"
입력 버전을 고정하는 이유는 비교 도중 조건을 바꾸지 않기 위해서다. Claude의 첫 결과를 보고 요구사항을 자세히 보완한 뒤 그 문서를 Codex에 주면 Codex가 유리해진다. 반대 순서도 같은 문제를 만든다. 두 도구의 첫 시도를 끝낸 뒤 발견한 누락은 다음 평가 버전에 반영하고 기존 결과는 그대로 보존한다.
환경 기록에는 모델 이름만 적지 않는다. 저장소 커밋, 허용한 도구, 테스트 명령과 작업 제한을 함께 남긴다. 에이전트가 중간에 질문할 수 있었는지도 기록한다. 계획 과제에서 질문을 막으면 모호함을 발견한 모델도 임의로 답을 채울 수밖에 없다. 구현 과제에서 테스트 실행을 막으면 코드 품질보다 추측 능력을 비교하게 된다.
실행 기록은 최종 답변만 보지 않는다. 어떤 파일을 읽었는지, 어느 테스트에서 실패했는지, 조건이 모호할 때 멈췄는지 남긴다. Anthropic은 이 전체 기록을 trace 또는 trajectory로 설명한다. 결과가 같아도 경로가 다르면 운영 선택이 달라진다. 한 도구는 필수 조건을 질문한 뒤 정확히 끝내고 다른 도구는 여러 번 수정해서 같은 결과에 도달한다. 나는 후자의 재작업을 비용으로 기록한다.
통과 여부와 사람의 재작업을 함께 기록한다
자동 검사는 결과가 최소 조건을 지켰는지 빠르게 알려 준다. 계획서에는 필수 섹션이 있는지, 구현 결과에는 테스트와 출력 형식이 맞는지 검사한다. 그러나 자동 검사만으로 업무에 바로 쓸 수 있는지를 판정하기 어렵다. 요구 문서가 놓친 조건과 원자료 해석은 사람이 읽어야 드러난다.
Anthropic의 성공 기준과 평가 설계 안내는 성공 기준을 구체적이고 측정 가능하게 정의하고 실제 사용 과제와 맞는 평가를 만들라고 권한다. 품질, 일관성, 지연과 비용처럼 여러 기준을 함께 볼 수도 있다. 내 POC에서는 누락과 재작업을 첫 기준으로 둔다. 빠르게 끝낸 결과라도 사람이 필수 항목을 다시 넣어야 한다면 내 업무 시간은 줄지 않는다.
| 역할 | 기계가 확인할 항목 | 사람이 확인할 항목 | 재작업 기록 |
|---|---|---|---|
| 계획 | 템플릿 필드, 필수 제약, 검사 명령 존재 | 모호한 요구를 찾았는가, 완료 상태가 실제 업무와 맞는가 | 사람이 추가한 요구와 다시 쓴 완료 기준 |
| 구현 | 테스트, 파일 범위, 출력 구조, 오류 상태 | 결과가 원자료와 맞는가, 팀에 바로 공유할 수 있는가 | 사람이 고친 코드와 문서, 다시 실행한 작업 |
통과 여부는 규칙과 사람 판단을 함께 쓴다. 기계 검사를 하나라도 통과하지 못하면 구현은 완료로 처리하지 않는다. 기계 검사를 모두 통과해도 사람이 핵심 누락을 발견하면 재작업으로 기록한다. 사람 판단에는 한 줄 근거를 남긴다. “마음에 들지 않음”보다 “근거 표에 원자료 위치가 없어 확인 불가”가 다음 평가에서 쓸 수 있는 기록이다.
속도와 사용량도 관찰할 수 있지만 첫 판정의 중심에는 두지 않는다. 빠른 결과를 고치느라 사람이 오래 붙잡으면 완료 시간의 뜻이 달라진다. 사용 비용이 낮아도 요구를 반복해서 설명해야 하면 업무 비용은 올라간다. 나는 먼저 누락과 수정 내용을 보고 두 결과의 품질이 비슷할 때 속도나 비용을 비교한다.
OpenAI의 Evals 작성 안내는 입력 데이터와 평가 방식을 함께 고정해 반복 실행하는 구조를 설명한다. 내 블로그의 빈 평가표도 같은 원칙만 가져온다. 특정 모델의 공식 벤치마크를 흉내 내지 않는다. 내가 실제로 맡기는 계획과 구현 작업을 같은 조건에서 기록하는 작은 업무 평가다.
한 번 실행한 뒤 결과가 엇갈리면 바로 승자를 정하지 않는다. 같은 입력으로 다시 수행하거나 실패가 우연인지 확인할 다른 과제를 붙인다. 반복할 여유가 없다면 판단에 “한 번의 POC에서 얻은 결과”라고 범위를 적는다. 제한을 기록하는 편이 과장된 승률을 만드는 것보다 쓸모 있다.
한 번의 평가를 영구적인 모델 서열로 만들지 않는다
모델과 도구는 바뀐다. 같은 이름을 쓰더라도 버전, 기본 지시, 사용할 수 있는 도구가 달라질 수 있다. 저장소의 테스트와 내 계획서도 다음 프로젝트에서 변한다. 평가 결과에는 날짜, 모델 식별자, 환경 버전을 남겨야 나중에 다시 읽을 수 있다.
다음 POC에서 Claude가 계획 과제의 누락을 적게 만들고 Codex가 구현 과제의 재작업을 줄인다면 현재 역할을 유지할 근거가 생긴다. 반대 결과가 나오면 역할을 바꾸거나 작업 유형별로 나눈다. 두 도구가 비슷하면 가격과 작업 속도, 사용 한도를 그다음 기준으로 본다. 어느 결과도 “Claude는 계획, Codex는 구현”이라는 문장을 모든 프로젝트의 규칙으로 만들지는 못한다.
평가표는 모델을 평가하는 동시에 내 요구사항을 검사한다. 두 도구가 같은 조건을 빠뜨렸다면 모델 문제가 아닐 가능성이 크다. 업무 요청서나 완료 기준이 모호했는지 먼저 본다. 한 도구만 질문을 통해 빈칸을 발견했다면 계획 역할의 장점으로 기록한다. 둘 다 구현을 끝냈는데 사람이 같은 형식을 다시 고쳤다면 고정 계획서를 수정한다.
나는 지금도 Claude에 계획을 맡기고 Codex에 구현을 맡긴다. 과거의 승률표가 이 선택을 증명한다고 쓰지는 않겠다. 다음 POC의 고정된 입력, 검사 결과, 내가 다시 고친 내용이 선택 근거가 된다. 기록이 쌓여 역할을 바꿔야 한다면 이 글의 결론도 함께 바꿀 생각이다.