핵심 요약 (Takeaways)

• AI를 이용한 데이터 분석의 문제는 '코드 생성 (Code Generation)'의 정확도가 아니라, 질문을 올바른 데이터와 연결하는 '문맥 (Context)'의 문제입니다.
• 실패 모드는 3가지가 있습니다 — 모호성 (Ambiguity) (어떤 정의를 사용할 것인가?), 신선도 (Freshness) (문서가 노후화됨), 검색 실패 (Retrieval Failure) (정답이 있음에도 찾지 못함).
• 이 3가지 모드에 대해 4계층 스택 (4-layer stack) (데이터 기반, 정보원, 기술 (skills), 검증)으로 대응함으로써 정확도를 높일 수 있습니다 (Anthropic에서 약 95% 달성).

작동은 하지만, 틀린다

LLM에게 분석을 부탁해 본 적이 있는 사람이라면 공감할 것입니다. SQL은 깔끔하게 작성되어 있습니다. 실행도 잘 됩니다. 숫자도 반환됩니다. 무서운 점은, 틀린 숫자임에도 불구하고 매우 그럴싸한 모습으로 반환된다는 것입니다.

코딩에서는 그렇게 믿음직한 파트너인데, 분석이 되는 순간 갑자기 신뢰할 수 없게 됩니다. 이 격차는 어디에서 오는 걸까요?

이 '이유'를 제가 읽은 내용 중 가장 납득이 가는 방식으로 분해해 놓은 것이 Anthropic의 데이터 사이언스 팀이 작성한 글입니다.

Anthropic 사내에서는 업무 분석 쿼리의 95%를 Claude가 자동화하고 있으며, 집계 정확도는 약 95%라고 합니다. Warehouse에 Agent를 연결해서 실행하는 것만으로는 '정확도가 높다는 착각 (false sense of precision)'을 불러일으킬 뿐이라고 먼저 경고한 뒤, 오류를 3가지 실패 모드로 분해하고, 효과가 없었던 대책과 아직 해결되지 않은 빈틈까지 공개하고 있습니다.

저 자신도 Data Analyst로서 AI 활용에 고전했던 입장이기에, 이 글은 제 현장 경험에서 공감할 수 있는 부분이 많아 소개하고자 합니다. 아래는 제 이해를 곁들여, 최대한 원문의 골격(문제 제기 → 해결책 → 검증 → 한계)을 유지하면서, 똑같이 고전하고 있는 분들을 위해 다시 정리한 내용입니다.

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

먼저 전제 조건에 대한 질문입니다. 같은 모델인데 왜 코딩에서는 신뢰할 수 있고, 분석에서는 신뢰할 수 없는 걸까요? 원문은 이를 "데이터는 소프트웨어가 아니다"라고 표현합니다.

코드는 틀리면 에러가 납니다. 하지만 분석은 틀려도 그럴듯한 징후가 없는 경우가 대부분입니다. 그럴싸한 숫자가 조용히 반환될 뿐입니다.

그리고 원문의 핵심은 이 문장입니다. 문제는 "사용자의 질문을 데이터 모델 내의 구체적이고 최신인 (specific and up-to-date) 데이터 필드에 매핑하고, 그 올바른 취급 방법을 아는 것"입니다. 그것만 할 수 있다면 SQL을 작성하는 작업 자체는 매우 간단하다는 것입니다.

즉, 우리가 막히고 있는 부분은 SQL 생성 능력이 아닙니다. 프롬프트로 SQL 작성법을 아무리 지도해도 고쳐지지 않는 이유도 바로 그것입니다. 고쳐야 할 곳이 다르기 때문입니다.

오류는 3가지 실패 모드로 분해할 수 있다

부정확한 답변의 거의 모든 것은 다음 3가지 실패 모드로 귀결됩니다.

