Slack에서 데이터를 직접 조회하다: Anthropic이 수시 질의에 Claude Tag를 활용하는 방법

이전 포스트에서 우리는 세 가지 핵심 요소를 통해 Claude가 데이터 분석 질문에 약 95%의 정확도로 답할 수 있도록 구현한 방법을 소개했습니다.

• 거버넌스가 적용된 시맨틱 레이어(semantic layer),
• 분석 관행을 담은 스킬 파일 모음, 그리고
• 성능을 측정하는 평가 스위트(evaluation suite)가 그것입니다.

해당 포스트는 데이터 과학자와 데이터 엔지니어의 주요 개발 환경인 Claude Code와 에이전트 정확도를 높이는 모범 사례를 중심으로 다뤘습니다.

이번 포스트에서는 Anthropic 데이터팀이 그 기반을 실제 업무 현장에 적용하는 방법을 소개합니다. 핵심 도구는 Claude Tag (퍼블릭 베타)로, Slack에서 작동하는 데이터 분석 에이전트의 토대입니다. 누구든 데이터 관련 질문을 던지면, 분석가들이 실제로 사용하는 공식 지표 정의를 바탕으로 한 답변을 받을 수 있습니다.

Slack에서 데이터 분석 에이전트를 배포하는 모범 사례

에이전트를 정확하게 만드는 것과 비분석가들도 쓸 수 있도록 배포하는 것은 전혀 다른 문제였습니다. 정확도에 관한 권장 사항은 이전 포스트에서 이미 다뤘고 지금도 유효하므로 여기서 반복하지 않겠습니다.

이번에는 지난 1년간 Slack에서 데이터 분석 에이전트를 운영하며 얻은 가장 중요한 다섯 가지 교훈을 소개합니다. 배포 방식, 권한 관리, 데이터 최신성, 그리고 가시성(observability)을 어떻게 고려해야 하는지 살펴보겠습니다.

Slack에서 데이터 분석 에이전트를 배포하는 모범 사례

에이전트를 정확하게 만드는 것과 비분석가들도 쓸 수 있도록 배포하는 것은 전혀 다른 문제였습니다. 정확도에 관한 권장 사항은 이전 포스트에서 이미 다뤘고 지금도 유효하므로 여기서 반복하지 않겠습니다.

이번에는 지난 1년간 Slack에서 데이터 분석 에이전트를 운영하며 얻은 가장 중요한 다섯 가지 교훈을 소개합니다. 배포 방식, 권한 관리, 데이터 최신성, 그리고 가시성을 어떻게 고려해야 하는지 살펴보겠습니다.

데이터 모델을 갱신할 때마다 스킬도 함께 갱신하세요

스킬은 자연어 지침과 참조 파일로 구성된 마크다운 파일로, 이를 통해 조직의 스타일과 요구사항에 맞게 Claude가 특정 작업을 수행하도록 가르칠 수 있습니다.

우리가 내린 가장 중요한 아키텍처 결정 하나는 스킬 파일을 한 번 배포하고 잊어버리는 대상이 아니라, 지속적으로 갱신되는 서빙 콘텐츠(served content)로 다루는 것이었습니다.

데이터 모델은 하루에도 여러 번 바뀔 수 있습니다. 컬럼 이름이 변경되거나, 지표 정의가 수정되거나, 테이블이 deprecated될 수 있죠. 이런 변경 사항은 비교적 빠른 시간 안에 스킬 파일에 반영되어야 합니다. Claude가 지난 화요일 버전의 스킬을 읽고 있다면, 지난 화요일의 틀린 답을 자신 있게 내놓을 뿐입니다.

이 문제는 데이터 소비자가 답변의 정확성을 판단하는 데 필요한 맥락과 완전히 단절되어 있기 때문에 더욱 심각합니다. 추세선이나 연관 지표를 볼 수 있는 대시보드가 눈앞에 없으니 직관적인 검증('스니프 테스트')도 어렵습니다. Slack에서 데이터 포인트 하나나 둘을 받을 뿐이고, 평소에 자주 보던 데이터가 아니라면 자신 있게 틀린 답을 그대로 받아들일 가능성이 높습니다.

이처럼 끊임없이 변하는 환경에 대응하기 위해, Claude Tag의 런타임은 데이터 저장소의 skills/ 디렉터리를 마운트하고 매 대화마다 이를 다시 읽습니다. 스킬 파일은 디스크에 저장된 마크다운 파일일 뿐이며, 에이전트는 다른 프로젝트 파일을 읽듯 동일한 방식으로 파일을 읽습니다.

