프로덕션에서 무너지지 않는 에이전트 시스템 설계

인상적인 데모에서 취약한 프로덕션 에이전트로

에이전트 시스템은 LLM이 단순히 프롬프트에 답하는 것을 넘어 다음에 무엇을 할지 결정하는 애플리케이션입니다: 어떤 도구를 호출할지, 어떤 데이터를 가져올지, 어떤 단계를 실행할지, 언제 "완료"로 간주할지. 이들은 모델, 도구 집합(API, DB, 서비스), 계획/실행 루프, 그리고 이를 연결하는 인프라를 결합합니다.

데모에서는 마법처럼 보입니다: 에이전트가 계획을 세우고, 몇 개의 도구를 호출해 완벽한 결과를 반환하죠. 해피 패스는 짧고, 지연은 낮으며, 동시에 실패가 발생하지 않습니다.

데모가 작동하고 프로덕션이 깨지는 이유

실제 워크로드에서는 같은 에이전트가 데모가 보지 못한 방식으로 스트레스받습니다:

• API가 타임아웃되거나 부분 데이터를 반환하거나 계약이 변경됩니다.
• 여러 요청이 공유 자원을 두고 경쟁하며 상태를 훼손합니다.
• 장기 대화가 메모리를 부풀려 컨텍스트 한도를 초과합니다.
• 미묘한 모델 실수가 여러 도구 호출을 거치며 누적됩니다.

결과는 재현하기 어려운 불안정한 동작, 조용한 데이터 손상, 가끔씩 멈추거나 무한 루프에 빠지는 사용자 흐름입니다.

실제 비즈니스 영향

불안정한 에이전트는 단순한 "즐거움"을 해치지 않습니다. 이들은:

• 인시던트와 온콜 페이지를 유발합니다.
• 다운스트림 시스템에 잘못된 답을 흘려보냅니다.
• 사용자 신뢰를 잠식합니다: 사람들은 조용히 기능을 신뢰하지 않게 됩니다.
• 재시도와 무한 루프로 클라우드 비용을 불립니다.

이 가이드가 다루는 내용

이 글은 "더 나은 프롬프트"가 아니라 엔지니어링 패턴에 관한 것입니다. 우리는 상태 머신, 명시적 도구 계약, 재시도 및 실패 처리 전략, 메모리와 동시성 제어, 그리고 로드 시 에이전트 시스템을 예측 가능하게 만드는 관찰성 패턴을 살펴봅니다. 무대 위에서만 인상적인 것이 아니라 실무에서 신뢰할 수 있는 설계를 목표로 합니다.

대부분의 에이전트 아키텍처가 스케일에서 깨지는 이유

대다수 에이전트 시스템은 단일 해피 패스 데모에서는 괜찮아 보입니다. 트래픽, 도구, 엣지 케이스가 함께 오면 실패합니다.

취약한 동작: 루프, 정지, 부분 작업, 조용한 오류

순진한 오케스트레이션은 모델이 한두 번의 호출에 "올바른 것"을 할 것이라고 가정합니다. 실제 사용에서는 다음 패턴이 반복됩니다:

• 루프: 에이전트가 완료나 실패를 인식하지 못해 계속 재계획하거나 같은 도구를 반복 호출합니다.
• 정지(스톨): 에이전트가 타임아웃 없이 도구나 하위 작업을 기다려 사용자 세션을 대기 상태로 둡니다.
• 부분 작업: 에이전트가 워크플로의 절반만 완료합니다(예: 이메일 초안은 작성했지만 전송하지 않음).
• 조용한 오류: 도구가 실패하거나 스키마가 불일치하지만 에이전트는 그럴듯한 답을 자신있게 반환해 누락되거나 잘못된 데이터를 낸다.

명시적 상태와 종료 조건이 없으면 이러한 동작은 불가피합니다.

숨겨진 비결정성 및 도구의 불안정성

LLM 샘플링, 지연 변동성, 도구 타이밍은 숨겨진 비결정성을 만듭니다. 같은 입력이 다른 분기를 지나거나, 다른 도구를 호출하거나, 도구 결과를 다르게 해석할 수 있습니다.

스케일에서 도구 문제는 지배적입니다:

• 상류 API 및 DB의 타임아웃과 불안정성
• 도구 계약과 실제 반환 값 사이의 스키마 표류
• 에이전트가 다루지 못한 일관되지 않은 오류 포맷

이들 각각은 스푸리어스 루프, 재시도, 또는 잘못된 최종 답으로 전환됩니다.

동시성이 엣지 케이스와 제품 불일치를 증폭시킴

10 RPS에서는 드물게 일어나는 문제가 1,000 RPS에서는 지속적으로 발생합니다. 동시성은 다음을 드러냅니다:

• 공유 상태나 캐시에서의 레이스 컨디션
• 소모된 레이트 리밋으로 인한 연쇄적 도구 실패
• 단일 종속성 문제로 트리거되는 쓰나미 같은 재시도

제품팀은 종종 결정론적 워크플로, 명확한 SLA, 감사 가능성을 기대합니다. 제약 없이 둔 에이전트는 확률적, 최선의 노력 행동을 제공하며 보장이 약합니다.

이 불일치를 무시하고 에이전트를 전통적 서비스처럼 취급하면, 신뢰성이 가장 중요할 때 예측 불가능해집니다.

프로덕션급 에이전트 시스템을 위한 설계 원칙

