AI 도구는 샀는데, 왜 배포는 여전히 느린가
Cursor 라이선스도 있고, Claude Code도 깔았다. GitHub Copilot은 기본이다. 그런데 스프린트 속도는 그대로다. 팀원들은 "AI가 코드를 짜준다"고 하는데, 정작 PR은 쌓이고 디버깅 시간은 줄지 않는다. 이게 지금 AI-First를 선언한 팀 대부분이 마주한 현실이다.
Vibe Coding의 실체: 설계 30분, 디버깅 5시간
최근 GeekNews에 올라온 한 개발자의 Vibe Coding 실전 기록이 이 문제를 정직하게 드러낸다. Cloudflare Web Analytics, GoatCounter, Analytics Engine 세 개의 데이터소스를 하나의 대시보드로 통합하는 작업을 Claude Code로 진행했는데, 상세 프롬프트와 plan mode로 초기 구현까지는 매끄러웠다. 문제는 그다음이었다.
작업 시간 6시간, 총 커밋 35회 이상. 그 70%는 디버깅이었다. Astro scoped CSS가 동적 콘텐츠에 적용되지 않는 문제, GoatCounter API의 미문서화 파라미터 탐색, Cloudflare GraphQL의 노드별 시간 범위 제한—9개 이슈를 14커밋에 걸쳐 수정했다. 결론은 명확했다. "AI에게 알아서 해줘"로는 원하는 품질이 나오지 않는다. 사람이 청사진을 설계하고, AI가 구현하고, 다시 사람이 확인하며 고치는 반복이 Vibe Coding의 실체다.
도구 문제가 아니라 조율 문제다
dev.to에 올라온 「Why Your AI Agents Need a Tech Lead」는 이 현상의 구조적 원인을 정확히 짚는다. 좋은 테크 리드가 실제로 하는 일을 분해해보면 다섯 단계다: ① 코드베이스 파악, ② 모호한 요구사항을 구체적 티켓으로 변환, ③ 누가 무엇을 할지 결정, ④ 올라온 diff 리뷰, ⑤ 머지 혹은 피드백 반환.
AI 에이전트는 티켓이 잘 작성돼 있을 때 ④번은 잘한다. 그런데 ①②③은 못하고, ⑤번은 아예 불가능하다—자신이 쓰지 않은 코드의 맥락을 모르기 때문이다. 결국 개발자가 프롬프트를 칠 때마다 ①②③을 수동으로 수행하고 있는 셈이다. 이것이 병목이다. 에이전트가 빠르게 코드를 생성해도, 그 앞뒤를 사람이 매번 채워야 한다면 전체 처리량은 늘지 않는다.
데이터가 말하는 불편한 진실
dev.to의 「The Skill AI Adoption Actually Requires: Leadership」은 여기에 데이터를 얹는다. METR의 2025년 연구에서 경험 많은 오픈소스 개발자들이 AI 도구를 사용할 때 평균 19% 더 느렸다—본인들은 20% 빠르다고 믿으면서. 4.2백만 명 개발자 데이터를 분석한 DX 리포트(2026년 2월)는 더 냉정하다. AI 코딩 어시스턴트 사용률은 92.6%, 프로덕션 코드의 27%가 이미 AI 작성이지만, 측정 가능한 생산성 향상은 고작 10%다. 이유는 단순하다. 개발자가 실제로 코딩에 쓰는 시간은 전체의 20~40%뿐이다. 나머지는 문제 분석, 커뮤니케이션, 리뷰다. 코딩 속도만 높이면 전체 속도는 조금밖에 안 오른다.
신뢰 문제도 겹친다. Stack Overflow 개발자 설문(2025, 49,000명 이상)에서 AI 결과물을 적극적으로 불신하는 개발자(46%)가 신뢰하는 개발자(33%)보다 많았다. 45%는 AI 생성 코드를 디버깅하는 게 직접 짜는 것보다 더 오래 걸린다고 답했다.
진짜 문제는 기술이 아니라 위임 역량이다
세 기사가 공통적으로 가리키는 지점은 하나다. AI 도입의 핵심 역량은 LLM 선택이나 프롬프트 스킬이 아니라 위임과 조율의 리더십이다. 팀원에게 일을 맡길 때처럼, AI 에이전트에게도 맥락·범위·완료 기준을 명확히 정의해야 한다. "어떤 아키텍처 결정이 적용되는가, 무엇은 건드리면 안 되는가"—이걸 에이전트에게 주지 않으면 컴파일은 되지만 시스템을 깨는 코드가 나온다.
Daniel Sogl(Thinktecture AG)은 이 역량 전환을 세 축으로 정리한다. 첫째, 쓰는 것에서 지시하는 것으로—에이전트는 판단력이 부족한 주니어 개발자다, 자율에 맡기되 복잡한 상황에서의 오판을 걸러야 한다. 둘째, 맹목적 신뢰도 맹목적 불신도 아닌 교정된 신뢰—Google DeepMind 연구가 지적하듯, AI가 너무 많은 작업을 가져가면 인간은 개입 능력 자체를 잃는다. 구조적 체크포인트가 필요하다. 셋째, 실패 문화 정착—DX 데이터에 따르면 AI 거버넌스가 탄탄한 조직은 고객 대면 인시던트가 50% 적다. 거버넌스는 관료주의가 아니라 에이전트를 힘의 배수기로 만드는 설계다.
테크 리드의 역할이 바뀌는 방향
여기서 팀 리드가 내릴 수 있는 실용적 결론은 이렇다. AI-First 워크플로우에서 테크 리드의 가치는 '더 빠른 구현자'에서 '더 명확한 정의자'로 이동한다. 요구사항을 에이전트가 오해 없이 실행할 수 있도록 구조화하고, 생성된 diff에서 기술적으로는 작동하지만 시스템 맥락상 틀린 것을 잡아내는 일이 핵심이다. 이건 코딩 속도보다 훨씬 희소한 역량이다.
자동화 테스트는 이 구조 안에서 단순한 품질 도구가 아니라 에이전트에게 '완료'의 의미를 전달하는 언어가 된다. 테스트를 작업 후 검증이 아니라 작업 전 브리핑으로 설계해야 하는 이유다. Stanford Perry et al.(2023) 연구에서 AI 어시스턴트를 쓴 개발자가 더 취약한 코드를 작성하면서도 본인은 안전하다고 믿었다는 결과는, 자동화 테스트 없이 에이전트에게 자율권을 주는 것이 얼마나 위험한지를 명확히 보여준다.
전망: 모델이 좋아질수록 '설계 격차'는 더 벌어진다
LLM 코딩 품질은 계속 오른다. 컨텍스트 윈도우는 이미 충분히 커졌다. 문제는 "AI가 코드를 쓸 수 있냐"에서 "AI가 이미 있는 시스템을 이해하고 올바른 위치에 올바른 코드를 쓸 수 있냐"로 이동했다. 이건 LLM 문제가 아니라 아키텍처 문제, 그리고 그 아키텍처를 에이전트에게 전달하는 사람의 문제다.
모델이 좋아질수록 위임을 잘하는 팀과 못하는 팀의 격차는 오히려 커진다. 에이전트 성능이 올라가면 잘못된 지시의 결과물도 더 정교하게, 더 빠르게 쌓이기 때문이다. AI-First 팀 리빌딩에서 지금 당장 투자해야 할 역량은 새 도구 도입이 아니라, 팀 전체의 '명확하게 위임하는 능력'이다.