Claude Code를 팀에 붙이고 나서 가장 먼저 체감하는 병목은 응답 품질이 아니다. 컨텍스트 오염이다. 세션이 길어질수록 모델이 보는 정보는 늘어나지만 유용한 정보의 밀도는 떨어진다. 세 개의 독립적인 프로젝트—Sipcode, Bastra Recall, Tessl의 Skills 분석—가 서로 다른 각도에서 같은 문제를 가리키고 있다. AI 코딩 도구를 실무에 붙인 뒤 컨텍스트를 어떻게 설계하느냐가 속도와 품질 모두를 결정한다.
토큰 낭비는 비용 문제가 아니라 품질 문제다
Dev.to에 공개된 Sipcode 사례는 숫자부터 직접적이다. 3,567,170토큰 규모의 실제 세션에서 도구 출력(Read, Bash, Grep)을 모델에 전달하기 전에 중복을 제거하는 로컬 프록시를 붙였더니 중앙값 62.6% 토큰 절감이 나왔다. 절약된 비용이 $67.43이라는 수치보다 중요한 건 Anthropic이 자체 발표한 데이터다. 클린한 컨텍스트는 품질 29% 향상, 에이전트 오류 40% 감소로 이어진다. 즉 토큰을 줄이는 건 절약이 아니라 정확도를 높이는 행위다.
흥미로운 건 Sipcode 개발자 자신이 자기 도구의 버그를 도그푸딩으로 잡아내는 과정이다. 4시간 세션에서 62만 토큰이 낭비됐는데 자신의 프록시 통계는 7,553만 절약됐다고 표시했다—83배 과소 집계. 원인은 세션 중간에 의존성을 설치하면서 캐시가 비워진 것. 이 문제를 9일 만에 세 차례 릴리스로 수정했다. 실무 운영에서 컨텍스트 최적화 도구 자체도 검증이 필요하다는 사실을 실증한 케이스다.
세션이 끝나면 사라지는 추론, 메모리 레이어로 막아야 한다
토큰 효율 못지않게 팀 생산성을 갉아먹는 문제가 있다. Claude는 세션 간 상태를 기억하지 못한다. 아키텍처 결정, 네이밍 컨벤션, 이미 논의된 트레이드오프—새 세션이 열리면 전부 다시 설명해야 한다. Dev.to의 Bastra Recall 프로젝트는 이 문제를 MCP 서버로 접근한다. 기억을 로컬 Obsidian 볼트의 Markdown 파일로 저장하고, 다음 세션에서 관련 메모리를 자동으로 컨텍스트에 주입한다.
설계 철학이 실용적이다. Redis 서버나 클라우드 API 없이 로컬 파일로만 동작하고, Claude Code·Claude Desktop·Cursor에 동일한 데몬이 연결된다. 한 도구에서 저장한 결정이 다른 도구에서도 바로 쓰인다. 단 현재 macOS Apple Silicon + Node 22+ 환경만 지원하는 베타(0.7.0)다. 프로덕션 투입보다는 팀 내 파일럿 검증 수준으로 접근하는 게 맞다.
핵심은 검색 품질이다. 저장은 쉽지만 올바른 기억을 골라 주입하지 못하면 오히려 컨텍스트 오염이 된다. Bastra Recall은 현재 대화와의 관련도 기반으로 상위 매칭만 주입하는 방식을 쓴다. 이 검색 레이어의 품질이 도구의 실질적 가치를 결정할 것이다.
Skills 파일도 컨텍스트다—90%는 첫 커밋 이후 방치된다
Tessl이 GitHub 전체를 분석한 결과는 충격적이다. SKILL.md 파일은 14주 만에 450배 성장해 5,460개 레포에 퍼졌다. 그런데 에이전트 설정 파일의 90%는 최초 생성 이후 한 번도 업데이트되지 않는다. 코드베이스는 매일 바뀌는데 에이전트에게 주는 지식은 첫 날에 고정된다.
더 구체적인 문제는 활성화율이다. Skills가 설치돼 있어도 에이전트가 강제 실행하지 않으면 활성화율이 41%까지 떨어진다. Tessl이 622개 오픈소스 PR을 분석하면서 찾아낸 가장 흔한 실패 원인은 설명 필드의 모호함이다. "코드 리뷰와 품질 향상을 위한 도움이 되는 스킬"같은 설명은 에이전트가 언제 이 Skills를 써야 하는지 판단할 수 없게 만든다. "ESLint 프로젝트 룰 실행, 타입 안전성 위반 플래그, TypeScript PR 리뷰 또는 프리-커밋 체크 시 사용"처럼 도메인 특화 명사와 구체적 트리거가 있어야 한다.
또 하나의 함정은 God Skills다. 50개 파일을 묶은 스킬은 설명이 너무 광범위해지고, 에이전트가 잘못된 상황에서 활성화하거나 아예 무시한다. SkillsBench 연구에 따르면 84개 태스크 중 16개에서 Skills가 오히려 에이전트 성능을 떨어뜨렸다. 불필요한 복잡성이 모델이 이미 잘 아는 영역에 간섭한 결과다.
팀 리드가 지금 당장 적용할 수 있는 것
세 프로젝트를 종합하면 Claude Code 실전 운영의 컨텍스트 설계는 세 레이어로 나뉜다.
레이어 1: 세션 내 노이즈 제거. Sipcode처럼 도구 출력을 모델에 전달하기 전에 필터링하는 레이어다. 직접 구축하지 않더라도 Bash 출력을 파이프로 가공하거나 Grep 결과를 정리해 전달하는 습관만으로도 효과가 있다. 핵심은 모델이 보는 텍스트의 품질이지 양이 아니다.
레이어 2: 세션 간 기억 유지. 지금 당장 쓸 수 있는 가장 단순한 방법은 CLAUDE.md에 팀의 핵심 결정을 기록하는 것이다. Bastra Recall 같은 자동화 도구는 안정화되면 도입 검토를 하되, 지금은 수동 관리라도 하는 게 낫다. "우리는 Drizzle 쓴다, Prisma 아니다" 한 줄이 다음 세션에서 10분을 아낀다.
레이어 3: Skills와 에이전트 설정의 갱신 주기 설계. SKILL.md를 코드와 함께 리뷰 대상에 넣어야 한다. API 계약이 바뀌었는데 Skills가 6개월 전 버전을 가리키고 있으면 에이전트가 잘못된 코드를 자신 있게 생성한다. 스프린트 회고나 주요 리팩터링 PR에 SKILL.md 업데이트를 체크리스트 항목으로 넣는 것만으로도 90% 방치 문제를 막을 수 있다.
컨텍스트 품질이 AI-First 워크플로우의 실질적 속도를 결정한다
AI 코딩 도구 도입 논의는 여전히 "어떤 도구를 쓸 것인가"에 집중되는 경향이 있다. 그러나 실전 데이터는 다른 질문을 가리킨다. 모델이 보는 컨텍스트가 얼마나 깨끗한가. 토큰 효율은 비용의 문제가 아니라 품질과 속도의 문제다. 세션 기억은 편의 기능이 아니라 팀 생산성의 누수를 막는 인프라다. Skills 설계는 한 번 쓰고 마는 설정이 아니라 코드베이스와 함께 유지보수해야 할 문서다.
컨텍스트를 설계하지 않은 채 빠른 AI 도구를 붙이는 건, 연료 필터 없이 엔진 출력을 높이는 것과 같다. 빠를 수 있다. 하지만 오래가지 못한다.