가장 깊은 모호성의 예를 원문의 그림을 빌려 다시 그려보겠습니다. "지난달 활성 사용자 수는?"라는 질문의 답은 하나의 Fact Table에 있지만, 어떤 Dimension을 기준으로 삼느냐에 따라 'active'의 정의가 갈립니다.

이 3가지는 모두 기술적으로는 옳습니다. SQL은 3개 모두 정상적으로 작동하며, 3개의 서로 다른 숫자가 반환됩니다. 그리고 그중 무엇이 틀렸다고 단정 지을 수 없습니다.

이것은 제 현장의 기억과도 일치합니다. 컨설팅에 있을 당시, 같은 회사 안에서도 '활성 사용자 (Active User)'의 정의가 부서마다 갈리곤 했습니다. 영업 부서는 지금 움직이고 있는 고객을 파악하기 위해 3일~1주일의 짧은 기간을 보고 싶어 했습니다. 마케팅 부서는施策(시책)의 효과를 추적하기 위해 1개월이라는 넓은 범위를 보고 싶어 했습니다. 둘 다 업무상 옳습니다. 사람끼리는 "영업팀에서 말하는 활성 사용자 말이죠"라며 대화의 문맥으로 보정하지만, 에이전트 (agent)는 이 비즈니스 컨텍스트 (business context)를 명시적으로 가르쳐주지 않는 한 알 방법이 없습니다.

자신의 환경에서 AI 분석이 틀렸을 때, "모델이 멍청해서 그래"라고 치부하기 전에 이 3가지 실패 모드 (failure modes)를 이해하고 깊이 파고든다면 대책의 해상도가 달라질 것입니다.

대책의 전체상: 어떤 계층이 어떤 실패 모드를 해결하는가

Anthropic의 해결책은 4개 계층의 스택 (stack)으로 구성되어 있으며, 어떤 계층이 어떤 실패 모드에 효과적인지 표로 나타내면 다음과 같습니다.

계층 1 데이터 기반: 데이터 자체를 정리한다 (모호성 · 최신성)

이 계층이 다루는 것은 데이터 그 자체입니다. 예를 들어, "이번 달 revenue는?"이라는 질문 하나에도 사내에는 계산 근거가 흩어져 있습니다.

• 가공되지 않은
  raw_transactions

• 집계된
  finance.monthly_revenue

• 각 분석가가 과거에 작성한
  SUM(amount)

이 수십 가지 방식으로 존재하며, 세금 포함·세금 별도·환불 전후에 따라 숫자가 어긋나기 때문에 에이전트 (agent)는 무엇이 정답인지 결정할 수 없습니다.

오해하기 쉬운 점은 '하나로 만든다'는 의미입니다. 세금 별도와 세금 포함처럼 정당하게 다른 것은 없애지 않습니다. 없애는 것은 아무도 관리하지 않고 각자 계산한 우연한 중복뿐입니다. 정당한 차이는 canonical한 원천을 하나(예: 세금 별도)로 정하고, 거기서부터 기계적으로 파생시킵니다. 세금 포함은 "canonical + tax"의 파생물이지, 서로 경쟁하는 별개의 정의가 아닙니다. 소스 (source)가 하나라면 파생이 아무리 많아도 서로 모순되지 않습니다. 이렇게 계산 근거가 하나의 계통으로 통합되면, 어떤 revenue인지에 대한 모호성도, 어떤 것이 최신인지에 대한 최신성 문제도 처음부터 발생하지 않습니다.

계층 2 정보원: 어디서 가져올지를 결정한다 (모호성)

계층 1이 데이터 자체를 정리한다면, 계층 2가 결정하는 것은 **에이전트 (agent)가 답을 "어디서 가져올 것인가"**입니다. 데이터를 하나로 통합하더라도 에이전트에게 어디를 보라고 가르쳐주지 않으면 다시 헤매기 때문입니다.

