단 한 시간 만에 연간 100만 달러에 달하는 AI 에이전트의 불필요한 지출을 제거한 방법

Databricks 엔지니어들은 업무를 간소화하고 가속화하기 위해 AI 에이전트에 크게 의존하고 있습니다. 이에 따라 이러한 에이전트는 다양한 파운데이션 모델뿐만 아니라 관련 아티팩트(예: 시스템 로그, 사용량 테이블, 지원 티켓, 위키)에 액세스할 수 있는 도구를 갖춘 MCP 서버에도 액세스해야 합니다. 이전 블로그에서는 대규모로 AI 비용을 관리하려면 모델 선택뿐만 아니라 에이전트가 도구를 사용하는 방식도 최적화해야 한다고 설명했습니다. 이번 포스트에서는 에이전트의 도구 사용에서 비용 절감 기회를 어떻게 모색했는지, 그 과정에서 겪은 어려움은 무엇이었는지, 그리고 Unity Gateway의 OTel 트레이싱을 통해 분석부터 연간 120만 달러의 비용 절감에 이르는 과정을 어떻게 단 한 시간으로 단축할 수 있었는지 설명합니다.

개발자가 자체 에이전트를 구축할 수 있도록 지원한 것은 생산성을 크게 높여주는 계기가 되었지만, 사용량이 급증하면서 비용도 함께 증가하는 문제에 직면했습니다. 저희는 몇 가지 최적화 방안을 조사하기 시작했고, 그중 하나는 실패하는 도구 호출의 숨겨진 비용에 대한 의구심이었습니다. 구체적으로 말하자면, 도구가 오작동할 때 이를 호출하는 에이전트는 명확한 에러를 내며 실패하는 경우가 드뭅니다. 대신 에이전트는 재시도하고, 추측하고, 결국 문제를 우회하여 해결하려고 시도하면서 그 과정에서 조용히 토큰과 개발자의 시간을 낭비하게 됩니다. 이러한 유형의 낭비는 위험합니다. 외부에서 보기에는 작업이 여전히 완료되는 것처럼 보이고, 전체 비용 대시보드에는 토큰 소비량이 10% 증가한 것으로 표시되어 단순히 사용량이 늘어난 것으로 쉽게 오해할 수 있기 때문입니다. 

저희는 Unity Gateway의 트레이싱 기능과 Genie One을 사용하여 에이전트 플릿에서 이러한 의구심을 조사했습니다. 그 결과, 도구 서버에서 연간 약 49만 9천 달러의 토큰 낭비와 연간 약 12,000시간의 에이전트 대기 시간(엔지니어링 시간)을 유발하는 7개의 작은 버그를 발견했습니다. 전체적으로 이는 연간 약 120만 달러의 생산성 손실로 추정됩니다. 

이 7가지 버그를 모두 찾아내고, 규모를 파악하고, 수정하는 데는 약 한 시간이 걸렸습니다. 이 포스트에서는 저희가 거친 과정과 이를 통해 에이전트용 도구 구축에 대해 무엇을 배웠는지 설명합니다.

AI 에이전트 및 MCP 활동을 모니터링하는 방법

Databricks에서 코딩 및 내부 워크플로우를 위해 AI 에이전트를 처음 광범위하게 배포했을 때는 에이전트의 도구 호출과 전반적인 활동에 대한 가시성이 부족하여 비용을 관리하거나 완전히 이해하는 것이 불가능했습니다. 이를 해결하기 위해 저희는 Unity Gateway를 활용했습니다. Unity Gateway는 도구 이름, 인수, 에러(있는 경우), 토큰 수, 지연 시간, 호출을 서로 연결하는 세션 ID를 포함하여 모든 MCP 도구 호출에 대해 OpenTelemetry 트레이스를 자동으로 생성합니다. 이러한 트레이스는 특정 시간 범위 동안 에이전트가 수행한 작업을 정확히 기록하는 단일 테이블에 저장됩니다. 새로운 인스트루멘테이션이 필요하지 않았고, 게이트웨이가 이미 모든 호출의 경로에 위치해 있으므로 데이터를 즉시 사용할 수 있었습니다.