프로덕션에 적합한 에이전트는 "똑똑한 프롬프트"에 관한 것이 아니라 규율 있는 시스템 설계에 관한 것입니다. 이를 이해하기 쉬운 방식은: 에이전트를 가끔 LLM을 호출하는 작은 예측 가능한 머신으로 생각하는 것입니다. 신비한 LLM 덩어리가 당신의 시스템을 가끔 건드리는 것이 아닙니다.

무엇이 에이전트를 프로덕션 준비 상태로 만드는가?

네 가지 속성이 가장 중요합니다:

• 안전성(Safety): 에이전트는 데이터 접근, 부작용, 사용자 약속에 대한 제약을 준수해야 합니다. 명시적 권한, 도구의 가드레일, 신뢰할 수 없는 출력의 신중한 처리 등이 필요합니다.
• 예측 가능성(Predictability): 동일한 입력과 상태가 주어지면 에이전트는 좁은 기대 범위 내에서 동작해야 합니다. 에이전트가 무엇을 할 수 있고 무엇을 할 수 없는지 설명할 수 있어야 합니다.
• 디버깅 가능성(Debuggability): 문제가 생겼을 때 어느 상태, 어느 결정, 어느 도구, 어느 모델 호출인지 추적할 수 있어야 합니다. 숨겨진 루프나 구조 없는 "생각"이 없어야 합니다.
• 변화 허용성(Change-tolerance): 모델, 도구, 전략을 전체 시스템을 다시 쓰지 않고도 업그레이드할 수 있어야 합니다.

이 속성들은 프롬프트만으로 얻을 수 없습니다. 구조에서 얻습니다.

자유형 루프보다 명시적 워크플로를 선호하라

많은 팀이 시작하는 기본 패턴은: "while not done, call model, let it think, maybe call a tool, repeat" 입니다. 프로토타입은 쉽지만 운영하기 어렵습니다.

더 안전한 패턴은 에이전트를 명시적 워크플로로 표현하는 것입니다:

• 유한한 상태 집합을 정의하세요(예: COLLECTING_INPUT, PLANNING, EXECUTING_STEP, WAITING_ON_HUMAN, DONE).
• 상태 간 허용 전이를 정의하세요.
• LLM은 주로 국소적 결정(다음 상태 선택, 도구 선택, 파라미터 채움)에 사용하세요.

이렇게 하면 에이전트는 검사 가능하고, 테스트 가능하며, 재생 가능한 상태 머신이 됩니다. 자유형 루프는 유연하게 느껴지지만, 인시던트를 디버깅 가능하게 하고 동작을 감사 가능하게 하는 것은 명시적 워크플로입니다.

"갓 에이전트(god agent)"를 작은 스킬로 분해하라

모든 것을 하는 모놀리식 에이전트는 매력적이지만 관련 없는 책임들이 강하게 결합되어 문제를 만듭니다: 계획, 검색, 비즈니스 로직, UI 오케스트레이션 등.

대신 작고 잘 범위가 정해진 에이전트나 스킬을 조합하세요:

• 작업을 분해하는 플래너
• 구체적 단계를 실행하는 실행기(executor)
• 도메인별 스페셜리스트(정산, 지원, 분석 등)

각 스킬은 자체 상태 머신, 도구, 안전 규칙을 가질 수 있습니다. 조합 로직은 상위 수준의 워크플로가 되고, 단일 에이전트 내부의 프롬프트가 점점 커지는 상황을 피할 수 있습니다.

이 모듈화는 각 에이전트를 이해하기 쉽게 만들고, 한 기능을 진화시키더라도 다른 부분을 불안정하게 만들지 않습니다.

정책, 상태, 도구를 분리하라

유용한 사고 모델은 에이전트를 세 개의 계층으로 분리하는 것입니다:

1. 결정 정책(LLM 프롬프트 + 모델)
   에이전트가 다음 행동을 어떻게 선택하는지를 캡슐화합니다. 엄격한 제약 하에서 해석됩니다. 모델을 교체하거나 온도를 조정하거나 프롬프트를 정제할 수 있어도 시스템 배선은 건드리지 않아야 합니다.

2. 상태 머신 / 워크플로 엔진
   프로세스상 어디에 있는지, 어떤 전이가 가능한지, 진행을 어떻게 영속화할지를 소유합니다. 정책은 이동을 제안하고 상태 머신이 검증해 적용합니다.

3. 도구 계층
   실제로 세상에서 무엇이 일어나는지를 구현합니다: API, DB, 큐, 외부 서비스. 도구는 좁고 타입이 정해진 계약을 노출하고 인가, 레이트 리밋, 입력 검증을 시행합니다.

이 분리를 강제하면 비즈니스 로직을 프롬프트나 도구 설명에 숨기는 함정을 피할 수 있습니다. LLM은 결정 구성 요소로서 명확하고 결정론적인 외피 안에서 동작합니다.

작은 단위와 명확성을 설계하라

가장 신뢰할 수 있는 에이전트 시스템은 가장 인상적인 데모가 아니라, 화이트보드에서 동작을 설명할 수 있는 시스템입니다.

구체적으로:

• 각 에이전트를 한 가지 작업과 한 가지 주요 성공 지표에 집중하세요.
• 워크플로와 상태 전이를 산문이 아니라 명시적으로 인코딩하세요.
• LLM이 전체 절차를 발명하게 하지 말고, 잘 정의된 옵션들 사이를 선택하게 하세요.

