루프 엔지니어링이란? AI가 계획·실행·검증하며 일하도록 설계하는 방법

루프 엔지니어링이란? AI가 일을 계획·실행·검증하도록 설계하는 방법#

금요일 저녁, 마케팅 담당자가 주간 보고서 자동화를 설정하고 퇴근했다고 가정해 보자. AI에는 “자료를 찾아 보고서를 작성하고, 부족한 부분은 다시 확인해”라고 지시했다.

월요일 아침 결과를 열어 보니 보고서는 완성되지 않았다. 같은 자료를 여러 차례 조회한 기록만 쌓여 있다. 일부 수치는 서로 맞지 않고, AI는 어느 정도 검토하면 끝내야 하는지도 판단하지 못했다.

이 문제를 단순히 “프롬프트가 부족했다”라고 설명하기는 어렵다. 업무의 완료 기준, 재시도 조건, 사용할 수 있는 도구, 사람에게 질문할 시점이 빠져 있었기 때문이다.

AI가 만들어 내는 답변 한 개와, 실제로 마무리된 업무 한 건 사이에는 여러 단계가 있다. 그 단계를 연결하고 결과를 확인하며 다음 행동을 결정하도록 설계하는 접근이 루프 엔지니어링이다.

위 상황은 개념을 설명하기 위한 학습용 가상 사례다. 특정 조직에서 발생한 사건이나 AI 제품의 성능을 나타내지 않는다.

루프 엔지니어링을 한 문장으로 설명하면#

루프 엔지니어링은 AI가 맡은 작업에 대해 계획하고 → 실행하고 → 결과를 관찰하고 → 기준에 따라 검증한 다음 → 계속할지, 수정할지, 멈출지를 결정하도록 업무 흐름을 설계하는 방법이다.

여기서 ‘루프’는 같은 질문을 AI에게 무한히 반복하는 뜻이 아니다.

예를 들어 이메일 초안을 작성할 때는 다음과 같이 한 차례의 루프가 진행될 수 있다.

어떤 내용을 전달해야 하는지 확인한다.
초안을 쓴다.
원자료와 비교해 빠진 내용을 찾는다.
필요한 부분만 수정한다.
발송 승인이 필요하면 사람에게 넘긴다.
승인 후 발송 결과가 확인되면 종료한다.

한 번에 기준을 만족하면 반복하지 않는다. 반대로 필요한 데이터가 없다면 계속 다시 쓰는 대신 정보가 부족하다고 알리고 멈추는 것이 올바른 루프의 동작이다.

AI, 프롬프트, 에이전트, 루프의 관계#

처음 접하는 독자는 네 용어가 비슷하게 느껴질 수 있다.

용어	쉬운 뜻	업무 사례
AI 모델	입력을 바탕으로 글을 생성하거나 판단을 돕는 핵심 기능	회의 메모를 읽고 요약문 작성
프롬프트	AI에 전달하는 질문이나 작업 지시	“결정 사항과 후속 작업을 구분해 줘”
AI 에이전트	목표를 위해 여러 단계와 허용된 도구를 사용하는 시스템	문서를 읽고 초안을 만든 뒤 자료와 대조
작업 루프	중간 결과를 확인해 다음 행동을 결정하는 흐름	초안 → 검토 → 보완 → 승인 요청

루프 엔지니어링은 특정 AI 제품의 기능 이름이 아니다. AI를 실제 업무에 연결할 때 필요한 절차와 판단 기준을 설계하는 관점이다. 간단한 작업은 대화만으로 루프를 진행할 수도 있고, 반복 업무는 도구와 자동화 시스템에 일부 단계를 맡길 수도 있다.

프롬프트를 잘 쓰는데도 일이 끝나지 않는 이유#

AI를 처음 사용할 때는 보통 질문부터 한다.

“지난주 영업 데이터를 분석해 줘.”

이 요청에 AI가 답하지 못하거나 일반적인 설명만 내놓으면 프롬프트를 더 자세히 쓴다.

“지난주 매출을 카테고리별로 분석하고, 증감률을 계산하고, 인사이트 세 가지와 다음 주 실행 계획을 작성해 줘.”

두 번째 요청은 첫 번째보다 분명하다. 하지만 여전히 해결되지 않은 문제가 남아 있다.

