WORXPHERE

🤖 Career Agent 개발기 (5) : Langfuse와 Token 비용 최적화

좋은 에이전트는 좋은 모델만으로 만들어지지 않습니다. 관찰하고, 측정하고, 개선하는 과정이 필요합니다

🚀 들어가며

마지막 편입니다. 이번 글에서는 Career Agent 개발 과정에서 실전에 적용했던 다양한 기법들을 공유하려 합니다. Langfuse를 활용한 에이전트 동작 분석, 대화 메모리 관리, 응답 속도 최적화, 그리고 대량 배치 작업의 비용 절감까지. 에이전트의 품질을 한 단계 끌어올리는 데 기여한 것들입니다.

🔍 Langfuse: 에이전트의 블랙박스를 들여다보다

Agent 개발에서 가장 답답한 순간은 에이전트가 이상한 답변을 했는데, 왜 그런 답변을 했는지 알 수 없을 때입니다.

• “왜 이 Tool을 선택했지?”
• “왜 저 파라미터를 그렇게 채웠지?”
• “instruction을 바꿨는데 실제로 효과가 있나?”

전통적인 소프트웨어는 로그를 보면 무슨 일이 일어났는지 파악할 수 있습니다. 하지만 LLM의 의사결정 과정은 블랙박스이기 때문에, 로그만으로는 충분하지 않았습니다.

Langfuse는 LLM 애플리케이션을 위한 observability 플랫폼입니다. 모든 LLM 호출을 추적하고, 입력/출력을 기록하며, 비용과 latency를 측정합니다.

실제 개발에서 활용한 디버깅 사이클을 하나 소개합니다.

Step 1: 문제 발견

Step 2: Langfuse에서 Trace 확인

Step 3: Instruction 수정

Step 4: 재배포 후 Trace 재확인

이런 사이클을 반복하면서 Langfuse로 다음 지표들을 지속적으로 측정했습니다.

• Latency per span: 어떤 에이전트/Tool이 병목인지 파악
• Token usage: 비용 최적화 대상 식별
• Tool selection 패턴: 잘못된 Tool 선택 빈도 추적
• Error rate: Tool 실패율, 재시도 빈도
• Conversation flow: 사용자가 목표 달성까지 걸리는 턴 수

search_companies와 search_web이 혼용되는 패턴을 Trace에서 발견했는데, 두 Tool의 description이 너무 유사한 것이 원인이었습니다. Description을 명확히 구분한 후, 잘못된 Tool 선택이 80% 감소했습니다. 또한 Token usage 분석을 통해 conversation_agent의 instruction에 사용하지 않는 예시와 중복된 설명이 포함되어 있다는 것을 확인하고, 정리하여 토큰 사용량을 줄일 수 있었습니다.

⚡ 응답 속도와 비용 최적화

사용자는 빠른 응답을 원합니다. 특히 검색 결과를 기다리는 시간은 체감상 더 길게 느껴집니다.

기능이 아무리 좋아도 응답이 느리면 사용자는 기다려주지 않는다는 것. 비용도 마찬가지입니다. 아무리 정확한 결과를 만들어도, 비용이 과도하면 서비스로 유지할 수 없습니다. 이를 개선하기 위해 적용한 방법들을 공유합니다.

작업별 모델 선택

모든 작업에 최신 모델을 사용할 필요는 없습니다. 작업의 복잡도에 맞는 적절한 모델을 선택하면 비용과 속도 모두 최적화할 수 있습니다.

프롬프트 캐싱 (Prompt Caching)

LLM API를 호출할 때, 매 요청마다 프롬프트의 모든 토큰을 처음부터 다시 처리한다는 사실을 알고 계셨나요? 시스템 프롬프트, Tool 정의, 퓨샷 예시 등 매번 동일하게 반복되는 부분도 매 호출마다 새로 연산됩니다. 프롬프트 캐싱은 이 반복 연산을 줄여주는 기술입니다.

동작 원리는 이렇습니다. LLM은 입력 토큰을 처리할 때 트랜스포머의 어텐션 레이어에서 KV(Key-Value) 프로젝션을 계산합니다. 프롬프트 캐싱은 이전 요청과 동일한 접두사(prefix)가 감지되면, 이미 계산된 KV 값을 재사용하여 중복 연산을 건너뜁니다. OpenAI에서는 이 기능이 별도 설정 없이 자동으로 적용되며, 캐시가 적중하면 입력 토큰 비용 50% 할인과 최대 80% 지연 시간 감소 효과를 얻을 수 있습니다.

