AI 루프 엔지니어링의 핵심:AI가 끝까지 일하게 만드는 방법, PAOV란? 계획·실행·관찰·검증으로 업무 완성하기

AI 루프 엔지니어링에서 PAOV가 중요한 이유: AI가 끝까지 일하게 만드는 방법#

“지난달 매출 보고서를 만들어 줘”라는 요청에 AI가 그럴듯한 문서를 바로 돌려주었다고 해 보자. 표와 결론까지 갖춰져 있어도 파일을 잘못 읽었거나, 지난달이 아닌 전달 데이터를 분석했거나, 숫자가 맞지 않으면 업무는 끝난 것이 아니다. 반대로 AI가 “매출 CSV를 읽었습니다”라고 보고해도, 그 사실은 파일 접근에 성공했다는 뜻일 뿐 보고서 작성이 완료되었다는 뜻이 아니다.

AI 루프 엔지니어링은 목표를 받은 AI가 행동하고, 결과를 확인하고, 부족한 부분을 고쳐, 실제 완료 기준에 도달하도록 작업 흐름을 설계하는 일이다. 이 글에서는 그 흐름을 Plan → Act → Observe → Verify, 즉 PAOV로 정리한다. PAOV는 이 콘텐츠에서 사용하는 운영 모델이며 업계의 보편적 표준 명칭은 아니다. 도구와 서비스가 달라져도 네 가지 질문은 그대로 쓸 수 있다.

단계	초보자가 던질 질문	그 단계에 남길 증거
Plan, 계획	무엇을 어떤 순서로 할까? 무엇이면 끝난 걸까?	작업 목록, 의존 관계, 완료 기준
Act, 실행	실제로 무슨 도구를 어떤 입력으로 사용했나?	도구 호출, 입력 범위, 실행 기록
Observe, 관찰	실행 결과로 무엇이 돌아왔나?	상태, 건수, 오류, 출력물, 원본과의 차이
Verify, 검증	돌아온 결과가 처음 약속한 기준을 충족하나?	통과·미달 판정, 근거, 수정 또는 승인 결정

여행 일정을 예로 들면, 계획은 “항공편과 숙소를 정하고 전체 예산을 80만 원 이내로 맞춘다”는 작업 설계다. 실행은 항공편을 검색하고 예약 후보를 비교하는 일이다. 관찰은 “검색 결과 세 건 중 저녁 출발은 두 건, 현재 표시된 가격은 각각 얼마”라고 기록하는 일이다. 검증은 “가족 모두 이동 가능한 시간이며, 총액이 예산 안에 들어오는가”를 판정하는 일이다. 검색 결과를 얻었다는 사실만으로 예약까지 끝났다고 말할 수 없으며, 실제 결제는 별도의 승인과 확인이 필요하다.

이 모델은 어떤 AI에 적용되는가#

도구를 쓰는 에이전트는 검색·파일 읽기·코드 실행을 Act에 연결할 수 있다. 도구가 없는 채팅 환경에서도 사람이 자료를 제공하고 AI가 계획·검토·수정 단계를 맡는 사람과 AI의 공동 루프를 설계할 수 있다. 매 단계에서 AI가 자율적으로 판단할 수도 있고, 정해진 순서를 자동화 프로그램이 통제할 수도 있다. 실무에서 중요한 것은 ‘에이전트’라는 호칭보다 행동과 결과를 검증할 수 있는 구조다.

Plan: 큰 목표를 실행 가능한 작업과 완료 기준으로 바꾸기#

계획은 긴 할 일 목록을 쓰는 일이 아니다. 최종 결과물을 정의하고, 그 결과물에 도달하기 위한 다음 행동과 판단 기준을 정하는 일이다. “시장 조사해 줘”보다 “최근 공개된 공식 제품 변경 기록을 세 곳에서 확인해 기능 변경 표를 만들고, 서로 다른 발표 날짜가 나오면 충돌을 표시해 줘”가 실행하기 쉽다.

계획에 먼저 적을 다섯 가지#

목표와 독자: 누가 결과를 쓰며 어떤 결정을 내려야 하는가? 경영진의 투자 판단용 보고서인지, 팀의 주간 회의 자료인지에 따라 필요한 내용이 다르다.
범위: 기간, 대상, 자료의 종류, 제외할 항목은 무엇인가? “지난달”은 실행 날짜와 시간대에 따라 달라지므로 데이터 기준 월을 명시한다.
입력과 도구: 어떤 파일이나 공식 출처가 있고, 무엇에 접근할 수 있는가? 접근이 안 되는 자료를 전제로 계획하지 않는다.
작업 간 순서: 데이터 수집이 끝나야 계산할 수 있다. 반면 독립적인 제품 두 곳의 변경 기록 수집은 함께 진행할 수 있다.
완료 기준(Definition of Done, DoD): 어떤 증거가 있어야 완료라고 할 것인가? “좋은 보고서” 대신 “요청한 4개 항목, 원본과 일치하는 합계, 근거 위치, 검토 상태가 있다”처럼 쓴다.

