AI 루프 엔지니어링의 완결 조건: 성공·재시도·사람 검토·중단 설계하기

AI가 ‘끝났다’고 말해도 일이 끝나지 않은 이유#

금요일 저녁, AI에게 “이번 주 고객 문의에서 반복되는 불만을 정리하고 다음 주 개선안을 써 줘”라고 맡겼다고 해 보자. AI는 문의 200건을 분석했다고 말하며 그럴듯한 표를 내놓는다. 그러나 실제 입력 파일은 240건이었다. 고객의 제품명을 적은 열도 절반은 비어 있다. AI가 선택한 다음 행동은 무엇일까? 빠진 자료를 확인할까, 문장을 다듬을까, 아니면 ‘완료’ 버튼을 누를까?

이 질문이 AI 루프 엔지니어링의 완결 문제다. 앞서 살펴본 PAOV는 계획(Plan)·실행(Act)·관찰(Observe)·검증(Verify)의 순환을 설명한다. 하지만 순환만으로는 끝이 정해지지 않는다. 루프가 제대로 작동하려면 성공 증거, 실패 시 수정 범위, 다시 시도할 수 있는 한계, 사람이 결정해야 하는 지점이 필요하다.

잘못된 종료	겉으로 나타나는 모습	실제 문제
너무 빨리 종료	“파일이 생성됐으니 완료”	내용이나 원본 대조가 빠짐
너무 늦게 종료	이미 합격한 문서를 계속 다시 씀	시간·비용이 늘고 맞던 부분도 바뀜
끝없이 반복	같은 오류를 같은 입력으로 계속 재시도	원인과 한계를 판단하지 않음
기준을 몰래 바꿈	처음엔 모든 출처를 요구하다 나중엔 일부만 있어도 통과	성공 기준이 실행 중 임의로 완화됨

이 글에서 만드는 최종 산출물은 종료 정책이다. “최대한 노력하세요”라는 문장이 아니라 “무엇을 확인하면 성공이며, 어떤 실패에 한 번 더 도전할 수 있고, 어떤 경우엔 사람에게 넘기며, 무엇이 생기면 즉시 멈추는가”를 기록한 운영 규칙이다.

완료 기준과 종료 정책은 서로 다르다#

완료 기준(Definition of Done, DoD)은 결과물이 갖춰야 할 조건이다. 종료 정책(Stopping Policy)은 성공 외의 상황까지 포함하여 루프가 언제 멈추고 누구에게 넘겨야 하는지 정한 규칙이다. 두 개를 나누어 생각하면 ‘끝내지 못했으니 계속 반복’이라는 함정에서 벗어나기 쉽다.

구분	묻는 질문	고객 문의 분석 예시
완료 기준	결과물이 무엇을 충족해야 성공인가?	입력 240건 처리 여부, 분류되지 않은 건의 목록, 핵심 주장의 원문 근거
재시도 규칙	어떤 문제를 고쳐서 다시 시도할 수 있나?	일시적으로 파일 읽기에 실패하면 경로와 접근 상태 확인 후 재시도
보류·사람 검토	무엇은 AI만으로 판정할 수 없나?	제품명이 비어 있어 어느 제품 불만인지 구별 불가능한 문의
즉시 중단	어떤 일이 생기면 더 실행하면 안 되나?	민감정보가 외부로 나가려는 상황, 승인되지 않은 고객 답변 발송

‘성공’과 ‘중단’은 모두 루프가 끝나는 상태지만 의미는 전혀 다르다. 성공은 합격 증거가 있는 종료다. 중단은 그 증거가 없거나 더 실행하면 안 되는 이유를 명시하고 끝내는 것이다. 사람 검토 역시 멈춰 있는 동안 할 일을 분명히 알려 주는 보류 상태다.

종료 상태를 다섯 가지로 기록하자#

상태	의미	그다음 행동
`SUCCESS`	필수 완료 기준을 모두 충족	결과물과 검증 근거 전달
`RETRY`	원인이 확인됐고 안전하게 다시 시도 가능	한도 안에서 수정 후 재실행
`REPLAN`	목표에 필요한 자료·조건이 달라짐	작업 범위·순서·방법 다시 설계
`HUMAN_REVIEW`	모호한 의미 또는 외부 영향에 사람 판단 필요	미결 항목과 관련 증거를 사람에게 전달
`HALT`	승인·권한·자원 한도 등으로 더 진행하면 안 됨	즉시 중단하고 이유·현재 상태 기록

원문의 ‘성공·재시도·에스컬레이션·안전 중단’ 구조를 실무에 맞게 쓰면 이처럼 재계획도 분리할 수 있다. 파일명 하나를 고치는 일과 분석 대상 자체가 바뀐 일은 같은 재시도가 아니다.

완료 기준(DoD): ‘그럴듯하다’를 증거로 바꾸기#

좋은 기준은 결과물의 목적에서 출발한다. 보고서를 요구했으면 문서 파일뿐 아니라 필수 주제와 수치 근거가 있어야 한다. 문서에서 계약 조항을 추출했으면 텍스트의 존재뿐 아니라 원문 어느 곳에서 가져왔는지가 있어야 한다.

한 업무에 필요한 다섯 가지 질문#

