AI가 추천을 건너뛰는 이유를 추적해봤습니다 — 공유 스킬 플랫폼 개선기

이전 글에서 MCP 서버 하나로 Claude Code, OpenCode, Codex 세 도구를 동시에 지원하는 구조를 만들었습니다. 이번엔 그 위에 "왜 추천이 안 되는지", "추천된 스킬을 실제로 쓰는지"를 추적하는 시스템을 Claude Code와 함께 만들었습니다.

바쁘시면 이것만 읽어도 됩니다:

• 스킬을 가져갔는지, 실제로 활용했는지 추적이 안 돼서 서비스 방향을 못 잡고 있었습니다

• 세션 추적 → 데이터 분석 → 검색 엔진 개선 → 퍼널 전체 추적까지 구현했습니다

• 추적 결과: 검색 622건 중 로드 176건(28%), AI가 건너뛰는 주된 이유는 "관련 없음" 판단이었습니다

• 검색 병목이 임베딩이 아니라 DB라는 걸 데이터로 확인했습니다 — 삽질도 기록합니다

• 커밋 38개, Claude Code 팀 편성으로 병렬 개발 (도구: Claude Opus 4.5 / Sonnet 4.5)

이런 분들께 도움됩니다:

• AI 코딩 도구를 써보고 있는데, 실제 프로덕트 개발에 어떻게 활용하는지 궁금하신 분

• 사내 도구나 플랫폼을 만들면서 사용자 행동 추적을 고민하시는 분

• Claude Code의 팀 편성, 병렬 작업 같은 기능을 실제로 어떻게 쓰는지 보고 싶으신 분

이전 글 이후의 문제

이전 글에서 MCP 서버 + 3개 플러그인 구조를 완성하고, UserPromptSubmit 훅으로 스킬 자동 검색까지 붙였습니다. "향후 계획"에 적었던 두 가지가 있었는데요:

• 사용 통계 기반 추천 순위 개선

• 시맨틱 검색 정확도 향상

막상 이걸 하려니 근본적인 문제가 있었습니다.

추천 정확도. 시맨틱 검색으로 스킬을 찾아주는데, 원하는 스킬이 잘 안 나왔습니다. 검색 속도도 2.6초나 걸려서 AI가 "느리니까 그냥 넘어가자"고 판단해버리는 경우가 있었습니다.

추적 불가. 사용자가 스킬을 검색했는지, 가져갔는지, 실제로 적용했는지 전혀 알 수 없었습니다. 뭘 개선해야 하는지 감으로 판단할 수밖에 없었습니다.

추적 없이는 개선도 없고, 서비스 방향성도 확정 못 짓는 상태였습니다.

진행 방법

1. 세션 추적부터 깔았습니다

제일 먼저 한 건 "사용자가 뭘 하고 있는지"를 기록하는 시스템입니다. 기존에 MCP 도구 호출 로그는 있었지만, 세션 단위로 "누가 언제 시작해서 뭘 했는지"를 알 수 없었습니다.

DEVLOG 스킬을 확인하고, 해당 방식을 플러그인에 접목해서 사용자가 에이전트와 대화했던 내역을 저장해 분석에 활용하고 싶어.

Claude Code가 서버 측 DB 테이블 설계부터 3개 플러그인 각각의 리포트 모듈까지 한 번에 만들었습니다. 각 플러그인이 세션 시작/종료를 서버에 보고하고, Cron으로 미완료 세션을 자동 정리하는 구조입니다.

이전 글에서도 언급했듯이 플러그인마다 구현 방식이 다릅니다. Claude Code는 셸 스크립트, OpenCode는 TypeScript 모듈, Codex는 스킬 문서. 이걸 각각의 방식에 맞춰서 만들어줍니다.

2. 데이터로 방향 잡기

세션 추적을 깔았지만, 기존 MCP 도구 호출 로그가 이미 수천 건 쌓여 있었습니다. 이걸 분석하면 현황 파악은 가능했습니다.

지금 문제는 두 가지야. ① 시맨틱 검색이 원하는 스킬을 찾아주지 못하는 문제. ② 스킬을 가져왔다고 해도 실제 유저가 효용성을 느낄 수 있는지에 대한 문제. 팀을 구성해서 다각도로 분석한 결과를 보여줘

Claude Code가 DB에서 실제 사용 데이터를 쿼리해서 분석 리포트를 만들고, 방향성 문서와 2주 로드맵을 작성했습니다. 이걸 바탕으로 Linear에 이슈 8개를 생성하고, 팀을 편성해서 6개를 병렬로 착수했습니다.

하루 만에 분석 → 로드맵 → 이슈 생성 → 구현 착수까지 끝났습니다. 검색에 userContext 파라미터를 추가하고, 임베딩 캐시를 도입하고, 메타데이터 품질 자동 체크를 구현하는 것까지 이날 바로 나왔습니다.

3. 검색 개선 + 삽질 두 건

