단일 에이전트 설계 패턴

복잡한 시스템처럼 보여도, 출발점은 대개 하나의 좋은 루프다

에이전트를 만들기 시작하면 금방 욕심이 생긴다. 검색 담당 에이전트, 요약 담당 에이전트, 검토 담당 에이전트, 관리자 에이전트까지 줄줄이 세우고 싶어진다. 하지만 실무에서는 오히려 반대인 경우가 많다. 대부분의 유용한 에이전트는 복잡한 척하는 한 개의 좋은 워크플로에서 시작한다. 단일 에이전트에 도구를 붙이고, 필요한 만큼만 생각하게 하고, 반복 횟수를 제한하는 편이 디버깅과 운영에 훨씬 유리하다.¹²

이 말은 멀티에이전트가 필요 없다는 뜻이 아니다. 다만 아직 한 명이 할 수 있는 일을 굳이 다섯 명에게 쪼개면, 성능보다 회의 시간이 먼저 늘어난다는 뜻이다. 사람도 그렇다. 문서 하나 요약하는데 팀장, 실무자, 감수자, 진행자까지 모이면 괜히 거창해진다. 에이전트도 비슷하다.

이번 장에서는 단일 에이전트를 설계할 때 가장 자주 만나는 대표 패턴을 살펴본다. 핵심은 패턴 이름을 외우는 데 있지 않다. 언제 단순하게 시작하고, 언제 한 단계 더 구조를 넣어야 하는지 감을 잡는 것이 중요하다.

단일 에이전트는 무엇을 잘하나

단일 에이전트는 하나의 모델이 프롬프트, 도구, 상태를 바탕으로 사용자 요청을 해석하고 필요한 행동을 선택하는 구조다. 질문을 이해하고, 계획을 세우고, 도구를 호출하고, 결과를 확인한 뒤 다시 다음 행동을 정한다. 이 과정을 한 에이전트가 책임진다.²

이 구조가 특히 잘 맞는 상황은 이렇다.

• 작업이 한 도메인 안에 있다

• 필요한 도구 수가 관리 가능한 수준이다

• 중간 판단은 필요하지만, 지나치게 복잡한 역할 분담까지는 필요하지 않다

• 실패 원인을 빠르게 추적해야 한다

예를 들어 고객 지원 에이전트가 주문 상태를 조회하고, 환불 정책을 확인하고, 답변을 정리하는 일은 단일 에이전트로도 충분히 잘할 수 있다. 연구 도우미가 웹 검색과 문서 검색을 오가며 초안을 만드는 일도 마찬가지다. 이런 문제를 처음부터 멀티에이전트로 설계하면 멋있어 보일 수는 있어도, 실제로는 지연 시간과 비용, 조정 복잡성만 커질 수 있다.¹

패턴을 보기 전에: 좋은 단일 에이전트의 공통 뼈대

패턴은 서로 달라 보이지만, 밑바닥 구조는 꽤 비슷하다. 좋은 단일 에이전트에는 대개 네 가지가 있다.

첫째, 현재 상태가 있다. 지금까지 무엇을 했는지, 어떤 도구 결과를 얻었는지, 무엇이 아직 불확실한지 기억해야 한다.

둘째, 행동 선택 규칙이 있다. 바로 답할지, 도구를 쓸지, 다시 검색할지, 사람에게 넘길지를 골라야 한다.

셋째, 종료 조건이 있다. 충분한 근거를 모았는지, 최대 반복 횟수에 도달했는지, 더 진행하면 오히려 품질이 나빠지는지 판단해야 한다.

넷째, 출력 형식이 있다. 사람에게 보여 주는 답변인지, 다른 시스템에 넘길 JSON인지, 다음 단계로 전달할 계획서인지가 분명해야 한다.

이 네 가지가 흐리면, 에이전트는 똑똑해 보이다가도 갑자기 빙빙 돌기 시작한다. 마치 지도를 들고는 있지만 목적지에 동그라미를 안 쳐 놓은 여행자처럼 움직인다.