범위: 어떤 입력을 다뤄야 하는가? 날짜, 파일, 문서 버전, 고객군을 정한다.
완결성: 결과물에 빠지면 안 되는 필드는 무엇인가? 누락도 ‘없음’ 또는 ‘확인 불가’로 표시한다.
정확성: 계산과 인용을 어떻게 원본에 대조할 것인가? 재계산, 원문 위치, 샘플 검토를 정한다.
사용 가능성: 파일이 열리는가? 형식과 분량이 실제 사용자 목적에 맞는가?
승인 상태: 사람이 결정해야 할 부분을 AI가 임의로 확정하지 않았는가?

모호한 말	검증 가능한 형태	누가 확인하나?
“알아보기 쉽게 정리”	요청한 세 가지 질문에 각각 답하는 절이 있고 핵심 용어 설명이 있다	담당자 또는 독자 검토
“모든 자료를 분석”	대상 파일 4개와 데이터 기간이 기록됐고 누락된 파일이 없다	파일 목록과 입력 기록
“정확한 통계”	표의 합계가 원본 재계산과 일치하고 모든 수치의 기준 기간이 표시됐다	계산 도구와 표본 검토
“출처를 달아 줘”	외부 수치와 인용마다 원문 위치를 연결하고 링크가 열림을 확인했다	출처 점검
“문제없이 배포”	승인된 범위의 검증을 통과했고 실제 배포는 별도 승인 상태다	자동 검사와 배포 담당자

모든 품질을 숫자 하나로 환원할 필요는 없다. “비전공자가 이해할 수 있는가”는 독자에게 실제로 읽혀 보거나 구체적 질문으로 점검해야 한다. 반대로 “요청한 열이 전부 있는가”는 기계가 확실하게 검사할 수 있다. 기계적 검사, AI의 내용 검토, 사람의 최종 판단을 각자 잘하는 곳에 배치한다.

예제: 경영 보고서의 완료 기준을 다듬기#

“30쪽 이상, 차트 세 개, 문법 오류 다섯 건 이하”는 눈에 잘 보이지만, 숫자가 틀린 30쪽짜리 보고서도 통과시킬 수 있다. 경영진이 다음 분기의 마케팅 예산을 결정하기 위한 보고서라면 이렇게 바꿔 보자.

대상: 2026년 2분기 국내 광고 집행 데이터
반드시 필요한 내용: 채널별 비용, 매출, 전분기 비교, 한계와 제안
필수 통과:
- 표의 총비용·총매출이 원본에서 다시 계산한 값과 일치한다.
- 각 비교 지표에는 기준 기간과 계산식이 있다.
- 출처를 확인할 수 없는 외부 통계를 확정된 수치로 쓰지 않았다.
- ‘다음 분기 예산 제안’ 절에는 근거와 미확인 가정이 구분되어 있다.
- 최종 PDF가 열리고 표가 잘리지 않는다.
승인: 예산을 실제로 변경하기 전 담당자가 검토한다.

이 기준에는 합격의 필수 조건과 사람의 최종 승인이 분리되어 있다. AI가 PDF를 잘 만들었다고 예산 변경까지 실행할 수는 없다.

문서에서 필수 조항을 추출할 때는 ‘없음’도 결과다#

가상의 계약서 한 건에서 계약 기간, 대금 지급 시점, 해지 조건, 손해배상 한도 네 항목을 추출한다고 해 보자. 처음 기준을 “필수 필드 4개가 모두 채워진다”라고 쓰면, 계약서에 없는 내용을 AI가 추측해 빈칸을 채울 유인이 생긴다.

더 나은 DoD는 각 필드의 상태와 근거가 존재한다는 것이다.

필드	허용되는 상태	종료에 필요한 근거
계약 기간	확인됨 / 원문에 없음 / 모호함	확인됨이면 조항·문장 위치
대금 지급 시점	확인됨 / 원문에 없음 / 모호함	날짜 계산 기준과 원문 위치
해지 조건	확인됨 / 원문에 없음 / 모호함	관련 조항의 표현 그대로 대조
손해배상 한도	확인됨 / 원문에 없음 / 모호함	한도 수치와 예외 조항 여부

완료 기준은 ‘네 칸에 무언가 쓰여 있다’가 아니라 ‘네 항목을 근거와 함께 판정했고, 모호한 조항은 사람 검토 대상으로 분리했다’다. 추출 완료와 법적 해석 승인도 구분한다.

기준을 언제 바꿀 수 있나#

실행 중 원본 파일이 잘못되었거나 사용자가 범위를 바꾸는 경우, DoD 변경은 필요할 수 있다. 다만 AI가 도달하기 어려운 기준을 조용히 낮춰서는 안 된다. 변경 전 기준, 변경 이유, 승인한 사람, 변경 시점과 결과에 미치는 영향을 로그에 남긴다.

예를 들어 “5개 문서 모두 확인”이 기준인데 하나가 제공되지 않았다면, 방법은 세 가지다. 문서를 요청한다. 부족한 문서가 있음을 밝힌 부분 결과물을 제출한다. 사용자가 조사 범위를 4개로 바꾸기로 결정한다. 어느 경우에도 AI가 몰래 4개를 ‘완료’로 바꿔 쓸 수는 없다.

태스크 청킹: 실패한 부분만 고칠 수 있게 나누기#

