프로덕션 AI 에이전트를 위한 5가지 지루한 인프라 패턴 (그리고 데모 데이 때 저지르는 실수들)
5 boring infrastructure patterns for production AI agents (and the demo day mistakes they fix)
핵심 요약
프로덕션 환경에서 AI 에이전트가 안정적으로 작동하게 만드는 5가지 실전 인프라 패턴을 소개함.
- 멱등성 키 — 외부 툴 호출 시 중복 실행 방지.
- 상태 관리 — 컨텍스트 윈도우 대신 PostgreSQL 활용.
- 모델 계층화 — 비용 절감을 위해 저가 모델 우선 사용.
- 사전 검증 — 실제 작업 수행 전 결과물 무결성 확인.
프로덕션 환경에서 살아남은 모든 에이전트에서 이 5가지 패턴이 계속 나타났음. 대부분의 튜토리얼은 이걸 건너뛰는데, 새벽 2시에 뭔가 터지고 나서야 중요성을 깨닫게 됨.
- 모든 외부 툴 호출에 멱등성 키 사용.
Twilio 웹훅 재시도가 전형적인 예시임. LLM이 느리면 Twilio가 요청을 재시도하고, 에이전트는 똑같은 왓츠앱 메시지를 두 번 보냄. UUID 기반의 멱등성 키가 이걸 해결해줌. 호출이 두 번 실행되어도 두 번째는 아무 일도 안 하게 됨.
- 상태는 컨텍스트 윈도우가 아니라 PostgreSQL에 저장.
대화가 길어지면 LLM 컨텍스트에 상태를 넘기는 방식은 바로 실패함. LLM은 까먹고, 출력은 엉망이 되고, 디버깅은 불가능해짐. 더 나은 패턴은 PostgreSQL에 상태 객체를 두는 거임. 모든 단계에서 상태를 읽고 다시 씀. 프롬프트는 현재 상태 {x}로 시작함. 추론은 컨텍스트가, 기억은 PostgreSQL이 담당함.
- 저가 모델 우선 사용, 재시도 시 고가 모델 사용.
Haiku나 GPT-4o mini가 큰 모델이 하는 일의 95%를 처리함. 검증에 실패하는 5%에 대해서만 Sonnet이나 GPT-4로 재시도함. API 비용을 크게 줄이면서도 사용자 입장에서 품질 저하는 거의 없음.
- 실제 작업 수행 전 검증 단계 필수.
돈을 보내거나, 이메일을 보내거나, 공개 게시물을 올리는 등 되돌릴 수 없는 모든 작업은 먼저 상태 확인이 필요함. 이 이메일 형식이 맞나? 이 거래가 예상 범위 내인가? 검증 없이는 이상한 출력물이 첫 주부터 실제 사용자에게 나감.
- 전체가 아닌 사용자별 속도 제한(Rate limiting).
전체 제한은 한 사용자가 실수로 루프를 돌려 200번 요청을 보내는 걸 못 막음. 사용자별 제한은 막을 수 있음. 누군가의 프론트엔드가 무한 재시도 루프에 빠졌을 때 비용 폭탄을 피하게 해줌.
메타 패턴: LLM이 매번 어떤 식으로든 실패할 거라고 가정하셈. 모든 단계를 실패해도 복구 가능하게 설계해야 함. 이런 사고방식의 전환이 데모 데이용 에이전트와 프로덕션용 에이전트를 가르는 차이임.
튜토리얼에는 안 나오지만 당신들이 쓰고 있는 패턴은 뭐가 있음?