ReAct: 생각하고, 행동하고, 관찰하는 기본 루프

단일 에이전트의 대표 패턴은 역시 ReAct다. 이름은 Reason and Act의 줄임말로, 말 그대로 생각한 뒤 행동하고, 행동 결과를 보고 다시 생각하는 방식이다.³

가장 단순한 형태는 이렇다.

• 지금 무엇이 필요한지 생각한다

• 필요한 도구를 고른다

• 도구 결과를 받는다

• 그 결과가 충분한지 본다

• 충분하지 않으면 다시 한 번 돈다

이 패턴이 좋은 이유는 에이전트가 처음부터 모든 답을 아는 척하지 않게 만들기 때문이다. 먼저 가설을 세우고, 실제 도구 결과로 확인하고, 그 결과를 바탕으로 다음 행동을 정한다. 그래서 최신 정보가 필요하거나, 중간에 방향을 바꿔야 하는 작업에 잘 맞는다.³

예를 들어 사용자가 "지난주 우리 결제 API 평균 응답 시간과 SLA를 비교해 줘"라고 물었다고 해 보자. 에이전트는 머릿속으로만 답하면 안 된다. 먼저 메트릭 데이터베이스를 조회하고, SLA 기준을 문서에서 찾고, 둘을 비교해야 한다. 이때 ReAct는 아주 자연스럽다.

이 패턴의 장점은 투명성이다. 어디서 잘못됐는지 보기 쉽다. 검색어가 이상했는지, 잘못된 도구를 골랐는지, 도구 결과를 해석하는 과정에서 헷갈렸는지 추적할 수 있다.³

물론 단점도 있다. 루프를 도는 만큼 호출 횟수가 늘어나고, 응답 속도와 비용이 올라간다. 또 잘못된 도구 결과를 너무 믿으면 그다음 판단도 연달아 흔들릴 수 있다. 그래서 실무에서는 최대 반복 횟수, 도구 실패 시 대체 경로, 중간 상태 로깅이 거의 필수다.¹²

계획-실행 루프: 먼저 길을 그리고, 그다음 걷는다

ReAct가 걸어가면서 생각하는 패턴이라면, 계획-실행 루프는 먼저 지도를 한 번 펼쳐 보는 방식이다. 복잡한 요청일수록 이 차이가 커진다.⁴

예를 들어 "신제품 출시 전략을 작성해 줘"라는 요청은 한 번에 답하기 어렵다. 시장 조사, 경쟁사 비교, 내부 데이터 검토, 메시지 초안, 일정 제안까지 얽혀 있을 수 있다. 이런 문제에서 바로 도구를 쓰기 시작하면, 중간에 "아, 순서가 잘못됐네" 하고 되돌아오기 쉽다.

계획-실행 루프는 보통 이렇게 움직인다.

먼저 에이전트가 작업을 몇 개의 하위 과제로 쪼갠다. 그다음 어떤 순서로 할지 정한다. 필요한 도구와 의존 관계를 잡는다. 그리고 나서 하나씩 실행한다. 실행 중에 상황이 바뀌면 계획을 수정할 수도 있다.⁴⁵

이 패턴이 특히 유용한 경우는 다음과 같다.

• 하위 작업이 여러 개이고 순서가 중요할 때

• 중간 산출물이 다음 단계 품질에 큰 영향을 줄 때

• 목표는 하나지만 실제 일감은 묶음 세트일 때

다만 단순한 질문에까지 계획부터 세우면 오히려 느리고 답답해진다. 오늘 날씨를 묻는데 "1단계: 지역 확인, 2단계: 기상 데이터 수집, 3단계: 요약"을 진지하게 출력하는 에이전트는 똑똑하다기보다 과몰입에 가깝다. 계획은 복잡성을 줄이기 위해 쓰는 것이지, 복잡성을 연출하기 위해 쓰는 것이 아니다.

