PDF 변환 에이전트 턴 제한으로 응답 속도 개선

PDF 문서 추출 및 번역 기능에서 에이전트의 multi-turn 호출을 단일 턴으로 제한하는 최적화 작업을 했다. src/lib/anthropic.ts에서 maxTurns를 1로 캡핑해 에이전트 오버헤드를 크게 줄일 수 있었다.

초기 설계와 문제 인식

PDF 추출/번역 기능을 처음 구현할 때는 에이전트에 multi-turn 대화 능력을 주는 것이 당연해 보였다. 사용자가 "이 섹션을 다시 번역해 줘" 같은 후속 요청을 할 수 있도록, 또는 에이전트가 자체적으로 판단해 추가 검증을 시도할 수 있도록. 하지만 실제 운영에 들어가 보니 문제가 명확했다.

각 turn마다 전체 문맥(이전 PDF 내용, 번역 결과, 에이전트의 추론 기록)을 다시 전달해야 하고, API 레이턴시도 turn 수만큼 누적되고, 결국 사용자에게 보이는 응답 시간은 불필요하게 늘어났다. 단순히 API 호출 비용도 문제지만, "이 기능이 왜 이렇게 느린가"라는 팀의 자연스러운 질문이 나오기 시작했다.

구조상 오버헤드 분석

다시 생각해 보니 PDF 문서 한 번의 추출/번역에서 굳이 다중 턴이 필요한가? 우리 API 스펙은 이미 단일 프롬프트로 추출과 번역을 동시에 처리할 수 있는 수준이었다. 에이전트가 "더 정교한 판단을 위해 재시도한다"는 건 대부분 의미 있는 개선이 아니라 과도한 신중함일 뿐이었다.

maxTurns = 1로의 변경

결정은 명확했다. src/lib/anthropic.ts의 에이전트 초기화 코드에서 maxTurns: 1을 명시적으로 설정했다:

// 이전: turn 제한 없음 (또는 기본값)
const agent = createAgent({
  model: "claude-opus",
  tools: [extractTool, translateTool]
})

// 변경 후: 단일 턴 제한
const agent = createAgent({
  model: "claude-opus",
  tools: [extractTool, translateTool],
  maxTurns: 1
})

이제 에이전트는 초기 API 호출 1회로 모든 결과를 내야 한다. 추가 검증이나 self-correction 기회가 없다는 뜻이지만, 우리의 문서 구조와 요청 형식이 충분히 명확해서 이게 오히려 더 안정적이었다.

팀 관점: 에이전트 설계의 균형

이 작업을 통해 깨달은 게 하나 있다. 에이전트 능력 = 항상 좋은 것이 아니다라는 점.

무제한 turn은 "더 똑똑한 에이전트"처럼 들리지만, 실제로는 비용과 응답 시간이 선형으로 증가하고, 동시 사용자가 늘어나면 시스템 부하도 함께 커진다. 특히 동기적 API 호출(사용자가 결과를 기다려야 하는 구조)에서는 더욱 그렇다.

비슷한 상황을 만날 때 고려할 점:

• 필요성 검증: 정말 다중 turn이 필요한가? 단일 회차로 충분한가?
• 실측 데이터: "에이전트가 더 정교한 판단을 한다"는 가정을 실제로 검증했는가?
• 운영 비용: 응답 시간 1초 단축이 전체 시스템에 주는 영향 (동시성, 비용, 배터리)
• 사용자 경험: 1회 실패보다 3초 지연이 더 나쁠 수 있다.

결국 "강력함"과 "빠름" 사이의 트레이드오프에서, 우리 서비스 특성과 사용자 행동에 맞는 지점을 찾는 게 팀장의 역할이다.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 노이즈캔슬링헤드폰 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.