최우선 순위는 시맨틱 레이어 (semantic layer) — 컴파일된 지표 정의입니다. "revenue를 출력해줘"라는 요청에 대해, 함수를 호출하듯 하나의 숫자가 반환되며 사내의 어떤 도구에서 물어도 동일한 값이 됩니다. 에이전트 (agent)는 스킬 (skill) 지시를 통해 우선 이곳을 참조하도록 구조적으로 제약됩니다.

앞서 언급한 '활성 사용자'도 여기서 해결할 수 있습니다. 영업은 3일, 마케팅은 30일 — 둘 다 정당했습니다. 시맨틱 레이어 (semantic layer)는 이를 active_3d, active_30d와 같이 이름이 붙은 지표 (named metrics)로서 둘 다 정의합니다. 에이전트 (agent)는 "어떤 active인가"를 모호하게 추측하지 않고, 이름을 지정하여 호출합니다. 계층 1의 revenue와 마찬가지로 용도를 없애는 것이 아니라, 정의를 한곳에 모아 호출할 수 있도록 만드는 것입니다.

정의와 컴파일 후의 SQL 보기 (의사 코드)

정의는 다음과 같이 설정해 둡니다.

# 시맨틱 레이어 (semantic layer) 정의 (한 곳에서 버전 관리)
metric active_3d:
measure: count_distinct(user_id)
...

에이전트 (agent)가 active_3d를 지칭하면, 컴파일되어 실행되는 SQL은 다음과 같습니다.

SELECT COUNT(DISTINCT user_id)
FROM fact_events
WHERE event_date >= CURRENT_DATE - INTERVAL '3 days'

숫자는 여기서 처음으로 계산됩니다. 저장된 값을 가져오는 것이 아닙니다.

semantic layer (시맨틱 레이어)만으로 부족할 경우를 대비하여, 참조 대상에는 신뢰도의 서열이 존재합니다. 위에서부터 semantic layer → lineage (데이터 계보) → query corpus (과거의 SQL 자산) → business context (사내 문서·로드맵·조직 구조) 순입니다.

여기서 원문이 강조한 점은, 신뢰도의 순위와 중요도의 순위는 별개라는 것입니다. business context의 신뢰도가 최하위임에도 불구하고 중요도는 최상위 클래스에 해당합니다. 비즈니스를 이해하지 못하는 agent는 "질문에는 답하지만, 의도에는 답하지 못하기" 때문입니다. 앞서 언급한 영업과 마케팅의 사례가 바로 이것입니다. active_3d와 active_30d를 모두 준비해 두더라도, "영업이 active라고 말하면 3일 기준이다"라는 대응 관계는 데이터 모델 내부가 아니라 조직 내부에 존재합니다. 가르쳐주지 않는 한 agent에게는 보이지 않습니다. 신뢰도가 낮다고 해서 중요도까지 낮다고 착각한 팀들이 이 부분을 놓치곤 합니다. 원문에 따르면 "우리가 가장 오랫동안 과소평가해 온 계층"이라고 합니다.

계층 3 skills: 가장 효과적인 레버 (검색 실패·신선도)

skills가 없을 때는 평가 세트에서의 정답률이 21%를 넘지 못했다. skills를 추가하면 95%를 초과하며, 도메인에 따라서는 99% 전후까지 올라간다.

동일한 모델에서 skill을 통해 증가한 것은 지능이 아니라 구조입니다.

skill은 두 종류를 한 쌍으로 만듭니다. 역할의 축은 단순하며, **한쪽은 "어디를 볼 것인가", 다른 한쪽은 "어떻게 진행할 것인가"**입니다.

• knowledge skill = "어디를 볼 것인가". 질문을 받으면 "그 이야기라면 이 참조 파일군을 보라"고 안내하는 역할입니다. "먼저 semantic layer를 보고, 없다면 이 도메인의 약 30개 파일을 확인하라"와 같은 식입니다. 수백만 개의 필드가 있는 warehouse를 쿼리를 작성하기 전에 수십 개의 파일로 좁히는 것—이것이 검색 실패(retrieval failure)에 대한 대처법입니다.
• runbook skill = "어떻게 진행할 것인가"에 대한 절차서. 질문을 명확히 하고, 소스를 특정하고, 쿼리를 실행하고, 마지막으로 다른 agent에게 적대적 리뷰(adversarial review)를 시키는—이 순서를 매번 밟게 합니다. 리텐션 곡선(retention curve)이나 퍼널 분석(funnel analysis) 같은 정형화된 패턴도 포함하여, 매번 처음부터 생각하게 만들지 않습니다.

