요약

발표자 배경 및 문제의식 (01:12-03:06)

발표자의 경력

개인정보 담당자 → 데이터 서비스 기획/운영

• 개인정보 보호와 데이터 활용의 균형 고민
• 현장에서 직접 실행하며 시행착오 경험

데이터의 역설

문제 인식

"데이터는 가치 있다고 생각했는데..."

• 시장에서 데이터 가치가 인정받지 못하는 경우 多
• 왜일까?

깨달음

데이터 ≠ 금 (본원적 가치 없음)

• 누가, 어떤 목적으로, 어떻게 쓰느냐에 따라 가치 결정
• 사용 방식에 따라 가치 천차만별

"데이터 = 21세기 원유" 비유의 이해

원유의 특성

원유 자체는 쓸모없음

• 최종 소비자에게 원유 줘도 사용 불가
• 정제 → 석유화학 제품 → 소비재 (의류, 페트병 등)
• 많은 사람이 옷이 원유에서 나온 줄 모름

데이터도 마찬가지

정제와 가공이 핵심

1. 원유(데이터) → 정제 필요
2. 석유화학 제품 → 중간재 생산
3. 소비재 → 최종 사용자에게 전달

→ 각 단계의 가공이 있어야 가치 창출

---

1. 기존 방식의 한계 (03:06-04:57)

전통적 데이터 상품 개발 프로세스

문제점

1. 데이터 분석가가 유스케이스 상상

   • 고객 니즈와 간격 큼
   • 실제 요구사항과 불일치

2. 딜리버리 시간 과다

   • 개발 → 테스트 → 배포
   • 고객 대응 느림

3. 결과

   • 데이터 가치 체감 어려움
   • 시장에서 인정받지 못함

게임 체인저: LLM의 등장

AI 모델 (LLM) = 게임 체인저

역할 변화

과거:

• 데이터 조직 = 분석 + 상품화 + 딜리버리

현재:

• AI 에이전트/LLM = 최종 상품 딜리버리
• 고객 요구사항에 맞춰 실시간 제품 생성
• 데이터 조직 = AI가 잘 일하도록 데이터 선별/전달

→ 역할이 완전히 바뀜

---

2. 시행착오 1: 도메인 특화 모델의 한계 (04:57-05:56)

많은 기업의 시도

도메인 특화 모델 학습

• 전문가가 데이터 만들기
• LLM 모델 학습시키기
• 특화된 모델 공급

문제점

기존 프로세스와 차이 없음

1. 딜리버리 시간 여전히 오래 걸림
2. 비용 많이 듦
3. 유연성 부족

발표자의 접근

추론 단계에서 데이터 활용

• 학습이 아닌 추론 시점에 데이터 제공
• 더 빠르고 유연함

타이밍의 행운

2024년 핵심 기술 등장

• MCP (Model Context Protocol)
• Claude Skills
• A2A (Agent-to-Agent)
• RAG 기술 발전

→ 추론 단계 데이터 활용 가능해짐

결론

범용 LLM + 좋은 데이터 = 도메인 특화 LLM 수준

---

3. 시행착오 2: 위키 형태 데이터 (05:56-07:43)

통신사의 강점

개인정보의 보고

• 가장 긴 컨텍스트/맥락 데이터 보유
• 서비스 구애 없이 통합 데이터
• 데이터 기업 중 최강자

가설: LLM은 위키를 좋아한다

근거

LLM 학습 데이터

• 나무위키, 위키피디아 등 위키 형태 대량 사용
• 양질의 학습 데이터 확보 위해

추측

"위키 형태 데이터를 LLM이 가장 잘 이해하고 활용할 것"

실험: 박찬호 테스트

질문: "박찬호 선수의 경력을 표로 정리해줘"

결과:

• Claude, ChatGPT 모두 잘 작동
• RAG 추론 근거 확인 시 → 나무위키, 위키피디아

→ 가설 확인!

데이터 구조 변경

기존: 스코어 기반 데이터 변경: 위키 형태 문서

• 위상과 체계를 가진 구조
• 개인 간 관계도 링크로 연결
• 위키피디아 스타일 구조화

적용 사례

퍼스널 AI 에이전트 서비스

• 개인 맞춤형 서비스 제공
• 100~200명 규모에서 잘 작동

결정적 단점: 스케일 문제

문제 발생

소규모 (100~200명): ✅ 잘 작동 대규모 (10만~1000만 명): ❌ 문제 발생

원인:

