어떤 관찰이 6주 연속 같은 결론을 내리면 그건 신호가 아니라 구조다.

Andrew Ng은 deeplearning.ai의 The Batch 뉴스레터를 통해 6주 연속 같은 패턴을 기록했다. AI 도입 속도가 팀 유형에 따라 체계적으로 다르다는 것이다. 가장 빠른 쪽은 프론트엔드, 그다음은 백엔드, 인프라는 그보다 느리고, 리서치 팀은 가장 다른 궤적을 그린다.

이 순서가 중요한 이유는 대부분의 PM이 이것을 무시하기 때문이다.

순서는 우연이 아니다

이 네 레이어가 AI를 흡수하는 속도가 다른 이유는 각 레이어의 피드백 사이클과 실패 비용이 다르기 때문이다.

프론트엔드는 실험이 빠르다. UI 컴포넌트 하나를 바꾸면 30분 안에 결과를 확인할 수 있다. 실패해도 롤백이 가능하고, 실패의 범위가 좁다. AI가 생성한 코드가 틀려도 테스트를 돌리고 고치면 된다. 코딩 에이전트가 가장 먼저 이 레이어에서 폭발적인 생산성 향상을 만들어낸 이유가 여기에 있다.

Duolingo와 GitHub Copilot의 협업 사례가 이를 수치로 보여준다. 코드 리뷰 시간이 67% 단축됐고, 신규 저장소 기준 생산성이 25% 향상됐다. 이 숫자가 나온 레이어는 주로 기능 개발 사이클이 빠른 팀이었다.

백엔드는 한 단계 느리다. API 계약, 분산 상태 관리, 서비스 간 의존성이 있다. AI가 생성한 코드가 데이터베이스 스키마를 잘못 이해하거나 레이스 컨디션을 만들면 디버깅에 며칠이 걸린다. 사이클이 프론트엔드보다 길고 실패 범위가 넓다. 일단 통합되면 단위 테스트 자동화, API 문서화, 코드 리뷰에서 큰 효과가 나타나지만, 그 전에 구조적 안전장치가 필요하다.

인프라는 또 다르다. 보안, 신뢰성 SLA, 실패의 폭발 반경이 서비스 전체를 건드린다. AI가 생성한 IaC(Infrastructure as Code)를 검증 없이 적용하면 프로덕션이 다운될 수 있다. 이 레이어는 실수의 비용이 너무 커서 AI 도입 속도가 필연적으로 느리다. 변경 승인 프로세스, 점진적 배포 파이프라인, 드라이런 검증이 AI 도입의 사전 조건이다.

리서치는 다른 궤도를 그린다. 도메인 전문성과 창의적 판단이 핵심이고, AI는 문헌 검색이나 코드 프로토타입 작성에서 보조 역할을 한다. 가설 설계와 실험 해석은 여전히 인간의 판단 영역이다. AI가 도구로 들어오는 속도는 빠르지만, 리서처의 핵심 판단을 흡수하는 것은 가장 느리거나 아직 일어나지 않는 일이다.

같은 기대치를 모든 팀에 적용하면 어떻게 되는가

많은 PM이 “팀 전체에 AI 도입해서 생산성 3배 올린다”는 목표를 설정한다. Andrew Ng이 기록한 패턴은 이 접근이 왜 구조적으로 실패하는지 보여준다.

프론트엔드 팀에 3배 기대치를 적용하면 달성 가능하다. 오히려 보수적인 목표일 수 있다. 반면 인프라 팀에 같은 기대치를 적용하면 팀은 두 가지 선택지 앞에 놓인다. 검증 프로세스를 건너뛰거나, 목표를 달성하지 못한 것에 대한 설명을 반복하거나.

검증을 건너뛰면 인시던트가 발생한다. 인시던트 하나가 그동안의 생산성 향상을 지워버린다. PM은 “AI 도입이 인프라 팀에서 실패했다”는 결론을 내린다. 실제 문제는 AI가 아니라 잘못 설정된 기대치였는데.

