Governed Self-Service Analytics: Brilliant Earth가 숫자는 코드로 계산하고 문장만 LLM에 맡긴 사내 분석
주얼리 기업 Brilliant Earth가 Snowflake 안에서 Posit을 돌려 권한은 Snowflake에 맡기고, 마케팅 믹스 모델을 시나리오 앱으로, 매장 대시보드를 자연어 질의로 바꿨습니다. 주간 보고는 코드가 지표를 계산·검증한 뒤 LLM이 문장만 쓰게 했습니다. 벤더 블로그 사례에 지표 페이로드 설계와 6주 실행안을 붙였습니다.
LLM에 데이터를 통째로 주고 보고서를 쓰게 하지 말고, 숫자는 코드가 계산해 검증한 뒤 LLM에는 문장만 맡기면 경영 보고에 AI를 믿고 쓸 수 있습니다. 그러려면 먼저 권한과 지표 정의가 한곳(데이터 플랫폼)에 모여 있어야 하고, 분석팀은 보고서 공급자에서 현업이 직접 쓰는 앱을 만드는 팀으로 역할을 바꿔야 합니다.
요약
Brilliant Earth는 온라인 매출 비중이 크고 미국 전역에 쇼룸을 늘려 가는 고급 주얼리·약혼반지 회사입니다. 다이아몬드 재고 가격을 매일 다시 매기는 모델을 Snowflake 안에서 돌리려고 Snowflake를 들였고, 그 성공으로 다른 분석에 대한 기대도 커졌습니다. 그런데 데이터 사이언스팀의 모델과 분석은 주로 팀 안에서만 쓰였고, 경영진은 주간 보고서와 PDF·슬라이드 같은 정적 요약만 받았습니다. 2026년 10월 22일 Snowflake 블로그에 실린 이 글(Snowflake·Posit·Brilliant Earth 공동 저자, 벤더 블로그)은 이 회사가 Posit Team(RStudio·Shiny·Quarto를 만든 Posit의 기업용 분석 앱 게시 플랫폼)을 Snowflake 안에 설치해, 같은 데이터와 같은 권한 위에서 현업이 직접 쓰는 도구를 만든 과정을 소개합니다.
바뀐 것은 다섯 가지입니다. 권한 신청과 계정 생성이 자동화됐고, 성장팀은 코드 없이 마케팅 예산 시나리오를 돌리며, 쇼룸 운영 인력 100명 이상이 레거시 BI에서 자연어로 묻는 대시보드로 옮겨 라이선스 비용을 줄였습니다(절감액은 원문에서 밝히지 않음). 주간 보고는 코드가 계산한 숫자 위에 LLM이 문장을 쓰는 방식으로 바뀌었고, 현업 전문가는 Claude와 에이전트로 시제품을 만듭니다. 분석 총괄 Matthias Mueller가 내세우는 이유는 하나입니다. 권한·지표·계산을 데이터 곁에 묶어 두면, 쓰는 사람이 늘어도 숫자가 흩어지지 않는다는 것입니다. 아래에서 그 구조를 다섯 메커니즘으로 풀고, 우리 회사에 옮길 때 필요한 설계와 일정을 덧붙입니다.
핵심 메커니즘
Native App on SPCS: 분석 앱을 데이터 플랫폼 안에서 돌리고 권한을 물려받기
Posit Team을 별도 서버가 아니라 Snowflake Native App(Snowflake 계정 안에 설치되는 앱)으로 깔고, Snowpark Container Services(SPCS, Snowflake 안에서 컨테이너를 돌리는 서비스) 위에서 실행합니다. 입력은 직원의 접근 신청입니다. IT 티켓 시스템의 타일을 누르면 해당 직원의 관리자와 분석팀이 승인하고, 시스템이 그 사람을 맞는 SSO 그룹에 넣습니다. 그 순간 Snowflake 역할과 Posit Connect(분석 앱 게시 서버) 계정 설정이 자동으로 만들어집니다. Posit Connect는 권한 구조를 Snowflake에서 그대로 가져오므로, 누가 어떤 테이블을 볼 수 있는지는 여전히 Snowflake가 정합니다.
Mueller는 전 직장들에서 Posit을 독립 서버로 운영했습니다. 그때는 서버마다 보안 규칙과 유지보수가 따로 필요했습니다. 이 방식은 데이터 플랫폼이 이미 있고 권한 체계가 정리된 회사에 맞습니다. 권한이 여러 BI 도구에 흩어져 있는 회사라면 이 구조부터 정리해야 뒤의 단계가 의미를 갖습니다.
Model as an App: 데이터 사이언스 모델을 현업이 만지는 시나리오 앱으로
성장팀은 회사 고유의 Bayesian MMM(베이지안 마케팅 믹스 모델, 채널별 지출이 매출에 미친 효과를 추정하는 모델)을 예전에는 요약 통계와 슬라이드로만 받았습니다. 데이터 사이언스팀은 이 모델을 Streamlit(파이썬으로 웹 앱을 만드는 도구) 앱으로 감싸 Posit Connect에 올렸습니다. 성장팀은 채널별 반응 곡선을 보고, 예산을 정하고, 채널 포화 지점 같은 제약을 걸어 매출과 ROI를 예측하는 시나리오를 직접 돌립니다. 코드는 쓰지 않습니다.
핵심은 모델을 다시 만드는 것이 아니라 질문하는 주체를 바꾸는 것입니다. 가상 예시로, 전에는 『TV 예산을 20% 줄이면?』 같은 질문이 분석팀 대기열에 들어갔다면, 이제는 성장팀이 앱에서 바로 답을 봅니다. 원문은 효과를 크다고만 표현하고 수치는 밝히지 않았습니다.
querychat: 필터 대신 말로 묻는 통제된 대시보드
쇼룸 운영 인력 100명 이상은 매장별 실적을 보던 레거시 BI(제품명은 원문에서 밝히지 않음)에서 Posit 대시보드로 옮겼습니다. 대시보드에는 querychat(Posit이 R·파이썬용으로 내놓은 오픈소스 도구, SQL과 LLM으로 표 데이터를 자연어로 탐색)이 붙어 있습니다. 매니저는 복잡한 필터를 고르는 대신 『우리 쇼룸의 최근 14일 예약 실적』처럼 문장으로 묻고, 맞춤 화면을 받습니다. 원문은 이를 통제된 대화형 인터페이스로 부릅니다.
여기서 바뀐 것은 화면의 입구입니다. 데이터와 권한은 그대로 Snowflake에 있고, 자연어는 이미 허락된 데이터 안에서 보기를 바꾸는 수단으로만 쓰입니다. 변화를 꺼리는 현장 사용자를 옮기는 데 이 입구가 도움이 됐다는 것이 저자들의 설명입니다.
Compute, Validate, then Narrate: 계산은 코드, 문장은 LLM
이 글의 가장 실용적인 대목입니다. 수작업 주간 보고를 대체하면서, 파이썬·R 코드가 Snowflake 데이터로 지표를 먼저 계산합니다. 숫자가 검증된 뒤에만 LLM API로 넘기고, LLM은 추세를 요약해 문장으로 씁니다. 계산은 끝까지 코드의 몫입니다. Mueller는 LLM을 산문 요약에 쓰고, 그 일은 아주 잘한다고 말합니다. 어떤 LLM을 쓰는지, 검증을 어떻게 하는지는 원문에서 밝히지 않았습니다.
이 구조가 맞는 곳은 숫자가 틀리면 신뢰가 무너지는 정기 보고입니다. 반대로 “왜 매출이 떨어졌는지 가설을 세워 달라”처럼 탐색이 목적인 일에는 이 틀이 좁습니다. 가상 예시로, 월요일 오전 7시에 매출·예약·객단가 표를 코드가 계산하고, 전주 대비 증감과 검증 결과를 붙여 LLM에 넘기면, LLM은 5문장 요약만 씁니다.
Disposable Analytics: 버려도 되는 시제품과 정식 앱으로 올리는 길
머천다이저 같은 현업 전문가는 Claude 같은 프런티어 모델과, 통제된 semantic layer(지표 정의를 한곳에 모은 의미 계층) 위에 만든 Snowflake CoWork 에이전트로 직접 시제품을 만듭니다. 예를 들어 캐럿 중량과 sell-through(입고 대비 판매 비율)를 묶은 맞춤 보고서입니다. 시제품이 여러 사람에게 쓸모 있다고 확인되면, 분석팀이 검증된 데이터 위에서 다시 만들어 Posit Connect에 정식 앱으로 올립니다.
Mueller는 Shiny 대시보드를 만들어 Snowflake에 붙이고 Posit에 올리는 일이 이제 매우 빨라졌다고 말합니다. 그래서 몇 시간씩 들이지 않고 한 번 쓰고 버릴 도구를 만들 수 있습니다. 시제품은 현업이, 운영용은 분석팀이 맡는다는 분업이 이 메커니즘의 요점입니다.
통념과 다른 주장
흔히 이렇게 봅니다데이터 민주화는 현업마다 대시보드를 더 많이 만들어 주는 일이다.
저자는 이렇게 봅니다대시보드 수를 늘리는 것이 목표가 아닙니다. 현업이 무엇을 결정하려는지 배워 함께 맞춤 도구를 만들고, 기존 화면을 복제하기보다 새로 설계해야 합니다.
근거Mueller는 계속 늘어나는 대시보드를 다시 만들고 싶지 않다며, 2년 뒤에도 쓰고 싶은 것을 만들겠다고 말합니다. 다음 대상인 머천다이징·디지털·재무팀도 이 원칙으로 옮길 계획입니다.
흔히 이렇게 봅니다LLM에 데이터와 질문을 주면 분석과 보고서 작성을 한 번에 맡길 수 있다.
저자는 이렇게 봅니다계산은 코드가 하고, 검증을 통과한 숫자만 LLM에 넘겨 문장을 쓰게 해야 보고서를 믿을 수 있습니다.
근거Brilliant Earth는 주간 보고를 이 순서로 바꿨고, Snowflake의 리테일 담당 Sem Sergunin은 준비되지 않은 데이터 위의 에이전트가 "scale your mess"(혼란을 키울 뿐)라고 경고합니다.
저자가 든 사례
글의 사례는 모두 Brilliant Earth 한 회사의 것입니다. 메커니즘 순서로 다시 짰습니다.
| 사례 | 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|---|
| 접근 권한 | 독립 서버는 보안·유지보수가 따로 필요 | Posit을 Native App으로 설치, 티켓 → 2단 승인 → SSO 그룹 → 역할 자동 생성 | 권한 부여 완전 자동화(소요 시간은 원문에서 밝히지 않음) | Native App on SPCS |
| 성장팀 MMM | 모델 결과를 요약·슬라이드로만 받음 | Streamlit 시나리오 앱으로 공개 | 코드 없이 예산·제약·ROI 시나리오(효과 수치는 밝히지 않음) | Model as an App |
| 쇼룸 운영 | 100명 이상이 레거시 BI 사용 | Posit 대시보드 + querychat으로 이관 | 레거시 라이선스 정리로 비용 절감(금액은 밝히지 않음) | querychat |
| 주간 보고 | 수작업 주간 보고 | 코드 계산 → 검증 → LLM 문장 | 수작업 보고 대체 | Compute, Validate, then Narrate |
| 머천다이저 시제품 | 맞춤 보고가 분석팀 대기열에 묶임 | Claude·CoWork 에이전트로 직접 시제품 | 쓸모가 확인되면 분석팀이 정식 앱으로 재구축 | Disposable Analytics |
기술 디테일: 우리 데이터 플랫폼에서 이 구조를 돌리려면
아래는 글의 구조를 우리 회사 데이터 플랫폼(Snowflake든 다른 웨어하우스든)에 옮길 때 필요한 설계로, AX Review가 새로 작성했습니다. 필드 이름과 숫자는 가상 예시입니다.
Compute, Validate, then Narrate를 돌리려면 LLM에 넘기는 입력을 표가 아니라 지표 페이로드(JSON)로 고정합니다. 지표마다 이름, 값, 단위, 비교 기준, 계산 SQL의 버전, 검증 결과를 담고, 검증에 실패한 지표는 아예 넣지 않습니다. LLM에는 『페이로드에 있는 숫자만 쓰고 새로 계산하지 말 것, 지표 이름은 label 그대로』를 지시하고, 구조화 출력으로 headline(1문장), bullets(35개), 0.2로 둡니다.cited_metrics(문장마다 근거 metric_id 목록)를 받습니다. temperature는 0
{
"report_id": "weekly_showroom_2026-W43",
"as_of": "2026-10-25",
"metrics": [
{ "metric_id": "bookings_14d", "label": "최근 14일 예약", "value": 1284, "unit": "건",
"prev": 1190, "delta_pct": 7.9, "sql_version": "v12",
"checks": { "row_count_ok": true, "fresh_hours": 6, "reconciled_with_finance": true } },
{ "metric_id": "aov", "label": "객단가", "value": 4120, "unit": "USD",
"prev": 4310, "delta_pct": -4.4, "sql_version": "v7",
"checks": { "row_count_ok": true, "fresh_hours": 6, "reconciled_with_finance": true } }
],
"excluded": [ { "metric_id": "returns_rate", "reason": "fresh_hours > 24" } ]
}검증 단계는 네 가지 검사로 시작합니다. 행 수가 지난 4주 평균의 ±30% 안인지, 데이터가 24시간 안에 갱신됐는지, 재무 마감 숫자와 1% 안에서 맞는지, 증감률이 ±50%를 넘으면 사람 확인으로 돌리는지입니다. 숫자가 맞는지는 코드가 판정하고, LLM은 판정하지 않습니다.
LLM 문장을 사후 검사하려면 생성된 문장에서 숫자를 정규식으로 모두 뽑아 페이로드의 value·prev·delta_pct와 대조합니다. 페이로드에 없는 숫자가 하나라도 있으면 그 문장을 버리고 한 번 다시 생성하며, 두 번째도 실패하면 숫자 표만 보냅니다. 같은 페이로드로 3회 생성해 cited_metrics가 달라지면 프롬프트의 지시가 모호하다는 신호입니다.
querychat 같은 자연어 질의를 붙이려면 권한은 앱이 아니라 데이터 쪽에서 막습니다. 쇼룸 매니저 역할에는 읽기 전용 권한과 행 수준 정책(자기 쇼룸 행만 보이게)을 걸고, 자연어에서 만들어진 SQL은 그 역할로만 실행합니다. 화면에는 생성된 SQL이나 적용된 조건을 함께 보여 줘 사용자가 무엇을 보고 있는지 확인하게 합니다. 시범 기간에는 질문·SQL·결과 행 수를 로그로 남겨, 답이 0행인 질문과 다시 묻는 질문을 주간 단위로 모아 대시보드 설계를 고칩니다.
MMM 시나리오 앱을 만들려면 앱이 모델을 매번 다시 학습하지 않게 합니다. 사후분포 표본과 채널별 반응 곡선을 미리 계산해 테이블로 두고, 앱은 예산 입력(채널별 금액), 제약(채널별 최소·최대, 포화 지점), 기간을 받아 매출·ROI의 중앙값과 80% 구간을 돌려줍니다. 구간을 함께 보여 줘야 성장팀이 숫자 하나를 확정값으로 읽지 않습니다.
시제품을 정식 앱으로 올리려면 졸업 기준을 미리 정합니다. 가상 예시로, 2주 동안 3명 이상이 5회 이상 썼고, 쓰는 지표가 모두 semantic layer에 정의돼 있으면 분석팀이 다시 만듭니다. 다시 만들 때는 시제품의 쿼리를 그대로 옮기지 않고, 지표를 정의된 이름으로 바꾸고 위의 검증 검사를 붙입니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 6주 동안 하는 일 |
|---|---|---|
| 스폰서 | 영업·운영 총괄 임원 | 대상 보고서 1개와 대상 팀 승인, 종료 판정 |
| 분석 리드 | 데이터 분석·사이언스 팀장 | 지표 정의, 검증 규칙, 앱 구조 결정 |
| 데이터 엔지니어 | 1명 | 권한 역할·행 수준 정책, 지표 계산 파이프라인 |
| IT·보안 | 1명 | SSO 그룹, 접근 신청 승인 흐름, 로그 보관 |
| 현업 대표 | 보고서를 받는 팀장 1명 + 실사용자 5~10명 | 질문 목록 제공, 시범 사용, 피드백 |
| 재무 | 1명 | 재무 마감 숫자와 대조 기준 제공 |
시작 전 준비물: 지금 매주 손으로 만드는 보고서 1개와 최근 8주치 사본, 그 보고서의 지표 목록과 계산식, 현재 BI 도구별 권한 목록과 라이선스 비용, 현업이 자주 묻는 질문 20개입니다.
| 주차 | 할 일 | 산출물 |
|---|---|---|
| 1주 | 대상 보고서 선정, 지표 정의서 작성, 권한 현황 정리 | 지표 정의서, 권한 매핑표 |
| 2주 | 지표 계산 코드와 검증 검사 4종 구현 | 지표 페이로드(JSON), 검증 리포트 |
| 3주 | LLM 요약 생성과 숫자 사후 검사 연결 | 자동 보고서 초안 4주치(과거 데이터로 재현) |
| 4주 | 실제 주간 보고 병행 발행(수작업본과 나란히) | 비교표: 숫자 일치율, 작성 시간 |
| 5주 | 자연어 질의 대시보드 시범(실사용자 5~10명) | 질문 로그, 0행 질문 목록 |
| 6주 | 판정 회의, 확대 대상 결정 | 판정 보고서, 레거시 라이선스 정리안 |
현업 인터뷰 질문: 이 보고서를 받고 실제로 바꾼 결정은 지난 분기에 무엇이었습니까? 보고서를 받은 뒤 분석팀에 다시 묻는 질문은 주로 무엇입니까? 숫자가 틀렸을 때 누가 어떻게 알아챘습니까? 필터를 고르다 포기한 화면이 있습니까?
진행 판정 기준(예시): 병행 발행 2주 동안 자동 보고서의 숫자가 수작업본과 100% 일치하고, 페이로드에 없는 숫자가 문장에 한 번도 나오지 않으며, 보고서 작성 시간이 수작업 대비 80% 이상 줄면 확대합니다. 숫자 불일치가 한 번이라도 원인 불명으로 남으면 지표 정의부터 다시 봅니다. 자연어 질의는 실사용자의 절반 이상이 2주 안에 3회 이상 다시 찾으면 레거시 화면을 끄는 일정을 잡습니다.
AX 적용 제언. 이 사례를 옮길 첫 자리는 경영회의 주간 보고입니다. 숫자가 이미 웨어하우스에 있고, 형식이 반복되며, 틀리면 바로 드러나기 때문입니다. 순서는 권한 정리 → 지표 정의 → 계산·검증 자동화 → LLM 서술 → 자연어 질의 → 현업 시제품입니다. 앞 단계를 건너뛰고 에이전트부터 붙이면 Sergunin의 경고대로 흩어진 숫자가 더 빨리 퍼집니다. 분석팀의 성과 지표도 발행한 보고서 수에서 현업이 직접 쓴 앱과 줄어든 재질문 수로 바꾸는 편이 이 구조와 맞습니다. 리테일·소비재처럼 매장·채널이 많은 회사라면, 쇼룸 사례처럼 레거시 BI 라이선스 정리를 함께 걸어 비용 근거를 만드는 것이 스폰서를 설득하기 쉽습니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 발표처 | Snowflake 블로그(2026.10.22), 리테일·소비재 분류. 벤더 블로그 |
| 저자 | Angela Marrujo Fornaca, Matthias Mueller(Brilliant Earth 분석·데이터 사이언스 시니어 디렉터), Natallia Drobau(Posit), Sem Sergunin(Snowflake) |
| 회사 | Brilliant Earth, 고급 주얼리·약혼반지, 온라인 판매와 미국 쇼룸망 |
| 출발점 | Snowflake 안에서 다이아몬드 재고 가격을 매일 재산정 |
| 플랫폼 | Posit Team을 Snowflake Native App으로 SPCS 위에 설치, Posit Connect가 Snowflake 권한 상속 |
| 접근 권한 | IT 티켓 → 관리자·분석팀 승인 → SSO 그룹 → Snowflake 역할·Posit Connect 계정 자동 생성 |
| 성장팀 | 고유 Bayesian MMM을 Streamlit 앱으로, 반응 곡선·예산·포화 제약·매출·ROI 시나리오 |
| 쇼룸 운영 | 100명 이상, 레거시 BI → Posit 대시보드 + querychat, 라이선스 비용 절감(금액 미공개) |
| 주간 보고 | 파이썬·R로 지표 계산 → 검증 → LLM API로 서술(모델명 미공개) |
| 시제품 | Claude, Snowflake CoWork 에이전트(semantic layer 기반), 캐럿 중량·sell-through 예시, 재구축 후 Posit Connect 게시 |
| 다음 대상 | 머천다이징, 디지털, 재무팀 |
핵심 개념
- Data Democratization(데이터 민주화)
- 분석팀만 쓰던 데이터와 모델을 현업 의사결정자가 직접 쓰게 하는 일. 이 글에서는 같은 권한과 같은 데이터 위에서만 넓힌다.
- Posit Connect
- Shiny·Streamlit·Quarto 같은 파이썬·R 결과물을 사내에 게시하고 공유하는 서버.
- SSO 그룹
- 통합 로그인 시스템의 사용자 묶음. 그룹에 넣는 것만으로 여러 시스템의 권한이 따라 붙는다.
- response curve(반응 곡선)
- 채널 지출을 늘릴 때 매출이 얼마나 늘어나는지를 그린 곡선. 기울기가 평평해지는 곳이 포화 지점이다.
- Shiny
- R·파이썬으로 대화형 웹 대시보드를 만드는 Posit의 오픈소스 프레임워크.
- Snowflake CoWork
- Snowflake의 에이전트 기능. 글에서는 통제된 semantic layer 위에서 현업 시제품을 만드는 데 쓰인다.
내 메모
TODO: 내 생각 추가
원문: Angela Marrujo Fornaca, Matthias Mueller, Natallia Drobau, Sem Sergunin, “How Brilliant Earth Drives Data Democratization with Snowflake and Posit”(Snowflake 블로그, 2026.10.22). 벤더 블로그로, 효과에 관한 서술은 벤더와 고객사의 설명입니다. 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 글의 내용을 AX Review가 다시 정리했습니다. querychat 설명은 Posit의 querychat 공식 페이지를 참고했습니다. 기술 디테일·현업 실행 디테일의 필드 이름, 검증 규칙, 일정, 판정 기준과 모든 인포그래픽은 AX Review가 새로 작성한 가상 예시입니다. 전체 내용은 원문에서 볼 수 있습니다.