앤트로픽이 사내 데이터 분석의 95%를 AI에 맡긴 법

앤트로픽이 공식 블로그에 흥미로운 글을 하나 올렸다. 제목은 How Anthropic enables self-service data analytics with Claude. 한 줄로 줄이면 이렇다. 회사 비즈니스 데이터 분석 질문의 95%를 AI(클로드)에게 통째로 맡겼고, 그 정확도가 평균 95%, 일부 영역은 99%에 이른다.

숫자만 보면 "모델이 똑똑해서 그렇겠지" 하고 넘기기 쉽다. 그런데 끝까지 읽어 보면 정반대다. 비결은 모델이 아니라 그 모델 둘레에 사람이 쌓아 올린 구조에 있었다. 그리고 그 구조의 심장에 요즘 가장 뜨거운 단어, 바로 스킬(Skill) 이 박혀 있었다.

이 글에서는 앤트로픽이 실제로 무엇을 했는지, 그 안에 숨은 노하우와 함정까지 하나도 빠뜨리지 않고 뜯어본다. 신입 개발자가 읽어도 따라올 수 있게 비유를 곁들이되, 숫자와 사실은 정확하게 옮긴다.

1. 왜 '셀프서비스 데이터 분석'은 늘 실패했나

데이터를 누구나 직접 쓰게 만드는 일, 이른바 셀프서비스 분석은 모든 회사의 오랜 숙제였다. 데이터 사이언티스트는 "이번 달 활성 사용자 몇 명이야?", "이 기능 전환율은?" 같은 단순 질문에 매일 시달린다. 이걸 자동화하려는 시도는 여러 번 있었지만, 방법마다 벽에 부딪혔다. 앤트로픽은 지난 실패를 세 가지로 정리한다.

① 넓고 평평한 테이블 (wide, denormalized tables)

모든 데이터를 거대한 시트 한 장에 다 때려 박는 방식이다. 처음엔 편해 보인다. 하지만 회사가 커지면 비슷비슷한 시트가 자꾸 늘어나고, 같은 지표인데 정의가 서로 어긋난다. "매출"이 이 시트에선 이렇게, 저 시트에선 저렇게 계산된다. 결국 SQL 모르는 사람한테는 아무 도움이 안 됐다.

② 울타리 친 환경 (ringfenced dashboards)

미리 정해 둔 대시보드만 보게 막는 방식이다. 안전하긴 한데, 사람들이 진짜 궁금해하는 자잘한 '롱테일' 질문은 받아 주지 못한다. 그래서 대시보드가 끝없이 늘어나고, 어느 순간 관리가 안 되는 상태(대시보드 비대화)에 빠진다.

③ 그냥 AI 에이전트한테 맡기기

가장 위험한 방식이다. AI는 그럴듯한 답을 주지만, 그게 맞는지 확인할 길이 없다. 회사의 진짜 데이터 구조나 도메인 전문가 지식과 따로 놀기 때문이다. 겉만 번지르르하고 속은 빈 가짜 정밀함(false precision) 이 생긴다.

세 방법 모두 실패했다. 그렇다면 앤트로픽은 무엇을 다르게 봤을까?

2. 진짜 문제는 셋이었다

앤트로픽은 "AI가 데이터 분석을 못 하는 이유"를 막연하게 두지 않고 딱 세 가지 실패 모드로 못 박았다. 글의 표현을 빌리면, 핵심은 "사용자의 질문을 데이터 모델 속 정확하고 최신인 엔티티에 연결하고, 그걸 올바르게 다루는 법까지 아는 능력"이다.

그 전에 한 가지를 짚고 가자. 분석 에이전트는 코딩 에이전트와 근본부터 다르다. 코드는 컴파일러와 테스트가 "맞는지"를 결정론적으로 잡아 주지만, 데이터 분석에는 그런 안전망이 없다.

그래서 "돌려 보고 통과하면 끝"이 통하지 않는다. 그럴듯한 오답을 걸러 줄 장치가 없으니, 아래 세 가지가 그대로 치명타가 된다.

1. 개념과 엔티티 사이의 애매함 (concept-to-entity ambiguity)
   "활성 사용자"라는 말 한마디에도 질문이 한가득이다. 로그인하면 활성인가? 글을 써야 하나? 가짜 계정도 넣나? 며칠 전까지 본 사람도 활성으로 치나? 후보 필드가 수백 개인데, AI는 사용자의 질문을 어느 엔티티에 붙여야 할지 모른다.

