프로덕션(Production) 환경에서 작동하는 AI 에이전트를 구성하는 요소는 데모(Demo)에서 보여지는 것과는 다릅니다. 데모는 '해피 패스(Happy path, 정상 경로)'를 보여줍니다. 프로덕션은 모든 '언해피 패스(Unhappy paths, 비정상 경로)'의 합이며, 아키텍처(Architecture)는 시스템이 이러한 경로들을 견뎌낼 수 있을지를 결정하는 핵심입니다.

이 포스트는 핵심 구성 요소, 이들이 연결되는 방식, 각 요소의 실패 모드(Failure modes), 그리고 팀이 실제 데이터 볼륨을 통해 학습한 후의 실제 아키텍처가 어떻게 변하는지를 설명합니다.

핵심 루프 (The central loop)

모든 AI 에이전트는 프레임워크(Framework)나 구현 방식에 관계없이 하나의 루프(Loop)를 실행합니다: 입력을 받고, 다음에 할 일을 결정하고, 행동을 취하고, 결과를 관찰하며, 작업이 완료되거나 중단 조건에 도달할 때까지 이 과정을 반복합니다. 프로덕션 에이전트의 복잡성은 각 단계에서 예상치 못한 결과가 발생할 때 이 루프가 이를 어떻게 처리하느냐에 거의 전적으로 달려 있습니다.

해피 패스는 쉽습니다. 프로덕션은 모든 언해피 패스의 합입니다. 도구(Tool)의 오류, 예상치 못한 컨텍스트(Context), 또는 모호한 목표를 처리할 아키텍처가 없는 에이전트는 테스트 세트가 결코 예측하지 못한 방식으로 실패할 것입니다.

오케스트레이터 (The orchestrator)

오케스트레이터는 루프를 실행하는 구성 요소입니다. 이는 작업의 현재 상태를 유지하고, 모델(Model)을 호출할 시점을 결정하며, 구성된 컨텍스트를 전달하고, 모델의 출력(Output)을 분석하며, 다음 행동을 라우팅(Routing)합니다. 대부분의 에이전트 프레임워크는 오케스트레이터를 제공합니다. 프레임워크의 추상화(Abstraction)가 가치보다 더 많은 마찰을 일으키는 유스케이스(Use case)의 경우, 직접 오케스트레이터를 구축하는 것이 적절합니다.

오케스트레이터는 대부분의 프로덕션 버그가 발생하는 지점입니다. 에이전트가 잘못된 행동을 취했을 때, 발생한 일을 재구성하기 위해 필요한 것은 바로 오케스트레이터의 로그(Log)입니다. 오케스트레이터에 계측(Instrumentation)이 되어 있지 않다면, 프로덕션의 실패를 디버깅(Debugging)하는 것은 고고학 작업과 다를 바 없습니다.

흔한 실패 방식 중 하나는 오케스트레이터(Orchestrator)가 이미 무엇을 시도했는지에 대한 명시적인 상태(State)를 가지고 있지 않은 경우입니다. 에이전트는 루프(Loop)에 빠져, 실패할 때마다 에스컬레이션(Escalation)하거나 중단하지 않고 동일한 인자(Arguments)로 동일한 도구를 호출합니다. 이는 토큰(Tokens)을 소모하고, 지연 시간(Latency)을 발생시키며, 심각한 경우 현실 세계에서 반복적인 부작용(Side effects)을 초래합니다.

도구와 액션 (Tools and Actions)

에이전트는 모델이 호출하는 법을 학습한, 정의된 입력(Inputs)과 출력(Outputs)을 가진 함수인 도구(Tools)를 호출함으로써 액션(Actions)을 취합니다. 도구는 API를 호출하거나, 데이터베이스 쿼리(Database query)를 실행하거나, 파일을 읽거나, 이메일을 보내거나, 또는 다른 모델을 호출할 수 있습니다. 각 도구는 잠재적인 실패 지점(Point of failure)입니다. 만료될 수 있고, 에러를 반환할 수 있으며, 예상치 못한 데이터를 반환하거나, 잘못된 인자로 호출될 수 있습니다.

