엔터프라이즈 AI를 위한 컨텍스트 엔지니어링(Context Engineering), 파트 3: 프로덕션 환경에서 생존하는 멀티 에이전트 아키텍처

원문은 PrepStack에 게시되었습니다.

프로덕션 환경에 있는 대부분의 "AI 에이전트(AI agents)"는 모든 도구와 10,000 토큰 분량의 프롬프트를 가진 하나의 거대한 에이전트입니다. 이는 루프(loop)에 빠지거나, 정체되거나, 확신에 찬 헛소리를 내뱉으며 배포됩니다. 이것은 저의 컨텍스트 엔지니어링 (Context Engineering) 시리즈의 파트 3입니다.

재정의 (The reframe)

모든 도구를 가진 단일 에이전트는 "하나의 스마트한 시스템"이 아닙니다. 그것은 상태(state)도, 가드(guard)도, 탈출구(exit)도 없는 상태 머신(state machine)일 뿐입니다. 이것은 더 나은 프롬프트로 해결할 수 있는 문제가 아닙니다. 구조로 해결해야 합니다: 모델이 결정하고, 그래프(graph)가 통제합니다.

아키텍처 (The architecture)

ASP.NET Core가 오케스트레이션(orchestration), 예산(budgets), 거버넌스(governance)를 담당하며, Python LangGraph 서비스가 에이전트 그래프(agent graph)를 실행합니다:

1. 관리자(Supervisor) → 전문 작업자(specialized workers) — 저렴한 관리자(gpt-4o-mini)가 검색기(retriever), 분석가(analyst), 작성자(writer), 비평가(critic)에게 라우팅합니다.
2. 모델 라우팅 (Model routing) — 분석가만이 고가의 모델을 사용하며, 나머지는 mini 모델에서 실행됩니다.
3. 타입화된 핸드오프 (Typed hand-offs) — 작업자들은 산문(prose)이 아닌 구조화된 데이터(Pydantic + C# records)를 전달합니다.
4. 제한된 루프 + 비평가 게이트 (Bounded loops + a critic gate) — 엄격한 단계별 예산(step budget)을 설정하며, 비평가가 답변이 근거에 기반했는지(grounded) 검증하기 전까지는 완료될 수 없습니다.
5. 실패 격리가 포함된 병렬 처리 (Parallelism with failure isolation) — 개별 페치(fetch) 타임아웃을 포함한 동시 검색을 수행합니다. 하나의 느린 도구는 전체 실행을 중단시키는 대신 최선 노력(best-effort) 방식으로 성능이 저하됩니다.
6. C# 경계 (The C# boundary) — 전역 실행 시간 예산(wall-clock budget), 비용 상한(cost cap), 프롬프트 인젝션 차단(prompt-injection screen)을 담당합니다.

결과 (The results)

지표 (Metric)	이전 (Before)	이후 (After)
p95 지연 시간 (latency)	4.2s	1.8s
...

세 가지 습관: 예산 없는 작업자 없음, 타입 없는 핸드오프 없음, 판결(verdict) 없는 완료 없음.

모든 C# 및 Python 코드가 포함된 전체 분석 내용을 PrepStack에서 확인하세요:
https://prepstack.co.in/blog/context-engineering-enterprise-genai-part-3-multi-agent-architecture