데이터브릭스, 에이전트 버그 7개로 연 120만달러 손실 찾아

풀어서 설명하면, MCP(모델 컨텍스트 프로토콜)는 AI 에이전트가 지라나 구글드라이브 같은 외부 도구를 호출할 때 쓰는 표준 규격이에요. 데이터브릭스는 모든 MCP 호출 기록을 자동으로 남기는 Unity Gateway 위에, 그 기록을 자연어로 질문해 답을 받는 Genie One을 얹어서 숨어 있던 버그를 찾아냈어요.

트레이싱과 자연어 질의로 한 시간 만에

데이터브릭스는 이 의심을 확인하기 위해 Unity Gateway의 트레이싱과 Genie One을 동원했어요. Unity Gateway는 모든 MCP 도구 호출마다 OpenTelemetry 추적 정보를 자동으로 남기는데, 도구 이름과 인자값, 오류 여부, 토큰 수, 지연 시간, 세션 아이디까지 하나의 표에 기록해요. 새로 계측 코드를 심을 필요 없이, 게이트웨이가 이미 모든 호출 경로에 있었기 때문에 데이터는 바로 쓸 수 있는 상태였어요.

여기에 Genie One을 트레이스 테이블에 연결해 "에이전트가 지라 호출에서 헛도는 것 같다" 같은 막연한 의심을 자연어로 질문했더니, 몇 분 만에 순위가 매겨진 버그 목록이 나왔어요. SQL을 짜고 스키마를 뒤지는 대신 평범한 질문으로 답을 받은 거예요. 한 시간 중 대부분은 쿼리를 작성하는 데가 아니라 그 답을 읽는 데 썼다고 해요. 버그를 찾고 수량화하고 코딩 에이전트로 수정까지 마치는 전체 루프가 약 한 시간이었어요.

지라와 구글드라이브에서 벌어진 일

가장 빈도가 높았던 버그는 지라의 issues.search 도구였어요. 이 도구는 fields 매개변수에 "key,summary,status" 같은 쉼표로 구분된 문자열을 기대했는데, 모델은 JSON 관례상 자연스러운 배열 형태로 값을 넘겼어요. 서버는 배열에 .split()을 호출하다 파이썬 트레이스백만 뱉었고, 에이전트는 이 오류에서 무엇이 잘못됐는지 아무 정보도 얻지 못한 채 같은 실수를 반복하거나 스키마를 다시 읽는 식으로 헤맸어요. 평균 회복까지 12번의 시도가 필요했고, 세션의 30%는 같은 오류를 두 번 이상 겪었어요.

구글드라이브 쪽 버그는 규모가 더 컸어요. drive_file_get 호출의 49.6%가 실패했는데, 모델이 id·name·mimeType처럼 구글 드라이브 API 문서상으로는 그럴듯한 필드 이름을 계속 보냈지만 정작 이 도구의 엔드포인트는 받아주지 않았기 때문이에요.

버그	실패 빈도	회복까지 평균 시도	비고
지라 issues.search	하루 535건	12회	세션 30%가 재발, 연 8만7000달러+4850시간 손실
구글드라이브 drive_file_get	전체 호출의 49.6%	원문에 별도 수치 없음	필드 이름 불일치로 반복 실패

도구는 모델이 실제로 부르는 방식에 맞춰야 한다

표면적인 결론은 "오류 메시지를 더 잘 써라"이고 실제로 데이터도 그걸 뒷받침해요. 하지만 더 흥미로운 질문은 왜 모델이 애초에 도구를 "잘못" 불렀느냐는 거예요. 데이터브릭스는 대부분의 경우 모델이 틀리지 않았다고 봐요. MCP 도구의 시그니처는 일반성을 위해, 그리고 매개변수 설명 하나하나가 모델이 매번 지불하는 토큰 비용이라 일부러 느슨하게 만들어지는 경우가 많아요. 그러다 보니 필드에 대한 명세가 모호하면 모델은 합리적인 추측으로 빈틈을 채우는데, 필드 목록을 JSON 배열로 넘기는 것도 그 합리적인 추측 중 하나였던 거예요. 문제는 서버가 여러 가능한 해석 중 딱 하나만 받아들이고 나머지에는 그냥 멈춰 버렸다는 점이었어요.

"고치는 일보다 무엇을 고쳐야 할지 아는 일이 늘 더 어려웠다"(데이터브릭스 블로그)는 문장이 이 사례의 핵심을 요약해요. 수정 자체는 리스트를 문자열로 바꿔주고, 빠진 매개변수에 기본값을 넣고, 예상치 못한 인자를 그냥 받아들이는 정도의 간단한 작업이었어요.

지금 무엇을 확인해볼 수 있나

데이터브릭스는 지난 8월 4일 Unity AI Gateway를 정식 출시했다고 밝힌 바 있어요. 이번 사례에서 쓰인 트레이싱 기능은 게이트웨이의 통합 트레이스 테이블에서 나오는데, 이 통합 트레이스 테이블 자체는 현재 베타 단계예요. 자기 조직에서 에이전트를 도구와 연결해 쓰는 팀이라면, 먼저 게이트웨이 같은 계층에서 도구 호출 로그를 모으고, 거기에 자연어로 질문할 수 있는 인터페이스를 붙이는 순서로 똑같은 조사를 해볼 수 있어요. 데이터브릭스도 글 말미에 "자기 도구에 에이전트를 붙여 쓴다면 똑같이 해보라. 호출을 추적하고 Genie One에게 뭐가 계속 잘못되고 있는지 물어보라"고 권했어요.

에디터의 시선

이 사례가 중요한 이유는 숫자 자체보다 낭비가 숨어 있던 자리에 있어요. 에이전트가 실패를 조용히 삼키고 재시도로 덮어 버리면, 비용 대시보드에는 그냥 "사용량이 늘었다"로만 찍히거든요. 사람이 쓰던 시스템이라면 오류가 화면에 떠서 누군가 알아챘겠지만, 에이전트는 알아서 우회하니 아무도 경보를 울리지 않아요. 에이전트 지출이 조직 안에서 계속 커지는 지금, 이런 침묵한 실패는 앞으로 더 많은 회사의 예산에서 반복될 구조적인 문제예요.

에이전트를 프로덕션에 붙여 본 팀이라면 이 패턴이 낯설지 않을 거예요. 처음엔 토큰 비용이 예상보다 조금씩 늘어나는 정도로 보이다가, 나중에 로그를 열어 보면 같은 오류가 수백 번 반복되고 있었다는 걸 뒤늦게 발견하는 경우가 많아요. 이번 사례가 보여준 값어치는 결국 트레이싱 인프라가 이미 갖춰져 있었기 때문에 조사 자체가 하루짜리 프로젝트가 아니라 즉석에서 던지는 질문 수준으로 줄어들었다는 데 있어요.

국내에서 사내 에이전트를 운영하는 팀에 주는 실무 교훈은 명확해요. 도구 서버를 만들 때 매개변수 명세를 느슨하게 두는 건 괜찮지만, 그 느슨함을 서버가 감당해야지 크래시로 되돌려주면 안 된다는 거예요. 그리고 에이전트 비용이 늘고 있다면 총합 대시보드만 볼 게 아니라 도구별, 오류별로 지출을 쪼개 보는 습관을 들이는 게 먼저예요. 앞으로 몇 달 안에는 에이전트 도구 서버의 오류 처리 방식 자체가 벤더 선택과 내부 감사의 기준으로 자리 잡을 가능성이 커요.