쿼리 대상 이상의 스킬을 에이전트에게 부여하세요

처음에는 Claude Tag로 데이터 분석 에이전트를 배포할 때 '지식 스킬(knowledge skill)'만 만들면 충분할 것이라고 생각했습니다. 어떤 테이블을 사용해야 하는지, 시맨틱 레이어가 어떻게 구성되어 있는지를 Claude에게 가르치는 것으로 끝내려 했죠. 그러나 이 방식으로는 정확한 수치는 얻을 수 있어도, 실질적으로 유용한 인사이트에는 한참 못 미친다는 사실을 금방 깨달았습니다.

대부분의 데이터 소비자는 "이 수치가 왜 떨어졌지?", "월말에 이 지표가 어디쯤 도달할까?", "이 데이터를 퍼널로 보여줘" 같은 열린 질문이나 모호한 질문을 던지는 경향이 있습니다. 이런 질문에 답하려면 에이전트가 데이터가 어디 있는지뿐 아니라 분석가라면 그 데이터를 어떻게 다룰지까지 알아야 합니다.

그래서 지식 스킬과 함께, 다음과 같은 분석 스킬과 런북(runbook) 스킬도 Claude Tag에 추가했습니다.

• 예측(Forecasting): 단순 추세를 언제, 어떻게 피팅할지, 계절성 가정은 어떻게 할지, 그리고 데이터 계열이 너무 짧거나 노이즈가 많을 때는 언제 응답을 거부할지.
• 코호트 및 리텐션 분석: 표준 코호트 정의, 경영진에 보고하는 리텐션 곡선 템플릿, 그리고 단순 구현 시 걸리기 쉬운 함정(좌측 절단, 생존 편향 등).
• 퍼널 분석: 핵심 제품 퍼널의 표준 단계 정의. "온보딩에서 어느 지점에 이탈이 집중되나요?" 같은 질문에 일관된 답변을 제공하기 위한 기준.
• 차트(Charting): 질문 유형에 따른 차트 종류 선택, 색상 팔레트 기준, 그래프보다 테이블이 더 명확한 경우 등 시각화 관행.
• 분석 글쓰기: 분석 결과를 구조화하는 방법(TL;DR 먼저, 수치, 인과 메커니즘, 주의사항 순), 그리고 신뢰도 수준에 따른 적절한 불확실성 표현 방식.

이런 관행은 대부분의 데이터팀이 이미 갖고 있습니다. 다만 보통은 누군가의 머릿속에만 있고, 간헐적으로만 문서화될 뿐입니다. 이를 스킬로 명문화하면, Claude도 데이터 과학자만큼 일관되게 적용할 수 있습니다.

데이터 웨어하우스만이 아닌 비즈니스 맥락과도 연결하세요

지식 스킬과 런북 스킬을 조합해도 모든 질문에 답하기엔 부족할 때가 있습니다. "화요일에 가입자 수가 왜 떨어졌나요?"라는 질문의 답은 데이터 모델 안에 없는 경우가 많습니다. 그 답은 보통 Slack 스레드, 인시던트 트래커, 릴리스 노트, 문서 등 여러 곳에 흩어져 있습니다.

이런 공백을 메우기 위해, 우리는 Claude Tag를 사내 지식 인덱스에 연결했습니다. 이 인덱스는 사내 문서, 토론, 이벤트를 통합 색인화합니다. 에이전트는 지표 변동을 감지하면 인덱스를 검색해 동시기(同時期) 맥락을 찾습니다. 그날 오전에 열린 인시던트, 플리퍼(feature flag) 변경, 누군가 채널에 공유한 경쟁사 공지 같은 것들이 그 예입니다.

그 결과 "화요일에 가입자 수가 12% 감소했습니다. 오전 9시부터 11시까지 결제 서비스 인시던트가 발생했고, 감소가 해당 지역에 집중되어 있습니다."와 같은 답변이 나오게 됩니다.

조직 내에 지식 그래프, 내부 검색 시스템, 또는 잘 정리된 인시던트·변경 이력 피드가 있다면, Claude Tag와 연결하는 것이 웨어하우스 연동 다음으로 투자 대비 효과가 가장 큰 선택입니다. 주요 Slack 채널을 읽고 맥락을 파악할 수 있도록 Claude Tag를 연결하는 방법도 있습니다.