WBS를 쓰되 필요 이상으로 쪼개지 않기#

WBS(Work Breakdown Structure)는 큰 목표를 결과물과 하위 작업으로 나누는 방식이다. 예컨대 50쪽 경영 보고서는 ‘자료 확인 → 분석 → 작성 → 검증’으로 분리할 수 있다. 하지만 실제 데이터를 열기도 전에 모든 장의 소제목과 작업 시간을 확정하면, 파일 열이 예상과 다를 때 계획 전체를 다시 써야 한다.

수준	매출 보고서 예시	그 수준의 판단
목표	전월 매출 변화를 설명하는 보고서	누구에게 어떤 판단을 돕나?
이정표	데이터 확인, 집계, 해석, 문서화, 검증	어느 결과가 다음 작업의 입력이 되나?
실행 작업	기간 확인, 열 이름 확인, 채널별 합계 계산	다음에 어떤 도구를 쓰고 무엇을 확인하나?

작업을 반드시 10분 또는 15분으로 자를 필요는 없다. 입력·출력·실패 조건이 분명한 단위가 적당하다. 첫 계획은 자세해야 할 부분만 자세히 쓰고, 모르는 부분은 ‘파일 구조를 본 후 세분화’라고 남겨 둔다. 이를 단계적 구체화라고 부를 수 있다.

예제 1: 가족 여행 계획을 작업 루프로 바꾸기#

목표는 ‘제주도 2박 3일 가족 여행 후보 일정’이다. 가상의 조건은 네 명, 총예산 80만 원, 저녁 늦은 도착을 피하는 것이다. 여기서 AI가 당장 확정할 수 있는 것은 후보안이다. 항공·숙소 가격과 운영 시간은 변할 수 있으므로 예약과 결제는 사용자 확인 후 진행한다.

작업	먼저 필요한 것	실행 결과로 기대하는 것	검증 기준
여행 조건 정리	인원·날짜·예산·선호	조건표	빠진 핵심 조건이 없거나 ‘미정’ 표시
이동 후보 찾기	여행 날짜	항공편 후보와 표시 가격	출발·도착 시간, 인원·수하물 조건 확인
숙소 후보 찾기	날짜와 대략적 이동 동선	숙소 후보와 취소 조건	방 인원 수용, 전체 숙박비 확인
일자별 동선 짜기	도착·출발 시각과 숙소 위치	하루별 방문 후보	이동 시간과 영업시간은 확인 전 ‘미확인’
예산·일정 점검	교통·숙소·이동 후보	항목별 예상 총액	합계 80만 원 이하인지, 미확정 금액 표시

이렇게 설계하면 AI가 관광지만 그럴듯하게 나열하고 항공편 도착 시각과 마지막 날 공항 이동을 빠뜨리는 일을 줄일 수 있다. 가격을 조회하지 못했다면 ‘80만 원 안에 든다’고 단정하는 대신, 확인할 항목과 보류된 판단을 남긴다.

예제 2: 공개 자료로 경쟁사 기능 변화 조사#

목표를 ‘세 경쟁사의 최근 제품 기능 변경을 한 장의 비교표로 정리’라고 정했다고 가정하자. Plan에서 완료 기준을 다음처럼 적는다.

비교 대상 세 곳과 조사 기간을 기록한다.
각 기능 변화에는 공식 발표나 제품 변경 기록의 원문 위치를 연결한다.
자료에 날짜 충돌이 있으면 어느 문서의 어떤 날짜가 다른지 적는다.
충돌이 해결되지 않으면 ‘확인 필요’로 남기고 확정된 사실처럼 요약하지 않는다.

이 기준은 뒤의 Verify에 그대로 쓰인다. 계획에 없는 기준을 최종 단계에서 즉흥적으로 만들면, AI는 자기에게 유리한 방향으로 ‘완료’를 선언하기 쉽다.

Plan에서 자주 발생하는 실패#

실패	왜 문제인가	고치는 방법
“보고서 잘 쓰기”만 적음	통과 여부를 판정할 수 없음	필수 절, 수치, 출처, 출력 형식 명시
아직 못 본 데이터의 열을 가정함	뒤의 실행이 허공을 겨냥함	먼저 파일 목록과 헤더를 확인한 후 세부 계획 수정
모든 작업을 동시에 돌림	앞 작업의 결과가 필요한 일을 먼저 시작함	선행 조건을 표시하고 독립 작업만 병렬 처리
계획에 없는 외부 전송을 끼워 넣음	사용자 의도와 권한을 넘어설 수 있음	초안 작성과 실제 전송을 별개 작업으로 구분

Act: AI의 판단을 실제 행동과 기록으로 연결하기#

Act는 ‘하겠습니다’라고 말하는 단계가 아니다. 계획에 정한 한 작업을 허용된 도구로 실행하는 단계다. 결과를 쓰려면 파일을 읽어야 하고, 현재 발표 내용을 확인하려면 출처를 열어야 한다. 도구에 접근할 수 없다면 실행에 성공한 척하지 말고, 필요한 입력을 사용자에게 요청하거나 가능한 범위의 초안을 만든다.

