AI 에이전트를 구축하는 모든 팀이 같은 벽에 부딪힙니다.
하나의 프롬프트와 몇 가지 도구로 시작합니다.
잘 작동합니다.
그러다 요구사항이 늘어납니다. 더 많은 엣지 케이스. 더 많은 팀. 더 많은 리스크.
갑자기 "에이전트"가 3,000단어 시스템 프롬프트로 변해 다섯 가지 일을 동시에 하려고 합니다.
해결책은 더 많은 프롬프트 엔지니어링이 아닙니다.
올바른 패턴을 선택하는 것입니다.
다음은 모든 프로덕션 에이전트 시스템을 구성하는 15가지 패턴과 각각을 언제 사용해야 하는지에 대한 정확한 설명입니다.
패턴을 선택하기 전에
모든 작업에 에이전트가 필요한 것은 아닙니다.
다음과 같은 경우에 작업에 에이전트가 필요합니다.
→ 단일 모델 호출로 신뢰할 수 있는 결과를 얻을 수 없는 경우
→ 모델이 실행 중에 도구나 데이터 소스 중에서 선택해야 하는 경우
→ 작업에 계획, 검증 또는 반복적 개선이 필요한 경우
→ 워크플로에 하드코딩할 수 없는 실제 불확실성이 있는 경우
입력-출력 경로가 예측 가능한 경우 작업에는 일반적으로 에이전트가 필요하지 않습니다.
요약. 분류. 간단한 추출. 템플릿 기반 생성.
이러한 작업은 직접 모델 호출로 처리하는 것이 더 빠르고 저렴하며 안정적입니다.
에이전트로 감싸면 지연 시간과 실패 지점만 추가될 뿐 이점이 전혀 없습니다.
패턴 1 — 단일 에이전트 (Single Agent)
가장 간단하고 가장 일반적인 시작점입니다.
하나의 모델. 하나의 시스템 프롬프트. 제한된 도구 세트.
모델이 호출할 도구를 결정하고, 결과를 관찰하고, 답변을 내릴 수 있을 때까지 계속 진행합니다.
실제 예시: 주문 상태를 확인하고, 배송을 추적하고, 문제를 해결할 수 없으면 티켓을 생성하는 고객 지원 에이전트입니다. 2-3개의 도구와 하나의 명확한 작업만으로 작동합니다.
사용 시기: 작업이 잘 정의되어 있고, 도구 세트가 작으며, 하나의 에이전트가 전체 컨텍스트를 혼란 없이 유지할 수 있을 때 사용합니다.
실패하는 경우: 계속해서 도구를 추가하고 시스템 프롬프트가 한 페이지를 넘어갈 때입니다. 이는 더 긴 프롬프트가 아닌 다른 패턴이 필요하다는 신호입니다.
패턴 2 — 다중 에이전트 순차 처리 (Multi-Agent Sequential)
전문화된 에이전트가 고정된 순서로 실행됩니다. 각 에이전트의 출력이 다음 에이전트의 입력으로 전달됩니다.
실제 예시: 계약 검토 파이프라인 — 한 에이전트가 의무 사항을 추출하고, 다음 에이전트가 위험을 식별하며, 세 번째 에이전트가 조달 부서를 위한 요약 초안을 작성합니다. 순서는 절대 변경되지 않습니다.
사용 시기: 워크플로에 명확하고 반복 가능한 단계가 있고 각 단계가 다음 단계에 필요한 것을 정확히 생성할 때 사용합니다.
실패하는 경우: 중간에 발견된 내용에 따라 순서가 실제로 변경되어야 할 때입니다. 순차적 파이프라인은 경로가 고정되어 있다고 가정합니다. 그렇지 않다면 더 동적인 것이 필요합니다.
패턴 3 — 다중 에이전트 병렬 처리 (Multi-Agent Parallel)
독립적인 하위 작업이 동시에 실행된 후 하나의 뷰로 결합됩니다.
실제 예시: 새벽 2시 프로덕션 장애. 세 개의 에이전트가 로그, 메트릭, 최근 배포를 동시에 조사합니다. 장애 중에는 1분 1초가 중요하기 때문에 순차적으로 처리하지 않습니다.
사용 시기: 하위 작업이 진정으로 독립적이고 속도가 중요할 때 사용합니다.
실패하는 경우: 작업이 실제로 서로의 결과에 의존할 때입니다. 의존적인 작업을 병렬 실행으로 강제하면 경쟁 조건과 불완전한 컨텍스트만 발생합니다.
패턴 4 — 루프 (Loop)
종료 조건이 충족될 때까지 일련의 단계를 반복합니다.
실제 예시: 지저분한 CSV 데이터를 프로파일링하고, 정리 계획을 제안하며, 품질 기준을 통과하는지 확인하고, 통과하지 못하면 재시도하는 데이터 정리 에이전트입니다. 최대 반복 횟수는 제한되어 있습니다.
사용 시기: 작업에 여러 번의 시도가 필요하고 명확하고 확인 가능한 중단 조건을 정의할 수 있을 때 사용합니다.
실패하는 경우: 신뢰할 수 있는 종료 조건이 없을 때입니다. 종료 조건이 없으면 비용이 통제 불능으로 증가하고 시스템이 종료되지 않을 수 있습니다.
패턴 5 — 검토 및 비판 (Review and Critique)
심판 에이전트가 다른 에이전트의 출력을 검토하고, 비판하며, 구체적이고 실행 가능한 피드백을 제공합니다.
실제 예시: 생성된 보고서가 별도의 "비평가" 에이전트의 검토를 받습니다. 이 에이전트는 보고서가 사람에게 전달되기 전에 약한 주장, 누락된 증거, 불명확한 섹션을 지적합니다.
사용 시기: 속도보다 품질이 중요하고, 시스템에 내장된 두 번째 의견을 원할 때 사용합니다.
실패하는 경우: 비평가 에이전트가 생성자와 동일한 사각지대를 가질 때입니다. 유사한 가정으로 훈련된 검토자는 같은 실수를 발견하지 못합니다.
패턴 6 — 반복적 개선 (Iterative Refinement)
품질 점수 임계값이 있는 피드백 루프입니다. 생성자가 기준을 넘을 때까지 계속 개선합니다.
실제 예시: 자체 초안을 브랜드 가이드라인에 따라 평가하고, 최소 품질 점수에 도달할 때까지 다시 작성하는 마케팅 카피 생성기입니다. 단순한 합격/불합격 검사가 아니라 등급별 개선입니다.
사용 시기: 출력 품질이 진정으로 가변적이고 "충분히 좋은" 수준에 측정 가능한 임계값이 있을 때 사용합니다.
실패하는 경우: 점수 함수가 모호하거나 조작 가능할 때입니다. 모델이 실제 개선 없이 자체 점수를 부풀릴 수 있다면 루프는 토큰만 낭비합니다.
패턴 7 — 코디네이터 (Coordinator)
중앙 라우팅 에이전트가 실제 요청 내용에 따라 요청을 전문화된 에이전트로 전달합니다.
실제 예시: 지원 티켓이 청구, 기술, 계정, 배송, 사기 전문가에게 라우팅됩니다. 각 에이전트는 모든 것을 알려고 하는 하나의 에이전트 대신 좁은 컨텍스트만 가집니다.
사용 시기: 다른 컨텍스트, 도구 또는 결정 논리가 필요한 진정으로 다른 요청 유형이 있을 때 사용합니다.
실패하는 경우: 라우팅 자체가 모호해질 때입니다. 요청이 하나의 범주에 깔끔하게 속하지 않으면 코디네이터가 새로운 병목 현상과 잘못된 라우팅의 원인이 됩니다.
패턴 8 — 계층적 작업 분해 (Hierarchical Task Decomposition)
루트 에이전트가 복잡한 목표를 더 작은 하위 목표로 나누고, 전문가 워커에게 위임한 후, 모든 것을 하나의 답변으로 종합합니다.
실제 예시: "내년에 진출해야 할 3개국은 어디인가?"라는 질문이 경쟁 분석, 규제 조사, 물류 타당성, 시장 규모 추정으로 분해됩니다. 각각 다른 전문가가 처리한 후 결합됩니다.
사용 시기: 문제가 한 번의 추론으로 처리하기에는 너무 광범위하지만 독립적인 전문 영역으로 깔끔하게 나눌 수 있을 때 사용합니다.
실패하는 경우: 하위 목표가 실제로 독립적이지 않을 때입니다. 작업 흐름이 실시간으로 서로 정보를 주고받아야 한다면 사전에 분해하면 그 상호 작용이 손실됩니다.
패턴 9 — 스웜 (Swarm)
여러 전문가 에이전트가 공유 토론에 기여하고, 서로의 가정에 이의를 제기하며, 퍼실리테이터가 최종 권장 사항을 종합합니다.
실제 예시: 회사가 구독 요금제를 출시해야 할까요? 연구, 엔지니어링, 재무, 지원 에이전트가 여러 라운드에 걸쳐 각자의 관점을 주장한 후 퍼실리테이터가 트레이드오프를 평가합니다.
사용 시기: 단 하나의 "올바른" 답이 없을 때입니다. 진정으로 경쟁하는 관점에 의해 형성된 합리적인 결정이 필요합니다.
실패하는 경우: 빠르고 결정적인 답변이 필요할 때입니다. 스웜은 의도적으로 느리고 탐색적입니다. 속도가 필요하다면 잘못된 도구입니다.
패턴 10 — ReAct (추론 및 행동, Reason and Act)
에이전트가 추론과 행동을 번갈아 수행합니다: 조사할 것을 결정하고, 도구를 호출하고, 결과를 관찰하고, 충분한 증거가 있는지 결정합니다.
실제 예시: "큐 프로세서가 멈춘 것 같습니다" — 에이전트가 문서를 검색하고, 서비스 상태를 확인하며, 결과를 상호 연관시킨 후에야 수정을 제안합니다. 조사 경로는 미리 정의되지 않습니다. 진행 중에 발견하는 내용에 따라 달라집니다.
사용 시기: 답변으로 가는 경로를 사전에 계획할 수 없을 때 사용합니다. 각 단계에서 무엇이 드러나는지에 따라 달라집니다.
실패하는 경우: 조사가 수렴되지 않고 오래 지속될 때입니다. 항상 추론-행동 주기 수를 제한해야 합니다. 그렇지 않으면 무한 탐색의 위험이 있습니다.
패턴 11 — 사람이 개입하는 루프 (Human-in-the-Loop)
에이전트가 조사하고 권장하지만, 위험하거나 모호한 사항에 대한 최종 결정은 사람이 내립니다.
실제 예시: 환불 승인 — 위험이 낮고 명확한 사례는 자동화됩니다. 높은 금액, 사기 신호 또는 정책 예외 사항은 최종 처리 전에 사람의 검토를 위해 일시 중지됩니다.
사용 시기: 결정이 실제 재정적, 법적 또는 평판적 위험을 수반하고 완전한 자동화가 아직 허용되지 않을 때 사용합니다.
실패하는 경우: 이것을 아키텍처적 기능이 아닌 단순한 UI 기능으로 취급할 때입니다. 지속적인 상태, 검토자 할당, 시간 초과 처리, 에스컬레이션 경로가 필요합니다. 단순한 "일시 중지" 버튼만으로는 부족합니다.
패턴 12 — 계획 및 실행 (Plan-and-Execute)
플래너 에이전트가 어떤 조치도 취해지기 전에 완전한 구조화된 계획을 사전에 생성합니다. 이 계획은 검토 및 수정이 가능합니다. 그런 다음 실행자가 단계를 수행합니다.
실제 예시: "워커 팟을 10개의 인스턴스에서 20개의 인스턴스로 크기 조정하고, 큐가 비는지 확인하고, 런북을 업데이트하세요." 실행이 시작되기 전에 전체 계획을 볼 수 있습니다. ReAct에서는 경로가 단계별로 드러나는 것과 다릅니다.
사용 시기: 어떤 조치가 취해지기 전에 계획을 검토하거나 승인할 수 있도록 하고 싶을 때 사용합니다. 실제 결과가 수반되는 운영에 중요합니다.
실패하는 경우: 환경이 계획이 실행되는 것보다 빠르게 변경될 때입니다. 쓸모없는 계획을 맹목적으로 실행하는 것은 계획이 없는 것보다 더 나쁩니다.
패턴 13 — 반성 (Reflexion)
에이전트가 자신의 실패를 평가하고, 무엇이 잘못되었는지 반성하며, 그 기억을 다음 시도에 활용합니다.
실제 예시: 코드 생성 에이전트가 스크립트를 작성하고, 실행 중에 실패합니다. 에이전트가 실제 오류를 분석하고, 수정해야 할 사항을 기록한 후 재시도합니다. 매 시도마다 같은 실수를 반복하는 대신 더 똑똑해집니다.
사용 시기: 실패가 유익하고 자기 수정이 다음 시도를 진정으로 개선할 때 사용합니다.
실패하는 경우: 실패 모드가 무작위적이거나 서로 관련이 없을 때입니다. Reflexion은 배울 실제 패턴이 있을 때만 도움이 됩니다.
패턴 14 — 커스텀 로직 (Custom Logic)
하이브리드 방식: 결정론적 코드가 절대 틀리면 안 되는 규칙을 처리하고, 모델이 판단, 초안 작성, 예외 처리를 담당합니다.
실제 예시: 구매 확인과 사기 검사가 하드코딩된 결정론적 규칙으로 실행되는 환불 워크플로입니다. 모델에 절대 위임되지 않습니다. 반면 고객 응답 초안 작성과 라우팅 권장 사항은 에이전트가 처리합니다.
사용 시기: 워크플로에 법적 또는 재정적 결과를 수반하는 실제 분기 로직이 있고, 결정론적인 것과 유연한 것 사이의 경계를 정확하게 설정해야 할 때 사용합니다.
실패하는 경우: 팀이 경계를 모호하게 하고 모델이 하드코딩된 규칙이어야 할 결정을 내리도록 할 때입니다. 자격, 권한, 자금 이동은 절대 모델의 단독 판단에 맡겨져서는 안 됩니다.
패턴 15 — 이벤트 기반 에이전트 (Event-Driven Agent)
에이전트는 요청을 기다리지 않습니다. 이벤트 스트림을 구독하고 조건이 트리거되는 즉시 행동합니다.
실제 예시: 의심스러운 거래 이벤트가 발생하는 즉시 반응하는 사기 탐지 에이전트입니다. 지원 티켓이 결국 접수될 때까지 기다리면 이미 피해가 발생한 후입니다.
사용 시기: 타이밍이 무엇보다 중요하고, 사람의 요청을 기다리는 것이 행동할 기회를 놓치는 것을 의미할 때 사용합니다.
실패하는 경우: 트리거 조건이 잘못 정의되었을 때입니다. 모호한 트리거가 있는 시끄러운 이벤트 스트림은 시스템이 계속해서 거짓 경보를 울리거나, 더 나쁘게는 실제 신호를 놓치게 만듭니다.
패턴 선택 — 과장된 말이 아닌 불확실성의 성격에 맞추세요
올바른 패턴은 작업에 존재하는 불확실성의 성격과 일치해야 합니다.
→ 어떤 도구를 사용할지 불확실함 → 단일 에이전트 또는 ReAct
→ 어디로 라우팅할지 불확실함 → 코디네이터
→ 품질이 불확실함 → 검토 및 비판 또는 반복적 개선
→ 실행 경로가 불확실함 → 계획 및 실행 또는 ReAct
→ 스스로 수정하는 방법이 불확실함 → 반성 또는 루프
→ 비즈니스 리스크가 불확실함 → 사람이 개입하는 루프 또는 커스텀 로직
→ 문제 구조가 불확실함 → 계층적 분해 또는 스웜
→ 요청을 기다릴 수 없음 → 이벤트 기반 에이전트
작업에 신뢰할 수 있는 하나의 도구 호출만 필요하다면 스웜이 단일 에이전트보다 더 진보된 것은 아닙니다.
계획이 3단계만에 쓸모 없어진다면 계획 및 실행이 ReAct보다 업그레이드된 것은 아닙니다.
가장 안정적인 프로덕션 시스템은 가장 자율적인 시스템이 아닙니다.
자율성을 가치를 창출하는 곳에 정확히 배치하고, 다른 모든 곳에서는 제한합니다.
프로덕션 에이전트 시스템을 위한 10가지 규칙
- 작동하는 가장 작은 패턴부터 시작하세요. 깨끗한 도구 계약을 가진 단일 에이전트가 약한 계약을 가진 다중 에이전트 시스템보다 낫습니다.
- 도구 설명을 계약서처럼 작성하세요. 모델은 도구가 무엇을 하는지 설명을 통해서만 알 수 있습니다. 여러분의 의도는 모릅니다.
- 요청당 반복 횟수, 도구 호출 횟수 및 지출을 제한하세요. 예산 제한이 없는 에이전트는 청구서에 나타날 때까지 기다리는 책임입니다.
- 전체 액션 트레이스를 기록하세요. 도구 호출, 인수, 출력, 최종 결정이 포함됩니다. 이것 없이는 장애 조사는 추측에 불과합니다.
- 되돌릴 수 없는 작업은 결정론적 검사 또는 사람의 승인 뒤에 두세요. 모델이 자금 이동이나 프로덕션 변경 전의 유일한 관문이 되게 하지 마세요.
- 행복한 경로뿐만 아니라 실제 실패 사례로 평가하세요. 행복한 경로의 정확성은 프로토타입입니다. 엣지 케이스의 정확성이 제품입니다.
- 시스템 프롬프트를 읽을 수 없게 되기 전에 책임별로 프롬프트를 분리하세요. "하지만 Y일 때는 X를 하지 마세요"라는 말이 프롬프트에 들어가기 시작하면 에이전트가 두 가지 일을 하고 있다는 의미입니다.
- 다중 에이전트 시스템을 분산 시스템으로 취급하세요. 부분 실패, 시간 초과, 재시도, 관찰 가능성은 선택 사항이 아닙니다.
- 모델 검토는 결정론적 검증을 대체하지 않습니다. 판정자를 사용하여 품질을 향상시키세요. 테스트와 권한 검사를 사용하여 정확성을 강제하세요.
- 더 간단한 패턴을 선호하세요. 단순함이 항상 더 좋기 때문이 아니라, 절약한 복잡성 예산을 더 나은 도구, 더 나은 프롬프트, 더 나은 평가에 사용할 수 있기 때문입니다.
이상 15가지 패턴이 전부입니다.
대부분의 팀은 잘못된 패턴을 선택했기 때문에 실패하지 않습니다.
자신이 실제로 어떤 불확실성을 해결하고 있는지 묻지 않았기 때문에 실패합니다.
패턴을 선택하세요. 문제의 성격에 맞추세요. 자율성이 그 자리를 정당화하지 못하는 곳에 추가하지 마세요.
도움이 되셨다면:
→ 여러분의 팀에서 에이전트를 구축하는 모든 엔지니어와 공유하려면 리포스트하세요
→ 더 많은 분석 내용을 보려면 @sairahul1을 팔로우하세요
→ 북마크하세요 — 새로운 에이전트 프로젝트를 시작할 때마다 다시 찾아보게 될 것입니다
저는 AI, 제품 구축, 그리고 여러분 없이도 잘 작동하는 시스템에 대해 글을 씁니다.
