우리 모두 그런 경험이 있습니다. 에이전트 프레임워크를 실행하고, 이를 GPT-4o에 연결한 뒤, 여러분의 노트북에서 마법처럼 작동하는 것을 지켜봅니다. 그러다 이를 프로덕션 (Production) 환경에 배포하면, 그 마법은 멈춥니다. 아침 식사를 하기 전에 API 청구서가 세 자릿수를 찍습니다. 여러분의 "자율 에이전트 (Autonomous agent)"는 CAPTCHA에 막혀 6시간 동안 루프를 돕니다. 그리고 여러분이 설계한 아름다운 아키텍처 — 오케스트레이터 (Orchestrator), 슈퍼바이저 (Supervisor), 그리고 특화된 서브 에이전트 (Sub-agents)로 구성된 구조 — 는 그 자체의 복잡성 아래 무너집니다.

저는 2025년 초부터 생업으로 AI 에이전트 시스템을 구축해 왔습니다. 장난감 데모가 아닙니다. 고객 데이터를 처리하고, 결정을 내리며, 실행하는 데 실제 비용이 드는 진짜 시스템들입니다. 저는 여러분이 상상할 수 있는 모든 실수를 저질러 보았습니다. 여기 실제로 중요했던 7가지 교훈이 있습니다.

1. 로그가 에이전트다 — 여러분의 오케스트레이터 코드가 아니다

개발자 워크스테이션 — 스톡 사진 — 📸 Unsplash

현재 Dev.to에서는 "로그가 에이전트인가"에 대한 뜨거운 논쟁이 벌어지고 있습니다. 저는 예전에 이것이 철학적인 회피라고 생각했습니다. 하지만 이제는 이것이 에이전트 아키텍처 (Agent architecture)에서 가장 중요한 통찰이라고 생각합니다.

핵심 아이디어는 이렇습니다. 내부적으로 상태 (State)를 추적하는 복잡한 오케스트레이터를 구축하는 대신, **이벤트 로그 (Event log)**를 에이전트의 진실의 원천 (Source of truth)으로 취급하는 것입니다. 모든 결정, 모든 API 호출, 모든 상태 전이(State transition) — 이 모든 것이 그저 테이블의 한 행일 뿐입니다.

# 이전: 암시적 상태를 가진 복잡한 오케스트레이터
class AgentOrchestrator:
 def __init__(self):
...

이것은 단순히 더 깔끔한 코드를 의미하는 것이 아닙니다. 이는 에이전트의 실행 중간에 일시 중지하고, 다시 시작하면 정확히 멈췄던 지점부터 다시 시작할 수 있음을 의미합니다. 또한 모든 결정을 감사 (Audit)할 수 있음을 의미합니다. 주니어 개발자도 SQL 쿼리 하나를 실행함으로써 전체 시스템 상태를 이해할 수 있음을 의미합니다.

이번 주 Hacker News의 인기 스레드에서는 다음과 같은 질문이 올라왔습니다: "이미 Postgres를 가지고 있는데, 정말로 별도의 시스템이 필요할까요?" 에이전트(Agent)의 경우, 그 대답은 단호하게 "아니오"입니다. 이벤트(Events)를 위한 Postgres, 상태(State)를 위한 Postgres, 메모리(Memory)를 위한 Postgres — 그것만으로도 충분합니다.

2. 계층적 지능 (Tiered Intelligence)을 설계하지 않으면 에이전트 비용이 시간당 $50가 될 것입니다

AI & technology — stock photography — 📸 Unsplash

AI 에이전트에 대해 아무도 말해주지 않는 사실이 하나 있습니다: 모든 LLM 호출에는 비용이 발생하며, 여러분의 에이전트는 생각보다 훨씬 더 많은 호출을 수행할 것입니다.

def categorize_email(email_text):
 """의사결정의 90%는 저렴한 모델을 사용하고, 어려운 10%에만 비싼 모델을 사용하세요."""
 # Tier 1: 정규 표현식 (Regex) + 규칙 — 무료
