Anthropic이 Claude로 셀프서비스 데이터 분석을 구현하는 방법

데이터 사이언스 및 데이터 엔지니어링 팀이라면 누구나 공감하겠지만, 셀프서비스 비즈니스 분석 환경을 구축하는 일은 언제나 험난한 여정이었다.

비기술직 동료들이 데이터 모델에 쉽게 접근할 수 있도록 넓고 비정규화된 테이블을 제공하면, 비즈니스가 성장하면서 정의가 제각각인 뷰들이 중복 생성되는 문제가 생긴다(게다가 SQL을 배울 의지가 없는 직원들에게는 별 도움도 되지 않는다). 반대로 사용자별로 접근 환경을 엄격히 제한하면, 다양한 비즈니스 질문의 긴 꼬리를 놓치기 쉽고, 팀마다 사일로를 쌓으면서 지표와 대시보드가 무분별하게 늘어나는 결과를 낳는다.

LLM의 부상은 이러한 난제를 피해 갈 수 있는 셀프서비스 분석의 새로운 길을 열어주었다. 하지만 Claude를 데이터 웨어하우스에 연결하고 에이전트가 알아서 실행하도록 두면, 마치 정밀한 결과를 얻고 있다는 착각에 빠지기 쉽다.

임시 요청(ad-hoc request)에서 해방됐다는 초반의 기쁨은, 이 구조가 이해관계자들을 기존에 올바른 데이터셋으로 안내하던 인프라, 문서, 전문 지식으로부터 단절시킨다는 사실을 깨닫는 순간 불안으로 바뀐다.

Anthropic에서는 비즈니스 분석 쿼리의 95%가 Claude를 통해 자동화되며, 전체 정확도는 약 95%에 달한다. 반복적이고 단순한 작업을 Claude에 맡김으로써, 데이터 사이언스 팀은 인과 모델링, 예측, 머신러닝과 같은 전략적 업무에 집중할 수 있다.

Anthropic의 주요 Claude Code 사용자 수십 명을 만나고, 분석 에이전트의 다양한 설계 패턴을 살펴본 경험을 토대로, LLM을 활용하는 데이터 팀을 위한 모범 사례를 정리했다. 이 글에서는 Claude의 셀프서비스 데이터 인사이트 도출 역량을 극대화하기 위한 실용적인 팁과 접근법을 공유한다. 다루는 내용은 다음과 같다.

• 분석 정확도는 코드 생성이 아닌 컨텍스트와 검증의 문제인 이유
• 대부분의 오류를 유발하는 세 가지 실패 유형
• 이러한 오류를 해결하기 위해 구축한 에이전틱 분석 스택
• 효과를 측정하는 방법
• 대부분의 스킬을 만들 때 사용하는 기본 템플릿 (부록 참고)

데이터는 소프트웨어가 아니다

LLM의 생성 능력은 양날의 검이다. 복잡한 문제에 창의적인 해법을 제시하는 바로 그 메커니즘이 잘못된 결과를 만들어내기도 한다. 분석 에이전트가 직면한 어려움을 제대로 이해하려면, 코딩 에이전트와 비교해 보는 것이 도움이 된다.

코딩은 열린 해결 공간이라 모델의 창의성이 빛을 발하며, 문서와 테스트가 환각(hallucination)을 막는 자연스러운 안전망 역할을 한다. 반면 분석 영역에서는 대부분의 경우 정해진 단 하나의 정답이 존재하고 단 하나의 정확한 데이터 소스만 유효한데, 그 정확성을 결정론적으로 증명할 방법이 없다.

셀프서비스 에이전틱 비즈니스 분석에서 복잡성은 주로 데이터의 모호성에서 비롯된다. 핵심 문제는 사용자의 질문을 데이터 모델 내의 구체적이고 최신의 엔티티에 정확히 연결하고, 그것을 올바르게 다루는 방법을 아는 것으로 귀결된다. 이 과정만 제대로 된다면, 실제 실행과 SQL은 사소한 문제에 불과하다.

부정확한 응답의 압도적인 다수를 설명하는 세 가지 문제 속성을 파악했다.

1. 개념 <> 엔티티 모호성: 데이터 모델에 수백 개의 후보(잠재적으로 수백만 개의 필드 중)가 존재하는 상황에서, 에이전트가 사용자의 질문에 가장 적합한 필드를 제대로 선택하지 못하는 경우다. 예를 들어 '활성 사용자 수'를 측정할 때, 어떤 행동을 '활성'으로 볼 것인가? 부정 사용자는 포함하는가? 회고 기간(lookback window)은 어떻게 설정하는가?

1. 데이터 노후화: 데이터 소스, 비즈니스 정의, 스키마는 끊임없이 변한다. 에셋과 에이전트 지식이 낡아지면서 미묘하게 잘못된 답을 반환하기 시작한다.

