모두가 AI 코딩 도구를 쓰는데, 왜 팀은 더 빨라지지 않는가
요즘 개발팀 어디를 가도 Cursor, GitHub Copilot, Claude Code 중 하나는 열려 있다. 엔지니어 개인의 코드 작성 속도는 체감상 2~3배 빨라졌다는 말도 심심찮게 들린다. 그런데 정작 팀 단위로 '가치를 더 빠르게 전달하고 있냐'는 질문을 던지면 대답이 흐릿해진다. 스프린트 속도가 체감상 늘었지만 릴리스 주기는 그대로고, PR 리뷰 대기는 여전히 길고, 프로덕션 사고는 줄지 않았다. AI 도구를 쌓으면 쌓을수록 오히려 팀이 느려지는 것처럼 느껴지는 조직이 생각보다 많다.
병목은 도구가 아니라 조직에 있다
O'Reilly에 최근 게재된 분석('병목은 조직에 있다')은 이 현상을 정확하게 짚는다. 핵심 논지는 단순하다. AI 코딩 도구는 증폭기(amplifier)다. DORA 최신 보고서도 같은 말을 한다. '고성과 조직의 강점과 부진 조직의 역기능을 모두 키운다.' 즉, AI가 빠르게 코드를 생성할수록 이미 취약했던 CI/CD 파이프라인, 테스트 커버리지 부재, 불명확한 오너십 구조가 더 빠르게 드러날 뿐이다.
이 논지가 흥미로운 이유는 마이크로서비스와의 비교 때문이다. 10년 전 마이크로서비스 도입 실패의 패턴을 돌아보면 놀랍도록 유사하다. 자동화 테스트, 점진적 배포, 문서화를 지원하는 CI/CD 파이프라인 없이 마이크로서비스를 도입했던 팀은 복잡도만 얻고 유연성은 얻지 못했다. AI 코딩 에이전트도 마찬가지다. 배포 파이프라인과 가드레일이 없는 조직에 AI를 붙이면, 잘못된 방향으로 더 빠르게 달려갈 뿐이다.
가드레일 없는 에이전트는 방향 없는 자율 팀과 같다
실제 현장에서 자주 목격하는 장면이 있다. AI가 생성한 코드가 PR에 올라왔는데 코딩 컨벤션이 제각각이고, 아키텍처 결정 기록(ADR)과 무관한 패턴이 섞여 있고, 테스트는 껍데기만 있다. 리뷰어가 이걸 하나씩 잡아내는 데 결국 사람 손이 더 들어간다.
앞서 언급한 분석은 이것을 '가드레일 문제'로 정리한다. 팀원에게 '올바른 일을 하라'고 말하는 것만으로는 부족하듯, 에이전트에게도 자동으로 올바른 방향으로 가도록 돕는 구조가 필요하다. CI에서 강제되는 코딩 표준, ADR, 서비스 템플릿—이것들이 사람 팀원을 위한 가드레일인 동시에 AI 에이전트를 궤도에 올려두는 제약이 된다. 이미 엔지니어링 인에이블먼트에 투자한 조직이 AI 도구 도입 효과를 가장 빠르게 누리는 이유가 여기에 있다.
도구를 많이 쌓는 것과 잘 쓰는 것은 다르다
팀 생산성이 제자리인 두 번째 이유는 도구 수가 아니라 도구의 컨텍스트 효율에 있다. Claude Code를 실무에서 쓰다 보면 세션마다 반복되는 낭비를 발견하게 된다. AI가 OS 환경, 패키지 버전, 쉘 종류를 매번 추측하면서 토큰을 소진한다. 이 문제를 해결하려고 개발자가 직접 MCP 서버를 만들었다. 'preflight'라 이름 붙인 이 도구는 두 파트로 구성된다. 머신 환경을 스캔해 스냅샷을 저장하는 감지 스크립트와, Claude Code가 세션 시작 시 호출할 수 있는 MCP 서버다. 이 구조 덕분에 Claude는 OS·쉘·패키지 버전·CDN 속도까지 추측 없이 즉시 파악한다. 콜당 토큰 비용은 약 400개—추측 실패로 낭비되는 수천 토큰과 비교하면 압도적으로 효율적이다.
요점은 도구 자체가 아니라 컨텍스트 설계다. AI가 매 세션마다 같은 실수를 반복하도록 두는 것은 팀 워크플로우 설계 실패다.
스킬이 40개가 넘으면 에이전트는 오히려 방해가 된다
세 번째 문제는 스킬 비대화다. dev.to에서 공유된 사례('How I manage 40+ skills across Claude Code, Codex, and .agents folders')는 이것을 정직하게 보여준다. 처음엔 세 개였던 스킬이 1년 만에 마흔 개를 넘었다. 그 결과, 개인 이메일 작성을 요청했더니 회사 이메일 템플릿 스킬을 추천받고, 개인 SQLite 프로젝트에서 회사 DB 스키마 문서가 튀어나왔다. 에이전트가 틀린 게 아니다. 모든 스킬을 보고 있었기 때문에 맥락상 가능한 선택을 한 것이다.
이 문제를 해결하기 위해 개발된 CLI가 Skillmux다. 핵심 모델은 단순하다. 스킬을 파일로 관리하는 게 아니라 프로필 단위로 묶는다. work, personal, research, frontend 같은 프로필을 만들고, 활성 프로필에 해당하는 스킬만 에이전트에 노출한다. skillmux use research를 실행하면 Claude Code, Codex, .agents 폴더가 동시에 research 프로필로 전환된다. 에이전트는 그 컨텍스트에 맞는 스킬만 본다.
시사점: 도구 추가 전에 설계부터
세 가지 사례가 공통으로 가리키는 것은 하나다. AI 도구는 쌓는 게 아니라 정제해야 한다. 도구 수를 늘리기 전에 먼저 물어야 할 질문들이 있다.
- CI/CD 파이프라인에 자동화 테스트와 점진적 배포가 붙어 있는가?
- 코딩 표준, ADR, 서비스 템플릿 같은 가드레일이 에이전트에게도 적용되는가?
- AI 세션마다 반복되는 컨텍스트 추측 비용을 사전에 제거했는가?
- 에이전트에 노출되는 스킬이 현재 작업 컨텍스트에 맞게 필터링되어 있는가?
이 질문들에 '아니오'가 많을수록, AI 도구를 더 붙이는 것은 팀의 혼란을 더 빠르게 증폭시킬 뿐이다.
전망: AI-First 팀 리빌딩의 진짜 순서
AI 코딩 도구 도입의 ROI를 제대로 뽑으려면 순서가 있다. 도구 도입 → 워크플로우 설계 → 가드레일 구축이 아니라, 가드레일 구축 → 컨텍스트 설계 → 도구 도입 순이어야 한다. DORA 보고서가 말하는 '고성과 조직'이란 AI를 가장 먼저 도입한 조직이 아니라, 기반에 먼저 투자한 조직이다.
AI 도구는 내일도 더 빨라질 것이다. 그 속도를 팀 전체의 가치 전달 속도로 전환하는 것은 도구가 아니라 조직 설계의 몫이다. preflight가 토큰 낭비를 없애고 Skillmux가 스킬 비대화를 막는 것처럼, 팀 레벨에서도 'AI가 올바른 맥락에서 올바른 방향으로 움직이도록' 설계하는 것이 테크 리드의 진짜 일이다.