영업 데이터는 어디에 있는가?
‘지난주’는 월요일부터 일요일까지인가, 최근 7일인가?
매출은 주문액인가, 결제 완료액인가?
환불과 취소를 포함하는가?
전주와 비교할까, 전월 같은 주와 비교할까?
원인이 확인되지 않은 변화를 어떻게 표현할까?
보고서의 수치를 누가 검수하고 누구에게 전달할까?

프롬프트를 길게 쓰는 것만으로는 AI가 읽지 못한 자료를 읽은 것처럼 만들 수 없고, 업무 시스템에 없는 권한을 만들 수도 없으며, 조직 안의 암묵적인 판단 기준을 자동으로 알려 줄 수도 없다.

프롬프트 엔지니어링이 필요 없다는 뜻은 아니다. 프롬프트는 목표와 작업 방식을 전달하는 중요한 부품이다. 다만 여러 단계가 필요한 업무에서는 프롬프트를 포함한 전체 작업 구조를 살펴봐야 한다.

좋은 답변과 업무 완료는 다르다#

회의록을 예로 들어 보자. AI가 보기 좋은 회의록을 작성해도 업무가 아직 끝나지 않았을 수 있다.

회의 내용 요약은 완료
결정 사항의 사실 확인은 미완료
후속 작업 담당자 확인은 미완료
수신자 확인은 미완료
이메일 발송은 미완료

“회의록을 써 줘”와 “회의록을 검토해 팀에 전달해 줘”는 다른 업무다. 뒤의 업무에는 초안 작성 이후의 검증, 승인, 발송, 결과 확인이 포함된다.

루프 엔지니어링은 이 상태들을 구분한다. AI가 “완료했습니다”라고 말하더라도 무엇이 완료되었고 무엇이 아직 남았는지 확인할 수 있어야 한다.

AI 업무 루프는 어떻게 움직이는가#

이 글에서는 업무 흐름을 이해하기 위해 계획·실행·관찰·검증이라는 네 단계로 나눈다. 특정 서비스가 반드시 이 네 단계의 이름을 사용해야 한다는 의미는 아니다.

1. 계획: 목표와 경계를 정한다#

계획은 AI에게 길고 복잡한 사고 과정을 요구하는 일이 아니다. 해야 할 일과 하지 말아야 할 일, 결과를 확인할 방법을 정하는 일이다.

고객 문의 답장 업무라면 계획에는 다음과 같은 내용이 들어간다.

고객이 문의한 주문을 확인한다.
주문 상태와 배송 정보를 조회한다.
조회 결과를 근거로 답장 초안을 작성한다.
배송일이 없으면 임의의 날짜를 제시하지 않는다.
환불이나 보상은 담당자 승인 없이 약속하지 않는다.
답장 발송은 승인 여부를 확인한 뒤 진행한다.

이 계획이 없으면 AI는 정중한 글을 잘 쓰더라도, 확인되지 않은 날짜를 고객에게 약속할 수 있다.

2. 실행: 허용된 자료와 도구로 일한다#

실행은 문장을 생성하는 것만 뜻하지 않는다. 업무에 따라 파일을 읽거나, 데이터를 조회하거나, 계산하거나, 문서 초안을 저장할 수 있다.

다만 프롬프트에 적힌 행동과 실제로 가능한 행동은 구분해야 한다.

“주문 정보를 조회해”라고 적어도 AI가 주문 시스템에 연결되어 있지 않다면 조회할 수 없다. “이메일을 보내”라고 적어도 이메일 도구와 권한이 없으면 발송할 수 없다.

따라서 설계자는 AI에 다음을 분명히 알려 줘야 한다.

실제로 접근 가능한 자료는 무엇인가?
사용할 수 있는 도구는 무엇인가?
각 도구에서 읽기만 가능한가, 수정도 가능한가?
도구가 실패하면 어떻게 처리할 것인가?

3. 관찰: 실제로 무엇이 일어났는지 본다#

계획대로 실행하려고 했다는 사실과 실제 실행 결과는 다르다.

예를 들어 주문번호를 조회한 뒤에는 다음을 확인해야 한다.

주문이 실제로 조회되었는가?
조회된 고객과 문의한 고객이 일치하는가?
배송 상태가 표시되는가?
예상 배송일이 있는가?
조회 결과가 일부만 반환되거나 오류가 발생하지 않았는가?