태스크 청킹(Task Chunking)은 큰 목표를 입력·출력·검증 기준이 구별되는 작은 작업으로 나누는 방법이다. 여기서 중요한 것은 짧은 시간 그 자체가 아니라 어디까지 성공했고 무엇을 다시 실행해야 하는지 알 수 있는 경계다.

원고에는 작업을 5~15분 단위로 나누는 예가 많다. 이것을 고정 규칙으로 적용하면 2시간 걸리는 데이터 적재를 15분마다 억지로 쪼개거나, 20분짜리 독립 분석을 불필요하게 분해하게 된다. 작업의 크기는 데이터량, 실행 비용, 실패 시 복구 범위를 보고 결정한다.

좋은 청크의 조건#

입력: 어느 버전의 파일이나 이전 단계 결과가 필요한가?
출력: 파일·표·판정 중 무엇이 생기는가?
검증: 그 결과가 맞는지 어떻게 확인하는가?
재실행: 같은 작업을 다시 하면 다른 데이터를 중복 생성하거나 외부 행동을 반복하는가?
의존 관계: 다른 작업이 이 결과를 기다리는가?

“하나의 청크는 반드시 파일 하나만 만든다”는 규칙도 절대적이지 않다. 분석 작업 한 번으로 요약 표와 오류 목록을 함께 만들 수 있다. 한 번의 실패를 분명하게 감지하고 해당 범위를 다시 처리할 수 있으면 합리적인 단위다.

예제: 30쪽 경영 보고서를 복구 가능한 단위로 나누기#

청크	입력	결과물	통과 검사	실패 시 조치
1. 자료 목록 확인	내부 CSV 두 개, 공식 공개 자료	사용 가능한 자료 목록	날짜·파일 버전·권한 확인	빠진 자료만 요청
2. 입력 정리	확인된 CSV	열 정의, 제외 건수와 사유	행 수·필수 열·중복 여부	정리 규칙 보완
3. 월별 집계	정리한 입력	월별 합계와 재계산 로그	원본 대비 합계 일치	집계 부분만 재실행
4. 차트	확인된 집계	추이 차트	축·단위·값 일치, 이미지 열림	차트만 다시 생성
5. 본문	검증된 집계·차트	보고서 초안	수치 근거와 필수 절 확인	틀린 절 수정
6. 통합 검증	문서·수치 원본	PDF와 판정 기록	표·본문 일치, 파일 표시 확인	연결된 청크까지 역추적

여기서 2가 끝나야 3을 시작할 수 있다. 3의 집계 결과가 있어야 4의 차트가 정확하다. 파일 이름만 서로 다르다고 모든 청크를 병렬로 돌려서는 안 된다. 반대로 서로 다른 출처의 독립적인 자료를 모으는 작업은 병렬로 진행할 수 있다.

네 번째 청크에서 오류가 나면?#

보고서용 차트를 생성할 때 ModuleNotFoundError: No module named 'plotly'가 발생했다고 가정하자. 월별 합계까지 검증됐는데 차트 도구만 실패했다면 전체 CSV 분석을 버릴 필요가 없다. 실행 환경과 의존성 목록을 확인한 뒤, 승인된 패키지 설치나 이미 사용 가능한 도구로 차트를 만든다. 패키지를 임의로 설치하거나 실행 환경을 바꾸는 것은 작업 정책에 따라야 한다. 새 차트가 만들어지면 4번을 검증하고, 차트가 들어간 5·6번 결과도 다시 확인한다.

청킹이란 ‘앞에서 한 일은 영원히 건드릴 필요가 없다’는 뜻이 아니다. 차트 실패가 사실은 집계값의 자료형 오류에서 비롯됐다면, 3번으로 돌아가야 한다. 실패가 발생한 지점과 근본 원인이 생긴 지점을 구분해야 한다.

대용량 자료는 ‘범위’와 ‘검증 상태’로 분리한다#

월별 로그를 분석한다면 하루씩 청크로 나눌 수 있다. 각 청크에 날짜 범위와 입력 버전을 붙이고 완료된 범위를 기록한다. 도중에 23일 자료에서 오류가 나면 나머지 날짜를 어떻게 처리할지 결정한다.

작업: 6월 로그 집계
1~22일: 처리 완료, 검증 통과
23일: 입력 파일 누락, 보류
24~30일: 처리 완료, 검증 통과
전체 월간 집계: 미완료, 23일 누락을 표기

‘일별 처리 성공 29건’과 ‘6월 월간 통계 완성’은 다른 상태다. 빠진 하루의 영향이 크다면 월 전체 결과를 확정하면 안 된다. 같은 레코드가 자정 경계에 중복되지 않는지도 최종 통합 단계에서 확인한다.

청크 저장과 재실행에는 중복 방지가 필요하다#

파일 읽기와 조회는 대체로 다시 해도 외부 상태가 크게 바뀌지 않지만, 주문 생성이나 메일 발송은 다르다. 재시도 전에 이미 처리됐는지 조회하거나, 시스템이 제공하는 중복 방지 키를 사용한다. 이를 멱등성(idempotency)이라고 한다. 핵심은 ‘같은 요청을 다시 보내더라도 결과가 두 번 만들어지지 않도록 하는 설계’다.

예를 들어 세 청크로 나누어 고객 30명에게 메일을 보냈다고 하자. 21번째 고객에서 응답이 끊겼다면 ‘21~30번을 다시 보내자’도 위험할 수 있다. 21번째 메일이 실제로 발송됐는지 확인해야 한다. 청크가 작아도 각 청크의 부작용과 재개 지점이 기록되지 않으면 안전한 복구가 어렵다.