1. 검색 실패: 데이터 모델 안에 올바른 정보가 있고 제대로 주석도 달려 있지만, 탐색 공간이 방대해 에이전트가 끝내 찾아내지 못하는 경우다.

에이전틱 분석 스택

Anthropic에서 이 세 가지 오류를 최소화하는 핵심 수단은 에이전틱 데이터 스택이다. 각 레이어는 하나 이상의 문제를 집중적으로 해결하기 위해 존재한다.

1. 엔티티 모호성: 데이터 파운데이션과 진실 공급원(sources of truth)이 가능한 엔티티의 범위를 단일하게 관리되는 하나의 답으로 좁혀 나간다.

1. 노후화: 유지보수 및 검증 프로세스가 비즈니스 변화에 따라 모든 것이 썩지 않도록 관리한다.

1. 검색 실패: 스킬이 에이전트가 그 답을 안정적으로 찾아내고 올바르게 활용하도록 보장한다.

이 섹션에서는 각 레이어를 어떻게 구축했는지 설명한다.

데이터 파운데이션

분석 에이전트의 정확도를 높이는 데 가장 중요한 것은 탄탄한 데이터 파운데이션이다. 여기에는 데이터 웨어하우스의 데이터 모델, 변환 로직, 테스트, 테이블, 그리고 이를 설명하는 메타데이터가 포함된다. 차원 모델링(dimensional modeling), shift-left 테스팅, 주요 파이프라인의 최신성 및 완전성 검사와 같은 표준 데이터 엔지니어링 및 데이터 품질 관행은 여전히 유효하다(이 부분은 새로 논하지 않겠다).

달라진 점은 데이터 모델의 최종 사용자가 더 이상 데이터 전문가(예: 데이터 사이언티스트)가 아니라는 것이다. 대신 다양한 수준의 데이터 이해도를 가진 사용자를 대신해 에이전트가 행동한다. 이 변화가 어려운 이유는, 결과의 정확성을 사용자가 직접 검증할 수 없기 때문이다. 최종 사용자가 그 정확성을 판단할 능력 자체가 없기 때문이다.

데이터 파운데이션 레이어는 주로 모호성 해소를 목표로 한다. 예를 들어 revenue라는 개념이 40개의 후보 데이터셋이 아닌 하나의 공식 데이터셋으로 귀결된다면, 에이전트가 탐색을 시작하기도 전에 문제가 사라진다. 또한 정규 모델을 정의하는 저장소가 모델의 최신성을 보장하기에 가장 적합한 곳이기 때문에, 이 레이어는 노후화에 대한 첫 번째 방어선이기도 하다.

특히 효과적이었던 몇 가지 방법을 소개한다.

• 정규 데이터셋 구축: 단연 가장 흔한 실패 원인은 에이전트가 "제품 X의 매출"이라는 개념을 올바른 단일 테이블, 컬럼, 지표 정의로 연결하지 못하는 것이다. 대체로 구현 방식이 미묘하게 다른 여러 후보가 존재하기 때문이다. 해법은 더 적고 더 엄격하게 관리되는 논리적 모델을 만드는 것이다. 명확한 소유권이 있고, 즉시 사용 가능하며, 쉽게 발견할 수 있는 소수의 정규 단일 진실 공급원 데이터셋을 선별하고, 유사 중복 데이터셋은 과감히 폐기해야 한다. 물리적 롤업과 캐시는 여전히 비용과 성능 측면에서 중요하지만, 병렬 대안으로 존재하는 것이 아니라 정규 모델에서 기계적으로 파생되어야 한다. 목표는 에이전트가 어떤 개념을 검색할 때 단 하나의 공식적인 답을 찾을 수 있도록 하는 것이다.
• 표준을 강제하라: 정규 모델과 지표 정의는 툴링(tooling) (에이전트가 구조적으로 해당 모델을 우선 탐색하도록 설계, 아래에서 자세히 설명), CI (정규 모델을 우회하는 변경사항은 리뷰에서 탈락), 규정(mandate) (하위 팀은 공식 레이어를 기반으로 구축하거나, 그렇지 않은 경우 사유를 설명) 으로 강제될 때만 효력이 유지된다는 것을 경험으로 확인했다. 강제 없는 거버넌스는 금세 다시 복수 후보 문제로 되돌아간다.
• 아티팩트 같은 위치에 배치: 끊임없이 변하는 데이터 모델과 비즈니스 로직에 대한 주요 방어 수단은 코로케이션(colocation)이다. 거의 모든 데이터 코드(모델링, 시맨틱 레이어, 참조 문서, 정규 대시보드 정의 등)는 단일 저장소에 두고, CI 검사가 레이어 간 무결성을 보호한다. 모델링 변경이 하위 대시보드를 망가뜨리거나 문서화된 지표를 무효화하면, CI가 이를 감지하고 수정이 동일한 PR에 포함되어 배포된다. (이 부분의 구체적인 동작 방식은 아래 스킬 섹션 에서 다시 설명한다.)
• 메타데이터를 1급 제품으로 다루라: 코딩 에이전트가 잘 작동하는 이유 중 하나는 코드베이스가 가독성이 높기 때문이다. README, 타입 시그니처, 독스트링 등이 그 예다. 데이터 웨어하우스도 그만큼 가독성이 높을 수 있지만, 컬럼·테이블 설명, 정규 지표 정의, 그레인(grain) 문서, 유효 값 범위, 계보(lineage), 소유권, 모델 등급이 변환 로직 자체와 동일한 수준의 엄격함으로 관리될 때만 가능하다. 새로운 인사이트는 아니지만, 훌륭한 거버넌스는 에이전트가 올바른 데이터셋을 선택하는 데 결정적인 컨텍스트를 제공한다.