그래서 실전에서는 이런 식으로 나누는 경우가 많다. 짧은 작업은 ReAct, 긴 작업은 계획-실행. 또는 먼저 짧은 계획을 만들고, 각 하위 과제 내부는 다시 ReAct로 해결한다. 이 조합이 꽤 강력하다.⁴

Reflection: 답을 낸 뒤 한 번 더 의심하기

사람이 글을 쓰고 바로 제출하면 어색한 문장이 꼭 보이지 않는다. 한 번 떨어져서 읽어 보면 비로소 보인다. Reflection 패턴은 에이전트에게 그런 한 걸음 물러나기를 강제로 시키는 구조다.⁶

흐름은 단순하다. 먼저 초안을 만든다. 그다음 스스로 비평가 모드로 들어가서 검토한다. 사실 오류가 없는지, 제약 조건을 어기지 않았는지, 논리가 비약하지 않았는지 살핀다. 문제가 있으면 고친 뒤 다시 확인한다.⁶

이 패턴은 특히 정답의 질이 중요한 작업에 잘 맞는다. 예를 들면 코드 생성, 규정 검토, 장문의 보고서 초안, 고객에게 바로 노출되는 답변 같은 경우다. 속도보다 정확성과 일관성이 중요할 때 Reflection의 값어치가 커진다.⁶

하지만 여기서도 함정은 있다. 기준이 모호하면 에이전트가 끝없이 까다로운 심사위원이 된다. "더 좋아질 수 있어"만 반복하다가 시간을 다 쓴다. 그래서 Reflection에는 반드시 검토 기준과 종료 기준이 있어야 한다.

좋은 기준은 대체로 구체적이다. 예를 들어 "좋은 글인지 확인해라"보다는 "사실 근거가 없는 주장에 표시하라", "JSON 스키마를 만족하는지 검사하라", "보안 정책 위반 여부를 검토하라"가 훨씬 낫다. Reflection은 감상이 아니라 검사에 가까울수록 힘을 발휘한다.

구조화된 출력: 자유로운 말보다 믿을 수 있는 모양

에이전트가 사람에게 설명할 때는 자연어가 편하다. 하지만 에이전트가 시스템과 연결될 때는 이야기가 달라진다. 예약 시스템, CRM, 티켓 시스템, 워크플로 엔진은 "대충 이런 뜻이에요"를 이해하지 못한다. 그래서 구조화된 출력이 중요해진다.⁷

구조화된 출력이란 에이전트의 결과를 미리 정한 형식으로 묶는 것이다. 예를 들어 이런 식이다.

• 작업 상태: success, needs_more_info, failed

• 다음 행동: search, ask_user, finalize

• 핵심 근거: 배열 형태의 인용 목록

• 최종 답변: 사용자에게 보여 줄 문장

이렇게 형식을 정해 두면 좋은 점이 많다. 먼저 파싱이 쉬워진다. 둘째, 검증이 가능해진다. 셋째, 실패를 다루기 쉬워진다. 예를 들어 필수 필드가 비어 있으면 바로 재시도시키거나 사람 검토로 넘길 수 있다. Agentic RAG 같은 패턴에서도 구조화된 출력은 중요한 역할을 한다. 검색 결과 평가, 재질의 여부, 최종 답변 생성이 모두 루프 안에서 이어지기 때문이다.⁷

쉽게 말해 구조화된 출력은 에이전트에게 "말을 잘해라"가 아니라 "정해진 양식에 맞춰 일해라"라고 요구하는 것이다. 자유 서술형 천재보다, 양식 지키는 유능한 실무자가 더 도움이 되는 순간이 많다.

Agentic RAG: 검색도 한 번에 끝내지 않는 에이전트형 검색

