AI-First 팀을 세팅하면 처음 몇 주는 꿈만 같습니다. Claude Code로 코드를 짜고, CI에 AI 리뷰를 붙이고, 에이전트가 문서를 읽고 아키텍처를 파악해주는 세상. 그런데 한 달쯤 지나면 팀 슬랙에 이런 메시지가 올라옵니다. "이번 달 API 비용이 왜 3배죠?" "AI 리뷰 코멘트 너무 뻔해서 다들 무시해요." "에이전트가 삭제된 API 엔드포인트 기준으로 코드 짜고 있었어요."
이번 주 dev.to에 올라온 네 편의 실전 포스트가 정확히 이 지점을 짚고 있어서, AI-First 팀이 도구 도입 '이후'에 반드시 마주치는 네 가지 운영 지뢰로 정리해봤습니다.
지뢰 1: Claude Code 캐시 미스가 만드는 '보이지 않는 청구서'
kitaekatt의 Mastering Cache Hits in Claude Code 분석에 따르면, Claude Code가 API를 호출할 때마다 시스템 프롬프트·CLAUDE.md·전체 대화 이력을 포함해 5만~20만 토큰 이상이 전송됩니다. 캐시가 제대로 작동하면 히트 토큰은 기본 입력 대비 10분의 1 비용이지만, 세션 중간에 모델을 /model로 교체하거나 CLAUDE.md를 수정하면 캐시 프리픽스가 통째로 깨집니다.
20턴 세션 기준으로 캐시가 잘 작동할 때 입력 비용은 약 $0.95인데, 캐시가 매번 미스 나면 $6.00—84% 차이입니다. 문제는 Claude Code UI가 캐시 히트율을 보여주지 않는다는 점이에요. 팀원 다섯 명이 각자의 세션에서 모르는 사이에 캐시를 깨뜨리면, 월말 청구서에서야 비로소 알게 됩니다.
저라면 팀에 이런 규칙을 세울 겁니다. 세션 중 모델 전환 금지, CLAUDE.md는 세션 시작 전에만 수정, 그리고 kitaekatt이 공개한 cache-kit 플러그인 같은 도구로 주 1회 캐시 리포트를 리뷰하는 루틴. AI 비용 최적화는 프롬프트 엔지니어링이 아니라 운영 습관의 영역입니다.
지뢰 2: AI 코드 리뷰가 '소음'이 되는 순간
lvndry의 Build your own AI code review agent in CI 포스트는 GitHub Actions에 Jazz AI를 연결해 PR마다 자동 리뷰를 생성하는 파이프라인을 소개합니다. 흥미로운 건 기술 구현보다 루브릭(rubric) 설계에 더 많은 지면을 할애한다는 점입니다.
저도 Claude한테 코드 리뷰를 시켜본 적이 많은데, 루브릭 없이 던지면 "테스트를 추가하세요" 같은 일반적인 코멘트만 줄줄이 나옵니다. 팀원들이 일주일이면 무시하기 시작하죠. lvndry가 강조하는 핵심은 세 가지입니다: 심각도 분류(High/Medium/Low), 확신도 표시("이건 추측입니다"), 그리고 구체적 수정안("이 함수의 이 라인을 이렇게 바꾸세요"). 여기에 "거짓 양성 예산"이라는 개념도 제안하는데, 일정 기간 노이즈가 너무 많으면 루브릭을 튜닝하라는 겁니다.
또 한 가지 실전 팁—diff 크기에 따라 모델을 라우팅하라는 조언이 좋았습니다. 10줄짜리 PR에 Opus를 쓸 필요가 없으니까요. 그리고 무엇보다 중요한 원칙: CI 에이전트에게 레포 변경 권한을 절대 주지 말 것. read-only로 제한하는 게 가장 안전한 출발점입니다.
지뢰 3: 에이전트가 '허구'를 기반으로 코딩하는 문서 드리프트
mossrussell의 Your AI Agent is Coding Against Fiction 제목이 아주 직관적입니다. 프로젝트 초기에 ARCHITECTURE.md를 잘 써두고 에이전트에게 컨텍스트로 넘겼는데, 커밋 20개 후에는 문서에 적힌 API 라우트 절반이 이미 없어진 상태—에이전트는 존재하지 않는 엔드포인트를 호출하는 코드를 자신 있게 생성합니다.
agent-guard라는 제로 디펜던시 CLI가 이걸 4중 레이어로 해결합니다. 소스코드에서 API 라우트·Prisma 모델·환경변수를 자동 추출해 마크다운 인벤토리를 생성하고, pre-commit 훅이 문서 변경이 필요한 커밋을 감지해서 Claude Code가 있으면 자동 업데이트, 없으면 복붙용 프롬프트를 출력합니다.
AI-First 팀 입장에서 이게 중요한 이유는 명확합니다. 에이전트의 출력 품질은 결국 입력 컨텍스트의 정확도에 비례하니까요. 문서 동기화를 사람의 기억에 의존하는 팀은, 에이전트가 생성하는 코드를 매번 의심해야 하는 비용이 누적됩니다. 자동화할 수 있는 신뢰 레이어는 가능한 빨리 깔아두는 게 맞습니다.
지뢰 4: MCP 서버의 런타임 보안—"도구 이름이 곧 명령어"
kai_security_ai의 The Two Layers of MCP Security 포스트가 전하는 경고는 소름끼칩니다. 319개 MCP 서버를 스캔한 결과, 16%(59개)가 인증 없이 노출되어 있었고, 541개 도구가 아무 에이전트나 호출 가능한 상태였습니다. Render.com의 클라우드 인프라 도구 24개, Airtable의 데이터베이스 CRUD 8개가 그 목록에 포함됩니다.
더 무서운 건 허니팟 실험입니다. get_aws_credentials(role)이라는 도구를 올려놨더니 3시간 만에 AI 에이전트가 role=admin으로 호출했습니다. 악의적인 에이전트가 아니었어요. 도구 목록을 열거하다가 이름이 '자격증명'이니까 자동으로 호출한 겁니다. LLM에게 도구 이름은 곧 시맨틱 명령어라는 뜻이죠.
Cisco가 이번 주 공개한 MCP Scanner가 공급망(코드 설치 전) 위협을 잡는다면, 런타임(배포 후) 노출은 별도 레이어로 막아야 합니다. 팀에 MCP 서버를 운영하고 있다면, 최소한 tools/list 엔드포인트에 인증을 거는 것이 첫 번째 조치입니다.
시사점: AI-First의 진짜 경쟁력은 '운영 규율'에 있다
네 가지 지뢰의 공통점이 보이시나요? 전부 도구 자체의 문제가 아니라 운영 방식의 문제입니다. 캐시 히트율은 세션 관리 습관, AI 리뷰 품질은 루브릭 설계, 문서 드리프트는 자동화 파이프라인, MCP 보안은 인증 정책—기술 도입 이후의 '두 번째 마일'을 뛰는 팀이 결국 AI-First의 실질적 ROI를 가져갑니다.
저는 팀원들에게 이렇게 이야기합니다. "AI 도구를 쓰는 건 누구나 해요. 우리가 이기려면 AI를 '잘 운영'하는 팀이 돼야 합니다." 이 네 가지 지뢰를 미리 인식하고, 각각에 대한 팀 규칙을 세우는 것—그게 AI-First 리빌딩의 진짜 시작입니다.