이러한 작은, 조립 가능한, 잘 구조화된 에이전트에 대한 편향이 시스템이 범위를 확장해도 복잡성에 무너지지 않게 합니다.

에이전트 워크플로를 명시적 상태 머신으로 모델링하기

대부분의 에이전트 구현은 LLM 호출을 둘러싼 "생각, 행동, 관찰" 루프로 시작합니다. 데모에는 괜찮지만 곧 불투명하고 취약해집니다. 더 나은 접근법은 에이전트를 명시적 상태 머신으로 다루는 것입니다: 유한한 상태 집합과 이벤트로 촉발되는 명확한 전이.

상태와 전이로 에이전트 흐름 표현하기

모델이 다음에 뭘 할지 암묵적으로 결정하게 두지 말고 작은 상태 다이어그램을 정의하세요:

• PLAN – 사용자 요청을 해석해 단계를 분해하고 도구를 선택합니다.
• CALL_TOOL – 검증된 입력으로 단일 도구 호출(또는 배치)을 실행합니다.
• VERIFY – 도구 출력을 간단한 불변식이나 추가 모델 검사로 확인합니다.
• RECOVER – 오류를 처리합니다: 재시도, 폴백, 혹은 에스컬레이션.
• DONE – 최종 답변을 반환하고 워크플로를 종료합니다.
• FAILED – 명확한 이유와 컨텍스트를 포함한 종단 오류 상태.

이 상태들 사이의 전이는 UserRequestReceived, ToolCallSucceeded, ToolValidationFailed, TimeoutExceeded, HumanOverride 같은 타입화된 이벤트에 의해 촉발됩니다. 각 이벤트와 현재 상태가 다음 상태와 행동을 결정합니다.

이렇게 하면 재시도와 타임아웃을 간단하게 만들 수 있습니다: 개별 상태에 정책을 붙이면 됩니다(예: CALL_TOOL은 지수적 백오프로 3번 재시도, PLAN은 재시도하지 않음). 분산된 코드베이스 전반에 재시도 로직을 흩어놓는 일을 피할 수 있습니다.

복원력과 스케일을 위한 상태 외부화

현재 상태와 최소한의 컨텍스트를 외부 저장소(DB, 큐, 워크플로 엔진)에 영속화하세요. 에이전트는 이제 순수 함수가 됩니다:

next_state, actions = transition(current_state, event, context)

이로 인해 얻을 수 있는 것들:

• 복원력 – 워커가 중간에 죽어도 다른 워커가 마지막 영속화된 상태에서 재개할 수 있습니다.
• 수평 확장 – 무상태 워커가 이벤트를 소비하고 상태를 갱신하며 다음 이벤트를 발행합니다.
• 재생과 보상 작업 – 실행을 재구성하고 원하는 상태에서 재구동하거나 흐름을 롤백할 때 보상 작업을 실행할 수 있습니다.

추론과 감사에 대한 이점

상태 머신을 사용하면 에이전트 동작의 모든 단계가 명시적입니다: 어떤 상태였는지, 어떤 이벤트가 발생했는지, 어떤 전이가 발동했는지, 어떤 부작용이 생성되었는지. 이 명확성은 디버깅을 빠르게 하고 인시던트 조사와 컴플라이언스 리뷰를 단순화합니다. 로그와 상태 기록으로 특정 위험한 행동이 특정 상태 및 정의된 조건에서만 수행되었음을 증명할 수 있습니다.

에이전트를 위한 신뢰할 수 있는 도구 계약 설계

도구가 "프롬프트 안에 숨어있는 API"처럼 보이지 않고 명확한 보장(guarantee)을 가진 인터페이스처럼 보일 때 에이전트는 훨씬 예측 가능해집니다.

프롬프트가 아니라 계약을 정의하라

각 도구는 다음을 포함하는 계약을 가져야 합니다:

• 입력 스키마: 필수 필드, 타입, 열거형, 제약, 기본값
• 출력 스키마: 성공 페이로드, nullable 필드, “결과 없음”의 의미
• 오류 모델: InvalidInput, NotFound, RateLimited, TransientFailure 같은 타입 오류와 명확한 의미
• SLA: 지연 시간 기대치, 가용성 목표, 레이트 리밋

이 계약을 모델에 구조화된 문서로 노출하세요. 에이전트 플래너는 어떤 오류가 재시도 가능한지, 사용자 개입이 필요한지, 워크플로를 중단해야 하는지를 알아야 합니다.

엄격한 JSON, 엄격한 검증

도구 입출력을 다른 프로덕션 API처럼 다루세요:

• 입력과 출력을 위해 엄격한 JSON 스키마(OpenAPI, JSON Schema 등)를 사용합니다.
• 호출 전후로 검증합니다(모델 실수와 도구 회귀를 잡기 위해).
• 사소한 문제는 자동 수정(예: 타입 강제 변환)하되 로그로 남겨 튜닝에 활용하세요.

이렇게 하면 프롬프트를 장황하게 만드는 대신 스키마 기반 안내에 의존할 수 있습니다. 명확한 제약은 환각(hallucination)된 인수와 말이 안 되는 도구 시퀀스를 줄입니다.

버전 관리 및 호환성

도구는 진화합니다; 에이전트가 도구 변경 때문에 깨지면 안 됩니다.

