AI 코딩 도구를 팀에 퍼뜨리려고 했다 — 3개월 시도의 솔직한 기록

도입

올해 2월, 팀장에게 이런 말을 했습니다.

"Claude Code 한 달만 써보게 해주시면 생산성 지표를 측정해볼게요."

팀장은 "해봐"라고 했습니다. 그때부터 3개월짜리 실험이 시작됐습니다. 결론부터 말하면: 성공도 실패도 아닌, 예상과 전혀 다른 방향으로 끝났습니다.

1. 시작 — "나는 효과 봤으니 팀도 되겠지"

제가 먼저 Claude Code를 4~5개월 혼자 써본 뒤에 팀 도입을 제안했습니다. 혼자 쓸 때는 분명히 빨라졌습니다. 반복 작업, 에러 디버깅, 문서화에서 시간이 많이 줄었습니다.

팀도 당연히 그렇게 될 거라고 생각했습니다. 그 생각이 순진했습니다.

도입 대상은 저 포함 5명이었습니다. 백엔드 2명(김 선임, 박 주임), 프론트엔드 1명(이 대리), 풀스택 1명(최 주임). 팀원들 경력은 3~8년 사이입니다.

처음에 제가 잘못 판단한 게 있었습니다. 숙련된 개발자들은 이미 자기만의 방식과 속도가 있습니다. AI 도구가 "빠르게 시작"을 도와주는 건 분명하지만, 이미 빠른 사람한테 그 이점이 내 경우만큼 크지 않을 수도 있다는 걸 몰랐습니다.

2. 첫 달 — 저항과 시큰둥한 반응

2월 둘째 주에 팀 내부 세션을 열었습니다. 제가 실제로 쓰는 방식을 라이브로 보여줬습니다. 스택 트레이스 붙여넣고 해결책 받아오기, 단위 테스트 자동 생성, API 문서 초안 잡기.

반응은 크게 셋으로 나뉘었습니다.

관심 있는 쪽(최 주임, 이 대리): "오, 이거 저한테도 써볼게요." 바로 Pro 구독 신청을 했습니다.

실용적으로 보는 쪽(박 주임): "그냥 코파일럿 쓰면 안 돼요? 이미 쓰고 있는데." 전환 유인이 없었습니다.

회의적인 쪽(김 선임): "결과물 검증을 내가 다 해야 하는데 그러면 더 오래 걸리는 거 아닌가요?" 이 말이 나중에 제일 날카로운 지적이었습니다.

첫 달엔 팀원 5명 중 실제로 정기적으로 쓴 사람이 2명이었습니다.

3. 두 번째 달 — 예상 못 한 변수들

3월에 들어서면서 재미있는 일이 생겼습니다.

좋은 방향: 이 대리가 혼자서 프론트엔드 컴포넌트 작성 속도가 올라갔습니다. 이전엔 UI 컴포넌트 하나에 2~3시간 잡던 게, Claude Code로 초안 잡고 수정하는 방식으로 1시간 안에 끝내는 경우가 늘었습니다. "이게 진짜 쓸 만하네요"라는 말을 들었을 때 뿌듯했습니다.

안 좋은 방향: 최 주임은 2주 쓰다가 사실상 안 쓰게 됐습니다. 이유를 물어보니 "세션 새로 시작할 때마다 설명을 다시 해야 하는 게 너무 번거롭다"고 했습니다. 여러 기능을 동시에 진행하는 타입인데, 컨텍스트 관리가 맞지 않았던 것 같습니다.

김 선임의 우려가 실제로 나타나기도 했습니다. 한번은 후배가 Claude Code로 만든 코드를 리뷰해야 했는데, 코드 자체는 작동하지만 우리 아키텍처 패턴과 맞지 않아서 수정 요청이 왔습니다. "차라리 처음부터 짰으면 더 빨랐겠다"는 말이 나왔습니다.