오류 피드백: “다시 해”를 실행 가능한 수정으로 바꾸기#

AI가 도구에서 오류를 받았을 때 실패했습니다 한 줄만 남으면 다음 행동을 판단하기 어렵다. 오류 피드백 보강(error enrichment)은 오류를 꾸미는 일이 아니라, 원본 오류에 목표·입력·환경·관찰 결과를 붙여 다음 판단에 필요한 정보를 만드는 일이다.

다음 네 문장을 비교해 보자.

“문제 생김. 다시 해.”

“파일을 못 읽음.”

“FileNotFoundError가 발생함. 요청 경로는 data/june.csv.”

“6월 집계에 필요한 data/june.csv를 열려다 FileNotFoundError가 발생했다. 현재 파일 목록에는 data/june_2026.csv가 있지만 같은 자료인지 아직 확인하지 않았다. 파일명과 기간을 검증한 후 다시 실행한다.”

마지막 문장은 실패를 숨기지 않고 확인된 사실과 가능한 해석을 분리한다. 비슷한 파일이 있다는 이유만으로 다른 파일을 덮어쓰거나 엉뚱한 자료를 집계하지 않는다.

좋은 오류 피드백의 구성#

구성	담아야 할 정보	피해야 할 것
하려던 일	어느 작업의 어떤 단계인가	모든 과정을 장황하게 반복
원본 오류	오류 코드·메시지·호출 ID 등	원본 메시지 지우고 AI 추측만 남기기
관련 맥락	입력 경로·자료 버전·실행 환경	비밀번호·접근 토큰 노출
사실과 가설	실제 확인한 것 / 아직 확인할 것	근거 없는 원인 확률 숫자
다음 행동	점검 순서, 안전한 수정, 재실행 범위	무조건 권한 상승·패키지 설치·무한 재시도
한도	남은 시도 횟수와 판단 시점	실패할 때마다 횟수 초기화

대표 오류 일곱 가지: 원인을 좁히는 질문#

오류	의미	바로 확인할 것	다음 행동의 예
`ModuleNotFoundError`	현재 실행 환경에서 모듈을 못 찾음	실제 Python 환경, 의존성 파일, 다른 환경에 설치됐는지	승인된 의존성만 설치하거나 대체 도구 선택
`FileNotFoundError`	지정한 경로에 파일이 없음	경로·확장자·실제 목록	올바른 파일인지 확인 후 경로 수정
`PermissionError`	해당 자원 접근이 허용되지 않음	접근 권한과 작업 범위	권한 승인 요청 또는 허용된 경로 사용
HTTP 429	호출량 제한	응답 헤더, 남은 한도, 재시도 가능 여부	안내된 대기 후 유한한 재시도
HTTP 400	요청 값이 잘못됐을 가능성	필수 매개변수와 규격	같은 요청을 반복하지 말고 입력 수정
JSON 파싱 오류	받은 내용이 기대한 JSON이 아님	빈 응답·HTML 오류 페이지·인코딩·원본 상태	원본 형식을 확인하고 파서 선택 수정
시간 초과	응답 시간이 한도를 넘음	서비스 상태, 입력 크기, 이미 실행됐는지	읽기 작업은 분할 검토, 쓰기는 처리 여부 우선 확인

오류 유형만으로 원인을 단정하지 않는다. ModuleNotFoundError도 ‘패키지를 설치하면 끝’이 아니라 다른 가상 환경에서 실행했기 때문일 수 있다. HTTP 500은 서버 오류 신호지만 같은 요청을 무한히 반복하면 상대 서비스의 부하를 키울 수 있다.

실행 가능한 피드백 예제: 배포 중 데이터베이스 변경 실패#

가상의 배포 로그에 다음 한 줄이 있었다고 해 보자.

Migration failed: column "user_email" already exists

“이미 있으니 이 변경을 건너뛰어”는 위험한 결론이다. 실제 스키마와 마이그레이션 기록이 어긋났을 수도 있고, 절반만 실행된 변경일 수도 있다. 사람이 검토하기 좋은 피드백은 다음과 같다.

목표: 스테이징 환경의 스키마 변경 42 적용
원본 오류: column "user_email" already exists
확인된 사실: 변경 실행 중 중단됨. 해당 열의 존재가 오류 메시지로 보고됨.
미확인: 열의 타입·제약 조건, 변경 이력에 성공으로 기록됐는지, 부분 변경 여부
먼저 할 일: 스키마와 변경 이력을 읽기 전용으로 조회
자동 변경 금지: 열 삭제, 이력 강제 수정, 재배포
상태: HUMAN_REVIEW — DBA 또는 배포 담당자에게 조회 결과 전달

실제로 안전한 수리 방법은 데이터베이스 종류와 마이그레이션 방식에 따라 달라진다. 피드백은 조사 순서와 사람의 결정 지점을 선명하게 해 주어야 한다.

재시도는 실패의 종류에 따라 다르게 한다#

재시도는 행동의 하나일 뿐, 모든 오류의 기본 답은 아니다. 특히 프롬프트에 “최대 세 번 다시 해”라고 적었다고 해서 실행 환경이 그 횟수를 반드시 지키는 것은 아니다. 시도 횟수·시간·예산·권한은 AI를 실행하는 프로그램이나 운영 정책에서 추적해야 한다.