※ 참조 문서의 템플릿이 원문에 공개되어 있습니다.

skill은 살아있는 데이터 모델을 설명하는 문서입니다. "revenue는 세전 금액이다", "active는 이 테이블을 의미한다"와 같은 내용 말입니다. 따라서 엔지니어가 정의를 변경했는데 skill을 수정하는 것을 잊어버리면, agent는 오래된 전제를 바탕으로 조용히 틀린 답변을 내놓게 됩니다. 실제로 Anthropic의 검증에 따르면, 방치할 경우 offline 정확도는 한 달 만에 95%에서 65%까지 떨어졌습니다.

해결 방법은 "자주 업데이트하자"가 아니라, 업데이트를 잊어버리는 것이 구조적으로 불가능하게 만드는 것입니다. skill의 마크다운(markdown) 파일을 데이터 변환 SQL과 동일한 리포지토리(repository)에 둡니다. 이렇게 하면 fct_revenue.sql (revenue의 정의)을 변경하는 PR을 올리는 시점에, 이를 설명하는 revenue.md가 동일한 변경 사항 바로 옆에 놓이게 됩니다. 그 상태에서 CI(지속적 통합)에 규칙을 하나 추가합니다. 리포트용 모델을 건드렸음에도 skill 파일을 하나도 수정하지 않은 PR은 리뷰 단계에서 반려한다. skill 마크다운을 수정하지 않는 한, 모델 변경은 애초에 merge(병합)할 수 없습니다.

※ skill 템플릿이 원문의 부록에 공개되어 있습니다.

계층 4 검증: 측정하지 않으면 고칠 수 없다 (모호성·신선도·검색 실패)

4단계인 validation(검증)은 "어떤 실패 모드가 아직 누락되었는가"를 탐지하는 메커니즘으로, 3단계 구조를 갖추고 있습니다.

offline eval (오프라인 평가)—질문과 정답의 쌍을 수십 개 보유하고, 시스템이 변경될 때마다 이를 통과시킵니다. 핵심은 정답을 "움직이지 않는 표적"으로 만드는 것입니다. 질문에 날짜를 못 박아두고, "2026년 5월의 active는? → 5,000"과 같이 Q&A 자체를 동결합니다. 이를 "지난달의 active는?"와 같은 상대적인 질문으로 만들면, 달이 바뀔 때마다 정답도 움직이게 되어 저장해 둔 5,000이 더 이상 정답이 아니게 됩니다. 이 경우 eval(평가) 결과가 떨어져도 "시스템이 퇴보한 것인지, 아니면 단순히 달이 바뀌었을 뿐인지" 구분할 수 없습니다. 날짜로 고정해 두면, 점수가 떨어졌을 때 곧바로 "시스템 측의 퇴보"라고 명확히 해석할 수 있습니다. offline에서의 정답률은 100%를 목표로 하지만, 이는 "틀리지 않았다는 증명"이 아니라 "명백한 허점이 없음을 확인"하는 과정입니다.

ablation (절제 실험)——eval (평가) 세트를 고정한 채, 구성 요소를 하나씩만 빼거나 넣어 전후 점수를 비교합니다. 요컨대, 변수를 하나로 좁힌 A/B 테스트입니다.

