에이전트 앱을 프로덕션에 올리면 진짜 어디서 터지나 묻는 글

• 이 글은 에이전트 앱을 프로덕션에 올려본 사람들의 전쟁담을 묻는 글임. 질문 자체가 꽤 현실적임

  • 작성자는 회사에서 리포트 생성을 위해 에이전트 팀을 만들고 있음
  • 구조는 대량의 전사 데이터를 처리하기 위해 많은 하위 에이전트로 작업을 팬아웃하는 방식
  • 문제는 중간에 API 호출이 실패하거나 메모리가 부족해지면 연쇄 오류가 나면서 전체 생성이 깨진다는 것

• 가장 큰 고통은 실패 자체보다 실패가 어디서 났는지 거의 안 보인다는 점임

  • 개별 단계 하나가 터졌는데 전체 리포트 생성이 무너짐
  • 작성자는 이 문제 때문에 지난 한 달 동안 개별 작업을 DBOS 기반 내구 실행 작업으로 다시 작성했다고 함
  • 그래도 이게 최선인지, 다른 팀들은 뭘 쓰는지 궁금해하는 상황임

sequenceDiagram
    participant 사용자
    participant 메인에이전트
    participant 하위에이전트
    participant 외부API
    participant 내구실행저장소
    사용자->>메인에이전트: 리포트 생성 요청
    메인에이전트->>하위에이전트: 전사 데이터 분석 작업 분산
    하위에이전트->>외부API: 필요한 데이터 호출
    외부API-->>하위에이전트: 오류 또는 지연 반환
    하위에이전트->>내구실행저장소: 실패 지점과 상태 저장
    메인에이전트->>사용자: 진행률과 복구 상태 표시

• 작성자가 던진 핵심 질문은 에이전트가 12단계 중 9단계에서 실패했을 때 어떻게 처리하냐는 것임
  • 해당 단계만 재시도할지, 부분 결과를 저장하고 이어갈지, 사용자에게 사람 개입을 요청할지 결정해야 함
  • 이건 단순한 프롬프트 문제가 아니라 워크플로 엔진, 큐, 상태 저장, 재시도 정책의 문제에 가까움

• 또 하나의 질문은 인프라에 들어간 시간이 정상 범위냐는 것임

  • 내구성, 모니터링, 사람 개입, 실시간 사용자 인터페이스에 들어간 엔지니어 주가 실제 에이전트 로직보다 커지는 게 흔한지 묻고 있음
  • 이 질문이 중요한 이유는 에이전트 앱에서 ‘모델이 뭘 할지’보다 ‘실패했을 때 어떻게 운영할지’가 더 오래 걸릴 수 있기 때문임

• 구매할지 직접 만들지도 고민 포인트로 올라옴

  • 후보로 언급된 도구는 랭스미스, 템포럴, 브레인트러스트 같은 에이전트·워크플로·평가 스택
  • 작성자는 어떤 기능이 있어야 직접 만드는 대신 돈을 낼 만한지, 실제로 비용 항목으로 인정받은 도구가 무엇인지 묻고 있음

기술 맥락

• 이 글에서 핵심 선택은 에이전트 로직을 그냥 함수 호출 묶음으로 두지 않고 내구 실행 작업으로 바꾸는 거예요. 긴 워크플로는 중간에 반드시 실패한다고 봐야 해서, 어느 단계까지 끝났는지를 저장하지 않으면 매번 처음부터 다시 돌리게 되거든요.

• DBOS나 템포럴 같은 도구가 나오는 이유는 재시도, 타임아웃, 상태 저장, 보상 작업을 앱 코드 안에 흩뿌리면 금방 감당이 안 되기 때문이에요. 특히 하위 에이전트를 많이 띄우는 구조에서는 실패가 하나의 호출이 아니라 전체 그래프의 문제로 번져요.

• 사용자에게 진행률을 보여주는 것도 단순한 UI 작업이 아니에요. 백엔드 워크플로 상태, 각 하위 작업의 완료 여부, 실패 원인, 재시도 가능 여부가 구조적으로 기록되어 있어야 화면에 믿을 만한 진행 상황을 보여줄 수 있어요.

• 그래서 build-vs-buy 질문이 꽤 날카로워요. 에이전트 품질을 높이는 일과 에이전트 운영 플랫폼을 만드는 일이 분리되지 않으면, 팀은 모델 기능보다 주변 인프라에 훨씬 많은 시간을 쓰게 될 수 있어요.