신입한테 "단골 손님 수 좀 세 줘" 시키면서 단골의 기준을 안 알려 주면, 신입은 제멋대로 센다. 딱 그 상황이다.

2. 데이터가 자꾸 낡는다 (staleness)
   회사는 살아 있다. 테이블 구조도, 지표 정의도, 로직도 계속 바뀐다. 어제 맞던 답이 오늘 틀린다. AI의 지식은 금세 낡는다.

3. 정보를 못 찾는다 (retrieval failure)
   정답은 분명히 회사 어딘가에 있다. 그런데 AI가 그걸 못 찾는다.

도서관에 책은 다 있는데 분류표(카탈로그) 만 없는 셈이다. 찾는 책이 있어도 수만 권 사이에서 헤맨다.

이 셋을 하나씩 무너뜨리려고 앤트로픽은 그 유명한 4계층 구조를 세운다. 집을 짓듯 1층부터 올라가 보자.

3. 4층 에이전틱 분석 스택

먼저 전체 지도를 펼쳐 보자. 네 개의 층이 각각 앞에서 본 실패 모드를 하나씩 맡는다 — 1층은 엔티티 모호성을, 2층은 그럴듯한 오답이 설 자리를, 3층은 검색 실패를, 4층은 데이터 노화를 정조준한다.

🧱 1층 — 데이터 기초 공사 (Data Foundations)

여기서 가장 중요한 단어가 표준 데이터셋(canonical dataset), 곧 단 하나의 진실의 원천(one source of truth) 이다.

앞에서 매출이 시트마다 다르게 계산된다고 했다. 표준 데이터셋은 "매출은 무조건 이 데이터를 봐라" 하고 못을 박는다. 그럴듯한 후보 40개가 아니라 딱 하나로.

음식점 표준 레시피와 같다. 알바가 바뀌어도 김치찌개 맛이 똑같으려면 레시피가 하나여야 한다.

여기에 진짜 노하우가 숨어 있다. 레시피만 정해 두면 사람들이 안 지킨다. 그래서 앤트로픽은 이걸 도그마처럼 강제(mandate) 했다. 바로 CI/CD로. CI/CD는 코드를 올릴 때 규칙을 자동으로 검사하는 컨베이어 검수대다. 규칙을 안 지키면 아예 통과를 못 시킨다.

또 하나, 메타데이터를 (부록이 아니라) 어엿한 제품으로 대접했다. 메타데이터란 이 데이터가 뭔지 설명해 주는 꼬리표다 — 설명, 정의, 출처, 소유자. 이걸 곁다리로 두지 않고 정성껏 관리했다.

이 세 가지(표준화·강제·메타데이터)가 하는 일을 한 장으로 그리면 이렇다. "매출이 얼마야?"라는 질문이 수십 개 후보 테이블을 거쳐 딱 하나의 거버넌스 엔티티로 좁혀진다.

🗂️ 2층 — 진실의 원천들 (Sources of Truth)

믿을 수 있는 정보를 신뢰도 순서로 쌓아 둔 층이다. 위로 갈수록 더 믿을 만하다.

이 네 원천을 신뢰도 순으로 세워 보면 이렇다. 위로 갈수록 더 권위 있고, 애매할 때 먼저 기대야 할 곳이다.

여기에 두고두고 반복되는 핵심 교훈이 하나 숨어 있다.

과거 SQL을 날것 그대로 검색만 시켰더니 정확도가 1%포인트도 안 올랐다. 다듬어야 비로소 의미가 생긴다.

그리고 2층 전체를 관통하는 한 문장.

"매출이라는 단어가 후보 40개가 아니라 딱 하나의 데이터로 이어지면, 문제는 거의 사라진다."

✨ 3층 — 스킬 (Skills): 정확도를 뒤집은 마법의 층

여기가 이 글의 심장이다. 앤트로픽이 공개한 그대로, 정확도를 21% → 95%로 뒤집은 단 하나의 층이다.

스킬은 절차적 지식(procedural knowledge)이다. 어려운 말 같지만 쉽게 말하면 "일하는 법" 이다. 어떤 자료부터 봐야 하는지, 애매할 땐 어떻게 헤쳐 나가는지, 잘 끝낸 분석은 어떤 모양이어야 하는지 — 이런 노하우를 마크다운(.md) 파일에 적어 두고, 에이전트가 필요할 때 읽는다.