예를 들어 "적대적 리뷰(Adversarial Review, 바로 아래에서 설명)는 비용이 많이 드는 공정인데, 그만큼의 가치가 있는가?"라는 질문이 있다면, 리뷰 이외의 모든 요소는 그대로 둔 채 리뷰가 있을 때와 없을 때를 각각 한 번씩 eval 하여 돌려봅니다. 점수가 올라가면 채택하고, 변함이 없다면 제외합니다. 다른 요소를 전혀 건드리지 않았기 때문에, 그 차이는 온전히 리뷰의 효과로 귀결될 수 있습니다. 회의에서 길게 토론하는 것보다, 단 한 번의 실측으로 결판을 냅니다. 다음 절에서 다룰 "효과가 없었던 것" 또한 이 기법이 찾아낸 성과입니다.

online eval (온라인 평가)——실제 운영 환경에서의 3가지 세트입니다.

적대적 리뷰 (Adversarial Review): 최종 답변을 다른 agent (에이전트)가 "정말로 그 테이블이 맞아? 그 기간이 정확해?"라며 전제부터 공격합니다. 정밀도는 6% 향상되지만, 대신 토큰(Token) 사용량은 32% 증가하고 레이턴시(Latency)는 72% 증가합니다. -
provenance footer (출처 푸터): 모든 답변의 끝에 출처와 최신성을 붙입니다. 예: "Source: semantic layer / Freshness: 5-01 / Owner: finance". 답변 자체가 정확해지지는 않지만, 받는 사람이 "얼마나 믿어도 되는지"를 판단할 수 있게 됩니다. -
correction harvesting (수정 사항 수집): stakeholder (이해관계자)의 정정("그건 다른 테이블이야")을 정기 agent가 포착하여, 참조 문서에 대한 1행 수정 PR (Pull Request)을 자동으로 생성합니다. 동일한 정정 사항은 offline eval (오프라인 평가)에도 반영합니다.

수정된 참조 문서는 다음에 동일한 질문이 들어왔을 때 agent가 읽게 됩니다. 따라서 같은 실수를 반복하지 않습니다. 정정이 일회성으로 끝나지 않고 시스템에 남아 다음 답변을 개선합니다.

그들이 "효과가 없었다"라고 단언한 것들

특히 두 번째 행은 시사하는 바가 크다고 느낍니다. 과거의 SQL 자산은 직관적으로 보물창고여야 합니다. 하지만 agent에게 전부 읽게 해도 정밀도는 거의 움직이지 않았습니다. 정보는 그곳에 있고, agent는 읽고 있었음에도 불구하고 사용할 수 없었습니다.

더 자세한 내용은 생략하지만, 관심 있는 분은 원문을 참조해 주시기 바랍니다.

미해결된 구멍: silent failure (침묵의 실패)

답이 틀렸음에도 불구하고 그럴듯해 보여서, 아무도 이의를 제기하지 않고 그대로 사용되는 실패를 말합니다. 지금까지의 탐지망(eval, 모니터링, 수정 수집)은 결국 모두 "누군가가 알아차리는 것"에 의존하고 있습니다. 아무도 알아차리지 못하는 실수는 빠져나갑니다.

완화책은 있습니다. provenance footer로 출처를 표시하고, 경영진용 숫자에는 인간의 sign-off (승인)를 필수화하며, 주요 KPI는 공식 대시보드와 매일 대조하는 것입니다. 그럼에도 원문은 솔직하게 적고 있습니다 — "we don't have a robust solution yet (아직 강력한 해결책을 가지고 있지 않다)".

서두에서도 언급했듯이, 틀린 숫자는 맞는 숫자와 똑같은 얼굴을 하고 있으며, 게다가 받는 쪽에서는 그 정확성 자체를 검증할 수 없습니다. 이것이 이 문제의 출발점이었습니다. 그렇기에 **최후의 보루는 "검증"이 아니라 "회의"**입니다. footer의 "실제 테이블 유래 · 최신성 불명"이라는 표시는, 검증할 수 없는 독자에게도 "이 숫자는 상부에 전달하기 전에 의심해야 한다"라고 판단하게 만들기 위한 것입니다.

