프로덕션 레디 AI 에이전트: 모놀리스 리팩토링에서 얻은 5가지 교훈

2026년 4월 21일

로컬 머신에서 멋지게 작동하는 AI 에이전트를 만드는 건 쉽죠. 하지만 현실 세계에서 살아남는 에이전트, 즉 레이트 리밋을 처리하고, 무한 루프를 피하며, 하드코딩된 데이터를 넘어 확장되는 에이전트를 만드는 건 완전히 다른 문제예요. 이건 단순히 코드를 깔끔하게 짜는 것만을 의미하지 않아요. 감당 못 할 클라우드 요금 폭탄, 환각(Hallucination) 출력으로 인한 평판 손상, 그리고 운영 환경에서 조용히 실패하는 악몽 같은 상황을 피하는 게 핵심이에요.

이런 '취약한 아키텍처' 패턴들을 해결하기 위해 Google 팀은 AI 에이전트 클리닉을 시작했어요. 첫 번째 미션은 '티타늄'이라는, 유망하지만 깨지기 쉬운 영업 조사 에이전트를 완전히 분해하고 재구성하는 거였어요. 첫 에피소드에서 Luis Sala는 Jacob Badish와 함께 이 에이전트를 처음부터 다시 만들었죠. 티타늄의 원래 작업은 특정 회사를 조사하고 개인화된 아웃리치 이메일을 작성하는 거였어요. 프로토타입은 작동했지만 느렸고, 거대한 모놀리스 파이썬 스크립트에 의존했으며, 고작 12개의 하드코딩된 사례 연구 목록으로 제한되어 있었어요.

한 시간 동안, 팀은 이 에이전트를 분해하고 운영 환경에 맞게 재구축했어요. 여기 에피소드 1에서 다룬 주요 문제점, 해결책, 그리고 얻은 엔지니어링 교훈들이에요.

1. 모놀리스를 버리고 오케스트레이션된 서브 에이전트로 전환하세요

문제점: 원래 에이전트는 거대한 선형 for 루프, 즉 모놀리스 스크립트 위에서 돌아갔어요. 만약 하나의 서브 작업(API 타임아웃이나 환각(Hallucination) 같은)이 실패하면, 전체 프로세스가 멈추고 조용히 실패해버리는 식이었죠.

해결책: 팀은 이 모놀리스를 뜯어내고 Google의 에이전트 개발 키트(ADK)를 사용해서 분산 프레임워크를 설치했어요. SequentialAgent 파이프라인을 만들어서, 작업을 회사 연구원(Company Researcher), 검색 플래너(Search Planner), 사례 연구원(Case Study Researcher), 선택자(Selector), 그리고 이메일 작성자(Email Drafter) 같은 전문화된 노드들로 나눴어요.

교훈: 관심사의 분리예요. 거대한 다단계 프롬프트를 혼자서 실행하려는 하나의 LLM보다, 좁은 작업에 특화된 에이전트들이 훨씬 더 안정적으로 작동해요.

아키텍처: 오케스트레이션된 파이프라인으로 전환

2. 구조화된 출력 강제화 (Pydantic을 통해)

문제점: 원래 티타늄은 프롬프트 문자열 안에 직접 대규모 하드코딩을 해서 모델에서 JSON 출력을 강제로 얻어냈어요. 그 결과 지저분한 코드, 깨지기 쉬운 파싱, 그리고 정확한 구조를 계속해서 설명하느라 토큰을 낭비하는 문제가 발생했죠.

해결책: ADK로 전환하면서, 팀은 프롬프트에서 스키마 포맷팅 지시를 완전히 제거했어요. 대신, Pydantic 네이티브 객체를 명시적인 스키마 정의로 직접 주입했죠. ADK는 내부적으로 구조화된 출력 (Structured Outputs) 기능을 동적으로 사용해서 상용구 코드를 추상화하고 구조를 강제해요. 이처럼 '계약'을 모호한 자연어 요청에서 런타임에 유효성이 검증되는 파이썬 객체로 옮김으로써, 구조적 무결성을 보장하고 깨지기 쉬운 커스텀 파싱을 없앨 수 있었어요.

# BEFORE: 프롬프트 문자열의 비대화
prompt = """
Give me the answer in this JSON format:
{
   "company": "Company Name",
   "pain_points": ["point1", "point2"]
}
"""

# AFTER: ADK에서 Pydantic 스키마 주입
class CompanyIntel(BaseModel):
    company: str
    pain_points: list[str]

3. 하드코딩된 상태를 동적인 RAG 파이프라인으로 대체하세요