진실 공급원

데이터 파운데이션이 데이터 웨어하우스 자체라면, 진실 공급원은 에이전트가 웨어하우스를 탐색하기 위해 참조하는 레퍼런스 표면이다. 이 레이어는 개념 <> 엔티티 모호성을 줄이고, 이해관계자의 질문에 담긴 "주간 활성 사용자"를 데이터 모델 내의 구체적이고 공식적인 엔티티로 변환하는 역할을 한다. 신뢰도가 높은 순서로 나열하면 다음과 같다.

• 시맨틱 레이어: 컴파일된 지표 및 차원 정의다. 질문이 정의된 지표에 명확히 대응되면, 에이전트는 함수를 호출해 하나의 숫자를 얻는다. 회사의 다른 모든 서비스가 생성하는 것과 동일한 숫자다. 우리 에이전트는 (스킬 지침에 따라) 구조적으로 시맨틱 레이어를 먼저 활용하도록 되어 있다(부록 참고). 시도했지만 효과가 없었던 방법도 있다. LLM이 원시 테이블과 쿼리 로그로부터 지표 정의를 자동 생성해 시맨틱 레이어를 부트스트래핑하는 방식이었다. 겉으로는 그럴듯해 보이는 정의들이 생성됐지만, 제거하려 했던 바로 그 모호성이 고스란히 담겨 있었고, 소수의 인간이 직접 큐레이션한 레이어와 비교한 평가에서 오히려 성능이 저하됐다. 따라서 문서화는 Claude로 생성하되, 정의의 소유권은 사람이 갖도록 권장한다.
• 계보와 변환 그래프: 시맨틱 레이어로 답할 수 없는 질문에는 계보와 테이블 순위(참조 횟수 기반)가 활용된다. 에이전트가 어떤 상위 모델이 특정 개념으로 이어지는지, 어떤 것이 폐기됐는지, 어떤 것이 같은 그레인을 공유하는지를 파악할 수 있게 해준다. 이를 통해 "지표를 모른다"는 상황이 "어떤 공식 모델에서 집계해야 하는지 안다"로 전환된다. 또한 아래에서 설명할 온라인 검증에서 제공하는 최신성 및 출처 신호의 근간이 되기도 한다.
• 쿼리 코퍼스: 대시보드, 노트북, 이전 분석에서 축적된 과거 SQL이다. 직관적으로 이 데이터는 매우 가치 있을 것처럼 보인다. 이미 올바르게 답변된 모든 질문의 기록이기 때문이다. 실제로 수천 개의 과거 쿼리에 대한 직접적인 검색 접근 권한을 에이전트에 부여해 봤더니, 정확도는 거의 개선되지 않았다(이 에블레이션은 아래 섹션에서 상세히 다룬다). 비정형 검색으로는 새로운 질문을 올바른 선례에 연결하지 못했다. 효과가 있었던 방법은 해당 코퍼스를 도메인별 구조화된 참조 문서와 스킬에 담긴 재사용 가능한 분석 패턴으로 정제하는 것이었다. 쿼리 히스토리는 에이전트가 직접 읽는 진실 공급원이 아니라, 큐레이션을 위한 원재료로 다뤄야 한다.
• 비즈니스 컨텍스트: 대부분의 팀이 건너뛰는 레이어이자, 우리 역시 가장 오래 과소평가했던 부분이다. 비즈니스를 이해하지 못하는 에이전트는 사용자가 물어본 것에는 답하지만, 사용자가 의도한 것에는 답하지 못한다. "Q2 론칭"이 어떤 특정 제품을 가리키는지, 두 팀이 같은 용어를 다르게 정의한다는 사실, 혹은 목요일에 이사회 미팅이 있어서 그 질문이 나왔다는 맥락을 알지 못한다. 우리는 색인된 문서, 로드맵, 의사결정 기록, 조직 구조로 구성된 회사 지식 그래프를 연결하여 에이전트가 주변 맥락을 파악하고 더 나은 명확화 질문을 던질 수 있게 한다.