실패 종류	같은 입력 재시도	먼저 해야 할 일
일시적 통신 문제	한도 안에서 가능	응답 상태와 연결 상태 확인
호출량 제한	안내된 시간 이후 가능	대기 시간과 전체 호출량 확인
잘못된 파라미터	그대로 반복해도 소용없음	입력 값 수정
자료 부재	그대로 반복해도 소용없음	입력 자료 요청·범위 변경
권한 부족	임의 우회 금지	정당한 승인이나 허용 경로 확인
외부 쓰기의 시간 초과	그대로 반복하면 중복 가능	이미 처리됐는지 조회
품질 검증 실패	구체적 수정이 있을 때 가능	어떤 기준을 왜 못 넘었는지 기록

서버가 일시적으로 바쁠 때는 점차 대기 시간을 늘리고 재시도 간격에 변동을 주는 방식을 사용할 수 있다. 요청 제한을 받은 서비스가 대기 시간을 알려 주면 해당 안내를 우선 확인한다. 재시도 한도와 대기 시간은 제품·계약·업무 목표에 맞게 정한다. ‘무조건 3회’는 원리가 아니다.

시도 횟수보다 중요한 네 가지 한도#

반복 한도: 같은 청크나 같은 오류를 몇 번까지 수정할 것인가?
시간 한도: 한 번의 도구 호출과 전체 작업은 각각 언제까지 기다릴 수 있는가?
비용 한도: 모델 호출·외부 API·데이터 처리 비용이 어디까지 허용되는가?
영향·승인 한도: 읽기, 초안 작성, 고객 발송, 결제 중 어디까지 자율적으로 실행할 수 있는가?

한 청크가 성공했다고 전체 시간과 비용 한도를 초기화하지 않는다. 재시도를 쌓아 작업이 무한히 늘어나는 것을 막기 위해 청크별·전체 한도를 함께 기록한다. 특정 오류에 대한 2회 재시도는 사례의 예시 설정일 뿐 정답이 아니다.

사례로 따라가기: 문서 조항 추출 루프를 끝까지 설계#

가상의 업무: 공급계약서 10건에서 계약 기간·지급 시점·해지 조건·손해배상 한도를 표로 정리한다. AI가 원문에 없는 내용을 작성하면 곤란하므로, ‘확인됨/없음/모호함’을 구분한다. 법적 해석과 최종 사용은 담당자가 검토한다.

1단계: 완료 기준과 자율 범위#

범위: 계약서 10건, 요청된 4항목
완료: 10건 모두에 각 항목의 상태를 기록하고,
      '확인됨' 항목에는 원문 위치를 연결한다.
정확성: 무작위 표본과 '모호함'으로 표시한 조항을 사람이 검토한다.
허용: 문서 읽기, 표 초안 작성, 누락·충돌 표시
금지: 문서 원본 수정, 계약 당사자 통지, 법적 효력 단정

2단계: 청크 경계#

문서 한 건을 독립 청크로 다룬다. 각 청크에는 문서 ID, 원본 버전, 추출한 네 항목과 원문 위치를 함께 저장한다. 10건 중 8건을 확인하고 9번째 문서가 암호화돼 열리지 않는다면 1~8번 결과를 버리지 않는다. 다만 ‘10건 모두 분석’이라는 전체 완료 기준은 아직 통과하지 못했다고 표시한다.

3단계: 가상 실행 기록#

문서 C-09
ACT       파일 열기 시도
OBSERVE   파일 열기 실패; 암호가 필요한 문서로 표시됨
VERIFY    문서 한 건의 네 항목 추출 기준 미달
NEXT      승인된 접근 경로 확인 또는 문서 제공자에게 열람 가능한 버전 요청
STATE     HUMAN_REVIEW

문서 C-10
ACT       네 항목과 조항 위치 추출
OBSERVE   기간·지급·해지 조항 확인; 손해배상 한도는 제12조와 제15조가 다르게 보임
VERIFY    세 항목 확인, 한 항목 모호함. 서로 다른 조항 위치 두 곳 기록
NEXT      수치 하나를 임의 확정하지 않고 담당자에게 충돌 전달
STATE     HUMAN_REVIEW

4단계: 사람에게 넘기는 결과의 모양#

“C-09와 C-10을 확인해 주세요”라고만 보내면 사람은 처음부터 다시 조사해야 한다. 다음처럼 누락·근거·결정 질문을 함께 전달한다.

대상	지금까지 확인된 것	남은 장애	사람이 결정할 질문
C-09	문서 목록에 존재, 열기 실패	읽기 권한 또는 암호 필요	열람 가능한 파일을 제공할 수 있는가?
C-10	네 항목 중 세 항목과 원문 위치 확보	한도 관련 제12·15조 표현 충돌	두 조항의 적용 관계를 어떻게 판단할 것인가?

이 상태는 실패를 감춘 완료도, 계속 클릭하는 무한 루프도 아니다. 검토할 사람에게 가장 적은 재작업으로 넘길 수 있는 상태다. 사람 판단을 받은 뒤 해당 문서 청크만 다시 검증하고 전체 표의 빠진 행을 확인한다.