이게 진짜 변수였습니다. 팀에서 쓰려면 팀 공통 컨텍스트(아키텍처, 코딩 컨벤션, 패턴)를 AI에게 어떻게 전달할지가 핵심인데, 개인 사용보다 훨씬 복잡한 문제입니다.

4. 세 번째 달 — 방향을 바꿨습니다

4월부터는 접근 방식을 바꿨습니다.

"팀 전체가 다 써야 한다"는 목표를 포기했습니다. 대신 "쓸 사람이 잘 쓸 수 있도록" 방향을 바꿨습니다.

이 대리와 저, 두 명이 적극적으로 활용하기로 했습니다. 그리고 팀 공통 컨텍스트 파일을 하나 만들었습니다. 우리 프로젝트의 아키텍처, 주요 패턴, 쓰지 말아야 할 패턴을 정리한 텍스트 파일. 세션 시작할 때 이걸 붙여넣는 방식으로 표준화했습니다.

이걸 만들고 나서부터는 결과물 품질이 훨씬 안정됐습니다. 김 선임도 "이 방식이라면 리뷰 부담이 줄어든다"고 했습니다.

5. 3개월 후 — 솔직한 결산

처음 목표: 팀 5명이 모두 Claude Code를 정기적으로 사용한다.

실제 결과: 2명이 정기 사용, 1명이 간헐적 사용, 2명은 기존 도구 유지.

수치로 보면 "실패"처럼 보입니다. 그런데 그 2명의 변화가 팀 전체에 생각보다 큰 영향을 줬습니다. 이 대리가 프론트엔드 속도가 올라가면서 프론트-백엔드 연결 작업이 더 빠르게 돌아갔습니다. 제가 문서화에 쓰는 시간이 줄면서 다른 작업에 더 시간을 쓸 수 있었습니다.

팀 단위 도입을 고민한다면 이걸 먼저 받아들이는 게 중요한 것 같습니다. 모두가 같은 방식으로 쓰는 게 목표가 아니라, 각자에게 맞는 방식으로 쓰는 것이 실용적인 목표입니다.

팀 도입을 고민한다면

팀 컨텍스트 파일부터 만드세요: 아키텍처, 코딩 컨벤션, 자주 쓰는 패턴을 텍스트로 정리하고, 세션 시작할 때 붙여넣는 게 팀 사용의 핵심입니다. 이게 없으면 결과물이 팀 스타일과 달라서 리뷰 비용이 올라갑니다.

강제하지 마세요: 경험상 도구는 자발적으로 쓸 때 효과가 납니다. 쓰고 싶은 사람이 잘 쓸 수 있게 지원하는 방식이 "모두 써야 한다" 방식보다 팀 전체 관점에서 낫습니다.

효과를 보는 유형이 있습니다: 시작이 막막한 작업, 반복 패턴이 많은 작업, 문서화·주석이 밀려 있는 사람에게 특히 잘 맞습니다. 이미 자기 속도와 방식이 완성된 숙련자에게는 효과가 더 제한적일 수 있습니다.

자주 묻는 질문

Q. 팀에 AI 코딩 도구 도입할 때 가장 큰 장벽이 뭔가요?
제 경험상 두 가지였습니다. 첫 번째는 기존 도구와의 비교 관성("코파일럿이 이미 있는데"), 두 번째는 컨텍스트 관리 비용("세션마다 설명해야 한다"). 팀 컨텍스트 파일로 두 번째는 어느 정도 해결할 수 있었습니다.

Q. 비용은 팀이 부담하나요, 개인이 부담하나요?
저희 경우엔 개인이 직접 구독했습니다. 팀장이 "써보고 효과 있으면 회사 비용으로 전환하자"고 했는데, 3개월 후에도 팀 전체가 쓰는 구조가 아니어서 아직 개인 구독 상태입니다.

이 글은 2026년 8월 기준 개인 경험을 바탕으로 작성되었습니다. 팀 규모, 업무 성격, 기존 도구 환경에 따라 경험이 크게 다를 수 있습니다.

— 텍드(TechDrift)