AI가 개발 생산성을 '곱셈'한다는 주장은 틀리지 않는다. 애니메이션 라이브러리 Motion의 개발자 Matt Perry는 AI를 본격 활용한 분기에 목표 이슈 60개를 넘어 160개를 종료했고, 대규모 리팩터링을 '1월 어느 오후' 한 번에 마쳤다. 수학자들은 ChatGPT와 협업해 혼자 했을 때보다 10배 빠르게 증명을 완성했다고 말한다. 숫자만 보면 반론이 어렵다.
그런데 이 곱셈 공식에는 눈에 잘 안 띄는 전제 조건이 하나 있다. 피승수가 0이면 곱셈 결과도 0이다. 기존 역량이 없는 상태에서 AI를 붙여봐야 속도만 빠른 엉망이 나온다는 뜻이다. vibe-coding 커뮤니티에서 MVP 이후 단계에서 막히는 사례가 반복되는 이유도 같다. 아키텍처 판단력과 도메인 지식 없이 프롬프트만 던지면, LLM은 개별 요청을 해결하는 코드를 열심히 생성하다가 전체 구조를 막다른 길로 몰고 간다.
더 직접적인 사례가 있다. 개발자 Sergii Khomenko는 Rails용 LLM 비용 추적 gem을 거의 전부 LLM으로 작성해 배포했다. 결과는 커뮤니티 피드백으로 빠르게 드러났다. activesupport와 activerecord를 하드 의존성으로 선언해 놓고, 코드 내부에서는 두 라이브러리의 존재 여부를 런타임에 체크하는 방어 로직이 삽입돼 있었다. 없으면 실행 자체가 불가능한 것들을 없을 수도 있다고 가정하고 지키는 코드—이런 '편집증 모드'는 사람이 의도적으로 짜지 않는다. 모델이 그럴싸하게 생성했고, 작성자가 읽지 않고 배포했기 때문에 통과된 것이다. 그가 나중에 스스로 내린 결론은 냉정하다. "코드를 쓰는 비용은 싸졌다. 그 코드에 책임지는 비용은 싸지지 않았다."
보안 레이어에서도 같은 구조가 반복된다. RepoSignal이 React 저장소를 스캔한 결과는 흥미롭다. GitHub 별 22만 개, Facebook 엔지니어링 팀 주도, 수천 명의 기여자가 리뷰하는 코드베이스에서 24초 만에 고위험도 16건을 포함한 20개 패턴이 탐지됐다. eval()을 통한 동적 코드 실행, 크리덴셜 노출 가능성, 트러스트 바운더리 위반. React 팀을 비난하려는 게 아니다. 핵심은 인간 리뷰어와 자동화 스캐너가 서로 다른 것을 본다는 점이다. 사람은 아키텍처, 로직, 성능에 최적화돼 있다. 40만 줄에 걸친 eval() 호출을 매 커밋마다 체계적으로 열거하는 작업은 자동화 도구의 영역이다. AI가 코드를 빠르게 쌓는 환경에서는 이 두 영역이 더 선명하게 분리된다.
세 사례는 한 가지 물음으로 수렴된다. AI가 코드를 빠르게 생성할수록, 팀에 요구되는 판단 역량은 무엇인가? 테크 리드 관점에서 이 질문을 팀 설계 문제로 바꾸면 세 가지 축이 나온다.
첫째, 리뷰 기준을 생성 속도에 맞게 끌어올려야 한다. Khomenko가 말한 것처럼, 리뷰 바는 코드가 나타나는 속도에 맞춰 올라가야 한다. AI가 diff를 빠르게 만들수록, 그 diff를 검토하는 사람의 눈이 더 날카로워야 한다. '설명할 수 없는 코드는 커밋하지 않는다'는 원칙은 실천 단위로 팀에 명문화할 가치가 있다.
둘째, 자동화 스캔은 리뷰의 경쟁자가 아니라 전제 조건이다. 인간 리뷰어가 컨텍스트와 비즈니스 로직을 판단한다면, 정적 스캐너는 패턴 공간을 체계적으로 커버한다. AI 보조 개발 환경에서 코드 생성 속도가 빨라질수록 스캐너 없이는 패턴 누락이 기하급수적으로 늘어난다. PR 레벨 자동화 스캔은 선택이 아니라 파이프라인 기본값이 돼야 한다.
셋째, AI 효과의 크기는 사용자의 판단 구조가 결정한다. Matt Perry와 vibe-coder의 결과 차이는 도구가 아니라 '아키텍처가 어떻게 보여야 하는지에 대한 스킬 템플릿'에서 갈린다. HN 댓글에서 한 개발자가 정확히 짚었다. "여기서 필요한 능력은 좋은 아키텍처가 무엇인지 알고, 프롬프트와 검증을 설계하는 능력이다." 이것이 AI-First 팀에서 온보딩과 역량 평가의 기준이 돼야 하는 이유다.
한 가지 경고도 붙여야 한다. 커뮤니티 토론에서 등장한 비유 하나가 마음에 걸린다. "지금은 Iron Man 슈트지만, 기업이 충분히 오래 버티면 그 지식이 완전히 사라지고 도구만 남는다. 그때는 Iron Man이 아니라 iron lung에 가까워진다." AI가 판단의 근거 자체를 대체하기 시작할 때 곱셈의 피승수는 조용히 0을 향해 이동한다. 빠르게 생성하되, 생성된 것을 판단하는 역량의 근육은 팀 전체에서 유지해야 한다.
AI 곱셈 효과는 실재한다. 그러나 그 공식이 성립하려면 두 가지가 팀 운영 설계 안에 명시적으로 들어가야 한다. 하나는 속도에 맞게 설계된 검증 루프, 다른 하나는 판단 역량을 팀 전체에서 유지하는 구조. 이 두 가지가 없으면 AI는 역량을 곱하는 게 아니라 문제를 곱한다.