신입한테 데이터만 툭 던져 주는 것과, 선배의 업무 매뉴얼까지 같이 쥐여 주는 것. 그 차이는 하늘과 땅이다.

그 차이를 숫자로 보면 충격적이다.

원문: "Without skills, Claude's ability to answer analytics questions accurately didn't exceed 21% on our evals. Adding skills gets these numbers consistently above 95% in aggregate and regularly around 99% in certain domains."

같은 AI인데 매뉴얼 하나로 이렇게 달라졌다. 그리고 앤트로픽은 이 스킬을 영리하게 둘로 나눴다.

(a) 지식 스킬 (knowledge skill) — 안내 데스크이자 라우터

질문이 들어오면 "아, 이건 마케팅 영역이네" 하고 판단해서, 그 영역에 맞는 참고 문서 30개쯤만 골라 불러온다. 수만 개를 다 뒤지는 게 아니라, 잘 고른 30개만. 앞서 말한 도서관 분류표가 바로 이 역할이다.

(b) 언북 스킬 (unbook skill) — 베테랑 분석가의 작업 순서

이름은 좀 특이하지만, 시니어 분석가의 워크플로를 그대로 박제한 것이다.

1. 질문을 명확히 하고
2. 자료를 찾고
3. 쿼리를 실행하고
4. 적대적 검토(adversarial review) — 자기가 낸 답을 자기가 의심하며 다시 따지고
5. 자주 쓰는 패턴을 재사용한다 (리텐션 곡선, 비율 분해, 퍼널 분석 등). 매번 새로 짜지 않고 검증된 도구를 가져다 쓴다.

참고 문서의 생김새도 정해져 있다. 맨 위에 빠른 참조(quick reference)를 두고, 이어서 데이터 맥락과 기본 필터, 차원(dimension) 설명, 핵심 테이블, 주의사항과 자주 쓰는 패턴을 적은 뒤, 마지막에 다른 문서로 가는 링크를 단다. 군더더기 없이 딱 필요한 것만.

이 두 스킬이 함께 움직이는 모습, 그리고 그것이 만든 정확도 점프를 그리면 이렇다.

🩸 그리고, 등골이 서늘해지는 이야기

스킬을 다 만들고 정확도 95%를 찍었다. 다들 좋아했다. 그런데 딱 한 달 뒤, 정확도가 95%에서 65%로 떨어졌다.

손 놓고 있어서가 아니다. 오히려 반대다. 그동안 회사가 계속 일을 했기 때문이다. 테이블이 바뀌고 정의가 바뀌었는데, 스킬 문서만 그대로였다. 문서가 낡아 버린 것이다.

가게 메뉴는 바뀌었는데 신입한테 준 매뉴얼은 작년 거인 셈이다. 신입이 열심히 일할수록 더 틀린다.

해법은 영리했다. 스킬 문서를 데이터 코드와 같은 저장소(repo)에 넣고 CI 훅을 걸었다. 데이터 모델을 바꾸면 스킬 문서도 같이 바꾸라고 강제한 것이다. 안 바꾸면 통과가 안 된다. 그 결과, 이제 코드 수정의 90%가 스킬 업데이트를 함께 담는다. 문서가 코드와 함께 살아 움직이게 됐다.

교훈: 낡은 문서는 모델 한 세대보다 더 빨리 AI 성능을 죽인다.

🔍 4층 — 검증 (Validation): 답이 맞는지 확인하는 층

크게 세 갈래다. 이 셋을 '배포 전'과 '운영 중' 두 무대로 펼치면 안전망이 어떻게 겹치는지 한눈에 보인다 (반전 실험은 배포 전 평가의 일부다).

(1) 오프라인 평가 (offline evals)
정답을 미리 아는 문제를 잔뜩 만들어 두고 AI에게 시험을 보게 한다. 흥미로운 건 이 시험 문제의 상당수를 클로드가 직접 만든다는 점이다. 대시보드를 읽어 약 90개 안팎의 문항을 자동으로 뽑으면 사람이 검수하고, 거기에 도메인 곳곳을 훑는 롱테일 문항을 더한다. 목표 정확도는 사실상 100%에 가깝게 잡는다. 평가 결과는 점수로만 끝내지 않고 스킬 버전, 깃 커밋(SHA), 모델 ID, 문항별 통과·실패, 토큰 수까지 함께 창고에 적재해 추적하고, 변경 하나하나가 정확도에 어떤 영향을 주는지 PR 단위로 절단 실험(ablation) 한다. 그렇게 정해 둔 기준을 못 넘으면 배포를 막는다.

