전사 데이터의 ‘기반’과 서비스 데이터의 ‘제품화’ 사이에서 요즘 생각이 많습니다.
회사에서 “데이터”라는 단어는 자주 하나로 뭉개집니다.
전사 데이터도 데이터고, 서비스 로그도 데이터고, 추천 점수도 데이터입니다.
하지만 같은 단어를 쓰는 순간, 책임이 흐려집니다.
어느 날은 데이터 조직이 “전사 데이터 표준”을 이야기하고, 또 어느 날은 서비스 조직이 “내일 아침까지 실험 결과”를 이야기합니다. 둘 다 데이터지만, 결은 완전히 다릅니다.
요즘 데이터가 어려워진 이유는 기술이 복잡해져서만이 아닙니다.
데이터가 ‘업무 지원물’에서 ‘서비스 재료’로 바뀌고 있기 때문입니다.
데이터의 시대가 바뀌고 있음 -> 보고서가 아니라 기능
예전의 데이터는 주로 이렇게 쓰였습니다.
- “지난달 매출 리포트 뽑아 주세요.”
- "실적 비교해 주세요.”
데이터는 설명에 가까웠습니다.
그런데 지금의 서비스는 데이터로 결정합니다.
- 추천 품질이 곧 매출이고
- 개인화가 곧 리텐션이며
- 실험 결과가 곧 제품 방향입니다.
즉, 데이터는 더 이상 뒤에서 돕는 자료가 아니라, 서비스 한가운데서 기능을 구성하는 재료가 됩니다.
이 변화는 자연스럽게 한 가지 질문으로 이어집니다.
“그럼 데이터는 누구의 일인가?”
데이터 영역은 ‘도구’가 아니라 ‘책임’으로 나뉜다.
데이터를 Redshift냐 Snowflake냐, Databricks냐로 나누기 시작하면 논의가 쉽게 흐려집니다.
더 정확한 구분 기준은 하나입니다.
누가 이 데이터를 끝까지 책임지는가?
데이터는 크게 3개의 영역으로 나눌 수 있습니다.
전사 기반 데이터: “같게 만드는 데이터”
회사 전체가 공유해야 하는 데이터입니다.
- 고객/회원, 상품 데이터와 같은 마스터
- 주문/결제/정산 같은 거래 핵심
- 권한, 개인정보 처리, 감사 로그
- “매출” “고객수” 같은 공통 지표 정의
이 영역에서 중요한 건 속도가 아니라 신뢰입니다.
여기서 정의가 흔들리면, 모든 팀의 숫자가 흔들립니다.
그래서 전사 기반 데이터는 보통 데이터 조직이 중심이 됩니다.
이건 권한이 아니라 책임의 문제입니다.
한 번 만들어 놓고 “계속 믿고 쓰게” 만드는 일입니다.
서비스 도메인 데이터: “빨리 배우는 데이터”
서비스가 실제로 살아 움직이는 현장에서 생성되는 데이터입니다.
- 앱/웹 이벤트 로그(노출, 클릭, 검색, 구매 흐름)
- 퍼널/리텐션 같은 서비스 지표 정의
- 실험(A/B) 설계와 결과 데이터
- 운영 지표(품질, 오류, SLA 등)
이 영역은 서비스 조직이 더 잘 압니다.
그리고 이 영역에서 중요한 건 “완벽한 표준”보다 학습 속도입니다.
서비스는 질문을 바꿉니다.
어제의 KPI가 오늘은 의미 없을 수 있습니다.
그래서 도메인 데이터는 보통 서비스 조직이 주도하는 편이 맞습니다.
제품화 데이터: “기능으로 작동하는 데이터”
여기부터 데이터는 보고서가 아니라 기능이 됩니다.
- 추천 결과 테이블
- 개인화 세그먼트/점수
- 예측(재고, 발주, 수요) 결과
- 이상탐지 알림/운영 자동화 룰
이건 “분석 결과”가 아니라 서비스의 일부입니다.
따라서 책임도 서비스에 붙습니다.
서비스 조직이 소유하고, 서비스 조직이 운영해야 합니다.
다만 전제는 분명해야 합니다.
서비스 조직이 마음대로 하라는 뜻이 아니라, 전사 기반(표준/보안/정의) 위에서 빠르게 움직이자는 뜻입니다.
역할 분담은 ‘업무’가 아니라 ‘문장’으로 정해야 한다
현장에서 갈등이 생기는 이유는 단순합니다.
“누가 뭘 하는지”가 사람의 머릿속에만 있기 때문입니다.
그래서 역할은 문장으로 정리되어야 합니다.
데이터 조직의 문장
- 신뢰 가능한 전사 기반을 만들고, 안전하게 유통한다.
- 정의를 통일하고(표준), 권한을 지키고(보안), 품질을 관리한다(정합성).
서비스 조직의 문장
- 전사 기반 위에서 서비스 지표를 설계하고, 기능으로 제품화한다.
- 실험하고, 반영하고, 롤백하며 학습 속도를 만든다.
같이 책임지는 문장
- 데이터 계약(Data Contract)을 만든다. (컬럼 의미, 변경 규칙, 승인 절차, SLA(지연/정확도))
- 공식 경로(공식 테이블/뷰)를 합의한다. (“각자 계산한 매출”이 여러 개가 되지 않게)
위 문장이 합의되면, 플랫폼은 선택이 쉬워집니다.
문장이 없으면, 어떤 플랫폼을 써도 상호간 혼선이 발생합니다.
“현업이 LLM으로 직접 데이터를 뽑는다”는 방향이 맞다. 단, 위치가 중요하다.
미래 그림은 꽤 선명합니다.
현업이 “뽑아 주세요”라고 말하는 대신, LLM에게 질문하고 스스로 차트와 인사이트를 얻는 방식입니다.
하지만 여기에도 원칙이 있습니다.
LLM은 ‘진실’을 만들면 안 된다.
이미 합의된 ‘진실’을 쉽게 꺼내는 손이어야 한다.
즉, LLM은 원천(raw) 데이터에 바로 붙는 게 아니라, 공식 데이터(정제된 표준 뷰/마트) 위에 붙는 편이 안전합니다.
- 전사 기반에서 ‘공식 고객/공식 매출/공식 채널’을 만들고
- 서비스 도메인에서 ‘공식 이벤트/공식 퍼널/공식 실험 결과’를 만든 뒤
- LLM은 그 위에서 질문을 SQL/쿼리로 번역하고
- 결과를 차트/요약으로 정리해 주는 역할
이 순서가 뒤집히면, LLM은 빠르게 답하지만 회사 전체가 서로 다른 답을 갖게 됩니다.
그건 생산성이 아니라 혼란입니다.
한 장면으로 이해하기: 같은 질문, 다른 책임
질문이 들어옵니다.
“최근 8주 동안, 비 오는 날에 프로모션 효과가 떨어진 상품 Top 20 알려줘.”
이때 역할은 이렇게 갈립니다.
데이터 조직
- 공식 매출/상품/날씨를 안전하게 조인할 수 있는 기반 제공
- 프로모션, 기간, 기준 같은 전사 정의와 표준 연결
서비스 조직
- ‘프로모션 효과’의 제품 정의(uplift 기준, 비교군) 확정
- 결과를 행동으로 연결(점포 운영/타겟팅/정책 변경)
LLM
- 공식 데이터 경로를 따라 질의를 만들고
- 결과를 차트+요약으로 정리해
- 현업이 “결정”할 수 있게 돕는다
결국 중요한 건 “누가 뽑느냐”가 아니라, 누가 끝까지 책임지느냐입니다.
결론: 데이터 조직은 ‘공장’, 서비스 조직은 ‘셰프’가 된다.
데이터 조직이 모든 데이터를 다 할 수 없습니다.
그건 능력의 문제가 아니라 구조의 문제입니다.
전사 기반 데이터는 공장처럼 “같은 품질로, 같은 기준으로” 만들어져야 합니다.
그리고 서비스는 셰프처럼, 그 재료로 메뉴를 만들고, 맛을 보고, 레시피를 바꿔야 합니다.
- 데이터 조직: 신뢰/표준/보안 기반
- 서비스 조직: 도메인 소유/제품화/학습속도
- 연결 장치: 데이터 계약/공식 지표/책임의 문장
이 구조가 잡히면, “데이터 조합 → 차트 → 인사이트”는 특별한 프로젝트가 아니라 매일의 작업이 됩니다.
그리고 그 일상의 속도를 끌어올리는 도구로 LLM이 들어옵니다.
데이터는 더 이상 한 조직의 일이 아닙니다.
데이터는 이제 서비스를 만드는 방식입니다.