보고서라면 관찰 대상은 작성된 문장뿐 아니라 원본 데이터, 계산 결과, 누락된 행, 도구의 오류 메시지까지 포함한다.

4. 검증: 다음 행동을 결정한다#

관찰한 결과를 업무의 기준과 대조한다. 결과는 대체로 네 가지 중 하나다.

검증 결과	뜻	다음 행동
통과	완료 기준을 충족	다음 단계 진행 또는 종료
보완 필요	필요한 근거가 있고 수정 가능	해당 부분 수정 후 재검증
정보 부족	확인할 자료가 없음	사람에게 질문하거나 자료 요청
권한 부족·실행 실패	승인이나 도구 조치가 필요	중단하고 현재 상태 보고

검증은 AI가 자기 답변을 다시 읽고 “좋아 보인다”라고 판단하는 것만으로 끝나지 않는다. 날짜와 수치는 원자료와 대조하고, 발송 여부는 실제 도구 결과로 확인하며, 정책 판단은 필요한 경우 담당자에게 넘겨야 한다.

루프를 언제 멈춰야 할까#

“완벽해질 때까지 반복해”는 좋은 종료 조건이 아니다. ‘완벽’의 의미가 불분명하고, 자료가 없을 때는 아무리 반복해도 해결되지 않기 때문이다.

실무에서는 다음과 같은 종료 조건을 둘 수 있다.

확인 가능한 항목이 모두 기준을 충족했다.
정해 둔 재시도 횟수에 도달했다.
같은 오류가 반복되어 더 이상의 실행이 유효하지 않다.
필요한 자료나 권한이 없어 사람이 개입해야 한다.
허용한 시간이나 비용 한도에 도달했다.

잘 설계된 루프는 더 일해야 할 때만 반복하고, 멈춰야 할 때 분명히 멈춘다.

사례 1: 회의록 작성과 이메일 발송#

“오늘 회의록을 작성해서 팀원 네 명에게 보내 줘”라는 요청을 살펴보자. 상황을 이해하기 위해 세 가지 방식으로 나눠 본다. 아래 내용은 실제 소요 시간을 비교한 실험이 아니라 학습용 가상 사례다.

방식 A: 한 문장으로 요청한다#

“오늘 회의록 작성해서 팀원들에게 보내 줘.”

AI는 회의 내용이 없으면 진행할 수 없다. 자료가 있더라도 ‘팀원 네 명’이 누구인지 모를 수 있다. 이때 올바른 동작은 필요한 자료와 수신자를 묻는 것이다.

부족한 정보를 추측해서 회의록을 쓰거나 수신자를 임의로 선택하면 업무가 빠르게 진행되는 것처럼 보여도 오류가 생긴다.

방식 B: 상세한 프롬프트를 제공한다#

사용자가 회의 주제, 참석자, 논의 안건, 이메일 제목, 수신자를 모두 적어 준다. AI는 훨씬 나은 초안을 만들 수 있다.

하지만 이 단계에서도 다음은 별개다.

안건 네 개가 실제 메모에 모두 있는가?
‘논의함’과 ‘결정함’을 구분했는가?
오늘 휴가인 팀원에게도 발송해야 하는가?
AI가 실제 발송 도구를 사용할 수 있는가?
발송 전에 사람이 본문을 승인해야 하는가?

상세한 프롬프트는 입력의 품질을 높인다. 여러 단계의 확인과 발송까지 자동으로 보장하는 것은 아니다.

방식 C: 업무 루프를 설계한다#

목표와 판단 기준을 먼저 나눈다.

목표: 회의록을 작성하고 확인된 수신자에게 전달한다.

사용할 자료: 회의 메모와 참석자 명단.

완료 기준: 결정 사항이 원자료와 일치하고, 담당자가 불명확한 항목은 표시했으며, 승인된 수신자에게 발송 결과가 확인된다.

승인 지점: 최종 본문과 수신자를 사람이 확인한다.

이제 흐름은 다음처럼 진행된다.