검색 엔진. 검색이 느리면 AI가 추천 자체를 건너뜁니다. 2.6초짜리 검색은 대화 흐름을 끊기에 충분합니다.

임베딩 모델을 Gemini에서 OpenAI text-embedding-3-small로 전환했습니다. 임베딩 생성 속도가 580ms에서 150ms로 4배 빨라졌고, 검색 정확도도 30% 향상됐습니다. 의미 없는 노이즈 쿼리를 사전에 걸러내는 필터도 붙였습니다.

다만 전체 검색 시간은 여전히 약 2.7초였습니다. 임베딩 생성은 빨라졌지만, 실제 병목은 Neon DB의 벡터 유사도 검색이었습니다. "모델만 바꾸면 해결될 줄 알았는데, 진짜 느린 건 DB였다"는 걸 데이터로 확인한 셈입니다. 검색 속도는 다음 스프린트 과제로 남겼습니다.

마켓플레이스 캐시 문제. 같은 날 또 다른 삽질이 터졌습니다.

현재 이 프로젝트의 클코 플러그인의 최신버전은 0.1.6인데 사용자는 0.1.3에서 멈춰있지?

플러그인을 업데이트해서 배포했는데 사용자 쪽에서 옛날 버전이 계속 뜨는 문제였습니다. Claude Code 마켓플레이스가 git tag 기반으로 버전을 조회하는 구조인데, 세션 시작 시 버전이 고정됩니다. 기존 세션에는 새 버전이 반영 안 되는 거였습니다. 이걸 파악하는 데 시간이 좀 걸렸습니다. 결국 세션 시작 시 최신 버전을 자동 체크하는 로직을 3개 플러그인 모두에 추가했습니다.

4. 퍼널 전체 추적

가장 핵심인 작업입니다.

기존에는 "스킬을 검색했다"는 로그만 있었습니다. 검색 결과를 AI가 봤는데 왜 안 가져갔는지, 가져간 스킬을 실제로 적용했는지 알 수 없었습니다.

검색 결과를 AI가 봤는데 왜 로드 안 했는지, 로드한 스킬을 실제로 적용했는지 — 이걸 둘 다 알 수 있게끔 어떻게든 추적할 수 있게 방법을 고안해봐

MCP 도구를 두 개 추가했습니다:

• report_search_skip — AI가 검색 결과를 보고 스킬을 로드하지 않은 이유를 기록

• report_skill_outcome — 로드한 스킬을 실제로 적용했는지, 안 했으면 왜인지 기록

이걸 3개 플러그인 전부에 반영하고, 분석 도구에도 퍼널 지표를 추가했습니다. 이전 글의 구조대로 3개 플러그인 동시 업데이트입니다.

스킬 배포 시 description과 tags를 필수로 채우게도 만들었습니다. 검색이 아무리 좋아도 메타데이터가 없으면 못 찾습니다.

결과와 배운 점

결과 비교

아직 못 푼 것:

• 전체 검색 속도 2.7초 — DB 벡터 검색 병목 (임베딩은 빨라졌지만 DB가 느립니다)

• 로드→적용 전환율 — 데이터 수집 시작 단계, 분석 가능한 양이 아직 부족합니다

수치:

• 커밋 38개

• 3개 플러그인 동시 업데이트 (claude-code v0.1.10, opencode v0.0.18, codex v0.1.8)

AI 활용 팁

효과적이었던 것

1. "팀 편성해서 병렬로 해" — Claude Code에게 작업 방식까지 지시하면 실제로 여러 이슈를 동시에 처리합니다. 분석부터 6개 이슈 병렬 구현까지 하루에 끝났습니다.

2. 데이터 먼저, 방향은 그다음 — AI에게 DB를 직접 쿼리시켜서 사용 행태를 분석하게 하면, 감이 아니라 근거로 결정할 수 있습니다.

3. "항상 3개 같이" — "플러그인 관련 작업은 항상 3개 같이"라고 메모리에 저장해두니, 이후 세션에서도 빠짐없이 3개 모두 업데이트합니다.

주의할 점

1. 캐시/업데이트 메커니즘을 가정하지 마세요 — 마켓플레이스가 버전을 어떻게 관리하는지 확인 안 하고 "배포하면 되겠지" 하면 삽질합니다.

2. 추적 없이 개선하려 하지 마세요 — 측정할 수 없으면 뭘 개선해야 하는지도 모릅니다. 추적 시스템을 먼저 깔아야 합니다.

3. 병목은 가정하지 말고 측정하세요 — 임베딩이 느린 줄 알았는데 DB가 느렸습니다. 프로파일링 없이 최적화하면 엉뚱한 데 시간 씁니다.

앞으로의 계획

• DB 벡터 검색 병목 해결 — 캐시 레이어 또는 인덱스 최적화로 전체 검색 시간 1.5초 이하 목표

• 퍼널 데이터가 충분히 쌓이면 추천 알고리즘 고도화

• 보안/사용성 이슈 해결 후 베타 테스터 대상 외부 공개 준비