• 데이터 양이 어마어마하게 증가
• 유스케이스가 나오지 않음
• 집계/분석 불가능

한계:

• 퍼스널 서비스에만 유용
• 유스케이스 너무 제한적
• 훌륭하지만 활용도 낮음

---

4. 시행착오 3: 벡터 DB & 지식 그래프 (07:43-08:36)

새로운 시도

벡터 DB + 지식 그래프

• 개인 프로파일 검색 최적화
• 다른 발표에서도 많이 소개된 방법

기대

"이번엔 검색이 잘 되겠지!"

실제 결과

한계 발견

• 잘 되는 데이터 도메인 있음
• 개인 프로파일은 안 맞음

왜 안 될까?

실험: 청중 테스트

질문 1: "나중에 QnA에서 손 들어보세요" → 거의 손 안 듦

질문 2: "Claude Skills 써보신 분?" → 거의 손 안 듦

이유:

"우리나라 사람들 대부분 샤이하거든요"

문제점

프로파일이 비슷비슷함

• 특성이 두드러지지 않음
• 검색으로 필요한 데이터 잘 안 나옴
• 차별화된 데이터 추출 어려움

→ 벡터 검색도 실패

---

5. 해결책: MCP (Model Context Protocol) (08:36-10:01)

전환점

팀원의 제안: "MCP 적용해보면 어떨까?" 결과:

"핏이 제일 잘 맞았어요!"

MCP의 3가지 핵심 특징

1. 표준화된 프로토콜

장점: 중복 개발 불필요

• 한 번 만들면 어디서나 사용
• 다양한 AI 에이전트와 호환

2. AI 모델 컨텍스트 반영

임팩트가 가장 컸던 부분

• LLM 추론 시 적절한 맥락 제공
• 정확도 대폭 향상

3. 다양한 데이터 조합 가능

유연성

• 필요한 데이터 선별
• 조합해서 사용
• 고객에게 최적화된 딜리버리

MCP의 혁명적 변화

과거:

• 고객 요구사항 1개 = 분석가 1명 필요
• 결과물 1회용
• 재사용 불가

현재 (MCP):

• 한 번 만든 MCP = 모든 곳에서 사용
• Claude 사용자 ✅
• Cursor 사용자 ✅
• 사내 AI 에이전트 ✅
• 다양한 유스케이스에 조합 가능 ✅

→ 재사용성 극대화

---

6. AI Readable 데이터의 조건 (10:01-11:49)

현장에서 체득한 요건

이론이 아닌 실전 경험

1. 신뢰할 수 있는 품질

데이터 선별이 핵심

중요한 깨달음:

"AI 시대에도 데이터 분석가/엔지니어 역할은 사라지지 않는다"

역할 변화:

• 과거: 분석 + 상품화 + 딜리버리
• 현재: 신뢰할 수 있는 좋은 데이터 선별 + 공급

→ 공급자로 역할 전환

2. 최신성 담보

추론용 데이터의 핵심

논리:

• 과거 데이터 = 학습에 사용
• 최신 데이터 = 추론에 사용
• 과거 데이터로 추론? → 차라리 학습시키기

장점:

• 실시간성
• 현재 상황 반영
• 경쟁 우위

3. 상세하고 구조화된 명세

LLM이 알아서 선택하도록

필요 요소:

• 디테일한 설명
• 다양한 도메인 커버
• 명확한 구조

문제점:

• 설명 부실 → LLM 헤맴
• 특정 도메인 누락 → 업무 수행 실패

4. 액션 가능한 결과

최종 목표

• 분석으로 끝나면 안 됨
• 실제 행동으로 연결되어야

결론

범용 LLM + AI Readable 데이터 = 도메인 특화 LLM

• 맥락과 의미 파악 가능
• 특화된 도메인 역할 수행

---

7. 기존 vs 현재 프로세스 비교 (11:49-13:45)

기존 프로세스

1단계: 데이터 수집

SKT 보유 데이터

• 위치 데이터
• 통화 데이터
• 앱 이용 데이터

2단계: 후보 도메인 선정

• 산업 조사
• 기업 인터뷰
• 고객사 요청

3단계: API 상품 개발

• 데이터 상품화
• API로 제공

4단계: 피드백 & 개선

• 사용 후 피드백
• 반영 → 재개발
• 루프 반복

영업 구조

1대 1 영업

• 영업사원 필요
• 개별 대응
• API 형태 판매

기존 방식의 한계

문제 1: 고객이 모름

"고객이 본인 요구사항을 잘 몰라요"