삼성SDS 사례가 이 패턴의 한국적 맥락을 보여준다. AX센터 보고에서 에이전트 실제 도입률이 5%에 머물렀다. 기술 부재가 아니었다. 도입 이후 운영을 책임질 조직 구조와 팀별 준비도가 서로 달랐기 때문이다. 준비된 팀은 빠르게 도입했고, 그렇지 않은 팀은 파일럿 단계를 벗어나지 못했다.

팀 레이어별 기대치를 달리 설계하는 방법

Andrew Ng의 관찰이 PM에게 주는 실무적 함의는 하나의 AI 전략이 아니라 팀 레이어별로 다른 전략을 설계하는 것이다.

프론트엔드 팀: AI 도입을 적극적으로 가속한다. 코딩 에이전트, 자동화 테스트, UI 생성을 빠르게 실험한다. 이 레이어에서의 실패는 배울 수 있는 실패다. 기대치는 높게 설정하되, 실험 사이클을 짧게 유지한다.

백엔드 팀: 특정 영역에 먼저 도입한다. 단위 테스트 자동화, API 문서화, 코드 리뷰 보조처럼 실패 범위가 제한된 곳부터 시작한다. 분산 시스템 전체에 AI를 한 번에 적용하려는 시도는 검증 레이어 없이는 위험하다.

인프라 팀: AI 도입의 속도보다 검증 구조를 먼저 갖춘다. IaC 생성에 AI를 쓸 때는 반드시 드라이런과 스테이징 검증을 거친다. 이 팀에서의 생산성 목표는 “3배 속도”가 아니라 “운영 인시던트 감소”처럼 다른 지표로 설정해야 한다.

리서치 팀: AI를 탐색 비용 절감 도구로만 기대치를 설정한다. 문헌 검색 자동화, 코드 프로토타입 생성, 실험 설계 초안은 AI가 할 수 있다. 그러나 리서처의 핵심 판단 — 어떤 방향이 맞는가, 이 결과를 어떻게 해석하는가 — 은 AI가 흡수하는 영역이 아니다. 이 팀에서 노려야 할 것은 리서처의 탐색 시간을 줄이는 것이지, 리서처를 대체하는 것이 아니다.

기대치보다 먼저 물어야 할 것

팀별 기대치를 다르게 설정하기 전에 PM이 먼저 확인해야 할 것이 있다. 각 팀이 지금 어느 단계에 있는가.

AI 도입의 사이클은 “도구 사용 → 워크플로우 통합 → 판단 위임 → 구조 재설계”의 순서로 진행된다. 프론트엔드 팀이 워크플로우 통합 단계에 있을 때 인프라 팀은 아직 도구를 평가하는 중일 수 있다. 같은 조직 안에서도 이 격차는 6개월에서 1년까지 벌어질 수 있다.

hwchase17이 “2026 is the year of evals”라고 명명한 것도 같은 맥락에서 읽힌다. PM이 설계해야 할 것은 기능 명세가 아니라 각 팀의 AI 활용이 얼마나 효과적인지 측정하는 평가 구조다. 같은 커밋 수나 PR 수로 비교하면 인프라 팀은 항상 프론트엔드 팀에 뒤처진다. 팀의 특성에 맞는 지표로 분리해야 각 팀이 실제로 성장하고 있는지 보인다.

Google이 내부 보고서에서 정리한 것처럼, 어떤 조직에서도 AI를 깊이 활용하는 20%, 부분적으로 사용하는 60%, 아직 실험 단계인 20%의 분포가 나타난다. PM은 이 분포가 팀 유형에 따라 완전히 다른 의미를 가진다는 것을 이해해야 한다. 프론트엔드 팀의 20%와 인프라 팀의 20%는 같은 숫자지만 전혀 다른 구조에서 나온다.

Andrew Ng이 6주 연속 기록한 패턴은 단순하다. AI는 모든 팀을 같은 속도로 바꾸지 않는다. PM이 그 차이를 설계에 반영하지 않으면, 가장 빠른 팀의 성과와 가장 느린 팀의 인시던트가 한 조직 안에서 동시에 나타난다.

당신의 AI 전략은 팀별 레이어를 다르게 설계하고 있습니까, 아니면 하나의 기대치로 전체를 관리하고 있습니까?