---
title: "에이전트 앱을 프로덕션에 올리면 진짜 어디서 터지나 묻는 글"
published: 2026-05-31T02:07:38.000Z
canonical: https://jeff.news/article/3408
---
# 에이전트 앱을 프로덕션에 올리면 진짜 어디서 터지나 묻는 글

작성자는 대량의 전사 데이터를 처리하는 에이전트 팀을 만들다가, 중간 단계 실패가 전체 리포트 생성을 깨뜨리는 문제를 겪었다. 한 달 동안 작업을 내구 실행 구조로 다시 짰지만, 장애 복구, 진행률 표시, 모니터링, 사람 개입까지 어디까지 직접 만들고 어디서 사야 하는지 묻고 있다.

- 이 글은 에이전트 앱을 프로덕션에 올려본 사람들의 전쟁담을 묻는 글임. 질문 자체가 꽤 현실적임
  - 작성자는 회사에서 리포트 생성을 위해 에이전트 팀을 만들고 있음
  - 구조는 대량의 전사 데이터를 처리하기 위해 많은 하위 에이전트로 작업을 팬아웃하는 방식
  - 문제는 중간에 API 호출이 실패하거나 메모리가 부족해지면 연쇄 오류가 나면서 전체 생성이 깨진다는 것

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

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

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

> [!WARNING]
> 에이전트 데모는 한 번 성공하면 끝이지만, 프로덕션 에이전트는 실패한 9번째 단계를 어떻게 다시 살릴지가 제품 품질을 결정함.

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

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

---

## 기술 맥락

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

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

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

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

## 핵심 포인트

- 에이전트가 12단계 중 9단계에서 실패했을 때 재시도와 복구를 어떻게 설계할지가 핵심 질문이다
- 작성자는 하위 에이전트를 많이 띄워 전사 데이터를 처리하는 구조에서 연쇄 오류와 가시성 부족을 겪었다
- 인프라 구축 비용이 실제 에이전트 로직 개발보다 얼마나 커지는지 커뮤니티 경험을 묻고 있다

## 인사이트

요즘 에이전트 앱의 어려움은 똑똑한 프롬프트보다 오래 걸리는 작업을 끝까지 살리는 운영 문제에 가깝다. 내구 실행, 관측성, 휴먼 인 더 루프, 라이브 진행률은 이제 데모와 프로덕션을 가르는 선이 됐다.