어디서부터 시작할 것인가

원문의 마무리는 다음과 같습니다. "소수의 canonical datasets (표준 데이터셋), 수십 개의 offline evals (오프라인 평가), 그리고 한 가지의 knowledge skill (지식 기술). 이것만으로도 이점의 대부분을 얻을 수 있다. 이 글의 나머지 내용은 모두 그것들을 만든 후에 추가한 것들이다"라고 말입니다.

고전하고 있는 입장에서 말하자면, 첫 번째 단계는 이 세 가지입니다.

eval (평가): 자신이 자주 받는 질문 20~30개를 질문과 정답 쌍으로 만들어 고정한다. 정답은 특정 날짜의 스냅샷으로 pin (고정)한다.

canonical (표준화): 가장 많이 질문되는 지표의 정의를 한 곳에 작성하고, 혼란을 주는 중복 테이블 및 중복 정의를 제거한다 (최소한 "사용 금지"라고 명시한다).

skill (기술): 담당 도메인의 참조 문서와 라우터 (router)를 작성한다.

그리고 "전부 다 하지는 마라"는 원문의 결론 중 일부입니다. 무엇을 어디까지 만들지는 상황에 따라 다르며, 시작하기 전에 고려해야 할 5가지 질문이 있습니다.

• 올바른 정답이 "지금" 얼마나 중요한가 —— 모델의 진화로 인해 무의미해질 인프라를 구축하고 있지는 않은가
• 비즈니스의 복잡성은 앞으로 어떻게 변할 것인가
• 출력의 독자는 얼마나 기술적인가 —— 오류를 스스로 알아차릴 수 있는 독자인가
• 정밀도 향상에 얼마를 지불할 수 있는가 —— 적대적 리뷰(adversarial review)의 "+6% 정밀도 / +32% 토큰 / +72% 레이턴시 (latency)"가 그 실례이다
• 액세스 제어와 사내 데이터 프라이버시의 허용도는 어떠한가 —— 에이전트 (agent)를 하나를 만들 것인가, 범위를 나누어 여러 개를 만들 것인가

요약

• 정밀도가 나오지 않는 정체는 "코드 생성 능력"도 모델의 지능도 아닌, 질문을 올바른 데이터에 연결하는 "문맥 (context)"의 문제였습니다. 분석은 코드와 달리 틀려도 시스템이 다운되지 않으며, 잘못된 숫자가 올바른 숫자와 똑같은 모습으로 반환됩니다. 게다가 숫자의 정확성을 검산할 수 없다 —— 그렇기 때문에 프롬프트 (prompt)로 SQL을 가르쳐줘도 고쳐지지 않는 것입니다.
• 그 문맥이 망가지는 방식이 세 가지 **실패 모드 (failure modes)**입니다 —— 모호성 (ambiguity) (영업과 마케팅에서 "활성"의 의미가 다름) · 신선도 (freshness) (문서가 몇 주 만에 거짓이 됨) · 검색 실패 (retrieval failure) (답은 존재하지만 도달하지 못함). 우선 자신의 환경이 어떤 실패 모드에서 막혀 있는지 진단해야 합니다.
• Anthropic은 이 세 가지 모드를 4개 층의 스택 (4-layer stack) (데이터 기반 · 정보원 · skills · 검증)으로 해결하여 정밀도를 약 95%까지 끌어올렸습니다. 각 층이 담당 모드를 타격하며, **검증 층만이 세 가지 모드 전부를 "탐지 (detection)"**합니다 (방지하는 것이 아니라). skill은 21%에서 95%로 향상되는 반면, 방치하면 한 달 만에 65%까지 부패합니다 —— 따라서 최소 세트 (canonical 소수 + offline evals 수십 개 + 얇은 knowledge skill)부터 시작하여, 유지를 시스템화해야 합니다. 그럼에도 silent failure (조용한 실패)는 그들에게도 여전히 미해결 과제로 남아 있습니다.

Discussion