프로덕션급 에이전트 아키텍처는 어떤 도구가 실패했을 때 어떤 일이 일어날지를 정의합니다: 재시도(Retry), 에스컬레이션(Escalate), 중단(Stop), 또는 불완전한 정보로 계속 진행(Proceed)할지 여부입니다. 이러한 정책은 암시적(Implicit)이 아니라 명시적(Explicit)이어야 합니다. 무한히 시도하는 에이전트는 위험합니다. 첫 번째 에러에서 바로 멈추는 에이전트는 쓸모가 없습니다. 적절한 지점은 액션의 중요도와 추가 시도마다 발생하는 비용에 따라 달라집니다.

각 도구의 스키마(Schema) 또한 똑같이 중요합니다. 모호한 스키마는 빈번하게 잘못된 인자를 생성합니다. 예시와 정의된 타입(Types)이 포함된 정밀한 스키마는 모델의 변경 없이도 호출 에러를 줄여줍니다. 이는 컨텍스트 엔지니어링(Context engineering)이 프롬프트(Prompt)를 위해 수행하는 작업의 도구 버전이라고 할 수 있습니다.

메모리과 상태 (Memory and State)

에이전트는 여러 단계의 작업을 완료하기 위해 메모리(Memory)가 필요합니다. 단기 메모리(Short-term memory)는 단일 실행 내에서의 대화 컨텍스트(Context)입니다. 장기 메모리(Long-term memory)는 실행 간에 지속되는 정보로, 데이터베이스에 저장되어 관련이 있을 때 검색(Retrieve)됩니다. 작업 메모리(Working memory)는 에이전트가 작업 중에 구축하는 구조화된 상태(Structured state)로, 후속 액션에 정보를 제공하는 중간 결과물들입니다.

시스템에 필요한 메모리의 유형은 작업에 따라 달라집니다. 단일 실행 과정에서 단일 문서를 처리하는 에이전트는 장기 메모리 (Long-term memory)가 필요하지 않습니다. 반면, 몇 주에 걸쳐 고객의 컨텍스트 (Context)를 유지해야 하는 에이전트는 구조화된 지속성 (Structured persistence)이 필요하며, 지금까지 발생한 모든 일을 컨텍스트 창 (Context window)에 가득 채우지 않으면서도 관련 히스토리를 가져올 수 있는 검색 전략 (Retrieval strategy)이 필요합니다.

전형적인 실패 모드: 에이전트가 긴 실행 과정 동안 컨텍스트 창에 상태 (State)를 계속 누적하면, 컨텍스트가 유용성을 넘어설 정도로 커지게 되고, 아무런 에러 메시지 없이 응답 품질이 저하됩니다. 해결책은 상태를 명시적으로 관리하고, 필요할 때 히스토리를 압축하며, 압축 과정에서 살아남아야 할 것과 폐기해도 되는 것을 분리하는 것입니다.

계획 (Planning)의 문제

복잡한 작업을 수행하기 위해 에이전트는 행동하기 전에 계획을 세워야 합니다. 계획 (Planning)이란 목표를 단계별로 분해하고, 의존성을 식별하며, 액션 (Actions)의 순서를 정하는 것을 의미합니다. 계획 없이 행동하는 에이전트는 해당 행동이 올바른지 판단할 충분한 정보를 얻기도 전에 너무 일찍 되돌릴 수 없는 행동을 취하는 경향이 있습니다.

잘못된 계획은 수집하지 않은 정보가 필요하다는 사실을 뒤늦게 깨닫거나, 선언된 목표를 달성할 수 없는 단계들을 따라가는 에이전트를 만들어냅니다. 로그상으로는 작업이 완료된 것처럼 보이지만, 실제 세상에서의 결과는 틀렸거나 불완전합니다.

좋은 계획에는 에이전트가 다음 단계로 넘어가기 전에 중간 결과물을 검증하는 체크포인트 (Checkpoints)가 포함됩니다. 문서에서 데이터를 추출한 후 외부 시스템에 기록하는 에이전트는 기록한 후가 아니라, 기록하기 전에 추출 내용을 검증해야 합니다. 잘못된 기록을 다시 수행하는 비용은 항상 추가적인 검증 단계를 거치는 비용보다 큽니다.

평가 및 모니터링 (Evaluation and monitoring)