전통적인 RAG는 보통 한 번 검색하고, 그 결과를 읽고, 답한다. 간단한 질문에는 이 방식이 잘 통한다. 하지만 현실의 질문은 종종 더 까다롭다. 여러 자료를 엮어야 하고, 첫 검색이 빗나가기도 하고, 아예 다른 데이터 소스를 다시 봐야 할 때도 있다.

이때 등장하는 것이 Agentic RAG다. 핵심은 검색이 한 번으로 끝나지 않는다는 점이다. 에이전트가 스스로 "지금 찾은 정보가 충분한가?", "검색어를 바꿔야 하나?", "벡터 검색 말고 SQL이나 웹 검색이 필요한가?"를 판단하며 반복적으로 탐색한다.⁷⁸

즉, 흐름이 이렇게 바뀐다.

사용자 질문이 들어오면 에이전트가 먼저 정보 공백을 판단한다. 필요한 도구를 고른다. 검색이나 질의를 실행한다. 결과의 품질을 평가한다. 부족하면 질의를 다시 쓴다. 다른 도구를 시도한다. 충분한 근거가 모이면 그제야 최종 답변을 만든다.⁷⁸

이 패턴은 특히 다음 같은 질문에 강하다.

• 여러 문서와 데이터 소스를 함께 봐야 하는 질문

• 비교와 검증이 필요한 질문

• 검색어를 한 번에 잘 쓰기 어려운 질문

• 정확성이 중요해서 근거를 재확인해야 하는 질문

예를 들어 "우리 엔터프라이즈 요금제와 스타트업 요금제의 가격 구조를 비교하고, 지난 분기 유지율까지 고려하면 어떤 쪽이 더 강한가?" 같은 질문은 전통적인 RAG에겐 꽤 버겁다. 가격 문서는 문서 저장소에 있고, 유지율은 분석 데이터베이스에 있고, 비교 판단은 별도 추론이 필요하기 때문이다. Agentic RAG는 이런 상황에서 검색과 추론을 엮어 준다.⁸

다만 여기서도 중요한 사실이 있다. Agentic RAG는 거대한 마법이 아니라, 결국 ReAct + 도구 사용 + 평가 + 재시도의 조합인 경우가 많다. 이름은 근사하지만, 속은 좋은 단일 에이전트 루프다.

실제 설계에서는 패턴을 섞는다

현실의 단일 에이전트는 보통 한 패턴만 쓰지 않는다. 오히려 다음처럼 섞는 편이 자연스럽다.

먼저 짧은 계획을 세운다. 그다음 각 단계에서는 ReAct로 도구를 호출한다. 초안을 만든 뒤 Reflection으로 검토한다. 마지막 결과는 구조화된 출력으로 정리한다. 검색이 많이 필요한 단계에서는 Agentic RAG처럼 질의를 반복 개선한다.

이 조합을 너무 무겁게 생각할 필요는 없다. "패턴을 조합한다"는 말은 거창한 프레임워크를 뜻하지 않는다. 사실상 좋은 습관을 여러 개 붙인 단일 루프에 가깝다.

예를 들어 사내 리서치 에이전트를 설계한다면 이렇게 만들 수 있다.

• 먼저 요청을 3단계 이하의 간단한 계획으로 나눈다

• 각 단계에서 필요한 검색이나 데이터 조회는 ReAct로 수행한다

• 중간 결과가 빈약하면 질의를 다시 써서 한 번 더 찾는다

• 최종 보고서는 근거 항목을 포함한 JSON과 사람용 요약문으로 함께 낸다

• 배포 전에는 Reflection으로 사실 누락과 과장 표현을 검사한다

보면 멀티에이전트가 전혀 없어도 꽤 그럴듯하다. 아니, 실제로는 이 정도가 가장 실용적인 경우가 많다.

단일 에이전트가 실패하는 흔한 이유

단일 에이전트 자체가 약해서 실패하는 경우보다, 설계가 흐려서 실패하는 경우가 더 많다.