네 가지 모두에서 공통적으로 나타나는 실패 패턴은 데이터 파운데이션 레이어에서와 동일하다. 부실하거나 노후화된 문서가 문제다. Claude는 이 격차를 좁히는 데 탁월한 도구다(컬럼 설명 초안 작성, 쿼리 패턴으로부터 지표 문서 제안, CI에서 문서화되지 않은 모델 감지 등). 하지만 큐레이션과 소유권은 사람이 담당해야 한다.

다음 두 섹션에서는 그 소유권 부담을 실제로 실천 가능한 수준으로 낮추는 방법을 다룬다.

스킬

진실 공급원이 에이전트의 선언적(declarative) 지식(즉, 지표의 의미)이라면, 스킬은 절차적(procedural) 지식이다. 어떤 소스를 어떤 순서로 참조할지, 모호한 데이터를 어떻게 다룰지, 완성된 분석이 어떤 모습이어야 하는지를 담는다.

Claude Code에서 스킬은 에이전트가 필요할 때 읽는 마크다운 파일 모음이다. Anthropic에서 개발한 스킬은 엄청난 가치를 더해준다. 스킬 없이는 Claude의 분석 질문 답변 정확도가 평가(eval)에서 21%를 넘지 못했다. 스킬을 추가하면 이 수치가 전체적으로 일관되게 95% 이상을 기록하고, 특정 도메인에서는 99%에 달하기도 한다. 대부분의 스킬을 만들 때 사용하는 골격은 부록을 참고하라.

몇 가지 모범 사례를 소개한다.

쌍을 이루는 스킬 설계: knowledge 스킬은 필요에 따라 추가 도메인 세부 정보를 불러올 수 있게 해주는 얇은 최상위 라우터 역할을 한다. "먼저 시맨틱 레이어를 시도하되, 커버리지가 없으면 이 도메인의 관련 테이블, 컬럼, 조인, 주의사항을 설명하는 약 30개의 참조 파일을 활용하라"고 안내한다. 이 라우터는 사실상 검색 실패에 대한 우리의 해법이다. 에이전트가 수백만 개의 필드를 가진 웨어하우스를 탐색하는 대신, 쿼리를 작성하기 전에 수십 개의 큐레이션된 파일로 탐색 범위를 좁혀준다. unbook 스킬은 시니어 분석가가 따를 법한 절차를 그대로 담는다. 질문을 명확히 하고, 소스를 찾고(knowledge 스킬을 통해), 쿼리를 실행한 뒤, 결과를 적대적 검토 서브 에이전트에 돌리는 루프를 구성한다. 또한 일반적인 요청이 매번 새로 만들어지지 않도록, 리텐션 곡선, 비율 분해, 퍼널 분석 등 수십 가지 재사용 가능한 분석 패턴도 함께 담는다.

적절한 참조 문서 작성: LLM이 검색하는 방식에 맞게 작성한다. 참조 문서에는 테이블(그레인, 범위, 제외 조건), 주의사항의 구체적인 처리 방식(예: "알려진 무료 이메일 도메인은 제외하되, anthropic.com과 같은 커스텀 도메인은 유지"), 명시적인 라우팅 트리거(예: "실험 리프트에 관한 질문이라면… 원시 이벤트 카운트에는 사용하지 말 것")를 포함한다. 단, 금방 낡아버리는 처방적 레시피는 담지 않는다. 참조 문서를 만들 때 사용하는 골격은 아래를 참고하라.

# [Domain] Tables

## Quick Reference
### Business Context — [what this domain means in plain words]
### Entity Grain — [what one row represents]
### Standard Hygiene Filter — [the filter every query in this domain applies]

## Dimensions
- [How the key dimensions are encoded, and how the same concept is named
  differently across tables]

## Key Tables
### [table_name]
- **Grain**: [...] · **Scope/exclusions**: [...]
- **Usage**: [when to use it, when NOT to, join keys, required filters]
[... one short section per governed table ...]

## Gotchas
- [The wrong-answer modes a senior analyst would warn you about]

## Best Practices / Common Query Patterns
- [Default choices, standard cuts, worked patterns where the exact query
  form is the hard part]

## Cross-References
- [Neighboring domain docs that own adjacent questions]

스킬 유지보수를 핵심 작업으로 다루라: 스킬 문서는 매일 변하는 데이터 모델을 설명하기 때문에, 능동적으로 관리하지 않으면 몇 주 만에 틀린 내용이 된다. 출시 시점에 ~95%였던 오프라인 정확도가 한 달 만에 ~65%까지 떨어지는 것을 지켜본 뒤에야 이를 엔지니어링 문제로 다루기 시작했다. 구체적인 조치는 스킬 마크다운 파일을 변환 모델과 같은 저장소에 두는 것이었다. 이렇게 하면 모델을 변경하는 PR이 그 모델을 설명하는 문서를 업데이트하는 PR과 동일해진다. 코드 리뷰 훅은 스킬 파일을 수정하지 않은 리포팅 모델 변경사항을 자동으로 감지한다. 현재 데이터 모델 PR의 약 90%에는 동일한 diff 안에 스킬 변경사항이 포함되어 있다. 또한 모델이 개선되고 이전 실패 패턴이 사라짐에 따라, 스킬 스캐폴딩도 정기적으로 정리한다.