핵심 조건은 접두사가 정확히 일치해야 한다는 것입니다. 프롬프트의 첫 번째 토큰부터 순서대로 비교하여, 한 글자라도 달라지는 시점부터는 캐시가 적용되지 않습니다. 그래서 시스템 프롬프트, Tool 정의처럼 변하지 않는 정적 콘텐츠를 프롬프트의 앞부분에, 사용자 메시지처럼 매번 달라지는 동적 콘텐츠를 뒷부분에 배치해야 캐시 적중률을 극대화할 수 있습니다.

Career Agent 같은 대화형 에이전트에서는 어떨까요? 시스템 프롬프트와 Tool 정의는 매 턴마다 동일하므로, 이 부분은 캐시가 적중합니다. 하지만 그 뒤에 붙는 대화 히스토리는 턴이 진행될수록 계속 길어지기 때문에, 히스토리 이후의 부분은 매번 새로 처리해야 합니다.

즉, 시스템 프롬프트 + Tool 정의 부분의 캐시 효과는 누릴 수 있지만, 대화가 길어질수록 캐시되지 않는 히스토리 부분의 비중이 점점 커집니다. 또한 캐시의 유효 시간이 비활성 상태에서 5~10분 정도로 짧기 때문에, 사용자가 잠시 대화를 멈추면 시스템 프롬프트 캐시마저 만료될 수 있습니다. 결국 대화형 서비스에서는 전체 입력 토큰 대비 캐시 적중 비율이 낮아, 비용 절감 효과가 크지 않았습니다.

프롬프트 캐싱이 가장 빛을 발하는 곳은 고정된 프롬프트로 반복 호출하는 패턴입니다. 동일한 시스템 프롬프트로 대량의 분류 작업을 처리하거나, 긴 문서를 컨텍스트에 넣고 여러 질문을 던지는 경우처럼 접두사의 대부분이 변하지 않는 상황에서 효과가 극대화됩니다.

이벤트 압축(Event Compaction)

프롬프트 캐싱이 대화형 서비스에서 제한적이라면, 입력 토큰 자체를 줄이는 방법은 없을까요? 앞서 메모리 섹션에서 언급한 이벤트 압축(Event Compaction)이 바로 그 해답입니다.

대화형 에이전트는 매 턴마다 이전 대화 히스토리 전체를 프롬프트에 포함합니다. 대화가 20턴만 넘어가도 히스토리만으로 수천 토큰을 소모하게 되고, 이는 곧 비용 증가와 응답 지연으로 이어집니다. 이벤트 압축은 과거 대화를 LLM으로 요약하여, 긴 히스토리를 짧은 요약으로 대체합니다.

일반적인 데이터 압축(compression)과 달리, 원본 복원이 불가능한 비가역적 요약입니다. 손실 압축이지만 핵심 정보는 유지됩니다. LLM이 보는 컨텍스트는 다음과 같이 변합니다.

원본 이벤트는 삭제되지 않고, LLM 컨텍스트 구성 시에만 CompactedEvent로 대체됩니다. 요약 품질이 에이전트 성능에 직접 영향을 미치므로, 구조화된 요약 포맷을 사용합니다.

요약 포맷

특히 Identifiers는 정확히 추출해야 합니다. 이전 검색의 saved_search_id를 잃어버리면 "아까 그 결과에서…"라는 요청을 처리할 수 없습니다.

정리하면, 프롬프트 캐싱은 시스템 프롬프트처럼 변하지 않는 접두사의 연산 비용을 줄여주고, 이벤트 압축은 대화 히스토리처럼 계속 늘어나는 동적 부분의 토큰 수 자체를 줄여줍니다. 두 기법은 서로 보완적인 관계로, 함께 적용하면 대화형 에이전트의 입력 토큰 비용을 효과적으로 관리할 수 있습니다.

Batch API로 대량 작업 비용 절감

실시간 응답이 필요하지 않은 대량 작업에는 OpenAI Batch API를 활용하면 비용을 크게 줄일 수 있습니다. Batch API는 여러 요청을 .jsonl 파일로 묶어 비동기로 처리하는 방식으로, 동일한 모델을 사용하면서도 동기 API 대비 50% 할인된 비용으로 처리할 수 있습니다.

Career Agent에서는 사전에 대량의 채용공고 데이터를 분석하거나, 임베딩을 생성하거나, 대규모 평가(evaluation)를 실행하는 등 즉각적인 응답이 필요 없는 작업들이 있었습니다. 이런 작업들을 Batch API로 전환하면 비용 절감 효과가 큽니다.