AI가 회의 메모에서 안건, 결정 사항, 후속 작업을 분리한다.
참석자와 담당자를 명단에 대조한다.
빠진 담당자나 서로 다른 날짜가 있으면 ‘확인 필요’로 표시한다.
회의록과 이메일 본문 초안을 작성한다.
사람에게 본문과 수신자를 보여 주고 승인을 요청한다.
발송 권한이 있다면 승인 후 발송한다.
발송 결과를 확인하고 업무 상태를 완료로 표시한다.

이 사례의 핵심은 AI가 회의록을 여러 차례 다시 썼다는 데 있지 않다. 초안이 어느 기준을 만족해야 다음 단계로 넘어가는지 정했다는 데 있다.

사례 2: 배송 지연 고객 문의 응대#

고객이 다음과 같이 문의했다고 가정하자.

“지난주 주문한 블루투스 이어폰이 아직 도착하지 않았습니다. 배송 조회에는 ‘배송 준비 중’으로 보이는데 언제 받을 수 있나요?”

고객 문의 자동화에서는 친절한 문장보다 확인된 사실에 근거한 안내가 먼저다.

계획: 무엇을 확인해야 하는가#

AI가 바로 답장을 쓰지 않고 먼저 확인해야 할 항목을 정한다.

문의한 고객의 주문번호가 있는가?
주문 상태를 조회할 수 있는가?
배송사 정보와 실제 조회 결과가 있는가?
예상 배송일이 표시되는가?
조직의 지연 안내와 보상 기준은 무엇인가?
고객 발송 전에 사람의 승인이 필요한가?

실행과 관찰: 조회 결과를 구분한다#

주문 시스템에는 ‘배송 준비 중’이라고 표시되지만 배송사의 예정일은 비어 있을 수 있다. 이 경우 두 정보는 서로 다른 상태다.

AI는 주문 상태가 확인되었다는 사실을 답장에 반영할 수 있다. 반면 도착 예정일은 확인되지 않았으므로 날짜를 약속할 수 없다.

또 다른 경우에는 주문 시스템이 조회되지 않을 수 있다. 이때 “현재 배송 준비 중입니다”라고 이전 정보를 그대로 사용하는 대신 조회 실패를 보고해야 한다.

검증: 어떤 답장이 가능한가#

확인된 정보가 주문 상태뿐이라면 다음과 같이 초안을 만들 수 있다.

“문의하신 주문은 현재 배송 준비 중으로 확인됩니다. 정확한 배송 일정은 추가 확인이 필요합니다. 확인되는 대로 안내드리겠습니다.”

이 문장은 실제 고객에게 바로 보낼 완성된 정책 문안이 아니라 검증 방식의 예시다. 발송 전에는 주문 일치 여부와 조직의 고객 응대 기준을 확인해야 한다.

반면 다음 문장은 검증을 통과하지 못한다.

“물량이 많아 배송이 지연되었으며 내일까지 도착합니다. 불편을 드려 보상해 드리겠습니다.”

조회 결과에 지연 원인, 배송일, 보상 기준이 없다면 세 가지를 모두 임의로 약속한 셈이다.

사람에게 넘길 지점#

환불, 보상, 배송 확약은 조직의 정책과 권한에 따라 처리한다. AI가 답장 초안을 만들더라도 금전과 대외 약속이 수반되는 판단은 승인 단계로 넘길 수 있다.

여기서 루프 엔지니어링은 ‘자동 발송 기능’을 만드는 일이 아니라 확인된 사실과 확인되지 않은 사실을 나누고, 책임이 필요한 결정 앞에서 멈추는 구조를 만드는 일이다.

사례 3: 영업 데이터로 주간 보고서 작성#

영업 보고서는 루프 엔지니어링이 필요한 이유를 잘 보여 준다. 텍스트가 매끄러워도 계산과 해석이 틀리면 업무 결과로 쓰기 어렵기 때문이다.

막연한 요청에서 생기는 문제#

“지난주 영업 데이터 분석해서 보고서 만들어 줘.”

이 요청만 받은 AI는 데이터 접근 여부부터 확인해야 한다. 실제 데이터가 없는데도 매출 추세나 원인을 적는다면 보고서가 아니라 추측을 작성하는 셈이다.

지나치게 상세한 형식 지시의 한계#

사용자가 “A열은 날짜, B열은 매출, 카테고리별 합계를 구하고 증감률 10% 이상을 표시하라”고 요청하면 표의 형식은 나아진다.

