ChatGPT를 오래 쓰다 보면 어느 순간 이런 벽을 만납니다. “답은 괜찮은데, 결국 내가 마무리까지 다 해야 한다”는 벽입니다. 자료를 더 찾아야 하고, 숫자를 다시 확인해야 하고, 문서를 템플릿에 옮겨야 하고, 관련자에게 물어야 하고, 마지막으로 품질을 검토해야 합니다.
에이전트(Agent)는 이 벽을 넘기 위한 방식입니다. 에이전트의 핵심은 ‘말을 잘하는 모델’이 아니라, 목표를 주면 계획을 세우고, 도구를 써서 실행하고, 기준에 맞을 때까지 검증하며, 실패하면 안전하게 폴백하는 시스템입니다.
이 장의 목표는 두 가지입니다.
첫째, 에이전트의 특징(자율 실행, 도구 사용, 체크/폴백)을 명확히 잡습니다.
둘째, 어떤 업무가 에이전트에 잘 맞는지 유형으로 분류합니다.
에이전트는 무엇이 다른가: “답변”이 아니라 “완수”
일반적인 챗봇/대화형 사용은 한 번의 출력을 중심으로 합니다. 반면 에이전트는 완수(run-to-completion)를 중심으로 설계됩니다. 그래서 입력도 달라집니다.
챗봇 입력: “이거 요약해줘.”
에이전트 입력: “이 자료를 요약해서, 특정 템플릿에 맞춰 문서로 만들고, 근거 링크를 붙이고, 검토 체크리스트를 통과하면 제출해.”
여기서 중요한 변화는 ‘프롬프트를 잘 쓰기’가 아닙니다. 업무의 끝단까지 가는 흐름을 설계하는 것입니다.
에이전트의 3가지 핵심 특징
1) 자율 실행: 스스로 다음 행동을 고른다
에이전트는 “무엇을 말할지”뿐 아니라 “다음에 무엇을 할지”를 결정합니다. 즉, 질문에 답하는 대신 목표 달성을 위해 행동을 이어갑니다.
이 자율성은 보통 ‘루프’로 구현됩니다. 대표적으로 Plan-and-Execute 패턴은 작업을 계획(Planning)과 실행(Execution) 두 단계로 분리해, 복잡한 문제를 한 번에 해결하려다 생기는 오류를 줄이려는 접근입니다.1
2) 도구 사용: 말이 아니라 행동이 된다
에이전트가 강해지는 이유는 “추론을 더 잘해서”가 아니라, 환경과 상호작용하기 때문입니다. 웹 브라우저, 사내 검색, 파일/문서, 데이터베이스, 티켓 시스템, 캘린더 같은 도구를 통해 정보를 가져오고 변경을 일으킵니다.
자율 에이전트는 “환경과 상호작용하며, 미리 정해진 작업을 자율적으로 수행하고, 계획을 세우며, 웹 브라우저 같은 실제 도구에 접근해 실행한다”는 관점입니다.2
3) 체크/폴백: 실패해도 ‘안전한 모드’로 간다
에이전트는 여러 단계를 거치기 때문에 실패 유형도 늘어납니다. 중간 단계에서 사실이 틀릴 수 있고, 도구 호출이 실패할 수 있고, 계획이 잘못될 수 있습니다. 그래서 에이전트는 “성공 시나리오”보다 실패 시나리오 설계가 더 중요합니다.
폴백은 대체로 다음을 포함합니다. 재시도(백오프), 타임아웃, 회로차단기(circuit breaker), 드래프트/읽기 전용 모드, 사람에게 에스컬레이션, 안전 기본값, 기능 플래그·킬 스위치, 감사 로그 등입니다.4
대표 실행 패턴: Plan-and-Execute에서 ‘자기치유 루프’까지
에이전트는 보통 “생각 → 행동 → 관찰 → 조정”의 반복으로 움직입니다. 그런데 복잡도가 커질수록, 한 단계씩 반응하는 방식만으로는 비용이 늘고 방향이 흔들립니다. 그래서 최근에는 계획을 먼저 명시적으로 세우고, 그 계획을 기준으로 실행과 검증을 반복하는 구조가 선호됩니다.1
여기서 한 단계 더 나아가면, ‘검증’이 루프의 중심이 됩니다.
예를 들어 AI Agent Orchestrator는 다중 에이전트(계획/평가/리서치/아키텍트/개발/검증)가 협업하면서, Plan-Eval-Gather-Execute-Verify 루프를 돌려 “검증된 성공”이 나올 때까지 반복하는 구조를 제시합니다.3
정리하면 다음과 같습니다.
Plan-and-Execute: 계획을 먼저 만들고, 그 계획을 따라 실행한다.1
PEGEV 같은 자기치유 루프: 실행 결과를 검증(Verify)하고, 실패하면 다시 계획/수집으로 되돌아간다.3
업무에서 체감되는 차이는 큽니다. “말을 잘한 답”이 아니라, “조건을 만족하는 산출물”이 나옵니다.
어떤 업무가 에이전트에 맞는가: 5가지 유형으로 분류
에이전트는 만능이 아닙니다. ‘한 번의 답변’으로 끝나는 작업에 에이전트를 붙이면 느리고 비싸기만 합니다. 반대로, 사람이 하던 절차를 그대로 따라가야 하는 업무는 에이전트가 생산성을 크게 올릴 수 있습니다.
아래는 실무에서 바로 써먹기 쉬운 분류입니다.
| 업무 유형 | 에이전트가 맡기 좋은 목표 | 필요한 도구(예) | 필수 체크(예) |
|---|---|---|---|
| 1. 딥리서치/근거 구축형 | “이 주제의 핵심 주장과 근거를 모아 보고서로 정리” | 웹 탐색, 사내 문서 검색, 인용 추출 | 출처 링크/인용, 상충 근거 탐지, 최신성 확인 |
| 2. 문서 생산·편집형(템플릿 준수) | “정해진 형식의 문서 완성(제안서/보고서/FAQ)” | 템플릿 문서, 파일 I/O | 형식 검증(섹션 누락), 숫자/고유명사 재검증 |
| 3. 운영/티켓/라우팅형 | “문의/요청을 분류하고 다음 담당자에게 넘김” | 티켓 시스템, CRM, 메신저 | 정책 위반 차단, 민감도 분류, 중복 티켓 방지 |
| 4. 개발·디버깅형 | “버그 재현→원인 추정→수정→테스트 통과” | 저장소, 테스트 실행, 린터 | 테스트 통과, 보안 체크, 변경 영향 범위 |
| 5. 실행 대행형(예약/등록/발송 등) | “여러 시스템을 오가며 실제 작업 완료” | 캘린더, 결재, 이메일, ERP | 멱등성(중복 실행 방지), 승인 단계, 킬 스위치 |
특히 1~2번은 요즘 많이 ‘Deep Research’라는 이름으로 묶입니다. 핵심은 검색을 잘하는 것이 아니라, 검색→정리→근거화→검증까지를 한 흐름으로 만드는 것입니다.
‘끝까지 해내는’ 흐름 설계: 에이전트에게 주는 6가지 계약
에이전트를 잘 쓰는 사람은, 프롬프트를 길게 쓰는 사람이 아닙니다. 완수 조건을 계약서처럼 써주는 사람입니다.
1) 목표(Goal): 한 문장으로 끝까지 정의하기
“보고서 작성”이 아니라 “경영진 공유용 1페이지 요약 + 근거 링크 10개 + 다음 액션 5개”처럼 완료 상태를 문장으로 씁니다.
2) 성공 기준(Success Criteria): 합/불을 가르는 체크리스트
성공 기준이 없으면 에이전트는 ‘그럴듯함’에서 멈춥니다. 반대로 성공 기준이 있으면, 스스로 검증 루프를 만들 수 있습니다.3
3) 도구 목록과 권한(Tools & Permissions): 할 수 있는 일의 경계
도구가 많을수록 좋지 않습니다. “읽기 도구”와 “쓰기 도구”를 나누고, 쓰기 도구는 승인(Approval)이나 드래프트 모드 같은 안전장치와 함께 줍니다.4
4) 중간 산출물(Artifacts): 체크포인트를 강제하기
장거리 업무는 중간 산출물이 없으면 방향이 어긋납니다. 대표적으로 다음이 체크포인트가 됩니다.
계획(작업 순서, 필요한 추가 정보)
수집 목록(어떤 자료를 봤는지)
초안(드래프트)
검증 리포트(어떤 기준을 통과/실패했는지)
5) 실패 시 행동(Fallback Policy): 안전한 모드로 ‘격하’
실패했을 때 “다시 해볼게요”만 반복하면 사고가 납니다. 그래서 실패 시 모드를 지정합니다.
예: “외부 발송/등록은 중단하고, 드래프트만 만들고, 사람 승인 요청을 올려라.”4
6) 종료 조건(Stop Conditions): 무한 루프를 막는 브레이크
루프 기반 에이전트는 ‘그만할 기준’이 없으면 비용이 새고, 결과도 흔들립니다. 최대 반복 횟수, 시간/비용 예산, 더 이상 진행 불가 조건을 명시합니다.4
실전 예시 1: 딥리서치 기반 ‘경쟁사 동향 브리핑’ 에이전트
업무 요청을 이렇게 바꿔보면 효과가 큽니다.
나쁜 요청: “A사 요즘 뭐해?”
에이전트 요청: “A사의 최근 30일 발표/채용/가격/제품 업데이트를 조사해서, (1) 사실 요약, (2) 근거 링크, (3) 우리에게 영향, (4) 다음 액션 제안까지 1페이지로 완성해.”
여기서 Plan-and-Execute가 유리한 이유는 ‘조사’가 곧바로 ‘글쓰기’로 이어지면 논리 오류가 늘기 때문입니다. 먼저 계획을 세우고, 계획에 따라 수집·정리·작성 단계를 분리하면 품질이 안정됩니다.1
실전 예시 2: “드래프트만 자동, 발송은 승인” 고객응대 에이전트
고객응대는 자동화 욕심이 나지만, 리스크도 큽니다. 그래서 폴백을 설계의 중심에 둡니다.
에이전트의 목표를 이렇게 둡니다.
입력: 리뷰/문의 원문 + 고객/주문 맥락(가능한 범위)
출력: 답변 드래프트 + 사유(정책 조항/근거) + 위험 플래그(환불/법적 표현/개인정보)
실행: “발송”은 하지 않고, 승인 큐로만 올림
이 접근은 “완전 중단”이 아니라 “가치 있는 격하(degradation)”로 서비스를 유지하라는 폴백 원칙과 맞닿아 있습니다.4
체크/폴백 설계 한 장 요약: 에이전트를 ‘운영 가능’하게 만드는 장치
에이전트가 현장에서 신뢰를 얻는 지점은, 답이 좋아서가 아니라 예외 상황에서 사고를 안 내서입니다. 아래는 최소 세트입니다.4
기술 실패 대비: 타임아웃, 재시도(백오프), 회로차단기, 큐잉
품질 실패 대비: 스키마/형식 검증, 금칙어/정책 검증, 근거 요구
비즈니스 리스크 대비: 드래프트/읽기 전용 모드, 승인, 쿼터(예산) 제한
운영 대비: 관측가능성(로그/사유 코드), 롤백, 킬 스위치
AI Agent Orchestrator처럼 검증(Verify) 역할을 분리하거나, 성공 기준을 평가(Evaluate)하는 단계를 따로 두면 ‘검증이 있는 완수’가 가능해집니다.3
이 챕터의 결론: 생산성 도약은 ‘정답’이 아니라 ‘흐름’에서 나온다
에이전트 시대의 핵심은 더 똑똑한 답을 얻는 게 아닙니다.
계획-실행-검증-폴백이 있는 “끝까지 해내는 흐름”을 설계하면, 사람이 하던 절차의 대부분이 시스템 안으로 들어갑니다. 그때 ChatGPT는 조언자가 아니라, 실제로 일을 굴리는 실행자가 됩니다.
다음 장에서는 이렇게 강해진 흐름이 왜 위험해질 수 있는지, 그리고 환각·오류·오남용을 막기 위한 품질/리스크 관리 체계를 다룹니다.
참고
1Major Agentic Design Patterns - Plan and Execute | Agent Innv Lab
2How to Build AI Agents Using Plan-and-Execute Loops | TELUS Digital
3AI Agent Orchestrator (Plan-Eval-Gather-Execute-Verify loop) | GitHub
4What Fallback Systems Are Needed for AI Agents? | The Pedowitz Group
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.