도구 실행을 시작하기 전 확인할 것#

질문	파일 읽기	외부 서비스에 게시하기
목표와 연결되는가?	분석할 입력 확보	검증된 내용을 외부에 전달
입력이 정확한가?	경로, 파일 형식, 읽을 범위	게시 대상 계정, 본문, 예약 시각
접근 권한이 있는가?	해당 경로의 읽기 권한	계정 권한과 승인 상태
실패하면 무엇을 남기나?	경로 오류·인코딩 오류	서비스 오류·중복 게시 가능성
되돌리기 쉬운가?	일반적으로 쉬움	외부 노출 이후 회수가 어려울 수 있음

한 번에 실행할 작업은 결과를 독립적으로 판단할 수 있을 만큼 작아야 한다. 예를 들어 파일을 처음부터 통째로 AI의 맥락에 넣기보다, 헤더와 샘플 행을 보고 구조를 파악한 다음 전체 집계를 실행한다. 데이터가 많으면 원본은 도구로 계산하고, AI에게는 필요한 집계와 예외 행만 전달할 수 있다.

도구 호출은 누가 실제로 실행하나#

도구 사용 기능을 가진 AI가 read_file 같은 호출을 제안할 수 있지만, 실제 파일을 여는 주체는 그 도구를 연결한 실행 환경이다. 실행 환경이 경로·권한·입력을 확인해 도구를 호출하고, 반환된 결과를 AI에게 다시 전달한다. 제품에 따라 형식은 다르지만, 요청 → 도구 실행 → 결과 반환 → 다음 판단이라는 핵심은 같다. 일부 API에서는 tool_use와 tool_result 같은 메시지 블록으로 이를 표현한다.

아래 기록은 특정 업체의 실제 내부 추론이나 운영 로그가 아니라, 흐름을 보여 주는 가상 실행 로그다.

작업: /data/sales.csv에서 6월 매출 집계 준비
PLAN    필요한 열: 날짜, 채널, 주문번호, 금액
ACT     read_file(path="/data/sales.csv", rows=5)
RESULT  status=ok; 헤더=[date, channel, order_id, amount]; 샘플 5행
OBSERVE 열 네 개가 존재한다. amount는 문자열로 읽힌 행이 있다.
VERIFY  ‘전체 집계 준비’ 기준은 미달: 금액 형식 확인이 필요하다.
NEXT    금액 열의 비정상 값 수를 확인한 후 집계 계획을 갱신한다.

문자열로 읽힌 금액을 무턱대고 숫자로 바꾸면 12,000처럼 쉼표가 있는 값이 실패하거나 누락될 수 있다. 루프는 이를 발견한 뒤 자료 형식을 확인하고, 유효한 변환 규칙을 정한 다음 계속한다.

순서대로 실행할 작업과 함께 실행할 작업#

“CSV 열 확인 → 집계 코드 작성 → 집계 결과 검토”는 의존 관계가 있어 순서대로 해야 한다. 반면 서로 다른 공식 제품 변경 기록 세 곳을 읽는 일은 독립적이라면 함께 할 수 있다. 병렬 실행은 호출 횟수 제한과 결과 취합 방식을 고려해야 한다. 독립성 확인 없이 무조건 동시에 호출한다고 빠르거나 정확해지는 것은 아니다.

실패한 실행을 어떻게 다룰까#

실행 결과	해석	다음 행동
파일을 찾을 수 없음	경로, 파일명, 전달 여부를 확인해야 함	경로 목록을 확인하고 없으면 자료 요청
접근 거부	권한 문제	권한을 우회하지 말고 접근 가능한 경로 또는 승인 요청
HTTP 429	서비스 요청 제한	응답의 재시도 안내를 확인하고 유한한 횟수로 재시도
시간 초과	데이터 크기·서비스 상태·처리 범위 문제 가능	범위를 줄이거나 상태를 확인; 외부 쓰기였다면 실제 완료 여부부터 확인
요청 형식 오류	같은 입력으로 반복하면 대개 개선되지 않음	입력과 API 규격 수정

특히 결제·게시·메일 전송 같은 중복되면 문제가 되는 행동은 응답이 시간 초과되었다는 이유만으로 즉시 다시 실행하지 않는다. 이미 처리됐는지 먼저 조회하거나 중복 방지 수단을 사용한다. 재시도 횟수와 중단 기준을 정해 무한 루프를 막는다.

Observe: 실행 결과를 ‘됐어요’가 아닌 증거로 읽기#

도구가 결과를 반환했다고 해서 바로 다음 작업으로 넘어가면 안 된다. Observe는 반환된 결과에서 상태와 수치, 누락과 충돌을 읽어 다음 판단의 근거로 바꾸는 단계다.

3C: Count, Context, Compare#