서비스 계정 권한은 신중하게 설계하세요

Claude Tag는 질문을 던진 사람이 아닌, 서비스 계정으로 웨어하우스에 쿼리합니다. 모든 Slack 사용자에게 웨어하우스 직접 접근 권한을 부여하고 싶지 않다면 올바른 설계입니다. 하지만 그 의미는, 봇을 멘션할 수 있는 모든 사람이 봇의 데이터 접근 권한을 공유하게 된다는 것입니다. 사용자별 행 수준 보안(row-level security)은 적용되지 않습니다. 서비스 계정이 읽을 수 있는 데이터는 채널의 누구든 조회할 수 있습니다.

우리는 다섯 가지 방식으로 이 문제를 다루고 있습니다. 잘못 설정하기 쉽고 한번 잘못되면 되돌리기 어려운 영역이므로, 신중하게 접근하길 권합니다.

1. 서비스 계정의 접근 범위를 거버넌스가 적용된 데이터로만 제한하세요. Anthropic에서 Claude Tag의 서비스 계정은 시맨틱 레이어의 출력 테이블과 그것을 구성하는 정제된 데이터 마트만 읽을 수 있습니다. 원시 이벤트 스트림, 스테이징 스키마, 개인 샌드박스에는 접근할 수 없습니다. 그 범위를 벗어난 데이터가 필요한 질문이 들어오면, 에이전트는 추측하는 대신 그 사실을 명확히 밝힙니다. 거버넌스가 적용되지 않은 레이어 외부 데이터는 검증되지 않은 것이므로, 이는 사용자 경험 측면에서도 올바른 접근입니다.

2. PII를 컬럼 수준에서 분류하고, 서비스 계정에 접근 권한을 부여하지 마세요. 거버넌스가 적용된 데이터라고 해서 자동으로 PII로부터 안전한 것은 아닙니다. 예를 들어, 정제된 테이블에도 이메일 주소가 포함될 수 있습니다. 우리는 컬럼 수준 계보(lineage)를 갖춘 데이터 카탈로그를 운영하며, 모든 컬럼의 출처와 다운스트림 흐름을 추적합니다. 새로운 컬럼이 추가되면 Claude가 이를 스캔해 PII 후보를 표시하고, 담당자가 검토 후 해당 컬럼의 메타데이터에 분류 레이블을 적용합니다. 계보를 통해 이 레이블이 파생 테이블에도 자동 전파됩니다. Claude Tag의 서비스 계정에는 PII 접근 권한이 없으므로, 웨어하우스의 컬럼 수준 접근 제어에 의해 PII 컬럼은 에이전트에게 보이지 않습니다. 테이블 자체는 쿼리할 수 있지만, 민감한 컬럼은 읽히지 않습니다.

3. 연결 경로를 스킬 파일에 문서화하세요. 우리의 웨어하우스 스킬에는 에이전트가 어떻게 연결하는지(CLI, 직접 API, MCP 서버 중 어느 경로를 통하는지), 그리고 각 경로별 인증 방식이 어떻게 작동하는지를 전용 섹션으로 정리해두었습니다. 이 단순해 보이는 기능 덕분에 에이전트가 "이 환경에서는 웨어하우스에 접근할 수 없습니다. 이유는 다음과 같습니다."처럼 명확하게 실패하는 것과, 쿼리가 잘못된 프로젝트에서 조용히 실행되거나 인증 프롬프트가 엉뚱한 곳으로 전달되는 것처럼 혼란스럽게 실패하는 것을 구분할 수 있습니다. 연결 방식이 스킬에 담겨 있으면 에이전트가 자신의 제약을 스스로 설명할 수 있습니다.

4. Claude의 채널 참여 자체를 접근 권한 부여로 여기세요. Claude Tag를 Slack 채널에 추가하는 것은 사실상 그 채널 구성원에게 에이전트가 쿼리할 수 있는 데이터에 대한 읽기 권한을 부여하는 것과 같습니다. 우리는 이 점을 명확히 합니다. Claude는 데이터팀 구성원이 추가하며, 채널 목록은 데이터팀이 관리합니다.

5. 모든 쿼리에 레이블을 붙이세요. 웨어하우스 쿼리마다 Claude Tag는 실행 환경, 대화 ID, 그리고 Slack이 제공하는 경우 요청자 정보를 레이블로 첨부합니다. 쿼리 실행 시점에는 어떠한 제어도 하지 않지만, 비용 귀속과 감사 추적이 가능해집니다. 4TB를 스캔한 쿼리를 누가 요청했는지 사후에 파악할 수 있습니다.

