앤드류 응이 deeplearning.ai/the-batch에 남긴 관찰이 있습니다.

AI 코딩 가속 효과는 프론트엔드에서 제일 크고, 백엔드로 갈수록 줄어들고, 인프라를 지나 리서치에 이르면 가장 작아집니다.

이 방향성이 6주 연속으로 같은 결론을 가리켰습니다.

많은 PM이 “AI 도입했으니 팀 전체가 빨라진다”는 전제로 로드맵을 짭니다. 이 전제는 절반만 맞습니다. 프론트엔드 팀은 실제로 2~3배 가속되는데, 인프라 팀은 왜 아직도 같은 속도인지 묻는 자리가 생깁니다. 설명하지 못하면 리더십 신뢰가 흔들립니다.

원인은 도구가 나쁜 게 아닙니다. 레이어의 본질이 다른 겁니다.

프론트엔드는 AI 가속의 최대 수혜 레이어입니다.

UI 컴포넌트는 패턴화되어 있고, 반복 구조가 많고, 결과를 눈으로 즉시 검증할 수 있습니다. Claude Code가 버튼 50개를 만들면 화면에 바로 보입니다. 인간의 승인 루프가 짧기 때문에 에이전트와의 협업 리듬이 자연스럽게 만들어집니다.

백엔드는 한 단계 느립니다.

도메인 로직이 붙고, 서드파티 연동이 생기고, 예외 케이스가 비선형으로 늘어납니다. AI는 좋은 초안을 줍니다만, “이 응답이 우리 도메인 규칙에 맞는가”는 코드 생성보다 판단 설계의 문제입니다. 검증 책임이 여전히 사람에게 있기 때문에 가속 효과가 초안 생성 단계에서 멈춥니다.

인프라는 더 느립니다.

실패 비용이 다릅니다. 프론트엔드 버그는 핫픽스로 대응할 수 있지만, 프로덕션 스키마 오류는 다릅니다. 인프라 팀은 AI가 제안한 코드를 승인하기 전에 훨씬 많은 검증 단계를 넣습니다. 가속 효과가 검증 절차에 흡수됩니다. 이것은 팀의 저항이 아니라 정상적인 판단입니다.

리서치는 레이어가 다릅니다.

무엇이 옳은 질문인지 아직 모르는 상태에서 시작합니다. AI는 작업 도구로 쓸 수 있지만, 연구 방향 자체를 정하는 판단은 인간이 지켜야 할 마지막 20%입니다. 카파시(Karpathy)가 “이해는 위임 불가”라고 말한 것이 바로 이 레이어를 두고 한 말입니다.

앤드류 응이 이 차등을 명시한 다음에 한 말이 더 중요합니다.

“코딩이 10배 빨라지면, 마케팅과 법무와 디자인이 새 병목이 된다.”

역설입니다. 코딩 팀의 AI 가속이 빠를수록 나머지 팀이 따라가지 못해 전체 속도가 갇힙니다. 프론트엔드 기대치만 올리고 마케팅 프로세스를 그대로 두면, 제품은 코딩이 아니라 마케팅에서 멈춥니다.

PM이 여기서 해야 할 일은 두 가지입니다.

레이어별로 기대치를 다르게 설정합니다. 프론트엔드 팀에 2~3배 목표를 주는 것과 인프라 팀에 같은 목표를 주는 것은 다른 개입입니다. 인프라 팀에게는 가속 속도보다 검증 프로세스를 AI 도움으로 어떻게 더 안전하게 만들 수 있는지를 먼저 묻는 게 맞습니다. 측정 지표도 “스프린트 속도”가 아니라 “검증 소요 시간”으로 바뀌어야 합니다.

코딩 외 팀의 AI 도입을 병렬로 추진합니다. 마케팅과 법무가 AI를 쓰기 시작하지 않으면, 코딩이 아무리 빨라져도 제품의 전체 속도는 달라지지 않습니다. deeplearning.ai가 6주간 확인한 신호의 진짜 메시지는 “개발팀에 AI 도구 주면 끝”이 아닙니다. 개발팀 가속이 조직의 나머지 팀을 다음 병목으로 만든다는 뜻입니다.

지금 여러분 팀에서 AI 가속이 가장 느린 레이어는 어디입니까?