요소	질문	부실한 기록	쓸 수 있는 관찰
Count, 수량	몇 건이 들어오고 처리됐나?	“데이터를 읽음”	“요청 범위 6월, 원본 1,000행, 유효 980행”
Context, 맥락	왜 빠졌고 어떤 조건인가?	“20건 오류”	“금액이 비어 있는 12행, 날짜가 범위 밖인 8행”
Compare, 비교	예상과 얼마나 차이가 나나?	“대체로 정상”	“완료 기준은 1,000행 전체 분류; 20행 미처리로 미달”

이 숫자는 이해를 위한 가상 자료다. 12행과 8행이 서로 겹치지 않는다고 확인했다는 전제에서만 1,000 - 12 - 8 = 980이라고 계산할 수 있다. 같은 행이 두 사유에 동시에 해당할 수 있다면, 중복 여부를 확인한 뒤 유효 행 수를 계산해야 한다. 관찰은 예쁜 문장을 만드는 일이 아니라 무엇을 실제로 셌는지 드러내는 일이다.

좋은 관찰은 결과의 층위를 구별한다#

실행 상태: 프로세스 종료 코드, API 응답 코드, 시간 초과 여부. exit=0은 프로그램이 정상 종료했다는 신호지만 보고서의 숫자가 맞다는 보증은 아니다.
형식과 양: 파일이 만들어졌는지, 열이 있는지, PDF가 열리는지, 응답이 빈 문자열인지 확인한다. HTTP 202는 작업 접수일 수 있어 최종 완료 상태를 별도로 확인해야 할 수 있다.
내용과 범위: 결과가 요청 기간과 대상에 해당하는지, 필요한 항목이 모두 있는지 확인한다.
출처와 의미: AI가 적은 수치나 설명이 원본 자료와 일치하는지 확인한다. 출처가 없다는 사실 자체도 관찰값이다.

stderr가 비어 있어도 업무 결과가 틀릴 수 있다. 반대로 stderr에 경고가 있어도 출력물이 생길 수 있다. 두 경우 모두 실제 결과와 기준을 따로 확인해야 한다.

예제: 생성된 보고서 파일이 있다고 해서 끝난 것은 아니다#

ACT      report_generator 실행
RAW      exit=0; output="/out/june_report.pdf"; stderr=""
OBSERVE  파일이 존재하며 PDF로 열림. 표 3개, 6월 데이터 980행 반영.
COMPARE  입력 1,000행. 미반영 20행의 원인과 보고서 반영 방침 미확정.
NEXT     제외 사유를 검토하고, 포함·제외 기준을 보고서에 밝힌다.

이 단계에서 “정상 종료했으니 완료”라고 판정하면 빠진 20행이 보고서에서 사라진다. 관찰은 결론을 서두르지 않고 판정할 만한 증거를 수집하는 과정이다.

경쟁사 조사에서는 ‘출처 충돌’도 관찰한다#

조사 대상: A·B·C 제품의 공식 변경 기록
Count: 공식 자료 3건 확보
Context: A와 B는 날짜가 일치; C의 안내 페이지와 변경 기록의 출시일이 다름
Compare: 완료 기준 ‘기능·발표일·출처의 확인’ 가운데 C의 발표일은 미확인
Observation: “세 제품 조사가 끝남”이 아니라 “두 제품 확인, 한 제품 날짜 충돌”

이 경우 다음 행동은 확인 가능한 공식 문서를 더 읽거나, 출처 두 개와 충돌 내용을 사용자에게 제시하는 것이다. 출처가 충돌할 때 AI의 자신 있는 어조는 해결책이 아니다.

Verify: 처음 정한 완료 기준에 비추어 판정하기#

Observe가 “무슨 일이 일어났나?”를 묻는다면, Verify는 **“그 결과로 사용자가 요청한 일을 끝냈나?”**를 묻는다. 관찰에서 ‘파일이 만들어졌다’고 확인했더라도, 검증에서는 ‘요청한 기간과 계산 기준에 맞는 보고서인가’를 따진다.

검증은 체크리스트와 판정으로 구성한다#

검증 축	질문	확인할 증거
완결성	요청한 대상과 항목이 모두 있는가?	요청 목록과 결과물의 대응표
정확성	계산과 사실이 원본과 일치하는가?	원본 행, 재계산, 공식 자료
범위	기간·단위·조건을 지켰는가?	날짜 필터, 통화·단위, 제외 기준
일관성	표·본문·요약의 수치가 같은가?	같은 지표의 위치별 대조
형식	사용자가 바로 쓸 수 있는가?	파일 열기, 필수 표·제목·링크
권한	실행을 승인받아야 하는 행동이 남았는가?	게시·결제·전송 승인 여부

이 중 일부는 코드로 정확히 검사할 수 있다. 예를 들어 합계는 원본에서 다시 계산하고, 필수 열은 열 이름으로 확인한다. 문서의 의미가 자료와 맞는지는 AI의 검토를 보조로 쓸 수 있지만, AI가 스스로 ‘맞다’고 말한 것만으로 원본 대조를 대체하지 않는다. 정확도가 중요하거나 대외적으로 공개될 결과물은 사람이 표본이나 원문을 직접 검토한다.