그러나 여전히 지표의 의미와 업무 목적이 빠져 있을 수 있다. 예를 들어 확정 매출과 잠정 매출이 섞여 있다면, 어느 값을 임원 보고에 사용해야 하는지 형식 지시만으로 결정할 수 없다.

보고서 루프의 설계 예시#

입력 정의#

분석 기간: 조직이 정의한 지난주 기간
데이터 원본: 승인된 영업 데이터
지표: 매출, 주문 건수, 취소 등 필요한 항목
비교 기준: 전주, 목표 대비 등 실제 업무에 필요한 기준

계획#

원본 데이터의 기간과 누락 여부를 확인한다.
지표를 계산한다.
전주 또는 목표와 비교한다.
큰 변동을 찾아 근거를 확인한다.
확인된 사실과 검토할 가설을 나눠 보고서를 작성한다.
수치와 문장을 다시 대조한 뒤 사람에게 검토를 요청한다.

검증#

매출이 전주보다 감소했다는 계산 결과는 확인된 사실일 수 있다. 그러나 “경쟁사의 가격 인하가 원인”이라는 설명은 경쟁사 자료가 없으면 가설이다.

보고서에서 이 둘을 같은 확신으로 표현하면 독자가 잘못된 결정을 내릴 수 있다.

완료 상태#

보고서 파일이 만들어진 상태는 초안 완료다. 숫자를 대조한 상태는 검증 완료다. 담당자가 승인하고 임원에게 전달했다면 공유 완료다.

이 상태를 분리하면 오류가 발생했을 때 어느 단계로 돌아가야 하는지 알 수 있다. 수치가 틀렸다면 문장만 고칠 것이 아니라 데이터 조회나 계산 단계부터 다시 확인해야 한다.

루프 엔지니어링에서 반드시 설계할 여섯 가지#

목표와 산출물#

먼저 무엇을 만들어야 하는지를 정한다. ‘시장 조사’처럼 넓은 표현이라면 범위, 기간, 결과물 형태를 좁힌다.

예를 들어 “경쟁사 조사를 해 줘”보다 다음 지시가 명확하다.

“지정한 경쟁사 세 곳의 공개 가격 페이지를 확인하고, 확인 날짜와 출처를 포함한 비교표 초안을 만들어 줘. 확인되지 않는 가격은 빈칸으로 두고 이유를 적어 줘.”

맥락과 근거 자료#

AI는 조직의 파일 구조와 내부 정책을 자동으로 알지 못한다. 어떤 문서를 근거로 삼을지, 자료가 충돌하면 무엇을 우선할지 정한다.

최신 주문 조회 결과와 오래된 고객 메모가 서로 다르다면 어느 정보를 사용해야 할까? 이런 우선순위는 업무마다 다르므로 설계에 포함해야 한다.

도구와 권한#

읽기, 작성, 수정, 발송은 서로 다른 수준의 행동이다.

자료 검색과 조회는 허용
초안 작성과 임시 저장은 허용
고객 정보 수정은 승인 필요
이메일 외부 발송은 승인 필요

이렇게 나누면 AI가 작업을 진행하면서도 책임이 큰 단계에서 멈출 수 있다.

검증 기준#

“꼼꼼하게 검토해”보다는 확인할 대상을 정한다.

표의 합계가 원본과 맞는가?
날짜가 조회 결과와 일치하는가?
출처를 확인할 수 있는가?
결정 사항과 제안 사항을 구분했는가?
고객에게 약속한 내용이 정책 범위 안에 있는가?

가능한 한 결과물 바깥의 근거와 비교하는 편이 좋다. AI가 만든 요약을 같은 AI가 다시 읽는 것만으로는 원자료에 없는 사실을 확실하게 찾아내기 어렵다.

재시도와 복구#

오류를 발견했을 때는 처음부터 모든 작업을 반복할 필요가 없다. 보고서의 표 합계만 틀렸다면 계산 단계로 돌아가고, 수신자만 틀렸다면 발송 직전 확인 단계로 돌아갈 수 있다.

반면 원본 데이터가 손상되었다면 AI가 문장을 고쳐 해결할 수 없다. 이때는 실패 원인, 마지막으로 성공한 단계, 사람에게 필요한 조치를 알려 주어야 한다.

승인과 종료#

