AI 코딩 가속이 팀 전체를 균일하게 빠르게 한다는 가정이 틀렸습니다.

Andrew Ng은 올해 AI 코딩 도구의 가속 효과가 영역별로 다르게 나타난다고 명시했습니다. 그의 관찰은 간결합니다. frontend > backend > infra > research 순서로 가속 효과가 점점 줄어든다는 것.

이 한 줄이 PM에게 던지는 질문은 단순하지 않습니다.

왜 가속 효과가 같지 않은가

프런트엔드 엔지니어가 Cursor나 Claude Code를 쓰면 즉각적인 피드백이 돌아옵니다. 화면에 결과가 보이고, 변경이 반영되고, 오류 메시지가 나타납니다. 반복 주기가 짧습니다.

백엔드는 조금 다릅니다. API 응답, 데이터베이스 쿼리, 비동기 처리 — 결과를 확인하려면 한 단계 더 필요합니다. 여전히 빠르지만, 피드백 루프가 프런트엔드만큼 즉각적이지 않습니다.

인프라로 가면 그 간격이 더 벌어집니다. 배포 파이프라인, 클라우드 구성, 모니터링 설정 — AI가 코드를 생성할 수 있어도, 실제 환경에서 검증하는 데 시간이 걸립니다. 코드 생성 속도와 검증 속도의 격차가 생깁니다.

리서치는 다른 축에 있습니다. 문제 정의 자체가 불명확하고, 정답이 없으며, 결과가 나타나기까지 오랜 시간이 필요합니다. AI는 논문을 요약하고 실험 코드를 짜줄 수 있지만, “무엇을 연구할 것인가”라는 질문은 AI가 대신해줄 수 없습니다.

요약하면 이렇습니다. AI 가속은 반복 주기가 짧고, 명세가 명확하고, 피드백이 즉각적인 영역에서 가장 크게 작동합니다. 반대의 특성을 가진 영역일수록 가속 효과는 줄어듭니다.

코딩이 10배 빨라지면 다음 병목은 어디인가

Andrew Ng은 코딩 가속의 연쇄 효과도 짚었습니다. 코딩 속도가 10배 빨라지면 marketing, legal, design, product decision이 새로운 병목이 됩니다.

전체 파이프라인에서 가장 느린 단계가 결과물 속도를 결정합니다. 코딩이 더 이상 병목이 아니게 됐을 때, 다음 병목은 어디로 이동하는가.

실제로 이런 상황을 경험한 팀들이 늘고 있습니다. 에이전트가 기능을 이틀 안에 구현해냈는데, 법무팀의 검토를 기다리는 데 열흘이 걸렸습니다. 디자인 시스템 승인 프로세스가 개발 속도보다 느렸습니다. 출시 결정을 위한 경영진 검토 일정이 기술 완료 후 3주 뒤였습니다.

이 상황에서 “개발팀이 에이전트를 더 잘 써야 한다”고 결론 내리면 실수입니다. 실제 병목은 다른 곳에 있습니다.

PM의 과제: 기대치 재조정

여기서 PM의 역할이 달라집니다.

과거의 PM은 팀 전체에 동일한 속도 기대치를 적용할 수 있었습니다. 프런트엔드든 백엔드든 리서치든, 스프린트 계획에서 비슷한 베이스라인을 공유했습니다.

AI 도구가 들어온 이후, 그 베이스라인이 영역별로 다르게 움직이기 시작했습니다. 프런트엔드 엔지니어가 AI 도구를 잘 활용하면 예전보다 3~5배 빠르게 움직일 수 있습니다. 리서처는 그 수준의 가속이 어렵습니다.

PM이 이 차이를 인식하지 못하면 두 가지 문제가 생깁니다.

첫째, 과도한 기대입니다. “AI 도구가 있으니 다 빨리 돼야 한다”는 가정으로 모든 팀에 동일한 속도 압박을 가합니다. 실제로 가속이 어려운 영역에 있는 팀원들은 구조적 이유가 아니라 개인 역량 부족으로 오해받습니다.

둘째, 잘못된 병목 진단입니다. 코딩이 빨라졌는데 제품 출시가 느린 이유를 엔지니어링 문제로 봅니다. 실제 병목은 design review, legal approval, product decision인데 엉뚱한 곳에 에너지를 씁니다.

PM이 해야 할 일은 세 단계로 정리됩니다.

1단계: 팀 기능별 AI 가속 현황 파악

지금 내 팀에서 AI 도구가 가장 크게 작동하는 영역은 어디인가. 프런트엔드, 백엔드, QA, 데이터 분석, 리서치 — 각 영역의 실제 반복 주기 변화를 측정합니다. 숫자가 없어도 됩니다. 팀원들에게 “AI 도구가 얼마나 도움이 되고 있나”를 직접 물어보는 것으로 시작할 수 있습니다.

2단계: 새 병목 식별

코딩이 빨라진 후 어디서 기다리고 있는가. 스프린트 회고에서 “무엇이 가장 느렸나”를 물어볼 때, “코딩이 느렸다”는 답이 줄었다면 다음 병목을 찾아야 합니다. 검토 프로세스인가, 의사결정 구조인가, 다른 팀의 의존도인가.

3단계: 병목에 맞는 개입

코딩 병목은 AI 도구로 풀 수 있습니다. 하지만 legal review 병목은 다른 방식의 개입이 필요합니다. 프로세스 변경, 사전 템플릿 준비, 병렬 검토 구조 설계 — PM이 코드 밖에서 병목을 제거해야 합니다.

가속이 균일하지 않을수록 조율이 중요해진다

이 상황이 흥미로운 이유가 있습니다. AI 도구가 팀 전체를 균일하게 가속한다면, PM의 역할은 오히려 단순해집니다. “AI 써라, 빠르게 해라”가 전부가 됩니다.

하지만 가속이 영역마다 다르게 나타날수록, 팀 전체의 속도를 맞추는 조율 역할이 더 중요해집니다. 가장 빠른 링크와 가장 느린 링크의 속도 차이가 커지면, 그 간격을 메우는 역할이 필요합니다.

그 역할이 PM입니다.

Karpathy는 AI에게 위임할 수 있는 것은 실행이라고 했습니다. 하지만 “무엇을 실행할 것인가”, “어떤 순서로 의존 관계를 풀 것인가”, “어디서 인간의 판단이 필요한가” — 이 질문들은 여전히 PM의 영역입니다.

Andrew Ng의 관찰은 그 맥락에서 더 선명해집니다. 코딩 가속이 팀 전체를 균일하게 빠르게 하지 않는다는 사실이, 오히려 PM의 조율 역할을 더 구체적으로 만듭니다. 팀 전체의 속도를 맞추는 일이 이제는 일정 관리가 아니라 가속 격차 설계입니다.

지금 당신의 팀에서 AI 도구가 가장 크게 작동하는 영역과 가장 작게 작동하는 영역은 어디입니까. 그리고 코딩이 빨라진 후, 기다리는 시간이 가장 긴 곳은 어디입니까.