여러 자료를 읽고 비교 보고서를 쓰게 한 뒤, 완성된 문서에서 기준 기간이 잘못됐음을 발견하면 비교표와 결론까지 함께 고치게 됩니다. 앤트로픽(Anthropic)의 워크플로 설계 설명은 앞 단계의 출력을 다음 단계에 전달하는 prompt chaining과 중간 검사 지점을 소개합니다. 개요가 기준을 충족하는지 확인한 뒤 본문을 쓰는 것도 그 예로 듭니다.
작업을 나누는 기준은 앞 단계가 틀렸을 때 영향을 받는 범위와 중간 결과의 확인 가능성입니다. 짧은 과제도 사실 확인과 외부 제출 사이의 경계가 필요할 수 있고, 긴 초안도 방향이 정해져 있다면 한 번에 작성한 뒤 검토할 수 있습니다.
앞 단계가 바뀌면 무엇을 다시 써야 하는지 봅니다
작업의 의존 관계는 한 단계의 결과가 다음 단계의 입력이 되는 관계입니다. 보고서의 비교 대상을 잘못 골랐다면 그 뒤의 자료 선택·평가·결론이 모두 영향을 받습니다. 이미 정한 내용을 같은 문체로 고치는 작업은 수정이 일부 문장에 머무를 수 있습니다. 두 작업은 글자 수가 같아도 나눌 이유가 다릅니다.
Zhou 등의 Least-to-Most 연구는 복잡한 문제를 쉬운 하위 문제로 나누고 앞서 구한 답을 사용해 순차적으로 푸는 방식을 제안했습니다. 연구의 관측 대상은 기호 조작·조합적 일반화·수학 추론 과제입니다. 업무 문서 작성의 품질이나 시간 절감률을 직접 측정한 결과로 옮길 수는 없습니다.
문서 작업에서는 확정되지 않은 독자, 비교 대상, 사실 근거가 여러 절에 영향을 줄 때 앞에서 확인할 가치가 있습니다. 반대로 맞춤법 수정, 정해진 항목의 표 변환, 표현 대안 만들기는 최종 결과를 보고 확인하기 쉬운 경우가 많습니다. 작은 출력이라도 틀린 채 다음 작업에 쓰이면 영향 범위는 커집니다.
다음 표는 단계 분리를 검토할 때 쓸 판단 축입니다. 같은 과제라도 자료의 상태와 검토 방식에 따라 선택이 달라집니다.
| 판단 축 | 한 번의 요청으로 시작하기 쉬운 조건 | 중간 결과를 나누어 확인할 조건 |
|---|---|---|
| 앞뒤 의존 관계 | 입력·판단 기준이 이미 정해짐 | 자료 선정이나 핵심 결론을 먼저 정해야 함 |
| 오류의 영향 범위 | 일부 문장·형식 수정으로 복구 가능 | 여러 절·후속 산출물에 같은 오류가 퍼짐 |
| 확인 가능성 | 최종 결과에서 오류를 바로 대조 가능 | 사실표·개요 등 중간 산출물이 더 쉽게 검토됨 |
| 자료의 불확실성 | 자료가 짧고 충돌·누락이 적음 | 출처 충돌이나 미확인 조건이 결론을 바꿈 |
| 전달 비용 | 단계 사이에 자료를 다시 정리할 부담이 큼 | 보존할 근거와 결정을 작은 결과물로 넘길 수 있음 |
모든 조건에 점수를 붙여 합계로 결정할 필요는 없습니다. 어떤 오류가 어느 결과를 바꾸는지 설명할 수 있으면 검토 지점도 그 앞에 놓을 수 있습니다. 설명할 수 없는 형식적인 단계는 관리할 항목만 늘릴 수 있습니다.
단계의 끝에는 다음 단계가 실제로 쓸 결과를 남깁니다
‘자료를 이해한다’, ‘깊이 생각한다’는 지시만으로는 사람이 중간에 확인할 대상이 생기지 않습니다. 문서 목록과 각 자료의 역할, 주장별 근거 구절, 개요와 절별 질문처럼 바깥에 남길 결과물을 정합니다. 이를 보면 사실을 잘못 읽었는지와 글의 방향을 잘못 정했는지를 구분할 수 있습니다.
다음 단계에 넘길 자료에는 최종 목표, 변하지 않는 요구, 선택한 판단과 이유, 남아 있는 불확실성이 포함됩니다. 중간 요약에서 숫자의 단위나 조건을 빼면 이후 단계가 원문으로 돌아가지 않는 한 그 정보가 빠진 상태로 진행됩니다. 자료를 줄일 때도 무엇을 확인하지 못했는지 함께 남깁니다.
앤트로픽의 prompt chaining 설명은 고정된 하위 과제로 명확히 나눌 수 있는 작업에 이 방식을 쓰고, 중간 단계에 검사를 둘 수 있다고 설명합니다. 업무 문서에서는 ‘필수 질문이 개요에 있는가’, ‘핵심 주장에 근거가 있는가’처럼 통과 여부를 확인할 항목을 정할 수 있습니다.
단계를 나누었다고 매번 사람의 승인이 필요한 것은 아닙니다. 누락된 필드처럼 규칙으로 확인할 수 있는 항목은 기계 검사에 맡길 수 있고, 자료 충돌이나 목적 변경처럼 해석이 필요한 지점은 사람이 봅니다. 허용한 범위 안의 표현 수정과 새로운 결정이 필요한 변경을 구별하면 검토 횟수를 줄일 자리가 보입니다.
FAQ 개편안 작성 과제를 입력·출력·검토로 나눕니다
다음은 팀에 제출할 FAQ 개편안을 만드는 가상 업무입니다. 자료의 역할과 중간 결과를 보여 주기 위한 구성 예시이며, 실제 고객 문의를 분석하거나 FAQ 개편 효과를 측정한 결과가 아닙니다. 한 사람이 같은 AI와 순차적으로 작업하는 상황으로 두며 별도 에이전트나 동시 실행은 필요하지 않습니다.
입력은 세 자료입니다. S1 문의 메모에는 ‘비밀번호 재설정 메일이 늦는다는 문의가 반복됐다’고 적혀 있습니다. S2 기존 FAQ에는 비밀번호 변경 방법은 있지만 재설정 메일 안내는 없습니다. S3 작업 범위에는 ‘문구와 FAQ 항목 수정만 포함하며 메일 시스템 변경은 제외한다’고 적혀 있습니다. 세 자료는 문제 관측, 기존 상태, 허용 범위를 각각 맡습니다.
처음부터 시스템 개선 효과까지 들어간 제안서를 완성하면 S3의 범위를 벗어나기 쉽습니다. 자료를 확인하는 단계에서는 ‘메일이 늦는다는 문의가 있었다’는 관측과 ‘메일 시스템이 느리다’는 원인 판단을 나누어 남깁니다. 문의 메모만으로 실제 발송 지연의 원인이나 시간을 확정할 수는 없습니다.
아래 단계표는 개편안의 근거가 바뀌면 어디부터 다시 작업할지 찾도록 만든 것입니다. 사람의 확인은 모든 문장 사이가 아니라 뒤 단계의 방향을 바꾸는 결과물에 둡니다.
| 단계 | 입력 | 남길 결과 | 확인할 지점 |
|---|---|---|---|
| 1. 자료와 범위 확인 | S1 문의 메모, S2 기존 FAQ, S3 작업 범위 | 자료별 역할, 확인한 관측, 범위 제한, 자료가 없는 질문 | 문의 관측을 시스템 원인으로 바꾸지 않았는가 |
| 2. 개편안의 구조 결정 | 1단계 기록과 제출 목적 | 독자가 결정할 질문, 절별 결론 후보, 필요한 근거 ID | 문구·FAQ 수정 범위 안에서 선택지가 제시되는가 |
| 3. 초안 작성 | 확인한 개요와 원문 근거 | FAQ 추가안, 안내 문구 초안, 적용 전에 확인할 항목 | 원문에 없는 대기 시간·효과·정책을 만들지 않았는가 |
| 4. 최종 대조 | 초안, 입력 원문, 완료 조건 | 근거와 문장 대조 결과, 수정본, 미확인 목록 | 제한·예외가 요약과 본문에 보존되는가 |
1단계 기록은 ‘E01: S1의 문의 관측’, ‘E02: S2의 안내 항목 부재’, ‘R01: S3의 수정 범위’, ‘M01: 실제 메일 도착 시간은 자료 없음’처럼 남길 수 있습니다. 원문 파일과 위치도 함께 적습니다. 짧은 ID는 근거를 찾는 이름입니다. 실제 내용은 원문으로 대조합니다.
2단계의 결론 후보가 ‘재설정 메일을 받지 못했을 때의 안내 항목을 추가한다’라면 E01·E02를 근거로 연결할 수 있습니다. ‘메일 도착을 빠르게 만든다’는 문장은 R01의 범위를 벗어나고 원인 자료도 없습니다. 이 차이는 문장을 길게 쓰기 전에 개요에서 확인할 수 있습니다.
3단계에는 미확인 항목도 함께 넘깁니다. 실제 메일 발송 조건이나 고객이 기다려야 할 시간을 모른다면 그 부분은 확인 항목으로 남깁니다. 승인된 개요가 있다는 이유로 AI가 부족한 사실을 채울 권한까지 얻는 것은 아닙니다.
4단계에서는 개요와의 일치만 보지 않고 원문과 최종 문장을 대조합니다. 중간 요약에 잘못 들어간 원인 판단을 모든 단계가 충실히 따랐다면, 개요와 초안은 서로 일치해도 같은 오류를 공유합니다. 같은 AI의 자기 점검과 별도로 원문·자료 소유자의 확인이 필요한 지점을 구분합니다.
재작업할 때는 바뀐 자료의 영향 범위를 따라갑니다
단계별 결과에 자료 이름과 판본을 붙이면 수정된 사실의 영향을 추적하기 쉽습니다. S2가 갱신되어 이미 재설정 메일 안내가 있었음이 확인되면 E02와 그 근거를 사용한 개요·본문을 다시 봅니다. S1의 문의 관측까지 자동으로 틀린 것으로 처리할 이유는 없습니다.
수정 요청에도 어느 단계의 오류인지 적습니다. ‘문서를 다시 써 달라’는 요청보다 ‘2단계의 선택지가 작업 범위를 벗어났다. R01을 적용해 개요를 수정하고 영향을 받는 본문만 다시 작성한다’는 요청이 수정 대상을 분명히 합니다. 누락된 사실을 문체 단계에서 고치려 하면 표현을 고치는 동안 같은 결론이 남을 수 있습니다.
앤트로픽의 평가 설계 지침은 실제 과제를 반영하는 평가와 구체적인 성공 기준을 권합니다. 문서 작업에 적용할 때는 결과물의 형식과 핵심 사실의 정확성을 따로 확인합니다. 보기 좋은 개요를 만들었다는 사실과 근거가 맞는 문서를 만들었다는 사실은 확인 방법이 다릅니다.
자기 점검을 한 번 더 요청하면 누락을 찾을 기회는 생기지만, 앞서 만든 판단을 그대로 받아들일 수도 있습니다. 외부 제출 전에 근거를 원문으로 돌아가 확인하거나 담당자에게 미확인 조건을 확인하는 작업은 단계 수만 늘리는 일과 구별됩니다. 무엇을 확인했는지 기록이 남아야 다음 수정에서도 같은 검사를 찾을 수 있습니다.
중간 검토의 비용까지 포함해 단계 수를 정합니다
작업 시간에는 AI의 응답 대기, 사람의 검토, 단계 사이 자료 전달, 오류 뒤 재작업이 함께 들어갑니다. 사실표를 만드는 데 쓴 시간이 뒤의 재작성을 줄이는 경우도 있지만, 단순한 작업을 여러 단계로 나누면 검토와 전달이 더 오래 걸릴 수 있습니다. 어느 쪽인지는 같은 과제를 실제로 처리한 기록으로 비교할 대상입니다.
앤트로픽의 워크플로 설명은 가능한 단순한 해법에서 시작하고 필요할 때 복잡성을 늘리도록 권하며, 에이전트 시스템의 작업 성능과 응답 지연·비용 사이의 절충을 설명합니다. 단계별 호출에 대해서도 이 절충을 생각할 수 있습니다. 단계가 늘어날수록 각 출력이 짧아져도 요청·전달·검토의 횟수는 늘어납니다.
처음 설계할 때는 뒤의 방향을 크게 바꾸는 한 지점에 검토를 두고, 최종 결과에서 놓치는 오류가 계속되는지 볼 수 있습니다. 핵심 근거가 자주 잘못 읽히면 사실표 확인을 앞당기고, 근거는 맞는데 요청한 질문이 빠지면 개요 확인을 추가합니다. 이미 안정적인 형식 변환에는 새 승인 단계를 넣을 이유가 적습니다.
한 번의 요청으로 확인 가능한 일은 그 방식으로 시작하고, 오류가 퍼지는 경계에 중간 결과와 검토를 추가하는 편이 좋습니다. 단계마다 다음 작업에 필요한 근거와 미확인 조건을 넘길 수 있는지가 분리의 완료 기준입니다.
자료 확인 기준: 2026년 10월 28일 UTC. FAQ 개편 예시는 가상 작업이며 시간·품질 개선의 실측값은 없습니다.

