에이전틱 엔지니어(Agentic Engineer)가 반드시 알아야 할 8가지 패턴 (그리고 왜 대부분의 팀은 단 두 가지만 사용하는가)

현재 대부분의 기업용 AI 프로그램 내부에서는 조용한 문제가 전개되고 있습니다. 팀들은 "에이전틱(agentic)" 시스템을 구축하고 있지만, 대부분은 RAG와 ReAct 기반의 동일한 시스템을 반복해서 만들고 있습니다. 질문에 답하는 검색 증강 생성(RAG) 에이전트, 그리고 프롬프트가 주어지면 도구를 호출하는 ReAct 루프. 둘 다 유용하고 잘 알려져 있습니다. 하지만 둘 다 에이전틱 엔지니어링(agentic engineering)이 실제로 할 수 있는 능력의 표면만을 겨우 긁고 있을 뿐입니다. 저는 지난 1년 동안 금융 서비스를 위한 GenAI 기술 참조 아키텍처(Technical Reference Architecture)를 구축하며, 에이전틱 AI가 데모 영상에서처럼 작동하는 방식이 아니라 복잡한 규제 기업 내부에서 실제로 어떻게 작동하는지를 매핑해 왔습니다. 그 과정에서 8가지의 뚜렷한 에이전틱 애플리케이션 패턴이 도출되었습니다. 동일한 것의 8가지 변형이 아닙니다. 에이전트가 추론하고, 행동하며, 협업하는 진정으로 다른 8가지 방식입니다. 그리고 제가 참여하는 거의 모든 프로젝트에서 팀들은 패턴 1과 2에 머물러 있습니다. 그들이 놓치고 있는 것들은 다음과 같습니다.

패턴 1 — RAG 증강 에이전트 (RAG-Augmented Agent)
기본적인 시작점입니다. 모델을 데이터에 기반하게(ground) 하여 환각(hallucination)을 줄이고 질문에 답합니다. 대부분의 팀이 여기서 시작하며, 여기서 멈춥니다.

패턴 2 — ReAct (Reason + Act)
에이전트가 단계별로 추론하고, 도구를 선택하고, 결과를 관찰하며 루프를 돕니다. 대부분의 챗봇 및 코파일럿(copilot) 구현이 여기에 해당합니다. 강력하지만, 실제로는 단일 에이전트(single-agent), 단일 턴(single-turn) 방식입니다.

패턴 3 — 계획 및 실행 (Plan-and-Execute)
에이전트가 계획과 실행을 분리합니다. 플래너(planner)가 복잡한 목표를 하위 작업(subtasks)으로 분해하면, 실행기(executor)가 이를 독립적으로 수행합니다. 에이전틱 AI가 진정으로 자율적으로 느껴지기 시작하는 지점입니다. 대부분의 팀은 아직 여기에 도달하지 못했습니다.

패턴 4 — 성찰 / 자기 비판 (Reflexion / Self-Critique)
에이전트가 자신의 출력을 검토하고, 루브릭(rubric)에 따라 점수를 매기며, 응답하기 전에 반복(iterate)합니다. 이는 단순히 답만 하는 것이 아니라 스스로 개선하는 에이전트를 만드는 방법입니다. 품질, 일관성, 그리고 감사 가능성(auditability)이 중요한 규제 환경에서 매우 중요합니다.

패턴 5 — 멀티 에이전트 오케스트레이션 (Multi-Agent Orchestration): 오케스트레이터 에이전트(orchestrator agent)가 작업을 분해하고, 각각 고유한 도구(tools), 메모리(memory), 도메인 집중 분야를 가진 전문 서브 에이전트(specialist sub-agents)에게 위임합니다. 이는 진정한 엔터프라이즈 규모의 자동화를 실현하는 패턴입니다. 또한 소유권(ownership), 관찰 가능성(observability), 제어(control)에 관한 대부분의 엔터프라이즈 아키텍처 가정을 깨뜨리는 패턴이기도 합니다.