우리의 기본 입장은, Slack의 데이터 분석 에이전트는 거버넌스가 적용된 웨어하우스의 공유 읽기 전용 복제본이라는 것입니다. 그에 맞게 범위를 설정하려 합니다.

모든 답변을 계측하세요

에이전트가 충분한 답변을 제공했는지는 눈으로 봐서는 알 수 없습니다.

우리는 Claude Tag가 처리하는 모든 질문에 대해 구조화된 이벤트를 기록합니다. 포함되는 정보는 다음과 같습니다.

• 어떤 스킬 파일이 어떤 버전으로 로드되었는지,
• 사용자가 👍/👎로 반응했거나 수정 댓글을 달았는지, 그리고
• 에이전트가 조회한 테이블에 열린 데이터 품질 경고가 있는지 여부. 또한 답변의 하단에 데이터 품질 경고를 직접 표시합니다. 오래된 데이터 경보가 수치와 함께 나타나므로, 사용자가 놓치지 않을 수 있습니다.

이 텔레메트리(telemetry)는 두 가지 뷰를 통해 확인합니다. 하나는 도입률을 추적합니다. 에이전트 쿼리 중 즉흥적인 SQL이 아닌 거버넌스 레이어를 통한 비율을, 환경 및 도메인별로 측정합니다. 다른 하나는 정확도를 추적합니다. 도메인별 👎 반응률과 수정 발생률로 측정하며, 평가 실행 사이 구간의 온라인 정확도 프록시(proxy)로 활용합니다.

도입률 지표는 우리가 추적한 수치 중 실제 행동으로 가장 잘 이어지는 지표였습니다. 특정 도메인의 도입률이 떨어지면, 거의 항상 스킬 파일이 최신 상태와 어긋났거나 시맨틱 레이어가 아직 커버하지 못하는 새로운 유형의 질문이 등장했음을 의미합니다.

셀프서비스 데이터 분석 도입을 어떻게 가속화하는가

Claude Tag 스레드가 새로운 회의 공간이 됩니다

가장 효과적인 Claude Tag 스레드를 보면 대부분 여러 사람이 함께 참여하고 있습니다. 사람들은 아이디어와 맥락을 제공하고, Claude는 실질적인 작업을 처리하는 구조입니다.

예를 들어, 데이터팀 구성원이 Claude에게 매출 대시보드가 평소보다 몇 분 더 오래 로딩된다는 문제를 물었습니다. Claude는 쿼리 결과가 캐시되지 않고 있었고, 결과가 페이지에 전달되는 속도를 늦추는 버그가 있다는 사실을 발견했습니다.

Claude는 대시보드 담당자에게 이를 알렸고, 담당자는 버그는 별도로 처리하면서 캐시 문제는 즉시 수정하기로 했습니다.

담당자가 동일한 문제로 느려진 다른 대시보드가 있는지 물었고, 수십 개의 대시보드가 같은 캐싱 오류의 영향을 받고 있다는 사실이 드러났습니다. Claude가 캐싱 수정 코드를 작성하고, 데이터팀 구성원이 검토했으며, 1시간도 채 되지 않아 영향받은 모든 대시보드가 정상 작동했습니다.

이 스레드들은 공개적으로 진행됩니다. 이 점이 여러 측면에서 유용합니다. 지켜보는 사람들은 별도의 요약 없이도 무슨 일이 있었는지, 왜 그런 일이 생겼는지, 어떻게 해결됐는지를 파악할 수 있습니다. 더 중요한 것은, 단순한 구경꾼으로 남을 필요가 없다는 점입니다. 위의 예시처럼, 유용한 정보를 가진 사람이라면 누구든 언제든 끼어들어 기여할 수 있습니다.

에이전트는 DM이 아닌 공유 채널에서 활용하고, 대화는 스레드 형태로 이어가세요. 스레드는 나중에 검토할 수 있는 기록으로 남습니다.

Claude Tag가 반복 작업을 처리합니다

파이프라인 상태 점검, KPI 모니터링 등 많은 데이터 업무는 반복적으로 이루어집니다. Claude에게 루프를 만들도록 요청하면, 정기적으로 또는 비정상적인 변화에 반응하여 주기적인 작업을 자동으로 처리할 수 있습니다. 우리가 실제로 구현한 데이터 관련 예시는 다음과 같습니다.