결과를 세 가지로 판정하기#

통과: 필수 기준을 모두 충족하고, 사용자가 요청한 최종 행동까지 허용 범위에서 완료했다.
부분 미달: 결과물은 쓸 만하지만 특정 항목이 빠졌다. 빠진 위치, 원인, 수정 조건을 기록하고 해당 부분을 보완한다.
중대 미달 또는 보류: 원본 수치에 접근할 수 없거나 핵심 출처가 충돌하거나 승인이 필요한 행동이 남았다. 근거 없이 계속 실행하지 않고 사람에게 판단을 요청한다.

점수 하나로 모든 실패를 덮지 않는다. 예를 들어 보고서 문체가 훌륭해도 매출 합계가 틀리면 ‘전반적으로 90점’이라는 이유로 통과시키기 어렵다. 기준마다 필수 여부와 실패 시 조치를 먼저 정해야 한다.

처음부터 끝까지: 매출 보고서를 PAOV로 만드는 전체 예제#

다음 표와 금액은 교육용 가상 자료다. ‘6월 채널별 매출 보고서를 작성해 지난달 실적을 비교한다’는 요청을 세부 단계로 풀어 보자.

가상의 입력과 요청#

month,channel,orders,revenue,ad_spend
2026-05,검색광고,100,1000000,250000
2026-05,이메일,50,500000,50000
2026-06,검색광고,120,1440000,300000
2026-06,이메일,60,660000,60000

사용자 요청: “6월 매출과 5월 대비 변화를 채널별로 보여 주고, 광고비 대비 매출도 계산해 줘. CSV에 있는 값만 근거로 삼아.”

첫 번째 루프: 자료가 분석 가능한지 확인#

Plan — 5월과 6월의 모든 채널 행을 확인한다. 필요한 열은 month, channel, orders, revenue, ad_spend다. 금액이 숫자로 해석되지 않으면 집계를 보류한다.

Act — CSV를 읽고 열과 각 월의 행 수를 검사한다.

Observe — 4행, 월별 2행이며 금액 열은 모두 숫자다. 요청한 두 달의 데이터가 있다.

Verify — ‘집계에 필요한 열과 기간이 존재한다’는 첫 기준을 통과했다. 다음 작업인 집계로 이동한다.

두 번째 루프: 숫자를 계산하고 대조#

Plan — 월별 매출과 광고비 합계, 전월 대비 매출 변화율, 채널별 매출 대비 광고비 지표를 정의한다. ‘광고비 대비 매출’을 이 예제에서는 매출 ÷ 광고비로 계산하며, 광고비가 0인 행은 별도로 처리한다. 이 수치는 엄밀한 증분 효과나 이익을 뜻하지 않는다.

Act — 합계와 비율을 계산한다.

항목	5월	6월	계산 근거
검색광고 매출	1,000,000원	1,440,000원	원본 `revenue`
이메일 매출	500,000원	660,000원	원본 `revenue`
전체 매출	1,500,000원	2,100,000원	두 채널 합계
전체 광고비	300,000원	360,000원	두 채널 `ad_spend` 합계
전체 매출/광고비	5.0배	약 5.83배	월 전체 매출 ÷ 월 전체 광고비

6월 전체 매출 증가율은 (2,100,000 - 1,500,000) ÷ 1,500,000 × 100 = 40%다. 6월 채널별 매출/광고비는 검색광고 1,440,000 ÷ 300,000 = 4.8배, 이메일 660,000 ÷ 60,000 = 11배다. 채널별 비율을 더해서 전체 비율을 만들지 않는다. 전체는 매출과 광고비를 각각 합산한 뒤 나눠야 한다.

Observe — 월별 합계는 표의 각 채널 값을 더한 결과와 일치한다. 그러나 6월 이메일의 높은 비율이 이메일 때문에 발생한 추가 매출을 증명하지는 않는다. 원본에는 귀속 기준과 구매자 중복 정보가 없다.

Verify — ‘CSV 기반 계산’은 통과한다. ‘어느 채널이 매출 상승의 원인인지 입증’은 입력 자료만으로 판단할 수 없다. 보고서에는 계산값과 이 한계를 함께 쓴다.

세 번째 루프: 문서 초안의 결함을 좁혀 수정#

가상의 첫 초안이 “전체 매출/광고비는 검색 4.8배 + 이메일 11배 = 15.8배”라고 적었다고 해 보자.

단계	수행 내용
Plan	전체 비율은 합계 매출 ÷ 합계 광고비라는 검증 규칙 적용
Act	잘못된 문장 위치를 찾고 원본에서 전체 합계 재계산
Observe	초안 15.8배, 재계산 2,100,000 ÷ 360,000 ≈ 5.83배
Verify	정확성 기준 미달 → 해당 문장과 연결된 표·요약을 수정하고 다시 대조