패턴 6 — 휴먼 인 더 루프 (Human-in-the-Loop, HiTL) 에이전트: 에이전트가 정의된 신뢰도 또는 리스크 임계값까지 자율적으로 실행한 후, 다음 단계로 넘어가기 전에 인간 검토자에게 업무를 인계합니다. 이는 단순한 대비책(fallback)이 아니라, 의도적인 설계 선택입니다. 금융 서비스 분야에서 이는 선택 사항이 아니라 규제 준수 태세(regulatory posture)입니다. 아키텍처 측면에서의 질문은 인간의 게이트(human gate)를 어디에 배치할 것인가이지, 필요 여부가 아닙니다.

패턴 7 — 이벤트 기반 에이전틱 파이프라인 (Event-Driven Agentic Pipeline): 에이전트가 인간의 프롬프트(prompt)가 아닌 이벤트(transaction, 문서 도착, 임계값 초과 등)에 의해 트리거됩니다. 시스템이 능동적(proactive)으로 변합니다. 이 지점에서 에이전틱 AI는 단순한 도구(tooling)를 넘어 인프라(infrastructure)처럼 동작하기 시작합니다. 그리고 이는 멱등성(idempotency), 장애 처리(failure handling), 에이전트 생명주기 관리(agent lifecycle management)에 대한 완전히 다른 접근 방식을 요구합니다.

패턴 8 — 연합 / 에코시스템 에이전트 (Federated / Ecosystem Agent): 조직의 경계를 넘어 파트너 API, 제3자 데이터 또는 다른 기관의 에이전트 네트워크와 상호작용하며 작동하는 에이전트입니다. 은행 업무를 예로 들면, 오픈 파이낸스(open finance), 에코시스템 파트너십, 실시간 상호운용성(interoperability)을 떠올려 보십시오. 이것이 바로 최전선(frontier)입니다. 대부분의 기업은 아직 이를 지원할 거버넌스 아키텍처(governance architecture)를 갖추지 못했지만, 이는 누구의 계획보다 빠르게 다가오고 있습니다.

그렇다면 왜 대부분의 팀은 단 두 가지만 사용할까요? 부분적으로는 도구(tooling) 때문입니다. LangChain, AutoGen 및 유사한 프레임워크들은 패턴 1과 2를 매우 쉽게 만드는 반면, 패턴 5~8은 진정으로 어렵게 만듭니다. 부분적으로는 리스크 수용도(risk appetite) 때문입니다. 그에 걸맞은 관찰 가능성 스택(observability stack)이 없다면 자율 실행은 공포스럽습니다. 하지만 무엇보다도, 저는 그것이 아키텍처 문제라고 생각합니다. 팀들은 자신이 해결하려는 문제의 유형(class of problem)이 무엇인지 먼저 묻지 않은 채 에이전트를 구축하고 있습니다.

당신이 선택하는 패턴은 메모리(memory)를 설계하는 방식, 상태(state)를 처리하는 방식, 감사 가능성(auditability)을 위한 계측(instrumentation) 방식, 그리고 신뢰(trust)를 거버넌스(governance)하는 방식 등 전체적인 다운스트림 아키텍처(downstream architecture)를 결정합니다. 초기에 잘못된 패턴을 선택하면 이를 되돌리는 데 막대한 비용이 듭니다. 제가 엔지니어링 팀 내에서 일어나길 바라는 대화는 "에이전트(agents)를 사용해야 할까요?"가 아닙니다. 그 논의는 이미 지나간 배와 같습니다. 대신 "어떤 패턴이 이 문제에 적합하며, 이를 안전하게 실행할 수 있는 아키텍처적 성숙도(architectural maturity)를 갖추었는가?"여야 합니다. 이 질문이 장난감을 만드는 팀과 인프라(infrastructure)를 구축하는 팀을 가릅니다. 저는 8가지 패턴 전체를 다루는 7계층 구현 프레임워크와 신뢰/거버넌스 모델을 포함하여, 금융 서비스 분야의 에이전틱 AI(agentic AI)를 위한 참조 아키텍처(reference architecture)를 개발해 왔습니다. 제 생각을 공유하고 싶으니, 댓글을 남기거나 직접 연락해 주세요. 원문은 https://www.linkedin.com 에서 게시되었습니다. — Ravi Shah는 에이전틱 엔지니어링(agentic engineering)과 금융 서비스 혁신에 대해 글을 씁니다. Hub: https://shahravir.github.io · LinkedIn · GitHub · DEV