지난달 활성 고객이 몇 명이냐는 질문을 받으면 SQL은 금방 나온다. 그런데 쿼리를 치기 전에 정할 게 셋 있다. 로그인만 해도 활성인지 결제까지 해야 활성인지, 환불 고객이나 부정거래 계정은 빼는지, 그리고 비슷하게 생긴 테이블 여러 개 중에 어느 게 공식인지. 여기서 하나만 다르게 골라도 SQL은 에러 없이 돌고 숫자는 틀린다. 분석가라면 다들 아는 얘긴데, 이걸 AI한테 시켜보면 이 앞단이 얼마나 큰지가 새삼 드러난다.
사람은 이 셋을 되묻고 시작한다. AI는 누가 적어줘야 안다.
앤트로픽이 6월에 자기네 데이터팀이 이걸 어떻게 했는지를 공개했다. 사내 분석 질문의 95%를 클로드가 처리하고 정확도가 95% 정도 나온다는 내용인데, 숫자보다 그 숫자에 가기까지 뭐가 안 됐는지가 훨씬 재밌었다.
1. SQL 수천 개를 줘도 안 됐다
처음에 부딪힌 실패는 세 종류였다고 한다. 질문에 나온 개념을 데이터 엔티티에 붙이지 못하는 것(활성 사용자라는 말에 그럴듯한 필드 후보가 수백 개), 스키마와 비즈니스 로직이 계속 바뀌어서 에이전트가 아는 게 낡는 것, 그리고 정보가 있는데도 못 찾는 것.
이걸 풀려고 제일 먼저 해볼 만한 게 과거 SQL을 전부 검색하게 해주는 거다. 대시보드, 변환 코드, 분석가 노트북에 든 쿼리 수천 개에 grep 접근을 줬다. 결과가 좀 뜻밖인데, 정확도가 1%p도 안 움직였다. 더 이상한 건 틀린 답을 하나씩 뜯어봤더니 그중 80%는 정답이 그 쿼리 더미 안에 있었다는 것. 정보가 없어서 틀린 게 아니었다. 질문을 어느 테이블 어느 컬럼에 붙여야 하는지를 몰라서 틀린 거였다.
과거 쿼리에는 과거의 정의가 들어 있다. 이미 폐기된 정의도 있고, 그 사람만 쓰던 기준도 있고, 같은 이름으로 다른 걸 재던 것도 섞여 있다. 그걸 많이 보여준다고 어느 게 지금 맞는 건지가 나오지는 않는다.
2. 그래서 만든 것
대신 깐 건 네 겹이다.
| 만든 것 | 하는 일 |
|---|---|
| 시맨틱 레이어 | 지표와 차원의 공식 정의. 에이전트는 SQL을 짜기 전에 여기부터 보게 강제된다 |
| 스킬 | 도메인별 참고 문서 30개쯤으로 가는 라우터, 그리고 선임 분석가의 절차(질문 명확화 → 소스 찾기 → 쿼리 → 검토)를 적은 런북 |
| 참고 문서 | 테이블의 grain, 범위, 제외 조건, 함정. 사람이 아니라 LLM이 검색해서 읽으라고 쓴 문서 |
| 정답셋 | 답이 알려진 질문으로 돌리는 오프라인 평가. 도메인당 몇십 개면 충분하다고 |
스킬 없이 돌리면 21%, 있으면 95% 근처였다. “revenue”라는 말이 그럴듯한 데이터셋 40개로 흩어지던 걸 공식 하나로 좁히자 문제의 상당 부분이 검색하기도 전에 사라졌다고 한다.
참고 문서에 든 함정 예시가 하나 있는데, “무료 이메일 도메인은 제외하되 anthropic.com 같은 자체 도메인은 남겨라” 같은 것이다. 이런 건 스키마 어디에도 안 적혀 있다. 그 회사에서 몇 년 일한 사람 머릿속에만 있던 거고, 그걸 꺼내서 글로 박아야 에이전트가 쓸 수 있다.
3. 한 달 만에 95에서 65로
여기까지만 보면 잘 된 사례 연구 하나인데, 런칭 뒤에 일어난 일이 있다. 95%였던 오프라인 정확도가 한 달 사이에 65%까지 내려갔다. 데이터 모델은 계속 바뀌는데 스킬 문서가 안 따라가서 그렇게 된 거고, 앤트로픽은 이걸 문서 문제가 아니라 엔지니어링 문제로 다시 잡았다.
방법은 정의를 코드 옆에 두는 거였다. 스킬 문서를 변환 모델과 같은 저장소에 넣고, 모델을 고쳤는데 관련 문서를 안 건드리면 CI가 잡는다. 지금은 데이터 PR의 90%가 스킬 수정을 같이 담는다고 한다. 정의가 한 번 쓰는 문서에서 코드와 같이 사는 자산으로 바뀐 셈이다.
데이터가 조용히 썩는 경로를 쓸 때 is_active 컬럼의 정의가 바뀌었는데 이름은 그대로라서 SQL은 멀쩡한데 숫자만 64% 빠지는 사례를 들었다. 앤트로픽이 겪은 건 그 반대쪽이다. 저쪽은 정의가 바뀌었는데 컬럼이 안 바뀐 거고, 이쪽은 컬럼이 바뀌었는데 정의 문서가 안 바뀐 거다. 어느 쪽이든 데이터와 정의가 따로 놀기 시작하면 한 달이면 무너진다.
4. 분석가가 내놓는 게 달라진다
이 사례를 데이터 분석가나 비즈니스 분석가 자리에서 읽으면, 바뀌는 건 결국 산출물이라는 생각이 든다.
지금까지 분석가의 산출물은 쿼리와 숫자였다. 누가 묻고, 쿼리를 짜고, 숫자를 돌려준다. 잘하는 분석가는 그 앞뒤에 판단을 붙였다. 이 질문에서 활성은 뭘 뜻하는지 되묻고, 어느 테이블이 맞는지 알고, 이 숫자를 믿어도 되는지 확인하고. 그런데 그 판단은 머릿속에 있었고 산출물에는 쿼리와 숫자만 남았다. 쿼리 수천 개를 줘도 소용없었던 이유가 이거다. 자산이 쿼리에 없었다.
문서는 AI가 만들고, 정의는 사람이 소유한다.
그러니까 앞으로 분석가가 내놓는 건 정의, 절차, 정답셋, 그리고 그 셋을 살아 있게 유지하는 루프에 가까워진다. 활성 고객은 이렇게 센다는 정의, 이런 질문은 이 순서로 푼다는 절차, 답이 알려진 질문 몇십 개, 데이터 모델이 바뀔 때 이것들이 같이 바뀌게 하는 장치. 앤트로픽 글에서 제일 마음에 든 문장이 “문서는 클로드가 만들되 정의는 사람이 소유하라”였는데, 그 소유가 곧 분석가의 일이 된다.
이건 데이터 자산을 AI가 읽을 수 있게 만든다는 말과 같은 말이다. 사람은 몇 년 다니면 알아서 배우던 걸 AI는 적어줘야 아니까, 그동안 조직의 암묵지로 있던 지표 정의와 제외 기준과 함정을 명시적인 문서로 옮기는 작업이 생긴다. 이 작업은 그 데이터를 만들고 써온 사람이 아니면 하기 어렵다.
5. 우리 팀도
우리 팀도 이 방향으로 가고 있다. 지표 정의를 사람 머릿속에서 꺼내 문서로 박고, 같은 걸 재는 테이블 여러 개 중에 공식을 정하고, 그 문서를 사람이 읽는 위키가 아니라 에이전트가 검색해서 읽는 형태로 옮기는 중이다. 아직 앤트로픽처럼 CI에 물려놓은 단계는 아니고 정답셋도 이제 만들기 시작했는데, 하다 보니 이게 새 일이라기보다 원래 해야 했는데 미뤄뒀던 일에 가깝더라.
6. 개인적인 견해
이 사례를 그대로 옮겨오기 전에 조심할 게 몇 개 있다.
앤트로픽은 데이터 변환 코드가 저장소에 있고 PR과 CI로 관리되는 회사다. 스킬 문서를 코드 옆에 두고 CI로 물리는 방법은 그 전제가 있어야 성립한다. 대부분의 데이터팀에서 격차는 LLM이 아니라 여기에 있다. 정의를 문서로 적는 것까지는 어디서든 할 수 있는데, 그 문서가 데이터 변경과 같이 움직이게 만드는 건 조직의 일이다.
95%라는 숫자도 앤트로픽이 자기 질문에 자기 정답셋으로 잰 것이다. 그리고 마지막 몇 점이 비싸다. 적대적 검토 단계를 붙여서 3%p를 더 올렸는데 토큰은 32%, 지연은 72% 늘었다. 어디까지 올릴지는 회사마다 다르게 답할 문제다.
분석가 수요가 늘지 줄지는 이 사례 하나로 말할 수 없다. 앤트로픽은 반복 요청이 줄어서 데이터 과학팀이 인과 모델링과 예측 쪽으로 옮겨갔다고 하는데, 그건 그럴 만한 일이 있는 팀 얘기고, 쿼리 대응이 업무의 대부분이던 팀에서는 다른 그림이 나올 수 있다.
그래도 방향 자체는 크게 안 틀릴 것 같다. 예전 분석가가 질문을 받아 숫자를 돌려주는 사람이었다면, 이제는 그 숫자의 기준을 정하고 그 기준이 계속 맞게 유지하는 사람에 가까워진다. 쿼리는 누가 짜도 되는 세상이 왔고, 활성 고객이 뭔지는 여전히 누군가 정해야 하니까.
함께 보면 좋은 글:
- 코드를 한 줄도 안 건드렸는데 시스템이 망가진다: 데이터가 조용히 썩는 경로들
- LLM은 어떻게 채점하나: 평가 방법 11가지를 네 계열로 정리했다
- 앤드류 응의 AI 엔지니어링 스킬맵을 뜯어보며
참고 자료
본 글은 2026년 9월 18일 기준으로 작성했다. 정확도, 비율 등 수치는 모두 앤트로픽이 자사 환경에서 자사 정답셋으로 측정해 공개한 값이며, 다른 조직에서 같은 수치가 나온다는 뜻은 아니다.