수정 뒤에도 문서의 다른 절에 15.8배가 남아 있다면 아직 완료가 아니다. 피드백은 “결과가 이상함”보다 **“요약의 전체 매출/광고비 15.8배를 약 5.83배로 고치고, 본문과 표에서 같은 지표를 모두 찾아 일치시키기”**처럼 위치와 기준을 포함해야 한다.

또 하나의 전체 예제: 경쟁사 기능 조사에서 ‘충돌’을 만났을 때#

공개 자료를 바탕으로 제품 A, B, C의 ‘새 알림 기능’ 도입 여부와 발표일을 표로 만들라는 요청을 받았다고 해 보자. 아래의 날짜는 특정 기업의 실제 발표가 아닌 가상 사례다.

단계	처음 실행	발견된 문제와 다음 행동
Plan	세 제품의 공식 자료에서 기능명·발표일·출처 위치 확보	날짜가 다르면 추측하지 않기로 기준 설정
Act	각 제품의 공식 변경 기록과 발표 페이지 열람	C 제품에 관련 문서 두 건 발견
Observe	A·B는 각각 한 날짜, C는 안내 페이지 ‘7월 10일’과 변경 기록 ‘7월 12일’	두 문서의 성격과 표현을 원문에서 재확인
Verify	A·B 통과, C 발표일은 근거 충돌로 보류	비교표에 두 날짜와 링크·설명 기재 후 사람에게 판단 요청

다음 계획에서는 “두 날짜가 실제 출시일과 공지일의 차이인가?”를 확인할 수 있다. 공식 자료가 이를 분명히 설명하지 않는다면, AI는 정확한 날짜를 확정하지 않는다. 이렇게 끝나도 결과는 유용하다. ‘확인 완료 2건, 보류 1건, 충돌 근거 2건’이라는 상태와 사용자의 다음 결정을 남겼기 때문이다.

Observe와 Verify를 헷갈리면 생기는 오류#

상황	Observe에서 말할 수 있는 것	Verify에서 따져야 할 것
PDF가 생성됨	“파일 존재, 8쪽, PDF 열림”	“요청한 절·기간·원본 수치를 모두 반영했나?”
검색 결과 세 개 발견	“공식 문서 3건, 날짜 충돌 1건”	“충돌을 해결했나, 보류 사유를 밝혔나?”
API가 200 반환	“요청 응답은 200, 주문 ID 반환”	“주문이 실제 최종 상태인가, 중복은 없나?”
코드 테스트가 통과	“정의된 테스트 12개 통과”	“사용자가 요구한 행동과 미시험 조건까지 확인했나?”

관찰은 사실을 기록한다. 검증은 그 사실을 사전에 세운 요구사항에 대조한다. 실무에서는 한 사람이 연속해서 해도 되지만, 기록에는 둘을 분리하는 편이 오류를 찾기 쉽다.

AI 검토자(Critic)를 쓸 때와 사람에게 넘길 때#

문서가 길거나 초안이 반복해서 수정된다면, 작성 역할과 검토 역할을 나눌 수 있다. 별도 AI에게 자료와 검증 기준을 주고 원본 숫자·빠진 항목·모순된 표현을 찾게 하는 방식이다. 이는 생성과 평가를 반복하는 작업 흐름의 한 구현이다. 검토자를 반드시 별도 에이전트로 만들어야 하는 것은 아니다. 먼저 계산 검증과 원본 대조처럼 결정적인 검사를 마련하고, AI 검토는 그 위에 추가한다.

검토를 맡긴다면 다음처럼 지시한다.

당신은 보고서의 검토자입니다.
입력: 사용자 요청, 원본 자료, 보고서 초안, 완료 기준.
1. 필수 항목이 있는지 요청과 대조하세요.
2. 모든 핵심 숫자는 원본 행 또는 재계산값과 대조하세요.
3. 각 오류에 [위치] [현재 내용] [근거] [필요한 수정]을 적으세요.
4. 확인할 수 없는 사실은 ‘미확인’이라고 표시하세요.
5. 전체를 한 점수로 뭉뚱그리지 말고 필수 기준별 통과·미달을 판정하세요.

세 번 검토하면 무조건 통과한다는 법칙은 없다. 같은 이유로 실패가 반복되거나, 자료 자체가 부족하거나, 정해 둔 비용·시간 한도에 도달하면 중단하고 사람에게 넘긴다. 법률 검토, 결제, 대외 공표처럼 실수의 영향이 큰 작업은 사람의 판단과 별도의 승인 절차가 필요할 수 있다.

실행 로그: 루프를 기억하고 다시 시작하는 최소한의 기록#

루프가 길어지면 AI가 앞에서 정한 기준을 잊거나, 실패한 작업을 반복할 수 있다. 다음과 같은 짧은 실행 로그를 남기면 어느 지점에서 멈췄는지, 다시 시작할 때 무엇을 확인해야 하는지 알 수 있다. 아래는 설명용 기록이다.