테스트에서 잘 작동하는 에이전트라도 테스트 세트에 없었던 이유로 인해 프로덕션(Production) 환경에서 실패할 수 있습니다. 해결책은 인스트루멘테이션(Instrumentation)입니다. 즉, 모든 모델 호출, 모든 도구 호출(Tool invocation)과 그 결과, 모든 결정 지점 및 최종 결과를 기록하는 것입니다. 이 로그는 실패를 진단하는 데 필요한 핵심 요소입니다. 로그가 없다면 프로덕션 에이전트의 실패를 디버깅하는 것은 고고학 작업과 다를 바 없습니다.

실행 로그 외에도, 프로덕션 에이전트는 실제 샘플을 대상으로 실행되는 지속적인 평가(Evals)가 필요합니다. 초기 테스트 세트는 출시 전 팀이 상상했던 케이스들을 포착합니다. 하지만 출시 후에 나타나는 케이스들은 서로 다르며, 종종 더 어렵습니다. 실제 트래픽에 맞춰 업데이트되지 않는 평가는 빠르게 노후화됩니다.

모니터링 측면은 AI 관측성 (AI observability)에서 다룹니다.

가드레일 (Guardrails) 및 중단 조건 (Stopping conditions)

실제 세계에서 행동을 취할 수 있는 에이전트는 명시적인 승인 없이 할 수 있는 일을 제한하는 가드레일(Guardrails)이 필요합니다. 이메일을 보낼 수 있는 에이전트가 임의의 외부 주소로 메일을 보낼 수 있어서는 안 됩니다. 데이터베이스 레코드를 수정할 수 있는 에이전트는 접근할 수 있는 테이블의 범위(Scope)에 제한이 있어야 합니다. 정의된 가드레일이 없다면 에이전트가 할 수 있는 일의 한계는 도구가 허용하는 범위가 되며, 이는 보통 필요 이상으로 매우 넓습니다.

중단 조건(Stopping conditions) 또한 똑같이 중요합니다. 에이전트가 단순히 작업을 완료해야 할 때뿐만 아니라, 언제 멈추고 사람에게 넘겨야 하는지를 정의하십시오. 명확한 중단 조건이 없는 에이전트는 에스컬레이션(Escalation, 상급자 보고)이 올바른 조치인 상황을 포함하여 모든 작업을 완수하려고 시도할 것입니다. 더 넓은 주제인 AI 가드레일 (AI guardrails)에서 이 주제를 다룹니다.

실제 아키텍처의 모습

우리가 협업하는 한 기업의 프로덕션 (Production) 에이전트는 고객 온보딩 (Onboarding) 문서를 처리합니다. 오케스트레이터 (Orchestrator)는 문서 업로드 이벤트를 수신하고 컨텍스트 (Context)를 구성합니다: 문서 내용, CRM의 고객 기록, 그리고 RAG (Retrieval-Augmented Generation)를 통해 검색된 관련 정책 규칙 등이 포함됩니다.

모델은 주요 필드에 대한 구조화된 추출 (Structured Extraction)과 필요한 후속 조치 목록을 생성합니다. 각 조치에 대해 오케스트레이터는 적절한 도구 (Tool)를 호출하고, 오류를 기록하여 인간 검토 큐 (Human Review Queue)로 라우팅함으로써 실패를 처리하며, 완료 상태를 추적합니다. 에이전트는 약 70%의 사례에서 자율적으로 작동합니다. 나머지 30%는 에이전트의 출력물을 사전 채워진 초안 (Pre-filled Draft)으로 활용하여 인간의 검토를 거칩니다.

이러한 분할은 계획된 것이 아니었습니다. 이는 에이전트가 일관되게 성공하는 사례와 일관되게 실패하는 사례가 무엇인지 보여주는 3주간의 실제 트래픽 (Real Traffic) 결과였습니다. 제대로 작동하는 아키텍처는 항상 첫 번째 배포 (Deploy) 전에 설계된 것이 아니라, 실제 볼륨 (Volume)이 가르쳐준 바에 따라 조정된 아키텍처입니다.

원문은 studiolabsai.com에 게시되었습니다. Studio Labs는 엔터프라이즈 팀을 위한 프로덕션 AI를 구축합니다. 상담 예약하기.