AI 자동화 하네스 완전 가이드: 프롬프팅과 컨텍스트 엔지니어링으로 AI 워크플로우 구축하기
AI 하네스는 단순 프롬프트를 넘어, 프롬프팅·컨텍스트·도구·검증을 하나의 파이프라인으로 묶은 자동화 시스템입니다. Claude Code와 CLAUDE.md를 중심으로 실전 하네스를 직접 설계하고 운영하는 방법을 처음부터 끝까지 정리했습니다.
멀티에이전트는 언제 도움이 될까: 분업 비용과 결과 통합
조사할 범위가 넓어져도 모든 작업을 동시에 나눌 수 있는 것은 아닙니다. 앞 단계 의존성과 공유 자료를 먼저 구분하고, 위임·중복·검수·통합까지 포함한 분업 비용을 기록합니다.
AI 에이전트가 멈추지 않을 때: 반복·시간·비용의 중단 조건
같은 오류를 다시 만나는 실행과 자료를 더 찾으며 전진하는 실행은 중단 기준이 다릅니다. 진척 신호와 호출·시간·비용 한도를 함께 두고, 끝날 때 남길 상태와 인계 정보를 정합니다.
AI 작업을 다음 사람에게 넘기는 법: 원본·출처·버전·판단 기록
완성된 문장만 전달하면 다음 담당자는 무엇을 근거로 썼고 어디까지 실행했는지 다시 조사하게 됩니다. 결과물에서 원본·판단·검증·외부 반영 상태를 찾아갈 수 있는 인계 기록이 필요합니다.