task: 2026년 6월 매출 보고서
goal: 5월 대비 매출과 채널별 결과를 CSV 근거로 설명
plan:
  current_step: 월별 전체 매출과 광고비 대조
  done_when: 합계와 비율이 원본으로 재계산되고 필수 절이 모두 존재
act:
  tool: csv_aggregate
  input: sales.csv, months=[2026-05, 2026-06]
observe:
  status: success
  rows: 4
  june_revenue: 2100000
  june_ad_spend: 360000
  draft_ratio: 15.8
  recomputed_ratio: 5.8333
verify:
  verdict: PARTIAL_FAIL
  evidence: 초안의 전체 비율이 채널별 비율을 더한 값임
  next: 요약과 본문에서 전체 비율을 재계산값으로 수정 후 재검증

실제 시스템에서는 작업 ID, 입력 자료 버전, 출처 위치, 실행 시각, 도구 오류와 승인 상태를 추가할 수 있다. 민감한 원본 데이터와 접근 토큰을 로그에 그대로 남기지 않도록 기록 범위를 정한다. 최종 답변만 저장하는 것보다 ‘왜 통과 또는 보류했는가’를 남기는 편이 다음 작업과 사후 점검에 유용하다.

바로 써 볼 수 있는 PAOV 요청 템플릿#

다음 템플릿은 AI에게 “알아서 해” 대신 실행과 확인의 경계를 알려 준다. 도구 접근이 없는 환경이라면 Act의 실행 기록은 사용자가 직접 제공한 자료를 바탕으로 채운다.

목표: [내가 실제로 얻고 싶은 결과]
대상 독자와 사용 목적: [누가 이 결과로 무엇을 결정하는지]
입력 자료: [파일, 공식 문서, 제공된 데이터]
허용된 행동: [읽기, 계산, 초안 작성 등]
사람의 승인 후에만 할 행동: [게시, 전송, 결제, 외부 시스템 변경]
완료 기준:
- [필수 내용 1]
- [원본과 맞아야 할 수치 또는 출처]
- [출력 형식]

각 작업에서 다음 순서로 기록해 주세요.
Plan: 다음 작업, 필요한 입력, 기대 결과, 완료 기준.
Act: 실제 사용한 도구와 입력. 사용할 수 없는 도구는 사용했다고 쓰지 않기.
Observe: 반환 상태, 처리 건수, 누락·충돌, 예상과의 차이.
Verify: 기준별 통과·미달, 근거, 수정·보류·승인 요청 중 다음 행동.

자료가 부족하거나 같은 실패가 반복되면 추측하여 완료하지 말고
부족한 자료와 결정이 필요한 지점을 알려 주세요.

처음 시도할 업무 고르기#

처음부터 자동 게시나 결제 루프를 만들 필요는 없다. 본인이 답을 확인할 수 있는 작은 읽기 전용 작업으로 시작해 보자.

이 주의 회의록에서 결정 사항과 담당자를 뽑는다. 원문 문장과 결과를 대조한다.
CSV 열 개와 행 수를 읽고 월별 합계를 계산한다. 사람이 손으로 한두 개 합계를 다시 확인한다.
제품 세 곳의 공식 변경 기록을 비교한다. 없는 날짜나 서로 다른 발표 날짜는 ‘미확인’으로 남긴다.

첫 작업에서 볼 것은 AI의 말솜씨가 아니다. 계획에서 약속한 기준이 결과 검증까지 이어졌는지다.

직접 실습: 네 줄짜리 자료로 관찰과 검증을 분리하기#

앞의 매출 CSV 네 줄을 sales.csv로 저장한 다음, 아래 코드를 check_sales.py로 저장해 실행해 보자. 외부 패키지를 설치하지 않아도 되는 Python 표준 라이브러리 예제다. 이 코드는 AI 자체가 아니라 관찰·검증에 사용할 결정적인 계산 도구다. 사용자에게 코드 실행 도구가 없다면 손으로 계산한 값과 비교해도 된다.

import csv
from collections import defaultdict
from decimal import Decimal

totals = defaultdict(lambda: {"revenue": Decimal(0), "ad_spend": Decimal(0)})

with open("sales.csv", encoding="utf-8-sig", newline="") as source:
    reader = csv.DictReader(source)
    required = {"month", "channel", "revenue", "ad_spend"}
    if not required.issubset(reader.fieldnames or []):
        raise ValueError(f"필수 열 누락: {required - set(reader.fieldnames or [])}")

    for row in reader:
        month = row["month"]
        totals[month]["revenue"] += Decimal(row["revenue"])
        totals[month]["ad_spend"] += Decimal(row["ad_spend"])

for month in sorted(totals):
    revenue = totals[month]["revenue"]
    spend = totals[month]["ad_spend"]
    ratio = "계산 불가" if spend == 0 else f"{revenue / spend:.2f}배"
    print(f"{month}: 매출 {revenue:,}원, 광고비 {spend:,}원, 매출/광고비 {ratio}")

예상 출력은 2026-05: 매출 1,500,000원, 광고비 300,000원, 매출/광고비 5.00배와 2026-06: 매출 2,100,000원, 광고비 360,000원, 매출/광고비 5.83배다. 실행 후 다음 질문으로 별도 검증을 해 보자.