문제점: 티타늄의 컨텍스트 코퍼스는 인위적으로 너무 작았어요. 파이썬 파일에 직접 작성된 고작 12개의 하드코딩된 사례 연구만 알고 있었죠. 개발자가 코드를 수동으로 업데이트하지 않으면 확장되거나 학습할 수 없었어요.

해결책: 팀은 동적인 데이터 수집 시스템을 구축했어요. 비동기 크롤러(Playwright)가 백그라운드에서 자율적으로 Google Cloud 고객 성공 웹사이트를 스크랩하고, 이를 Google Cloud 벡터 검색 (Vector Search)으로 일괄 전송해요. 다시 파이프라인으로 돌아와서, 사례 연구원(Case Study Researcher)은 인덱싱된 코퍼스에 대해 진정한 하이브리드 검색(Hybrid Search)을 실행해서 이상적인 사례 연구를 가져오죠. (참고: 하이브리드 검색(Hybrid Search)은 쿼리의 의미론적 '의미'와 정확한 키워드 매칭의 정밀도를 결합하여, 에이전트가 특정 기술 용어를 놓치지 않도록 보장해요).

교훈: 하드코딩은 프로토타입에는 괜찮지만, 운영 환경 파이프라인은 스스로 데이터를 새로고침할 필요가 있어요. 진정한 에이전틱(agentic) 가치는 에이전트에게 벡터 검색(Vector Search)을 통해 자율적으로 데이터를 가져오고, 확장하고, 쿼리할 수 있는 도구를 제공하는 데서 나와요. 이제 컨텍스트 제한을 하드코딩하는 건 그만두세요.

아키텍처: RAG 파이프라인 수집

4. 관찰 가능성(Observability)은 필수예요

문제점: 표준 스크립트에서 LLM이 혼란스러워하면, 그건 '블랙박스'나 다름없어요. 뭔가 실패했다는 건 알지만, 어느 구성 요소가 문제를 일으켰는지 전혀 알 수 없죠.

해결책: 팀은 Google Cloud의 OpenTelemetry에 대한 ADK의 최고 수준 지원을 활용했어요. 별다른 설정 없이도 ADK는 전체 실행 흐름에 대한 분산 추적(distributed traces)을 내보내며, 모델 요청, 토큰, 도구 실행 등을 모두 캡처해요.

# ADK에서 OTel 부트스트랩은 한 줄이면 돼요
from adk.observability import configure_telemetry

configure_telemetry(project_id="my-gcp-project", enable_sse_stream=True)

팀은 이 OpenTelemetry 백엔드를 맞춤형 서버 센트 이벤트(SSE) 스트리밍 앱과 연결해서, 사용자에게 세련된 실시간 텔레메트리 대시보드를 효과적으로 제공했어요.

교훈: 실시간 진단 없이는 에이전트를 운영 환경에 투입할 수 없어요. 실제 상황의 문제를 해결하고 개별 구성 요소의 레이턴시를 디버깅하려면 OpenTelemetry 추적(traces)이 꼭 필요해요.

5. 토큰 소모 길들이기 (비용 최적화)

문제점: 에이전틱(agentic) 루프는 비용이 많이 들어요. 에이전트가 오류를 만나서 엄격한 경계 없이 프롬프트를 계속 재시도하면, 몇 분 만에 토큰 예산을 다 태워버릴 거예요.

해결책: ADK의 네이티브 오케스트레이션에 크게 의존함으로써, 팀은 본질적인 비용 최적화 기능을 자동으로 상속받았어요. 프레임워크는 파이썬 코드에 사용자 정의 로직을 작성할 필요 없이, 지수 백오프(exponential backoffs), 타임아웃 경계, 그리고 구성 가능한 재시도 루프를 기본적으로 포함하고 있어요.

교훈: 항상 회로 차단기(circuit breakers)를 설치하세요. 복잡한 try-catch 재시도 루프를 직접 작성하는 대신, ADK나 사용하는 오케스트레이션 프레임워크가 정상적인 실패 처리를 담당하도록 하는 게 좋아요.

코드가 실제로 작동하는 모습을 보고 싶으신가요? 엔진이 실시간으로 재구축되는 걸 직접 보는 것만큼 좋은 건 없죠. 티타늄이 어떻게 리팩토링되었는지 정확히 보려면 여기에서 AI 에이전트 클리닉의 전체 에피소드 1을 시청하세요. 또한 여기에서 티타늄 리포지토리(Repo)를 포크할 수도 있어요.

여러분의 에이전트가 고장 났거나, 버그투성이거나, 프로토타입 지옥에 갇혀 있나요? Google 팀이 도와드리고 싶어요. 다음 에피소드에서 여러분의 에이전트와 아키텍처를 라이브로 진단하고 리팩토링할 기회를 얻으려면 agent-clinic@google.com으로 제출해 보세요!