사례로 따라가기: 보고서 수정 루프가 같은 문제를 되풀이할 때#

이번에는 가상의 경영 보고서다. 초안의 8쪽에는 ‘6월 총매출 2,100만 원’이라고 적혀 있는데, 원본 재계산 결과는 2,010만 원이다. AI에게 “수정해”라고 말했더니 8쪽 숫자를 바꾸지만 요약 표에는 2,100만 원이 남았다.

시도	발견된 사실	다음 행동
첫 검증	본문 8쪽 2,100만 원과 원본 2,010만 원 불일치	원본 집계식과 누락·중복 행 확인
첫 수정 뒤	8쪽은 2,010만 원, 요약 표는 2,100만 원	같은 지표가 나오는 위치 목록을 만들고 표·본문·차트 대조
두 번째 수정 뒤	전체 수치 일치, 차트 축의 통화 단위가 다름	축 단위 수정 후 출력 이미지 확인
최종 검증	요청한 필수 절과 원본 대조 통과	결과와 검증 기록 제출

이 예에서는 매번 다른 결함을 찾아 수정했다. 반대로 AI가 두 번 연속 같은 합계 오류를 고치지 못한다면, ‘한 번 더’가 아니라 원본 데이터·집계 규칙·작업 도구 중 무엇이 잘못됐는지 진단해야 한다. 검증 기준을 줄여서 통과 처리해서는 안 된다.

점수보다 결함의 성격을 보자#

“보고서 90점”이라는 평가는 편하지만, 어떤 문제인지 알려 주지 않는다. 투자 결정에 쓰일 보고서의 총매출이 틀렸다면 문체 점수가 높아도 그대로 제출할 수 없다. 필수 수치 오류는 차단 조건, 표현상의 작은 어색함은 수정 권고로 분리한다. 매 작업에서 중대한 항목과 허용 가능한 미완성 항목을 정해야 한다.

사례로 따라가기: 시간 초과된 외부 행동#

AI가 게시 도구를 사용해 회사 공식 계정에 공지문을 올렸다고 가정하자. 도구는 시간 초과를 반환한다. 여기서 관찰할 수 있는 것은 **‘응답을 받지 못했다’**는 사실이지 **‘게시되지 않았다’**는 사실이 아니다.

ACT       승인된 공지문 게시 요청
OBSERVE   30초 뒤 응답 시간 초과. 게시 성공·실패 상태는 불명
VERIFY    ‘게시 여부 확인’ 기준 미달
NEXT      게시 목록을 읽기 전용으로 조회하고 동일한 공지의 존재 여부 확인

게시됐다면 SUCCESS와 게시물 ID를 기록한다. 없다는 것이 확실하고 재실행이 허용된다면, 중복 방지 절차를 확인한 뒤 다시 게시한다. 확인할 방법이 없다면 HUMAN_REVIEW로 넘긴다. 시간 초과를 곧 실패로 간주한 자동 재시도는 같은 공지를 두 번 올릴 수 있다.

된장찌개로 이해하는 ‘수정하고 멈추는’ 감각#

기술 용어가 낯설다면 된장찌개를 떠올려 보자. 냉장고에 두부·버섯·양파가 있고, 두 사람이 함께 먹을 찌개를 만든다고 가정한다. 이 사례의 AI는 실제 주방을 조작하지 않는다. 사람의 요리 과정을 빌려 루프를 설명하는 비유다.

단계	주방에서 하는 일	AI 업무의 대응
Plan	있는 재료를 확인하고 순서·맛 기준을 정함	입력과 완료 기준 확인
Act	재료를 손질하고 끓임	파일 읽기·계산·문서 작성
Observe	국물의 농도와 맛을 확인함	실제 반환값과 오류·누락 기록
Verify	먹을 사람의 기준에 비춰 적절한지 판정	사용자가 요구한 조건에 대조

한 숟갈 맛봤더니 싱겁다고 하자. “처음부터 다시 만들자”보다 간을 조금 조절하고 다시 맛보는 것이 낫다. 이것이 수정 범위를 좁힌 청킹이다. 그런데 집에 된장이 떨어졌다면 같은 조정을 계속 시도해도 해결되지 않는다. 재료를 새로 구하거나 다른 메뉴를 선택해야 한다. 이것이 재계획 또는 사람 판단이다. 충분히 맞는 맛인데 계속 끓이다 재료를 무르게 만들면 과잉 반복이다. 완료 기준을 만족했으면 멈춰야 한다.

원문의 상세 레시피처럼 국물 색을 특정 RGB 값으로 정하거나 모든 요리에 동일한 조리 시간·맛보기 횟수를 강제할 필요는 없다. 색은 된장 종류와 조명에 따라 달라진다. 요리 비유의 핵심은 ‘몇 번 끓였는가’보다 관찰을 바탕으로 필요한 부분만 고치고 적절한 순간에 종료한다는 점이다.

초급·중급·고급의 차이는 요리 종류가 아니라 의존성이다#

비유	루프의 구조	배울 점
한 냄비 요리	준비 → 조리 → 간 확인	작은 작업에도 관찰과 종료 기준이 있다
된장찌개	육수와 손질 일부를 함께 진행, 간은 뒤에 조정	독립 작업은 병렬 가능, 조정은 부분 재실행
여러 코스의 식사	각 요리의 준비 시점과 실제 제공 순서를 맞춤	청크가 개별 통과해도 전체 경험 검증이 필요

