Claude Code가 4만 건 계약 분석에서 합계를 약 80만 달러 틀린 원인은 연결되지 않은 부속 계약서였습니다 | DAKER 커뮤니티

AlixPartners는 Claude Code에 인수합병 뒤 조달 분석을 맡겼고, 처음 나온 답은 보기에 완전했지만 계약 총액이 약 80만 달러 틀렸고 갱신 자동 연장을 막아야 하는 날짜도 한 달 늦게 나왔습니다. 원인은 모델 성능이 아니라 모델이 읽은 데이터였습니다. 에이전트에 분석을 맡길 예정이라면 오늘 먼저 데이터가 빠짐없이 들어갔는지부터 확인하십시오.

어떤 영상이고 무엇을 했습니까

AI Engineer 채널에 올라온 Natalia Connolly와 Kevin Madura의 「Claude Code Looked Right but Missed $800K」 발표입니다. 2026년 11월 8일에 공개됐고 길이는 약 18분입니다. 두 사람이 속한 AlixPartners는 구조조정과 기술 컨설팅을 하는 회사이고, 발표는 합성 데이터로 재구성한 사례를 사용합니다.

상황은 이렇습니다. 대형 의료 회사가 작은 전문 회사를 인수했고, 구매팀에는 수백 개 공급업체와 4만 건이 넘는 계약 문서, 서로 연결되지 않은 여러 데이터베이스가 남았습니다. 구매 담당자가 협상 자리에서 계약서 몇 쪽, 청구서 몇 번째 줄이라고 근거를 댈 수 있어야 했기 때문에 모든 답은 원본으로 추적 가능해야 했습니다.

처음 답은 어디가 맞았고 어디가 틀렸습니까

발표자들은 Claude Code의 첫 답이 형식도 깔끔하고 그럴듯했다고 말합니다. 그래서 답을 하나씩 데이터베이스와 대조했습니다.

• 연간 총비용, 두 회사 사이의 비용 배분, 계약 건수는 맞았습니다.
• 계약 총액은 약 80만 달러 틀렸습니다.
• 가장 먼저 만료되는 계약의 자동 연장을 막으려면 조치해야 하는 날짜를 에이전트는 12월 1일이라고 답했고, 실제로는 11월 1일이었습니다.

발표자들은 12월 1일까지 기다렸다면 계약이 원하든 원하지 않든 자동 연장됐을 것이라고 설명합니다. 두 번째 오류는 해지 조항의 날짜를 가져왔는데, 질문은 갱신 조항에서 계산한 날짜를 요구하고 있었기 때문에 생겼습니다.

Claude Code가 틀린 데이터의 원인 네 가지

발표자들은 계약 데이터에서 흔히 생기는 문제를 네 가지로 정리합니다.

1. 아주 긴 계약서가 전처리 중에 멈추고, 시간 초과 예외를 넘겨 버리면 그 계약이 데이터베이스에 들어가지 않았다는 사실도 모르게 됩니다.
2. 부속 계약서가 원 계약서와 연결되지 않은 채 혼자 떠 있는 경우입니다. 80만 달러 누락이 이 경우였다고 발표자들은 말합니다.
3. 하나의 기본 계약에 부속 문서 두 개가 붙어 총액을 각각 다시 정하는 경우입니다. 숫자만 뽑아 더하면 합계가 크게 나오지만, 본문을 읽으면 마지막 부속 문서의 값이 정답입니다.
4. 여러 쪽에 걸친 요율표입니다. 둘째 쪽은 제목 없이 숫자부터 시작하기 때문에 각 열이 무엇인지 에이전트가 추측하게 됩니다.

발표자들은 이런 문제가 특별한 사례가 아니라 실제 계약 묶음에 흔하다고 강조합니다.

다섯 단계 처리 파이프라인으로 먼저 구조화했습니다

두 사람은 약 2주 동안 파이프라인을 만들었고, 완성한 뒤 4만 건이 넘는 계약을 하룻밤 사이에 처리했다고 말합니다. 사람이 직접 했다면 두 사람보다 훨씬 큰 팀과 더 긴 시간이 필요했을 것이라는 설명입니다.

1. 문서 전처리와 OCR
2. 계약 종류 분류: 기본 서비스 계약인지, 추가 계약인지, 비밀유지 계약인지
3. 조건, 요율, 비용 추출: 페이지 경계에서 끊기는 긴 표를 여기서 처리
4. 서비스를 비용 범주에 매칭
5. 그다음에야 Claude Code가 구조화된 데이터를 검토