언제 완료인지와 언제 사람의 승인이 필요한지 정한다.

특히 발송, 결제, 삭제, 정책 예외 적용은 결과를 되돌리기 어렵거나 외부에 영향을 준다. “AI가 내용 검토를 마쳤다”와 “사람이 대외 발송을 승인했다”는 구분해야 한다.

잘못 설계된 루프는 어떻게 실패하는가#

완료 기준이 없어 계속 반복한다#

“더 좋은 보고서를 만들어”만 반복하면 무엇이 좋아져야 하는지 알 수 없다. 문장의 길이만 늘어나거나 이미 확인한 자료를 계속 다시 조회할 수 있다.

개선: 완료 기준을 먼저 적는다. 예를 들어 “원본 합계와 일치하고, 큰 변동 세 건에 출처 또는 ‘원인 확인 필요’ 표시가 있으면 검토 단계로 넘긴다.”

같은 AI의 자기평가만 믿는다#

AI가 생성한 답변을 다시 읽고 “정확하다”고 말하는 것만으로 실제 사실이 검증되지는 않는다.

개선: 수치에는 원본 데이터, 일정에는 캘린더 기록, 주문에는 실제 주문 조회 결과처럼 확인 가능한 근거를 둔다. 자체 검토는 형식과 누락 점검에 사용한다.

재시도 횟수와 비용 한도가 없다#

일시적인 오류는 재시도가 도움이 될 수 있다. 하지만 접근 권한이 없는 자료를 계속 요청하거나 존재하지 않는 파일을 반복해서 찾는 것은 문제를 해결하지 못한다.

개선: 같은 오류가 반복되면 중단하고 사람에게 보고한다. 도구 사용량과 실행 시간에도 적절한 한도를 둔다.

승인 단계가 문장으로만 존재한다#

프롬프트에 “발송 전에 승인받아”라고 적어도 실제 자동화가 승인 전에 발송 도구를 호출할 수 있다면 설계가 부족하다.

개선: 중요한 행동은 도구 권한이나 업무 흐름에서도 승인 전 실행되지 않도록 구성하고, 시험 환경에서 확인한다.

불확실한 내용을 사실처럼 채운다#

배송일, 매출 감소 원인, 담당자 이름이 비어 있는데 자연스러운 문장으로 메우면 결과물이 완성되어 보일 수 있다.

개선: 확인되지 않은 값은 ‘확인 필요’로 표시하고, 어디에서 확인해야 하는지 함께 적는다.

비전공자도 시작할 수 있는 작은 루프 실습#

처음부터 코드를 작성하거나 여러 서비스를 연결할 필요는 없다. 자신이 이미 하는 업무 한 가지로 사람과 AI가 함께 진행하는 루프를 만들어 보자.

여기서는 신제품 마케팅 아이디어 초안 작성을 예로 든다.

첫 번째 요청: 결과물만 요구한다#

“선크림 출시 마케팅 아이디어 세 개 줘.”

결과를 읽고 다음을 확인한다.

타깃 고객이 분명한가?
제품의 확인되지 않은 효능을 주장하지 않는가?
아이디어마다 실행 방법이 있는가?
예산이나 판매 채널에 맞는가?

이 확인 항목이 다음 요청에서 검증 기준이 된다.

두 번째 요청: 계획과 기준을 포함한다#

목표: 신제품 선크림의 인스타그램 마케팅 아이디어
3개를 제안해 주세요.

제공한 제품 정보만 사용하세요.
정보가 부족하면 효능이나 인증을 추측하지 말고
확인이 필요한 항목으로 표시하세요.

진행 순서:
1. 먼저 타깃과 필요한 추가 정보를 정리하세요.
2. 타깃별 아이디어 3개를 제안하세요.
3. 각 아이디어에 콘셉트, 게시물 형식,
   짧은 영상의 핵심 장면, 실행 시 필요한 자료를 적으세요.
4. 제품 정보와 모순되는 표현이 없는지 다시 확인하세요.
5. 실행 가능성을 판단하기 위해 내가 답해야 할 질문을
   최대 3개 제시하세요.

완료 기준:
- 세 아이디어의 타깃과 콘셉트가 서로 구분된다.
- 확인되지 않은 제품 효능을 사실처럼 쓰지 않는다.
- 각 아이디어에 필요한 다음 행동이 제시된다.

