자료를 받아 보고서 초안을 만드는 업무 자동화를 만든 적이 있다. 입력 자료를 읽고 문장을 정리하는 동작은 끝까지 돌아갔다. 테스트도 실패하지 않았다. 그런데 결과물을 열어 보니 실제 업무에서 요구한 섹션과 표가 빠졌고 항목 순서도 달랐다. 코드가 멈춘 곳은 없었지만 그 보고서를 그대로 공유할 수는 없었다.
원인은 구현보다 앞에 있었다. 내가 계획서에 결과물의 필수 구조를 적지 않았다. Claude는 내가 준 요구를 바탕으로 계획을 만들었고 Codex는 그 계획을 따라 구현했다. 테스트도 계획에 적힌 조건을 검사했다. 필수 섹션이 계획 밖에 있었으니 테스트가 통과해도 내가 원한 보고서는 나오지 않았다. 사람 손으로 출력 형식을 다시 맞추면서 한 가지를 분명히 봤다. 자동 검증은 명세에 들어온 조건을 잘 확인하지만 사람이 빠뜨린 조건까지 복원해 주지는 않는다.
이 경험 뒤로 나는 “검수를 생략한다”는 말을 쓰지 않는다. 개인 초안을 만드는 동안에는 자동 검증에 많은 일을 맡긴다. 팀에 공유하거나 외부 시스템에 결과를 넘기기 전에는 사람이 멈춰서 본다. 지금 내가 쓰는 흐름은 Claude가 계획을 만들고 Codex가 구현과 테스트를 맡은 뒤 내가 최종 결과를 확인하는 방식이다. 모델 역할은 바뀔 수 있어도 공유 전 사람 검수라는 경계는 작업의 위험도를 따라 정한다.
계획이 틀리면 테스트도 같은 방향으로 통과한다
계획서는 구현 지시문인 동시에 테스트가 바라볼 기준이다. 계획에 “보고서를 생성한다”라고만 적으면 파일이 생겼는지 확인하는 테스트로 끝나기 쉽다. 실제 사용자는 제목, 요약, 근거 표, 다음 행동처럼 정해진 구조를 기대한다. 계획이 그 구조를 담지 않으면 구현자는 빠진 항목을 오류로 인식할 근거가 없다. AI 에이전트도 같은 제약을 받는다.
내 보고서 자동화에서 테스트가 통과한 이유도 단순했다. 입력 파일을 읽었고 결과 파일을 만들었으며 실행 중 예외가 나지 않았다. 개발 관점에서는 확인할 항목을 모두 통과했다. 업무 관점에서는 필수 항목이 빠진 미완성 결과였다. 두 판정이 갈린 까닭은 테스트 품질보다 완료 조건의 범위에 있었다.
같은 실패는 코드 리뷰만 추가해도 남을 수 있다. 리뷰어가 코드 품질과 오류 처리를 살펴봐도 요구 문서에 없는 표를 찾아내기는 어렵다. 사람 리뷰어에게도 원래 결과물의 기준이 필요하다. 나는 검수 인원을 늘리기 전에 계획서가 실제 사용 장면을 묘사하는지 확인한다. 누가 결과를 받는지, 어떤 형식으로 넘기는지, 받는 사람이 어떤 항목을 보고 다음 일을 시작하는지까지 적는다.
Anthropic의 Claude Code 모범 사례는 에이전트가 자기 작업을 확인할 수단을 제공하고 탐색, 계획, 구현 순서를 분리하라고 안내한다. 이 원칙은 내 실패를 설명하는 데 도움이 됐다. 확인 수단을 주는 일은 테스트 명령을 한 줄 적는 데서 끝나지 않는다. 사람이 기대한 결과를 기계가 검사할 문장으로 바꾸는 작업이 먼저다.
Claude에게 계획을 맡길 때 완료 조건까지 적는 법
나는 Claude에게 계획을 부탁하기 전에 입력과 결과물의 경계를 적는다. “자료를 요약해 보고서를 만든다”라는 요청에는 판단해야 할 빈칸이 많다. 입력 파일의 종류, 빠진 자료를 처리하는 방식, 보고서 독자, 필수 항목, 파일 이름이 모두 열려 있다. Claude가 그 빈칸을 자연스럽게 채워도 내 업무 규칙과 맞는다는 보장은 없다.
OpenAI의 Codex 모범 사례는 목표, 맥락, 제약, 완료 기준을 구체적으로 주는 방식을 권한다. 나는 네 항목에 human_review_gate를 더한다. 에이전트가 어디까지 처리하고 어느 지점에서 사람에게 결과를 넘겨야 하는지 계획 단계에서 정하기 위해서다. 계획서가 길어지는 것보다 검사 가능한 문장을 남기는 편이 낫다.
goal: "입력 자료를 내부 공유용 보고서 초안으로 바꾼다"
input:
type: "문서와 표 형태의 원자료"
missing_data: "빈 항목을 추측하지 말고 확인 필요로 표시"
required_sections:
- "요약"
- "근거 표"
- "확인할 항목"
constraints:
- "원자료에 없는 수치나 이름을 만들지 않는다"
- "원자료 위치를 결과와 연결한다"
done_when:
- "필수 섹션이 지정한 순서로 존재한다"
- "각 근거를 원자료에서 다시 찾을 수 있다"
- "샘플 입력과 누락 입력 검사가 통과한다"
human_review_gate: "팀 공유 또는 외부 시스템 등록 직전"
위 예시는 내 경험을 특정 회사 양식으로 공개하지 않으면서도 실패 원인을 드러낸다. required_sections가 빠지면 예전 실수를 반복한다. done_when이 “파일 생성 성공”으로 끝나면 내용이 어긋난 보고서도 완료로 처리한다. human_review_gate가 없으면 자동화가 초안을 만든 뒤 어디서 멈춰야 하는지 사람마다 다르게 해석한다.
계획을 받을 때 나는 바로 구현으로 넘기지 않는다. 요구한 항목이 빠졌는지 읽고 모호한 표현에 표시한다. Claude가 만든 계획의 문장 하나를 테스트나 눈으로 확인할 수 없다면 그 문장을 다시 쓴다. “품질을 높인다”는 완료 조건이 되기 어렵다. “필수 섹션을 지정 순서로 만들고 원자료 링크를 남긴다”는 문장은 구현과 검수에 같은 기준을 준다.
Codex의 테스트가 확인할 수 있는 것과 없는 것
Codex는 계획이 분명할 때 강하다. 파일을 수정하고 테스트를 실행하며 실패 원인을 찾아 다시 고친다. 내가 직접 코드를 한 줄씩 읽는 것보다 자동 테스트가 빠르게 잡는 오류도 많다. 사내 POC에서 반복 입력, 파일 변환, 문서 생성처럼 범위가 좁은 작업은 이 장점을 쓰기 좋다.
다만 테스트는 사람이 작성한 판정 규칙 안에서 움직인다. 파일 존재 여부, 필드 형식, 정해진 섹션, 금지 문자열, 함수 반환값은 코드로 검사하기 쉽다. 보고서가 회의에서 바로 쓰일 만큼 읽기 좋은지, 핵심 판단이 원자료와 맞는지, 받는 사람이 다음 행동을 결정할 수 있는지는 별도 판단이 필요하다. LLM을 채점자로 붙여도 평가 문구가 틀리면 같은 문제가 반복된다.
나는 검사를 세 층으로 나눈다. 첫 층에서는 스키마, 테스트, 링크와 파일을 기계가 확인한다. 다음 층에서는 Codex가 계획과 변경 범위를 대조하고 실패한 테스트를 고친다. 마지막 층에서는 사람이 실제 결과물을 열어 독자의 업무와 맞는지 본다. 세 층을 모두 같은 강도로 쓰지 않는다. 개인이 버릴 수 있는 초안에는 첫 두 층만 적용하고 공유가 시작되는 지점에서 마지막 층을 연다.
OpenAI의 코드 리뷰 안내는 자동 리뷰를 추가 검토자로 쓴다고 설명한다. 내 작업에서도 같은 구분이 맞았다. Codex가 테스트와 자체 검토를 마친 기록은 유용한 증거다. 사람은 그 증거를 바탕으로 확인 범위를 줄인다. 업무 목표와 위험은 여전히 사람이 책임진다.
검사 실패를 다루는 방식도 계획서에 넣는다. 테스트가 깨지면 Codex가 수정한 뒤 다시 실행한다. 원자료가 비었거나 형식이 달라서 판단이 필요한 경우에는 값을 만들어 통과시키지 않고 작업을 멈춘다. 자동화가 멈추는 비용은 잘못된 보고서가 팀에 퍼진 뒤 수정하는 비용보다 작다.
개인 초안과 공유 가능한 결과물 사이의 검수 경계
POC라는 이름만 보고 위험이 낮다고 판단하면 안 된다. POC도 회사 자료를 읽거나 메시지를 보내고 외부 시스템에 값을 쓸 수 있다. 코드 규모가 작아도 행동의 결과는 클 수 있다. 나는 프로젝트 이름보다 실패했을 때 되돌릴 수 있는지를 기준으로 검수 강도를 정한다.
| 작업 상태 | 자동 검증 | 사람 확인 | 실패 시 행동 |
|---|---|---|---|
| 내 컴퓨터에서 만드는 개인 초안 | 스키마, 테스트, 필수 항목 검사 | 선택 | 결과 폐기 후 다시 실행 |
| 팀에 공유할 문서 | 자동 검사와 원자료 연결 확인 | 공유 전에 필수 | 누락 항목을 고친 뒤 새 버전 공유 |
| 메시지 발송이나 외부 시스템 등록 | 자동 검사와 dry-run | 실행 전에 필수 | 실행을 멈추고 대상과 권한 재확인 |
| 개인정보, 권한, 결제 처리 | 테스트와 보안 검사 | 설계와 실행 단계에서 필수 | 자동 진행 금지, 승인 기록 보존 |
개인 초안은 되돌리기 쉽다. 형식이 틀리면 파일을 지우고 다시 만들면 된다. 팀 공유부터는 다른 사람이 잘못된 결과를 근거로 일할 위험이 생긴다. 외부 발송과 시스템 등록은 한 번 실행한 뒤 회수하기 어렵다. 개인정보와 권한은 노출이나 오작동이 생기면 파일 한 개를 지우는 것으로 복구되지 않는다.
이 경계는 사람에게 모든 코드를 읽으라는 규칙이 아니다. 사람은 계획서의 완료 조건과 실제 결과물을 대조한다. 보고서라면 필수 구조와 근거를 확인하고 발송 작업이라면 대상과 권한을 확인한다. 테스트 로그 전체를 반복해서 읽는 대신 기계가 잘하는 검사와 사람이 맡을 판단을 나눈다. 검수 시간을 줄이면서도 책임을 남기는 방식이다.
내 기준에서 사람 검수는 팀 공유 직전에 시작한다. 자동화가 개인 작업 공간 안에서 초안을 여러 번 만드는 동안에는 기계 검사를 활용한다. 다른 사람이나 외부 시스템에 영향을 주는 순간에는 내가 결과와 대상을 확인한다. 이 선을 계획서에 적어 두면 속도가 바쁜 날에도 검수 여부를 감으로 정하지 않는다.
다음 POC에서 사용할 계획·구현·검수 계약
다음 POC에서는 도구 이름부터 고르지 않는다. 먼저 실제 업무 하나를 골라 입력, 결과 형식, 공유 지점을 적는다. 같은 계획을 읽은 동료가 어떤 파일이 나오면 끝인지 말할 수 있어야 한다. 설명이 갈리면 구현을 시작하기 전 계획을 고친다.
Claude에는 업무 맥락과 결과물의 독자를 설명하고 계획을 요청한다. 내가 그 계획에서 누락 조건과 모호한 완료 문장을 찾는다. Codex에는 승인한 계획과 검사 명령을 함께 준다. Codex가 구현과 테스트를 마치면 나는 코드 전체보다 생성된 결과, 원자료 연결, 공유 대상을 먼저 확인한다. 위험이 높은 변경에서는 코드와 권한 설정까지 검토 범위를 넓힌다.
작업이 끝난 뒤에는 사람 손으로 다시 고친 부분을 계획서에 남긴다. 보고서의 섹션을 바꿨다면 다음 계획의 required_sections에 반영한다. 원자료 연결이 부족했다면 done_when에 추적 조건을 추가한다. 재작업 기록을 남기면 다음 자동화의 검수 항목이 구체화된다. 도구가 좋아지기를 기다리지 않아도 같은 실수를 줄일 수 있다.
Claude가 계획에 잘 맞고 Codex가 구현에 잘 맞는다는 판단은 내 현재 작업에서 얻은 가설이다. 이 역할이 다른 팀에도 맞는지는 별도 평가가 필요하다. Claude와 Codex를 고를 때 승률표보다 먼저 볼 것에서는 같은 POC를 두 역할로 나누고 누락과 재작업을 기록하는 평가표를 만든다.
보고서 자동화에서 내가 놓친 것은 코드 한 줄이 아니었다. “완료된 보고서가 어떤 모습인가”라는 문장이었다. 지금은 그 문장을 계획서에 쓰고 Codex가 검사하게 만든다. 결과물이 내 작업 공간을 벗어나기 전에는 내가 마지막으로 읽는다.