구조화의 효과는 두 가지입니다. Claude Code가 환경을 처음부터 다시 탐색하느라 토큰을 쓰지 않아도 되고, 나온 답을 코드로 검증하기도 쉬워집니다. 도표가 있는 쪽은 이미지로 DSPy에 넣어 구조화된 항목으로 바꿨다고 합니다. 발표자들은 이런 사전 구조화가 6개월에서 12개월 뒤에는 필요 없어질 수도 있다고 덧붙이며, 지금은 정액 요금과 할인처럼 처음부터 필요한 항목을 아는 프로젝트라면 미리 틀을 잡고 모델이 채우게 하는 편이 낫다고 설명합니다.

업무 규칙은 프롬프트가 아니라 도구 안에 넣었습니다

데이터가 구조화된 뒤에는 Claude Code가 이 거래 전용 도구를 만들게 했습니다. SQL 실행이나 표 목록 같은 기본 도구 외에, 가격표 가져오기나 특정 공급업체 비용 조회 같은 도구입니다. 계약 데이터만 봐서는 드러나지 않는 함정을 알고 있다면 그 규칙을 도구가 데이터를 조회하는 방식 안에 넣었습니다.

효과가 있었던 방식은 먼저 Claude Code가 탐색하게 두고, 쓸 만한 것이 확인되면 프롬프트에 적기보다 맞춤 도구와 데이터베이스 보기로 코드에 굳히는 것이었다고 발표자들은 말합니다. 접근 제어도 같은 방식입니다. 믿을 수 있는 작업 목록을 미리 정하고 나머지는 막는다는 설명입니다.

발표자들이 정리한 교훈 다섯 가지

• 날짜는 업무 맥락을 미리 알려 줘야 합니다. 해지 조항의 날짜와 갱신 조항에서 계산한 날짜는 다른 값이고, 이런 규칙을 미리 적을수록 결과가 좋아집니다.
• 연결되지 않은 부속 계약서가 많습니다. 계약 관리 시스템은 거의 제대로 유지되지 않기 때문에, Claude Code가 계약 내용을 읽고 기본 계약, 작업 지시서, 부속 문서의 계층을 만들게 했습니다. 인수합병에서는 같은 것을 두 번 세지 않는 것이 중요합니다.
• 접근 오류가 0으로 보일 수 있습니다. 두 조직의 데이터 접근 방식이 달라 값이 0으로 오거나 권한 오류가 났는데, 도구가 이유를 알려 주지 않자 Claude Code는 청구액이 0이라고 믿고 작업을 계속했습니다. 오류 이유를 자세히 돌려주면 에이전트가 멈추거나 다른 기준 데이터베이스를 참고할 수 있습니다.
• 병렬 에이전트의 절감 후보는 중복을 제거해야 합니다. 비용 절감 방법별로 에이전트를 병렬로 돌렸더니 같은 공급업체에서 나온 절감액이 두 번 잡힐 수 있었고, 그래서 DSPy 기반의 조정 단계를 따로 두었습니다.
• 회사가 이미 하는 일을 알려 줘야 합니다. 에이전트의 절감 제안이 석 달 전에 이미 시작한 일이라는 이유로 바로 기각된 적이 있다고 합니다.

오늘 할 일: 에이전트 분석 전에 확인할 세 가지

이 영상은 계약 분석 사례지만, 해커톤 프로젝트나 데이터 대회 파이프라인에도 그대로 옮길 수 있는 점검 항목이 있습니다.

1. 입력 문서 수와 데이터베이스에 들어간 행 수를 비교하십시오. 처리에 실패한 파일이 조용히 빠졌는지 알 수 있습니다.
2. 도구가 권한 오류나 시간 초과를 0이나 빈 값으로 돌려주고 있지 않은지 확인하고, 오류에는 이유를 담아 돌려주십시오.
3. 에이전트가 낸 숫자 하나를 골라 원본 쪽 번호까지 추적해 보십시오. 이 사례의 팀도 모든 답을 원본으로 되짚을 수 있게 만드는 것을 목표로 삼았습니다.

발표자들이 마지막에 남긴 결론은 두 가지입니다. 데이터를 먼저 구조화하는 데 시간과 비용을 들이면 Claude Code가 환경을 다시 탐색하며 낭비하는 일이 줄어든다는 것, 그리고 컨텍스트 창이 아무리 커져도 업무 맥락은 직접 줘야 한다는 것입니다.

출처

AI Engineer 채널의 「Claude Code Looked Right but Missed $800K - Natalia Connolly & Kevin Madura, AlixPartners」 영상(2026년 11월 8일 공개)을 기준으로 정리했습니다. 발표에 나온 사례는 합성 데이터로 재구성한 것이며, 위 수치는 영상 설명과 발표 내용에서 확인한 값입니다.