배치당 최대 50,000건의 요청을 처리할 수 있으며, 24시간 내에 완료됩니다. 실시간 서비스에는 적합하지 않지만, 사전 데이터 가공이나 대규모 평가처럼 시간 여유가 있는 작업에서는 동일한 품질의 결과를 절반의 비용으로 얻을 수 있습니다.

👋 돌아보며

6주라는 시간이 길다면 길고 짧다면 짧았습니다. 돌아보면 매일이 새로운 도전이었고, 그만큼 배운 것도 많았습니다. 5편에 걸쳐 다뤘던 내용 중 가장 기억에 남는 것들을 정리하며 마무리하겠습니다.

• Agent 개발은 전통적인 소프트웨어 개발과 다릅니다. 입력과 출력이 결정론적이지 않고, 같은 입력에도 다른 결과가 나올 수 있습니다. 처음에는 “이게 개발이 맞나?”라는 의문이 들었지만, 프롬프트 한 줄이 에이전트의 판단을 완전히 바꾸는 경험을 반복하면서 그 힘을 실감했습니다.
• 프롬프트 엔지니어링만 잘해도 Agent 성능의 대부분이 결정됩니다. 영어로 작성하는 것만으로 토큰 사용량이 40% 이상 줄었고, 서술형 대신 XML이나 마크다운 같은 구조화된 포맷을 사용하니 LLM의 이해도가 눈에 띄게 올라갔습니다. CoT로 단계별 사고를 유도하고, ReAct 패턴으로 추론-행동-관찰 사이클을 명시적으로 설계한 것이 에이전트의 체계적인 동작에 큰 도움이 되었습니다.
• 방어적 프롬프팅은 서비스 배포의 필수 조건입니다. 프롬프트 추출, 탈옥, 프롬프트 주입 등 다양한 공격 유형에 대비해야 했습니다. 프롬프트 수준의 방어만으로는 불완전하기 때문에, 입력 필터링과 출력 검증 같은 시스템 수준의 다층 방어를 함께 갖추는 것이 중요했습니다.
• Tool Description의 품질이 곧 Agent의 품질입니다. 처음에는 함수 이름과 파라미터 타입만 정의하면 될 줄 알았지만, description이 부실하면 Tool Selection Error와 Parameter Hallucination이 빈번하게 발생했습니다. Anthropic이 강조하듯, 극도로 상세한 description을 작성하는 것이 도구 성능에서 가장 중요한 요소였습니다.
• Multi-Agent 아키텍처는 복잡성을 관리하는 좋은 방법입니다. 단일 에이전트의 프롬프트가 비대해지면서 역할 혼란과 유지보수 악몽을 겪었고, Intent Router + Specialist 패턴으로 역할을 분리했을 때 비로소 토큰 효율, 독립적 개선, 모델 최적화가 가능해졌습니다.
• RAG는 에이전트의 지식 한계를 극복하는 핵심 기술입니다. 수만 건의 채용공고를 프롬프트에 담을 수 없기에, 청킹 전략, 하이브리드 검색, 질의 재작성 등을 통해 각 질의에 적절한 컨텍스트를 구성하는 법을 배웠습니다. 특히 하이브리드 검색에서 RRF로 여러 검색기의 결과를 종합하는 방식이 단일 검색기보다 훨씬 균형 잡힌 결과를 만들어냈습니다.
• Observability는 선택이 아닌 필수입니다. LLM의 블랙박스 특성상, Langfuse 같은 도구 없이는 에이전트가 왜 그런 판단을 했는지 알 수 없었습니다. Trace 분석을 통해 잘못된 Tool 선택 패턴을 발견하고, 토큰 과다 사용을 식별하는 등 “데이터”로 의사결정할 수 있게 된 것이 개발 품질을 근본적으로 바꿔놓았습니다.

5편에 걸쳐 Career Agent 개발기를 공유했습니다. Multi-Agent부터 프롬프트 엔지니어링, Tool Description, RAG, 그리고 실전에서 적용한 다양한 기법들까지. 처음 Agent 개발을 시작했을 때의 막막함이 아직도 생생합니다. 하지만 프롬프트 한 줄의 힘을 체감하고, Tool Description의 중요성을 깨닫고, RAG로 에이전트에게 지식을 전달하는 법을 배우면서, 점차 Agent 개발이라는 새로운 영역에 대한 확신이 생겼습니다.

AI Agent 개발을 시작하시는 분들께 이 글이 조금이나마 길잡이가 되었으면 합니다. 끝까지 읽어주셔서 진심으로 감사합니다!