2000만 사용자, 이 숫자가 말해주는 것과 감추는 것
GitHub Copilot의 누적 사용자가 2000만 명을 넘어섰다. 이 숫자의 의미는 ‘좋은 도구’라는 광고 문구가 아니라 시장 단계의 이동에 있다. 2021년 기술 프리뷰, 2022년 유료화 시점만 해도 Copilot은 IDE 자동완성을 강화한 편의 기능으로 취급됐다. 지금은 채팅으로 코드를 설명받고, 단위 테스트 초안을 뽑고, 여러 파일을 넘나들며 작업을 수행하는 에이전트 기능까지 붙었다. 확산 속도를 끌어올린 실질 요인은 세 가지다. 개인 요금제의 낮은 진입 장벽(월 10달러 안팎), 기업용 Business·Enterprise 요금제(사용자당 월 19~39달러대)로 나뉜 계층화, 그리고 학생·인증된 오픈소스 관리자에 대한 무료·할인 정책이다. 즉 숫자는 ‘기술이 좋아져서’라기보다 ‘쓰기 시작하는 비용이 낮아져서’ 커진 측면이 크다.
그래서 도입을 검토하는 조직이 ‘누적 2000만’을 근거로 삼으면 판단을 그르친다. 누적 사용자는 활성 사용자(DAU/WAU)나 유료 유지율과 전혀 다른 지표이고, 벤더 발표치는 대개 ‘한 번이라도 설치한 사람’에 가깝다. 설치 후 첫 주에 이탈하는 사용자와 매일 커밋마다 제안을 받아쓰는 사용자를 같은 통계가 뭉뚱그린다는 뜻이다. 실무적으로 이 숫자는 도입 근거가 아니라 ‘생태계가 성숙했다’는 방증으로만 받아들이는 편이 안전하다. 플러그인, 사내 도입 사례, 트러블슈팅 자료가 충분히 쌓였는지가 초기 도입 조직이 겪는 마찰을 좌우하기 때문이다. 반대로 ‘남들이 다 쓰니 우리도’는 뒤에서 다룰 데이터·라이선스 관문을 건너뛰게 만드는 가장 흔한 실책이다.
생산성은 어디서 오르고 어디서 떨어지는가
효과를 뭉뚱그려 ‘30% 빨라진다’고 말하는 순간 오해가 시작된다. 현장 활용 사례들이 공통으로 지목하는 이득 구간은 명확히 좁다. 보일러플레이트 작성, 단위 테스트 초안, 익숙지 않은 언어·라이브러리의 문법 조회다. 패턴이 뚜렷하고 정답이 관습화된 코드일수록 제안 채택률이 높고, 이 구간에서는 타이핑·검색 시간이 눈에 띄게 준다. 문제는 반대편이다. 도메인 규칙이 얽힌 비즈니스 로직, 수십만 줄 레거시의 맥락을 읽어야 하는 수정 작업에서는 제안 정확도가 떨어지고, 그럴듯하지만 틀린 코드를 걷어내는 ‘검토 비용’이 절약분을 상쇄하거나 초과한다. Copilot이 순생산성을 깎는 경우는 도구가 나빠서가 아니라, 이 두 구간을 구분하지 않고 모든 작업에 같은 기대를 걸 때 발생한다.
그래서 효과 측정은 만족도 설문이 아니라 흐름 지표로 해야 한다. 최소 세 가지를 도입 전후로 비교하자. (1) PR 리드타임(첫 커밋부터 머지까지), (2) 코드 리뷰 반려율 — 올라가면 제안을 과신하고 있다는 신호다, (3) 특정 반복 작업(예: CRUD 엔드포인트 1개, 테스트 1세트)의 실측 소요 시간. 여기서 주니어에 대한 흔한 오해를 짚어야 한다. ‘AI가 있으니 신입도 시니어만큼 짠다’는 기대는 위험하다. 초급자는 제안을 검증할 기준선이 약해 틀린 코드를 무비판적으로 병합하기 쉽고, 그 상태가 반복되면 실력 정체와 기술 부채가 동시에 쌓인다. 대응책은 ‘금지’가 아니라 학습 장치다. 주니어에게는 생성된 코드를 그대로 커밋하지 않고 ‘왜 이렇게 나왔는지 한 줄 주석으로 설명한 뒤 커밋’하는 규칙을 두면, 도구를 학습 보조로 되돌릴 수 있다.
AT&T의 사용 제한이 드러낸 기업 도입의 진짜 관문
AT&T가 일부 직원의 Copilot 사용을 제한했다는 보도는 ‘좋은 도구는 빨리 깔수록 이득’이라는 통념을 정면으로 반박한다. 규제 산업의 대기업이 신중한 이유는 성능 불신이 아니라 통제 가능성이다. 쟁점은 세 축으로 압축된다. 첫째, 사내 소스코드가 외부 모델로 전송·학습되지 않는다는 보장이다. 기업용 요금제는 프롬프트·코드를 학습에 쓰지 않는다고 명시하지만, 조직은 ‘명시’를 계약 조항과 감사 권한으로 검증해야 한다. 개인용 저가 요금제는 데이터 처리 정책이 다를 수 있어, 개발자가 개인 계정으로 사내 코드를 붙여 넣는 순간 이 보장은 무너진다. 둘째, 생성 코드가 라이선스가 걸린 오픈소스와 유사할 때의 지식재산권 리스크다. 셋째, 누가 언제 무엇을 생성했는지 남는 감사 로그와 사용자별 권한 관리의 부재다.
계약 전에 문서로 확보할 체크포인트는 구체적이어야 한다. ① 데이터 처리·보존 위치가 자사 컴플라이언스(예: 금융·통신·공공의 데이터 국외 이전 규정)와 맞는가, ② 공개 코드와 유사한 제안을 걸러내는 ‘퍼블릭 코드 필터’를 조직 단위로 강제 적용할 수 있는가, ③ 감사 로그와 SSO 기반 계정 관리가 제공되는가, ④ 개인 계정 사용을 차단하고 조직 라이선스로만 접속하도록 정책을 걸 수 있는가다. AT&T 사례의 교훈은 ‘Copilot이 위험하다’가 아니다. 도구의 성능 검증(PoC)과 데이터·법무·보안 검토는 별개의 트랙이며, 후자를 개발팀 단독으로 통과시킬 수 없다는 점이다. 성능 PoC만 보고 전사 배포를 결정하면, 배포 후 법무·보안 반려로 롤백하는 비용이 훨씬 크다.
‘바이브 코딩’과 보안: 속도가 붙을수록 커지는 부채
보안 진영이 경고하는 이른바 ‘바이브 코딩(vibe coding)’은 AI가 뽑아 준 코드를 깊이 읽지 않고 감으로 이어 붙여 빠르게 완성하는 방식이다. AI의 위험한 특성은 ‘틀린 코드를 자신 있게 제안한다’는 데 있다. 검증 없는 입력 처리, 이미 취약하다고 알려진 암호 알고리즘, 소스에 박힌 API 키·비밀번호처럼 겉보기엔 정상 동작하지만 보안 결함이 숨은 코드가 리뷰 없이 머지되면, 개발 속도가 붙는 만큼 보안 부채도 빠르게 누적된다. 여기서 흔한 착각은 ‘리뷰어가 걸러 주겠지’다. 하지만 제안이 자연스럽고 문법이 깔끔할수록 리뷰어의 경계심은 오히려 낮아진다 — AI 생성 코드가 사람이 짠 코드보다 ‘리뷰를 덜 받는’ 역설이 생기는 지점이다.
대응은 도구 하나로 끝나지 않고 프로세스로 고정해야 한다. Microsoft가 AI 에이전트의 보안·거버넌스를 통합 관제하는 ‘Agent 365’ 같은 플랫폼을 정식 출시한 흐름은, 개별 개발자의 자율에 맡기던 통제를 조직 차원으로 끌어올리려는 방향을 보여준다. 조직이 지금 당장 걸 수 있는 규칙은 세 가지다. ① AI 생성 코드에도 사람이 짠 코드와 동일한 코드 리뷰·정적 분석(SAST)·의존성 취약점 스캔을 예외 없이 적용한다(예외를 하나라도 두면 그 경로로 부채가 샌다). ② 비밀키·개인정보가 프롬프트에 들어가지 않도록 사전 차단 가이드와 시크릿 스캐너를 붙인다. ③ 생성 코드의 책임 소재를 커밋 저자에게 명확히 귀속시켜 ‘AI가 짰으니 내 책임 아니다’를 차단한다. 6개월~2년 관점에서 Copilot류 도구의 경쟁력은 ‘더 똑똑한 제안’보다 ‘조직이 안심하고 통제·감사할 수 있는가’에서 갈릴 가능성이 크다. 도입 여부를 묻기 전에, 우리 조직이 이 세 규칙을 운영할 준비가 됐는지를 먼저 물어야 한다.
자주 묻는 질문
GitHub Copilot 무료로 쓸 수 있나요?
개인 개발자는 기능이 제한된 무료 플랜이나 유료 개인 요금제(월 10달러 안팎)를 고를 수 있고, 인증된 학생·교사·인기 오픈소스 프로젝트 관리자에게는 무료 또는 할인이 제공됩니다. 다만 회사 코드를 다룬다면 개인 무료 플랜은 부적합합니다. 데이터 학습 제외 보장과 관리·감사 기능이 포함된 Business·Enterprise 요금제(사용자당 월 19~39달러대)가 사실상 필수입니다.
내 회사 코드가 Copilot 학습에 쓰이나요?
기업용(Business·Enterprise) 요금제는 입력한 프롬프트와 코드를 모델 학습에 사용하지 않는다고 명시합니다. 위험한 구멍은 개인 계정입니다. 개발자가 개인용 저가·무료 요금제로 사내 코드를 붙여 넣으면 이 보장이 적용되지 않을 수 있으므로, 조직은 개인 계정 접속을 차단하고 조직 라이선스·SSO로만 쓰도록 정책을 걸어야 합니다.
Copilot이 만든 코드가 저작권 문제를 일으킬 수 있나요?
가능성이 있습니다. 생성 코드가 기존 오픈소스와 유사할 경우 라이선스 충돌이 생길 수 있어, 기업용에는 공개 코드와 유사한 제안을 차단하는 퍼블릭 코드 필터가 제공됩니다. 이 필터를 조직 단위로 강제 적용하고, 최종 코드는 반드시 사람이 검토·귀속하는 절차를 함께 두는 것이 안전합니다.
AI 코딩 도구를 쓰면 정말 개발이 빨라지나요?
작업 종류에 따라 정반대입니다. 보일러플레이트, 단위 테스트 초안, 익숙지 않은 문법 조회 같은 반복·패턴 작업에서는 체감 효과가 큽니다. 반면 복잡한 도메인 로직이나 대규모 레거시 맥락이 필요한 작업에서는 틀린 제안을 걷어내느라 오히려 시간이 더 들 수 있습니다. PR 리드타임과 리뷰 반려율을 도입 전후로 비교해 구간별로 판단하세요.
주니어 개발자에게 Copilot을 권해도 될까요?
금지보다 조건부 사용이 낫습니다. 초급자는 제안을 검증할 기준선이 약해 틀린 코드를 그대로 병합하기 쉽고, 반복되면 실력 정체와 기술 부채가 함께 쌓입니다. 생성 코드를 그대로 커밋하지 않고 ‘왜 이렇게 나왔는지 설명한 뒤 커밋’하게 하는 규칙을 두면 도구를 학습 보조로 되돌릴 수 있습니다.