• 데이터를 어떻게 써야 할지
• 무엇을 요청해야 할지

문제 2: 개발자 필수

API 사용 = 개발자 필요

• 기획자/마케터는 사용 어려움
• GPTS에 API 연결도 어려움
• 데이터 가치 측정 전에 허들

→ 데이터 가치 체감 불가

기존 유스케이스 예시

서울교통공사 지하철 혼잡도

• 열차 혼잡도 안내
• 앱 서비스
• 전광판 안내
• 종합 안내판

공통점: 모두 개발자 필요

MCP 적용 후 변화

혁명적 개선

MCP로 도메인별 데이터 제공

• 고객 질의에 자동 대응
• MCP가 자동으로 조합
• 대답 경우의 수 폭발적 증가

결과:

"저희도 상상 못한 유스케이스들이 마구 나옵니다"

기존 유스케이스도 해결

지역 축제 방문객 분석

• 가장 많이 구매하는 데이터 상품
• 유동인구 통계
• 방문객 분석

새로운 유스케이스:

• 방문객 정보로 다양한 분석
• 예상 못한 활용 사례 속출

→ 활용도 극대화

---

8. 사내 적용 및 검증 (13:45-15:10)

단계적 접근 전략

왜 사내부터?

경험 부족 문제

• 보안 처리
• 접근 인증/인가
• 외부 출시 전 검증 필요

목표:

1. 활용도 확인
2. 문제점 발견
3. 해결 방법 마련

사내 MCP 데이터 구축

구축한 데이터 종류

1. 구매 데이터: 고객 구매 이력
2. 상담 데이터: 고객 상담 내역
3. 프로파일: 개인 정보
4. 통계 데이터:
   • 지하철 혼잡도
   • 장소 혼잡도
   • 음식점 인기도
   • 학원 인기도
   • 통화 기반 통계
   • 위치 기반 통계
   • 앱 방문 기반 통계

연동 AI 에이전트

• A. (에이다): SKT AI 서비스
• 폴라리스 AI: 사내 서비스
• 기타 다양한 AI 에이전트

→ 다양한 서비스에서 활용 가능

서비스 구조

3단계 아키텍처

1. MCP 카탈로그

   • 사용 가능한 MCP 목록

2. 에이전트 서비스

   • 카탈로그의 MCP 조합
   • 불러서 사용

3. 워크플로우 빌더

   • 에이전트를 다시 조합
   • 복잡한 워크플로우 구성

→ 계층적이고 유연한 구조

---

9. 실제 활용 사례 1: 축제 분석 (15:10-18:19)

기존 방식: 축제 분석

지자체의 요구사항

데모그래픽 분석

1. 성별 분포
2. 연령 분포
3. 지역별 방문자
4. 피크 타임
5. 총 방문객 수
6. 다른 축제와 비교
7. 작년 대비 비교

문제점:

• 복잡한 분석 요청
• 전문가 필요
• 시간 많이 걸림

MCP 방식: 축제 분석

구현 과정

1단계: MCP 생성

• 방문객 수 통계 MCP
• 장소 잡기 MCP

2단계: 스킬 생성

• Claude에 요청: "축제 분석 스킬 만들어줘"
• 발표자가 직접 프롬프트 작성 안 함
• Claude가 더 잘 만듦!

3단계: 분석 요청

"송파 석촌호수 벚꽃축제와 여의도 벚꽃축제를 비교해줘"

기존 퍼즐지도 서비스의 한계

서비스 기획자의 의도와 불일치

• 최근 30일 데이터만 제공
• 축제 기간 데이터 보고 싶은데...
• 다른 기간 보려면? → API 구매하라고 나옴
• 포기!

MCP + Claude Skills 결과

놀라운 성과

전문가 수준 리포트 자동 생성

• 실제 데이터 기반
• 전문가가 만든 수준
• 즉시 생성

가장 마음에 들었던 점

유연한 수정 가능

기존 프로세스:

1. 보고서 받음
2. 수정 필요 발견
3. SK텔레콤 영업사원 연락
4. "비용 얼마 더 드릴게요"
5. "2주 기다려주세요"
6. 분석가 작업
7. 딜리버리

MCP 프로세스:

• "페르소나 3개 말고 6개로 만들어줘"
• 즉시 업데이트
• 스킬 자동 수정

→ 실시간 대응 가능!

데모 사이트

실제 작동 예시 제공

• 링크로 확인 가능
• 직접 돌려볼 수는 없지만
• 예시로 도움됨