• 도구 계약에 버전(v1, v1.1, v2)을 붙이고 에이전트를 특정 버전에 고정하세요.
• 필드는 점진적으로 폐기하고 오래된 필드를 당분간 읽을 수 있게 유지하세요.
• 시맨틱을 조용히 변경하지 말고 호환성 있게 필드를 추가하세요.

플래닝 로직은 서로 다른 성숙도 수준의 에이전트와 도구를 안전하게 섞을 수 있습니다.

실패와 저하 모드 처리

도구 계약을 부분 실패를 염두에 두고 설계하세요:

• 항목별 오류 세부 정보를 포함한 부분 결과를 허용하세요.
• 하드 실패 대신 저하된 응답(예: 캐시된, 근사값, 오래된 데이터)을 정의하세요.
• 어떤 필드가 "best effort"인지, 어떤 필드가 "필수"인지 표시하세요.

에이전트는 그에 따라 적응할 수 있습니다: 기능을 축소해 워크플로를 계속하거나 사용자에게 확인을 요청하거나 대체 도구로 전환합니다.

보안 및 권한 경계

도구 계약은 보안 제한을 인코딩하기에 자연스러운 장소입니다:

• 도구가 읽거나 수정할 수 있는 범위를 명시하세요.
• 민감한 동작에는 명시적 파라미터(예: confirm: true)를 요구하세요.
• 사용자 범위와 시스템 범위 작업을 구분하세요.

모델이 "잘 행동"할 것이라고만 믿지 말고 서버 사이드 검사와 결합하세요.

좋은 계약이 에이전트를 단순화하는 이유

도구가 명확하고 검증 가능하며 버전 관리된 계약을 가지면 프롬프트는 짧아지고 오케스트레이션 로직은 단순해지며 디버깅이 훨씬 쉬워집니다. 복잡성을 취약한 자연어 지시에서 결정론적 스키마와 정책으로 옮기면 환각된 도구 호출과 예기치 않은 부작용이 줄어듭니다.

재시도, 멱등성, 실패 처리 패턴

신뢰할 수 있는 에이전트 시스템은 모든 것이 결국 실패할 것이라고 가정합니다: 모델, 도구, 네트워크, 심지어 자체 조정 계층까지. 목표는 실패를 피하는 것이 아니라 실패를 저렴하고 안전하게 만드는 것입니다.

멱등성: 안전한 재시도의 기초

멱등성은: 같은 요청을 반복하면 한 번 실행한 것과 동일한 외부 가시적 효과를 가진다는 뜻입니다. 이는 부분 실패나 모호한 응답 이후에 도구 호출을 자주 다시 수행하는 LLM 에이전트에서 매우 중요합니다.

도구를 멱등하도록 설계하세요:

• 요청 ID: 모든 도구 호출에 안정적인 request_id를 포함하세요. 도구는 이를 저장하고 다시 같은 ID를 보면 동일한 결과를 반환합니다.
• 업서트(upsert): 자동 증가 ID 대신 자연 키나 합성 비즈니스 키로 식별되는 "생성 혹은 업데이트" 의미를 사용하세요.
• 체크섬과 버전링: 콘텐츠 해시나 버전 번호를 첨부해 중복, 오래된 쓰기, 충돌을 감지합니다.

비용 폭증을 막는 재시도 전략

일시적 실패(타임아웃, 레이트 리밋, 5xx)에 대해서는 구조화된 재시도(지수 백오프, 지터, 엄격한 최대 시도 수)를 사용하세요. 에이전트 동작을 추적할 수 있게 상관 ID로 모든 시도를 로깅하세요.

영구 실패(4xx, 검증 오류, 비즈니스 규칙 위반)에 대해서는 재시도하지 마세요. 에이전트 정책에 구조화된 오류를 노출해 재계획, 사용자 문의, 다른 도구 선택 등을 하게 하세요.

회로 차단기와 폴백

에이전트와 도구 계층 모두에 회로 차단기를 구현하세요: 반복 실패 이후 해당 도구에 대한 호출을 일시 차단하고 빠르게 실패하게 만드세요. 이를 저하 모드(캐시, 근사값, 대체 도구)와 페어링하세요.

에이전트 루프에서 무작정 재시도하지 마세요. 도구가 멱등하지 않고 실패 유형이 명확하지 않으면, 단지 부작용, 지연, 비용만 증폭시킬 뿐입니다.

에이전트를 위한 메모리, 상태, 데이터 일관성 관리

신뢰할 수 있는 에이전트는 무엇이 상태인지와 어디에 존재하는지에 대해 명확하게 생각하는 것에서 시작합니다.

단기 상태 vs 장기 메모리

에이전트를 요청을 처리하는 서비스처럼 다루세요:

• 단기 상태: 현재 작업이나 하위 작업을 완료하는 데 필요한 모든 것(활성 목표, 현재 단계, 도구 출력, 부분 결정, 재시도 남음 등). 범위가 좁고 워크플로 종료 시 폐기 가능합니다.
• 장기 메모리: 여러 실행과 세션을 넘겨 보존해야 하는 정보(사용자 프로필, 선호도, 과거 결정, 프로젝트 히스토리 등).

이 둘을 섞으면 혼란과 버그가 생깁니다. 예를 들어 일시적인 도구 결과를 메모리에 넣으면 이후 대화에서 오래된 컨텍스트를 재사용하게 됩니다.