(2) 반전 실험 — 정보가 아니라 '구조'가 문제다
앤트로픽이 궁금해했다. "AI에게 과거 SQL 수천 개를 통째로 주면 어떨까?" 실제로 줘 봤더니 그 파일의 80%가 질문과 관련이 있었다. 정답이 거기 다 있었다는 뜻이다. 결과는? 정확도가 1포인트도 안 올랐다.

앤트로픽은 이 결과를 세 단계로 쪼개 물었다.

1. 정답이 과거 쿼리 더미 안에 있었나? → 그렇다 (80%).
2. 에이전트가 그 파일들을 읽었나? → 그렇다.
3. 그런데도 활용하지 못했나? → 그렇다.

정보도 있었고 읽기까지 했는데 못 썼다. 그러니 부족한 건 정보가 아니라 구조였다.

원문: "giving the agent raw retrieval access to thousands of prior queries moved accuracy by less than a point."

즉, 막혔던 건 '정보 접근'이 아니라 질문을 데이터에 이어 주는 '다리'의 부재였다.

신입한테 10년치 영수증을 박스째 던지며 "답은 다 여기 있어"라고 한 꼴이다. 정리가 안 됐으니 못 쓴다.
핵심 교훈: 데이터는 쌓는 게 아니라 구조화하는 것이다.

(3) 실시간 검증 (online validation)
운영에 올린 뒤에도 답의 신뢰성을 지키기 위해 앤트로픽은 여러 겹의 장치를 둔다.

• 적대적 검토(adversarial review): 잠정 최종 답이 기댄 모든 가정을 공격적으로 따져 보는 클로드 스킬을 한 번 더 태운다. 평가셋 기준 정확도가 6% 올랐다. 다만 대가가 있다 — 토큰은 32% 더 들고, 응답 시간은 72% 더 늘어난다. 더 정확해지는 만큼 더 비싸고 느려지므로, 모든 질의가 아니라 위험이 크거나 가치가 높은 질의에 선별 적용한다.
• 출처 푸터(provenance footer): 모든 답변 아래에 꼬리표를 붙인다 — 어느 신뢰 등급의 출처에서, 얼마나 최신 데이터로, 누구 소유로 왔는지. 사용자가 그 답을 얼마나 믿을지 스스로 판단하도록 돕는다.
• 데이터 품질 점검과 상시 모니터링: 핵심 지표(top KPI)는 매일 상태를 확인하고, 파이프라인 품질 체크로 '조용히 틀리는' 오류를 빠르게 잡는다. 영향이 큰 의사결정에는 사람의 최종 확인(사인오프)을 거치게 한다.
• 자동 교정 수집(correction harvesting): 예약된 에이전트가 사내 채팅 채널을 돌며 "이 숫자 틀렸다" 같은 지적을 모아 수정안으로 바꾼다. 운영 피드백을 받아 시스템이 스스로 나아진다.

적대적 검토의 수치(정확도 +6%, 토큰 +32%, 지연 +72%)가 보여 주듯, 정확도에는 공짜가 없다. 비용과 속도를 내주고 사는 것이다.

4. 결과와, 앤트로픽이 직접 짚은 교훈

결과 (숫자로):

• 비즈니스 분석 질문의 95% 자동화
• 정확도 평균 95%, 특정 영역 99%
• 그리고 무엇보다 — 데이터 사이언티스트가 자유로워졌다. 매일 쏟아지던 단순 질문에서 벗어나, 인과 모델링·예측·머신러닝 같은 진짜 어려운 일로 올라섰다. AI가 잡일을 가져가니 사람은 더 가치 있는 일을 한다.

앤트로픽이 직접 짚은 교훈:

1. 데이터는 소프트웨어가 아니다. 코드는 맞는지 증명할 수 있지만, 데이터 분석은 정답을 딱 잘라 증명할 방법이 없다. 진짜 문제는 코드 생성이 아니라 애매함 그 자체다.
2. 정확도는 결국 맥락(context)과 검증(verification)의 문제다. 모델이 똑똑하냐의 문제가 아니다.
3. 강제 없는 규칙은 빠르게 썩는다. 정해만 두고 강제하지 않으면 무너진다.
4. 낡은 문서는 모델 한 세대보다 성능을 더 빨리 죽인다. (한 달 만에 65%로 추락한 그 사건.)
5. AI는 문서를 만드는 건 잘한다. 하지만 정의는 사람이 책임져야 한다. 실제로 앤트로픽은 시멘틱 레이어(지표 정의)를 LLM에게 자동 생성시켜 봤다가, 그럴듯하지만 정작 없애려던 그 애매함을 그대로 박아 넣은 정의가 나오는 바람에 순효과가 마이너스였다고 털어놓는다. "활성 사용자가 뭔지"는 AI가 정하면 안 된다. 그건 사람의 몫이다.
6. 과거 쿼리는 그냥 쌓지 말고 정리된 패턴으로 다듬어라. (날것은 1%도 못 올린다 — 글에서 두 번이나 강조된다.)

5. 그래서, 어떻게 시작하면 되나

앤트로픽은 최소 시작점까지 친절하게 일러 준다. 거창하게 시작할 필요 없다. 딱 셋이면 된다.

1. 표준 데이터셋 몇 개 — 다 정리할 필요 없다. 제일 중요한 핵심 데이터 몇 개만 '단 하나의 진실'로 정한다.
2. 오프라인 평가 수십 개 — 정답을 아는 시험 문제 수십 개만 만들어 두고 잘 굴러가는지 측정한다.
3. 얇은 지식 스킬 하나 — 처음부터 두껍게 만들 것 없다. 안내 데스크 역할만 하는 아주 얇은 스킬 하나면 충분하다.

이 셋으로 시작한 다음, 우리 상황에 맞춰 조절한다 — 오류를 얼마나 견딜 수 있는지, 비즈니스가 얼마나 복잡한지, 사용자가 기술에 얼마나 익숙한지, 정확도와 속도 중 무엇이 더 중요한지, 접근 관리는 어떻게 할지. 그렇게 한 층씩 쌓아 올린다.

조절의 큰 그림은 위험 감수성과 비즈니스 복잡도 두 축으로 잡힌다. 핵심은, 대부분의 가치가 오른쪽 아래 '0에서 시작' 사분면 하나에서 나온다는 점이다.

시작하라 → 측정하라 → 강제하라 → 관리하라. 이게 박자다.

6. 마치며 — "에이전트가 아니라 스킬"

앤트로픽이 이 글에서 내린 결론은 분명하다. 분석의 어려움은 모델의 한계가 아니라 데이터의 애매함에 있다는 것이다. 블로그의 표현 그대로 데이터는 소프트웨어가 아니다(Data is not software) — 코드와 달리 분석은 정답을 딱 잘라 증명할 방법이 없고, 그래서 정답은 모델의 창의력이 아니라 맥락과 검증에서 나온다.

그 차이는 숫자로 드러난다. 스킬이 없을 때 21%, 넣으니 95% 이상. 이걸 만든 건 더 똑똑한 모델이 아니라 블로그가 짚은 애매함을 줄이는 구조였다 — "매출이 후보 40개가 아니라 단 하나의 거버넌스 데이터로 정해지면 문제는 거의 사라진다", 그리고 그 표준은 tooling·CI·mandate로 강제될 때만 유지된다. 표준 데이터셋, 스킬, 그리고 그걸 낡지 않게 붙드는 규율이 정확도를 끌어올린 진짜 동력이었다.

그래서 이 청사진이 던지는 마지막 메시지는 역설적이다. 에이전트는 결국 결벽에 가까운 데이터 엔지니어링 위에 얹힌 얇은 UI일 뿐이라는 것. 화려한 건 모델이 아니라, 그 아래에서 모호함을 한 겹씩 걷어 낸 사람들의 규율이다.

이 결론을 한 줄로 압축한다.

"필요한 건 에이전트를 만드는 게 아니라 스킬을 만드는 것이다. 검증된 스킬을 쌓아 가는 것, 그게 우리의 해자(moat)다."

참고 자료

• 영상: 진짜는 에이전트가 아니라 '스킬'이었다 (메이커 에반 | Maker Evan)
• 블로그: How Anthropic enables self-service data analytics with Claude