...

계층적 접근 방식(Tiered approach)을 통해 제 비용을 80% 절감했습니다. 실제 시스템의 예산 내역은 다음과 같습니다:

• 정규 표현식 (Regex) + 규칙: 의사결정의 60% — 무료
• 로컬 모델 (Ollama를 통한 Llama 3.2 3B): 의사결정의 25% — 개당 약 ~$0.0001
• 클라우드 LLM (GPT-4o-mini): 의사결정의 12% — 개당 약 ~$0.001
• 프런티어 모델 (Frontier model) (Claude Sonnet / GPT-4o): 의사결정의 3% — 개당 약 ~$0.03

총합: $50 대신 하루 약 $2.50입니다. 출력 품질은 동일합니다. 프런티어 모델은 예외 케이스(Edge cases)를 처리하고, 그 외의 모든 것은 더 저렴하고 빠른 모델이 처리합니다.

3. 도구(Tools)가 제품이며, LLM은 단지 라우터(Router)일 뿐입니다

AI & technology — conceptual illustration — 📸 Unsplash

저는 예전에 LLM (Large Language Model)이 가장 중요한 부분이라고 생각했습니다. 틀렸습니다. LLM은 교체 가능한 것입니다. 6개월마다 새로운 모델이 리더보드(leaderboard)의 정상을 차지합니다. 여러분의 에이전트(agent) 코드가 살아남는 이유는 특정 모델이 아니라 인터페이스(interface)를 호출하기 때문입니다.

변하지 않는 것은 무엇일까요? 바로 여러분의 **도구 (tools)**입니다. 여러분의 API, 데이터베이스 스키마 (database schema), 그리고 평가 파이프라인 (evaluation pipeline)입니다.

def run_tool(name, args):
 """도구는 다른 프로덕션 API와 마찬가지로 버전이 관리되고, 문서화되며, 테스트됩니다."""
 if name == "search_docs":
...

제가 본 최고의 에이전트들은 잘 설계된 10~15개의 도구와 그 상단에 위치한 단순한 라우터 (router)를 가지고 있었습니다. 반면 최악의 에이전트들은 고작 2개의 도구만을 가진 채, 모든 것을 처리하려고 시도하는 500줄짜리 시스템 프롬프트 (system prompt)를 가지고 있었습니다.

프롬프트가 아니라 도구에 투자하세요. 99.9%의 확률로 작동하는 도구는 여러분의 에이전트를 똑똑해 보이게 만듭니다. 훌륭한 프롬프트를 가졌더라도 취약한 도구를 사용하면 에이전트는 혼란스러워 보일 것이며, 재시도 (retries) 과정에서 비용만 발생시킬 뿐입니다.

4. 평가 프레임워크 (Evaluation Framework)는 시작 전부터 필요합니다 — 시작한 후가 아니라

저는 평가 (eval) 없이 에이전트를 출시한 적이 있습니다. 제 테스트 케이스에서는

저는 간단한 트레이싱 (tracing) 대시보드를 만드는 데 주말을 보냈습니다. SQLite에 트레이스를 저장하고 기본적인 HTML 테이블로 렌더링하는 FastAPI 앱이었습니다. 그 주말 덕분에 수개월의 디버깅 (debugging) 시간을 아낄 수 있었습니다. 이제 제가 만드는 모든 에이전트에는 첫 번째 줄부터 트레이싱 (tracing) 기능이 내장되어 있습니다.

6. 에러 복구 (Error Recovery)가 기능이다 — 에러 방지가 아니다

이 교훈은 제 사고방식을 완전히 뒤집어 놓았습니다. 예전에는 에이전트가 절대 실패하지 않도록 만드는 데 몇 주를 소비했습니다. 이제는 에이전트가 실패했을 때 우아하게 복구 (recover)할 수 있도록 만드는 데 몇 시간을 씁니다.