디저트를 먼저 완성하고 메인 요리가 늦게 준비됐다면, 각각의 요리가 한 번씩 ‘성공’했다고 전체 식사가 성공한 것은 아니다. 문서도 각 절은 좋아 보여도 요약과 표의 숫자가 다르면 최종 검증에서 멈춰야 한다.

종료 정책 명세: 프롬프트 밖에도 남겨야 할 운영 규칙#

아래 YAML은 한 팀이 문서 조항 추출 업무에 적용할 수 있는 설계 예시다. 숫자는 제품 권장값이 아니라 예시 한도다. 프롬프트에 적어 두는 데 그치지 않고, 실제 실행 프로그램이 시도 횟수·시간·비용을 기록하고 강제해야 한다.

task: contract_clause_extraction
scope:
  documents: 10
  required_fields:
    - term
    - payment_date
    - termination
    - liability_limit

done:
  each_document_has_field_status: true
  each_confirmed_value_has_source_location: true
  ambiguous_values_are_flagged: true

limits:
  total_attempts_per_document: 2
  total_run_minutes: 40
  max_external_cost: "팀에서 승인한 한도"

retry:
  transient_network_error: true
  missing_file_without_new_input: false
  permission_denied_without_approval: false

human_review:
  on_ambiguous_clause: true
  on_missing_source_document: true
  on_unapproved_external_write: true

halt:
  on_cost_limit_reached: true
  on_total_time_limit_reached: true
  on_repeated_identical_failure: true

handoff:
  include_original_error: true
  include_document_id_and_source_version: true
  include_unresolved_questions: true

실제 업무에서는 다음처럼 판단 순서까지 정해 두면 충돌을 줄일 수 있다.

개인정보 유출, 권한 위반, 승인되지 않은 외부 행동처럼 즉시 멈춰야 할 사유가 있는가?
필수 완료 기준에 대한 증거가 전부 있는가? 있다면 성공으로 끝낸다.
한도가 남아 있고, 고칠 수 있는 실패 원인이 확인됐는가? 그렇다면 필요한 청크만 재시도한다.
결과 해석이 모호하거나 새로운 입력이 필요한가? 사람에게 질문과 증거를 전달한다.
시간·비용·반복 한도에 도달했는가? 중단 이유와 확보한 결과를 기록한다.

프롬프트 안에서만 ‘이제 그만하세요’라고 말하는 것은 운영 정책을 대신하지 못한다. 도구 권한, 쓰기 승인, 비용 한도와 반복 제한은 모델 바깥의 실행 환경에서도 확인해야 한다.

실제 기록은 이렇게 남긴다#

task_id: example-contract-C10
document_version: v3
attempt: 2
plan: "손해배상 한도 조항의 적용 범위를 확인"
act: "원문 제12조와 제15조 읽기"
observe:
  status: "두 조항의 적용 관계가 불명확"
  evidence: ["제12조 위치", "제15조 위치"]
verify:
  result: HUMAN_REVIEW
  failed_requirement: "한도 해석 확정"
  reason: "근거 충돌을 자동으로 해결할 수 없음"
next:
  owner: "계약 담당자"
  question: "제12조와 제15조의 우선 적용 관계는 무엇인가?"

이 기록은 ‘AI가 자신 있게 말했다’는 인상보다 강한 자료다. 어떤 문서 버전으로 작업했고, 몇 번 시도했으며, 무엇이 미결인지 그대로 남는다. 민감한 원문이나 비밀 키를 로그에 복사하기보다 접근 통제된 저장 위치와 식별자만 기록한다.

직접 해보기: 내 업무의 종료 정책을 30분 만에 작성#

종료 정책을 처음 만든다면 복잡한 자동화부터 시작하지 말자. 작은 읽기 전용 업무에 대해 아래 질문을 순서대로 적어 보자.

실습 1: 결과물과 실패 유형 정하기#

업무를 “지난달 고객 문의에서 자주 나온 문제 3개 뽑기”로 정한다.

입력: 지난달 고객 문의 CSV
결과물: 문제 유형 3개, 각 유형의 건수, 원문 예시 위치
미확인 상태: 분류가 모호한 문의는 별도 목록
완료 증거: 분석 대상 건수 + 세 유형의 근거 + 미분류 건수

이제 “CSV가 없다”, “열이 빠졌다”, “분류 기준이 애매하다”, “분석 도구가 일시적으로 실패했다”를 나눠 적는다. 넷 모두 같은 재시도 규칙을 적용할 수 없다.

실습 2: 작은 분할과 복구 지점 정하기#

파일 확인 → 열·기간 점검 → 문의 유형 분류 → 빈칸 검토 → 보고서 초안 → 원문 대조로 나눈다. 각 작업에서 성공을 확인할 수 있는 증거를 적는다. 파일이 두 개라면 자료별로 분리해 어느 파일이 빠졌는지도 기록한다.

실습 3: 상태 전이 직접 써 보기#

유효한 CSV + 필요한 열 존재 → 다음 청크로 진행
일시적 파일 접근 오류 + 한도 남음 → 원인 확인 후 재시도
분류 기준을 바꿔야 함 → Plan으로 돌아가 기준 갱신 요청
고객 문의의 의미가 둘 이상으로 해석됨 → HUMAN_REVIEW
허용되지 않은 외부 게시 시도 → HALT
필수 기준 통과 + 근거 대조 완료 → SUCCESS