상태를 어디에 저장할 것인가

세 가지 주요 옵션이 있습니다:

1. 인컨텍스트(프롬프트만) – 단순하고 지연이 낮지만 한계가 있고 지속성이 없습니다. 단일 실행의 단기 상태에 적합합니다.
2. 외부 저장소 – DB, 캐시, 벡터 스토어. 재시작을 견뎌야 하거나 워커 간 조정이 필요하면 장기 메모리에 사용합니다.
3. 하이브리드 – 권한 있는 상태를 외부에 두고 다음 단계에 필요한 것만 컨텍스트로 로드합니다.

좋은 규칙: LLM은 명시적 상태 객체에 대한 무상태 함수입니다. 그 상태 객체를 모델 밖에 보관하고 프롬프트는 그로부터 재생성하세요.

"로그를 메모리로" 사용하는 안티패턴 피하기

대화 로그, 트레이스, 원시 프롬프트를 사실상의 메모리로 사용하는 것은 흔한 실패 패턴입니다.

문제점:

• 검색이 애드혹하고 취약해집니다.
• 중요한 사실이 긴 텍스트에 묻힙니다.
• 여러 실행이 서로 모순될 때 명확한 최종값 규칙이 없습니다.

대신 user_profile, project, task_history 같은 구조화된 메모리 스키마를 정의하세요. 로그는 상태에서 파생되어야지 그 반대가 되어서는 안 됩니다.

공유 데이터 및 도구와의 일관성

여러 도구나 에이전트가 동일 엔터티(예: CRM 레코드, 티켓, 문서)를 업데이트할 때는 기본적인 일관성 제어가 필요합니다:

• 핵심 엔터티에 대해 단일 소스 오브 트루스를 사용하세요.
• 멱등성 도구 계약을 선호하세요: 도구가 안정적 ID와 업서트 의미로 재시도를 안전하게 처리하도록 합니다.
• 에이전트가 같은 레코드를 경쟁적으로 업데이트할 수 있을 때는 낙관적 동시성(버전 번호, 타임스탬프)을 적용하세요.

중요한 작업에는 대화 로그와 별개로 무엇이 변경되었는지, 왜 변경되었는지, 어떤 입력을 근거로 했는지 기록한 결정 로그를 남기세요.

스냅샷과 재개 가능한 실행

크래시, 배포, 레이트 리밋을 견디려면 워크플로는 재개 가능해야 합니다:

• 주요 단계마다 상태 스냅샷(현재 단계, 입력, 도구 결과, 보류 중 액션)을 저장합니다.
• 상태 머신의 모든 전이는 스냅샷에서 재생 가능하게 만드세요.
• 실패나 재시작 시 마지막 스냅샷을 불러와 계속 진행하게 하세요(처음부터 재시작하지 않음).

이것은 타임 트래블 디버깅도 가능하게 합니다: 문제가 된 정확한 상태를 검사하고 재생할 수 있습니다.

개인정보, 보존, 최소 기억 원칙

메모리는 자산인 동시에 책임입니다. 프로덕션 에이전트를 위해:

• 절대 저장하면 안 되는 것(비밀, 원문 문서, 민감한 PII)을 명시하세요. 필요한 경우 마스킹이나 해싱을 사용합니다.
• 메모리 유형별 보존 정책(세션 수준, 30일, 법적 보존 등)을 정의하세요.
• 사용자가 장기 메모리를 조회하고 삭제할 수 있는 권한을 제공하세요.
• 전체 프롬프트나 도구 입력을 저장할 필요가 없으면 더 작은 구조화 요약을 저장하세요.

메모리를 설계되고 버전 관리되며 거버넌스되는 제품 표면으로 취급하세요. 단순히 늘어나는 텍스트 덤프로 두지 마세요.

에이전트 시스템에서의 동시성, 레이트 리밋, 백프레셔

에이전트는 화이트보드상에서 순차적으로 보일지 몰라도 실제 부하 아래서는 분산 시스템처럼 동작합니다. 많은 동시 사용자, 도구, 백그라운드 작업이 생기면 레이스 컨디션, 중복 작업, 정렬 문제를 처리해야 합니다.

에이전트 워크플로의 동시성 위험

일반적인 실패 모드:

• 레이스 컨디션: 두 개의 에이전트 실행이 동일 티켓, 카트, 문서를 동시에 업데이트해 덮어쓰기 발생
• 중복 작업: 재시도나 잘못 구성된 워커 때문에 같은 작업을 두 번 처리(예: 결제 이중 청구)
• 순서 뒤바뀜: 도구 호출이 예상치 못한 순서로 완료되어 오래된 결과가 최신 상태를 덮어씀

이를 완화하려면 멱등성 도구 계약, 명시적 워크플로 상태, 데이터 레이어의 낙관적/비관적 잠금을 사용하세요.

큐 vs 동기 흐름

동기적인 요청–응답 흐름은 단순하지만 취약합니다: 모든 종속성이 작동하고 레이트 리밋 내에 있으며 빠르게 응답해야 합니다. 에이전트가 많은 도구나 병렬 하위 작업으로 팬아웃하면 장기 실행이나 부작용 스텝을 큐 뒤로 옮기세요.

큐 기반 오케스트레이션은 다음을 가능하게 합니다:

• 워커 풀로 동시성을 제어
• 재시도와 중복 제거 중앙화
• 느리거나 불안정한 도구를 사용자 대기 시간으로부터 분리

레이트 리밋과 백프레셔

에이전트는 일반적으로 세 가지 클래스의 리밋에 걸립니다:

• 모델: 분당 토큰, 분당 요청, 컨텍스트 크기
• 도구: 내부 서비스의 QPS 또는 CPU 제약
• 상류 API: 서드파티 할당량과 하드 캡

명시적 레이트-리밋 계층을 도입해 사용자별, 테넌트별, 글로벌 스로틀을 적용하세요. 토큰 버킷이나 리키 버킷을 사용하고 RATE_LIMIT_SOFT, RATE_LIMIT_HARD와 같은 명확한 오류 타입을 노출해 에이전트가 점진적으로 백오프하게 하세요.

백프레셔는 시스템이 스트레스 아래 스스로를 보호하는 방식입니다. 전략으로는:

• 중요하지 않은 트래픽을 먼저 차단
• 기능 저하(작은 컨텍스트, 적은 도구 호출)
• 낮은 우선순위 큐를 일시 중단하고 중요한 흐름은 유지

큐 깊이, 워커 활용률, 모델/도구 오류율, 레이턴시 퍼센타일을 모니터해 포화 신호를 감지하세요. 큐가 쌓이고 레이턴시나 429/503 오류가 증가하면 에이전트가 환경을 넘기려 한다는 초기 경고입니다.

에이전트 행동을 위한 관찰성: 트레이싱, 메트릭, 로그

무엇을 해야 하는지, 왜 그렇게 했는지를 빠르게 대답할 수 없다면 에이전트를 신뢰할 수 없습니다. 에이전트 관찰성은 그 답을 쉽고 정밀하게 하는 것입니다.

무엇을 봐야 하는가

단일 작업에 대해 다음을 하나의 트레이스로 연결하세요:

• 모든 에이전트 단계와 상태 전이
• 모든 도구 호출과 응답
• 모든 모델 호출과 프롬프트 변형

트레이스 안에 핵심 결정(라우팅 선택, 계획 수정, 가드레일 발동)을 위한 구조화된 로그와 볼륨 및 상태를 위한 메트릭을 붙이세요.

유용한 트레이스에는 보통 다음이 포함됩니다:

• 작업 메타데이터: 테넌트, 사용자, 채널, 우선순위
• 에이전트 상태: 현재 상태 이름, 다음 상태, 재시도 카운트
• 도구 I/O: 입력, 출력, 지연, 오류, 회로 차단 상태
• 모델 호출: 프롬프트 템플릿 ID, 모델 이름, 토큰 수, 지연

로깅 및 레다션

프롬프트, 도구 입력, 출력을 구조화된 형태로 로깅하되 레다션 레이어를 통과시키세요:

• PII와 시크릿 마스킹
• 초과 크기 페이로드는 해시와 함께 잘라서 상관성 유지
• 민감도 수준을 표시해 보존과 접근을 제어

로우 콘텐츠는 하위 환경에서 기능 플래그로 접근 가능하게 하고, 프로덕션은 기본적으로 레다션된 뷰를 사용하세요.

실제로 중요한 메트릭

최소한 다음을 추적하세요:

• 에이전트 및 사용 사례별 작업 성공/실패율
• 작업당 평균 및 P95 단계 수
• 종단 간 레이턴시 및 도구/모델별 레이턴시
• 작업당 비용(토큰, 도구 비용) 및 성공 결과당 비용

인시던트 시 좋은 트레이스와 메트릭은 "에이전트가 불안정하게 느껴진다"에서 "P95 작업이 ToolSelection에서 2번의 재시도 이후 실패, 원인은 billing_service의 새로운 스키마" 같은 정밀한 진술로 이동하게 해 진단 시간을 수시간에서 수분으로 줄입니다.

에이전트 시스템을 위한 테스트 및 평가 전략

에이전트를 테스트한다는 것은 에이전트가 호출하는 도구와 모든 것을 이어 붙이는 흐름을 모두 테스트하는 것입니다. 프롬프트 튜닝이 아니라 분산 시스템 테스트로 접근하세요.

유닛 테스트: 프롬프트가 아니라 도구 계약

도구 경계에서 시작하세요:

• 스키마 검증: 필수 필드, 열거형, 범위, 불변식
• 멱등성과 오류 의미(어떤 오류, 어떤 코드, 재시도 가능성) 확인
• 도구가 잘못된 입력을 우아하게 처리하고 구조화된 실패를 반환하는지 단언

이 테스트들은 LLM에 의존하지 않습니다. 합성 입력으로 도구를 직접 호출해 정확한 출력이나 오류 계약을 검증합니다.

통합 테스트: 흐름과 다단계 동작

통합 테스트는 에이전트 워크플로(LLM + 도구 + 오케스트레이션)를 종단 간으로 검증합니다.

시나리오 기반 테스트를 만드세요:

• 핵심 사용자 여정의 해피 패스(예약, 환불, 에스컬레이션 등)
• 엣지 케이스: 누락된 데이터, 부분 도구 실패, 타임아웃, 레이트 리밋
• 도구 간 상호작용: 도구 A의 출력이 도구 B의 입력이 되는 경우