5%의 확률로 실패하지만 그 실패 중 95%를 복구하는 에이전트가, 3%의 확률로 실패하지만 매 실패마다 완전히 충돌 (crash)하는 에이전트보다 더 신뢰할 수 있습니다.

def execute_with_recovery(agent, task, max_retries=3):
 """방지하지 말고, 복구하라."""
 for attempt in range(max_retries):
...

이 방식은 2026년 3월 Anthropic API 장애 당시 저를 구했습니다. 제 에이전트는 Claude Sonnet에서 GPT-4o-mini로 자동으로 폴백 (fallback)되었고, 품질은 다소 낮아졌지만 작업의 80%를 완료했으며, 나머지 20%는 나중에 처리하도록 큐 (queue)에 쌓았습니다. 다운타임은 제로였습니다.

7. 작은 모놀리스 (Small Monoliths)가 분산 에이전트 시스템을 언제나 이긴다

저는 유행에 속았습니다. 멀티 에이전트 시스템 (Multi-agent systems)! 전문화된 감독관 (Specialized supervisors)! 오케스트레이터 패턴 (Orchestrator patterns)! 저는 에이전트 마이크로서비스 (microservices)를 위한 Kubernetes 클러스터를 구축했습니다. 그것은 재앙이었습니다.

진실은 이렇습니다. 사용 사례의 90%에 대해, asyncio와 Postgres 연결을 사용하는 단일 Python 프로세스가 지연 시간 (latency), 비용, 디버깅 가능성 (debuggability), 그리고 개발자의 행복도 등 모든 지표에서 분산 멀티 에이전트 시스템을 압도합니다.

async def main():
 db = await asyncpg.connect(os.getenv("DATABASE_URL"))
 agent = SimpleAgent(
...

제 프로덕션 에이전트는 단일 Python 프로세스에서 시간당 500개 이상의 작업을 처리합니다. VM 비용은 월 12달러입니다. 절대 충돌하지 않습니다. 디버깅이 필요할 때 저는 직접 연결하여 코드를 단계별로 실행 (step through)합니다. 서비스 메시 (service mesh), Kafka 스트림 (Kafka streams), 컨테이너 오케스트레이션 (container orchestration) 같은 것은 필요 없습니다.

분산 시스템 (distributed system)이 필요할 때까지 기다리세요. 에이전트 활용 사례의 90%는 분산 시스템이 필요하지 않습니다. 그리고 분산 시스템이 정말로 필요한 경우 — 즉, 진정으로 높은 처리량 (high-throughput)을 요구하거나 멀티 테넌트 (multi-tenant) 시스템인 경우 — 큐 (queue), 워커 (workers), 그리고 동일한 Postgres 기반의 이벤트 로그 (event log)만으로도 구축할 수 있습니다.

결론 (The Bottom Line)

AI 에이전트를 구축하는 것은 최신 프레임워크 (framework)나 가장 정교한 아키텍처 (architecture)를 쫓는 것이 아닙니다. 그것은 지루한 일들에 관한 것입니다: 좋은 도구, 견고한 에러 핸들링 (error handling), 구조화된 관측성 (observability), 그리고 신뢰할 수 있는 단일 원천 (source of truth)으로서의 단순한 이벤트 로그 (event log) 말입니다.

프로덕션 (production) 환경에서 살아남는 에이전트는 서류상으로 가장 인상적인 에이전트가 아닙니다. 에러를 우아하게 처리하고, 예산 범위 내에서 작동하며, 에이전트가 내린 모든 결정을 추적할 수 있기 때문에 당신이 밤에 잠을 잘 수 있게 해주는 에이전트입니다.

Postgres를 선택하세요. 이벤트를 기록하세요. 도구를 테스트하세요. 그리고 제발, 무엇보다도, 당신의 에이전트가 사용자 테이블 (users table)을 삭제하게 두지 마세요.