AI 코딩 도구는 도입 순간이 아니라 설계 순간에 작동한다
AI 코딩 도구를 도입했다고 해서 팀 생산성이 자동으로 올라가지 않는다. 오히려 잘못 도입하면 코드 품질이 떨어지고, 보안 취약점이 증가하며, 주니어 개발자의 성장이 멈춘다. 최근 공개된 세 편의 실증 사례는 이 문제를 각기 다른 각도에서 정확히 짚는다. 공통된 결론은 하나다. 언제, 어떻게, 무엇을 AI에 맡길지를 팀 단위로 설계해야 한다.
GitHub Copilot을 30일 끊었더니 코드 품질이 올라갔다
dev.to에 올라온 Gerus-lab 팀의 실험은 불편한 진실을 직접 보여준다. 14개 이상의 제품을 출시한 이 팀은 AI 자동화에 적극적이었지만, DeFi 앱 스테이징에 AI 생성 버그 세 개가 올라간 사건을 계기로 30일간 GitHub Copilot을 전면 금지했다.
결과는 예상을 뒤집었다. 첫 주는 고통스러웠지만, 2주차부터 아키텍처 문제를 더 일찍 발견하기 시작했다. 코드 리뷰에서 실제로 코드를 읽게 됐고, 그 과정에서 API에 숨어 있던 IDOR(Insecure Direct Object Reference) 취약점 세 건을 잡아냈다. 주니어 개발자들은 AI 없이 직접 찾아보고 고민하는 과정에서 두 달 후 눈에 띄게 성장했다. 출시 기능 수는 줄었지만 재작업은 거의 없었다.
이 팀이 내린 결론은 Copilot을 버리는 것이 아니었다. 재도입할 때는 규칙을 설계했다. 비즈니스 로직과 보안 코드는 AI 제안 없이 수작업으로 작성한다. 인증·결제·암호화 모듈은 AI 프리존으로 지정한다. AI 비중이 높은 PR은 리뷰 시간을 두 배로 잡는다. "AI가 생성했으니 괜찮겠지"라는 심리적 지름길을 팀 프로세스로 차단한 것이다.
같은 실수를 세 번 반복한 뒤 찾아낸 Claude Code 확장성 원칙
도구를 잘못 선택하는 문제는 Claude Code에서도 똑같이 나타난다. dev.to의 또 다른 실험 사례는 Claude Code의 세 가지 확장 메커니즘—Skill, Subagent, MCP 서버—을 잘못 골랐을 때 어떤 일이 벌어지는지를 직접 보여준다.
첫 번째 실수: 코드 리뷰 체크리스트를 제공하려고 Rust로 MCP 서버를 40시간 만들었는데, 마크다운 파일 하나로 10분 만에 동일한 결과를 낼 수 있었다. 두 번째 실수: 데이터베이스 분석을 위해 Skill을 만들었지만, Skill은 외부 시스템에 실제로 연결할 수 없다. 세 번째 실수: 코드 리뷰·디버깅·배포 체크를 하나의 Opus 세션에서 처리했더니 비용이 폭발하고 리뷰 품질도 오히려 떨어졌다.
이 경험에서 도출한 의사결정 트리는 단순하다. 외부 시스템에 연결이 필요하면 MCP 서버. Claude의 동작 방식 자체를 특정 작업에 맞게 바꾸고 싶으면 Subagent. 재사용 가능한 지식·컨벤션·워크플로우를 주입하고 싶으면 Skill. 세 가지 메커니즘은 용도가 겹치지 않는다. 겹쳐 보이는 순간 설계가 잘못된 것이다.
팀 컨벤션을 코드가 아닌 스킬로 구워 넣기
세 번째 사례는 한 발 더 나아간다. Claude Code Skill을 실제 팀 워크플로우에 연결하는 다섯 가지 패턴을 구체적으로 제시한다. /fix-issue 42를 입력하면 GitHub 이슈를 읽고 코드를 수정하고 PR까지 올린다. /security-review는 읽기 전용 툴만 허용한 격리된 컨텍스트에서 실행되어 코드 수정 없이 보안 감사만 수행한다. /pr-summary는 실행 시점에 gh pr diff 결과를 실시간으로 주입해 환각 없이 실제 PR 데이터를 요약한다.
특히 주목할 패턴은 user-invocable: false로 설정한 컨벤션 Skill이다. 팀의 REST API 설계 규칙을 마크다운으로 정의해두면, Claude가 API 관련 작업을 감지할 때 자동으로 로드해 적용한다. 개발자가 명시적으로 호출하지 않아도 팀 컨벤션이 자동 적용된다. 코드 리뷰 코멘트로 반복 지적하던 것들을 Skill 파일 한 장으로 해결하는 방식이다.
세 사례가 공통으로 가리키는 것
세 실험의 교차점은 명확하다. AI 코딩 도구의 문제는 도구 자체가 아니라 도구 주변 워크플로우의 부재에 있다.
GitHub Copilot 실험이 보여준 것: AI가 생성한 코드는 형식적으로 완벽해 보이기 때문에 리뷰어의 인지적 경계심이 낮아진다. 이 심리적 허점을 막으려면 '어느 영역에 AI를 쓰지 않을 것인가'를 팀이 명시적으로 설계해야 한다.
Claude Code 확장성 트라이앵글이 보여준 것: 도구가 제공하는 메커니즘을 올바르게 이해하지 못하면, 같은 결과를 얻는 데 40배의 비용을 쓰는 일이 벌어진다. 팀이 공유하는 구조 이해가 선행되어야 한다.
커스텀 스킬이 보여준 것: 팀의 암묵적 컨벤션—리뷰 기준, 커밋 형식, API 설계 규칙—을 버전 관리 가능한 Skill 파일로 명문화하면, 팀원 교체와 온보딩 비용이 구조적으로 줄어든다.
AI-First 팀 리빌딩 관점에서 당장 해볼 것
이론 말고 내일 팀에 바로 적용할 수 있는 세 가지를 꼽는다면:
첫째, AI 프리존을 팀 문서에 명시한다. 인증, 결제, 암호화, 핵심 비즈니스 로직 중 어느 영역에 AI 자동완성을 허용하지 않을지 목록을 만들어 PR 체크리스트에 붙인다.
둘째, Claude Code를 쓴다면 Skill부터 시작한다. 팀 코드 리뷰 기준, 커밋 컨벤션, API 설계 규칙을 마크다운으로 .claude/skills/에 작성한다. MCP 서버를 만들기 전에 Skill로 해결되는지 먼저 확인한다.
셋째, AI 비중이 높은 PR에는 리뷰 시간을 두 배로 책정한다. 코드가 깔끔해 보일수록 더 꼼꼼히 읽어야 한다. AI가 생성한 SQL 인젝션 취약점은 포맷이 완벽하기 때문에 더 위험하다.
전망: 설계 능력이 AI 도구 활용 능력을 결정한다
'AI 10배 생산성' 담론은 계속될 것이다. 하지만 현장에서 실제로 차이를 만드는 것은 더 좋은 AI 도구를 쓰는 팀이 아니라, 도구를 둘러싼 워크플로우를 더 잘 설계하는 팀이다.
AI 코딩 도구는 타이핑 속도를 높이는 데 탁월하다. 하지만 소프트웨어 개발의 병목은 타이핑이 아니다. 문제를 올바르게 이해하는 것, 아키텍처를 잘 결정하는 것, 엣지 케이스와 보안 이슈를 잡는 것—이것들은 여전히 사람의 설계 능력이 결정한다. AI-First 팀 리빌딩의 진짜 과제는 AI 도구를 더 많이 쓰는 것이 아니라, AI가 잘하는 영역과 사람이 반드시 해야 하는 영역의 경계를 팀 전체가 동일하게 이해하고 실행하게 만드는 것이다.