핵심 요약
LLM을 데이터 웨어하우스에 바로 연결한다고 정확한 분석이 자동으로 나오지는 않는다.
분석 에이전트의 정확도는 SQL 생성 능력보다, 질문을 올바른 데이터 개념과 연결하고 최신 기준으로 검증하는 구조에 달려 있다.
Anthropic은 표준 데이터 모델, 신뢰 가능한 지식 소스, Claude Skills, 오프라인·온라인 검증 체계를 결합해 비즈니스 분석 자동화 정확도를 높였다.
데이터 분석은 소프트웨어 개발과 다르다
코딩에서는 정답이 여러 개일 수 있다. 같은 기능도 다양한 방식으로 구현할 수 있고, 테스트와 문서가 결과를 검증해 준다.
반면 데이터 분석은 보통 "하나의 올바른 숫자"를 요구한다. 매출, 활성 사용자, 전환율 같은 지표는 정의가 조금만 달라도 완전히 다른 결론을 만든다.
예를 들어 "활성 사용자 수"를 묻는다고 해도 기준은 다양하다. 로그인한 사용자만 볼 것인지, 특정 행동을 한 사용자까지 포함할 것인지, 부정 사용자를 제외할 것인지, 기간은 7일인지 30일인지 정해야 한다.
따라서 분석 에이전트의 핵심 문제는 SQL을 잘 쓰는 것이 아니라, 사용자의 애매한 질문을 정확한 데이터 정의와 연결하는 것이다.
분석 에이전트가 틀리는 세 가지 이유
첫 번째는 개념과 데이터 엔티티의 혼동이다. 사용자는 "매출"이라고 묻지만 데이터 모델 안에는 매출처럼 보이는 테이블과 컬럼이 수십 개 있을 수 있다.
두 번째는 데이터와 문서의 노후화다. 스키마, 비즈니스 정의, 대시보드, 파이프라인은 계속 바뀐다. 에이전트가 어제의 정의를 오늘도 믿으면 조용히 틀린 답을 낸다.
세 번째는 검색 실패다. 정답이 문서나 데이터 모델 안에 있어도, 탐색 공간이 너무 넓으면 에이전트가 찾지 못한다.
결국 문제는 "정보가 없어서"라기보다 "올바른 정보를 좁혀서 찾고, 최신인지 확인하는 구조가 없어서" 생긴다.
좋은 데이터 기반은 에이전트 정확도의 출발점이다
정확한 분석 에이전트를 만들려면 먼저 데이터 웨어하우스 자체가 정리되어 있어야 한다.
핵심은 표준 데이터셋을 만드는 것이다. 비슷한 목적의 테이블이 여러 개 있으면 에이전트는 그중 하나를 그럴듯하게 고른다. 이때 틀릴 가능성이 커진다.
좋은 구조에서는 "매출"이라는 질문이 들어왔을 때 후보가 40개가 아니라 하나의 관리된 데이터셋으로 수렴한다.
이를 위해 표준 모델, 테스트, 최신성 검사, 완전성 검사, 소유자 정보, 컬럼 설명, 데이터 계보를 관리해야 한다. 데이터 웨어하우스를 코드베이스처럼 읽기 쉽게 만드는 것이다.
단일 진실 공급원이 필요하다
에이전트가 참고할 신뢰 계층이 있어야 한다. Anthropic은 대체로 네 가지를 사용한다.
가장 신뢰도가 높은 것은 시맨틱 레이어다. 여기에는 지표와 차원의 공식 정의가 들어 있다. 질문이 정의된 지표와 맞으면 에이전트는 직접 SQL을 짜기보다 이 계층을 먼저 사용해야 한다.
그다음은 데이터 계보와 변환 그래프다. 시맨틱 레이어에 없는 질문이라도, 어떤 모델이 어떤 상위 모델에서 왔는지 알면 더 안전하게 판단할 수 있다.
과거 쿼리 모음도 참고할 수 있지만, 원문에서는 단순히 수천 개 쿼리를 검색하게 하는 방식은 효과가 작았다고 설명한다. 중요한 것은 과거 쿼리를 그대로 던져주는 것이 아니라, 반복 패턴을 정리해 구조화된 문서로 바꾸는 것이다.
마지막으로 비즈니스 맥락이 필요하다. "Q2 출시", "핵심 고객", "그 팀의 정의" 같은 표현은 회사 내부 맥락 없이는 해석하기 어렵다.
Skills는 에이전트의 절차적 지식이다
지식 소스가 "무엇이 맞는가"를 알려준다면, Skill은 "어떤 순서로 확인해야 하는가"를 알려준다.
Claude Code의 Skill은 에이전트가 필요할 때 읽는 마크다운 기반 지침 묶음이다. Anthropic은 Skill을 통해 에이전트가 먼저 시맨틱 레이어를 확인하고, 없으면 도메인별 참조 문서를 보고, 이후 쿼리와 검증을 수행하도록 만들었다.
Skill이 중요한 이유는 검색 공간을 줄여주기 때문이다. 에이전트가 수백만 개 필드를 헤매는 대신, 특정 도메인에 필요한 수십 개의 문서와 테이블로 탐색 범위를 좁힌다.
비유하면 Skill은 신입 분석가 옆에 앉은 선임 분석가의 체크리스트다. "이 질문이면 이 문서를 먼저 보고, 이 테이블은 쓰지 말고, 이 필터는 꼭 넣어라"라고 안내한다.
참조 문서는 LLM이 찾기 쉽게 써야 한다
사람이 읽기 좋은 문서와 LLM이 검색하기 좋은 문서는 다를 수 있다.
좋은 참조 문서는 테이블의 단위, 범위, 제외 조건, 조인 키, 필수 필터, 자주 틀리는 지점을 명확하게 적는다.
예를 들어 "이 테이블은 실험 효과 분석에는 쓰지만, 원시 이벤트 수 집계에는 쓰지 말 것"처럼 사용 조건과 금지 조건을 분명히 적어야 한다.
반대로 너무 자세한 SQL 레시피를 많이 넣으면 금방 낡는다. 문서는 매번 복사할 쿼리 모음이 아니라, 올바른 판단을 돕는 안내판에 가까워야 한다.
문서 유지보수는 선택이 아니라 운영 시스템이다
데이터 모델은 매일 바뀐다. 그런데 Skill과 참조 문서가 그대로라면 에이전트 정확도는 빠르게 떨어진다.
Anthropic은 Skill 문서를 데이터 변환 코드와 같은 저장소에 두었다. 모델을 바꾸는 PR이 문서도 함께 바꾸도록 만든 것이다.
또한 보고용 모델이 바뀌었는데 Skill 파일이 수정되지 않으면 코드 리뷰에서 경고가 뜨게 했다.
핵심은 문서 업데이트를 "나중에 시간 날 때 하는 일"로 두지 않는 것이다. 데이터 변경과 문서 변경이 같은 흐름 안에서 일어나야 한다.
오프라인 평가는 출시 전 안전망이다
분석 에이전트를 만들었다면 반드시 질문-정답 세트로 평가해야 한다.
오프라인 평가는 실제 운영 환경을 완벽히 대체하지는 못하지만, 명백한 구멍을 찾는 데 유용하다.
평가 질문은 대시보드에서 자주 나오는 질문을 바탕으로 만들 수 있고, 장기적으로는 사용자가 에이전트를 정정한 사례도 평가 세트에 추가할 수 있다.
중요한 점은 정답이 흔들리지 않게 고정하는 것이다. 실시간 데이터에 대해 "어제 매출은?"이라고 평가하면 시간이 지나며 정답이 바뀐다. 그래서 스냅샷 날짜나 안정된 팩트 테이블을 기준으로 삼아야 한다.
Ablation은 감이 아니라 실험으로 개선하는 방법이다
Ablation은 한 번에 하나의 요소만 바꿔 성능 차이를 보는 실험이다.
예를 들어 "과거 SQL 전체를 검색하게 하면 정확도가 오를까?"를 테스트할 수 있다. Anthropic은 이 실험에서 정확도가 거의 오르지 않았다고 설명한다.
흥미로운 점은 답이 과거 쿼리 안에 있었는데도 에이전트가 제대로 활용하지 못했다는 것이다. 문제는 정보 접근이 아니라 구조화와 라우팅이었다.
이런 실험은 논쟁을 줄인다. "문서를 더 길게 쓰자", "저렴한 모델로 리뷰하자" 같은 주장도 평가 세트에서 실제로 좋아지는지 확인하면 된다.
온라인 검증은 실제 사용 중의 사고를 줄인다
운영 환경에서는 에이전트가 그럴듯하지만 틀린 답을 낼 수 있다. 이를 줄이기 위해 여러 장치가 필요하다.
하나는 적대적 리뷰다. 별도의 리뷰 에이전트가 쿼리와 가정을 공격적으로 검토하게 하면 정확도는 오르지만, 토큰 비용과 지연 시간이 증가한다.
또 하나는 출처 표기다. 답변 끝에 시맨틱 레이어를 썼는지, 관리된 테이블을 썼는지, 원시 테이블을 탐색했는지, 데이터가 얼마나 최신인지, 소유자가 누구인지 표시한다.
데이터 품질 검사도 중요하다. 올바른 컬럼을 썼더라도 그 컬럼 자체가 늦게 적재되었거나 누락되었을 수 있다.
마지막으로 사용자 정정 표현을 모니터링한다. "그 테이블이 아니야", "필터가 빠졌어" 같은 피드백은 문서 수정과 평가 세트 보강으로 이어져야 한다.
처음 시작할 때 필요한 최소 구성
처음부터 거대한 시스템을 만들 필요는 없다.
가장 먼저 할 일은 핵심 비즈니스 영역별 표준 데이터셋을 몇 개 만드는 것이다. 그다음 자주 묻는 질문을 기준으로 오프라인 평가 세트를 수십 개 만든다.
이후 얇은 지식 Skill을 만들어 에이전트가 시맨틱 레이어와 참조 문서를 먼저 보게 한다.
출발점은 단순하다. 후보를 줄이고, 정답 위치를 알려주고, 낡은 정보를 발견하는 구조를 만드는 것이다.
인사이트
LLM 분석 에이전트의 성패는 모델의 똑똑함보다 조직의 데이터 운영 방식에 더 크게 좌우된다.
가장 실용적인 원칙은 세 가지다. 하나의 관리된 답으로 모호성을 줄이고, 그 답을 에이전트가 쉽게 찾게 만들고, 시간이 지나 낡았을 때 자동으로 드러나게 해야 한다.
작게 시작하려면 "핵심 지표 10개", "표준 테이블 몇 개", "자주 묻는 질문 평가 세트", "간단한 Skill 문서"부터 만들면 된다. 이 네 가지가 있으면 LLM은 단순한 SQL 생성기를 넘어, 실제 업무에 쓸 수 있는 분석 동료에 가까워진다.
Source : How Anthropic enables self-service data analytics with Claude | Claude
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.