모든 서비스에서 일관되고 매끄러운 경험 제공: 동일한 스킬은 Slack, IDE, 대시보드 툴, 독립 실행형 에이전트 세션 어디서나 반드시 동일한 답변을 제공해야 한다. 단일 정규 소스(데이터 저장소)를 유지하고 스킬 변경사항이 자동으로 동기화되도록 함으로써 이를 구현했다. 머지 시 스킬은 플러그인 마켓플레이스(IDE 사용자용), 클라우드 스토리지 블롭(단일 파일을 읽는 호스팅 앱용)에 동기화되고, MCP를 통해 리소스로 직접 제공된다. 또한 하드코딩된 저장소 경로와 서비스별 네임스페이스를 피함으로써 처음부터 이식성을 고려해 설계했다.

검증

검증은 세 가지 실패 유형 중 어떤 것이 여전히 새어나오는지 파악하는 방법이다.

오프라인 평가

흔히 볼 수 있는 패턴 중 하나는, 데이터 팀이 정교한 분석 환경을 구축하면서도 에이전트 정확도를 파악하는 프로세스는 갖추지 않는 경우다.

이 문제를 해결하는 한 가지 방법이 오프라인 평가다. 오프라인 평가는 단순한 질문·정답 쌍으로 구성된다. ML 모델의 오프라인 테스트와 유사하게 생각하면 된다. 온라인 에이전트의 실제 성능을 직접 알려주진 않지만, 적절한 평가 커버리지를 갖춘다면 명백한 취약점이 없는지 파악하는 데 효과적이다.

Anthropic에서는 두 종류의 오프라인 평가를 운영한다. 대시보드 기반 평가는 가장 일반적인 이해관계자 질문을 다루며, Claude가 자동 생성하고 사람이 검증한다. 롱테일 평가는 Claude에게 비즈니스 컨텍스트(로드맵, 테이블 문서)를 제공하고 도메인 전반에 걸쳐 예상 가능한 질문을 생성하게 하는 방식이다. 또한 이해관계자가 스레드에서 에이전트를 수정할 때마다 해당 수정 내용을 평가 후보로 지속적으로 수집한다.

그 외 모범 사례는 다음과 같다.

• 드리프트를 막는 기준값 고정: 실제 데이터를 기준으로 작성된 평가는 기반 수치가 바뀌는 순간 낡아진다. 모든 평가를 특정 스냅샷 날짜에 고정하거나, 안정적인 팩트 테이블을 기준으로 작성하거나, 채점자가 에이전트의 결과 숫자가 아닌 쿼리를 평가하도록 설계하라. 평가 세트를 CI에 연결해 의존성이 변경된 PR이 관련 평가를 자동으로 재실행하도록 한다.
• 결과를 테스트 로그가 아닌 텔레메트리처럼 저장하라: 모든 실행 결과를 스킬 버전, git SHA, 모델 ID, 항목별 합격/불합격, 토큰 수, 실행 시간과 함께 웨어하우스 테이블에 저장한다. "이 변경사항이 도움이 됐나?"는 질문이 단순한 쿼리로 답변되고, 단일 CI 실행으로는 잡기 어려운 점진적 성능 저하를 시계열로 감지할 수 있다.
• 도메인별 출시 기준 설정: 도메인 담당자는 해당 도메인의 평가 세트가 특정 임계값(초기에는 ~90%를 사용)을 통과해야만 이해관계자에게 에이전트를 공개할 수 있다. 이 방식은 사용자가 실패를 경험하기 전에 참조 문서를 수정하도록 강제한다.
• 적절한 수의 평가 구성: 필요한 평가 수는 비즈니스 영역의 복잡도와 기반 데이터 모델의 복잡도에 따라 다르다. 오프라인 정확도가 온라인 정확도를 얼마나 잘 예측하는지 추적해 기준을 잡아라. 우리 경험에서는 토픽(예: "성장")당 수십 개를 넘어서면 수확 체감이 시작되고, 새로운 모델 세대가 나올수록 그 한계치도 낮아지는 경향이 있다.
• 오프라인 평가 정확도는 ~100%를 목표로 해야 한다. 올바른 답변은 시맨틱 레이어(있는 경우)에도 반드시 도달해야 한다. 다시 강조하지만, 이 수준의 정확도가 시스템이 절대 오답을 내지 않는다는 보장은 아니다. 적절한 평가 커버리지를 갖춘 상태에서 명백한 취약점이 없다는 것을 의미할 뿐이다.

에블레이션 기법

스킬에 관한 모든 구조적 결정(어떤 소스를 노출할지, 서브 에이전트가 그 지연 시간을 감수할 만한지, 두 스킬을 하나로 합칠지 등)은 오프라인 평가 세트를 고정한 채로 진행한다.