덕분에 AI 에이전트 비용 관리가 더욱 실질적으로 가능해졌습니다. 단순히 누적된 토큰 소비량만 보는 대신, 낭비된 비용의 원인을 특정 도구, 에러 및 에이전트 세션별로 파악할 수 있게 되었습니다.

이제 데이터를 사용할 수 있으므로 다음 단계는 탐색입니다.

• 어떤 도구 에러가 가장 많이 재발하는가?
• 에이전트가 에러를 만났을 때 복구하는 데 몇 번의 턴이 걸리는가?
• 각 에러로 인해 소모되는 토큰과 실제 대기 시간은 얼마인가?

보통 이러한 분석에서 가장 까다롭고 시간이 많이 걸리는 부분은 SQL 작성과 스키마 탐색입니다. 하지만 Genie One을 사용하면 트레이스 테이블을 지정하고 일상적인 영어로 바로 이 질문들을 던지기만 하면 몇 분 만에 답변을 얻을 수 있었습니다. 저희가 쓴 한 시간 중 대부분은 쿼리를 작성하는 대신 이러한 답변을 읽는 데 소요되었습니다.

트레이스가 밝혀낸 사실: MCP 도구 실패가 AI 에이전트 비용을 증가시키는 방식

Genie One은 "에이전트가 Jira 호출에서 헤매는 것 같다"는 막연한 의구심을 단 몇 분 만에 순위가 매겨지고 수량화된 버그 목록으로 바꾸어 놓았습니다. 다음은 단 하루(24시간) 동안의 데이터를 보여주는 예시로, Jira 및 Google Drive/Docs 도구 서버의 버그를 나타냅니다.

하루에 535번이나 실패하여 가장 빈번하게 발생한 버그를 예로 들어보겠습니다. Jira의 issues.search 도구는 fields 매개변수를 사용하며, 서버는 다음과 같이 작동했습니다.

서버는 "key,summary,status"와 같이 쉼표로 구분된 문자열을 예상했습니다. 하지만 배열은 "필드 목록"을 나타내기에 의미론적으로 자연스러운 JSON 타입이며, 모델은 JSON 규칙에 대한 배경 지식과 동일한 세션의 인접한 도구 호출을 통해 이를 추론했습니다. 따라서 모델은 합리적인 호출자라면 전달했을 다음과 같은 구조화된 값을 전달했습니다.

리스트에는 .split()이 없기 때문에 서버는 'list' object has no attribute 'split' 에러를 발생시켰습니다. 이는 에이전트에게 무엇이 잘못되었는지 전혀 알려주지 않는 가공되지 않은 Python 트레이스백이었습니다. 이에 따라 에이전트는 다시 추측해야 했습니다. 때로는 동일한 리스트를 재시도하여 동일한 방식으로 실패했고, 때로는 스키마를 다시 읽거나 시행착오에 의존했습니다. 복구하는 데 평균 12번의 턴이 걸렸으며, 세션의 30%는 이 에러를 두 번 이상 겪었습니다. 단 하나의 .split() 호출로 인해 연간 약 8만 7천 달러의 토큰 비용과 4,850시간의 에이전트 대기 시간이 낭비되고 있었던 것입니다.

Google Drive의 Invalid field selection 에러는 발생 빈도 면에서 훨씬 더 놀라웠습니다. 전체 drive_file_get 호출의 49.6%가 실패했는데, 이는 모델이 도구의 엔드포인트에서 허용하지 않는 유효해 보이는 Drive API 필드 이름(id, name, mimeType)을 계속 전달했기 때문입니다.

진정한 교훈: AI 에이전트 및 LLM을 위한 MCP 도구를 설계하는 방법

여기서 얻을 수 있는 명백한 교훈은 "더 나은 에러 메시지를 작성하라"는 것이며, 데이터가 이를 뒷받침합니다. 복구 비용은 에러 메시지의 품질과 거의 완벽하게 비례합니다:

하지만 "좋은 에러 메시지가 도움이 된다"는 것은 이미 다 아는 사실입니다. 더 흥미로운 질문은 애초에 모델이 왜 이러한 도구들을 "잘못" 호출했는가 하는 점입니다. 대부분의 경우, 모델은 잘못 호출하지 않았습니다.

MCP 도구 시그니처는 종종 의도적으로 불완전하게 정의됩니다. 여기에는 의도가 있습니다. 부분적으로는 범용성을 위해서이고, 또 다른 부분은 컨텍스트 토큰을 절약하기 위해서입니다. 모든 매개변수 설명은 모델이 호출할 때마다 지불해야 하는 토큰 비용을 발생시키기 때문입니다. 그 결과, 시그니처의 필드 정의가 모호할 때 모델은 합리적인 추측으로 그 공백을 메우며, 필드 목록에 대해 JSON 배열은 합리적인 추측이 됩니다. 버그는 모델이 도구를 잘못 호출한 데서 발생한 것이 아닙니다. 서버가 여러 합리적인 해석 중 단 하나만 수용하고 나머지에 대해서는 크래시를 일으켰기 때문입니다.

따라서 설계 원칙은 반사적인 방식과는 반대입니다. 즉, 에이전트용 도구는 LLM이 자연스럽게 호출하는 방식에 맞춰 조정되어야 합니다. 예를 들어, 목록을 문자열로 강제 변환하거나, 생략된 매개변수에 기본값을 제공하거나, 예상치 못한 인수를 흡수하는 등의 방식입니다. 불완전하게 정의된 시그니처는 유연성에 대한 약속이며, 도구는 작성자가 염두에 둔 단 하나의 형태와 일치하지 않는 첫 번째 입력에서 크래시를 일으키기보다는 수신 측에서 그 약속을 지켜야 합니다.

쉬운 부분: 1시간 만에 낭비되는 AI 에이전트 비용을 줄인 방법

수정 자체는 간단했으며 이 이야기에서 흥미로운 부분은 아닙니다. Genie One이 수정해야 할 오류와 모델이 실제로 전송한 내용에 대한 순위 목록을 제공한 후에는, 코딩 에이전트를 통해 도구 서버 전체에 수정을 빠르게 적용할 수 있었습니다. 전체 루프(찾기, 정량화, 수정)는 약 1시간이 걸렸습니다.

까다롭고 비용이 많이 드는 단계는 수정을 작성하는 것이 아니었습니다. 바로 무엇을 수정해야 하는지 아는 것이었습니다. 트레이싱(Tracing)과 Genie One 덕분에 이 단계는 연구 프로젝트에서 말로 직접 물어볼 수 있는 질문으로 바뀌었습니다.

루프 닫기: AI 에이전트 비용을 지속적으로 모니터링하고 줄이는 방법

더 많은 실제 작업이 에이전트로 이동함에 따라, 감지되지 않는 도구 실패는 "사용량 증가" 뒤에 숨어 아무에게도 알림을 보내지 않는 주요 비용 요인이 됩니다. 이를 포착하는 루프는 저렴하고 반복 가능합니다. Unity Gateway는 에이전트 동작을 관찰 가능하게 만들고, Genie One은 SQL 없이도 해당 동작을 쿼리할 수 있게 해줍니다.

이를 통해 팀은 AI 에이전트를 모니터링하고, MCP 도구 실패를 진단하며, 낭비되는 AI 비용을 줄일 수 있는 반복 가능한 방법을 확보할 수 있습니다. 자체 도구에서 에이전트를 실행하는 경우에도 동일하게 수행해 보세요. 호출을 추적하고 Genie One에 무엇이 계속 잘못되고 있는지 물어보세요.

Genie One을 사용한 Unity Gateway 트레이스 분석 시작하기

Unity Gateway는 정식 출시(Generally Available)되었으며, 이제 베타 버전인 통합 트레이스 테이블을 사용하여 모든 AI 활동을 모니터링할 수 있습니다. 시작하는 방법은 문서를 참조하세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)