이 테스트들은 LLM의 모든 토큰을 검증하지 않고 상태 전이와 도구 호출을 assert 하세요: 어떤 도구가 어떤 인수로 어떤 순서로 호출되었는지, 최종 상태/결과가 무엇인지.

LLM과 도구에 대한 결정적 픽스처

테스트를 반복 가능하게 유지하려면 LLM 응답과 도구 출력을 픽스처로 고정하세요:

• LLM 응답을 한 번 기록하고(프롬프트 + 모델 + 설정) JSON 픽스처로 저장
• 도구 뒤에 외부 시스템을 목(mock) 처리해 라이브 서비스에 의존하지 않게 함
• 테스트에서 명시적 시드와 고정된 온도 설정 사용

전형적인 패턴:

with mocked_llm(fixtures_dir="fixtures/llm"), mocked_tools():
    result = run_agent_scenario(input_case)
    assert result.state == "COMPLETED"

프롬프트와 스키마에 대한 회귀 테스트

모든 프롬프트나 스키마 변경은 비협상적인 회귀 실행을 트리거해야 합니다:

• 입력과 기대되는 상태, 도구 트레이스를 포함한 큐레이션된 코퍼스를 유지
• 이를 골든 파일로 잠그고, 차이(diff)는 동작 변화로 간주
• 중요한 흐름의 드리프트는 명시적 승인이나 롤백이 필요

스키마 진화(필드 추가, 타입 강화)는 별도의 회귀 케이스로 관리해 여전히 옛 계약을 가정하는 에이전트나 도구를 잡아냅니다.

롤아웃 전 오프라인 평가

새 모델, 정책, 라우팅 전략을 바로 프로덕션에 배포하지 마세요.

대신:

• 회귀 코퍼스를 새 구성으로 오프라인에서 재실행
• 샘플된 과거 상호작용을 리플레이 테스트
• 자동 메트릭(작업 성공률, 도구 오류율, 레이턴시, 비용) 계산 및 필요 시 샘플에 대한 인간 평가

오프라인 게이트를 통과한 경우에만 새 변형을 프로덕션에 투입하세요. 이상적으로는 피처 플래그와 점진적 롤아웃을 사용합니다.

테스트 데이터 관리와 익명화

에이전트 로그는 종종 민감한 사용자 데이터를 포함합니다. 테스트는 이를 존중해야 합니다:

• 데이터셋은 익명화되었거나 합성된 입력으로 구성
• 식별자, 자유 텍스트 PII, 시크릿을 저장하기 전에 스트립하거나 해싱
• 추적 가능성은 허용하되 원시 사용자 비밀에 대한 접근은 세분화

CI 파이프라인에서 이러한 규칙을 코드화해 익명화 검증 없이 테스트 아티팩트를 생성하거나 저장하지 못하게 하세요.

프로덕션에서 에이전트를 운영, 모니터, 진화시키기

에이전트를 운영하는 것은 정적 모델을 배포하는 것보다 분산 시스템을 운영하는 것에 가깝습니다. 롤아웃 제어, 명확한 신뢰성 목표, 엄격한 변경 관리가 필요합니다.

안전한 롤아웃 전략

새 에이전트나 동작을 점진적으로 도입하세요:

• 섀도우 모드: 에이전트를 기존 시스템 옆에서 실행해 결정을 기록하지만 사용자에게 영향 주지 않음. 오프라인에서 비교.
• 카나리: 트래픽의 소량(예: 1–5%)에 새 버전을 노출하고 에러율, 레이턴시, 품질을 관찰
• A/B 테스트: 사용자 영역 흐름의 경우 모델 메트릭이 아닌 비즈니스 KPI로 비교

모든 변경은 피처 플래그와 설정 기반 정책(라우팅 규칙, 사용 도구, 온도, 안전 설정)으로 제어하세요. 코드가 아니라 설정으로 배포되고 즉시 되돌릴 수 있어야 합니다.

SLO와 인시던트 워크플로

시스템 건강과 사용자 가치를 반영하는 SLO를 정의하세요:

• 신뢰성: 작업, 도구 호출, 종단 간 워크플로의 성공률
• 레이턴시: 중요한 경로의 p50/p95
• 품질: 자동 평가 점수, 인간 평가 분포, 작업별 성공 지표

이를 알람에 연결하고 일반적인 프로덕션 서비스처럼 인시던트를 처리하세요: 명확한 소유권, 런북, 완화(플래그 롤백, 트래픽 드레인, 안전 모드) 단계 포함.

지속적 개선과 변경 통제

로그, 트레이스, 대화 기록을 사용해 프롬프트, 도구, 정책을 정교화하세요. 각 변경은 버전화된 아티팩트로 검토, 승인, 롤백 가능해야 합니다.

무단 프롬프트나 도구 변경은 피하세요. 변경 통제가 없으면 회귀를 특정 편집과 연결할 수 없고 인시던트 대응은 추측에 의존하게 됩니다.

신뢰할 수 있는 에이전트 시스템을 위한 참조 아키텍처

프로덕션 준비된 에이전트 시스템은 책임 분리가 명확한 구조의 이점을 누립니다. 목표는 에이전트를 결정에서는 "똑똑하게" 유지하되 인프라에서는 "단순하게" 만드는 것입니다.

핵심 구성 요소

1. 게이트웨이 / API 엣지
클라이언트(앱, 서비스, UI)를 위한 단일 진입점입니다. 여기서:

• 인증 및 권한 부여(사용자, 서비스, 테넌트)
• 레이트 리밋 및 쿼터
• 요청 셰이핑(스키마, 크기 제한, 기본 검증)을 처리합니다.

2. 오케스트레이터
오케스트레이터는 "뇌간"이지 뇌는 아닙니다. 다음을 조정합니다:

• 플래너: 사용자 의도를 워크플로나 상태 머신으로 번역
• 상태 오케스트레이터: 워크플로 실행, 상태 추적, 재시도 및 타임아웃 처리
• 정책 엔진: 안전, 컴플라이언스, 허용 도구, PII 규칙, 비용 예산 집행

LLM은 오케스트레이터 뒤에 위치하며 플래너와 특정 도구에서 언어 이해용으로 사용됩니다.

3. 도구 및 스토리지 계층
비즈니스 로직은 기존 마이크로서비스, 큐, 데이터 시스템에 남겨두세요. 도구는 다음을 감싸는 얇은 래퍼입니다:

• 내부 HTTP/gRPC 서비스
• 데이터베이스, 벡터 스토어, 캐시
• 외부 API

오케스트레이터는 엄격한 계약을 통해 도구를 호출하고 스토리지 시스템은 진실의 원천입니다.

통합, 제어, 텔레메트리

게이트웨이에서 인증과 쿼터를 시행하고, 오케스트레이터에서 안전성, 데이터 접근, 정책을 시행하세요. 모든 호출(LLM과 도구)은 구조화된 텔레메트리를 방출해 다음에 공급됩니다:

• 단계별 행동을 위한 트레이스
• SLO와 레이트 리밋을 위한 메트릭
• 보안 및 컴플라이언스를 위한 감사 로그
• 사용자, 프로젝트, 도구별 비용 회계

더 단순한 아키텍처(게이트웨이 → 단일 오케스트레이터 → 도구)가 운영하기 쉽습니다. 플래너, 정책 엔진, 모델 게이트웨이를 분리하면 유연성은 커지지만 조정, 지연, 운영 복잡성이 증가합니다.

정리 및 팀을 위한 다음 단계

이제 로드에서 예측 가능하게 동작하는 에이전트를 만드는 핵심 재료를 가지고 있습니다: 명시적 상태 머신, 명확한 도구 계약, 규율된 재시도, 그리고 깊은 관찰성. 마지막 단계는 이 아이디어들을 팀 내에서 반복 가능한 실천으로 전환하는 것입니다.

핵심 패턴을 한 장으로 요약하면

각 에이전트를 상태가 있는 워크플로로 생각하세요:

• 상태 머신이 합법적 단계(plan → gather → act → summarize 등)와 전이를 정의
• 도구 계약은 엄격한 스키마, 타임아웃, 오류 표면을 가진 행동 단위를 정의
• 재시도와 멱등성은 모든 외부 상호작용을 보호해 재생이 안전하게 함
• 관찰성(트레이스, 메트릭, 로그)은 모든 결정과 도구 호출을 설명 가능하게 함

이 요소들이 정렬되면 엣지 케이스에서 우아하게 저하되는 시스템을 얻을 수 있습니다. 무너지지 않습니다.

에이전트를 프로덕션화하기 위한 경량 체크리스트

프로토타입 에이전트를 실제 사용자에게 배포하기 전에 다음을 확인하세요:

• 워크플로: 상태와 전이가 명시적이며 숨겨진 루프나 무한 도구 체인이 없음
• 계약: 모든 도구에 타입화된 입/출력, 명확한 실패 모드, 타임아웃 존재
• 안전: 입력/출력/행동에 대한 가드레일(레이트 리밋, 허용 목록, 쿼터)
• 재시도: 도구별 정책 정의, 모든 부작용 호출에 멱등성 키 존재
• 상태: 메모리와 영속 상태가 범위가 정해지고 버전 관리되며 복구 가능
• 관찰성: 어떤 사용자 세션에 대해서도 한 트레이스에서 "무슨 일이 일어났나?"를 답할 수 있음
• 테스트: 시나리오 기반 테스트와 프롬프트/도구/정책 회귀 스위트 존재

어느 항목이라도 없다면 아직 프로토타입 단계입니다.

팀이 소유권을 나누는 방법

지속 가능한 구조는 보통 다음과 같이 분리됩니다:

• 제품팀: 에이전트 동작, 프롬프트, 도메인 특정 도구, 평가 데이터셋 소유
• 플랫폼/인프라팀: 상태 머신 프레임워크, 공통 도구 SDK, 로깅·트레이싱, 정책 집행, 공통 평가 인프라 소유

이렇게 하면 제품팀은 빠르게 움직일 수 있고 플랫폼팀은 신뢰성, 보안, 비용 제어를 강제할 수 있습니다.

확장 가능한 다음 단계와 안전한 실험

기반이 안정화되면 다음을 탐구하세요:

• 학습 기반 정책: 기록된 트레이스를 사용해 라우팅, 도구 선택, 폴백 전략 개선
• 강화 학습: 단회 응답이 아닌 장기간 결과(작업 완료, 매출) 최적화
• 자기 조정 워크플로: 관찰된 성능에 따라 온도, 도구, 하위 흐름을 자동 조정

이런 진전은 점진적으로 도입하세요: 피처 플래그 뒤에서, 오프라인 평가와 강력한 가드레일로 보호하세요.

일관된 주제는 같습니