구성 요소 하나만 변경하고 통과율을 비교한다. 실행 한 번에 한 시간이면 충분하고, 많은 논쟁을 대체한다. 개별 결과보다 방법론이 더 중요하다.

• 부정적 결과를 위한 설계. 가장 유용했던 에블레이션은 부정적인 결과를 낸 실험이었다. 에이전트에게 전체 대시보드, 변환 로직, 분석 노트북 SQL(수천 개의 파일)에 대한 직접 grep 접근 권한을 부여했다. 실행 트랜스크립트를 통해 에이전트가 매번 답변 전에 실제로 해당 파일을 읽는다는 것도 확인했다. 그런데 정확도는 어느 방향으로도 1%포인트 미만으로 움직였다. 분명한 교란 변수도 확인했다. 오답을 낸 질문의 경우, 정답이 코퍼스에 있었는가? 약 80%의 경우 그랬다. "정답 존재"가 "이번엔 맞힘"을 예측했는가? 그렇지 않았다. 뒤집기 비율은 변하지 않았다. 정보가 있었고, 에이전트가 그것을 봤지만, 여전히 활용하지 못했다. 이 단 하나의 실험이 병목이 이전 작업에 대한 접근성이 아니라 구조(즉, 질문을 올바른 엔티티로 연결하는 것)에 있다는 사실을 알려줬다. 이 인사이트가 몇 달치 로드맵 방향을 바꿨다.
• PR 단위로 에블레이션 수행. 의미 있는 스킬 수정마다 관련 평가 슬라이스에 대해 변경 전·후 실행 결과를 비교하고, 그 차이를 PR 설명에 기록한다. "문서를 개선했다"는 주장을 검증할 수 있게 해주고, 선의로 추가한 내용이 오히려 성능을 저하시키는 놀랍도록 흔한 경우를 잡아낸다.
• 효과 없었던 것의 목록을 짧게 유지하라. 우리의 경우 두 가지가 있다. 특정 지점을 넘어서 문서 정제를 추가로 반복한 것(세 번 연속으로 순 부정적인 결과가 나왔다. 문서가 나아지는 게 아니라 길어지고 있었다)과, 지연 시간 단축을 위해 적대적 검토자를 더 저렴한 모델로 교체한 것(정확도 향상의 대부분이 사라진 반면, 실질적인 속도 향상은 없었다). 부정적인 결과는 기록 비용이 낮고, 다음 사람이 같은 실험을 반복하는 것을 막아준다.

온라인 검증

마지막 단계는 실제 온라인 시스템 성능을 최대한 정확하게 유지하는 것이다. 우리가 취하는 조치들은 다음과 같다.

• 적대적 검토: Claude 스킬을 활용해 잠재적인 최종 답변의 모든 기반 가정을 공격적으로 검증하면, 평가 세트 내 정확도가 6% 향상되었다. 다만 토큰은 32%, 지연 시간은 72% 증가하는 비용이 따른다.
• 출처 푸터: 모든 응답에는 어떤 소스 계층에서 왔는지(시맨틱 레이어 › 큐레이션된 참조 › 원시 테이블), 기반 데이터의 최신성, 모델 소유자 정보를 담은 푸터가 포함된다. 답변의 정확도를 높이는 건 아니지만, 수신자가 응답을 얼마나 신뢰할지 판단하는 데 도움이 된다. "원시 테이블, 최신성 불명"이라는 푸터는 상위에 전달하기 전 검증하라는 신호이며, 무음 실패(silent failure)에 대한 몇 안 되는 완화 수단 중 하나다.
• 데이터 품질 검사: 에이전트가 올바른 필드를 적절한 방식으로 사용하더라도, 데이터 자체가 잘못됐을 수 있다. 참조된 필드가 최신 상태인지, 완전한지, 이상값이 없는지 확인하는 기본적인 데이터 품질 검사를 추가하는 것은 일반적으로 좋은 위생 관리다.
• 수동 모니터링: 지속적으로 추적하는 두 가지 운영 지표는 시맨틱 레이어를 통해 해결되는 에이전트 쿼리의 비율과, 수정 언어("그건 잘못된 테이블입니다", "사기 필터가 빠져 있습니다")를 사용하는 응답의 비율이다. 두 지표 모두 오프라인 통과율과 함께 매주 리뷰하는 대시보드에 반영된다.
• 능동적 수정 수집: 피드백 루프를 닫는 핵심 단계다. 예약된 에이전트가 몇 시간마다 이해관계자 채널을 스캔해 유사한 수정 언어를 찾아내고, 관련 참조 문서에 대한 한 줄짜리 수정 초안을 작성해 도메인 담당자에게 태그된 PR을 연다. 수정 경로는 의도적으로 단순하게 유지한다. 마크다운 파일 수정, 머지, 자동 동기화. 도메인 담당자가 여기에 많은 시간을 쏟지 않도록 하기 위해서다. 동일한 수정 내용은 오프라인 평가 세트로도 피드백된다.