첫 번째는 루프가 끝나지 않는 경우다. 정보가 부족할수록 더 검색하고 싶어 하지만, 언제 멈춰야 하는지 모르면 제자리걸음이 된다. 그래서 최대 반복 횟수와 "이 이상은 사람 확인 필요" 같은 탈출구가 중요하다.¹²

두 번째는 계획이 없어서 헤매는 경우다. 긴 작업인데도 매 순간 즉흥적으로 행동하면 앞에서 한 일을 뒤에서 다시 한다. 검색은 많이 했는데 정작 결과물은 허술해진다.

세 번째는 검토 단계가 없어서 자신감 넘치는 오답을 내는 경우다. 초안을 바로 정답처럼 내보내면 화려한 문장으로 포장된 실수가 남는다. Reflection이 괜히 있는 것이 아니다.⁶

네 번째는 출력 형식이 들쭉날쭉한 경우다. 어떤 날은 JSON, 어떤 날은 산문, 어떤 날은 반쯤 섞여 나오면 그 순간부터 시스템 연결이 흔들린다. 구조화된 출력은 개발자 편의 기능이 아니라 신뢰성 장치다.⁷

어떤 패턴부터 써야 할까

처음 만드는 사람이라면 어렵게 생각할 필요가 없다. 보통은 이 순서가 무난하다.

• 한 번의 답변으로 끝나는 작업이면 그냥 좋은 프롬프트부터 시도한다

• 도구가 필요하고 중간 판단이 있으면 ReAct를 쓴다

• 작업이 길고 순서가 중요하면 계획-실행 루프를 넣는다

• 품질 요구가 높으면 Reflection을 붙인다

• 다른 시스템과 연결되면 구조화된 출력을 강제한다

• 검색이 자주 빗나가거나 여러 데이터 소스를 오가면 Agentic RAG로 발전시킨다

이 순서가 중요한 이유는, 복잡성을 단계적으로 올릴 수 있기 때문이다. 처음부터 모든 기능을 다 넣으면 어느 부분이 효과를 냈는지, 어느 부분이 문제를 일으켰는지 구분하기 어렵다. 반대로 단순한 형태에서 출발해 하나씩 추가하면 개선이 눈에 보인다.

이 장의 핵심

단일 에이전트 설계 패턴의 요점은 화려한 이름이 아니라 좋은 루프를 만드는 것이다.

ReAct는 생각-행동-관찰의 기본 리듬을 만든다. 계획-실행 루프는 긴 작업에서 길을 잃지 않게 해 준다. Reflection은 첫 답을 마지막 답으로 착각하지 않게 한다. 구조화된 출력은 에이전트를 시스템 친화적으로 만든다. Agentic RAG는 검색을 한 번의 이벤트가 아니라 반복 가능한 탐색 과정으로 바꾼다.

그리고 중요한 결론이 하나 남는다. 실용적인 에이전트는 대개 "대단한 멀티에이전트 시스템"으로 시작하지 않는다. 도구를 잘 쓰고, 적당히 계획하고, 필요할 때 스스로 검토하며, 정해진 형식으로 결과를 내는 단일 에이전트로 시작한다.

그 한 개가 정말 잘 돌아가기 시작했을 때, 그다음에야 비로소 둘째 에이전트를 고민해도 늦지 않다.

참고

¹AI Agent Orchestration Patterns - Azure Architecture Center | Microsoft Learn

²에이전트 AI 시스템의 설계 패턴 선택

³AI Agent Design Patterns 2026: ReAct, Reflection & Planning Implementation Guide

⁴7 Must-Know Agentic AI Design Patterns

⁵Top AI Agentic Workflow Patterns — A Practical Guide

⁶AI Agent Design Patterns: ReAct, Plan-and-Execute, and Reflexion

⁷Agentic RAG

⁸Agentic RAG: How AI Agents That Search, Reason, and Act Are Replacing Traditional Retrieval Pipelines