완성한 뒤 옆 사람에게 “이 규칙만 보고 같은 결정을 할 수 있겠어?”라고 물어보자. 사람이 해석할 때마다 종료 상태가 달라진다면 기준을 더 구체화해야 한다.

바로 사용할 수 있는 AI 요청 템플릿#

아래는 모델에게 맡길 판단의 형식이다. 실제 재시도 횟수와 권한을 애플리케이션이 따로 관리한다는 전제로 쓴다.

목표: [결과물과 사용 목적]
입력 자료: [파일·기간·버전]
실행 가능한 행동: [읽기, 계산, 초안 작성 등]
사람 승인 후에만 할 행동: [게시, 발송, 결제, 배포 등]

완료 기준:
1. [필수 범위와 항목]
2. [원본과 대조할 수치·출처]
3. [사용할 파일 형식·전달 방식]

한 작업을 입력·출력·검증 기준이 있는 단위로 나누세요.
도구를 실행한 뒤에는 원본 결과와 관찰된 사실을 적으세요.
오류가 나면 목표, 실행 입력, 원본 오류, 확인된 사실과 가설,
안전한 다음 행동을 구분하세요.
같은 입력을 이유 없이 되풀이하지 마세요.
모호한 내용은 지어내지 말고 원문 위치와 함께 보류하세요.

각 단계의 마지막에 다음 가운데 하나를 고르세요.
SUCCESS: 완료 기준 통과, 근거 기록.
RETRY: 고칠 수 있는 원인과 남은 시도 한도 기록.
REPLAN: 입력·범위·순서를 변경해야 하는 이유 기록.
HUMAN_REVIEW: 사람이 결정할 질문과 관련 자료 기록.
HALT: 즉시 멈춘 이유와 현재까지의 산출물 기록.

자주 묻는 질문#

AI가 스스로 품질을 평가하면 종료 기준도 스스로 정할 수 있나?#

AI가 초안 평가를 도울 수는 있다. 다만 사용자가 필요한 결과와 권한 범위는 작업 시작 전에 정해야 한다. 모델이 자기 결과에 맞춰 필수 기준을 낮추면 통제할 수 없다. 자동 계산이 가능한 항목은 도구로 검사하고, 애매한 해석은 사람에게 넘긴다.

모든 기준을 예·아니오로 만들 수 있나?#

수치 합계나 파일 존재처럼 명확한 항목은 가능하다. “설명이 이해하기 쉬운가”처럼 독자의 맥락이 필요한 항목은 간단한 점수 하나보다 독자 질문과 예시, 담당자 확인을 두는 편이 낫다. 판정 방법이 명확해야 한다는 뜻이지 모든 품질을 임의의 숫자로 바꾸라는 뜻은 아니다.

재시도는 최대 세 번이면 충분한가?#

일률적인 정답은 없다. 읽기 전용 API의 일시적 장애와 결제 요청의 응답 시간 초과는 재시도 위험이 다르다. 한도는 서비스 규칙, 비용, 외부 영향, 사용자 기대를 보고 정한다. 같은 오류가 되풀이되는데 원인이 그대로라면 한 번 더 하는 것보다 멈추고 진단하는 편이 낫다.

청크를 잘게 쪼개면 항상 비용이 줄어드나?#

아니다. 너무 잘게 쪼개면 도구 호출과 통합 검증이 늘어난다. 복구가 쉬운 단위와 관리 비용 사이에서 정한다. 파일 한 행마다 AI를 호출하는 것보다, 날짜별로 계산하고 누락 건만 별도 처리하는 편이 나은 경우도 있다.

사람이 검토해야 하면 AI 루프는 실패인가?#

아니다. 모호한 계약 조항이나 승인되지 않은 외부 발송을 정확히 보류했다면, 운영 규칙을 지킨 결과다. 사람이 받는 질문과 증거까지 준비했다면 작업은 다음 책임자에게 제대로 인계된 것이다.

오류 피드백에 원인을 세 개씩 꼭 적어야 하나?#

아니다. 확인된 원인이 하나라면 하나를 적으면 된다. 중요한 것은 원인 후보의 개수가 아니라 확인된 사실과 추정을 섞지 않는 것이다. 근거 없는 원인별 확률을 숫자로 붙이지 않는다.

정리: 완결은 ‘성공’과 ‘멈춤’을 모두 설계하는 일#

AI 루프는 네 단계를 계속 돌리기만 해서는 완성되지 않는다. 완료 기준으로 결과를 판정하고, 작업 분할로 실패 범위를 줄이며, 오류 피드백으로 고칠 수 있는 문제와 사람이 판단해야 할 문제를 나눈다. 마지막으로 반복·시간·비용·승인 한도를 실행 환경에서 관리해 성공, 재시도, 재계획, 사람 검토, 중단 중 하나로 상태를 닫는다.

이 글을 읽고 한 가지를 바꾼다면, 다음 업무에서 “최대 몇 번 다시 할까?”보다 먼저 **“무엇을 확인해야 끝났다고 말할 수 있는가?”**를 적어 보자. 그 기준이 있어야 AI는 성공을 선언할 수도, 정당한 이유로 멈출 수도 있다.