이 모든 방법으로도 완전히 잡기 어려운 실패 유형은 무음 실패다. 답이 틀렸지만 그럴듯하게 보여서 아무 이의 없이 사용되는 경우다. 우리의 완화 방법은 출처 푸터, 리더십에 전달되는 모든 내용에 대한 명시적인 사람의 검토, 그리고 각 도메인의 핵심 KPI를 매일 공식 대시보드와 대조해 정상 여부를 확인하는 정기 평가 세트다. 다만 아직 완전한 해결책은 없다.

시작하기

완전히 처음 시작하는 경우라면, 소수의 정규 데이터셋, 수십 개의 오프라인 평가, 그리고 얇은 knowledge 스킬만으로도 대부분의 가치를 얻을 수 있다. 이 글에서 다룬 나머지 내용들은 그 기반을 구축한 이후에 추가한 것들이다.

이 글에서 다양한 모범 사례를 소개했지만, 모든 데이터 팀에 적합한 방법이 동일하지는 않다. 접근 방식에 영향을 미치는 몇 가지 원칙에 대해 조직과 먼저 논의해 보기를 권한다.

• 지금 당장의 정확한 답변과 미래의 정확성 중 무엇이 더 중요한가? AI 모델은 빠르게 발전하고 있다. 많은 기업이 현재 모델의 한계를 보완하기 위해 상당한 인프라를 구축하지만, 모델이 개선되면서 그 인프라의 상당 부분이 불필요해지는 경우를 자주 본다. 모델이 부족한 부분을 파악하고 모델 발전이 그 격차를 메울 때까지 기다리는 방식은 오버헤드가 훨씬 적지만, 조직의 리스크 허용 범위에 맞지 않을 수 있다.
• 시간이 지남에 따라 비즈니스 복잡도가 어떻게 변할 것으로 예상하는가? 예를 들어 데이터 생산량이 많지 않거나, 결과물의 소비자가 소수이거나, 데이터 모델이 단순하게 유지될 것으로 예상된다면, 앞서 논의한 일부 프로세스는 과도한 투자일 수 있다.
• 결과물의 대상 독자는 얼마나 기술적인가? 달리 말하면, 이 분석 시스템을 오답을 알아볼 수 있는 데이터 사이언티스트를 위해 만드는 경우라면, 기반 데이터 모델에 익숙하지 않은 독자가 대상인 경우보다 오류에 더 관대할 수 있다.
• 정확도 향상을 위해 얼마나 투자할 의향이 있는가? 적대적 검증과 같은 특정 프로세스가 정확도를 크게 높일 수 있지만, 더 높은 비용과 지연 시간이 수반되는 경우가 많다.
• 접근 제어와 내부 데이터 프라이버시에 대한 입장은 어떠한가? 에이전트는 일반적으로 컨텍스트가 많을수록 성능이 크게 향상된다. 하지만 광범위한 데이터 접근은 대부분의 기업이 지향하는 거버넌스 방향과 충돌한다. 이 문제가 하나의 에이전트를 만들지, 아니면 범위가 좁은 여러 에이전트를 만들지를 결정하는 요인이 된다.

어떤 경로를 선택하든, 우리가 가장 큰 성과를 거둔 방법은 세 가지 실패 유형을 모두 직접 공략하는 것이었다. 모호성을 단 하나의 공식 답변으로 수렴시키고, 그 답변을 쉽게 찾을 수 있게 하며, 어느 하나라도 낡아졌을 때 이를 감지하는 것이다.

이 글은 데이터 사이언스 및 데이터 엔지니어링 팀의 Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry가 작성했습니다. Michael Segner의 기여에 감사드립니다.

부록

스킬 파일 골격

아래는 우리가 사용하는 메인 웨어하우스 스킬의 골격이다. 실제 파일 구조를 바탕으로, 내부 세부 내용은 [괄호 형식의 플레이스홀더]로 대체했다. 그대로 복사해서 쓰라는 것이 아니라, 우리가 기록할 가치가 있다고 판단한 섹션의 종류를 보여주는 것이 목적이다.

---
name: [warehouse-skill]
version: [x.y.z]
description: "IF the user asks to query [the company]'s data warehouse for any
  [list of business domains] question — THEN invoke this skill. DO NOT invoke
  for [adjacent engineering tasks] or questions with no data-warehouse component."
---

# [Warehouse] Skill Instructions

## Description
The single source of truth for safe and effective [warehouse] querying.
Referenced by other skills [listed] for query execution guidance.

Act as a Data Analyst, providing strategic insights and data-driven
recommendations but seek guidance along the way.

**Out-of-scope decisions**: [product areas, etc.] → surface data only,
state "decision is [owning team]'s call", do NOT take a position or author
code fixes.

## Executing queries
Priority:
1. **[Managed connection]** (if available): [query tool] / [schema tool]
2. **[CLI fallback]** (if installed): [default project, fallback project]
3. **Neither** — ask the user to authenticate, then stop

