AI가 드러낸 불편한 진실
AI 코딩 도구를 도입하고 나서 팀이 갑자기 요구사항을 명확히 쓰기 시작했다면, 문서를 제대로 남기기 시작했다면, 작업을 잘게 쪼개기 시작했다면—그건 AI 덕분이 아니다. AI가 그 필요성을 눈에 보이게 만들었을 뿐이다.
dev.to에 게재된 Ollie Church의 분석은 이 지점을 정확히 찌른다. 좋은 엔지니어링 관행—명확한 요구사항, 사전 설계, 작은 단위 태스크 분해, 의사결정 문서화—은 AI 이전에도 항상 옳았다. 문제는 피드백 루프가 너무 느렸다는 것이다. 요구사항을 잘 쓴 개발자가 더 나은 코드를 냈다는 사실은 몇 주가 지나야 드러났고, 그 사이 수많은 변수가 끼어들었다. 경영진은 인과관계를 연결하지 못했다.
AI는 그 피드백 루프를 몇 분으로 압축했다. 뭉툭한 요구사항을 주면 뭉툭한 코드가 나온다. 구조화된 스펙을 주면 쓸 만한 결과물이 나온다. 인과관계가 즉각적이고 반복 가능하다. 관행의 가치가 처음으로 측정 가능해진 것이다. AWS Kiro가 '스펙 주도 개발(spec-driven development)'—요구사항 파악, 설계, 태스크 목록 작성, 그 다음 코딩—을 전면에 내세운 것도 이 맥락이다. 오랫동안 좋은 팀이 해오던 방식이 AI 워크플로우에서 그대로 증명됐다.
수치가 말하는 것: 10%와 50% 사이
하지만 이제 냉정하게 숫자를 봐야 한다. LinkedIn에서 흔히 보이는 '생산성 40~80% 향상' 주장은 연구 데이터와 거리가 있다.
METR의 2025년 중반 연구에서 숙련 개발자들은 AI를 사용했을 때 오히려 작업 완료 시간이 19% 더 걸렸다. 본인들은 20% 빨라졌다고 느꼈는데도. DX의 Laura Tacho가 2026년 2월 Pragmatic Summit에서 발표한 연구는 더 넓은 범위를 다뤘다. 450개 이상 기업, 12만 1천 명의 개발자를 대상으로 한 조사에서 AI로 인한 실측 생산성 향상은 약 10%였다. 체감과 측정의 괴리가 크다.
그런데 더 중요한 숫자가 있다. 같은 연구에서 67,000명의 개발자를 심층 분석한 결과, 결과가 극단적으로 갈렸다. 일부 조직은 고객 대면 인시던트가 50% 감소했고, 다른 조직은 오히려 두 배로 늘었다. 차이를 만든 건 AI 도구가 아니었다. 조직의 구조와 관행이었다. Tacho의 표현을 빌리면: 'AI는 조직의 근본적인 문제를 해결해주지 않는다. 먼저 그 문제를 직접 다뤄야 한다.' 잘 돌아가는 팀에서 AI는 승수 효과를 냈고, 이미 무너져 있던 팀에서 AI는 기존 문제를 가속시켰다.
Anthropic의 연구는 또 다른 리스크를 지적한다. 주니어 개발자 대상 통제 실험에서 AI를 사용한 그룹은 작업을 더 빨리 완료했지만, 코드 이해도가 17% 낮았다. 자신이 무엇을 만들었는지 모른 채 코드를 배포한 것이다. 이해도를 유지한 개발자들은 AI를 생성 도구가 아니라 학습 도구로 사용한 이들이었다.
Jazzband 종료가 주는 경고
이론이 아니라 실제로 AI 관행 부재가 조직을 어떻게 망가뜨리는지 보여주는 사례가 나왔다. pip-tools, tablib, django-auditlog 등을 공동 관리하던 파이썬 오픈소스 커뮤니티 Jazzband가 2026년 말까지 단계적으로 운영을 종료한다.
직접적인 방아쇠는 이른바 'slopocalypse'—LLM이 생성한 저품질 PR과 이슈의 폭증이었다. '누구나 가입하면 레포에 쓸 수 있는 권한' 모델은 AI가 없던 시절에도 취약했지만, AI가 PR 제출 비용을 사실상 0에 가깝게 낮추자 그 취약성이 한순간에 터졌다. 공급망 보안 리스크가 통제 불가능한 수준이 됐다.
그러나 근본 원인은 더 오래된 곳에 있다. 2010년대 중반부터 단일 운영자에게 과도하게 집중된 구조, 자원봉사에만 의존한 거버넌스, 지속 가능성 없는 재정—AI는 이 오래된 기술 부채에 불을 붙인 것이지, 불을 만든 것이 아니다. 관행과 거버넌스가 갖춰지지 않은 상태에서 AI가 유입 속도를 높이면 어떻게 되는지를 보여주는 교과서적 사례다.
AI 도구 도입 전에 먼저 점검할 것
이 모든 데이터가 가리키는 방향은 하나다. AI 코딩 도구는 이미 잘 돌아가는 팀을 더 빠르게 만든다. 아직 작동하지 않는 팀의 문제를 고쳐주지는 않는다.
바이브 코딩 보안 체크리스트(dev.to)가 AI 생성 코드 배포 전에 하드코딩된 시크릿, 인증 로직 누락, 의존성 취약점 등을 반드시 검토하라고 명시하는 이유도 같은 맥락이다. GitClear의 2025년 연구에 따르면 AI 생성 코드는 사람이 작성한 코드보다 40% 높은 비율로 프로덕션에 반영되지만, 보안 취약점은 거의 두 배에 달한다. 속도를 신뢰로 착각하는 팀에서만 벌어지는 일이다.
팀에 AI 도구를 붙이기 전에 먼저 물어야 할 질문들이 있다.
- 요구사항이 명확한가? AI에게 줄 컨텍스트가 뭉툭하면 결과도 뭉툭하다.
- 코드 리뷰가 실제로 일어나고 있는가? AI가 PR 속도를 높이면 리뷰 부채는 기하급수적으로 쌓인다.
- 보안 게이트가 자동화되어 있는가? 사람이 검토를 건너뛸 때를 대비한 자동화 레이어가 없으면 AI는 취약점 주입 속도를 높일 뿐이다.
- 오너십 구조가 명확한가? Jazzband처럼 '누구나 접근 가능'한 구조는 AI 시대에는 유지되지 않는다.
전망: AI는 촉매, 관행이 기반
AI 코딩 도구의 생산성 효과를 부정하는 게 아니다. 실제로 속도는 빨라지고, 반복 작업의 마찰은 줄어들며, 툴링은 계속 개선되고 있다. 낙관할 이유는 충분하다.
하지만 AI는 승수다. 승수는 기반값을 증폭시킨다. 기반이 양수이면 더 커지고, 기반이 음수이면 더 작아진다. 지금 팀에서 보이는 생산성 향상이 AI 덕분이라고 100% 귀인하고 있다면, 실제로는 뒤늦게 자리잡은 좋은 관행들이 만들어낸 성과를 AI가 가져가고 있을 가능성이 높다.
AI-First 팀 리빌딩을 설계할 때 도구 스택보다 먼저 점검해야 할 것은 팀의 관행이다. 스펙 작성 문화, 코드 리뷰 프로세스, 보안 자동화, 거버넌스 구조—이것들이 자리를 잡아야 AI 도구가 그 위에서 제대로 작동한다. 순서가 바뀌면 Jazzband처럼 AI가 방아쇠를 당기는 날이 온다.