• 정기 리포트: 주간 스탠드업 전에 Claude가 요약을 제공합니다. 지난주에 어떤 지표가 움직였는지, 전주 대비 어떤지, 주목할 만한 사항은 무엇인지를 알려줍니다.
• 테스트 모니터링: 런칭이나 실험을 모니터링할 때, Claude가 하루에 여러 차례 현황을 보고합니다. 최근 진행한 한 실험에서는 Claude가 중간에 설정이 변경된 것을 발견해 조기에 문제를 파악하고 수정하는 데 도움을 주었습니다.
• 가시성: 다른 루프는 파이프라인과 대시보드를 모니터링합니다. 파이프라인이 실패하면 Claude가 조사를 시작하고 수정안을 작성한 뒤 온콜 담당자에게 알립니다. KPI가 예상치 못하게 움직이면, 누군가 대시보드를 열기도 전에 Claude가 가능한 원인을 검토합니다. 공휴일 효과인지, 업스트림 데이터 변경인지 등을 미리 확인해둡니다.
• 트리아지(Triage): 또 다른 루프는 데이터 질문 채널을 모니터링합니다. 새 질문이 올라오면 Claude가 판단합니다. 바로 답변할 수 있는지, 더 깊은 조사가 필요한지, 사람이 개입해야 하는지를 결정합니다. 데이터팀 누군가가 채널을 확인할 때쯤이면 대부분의 작업이 이미 완료되어 있습니다.
  

루프 설계 자체도 Claude에게 맡길 수 있습니다. @Claude에게 채널에서 반복적으로 등장하는 작업이 무엇인지, 어떻게 도울 수 있는지 물어보세요.

필요한 순간에 직접 나서다

원하는 채널에서 Claude를 더 능동적으로 활동하도록 설정할 수 있습니다. 호출 없이도 대화를 읽다가 필요한 순간에 직접 개입하는 방식입니다. 지난 한 달간 우리의 한 데이터 채널에서 Claude Tag는 사람들이 올린 질문의 75% 이상에 보통 1~2분 안에 답변했으며, 대부분 멘션 없이도 스스로 답했습니다.

한 예로, Anthropic 팀원이 공개 채널에서 대시보드에 새로운 사용량 카테고리가 포함되어 있는지 물었습니다. 90초 만에 Claude는 데이터가 어떻게 정의되어 있는지 설명하고, 해당 세그먼트가 누락되어 있음을 확인하고, 수정안을 제안한 뒤, PR 초안까지 작성했습니다. 데이터 과학자가 검토하고 승인했고, Claude가 PR을 머지한 뒤 대시보드를 새로고침했습니다.

시작하기

첫 번째 포스트에서 다룬 작업을 이미 완료했다면, Slack 배포는 대부분 배관 작업에 가깝습니다. 다만 순서가 중요합니다.

1. 권한 설정이 먼저입니다. 에이전트 코드 한 줄 작성하기 전에, 서비스 계정이 읽을 수 있는 데이터 범위를 결정하세요. 접근 범위를 나중에 넓히는 것은 쉽지만, 한번 열어준 권한을 회수하기는 훨씬 어렵습니다.
2. 배포 방식은 그 다음입니다. 마운트된 저장소를 쓸지, MCP를 통한 스킬을 쓸지 결정하고, 최신성을 끝까지 검증하세요. 스킬 파일을 변경한 뒤 Claude Tag가 SLA 내에 이를 반영하는지 직접 확인하세요.
3. 텔레메트리는 첫날부터 시작하세요. 한 달 치 대화를 소급해서 계측할 수는 없습니다. 첫 번째 질문부터 구조화된 이벤트를 기록하세요.
4. 지식 인덱스는 준비되는 대로 연결하세요. 웨어하우스는 무엇을 답하고, 내부 문서와 인시던트 피드는 왜를 답합니다. 데이터 경로가 안정화되는 대로 연결하세요.
5. 분석 스킬은 마지막입니다. 먼저 데이터 접근 스킬을 만들고, 실제 질문들을 바탕으로 동료들이 어떤 분석 스킬(예측, 코호트, 퍼널)을 실제로 필요로 하는지 파악한 뒤 추가하세요.

이 글은 Anthropic 데이터 과학 및 데이터 엔지니어링팀의 Clement Peng과 Lily Zhao가 작성하고, Josh Cherry와 Michael Segner가 기여했습니다.