개발이 0초가 돼도 출시는 1.5배밖에 안 빨라진다…딩코딩코 "기업이 프로덕트 빌더를 찾는 이유"
2026년 11월 7일원작 딩코딩코 · METR · Google DORA ↗
3줄 요약
- 개발이 0초가 돼도 기획·확인 구간이 그대로라 출시는 3주에서 2주, 1.5배 빨라지는 데 그친다
- AI로 PR이 60% 늘어도 매출은 그만큼 안 늘고 장애·재작업이 늘었다는 현장 증언
- 회사는 고르고 확인하는 일을 직접 뚫는 프로덕트 빌더를 찾고, 신입에겐 '왜 골랐나'가 무기
"내일부터 개발이 0초가 되면 제품 출시는 얼마나 빨라질까요?" 백엔드 개발자 딩코딩코가 LOOP:TALK 강연을 20분으로 정리한 영상의 첫 질문이다. 그의 답은 3주 걸릴 일이 2주로 줄 뿐이라는 것이다. 병목이 코딩에서 '무엇을 만들지 고르는 일'로 옮겨 갔고, 회사들은 그 막힌 구간을 직접 뚫을 프로덕트 빌더를 찾기 시작했다. 영상 속 주장에 METR 실험과 구글 DORA 보고서로 맥락을 붙였다.
개발이 0초가 돼도 출시는 3주에서 2주로 줄 뿐
기획 1주, 개발 1주, 확인·출시 1주가 걸리는 기능이 있다고 치자. AI 덕에 개발이 0주가 돼도 전체는 3주에서 2주, 1.5배 빨라지는 데 그친다. 딩코딩코는 대표들이 개발자 한 명당 월 200달러 안팎의 AI 비용을 쓰면서 결과물이 몇 배는 늘기를 기대하지만, 자기 회사를 포함해 대부분 그만큼 늘지 않는다고 말했다. 코드를 쓰는 일만 빨라졌기 때문이라는 설명이다.
체감은 확실히 빨라졌다…티켓 산정 1시간이 5분으로
그는 같은 백엔드 개발자인 자신의 2019년과 2026년을 비교했다. 티켓 산정은 1시간에서 5분, 장애 대응은 2시간에서 15분이 됐다. 구글 DORA의 2025년 보고서에서도 소프트웨어 전문가의 90%가 AI를 쓰고, 다수가 생산성이 올랐다고 답했다. 다만 METR의 무작위 실험에서는 경력 개발자 16명이 AI를 쓰면 24% 빨라질 것으로 예상했지만 실제로는 19% 더 오래 걸렸고, 끝난 뒤에도 20%쯤 빨라졌다고 믿었다. 2025년 초 도구 기준 결과다.
METR · METR ↗고속도로 한 구간만 8차선으로 넓히면 집에 빨리 갈까
딩코딩코는 제품이 나오는 길을 문제 발견, 방향 선택, 기획 설계, 구현 검증, 출시, 사용 확인으로 나눴다. AI가 넓힌 구간은 가운데인 기획 설계와 구현 검증이다. 앞뒤가 그대로이니 병목은 '무엇을 만들지 고르는 일'과 '만든 것이 방향에 맞는지 확인하는 일'로 옮겨 갔다. DORA는 AI를 조직의 강점도 약점도 키우는 증폭기로 규정했고, 개인 성과는 오르지만 조직 단위 효과는 더 복잡하다고 짚었다.
Google DORA · Google ↗고르는 일까지 AI에 맡기면 아무도 설명 못 하는 제품이 된다
그가 운영한 10주 백엔드 부트캠프에서 개발 경험이 없던 수강생들이 장애 모니터링, 분류·탐지 시스템 같은 프로젝트를 만들어 왔다. 그런데 발표 때 질문을 하면 답을 못 했다. 문서에는 '○○조항 근거로 27만 원에 32%' 같은 문장이 가득했다. 문제 발견과 방향 선택까지 AI에 넘겼기 때문이다. 그는 이렇게 확인되지 않은 기능과 결정이 쌓이는 현상을 'AI적 발산'이라 불렀다. 사용자가 '왜 포인트가 275원이냐'고 물어도 조항 번호로는 설명이 안 된다는 것이다.
PR은 60% 늘었는데 매출은 그만큼 안 늘었다
딩코딩코는 인프런 개발자 이동욱 씨의 말을 전했다. AI로 지난해보다 풀리퀘스트와 코드 생산량이 60% 넘게 늘었지만 매출이 같은 비율로 늘지는 않았고, 장애와 재작업이 함께 늘었다는 것이다. 개발은 AI에 맡기고 검증은 QA의 AI에 넘기는 식으로 부담을 서로 떠넘기고, 코드 리뷰에서 개발자들의 클로드끼리 '내 AI가 더 잘한다'며 맞서는 '포켓몬 싸움'도 벌어진다고 했다.
개발은 2시간 만에 끝나는데 나머지 6시간은 답을 기다린다
하루 8시간 걸리던 개발이 2시간이면 끝나면 개발자는 사실상 파트타임이 된다. 남는 시간은 기획의 결정을 기다리는 데 쓰인다. '방식 A는 3일, B는 4일인데 B는 쿠폰 쪽에 영향이 있을 수 있다'는 말이 오가면 기획자가 다른 팀과 다시 협의하고 사나흘이 지난다. 그는 이 왕복 시간을 줄이는 직군으로 프로덕트 빌더가 생겨난다고 설명했다. 공고에서 프로덕트 빌더를 찾는 비중이 1.5%에서 4.9%로 늘었다는 수치도 제시했다.
프로덕트 빌더는 '뚫어뻥'…모든 스탯을 5로 채울 필요는 없다
프로덕트 빌더가 PM 일을 전부 대신하는 것은 아니다. 직군별 깊이는 여전히 다르고, 그는 5·5·5·5가 아니라 본업은 5, 이웃 영역은 2~3 수준을 AI의 도움으로 채운 사람을 회사가 찾는다고 봤다. 프런트엔드는 사용자가 어디서 멈추는지를 데이터로 들고 오고, 백엔드는 쌓인 데이터로 병목과 검증 지표를 제안한다. 토스와 오늘의집 출신 10년 차 PM이 코드와 지라 맥락을 모은 뒤 회의에서 'A는 개발이 어려우니 B로 가자'고 정리해 소통 비용을 절반으로 줄였다는 사례도 들었다.
연차보다 판단의 속도…신입에게는 오히려 기회
그는 회사가 엔지니어에게 원하는 것이 구현 실력만이 아니라 그 위에 얹은 판단의 속도라고 했다. 시키는 대로 일정에 맞춰 넘기기만 하는 시니어는 소통이 끊겨 병목이 될 수 있고, 이 점이 신입에게는 기회로 보일 수 있다고 했다. 다만 선택지를 좁히려면 한 번이라도 직접 구현해 본 사람이어야 한다고 덧붙였다. 포트폴리오도 '무엇을 만들었나'보다 '왜 그걸 골랐나'를 담으라고 권했다. 부트캠프 질문도 1~2주 차의 '어떻게 구현하나요'에서 5~6주 차에는 'A와 B 중 뭐가 낫나요'로 바뀌었다고 한다.
오늘 프로젝트에 던질 세 가지 질문
강연은 세 질문으로 끝났다. 이 프로젝트로 누구의 어떤 상황이 나아지는가. 더 작게 먼저 확인할 방법은 없는가. 출시 뒤에 무엇을 보면 알 수 있는가. 그는 이 질문을 던지다 보면 막힌 구간이 보이고, 그 구간을 뚫는 사람이 프로덕트 빌더라고 말했다. 예시로 든 문장도 '공지를 놓치는 팀원을 확인하고 알림을 고쳐 일주일간 확인율을 로그로 봤다'처럼 문제, 선택, 지표가 한 줄에 담긴 꼴이었다.