두 결과를 비교할 때는 “두 번째 답변이 더 길다”만 보지 않는다. 확인되지 않은 내용을 표시했는지, 실제로 다음 작업으로 이어지는지, 검토할 부분이 줄었는지 확인한다.

세 번째 단계: 사람의 피드백을 루프에 넣는다#

세 아이디어 가운데 하나를 고른 다음 이렇게 요청한다.

“두 번째 아이디어를 선택하겠습니다. 목표 고객을 20대 직장인으로 좁혀 다시 작성해 주세요. 제품의 자외선 차단 지수는 아직 확인되지 않았으니 언급하지 마세요. 수정 전후의 차이를 짧게 설명해 주세요.”

이 과정에서 사람은 목표와 근거를 제공하고, AI는 그 범위 안에서 초안을 수정한다. 계획 → 실행 → 관찰 → 검증 → 수정이 실제 업무에 적용되는 가장 간단한 형태다.

자동화 수준은 업무에 맞게 정한다#

모든 업무에 AI 에이전트가 필요한 것은 아니다. 루프 엔지니어링은 자동화를 무조건 늘리는 접근이 아니라 어디까지 자동으로 진행할지 정하는 작업이기도 하다.

업무 유형	적합한 시작 방식	사람의 역할
문장 다듬기	한 번의 요청과 결과 확인	최종 문장 선택
회의록 초안	초안 작성과 원문 대조 루프	결정 사항과 수신자 확인
주간 보고서	데이터 조회·계산·검증 루프	해석과 대외 공유 승인
고객 문의 응대	주문 정보 조회와 답장 초안 루프	정책 판단과 필요 시 발송 승인

간단한 작업에 복잡한 절차를 붙이면 검토 시간이 오히려 늘어날 수 있다. 반대로 고객 응대나 데이터 보고처럼 오류의 영향이 큰 일에 단발성 프롬프트만 쓰면 확인 과정이 빠진다.

효과는 ‘AI가 만든 시간’이 아니라 ‘업무가 끝난 시간’으로 측정한다#

루프를 적용했을 때 개선되었는지는 실제 업무에서 비교해야 한다.

측정 항목	확인할 내용
총 완료 시간	AI 실행부터 사람 검토와 최종 처리까지 걸린 시간
사실 오류	원자료와 다른 수치·날짜·이름의 개수
재작업	같은 결과물을 다시 작성하거나 수정한 횟수
판단 보류	정보가 없을 때 추측하지 않고 질문했는지
권한 준수	승인 전 발송·수정·삭제가 발생하지 않았는지
운영 비용	AI 사용량, 도구 실행, 사람의 검토 부담

예를 들어 AI가 보고서 초안을 빠르게 작성해도 사람이 수치를 일일이 다시 계산해야 한다면 효과가 제한적이다. 반면 AI가 불확실한 항목을 명확히 표시하고 원본과 다른 숫자를 먼저 찾아 준다면, 글을 작성하는 속도 외에도 검토 과정의 질을 개선할 수 있다.

실제 절감 시간이나 생산성 배수는 업무의 종류와 데이터 품질, 도구 연결, 승인 방식에 따라 달라진다. 따라서 일반적인 숫자를 약속하기보다 자신의 업무에서 직접 비교해야 한다.

정리: 프롬프트 작성자에서 업무 흐름의 설계자로#

프롬프트는 AI에게 무엇을 할지 알려 준다. 루프 엔지니어링은 그 일을 어떤 근거로 진행하고, 무엇을 확인하며, 문제가 생기면 어떻게 대응하고, 어느 상태에서 끝낼지 정한다.

핵심 질문은 여섯 가지다.

AI가 이루어야 할 목표는 무엇인가?
어떤 자료를 근거로 사용할 것인가?
어떤 도구와 권한이 필요한가?
무엇을 확인해야 다음 단계로 갈 수 있는가?
언제 다시 시도하고 언제 멈출 것인가?
어느 행동 앞에서 사람의 판단이나 승인이 필요한가?

이 질문에 답할 수 있다면 AI에게 그럴듯한 답변을 받는 단계를 넘어, 사람이 확인하고 책임질 수 있는 업무 결과를 반복해서 만드는 구조를 설계하기 시작한 것이다.