01 / OhMoney · 멀티에이전트 콘텐츠 서비스
에이전트 20개를 혼자 운영하려면
실패부터 설계해야 했습니다
쇼츠 콘텐츠의 수집·기획·제작·게시·분석을 사람 손 없이 끝까지 돌리는 서비스입니다. TTS·이미지·영상 같은 외부 API는 제각각 실패했습니다. LLM 호출은 하루 수백 건씩 쌓였고 결과물 품질은 들쭉날쭉했습니다. 혼자 운영하는 이상 사람이 매번 판단하는 자리가 곧 병목이었습니다.
- 비용은 등급으로 통제했습니다
- 토픽마다 0~100점을 자동으로 매겨 70점 미만은 버리고 93점 이상만 상위 모델에 보냅니다. 전부를 좋은 모델로 돌리는 대신 될 만한 콘텐츠에만 비용을 씁니다.
- 실패는 격리하고 그 지점부터 다시 돌립니다
- 공정을 Plan → Asset → Render → Package → Publish 다섯 단계로 끊고 단계마다 타임아웃·재시도·Fallback·DLQ를 뒀습니다. TTS가 죽어도 렌더링은 멈추지 않습니다.
- 지표는 하나만 남겼습니다
- 조회수·좋아요 대신 EV(기대 수익) 하나를 North Star로 고정하고 다음 제작의 자원 배분 기준으로 삼았습니다. 조회수가 높아도 EV가 낮으면 늘리지 않습니다.
실행 이력 저장 · Prometheus / Grafana 모니터링
이 사례가 보여주는 것이 서비스에서 배운 것은 AI 제품의 신뢰성이 성공률이 아니라 실패를 얼마나 빨리 드러내고 싸게 복구하느냐에서 온다는 점입니다. 그 구조를 설계만 하지 않고 직접 만들었습니다.
직접 구현한 범위와 운영 방식
프레임워크에 기대지 않은 구현
기능별 에이전트와 프롬프트, JSON Schema 기반 도구 호출을 상위 프레임워크 없이 직접 구현했습니다. LangGraph는 분기와 흐름 제어에만 썼습니다. 배치당 8슬롯, 같은 토픽은 최대 3개로 제한해 다양성을 지켰습니다.
운영이 가능한 구조
Python·FastAPI·Redis(ARQ)·PostgreSQL 위에 백엔드 모듈 30개 이상을 올리고 Docker 9컨테이너로 돌립니다. 실행 상태와 이력은 PostgreSQL에 남기고 Prometheus·Grafana로 지켜봅니다. 텔레그램 봇 명령을 기존 배치와 같은 큐·파이프라인에 붙여 긴급 재실행과 장애 복구를 처리했습니다.