네 행이 모두 계산에 들어갔는가? 이 코드는 월별 합계만 출력하므로, 행 누락 여부를 확실히 알려면 월별 행 수 출력도 추가해야 한다.
금액이 음수이거나 서로 다른 통화인 자료가 들어오면 어떻게 될까? 이 코드는 이를 막지 않는다. 실무에서 그런 자료가 가능하다면 입력 검증 규칙을 추가한다.
매출/광고비 5.83배라는 사실로 이메일이 검색광고보다 ‘더 효과적’이라고 결론 낼 수 있는가? 구매자의 중복과 매출 귀속 자료가 없으므로 단정할 수 없다.

즉, 코드가 계산을 마치고 exit=0을 반환해도 검증 질문은 여전히 남는다. 실습의 핵심은 숫자 자체보다 도구가 확인한 범위와 아직 확인하지 못한 범위를 구별하는 것이다.

실무에서 루프를 멈추거나 되돌리는 기준#

상태	무엇을 해야 하나	이유
기대한 자료가 없음	Plan으로 돌아가 입력·범위를 수정하거나 자료 요청	없는 자료를 추측해 채우지 않기 위해
도구가 일시적으로 실패	원인을 관찰하고 정책 범위에서 재시도	일시적 오류와 입력 오류를 구분하기 위해
결과의 일부만 미달	실패한 절이나 계산만 보완하고 전체 검증 다시 수행	이미 맞는 부분을 불필요하게 흔들지 않기 위해
공식 출처가 충돌	충돌을 기록하고 추가 확인 또는 사람 판단	임의로 하나를 진실로 택하지 않기 위해
게시·전송·결제 직전	검증된 초안과 대상·영향을 제시하고 승인 절차 진행	외부 효과가 있는 행동을 통제하기 위해
반복해도 같은 오류	반복 중지, 원인과 남은 선택지 보고	시간·비용 낭비와 무한 실행 방지
모든 필수 기준 통과	최종 산출물과 핵심 근거·미확인 사항 전달	‘완료’ 선언을 증거와 연결하기 위해

자주 묻는 질문#

PAOV는 매번 네 단계를 똑같이 한 번씩 거치나?#

아니다. 작은 작업은 계획과 검증을 짧게 기록해도 된다. 자료를 확인하고 나면 다시 계획을 세워야 할 수도 있고, 한 번의 검증이 여러 수정을 요구할 수도 있다. 중요한 것은 순서 암기가 아니라 새 행동에 앞서 지금까지 얻은 증거와 완료 기준을 연결하는 것이다.

AI가 “완료했습니다”라고 답했다면 Verify도 끝난 것 아닌가?#

아니다. 어떤 자료를 읽었는지, 수치가 원본과 맞는지, 빠진 요구사항은 없는지 확인해야 한다. ‘파일 생성’, ‘도구 성공’, ‘업무 완료’는 서로 다른 상태다.

검증은 다른 AI가 해야 하나?#

필수는 아니다. 계산, 파일 존재, 필수 열 같은 것은 규칙과 도구로 먼저 확인한다. AI 검토자는 문서의 누락과 모순을 찾는 보조 역할에 유용하지만, 원본과 비교할 근거를 주지 않으면 검토자도 같은 오류를 반복할 수 있다.

AI에 도구가 없으면 루프 엔지니어링을 할 수 없나?#

할 수 있다. AI가 계획과 검토를 하고, 사람이 자료 조사·실행 결과를 제공하는 구조도 루프다. 단, AI가 검색하거나 파일을 읽지 않았다면 그렇게 했다고 기록하면 안 된다.

언제 ‘완료’ 대신 ‘보류’라고 해야 하나?#

필수 근거가 없거나 공식 출처가 충돌하거나 승인되지 않은 외부 행동이 남았을 때다. 보류는 실패를 감추는 표현이 아니라, 남은 판단을 정확하게 사용자에게 넘기는 상태다.

정리: 루프의 끝은 AI의 자신감이 아니라 완료 증거다#

PAOV는 계획에서 정한 완료 기준을 실행 결과와 대조하고, 미달이면 필요한 지점으로 돌아가는 작업 방식이다. Plan은 일을 나누고 기준을 세운다. Act는 도구를 써서 실제로 행동한다. Observe는 반환된 상태와 수치, 충돌을 기록한다. Verify는 그 증거가 사용자 목표를 충족하는지 판정한다.

가장 중요한 실무 습관은 작은 것이다. 다음에 AI에게 일을 맡길 때 “어떤 결과면 끝인가?”, “실제로 무엇을 했나?”, “무엇을 관찰했나?”, “어떤 근거로 통과라고 했나?”를 작업 기록에 남겨 보자. 그러면 결과가 부족할 때도 막연히 ‘다시 해’라고 말하는 대신 어느 단계의 어떤 조건을 고쳐야 하는지 알 수 있다.