같은 에이전트를 넣어도, 팀마다 체감 속도가 다릅니다.

이건 제 경험에서 나온 말이 아닙니다. Andrew Ng이 deeplearning.ai The Batch에 공식적으로 쓴 문장입니다.

“Coding agents accelerate frontend, backend, infrastructure, and research at different degrees.”

프론트엔드에서 가장 빠르고, 리서치에서 가장 느립니다. 같은 에이전트, 같은 모델, 같은 비용 — 팀에 따라 결과가 다릅니다.

이 한 문장이 PM에게 주는 숙제는 단순합니다. “어느 팀에 얼마나 기대할 수 있는가”를 먼저 지도로 그리는 것입니다.

왜 영역마다 가속 속도가 다른가

차등이 생기는 이유는 세 가지입니다: 검증 루프의 속도, 도메인 복잡도, 실패 비용.

프론트엔드는 에이전트가 가장 빠르게 가치를 만드는 영역입니다. 입출력이 명확하고, 결과를 브라우저에서 즉시 시각적으로 검증할 수 있습니다. 컴포넌트 수정, 스타일링, UI 반복 — 에이전트가 생성한 코드를 “눈으로 확인”하는 시간이 짧습니다. 잘못됐으면 즉시 다시 요청하면 됩니다. 반복 속도가 빠르고 롤백도 쉽습니다.

백엔드는 조금 다릅니다. API 스펙과 도메인 로직이 얽혀 있고, 에이전트 코드가 프로덕션까지 도달하려면 테스트 커버리지를 통과해야 합니다. 테스트가 잘 갖춰진 코드베이스에서는 빠르지만, 그렇지 않으면 에이전트가 빠르게 생성한 코드가 오히려 기술 부채를 쌓습니다. 사전 인프라 상태가 가속의 전제 조건입니다.

인프라는 에이전트가 가장 신중하게 개입해야 하는 영역입니다. Terraform 한 줄의 실수가 프로덕션 데이터베이스에 영향을 줄 수 있습니다. 에이전트의 자율성을 높이 허용하는 것이 위험합니다. 초안 작성, 제안, 검토, 승인의 단계를 에이전트가 단축하지 않도록 설계해야 합니다.

리서치는 가장 느립니다. 정답이 없는 탐색 영역에서 에이전트는 방향을 잡아주지 못합니다. 문제 정의가 모호하면, 에이전트의 실행 속도는 잘못된 방향으로의 가속이 됩니다. 리서치 영역에서 에이전트에게 “탐색”을 맡기는 것은 착각입니다.

Karpathy의 표현을 빌리면: “vibe coding raises the floor, agentic engineering raises the ceiling.” 하지만 어느 영역에서 천장이 올라가는지는 도메인마다 다릅니다.

PM의 실수: 기대를 균일하게 설정하는 것

서울 CIS 2026에서 약 600명의 기업·학계 관계자가 모여 나온 결론이 이것이었습니다. “AI에 큰 비용을 투입해도 체감 변화가 작은 이유는 더 좋은 모델이 없어서가 아니라, 업무 맥락을 에이전트에 정확히 주입하는 설계가 없어서다.”

이 진단의 이면을 보면, 많은 팀이 에이전트를 도입할 때 “전사적으로 동일한 기대치”를 설정합니다. 프론트엔드 팀도, 인프라 팀도, 리서치 팀도 — 같은 기준으로 측정하고 같은 목표를 요구합니다.

결과는 예상대로입니다. 프론트엔드 팀은 기대를 넘기고, 인프라 팀은 기대를 못 채우고, 리서치 팀은 왜 써야 하는지 모르겠다고 합니다. PM은 전체 숫자를 보며 “왜 우리 팀은 ROI가 낮은가”를 묻습니다. 하지만 질문 자체가 잘못됐습니다.

팀별 가속 지도 — 네 가지 설계 원칙

PM이 해야 할 일은 영역별로 기대치, 자율성 수준, 검증 루프를 다르게 설정하는 것입니다.

[프론트엔드]  자율성: 높음 | 검증: 즉시(시각) | KPI: 반복 속도
[백엔드]      자율성: 중간 | 검증: 테스트 통과 | KPI: 버그 감소율
[인프라]      자율성: 낮음 | 검증: 인간 승인   | KPI: 제안 품질
[리서치]      자율성: 제한 | 검증: 구조화 태스크| KPI: 서브태스크 완료율

구체적으로는 이렇습니다.

프론트엔드에서는 에이전트 자율성을 높이 허용합니다. 컴포넌트 생성과 UI 반복에서는 에이전트를 막지 않습니다. 일일 단위로 결과를 검토합니다.

백엔드에서는 테스트 커버리지를 먼저 기준으로 세웁니다. 에이전트가 생성한 코드가 통과해야 할 자동화 테스트 기준이 없으면, 에이전트 도입의 선행 과제는 모델 선택이 아니라 테스트 인프라 구축입니다.

인프라에서는 에이전트를 초안 작성자로만 씁니다. 제안→검토→승인의 3단계를 줄이지 않습니다. 이 단계를 건너뛰도록 에이전트를 설계하면 오히려 위험이 높아집니다.

리서치에서는 “탐색”을 에이전트에게 맡기지 않습니다. 대신 문헌 요약, 실험 데이터 정리, 논문 코드 재현처럼 구조화된 서브태스크만 위임합니다. 에이전트가 “무엇을 찾아야 하는가”를 정하게 하면 결과가 없습니다.

다음 병목은 마케팅, 법무, 디자인

Andrew Ng이 덧붙인 경고가 더 중요합니다. 코딩 에이전트가 개발 속도를 10배 높이면, 다음 병목은 마케팅, 법무, 디자인 팀이 된다고 했습니다.

이 팀들이 갑자기 조직의 새 속도 제한 요소가 됩니다. 개발은 빨라졌는데 법무 검토가 2주 걸리고, 마케팅 카피 승인이 3일 걸리고, 디자인 시안이 1주일 걸리는 상황이 옵니다.

PM이 이 구조 변화를 먼저 보지 않으면, 조직은 빠른 팀과 느린 팀 사이의 갈등으로 에너지를 소모합니다. 에이전트 도입의 ROI는 숫자가 아니라 팀 간 마찰로 돌아옵니다.

이 지도를 그리는 것이 PM의 역할입니다. 모델을 고르는 것이 아니라, 어느 팀이 먼저 빨라지고, 어느 팀이 다음 병목이 되는지를 미리 예측하고 설계하는 것입니다.

당신의 팀에서 코딩 에이전트가 가장 효과를 내는 영역은 어디인가요? 반대로 기대만큼 되지 않는 영역은 어디인지, 그 이유가 무엇인지 들어보고 싶습니다.