---

# Semantic Layer (REQUIRED first step)

The governed semantic layer is the **mandatory default path** for every data
question — same numbers as [the BI tool], joins/grain/filters baked in. Raw SQL
via the reference docs below is the **fallback**, used only after the
semantic-layer path is shown not to cover the ask.

## Required workflow
1. **Load** — [how to load the semantic layer in each runtime, with fallbacks]
2. **Discover** — search measures/dimensions by keyword; **always check
   segments** (the named canonical population filters — hand-rolled WHERE
   clauses for these are the dominant wrong-answer mode)
3. **Compile + run** — build the spec → compile to SQL → execute
4. **Fallback** — only if discovery finds no relevant metric or compile fails
   → raw SQL via `references/*.md` (PART 3 below)

> **Don't bail early.** Do NOT fall back to raw SQL on these grounds:
> - "[custom date filtering / cohorts]" → [covered by time-dimension specs]
> - "[needs a join]" → [the metric layer already encapsulates its joins]
> - [3–4 more pre-rebutted excuses agents use to skip the semantic layer]

### Date windows & timezone — decide before you query
- **As-of date vs trailing-N days**: [convention for each]
- **"Last week/month"** → the last *complete* calendar week/month, not trailing-7/30
- **Timezone default**: [TZ]; [exception for certain reporting rollups]
- **Freshness lag**: [some] tables settle late — anchor on MAX(date), not "yesterday"

---

# PART 1: MUST KNOW (Read First for Every Request)

## 🚀 Quick Start Workflow
1. **Check for red flags first**: [restricted/PII requests, gated domains,
   high-stakes asks that need extra validation]
2. **Out of scope — escalate, don't guess**: [access requests, pipeline
   troubleshooting, stale dashboards, root-cause assertions, product/pricing
   recommendations] → redirect to [the owning team], don't answer
3. **Clarify the request**: time period, segment, the business decision it informs
4. **Check for existing dashboards**: [per-domain dashboard catalogs]
5. **Identify the data source**: [navigation map below; prefer governed/aggregated tables]
6. **Execute the analysis**: [required filters + adversarial review]
7. **Deliver insights**: show methodology, differentiate observations from interpretations

## 🏢 Business Context

### Entity Disambiguation (MUST CLARIFY)
- **"[Term A]" can mean**: [entity 1] or [entity 2] — always clarify which
- **"[Term B]" can mean**: [entity 1] → [entity 2] → [entity 3] (one-to-many chain)
- **"Users"**: [which identifier gives accurate counts, and which ones inflate them]

### Business Terminology
- [Current product names vs deprecated aliases that still appear as frozen
  values in the data layer — write with the new names, filter with the old]
- [Key internal acronyms]
- **[Headline metric] calculations**: [monthly / default window / leading indicator]
- **Unfamiliar terms — search [internal docs], don't guess**

### Data Integrity Requirements ⚠️
- **NEVER**: make up data/columns; make speculative assertions beyond what data shows
- **ALWAYS**: use safe division; differentiate observations ("data shows X")
  from interpretations ("this suggests Y"); flag limitations

---

# PART 2: HOW TO DO (Follow During Execution)

## 🔧 Technical Execution Guide
- [Managed-connection tools and CLI invocation details]
- **PII protection**: for restricted data, return the SQL for the user to run
  themselves — do not return results

## 📊 Analysis Best Practices Guide
1. Clarify the ask before querying
2. Show your work (filters, inclusions/exclusions, freshness)
3. Clarify denominators
4. Consider sample bias
5. Connect to business impact
6. **Adversarial SQL review (MANDATORY)** — spawn the [sql-reviewer] sub-agent
   for every query before the final answer; blocking findings must be fixed
   and re-reviewed; do not self-certify
7. **Report with provenance** — every answer ends with a footer:
   > **Source:** [semantic layer | governed table | raw exploration] ·
   > **Confidence:** [tier] · **Reviewed:** [reviewer ✓, round N] ·
   > **Freshness:** [max date in the data] · **Owner:** [owning team]

---

# PART 3: DATA REFERENCES & RESOURCES

## 📚 Knowledge Base Navigation
### [Domain A] → `references/[domain_a].md`
- **Use for**: [kinds of questions]
- **Key tables**: [...]
- **Dashboards**: `references/[domain_a]_dashboards.json`

### [Domain B] → `references/[domain_b].md`
- **Use for**: [...]

[... one entry per business domain — a few dozen in total ...]

## ⚠️ Troubleshooting Guide

### When Information Is Missing
- [missing tables / access denied / outdated docs / unknown enum values → what to do]

### Field Naming Gotchas
- Use `[field_x_v2]` NOT `[field_x]`
- [Two similarly-named tables report the same metric at different grains — which to use]
- [Which of two plausible sources is canonical for the headline metric]
- [… a dozen more hard-won one-liners …]