---

10. 실제 활용 사례 2: 페르소나 생성 (18:19-18:55)

요금제 설계 시나리오

필요성

새 요금제 출시 전 검증

• 영 고객 타겟 요금제
• 시장 반응 예측 필요

기존 방식

• 설문 조사 진행
• 시간과 비용 소요
• 표본 한계

MCP 활용

프로세스

고객 프로파일 데이터 MCP 활용

1. 페르소나 자동 생성
2. 가상 설문 실시
3. 반응 예측

대상 사용자

• 요금제 기획자
• 마케터

효과

빠른 검증

• 실제 출시 전 테스트
• 수정 사항 미리 파악
• 실패 위험 감소

---

11. 실제 활용 사례 3: 세일즈 프로모션 분석 (18:55-20:11)

비즈니스 도메인 활용

"돈이 될 만한 걸 고민해보자"

배경: 신규 단말 출시

기존 프로세스

아이폰/갤럭시 신규 출시

1. 사전 예약 프로모션
2. 실적 대시보드로 관리
3. 지역 마케터/팀/본부에서 확인

기존 대시보드의 문제

문제 1: 니즈 불일치

어떤 팀: 대시보드 잘 활용 ✅ 다른 팀: 대시보드 안 맞음 ❌

문제 2: 엑셀로 회귀

대시보드 못 쓰는 팀의 해결책

1. 영업 전산 시스템에서 데이터 다운로드
2. 엑셀로 수작업 관리

결론:

"대시보드를 아무리 잘 만들어도 니즈 안 맞으면 못 쓰신다"

MCP 솔루션

구현

기본 대시보드 포맷 + MCP

• 대리점 실적 데이터 MCP
• 신규 구매 데이터 MCP
• 기타 필요 데이터 MCP

사용 방식

질문으로 대시보드 변경

1. 기본 대시보드 제공
2. 사용자가 질문 입력
3. 보고서가 자동으로 변경
4. 원하는 형태로 커스터마이징

효과

유연한 대응

• 다양한 유스케이스 대응
• 개인별 맞춤 대시보드
• 엑셀 작업 불필요

→ 모든 팀이 활용 가능

---

전체 요약

데이터 가치 실현의 여정

출발점: 문제 인식

데이터 ≠ 금 (본원적 가치 없음)

• 사용 방식에 따라 가치 결정
• 원유처럼 정제 필요

게임 체인저: LLM

역할 대전환

• AI가 최종 상품 딜리버리
• 데이터 조직은 공급자로

시행착오와 학습

시도 1: 도메인 특화 모델

• ❌ 시간과 비용 과다
• ❌ 기존 방식과 차이 없음

시도 2: 위키 형태 데이터

• ✅ 소규모에서 작동
• ❌ 스케일 문제 (대규모 불가)

시도 3: 벡터 DB & 지식 그래프

• ❌ 개인 프로파일에 부적합
• ❌ 차별화 어려움

성공: MCP

• ✅ 표준화
• ✅ 컨텍스트 반영
• ✅ 데이터 조합
• ✅ 재사용성

AI Readable 데이터 4대 조건

1. ✅ 신뢰할 수 있는 품질
2. ✅ 최신성 담보
3. ✅ 상세하고 구조화된 명세
4. ✅ 액션 가능한 결과

실제 성과

축제 분석

• 전문가 수준 리포트 자동 생성
• 실시간 수정 가능
• 2주 → 즉시

요금제 설계

• 페르소나 자동 생성
• 가상 설문 실시
• 빠른 검증

세일즈 분석

• 유연한 대시보드
• 개인별 맞춤화
• 엑셀 작업 불필요

핵심 인사이트

데이터 조직의 미래

사라지지 않는다, 진화한다

• 과거: 분석 + 개발 + 딜리버리
• 현재: 품질 좋은 데이터 선별 + 공급

성공 공식

범용 LLM + AI Readable 데이터 = 도메인 특화 LLM

MCP의 혁명

1회용 → 재사용

• 한 번 만들면 어디서나
• 조합해서 새로운 가치
• 상상 못한 유스케이스 속출

발표자의 메시지

"데이터는 원유입니다. 정제하고 가공해야 가치를 발합니다. MCP는 그 정제 과정을 표준화하고, AI는 최종 소비자에게 맞춤형 제품을 즉시 전달합니다."

결론: AI 시대에 데이터 조직은 사라지는 게 아니라, 더 중요한 역할(공급자)로 진화한다!

스크립트