진짜는 에이전트가 아니라 '스킬'이었다

01핵심 개요

02실패한 3가지 접근 (왜 어려웠나)

• 넓고 평평한 테이블: 모든 데이터를 한 시트에 → 매출 정의가 시트마다 달라짐, SQL 모르는 사람은 무용.
• 울타리친 대시보드: 미리 정한 화면만 → 자잘한 질문 못 받아 대시보드 무한 증식, 관리 불가.
• AI 에이전트에 그냥 위임: 그럴듯한 답을 주지만 맞는지 확인 불가 → 겉만 정밀한 가짜.

03진짜 문제 3가지 (Anthropic의 진단)

1. 개념과 실제 데이터의 애매함: "활성 사용자"의 기준이 정의되지 않으면 제각각 해석.
2. 데이터가 자꾸 낡음: 테이블·정의·로직이 계속 바뀌어 어제 맞던 게 오늘 틀림.
3. 정보를 못 찾음: 정답은 회사 어딘가 있지만 분류표가 없어 헤맴.

04핵심 해법 — 4층 구조

1층 데이터 기초 공사

• 표준 데이터셋 = 단 하나의 진실의 원천(One Source of Truth). "매출은 무조건 이 데이터" 못 박기.
• CI/CD로 규칙 강제(안 지키면 통과 불가). 메타데이터를 1등 시민으로 제품처럼 관리.

2층 진실의 원천들 (신뢰 순서)

• 시멘틱 레이어(공식 인증 지표 계산기) → 데이터 족보(출처·변경 흐름) → 정리된 과거 쿼리 → 회사 맥락 지식.
• 핵심: 낡은 SQL을 그냥 검색하게 하면 정확도 1%도 안 오름 → 다듬어야 의미.

3층 스킬 (정확도를 뒤집은 층)

• 스킬 = 절차적 지식 = "일하는 방법"(어떤 자료부터, 애매할 때 대처, 완성 분석의 형태).
• 효과: 스킬 없을 때 21% → 스킬 도입 후 95%(일부 99%).
• 지식 스킬(안내데스크/라우터): 질문 영역 판별 후 관련 문서 ~30개만 호출.
• 플레이북 스킬(베테랑 절차): 질문 명확화 → 자료 탐색 → 실행 → 적대적 검토(자기 답 의심) → 검증된 패턴 재사용.

4층 검증

• 오프라인 평가: 정답 아는 시험 문제(Claude가 생성, 사람이 검수). 영역별 90% 미달 시 출시 차단.
• 실시간 검증: 별도 AI 검토관이 답을 의심. 트레이드오프 — 정확도 +6%, 토큰 -32%, 응답시간 +72%.
• 출처 푸터(등급·신선도·소유자 표기) + 자동 교정 수집(채팅 채널 순회하며 오류 수정안 생성).

05반전 실험 — 정보가 아니라 구조

• 과거 SQL 수천 개를 통째로 제공(파일의 80%가 관련 정보 보유) → 정확도 1점도 안 오름.
• 결론: 문제는 정보 접근이 아니라 질문을 데이터에 연결하는 "구조"(다리)의 부재.
• 또 다른 사고: 스킬 완성 후 한 달 만에 95% → 65%로 추락. 회사가 바뀌었는데 문서가 안 바뀜.
• 해결: 스킬 문서를 데이터 코드와 같은 창고에 넣고 CI 훅으로 동시 수정 강제 → 수정의 90%가 스킬 업데이트 포함.

06활용 시나리오

1. 사내 데이터 분석 자동화: 표준 데이터셋 몇 개 + 오프라인 평가 수십 개 + 얇은 지식 스킬 1개로 최소 시작.
2. AI 에이전트 운영팀: 에이전트 추가보다 "스킬(매뉴얼)" 제작·갱신에 투자. 문서-코드 동기화 훅 도입.
3. 정확도-비용-속도 균형 설계: 적대적 검토의 트레이드오프(정확도↑·비용↓·속도↓)를 업무 특성에 맞게 선택.

07핵심 교훈

• 데이터는 소프트웨어가 아니다 — 정답을 증명하기 어렵고, 진짜 문제는 코드 생성이 아니라 애매함.
• 정확도는 결국 맥락·검증의 문제(모델이 똑똑한가의 문제가 아님).
• 강제 없는 규칙은 빠르게 썩는다.
• 낡은 문서는 모델 한 개보다 성능을 더 빨리 죽인다.
• 정의는 사람이 책임지고(활성 사용자 정의 등), 과거 쿼리는 정리된 패턴으로 다듬는다.
• 결론 한 줄: 필요한 건 에이전트가 아니라 "스킬"이며, 검증된 스킬 축적이 해자(垓子).

08용어 사전

09핵심 타임스탬프

• 0:00 Anthropic 사례 개요 (95% 자동화)
• 3:15 표준 데이터셋 = One Source of Truth
• 5:22 3층 스킬 — 21%→95% 반전
• 7:22 문서 노화로 95%→65% 추락과 해결
• 8:24 반전 실험 — 정보가 아니라 구조
• 11:36 최소 시작 3종 세트