r/AI_Agents•5개월 전•24•12
프로덕션 환경에서 AI 에이전트를 구축하며 배운 교훈
Lessons learned building agents in production
핵심 요약
AI 에이전트의 안정적인 운영을 위해 프롬프트보다 런타임 아키텍처와 시스템 설계가 중요함을 강조함.
- 시스템 설계 — LLM을 가드레일로 쓰지 말고 결정론적 코드와 스키마로 제어함.
- 런타임 아키텍처 — 재시도, 상태 체크포인트, 복구 기능을 갖춘 내구성 있는 런타임이 필수적임.
- 컨텍스트 관리 — 불필요한 정보 누적을 방지하고 에이전트 간 공유되는 단일 진실 공급원을 유지함.
- 운영 가시성 — 에이전트의 판단과 실행 과정을 추적할 수 있는 관측 가능성 확보가 중요함.
에이전트 구축은 쉽다. 하지만 안정적으로 실행하는 것은 어렵다.
프로덕션 환경에서 얻은 몇 가지 교훈:
- LLM을 가드레일로 사용하지 마라. 코드, 스키마, 정책, 허용 목록, 결정론적 검사를 사용하라. LLM은 추론하게 두고, 시스템이 강제하게 하라.
- 에이전트가 중간에 실패할 것이라고 가정하라. 툴 호출 실패, 루프 중단, API 타임아웃, 컨텍스트 손실 등이 발생한다. 재시도, 체크포인트, 멱등성, 마지막 성공 상태에서 재개하는 기능이 필요하다.
- 컨텍스트 오염은 실재한다. 모든 것을 계속 추가하면 컨텍스트는 쓰레기가 된다. 능동적인 컨텍스트 관리가 필요하다.
- 작은 에이전트가 더 잘 작동한다. 거대한 '모든 것을 다 하는' 에이전트보다 좁은 목표를 가진 에이전트가 낫다. 분할 정복하라.
- 공유 컨텍스트는 어렵지만 필수적이다. 하위 에이전트들은 하나의 진실 공급원이 필요하다. 마크다운, 구조화된 상태, 벡터 DB, 그래프 등 무엇이든 좋지만, 모든 에이전트가 자신만의 현실을 만들게 두지 마라.
- 내구성 있는 런타임을 사용하라. 체크포인트가 있는 LLM 루프만으로는 충분하지 않다. 재시도, 상태, 복구, 동적 계획, 인간 개입(human-in-the-loop)을 지원하는 워크플로우/런타임 계층을 사용하라. 나는 이를 위해 Conductor / Agentspan을 사용한다.
- 관측 가능성은 생각보다 중요하다. 에이전트가 무엇을 보았고, 결정했고, 호출했고, 재시도했고, 건너뛰었고, 변경했는지 알아야 한다.
- 벤더 종속을 피하라. 에이전트는 대부분 프롬프트, 툴, 설정, 컨텍스트, 런타임 동작이다. 이들을 이식 가능하게 유지하라.
- 자격 증명을 에이전트 코드와 분리하라. 에이전트는 작업을 요청해야 한다. 시스템이 인증, 비밀 정보, RBAC, 감사를 강제해야 한다.
- 평가(Evals)를 수행하라. 항상. 데모는 평가가 필요 없지만, 프로덕션 시스템은 반드시 필요하다.
나의 결론: 프로덕션 에이전트는 '더 똑똑한 프롬프트'보다는 런타임 아키텍처, 즉 내구성, 컨텍스트, 관측 가능성, 보안, 복구에 관한 것이다.
궁금한 점: 데모를 넘어 에이전트를 실행할 때 실제로 무엇이 고장 났는가?
