<div id="readability-page-1" class="page"><section itemprop="text">
        
        <h2 id="들어가며">들어가며</h2>

<p><img src="https://veluxer62.github.io/assets/images/posts/why-product-development-is-slow/slow-reason.webp" alt="slow-reason"></p>

<p>중국에는 실제로 50차선 고속도로가 있다. 베이징 인근의 고속도로인데, 명절 연휴에 4차선으로 좁아지는 지점에서 극심한 정체가 발생한다. 50차선이 아무리 넓어도, 그 모든 차가 4차선을 통과해야 한다면 결국 4차선의 속도로 수렴한다.</p>

<p>요즘 AI 도구를 쓰면서 개발 생산성이 몇 배는 올라갔다는 느낌을 받는다. 나도 그렇다. 이전에 며칠 걸리던 작업을 하루 안에 끝내는 경우가 생겼다. 그런데 이상하게도, 팀 전체로 보면 제품의 신규 기능이 나오는 속도는 크게 달라진 것 같지 않다.</p>

<p>개발은 분명히 빨라졌다. 그런데 왜 제품은 느린 걸까.</p>

<h2 id="50차선이-4차선을-만날-때">50차선이 4차선을 만날 때</h2>

<p>개발 속도를 50차선이라고 한다면, 제품이 실제로 사용자에게 닿는 데까지의 과정에는 수많은 다른 차선들이 끼어든다. 방향 설정, 팀 간 조율, 요구사항 정의, 릴리스 프로세스, 맥락 공유.</p>

<p>이 중 어느 하나라도 4차선으로 좁아지는 순간, 50차선의 개발 속도는 의미를 잃는다.</p>

<p>아이러니하게도 AI 도구가 개발을 더 빠르게 만들수록, 나머지 병목들이 더 선명하게 드러난다. 예전엔 개발 자체가 느렸으니 다른 것들이 숨어 있었다. 이제는 개발이 빠르게 끝나도 다음 단계에서 막히는 게 눈에 보이기 시작했다.</p>

<p>그 병목들을 하나씩 들여다보면 이렇다.</p>

<h2 id="병목-1-방향을-모르면-속도는-의미-없다">병목 1: 방향을 모르면 속도는 의미 없다</h2>

<p>빠른 차도 목적지가 없으면 그냥 돌아다니는 거다.</p>

<p>제품 개발에서 가장 치명적인 병목 중 하나는 명확한 비전과 목표의 부재다. “이번 분기엔 사용자 경험을 개선한다”는 목표는 목표가 아니다. 실제로 이런 경험을 한 적이 있다. 이번 분기 목표가 ‘사용자 경험 개선’이어서 팀원마다 다른 기능을 만들다가 나중에 합쳐보니 서로 방향이 달랐다. 모두가 다른 곳을 보면서 바쁘게 일하고, 합쳐놓으면 결과는 제각각이 된다.</p>

<p>여기에 더해, 이 방향을 잘게 쪼개서 팀이 실행 가능한 단위로 만들어주는 역할이 있다. 즉 좋은 Product Owner의 부재도 크다. 최단 동선을 설계하는 능력 없이는 팀이 아무리 빠르게 달려도 먼 길을 돌아가게 된다.</p>

<blockquote>
  <p>방향이 없는 팀에서 속도를 높이면, 엉뚱한 곳에 더 빨리 도착할 뿐이다.</p>
</blockquote>

<h2 id="병목-2-왼손이-하는-일을-오른손이-모른다">병목 2: 왼손이 하는 일을 오른손이 모른다</h2>

<p>실무에서 자주 목격하는 장면이 있다. 개발팀은 기획서를 받아서 구현하고, 기획팀은 구현된 결과물을 보고 “이게 아닌데”라고 한다. 개발자가 2주 만에 구현을 끝냈는데, 기획자가 보고 “이게 아닌데”라고 했을 때의 그 공허함을 경험해본 사람은 알 것이다. 서로 다른 언어로 소통하고 있는 것이다.</p>

<p>개발자가 기획 단계에 참여하지 않으면, 기획자는 기술적 제약을 모른 채 설계하고, 개발자는 의도를 모른 채 구현한다. 게다가 조직 전체의 투명성이 낮으면 누가 무엇을 하고 있는지, 어디서 의존 관계가 생기는지 파악이 안 된다. 옆 차선 차가 어디로 가는지 모르고 달리는 것과 같다. 나중에 통합하려 할 때 맞지 않는 조각들이 나온다.</p>

<p>정보가 파편화된 조직에서는, 빠른 개발보다 잦은 커뮤니케이션이 더 중요한 병목이 된다.</p>

<hr>

<p>방향과 소통이 만들어내는 병목들을 살펴봤다면, 이번엔 시간과 부채의 문제로 넘어간다.</p>

<h2 id="병목-3-과거의-빚이-미래를-잡아먹는다">병목 3: 과거의 빚이 미래를 잡아먹는다</h2>

<p>빠르게 만들다 보면 어딘가엔 반드시 빚이 쌓인다.</p>

<p>기술 부채는 처음엔 잘 보이지 않는다. “지금은 이렇게 해두고 나중에 고치자”는 결정이 쌓이면, 어느 순간부터 새 기능을 추가하기 위해 기존 코드를 뜯어고치는 시간이 기능을 만드는 시간보다 길어진다. 최근에 if 분기 하나 추가하려고 영향 범위 파악에 반나절을 쓴 적이 있다. 포장이 망가진 도로에서 빠르게 달리려는 것과 같다. 차가 아무리 좋아도 노면이 울퉁불퉁하면 속도를 낼 수 없다.</p>

<p>AI 시대에 이 문제는 오히려 심화될 수 있다. 빠르게 코드를 생성하는 만큼, 빠르게 부채가 쌓일 수도 있다. 속도의 이면에는 항상 이 대가가 따라온다.</p>

<h2 id="병목-4-자주-배포하지-않으면-배울-수-없다">병목 4: 자주 배포하지 않으면 배울 수 없다</h2>

<p>한 달에 한 번 릴리스하는 팀과 매주 배포하는 팀은, 같은 시간 동안 얻는 피드백의 양이 다르다. 톨게이트가 한 달에 한 번만 열린다면, 아무리 빠른 차도 그 앞에서 기다릴 수밖에 없다.</p>

<p>장주기 릴리스는 여러 문제를 만든다. 오래 묵힌 기능은 합칠 때 충돌이 많고, 사용자 반응을 늦게 알게 되니 잘못된 방향으로 오래 달리게 된다. 릴리스를 한 달 미루다가 두 달치 변경사항이 한꺼번에 나가고, 문제가 생겼을 때 어디서 터진 건지 찾는 데만 며칠이 걸린 경험이 있다. 릴리스 자체가 큰 이벤트가 되어버리면, 두려움이 생기고, 두려움은 더 긴 주기를 만든다. 악순환이다.</p>

<p>빠른 개발이 의미를 가지려면 배포 주기가 이를 뒷받침해야 한다. 만들고 나서 두 주를 기다려야 한다면, 그 두 주 동안 생산성의 이점은 허공에 떠 있다.</p>

<hr>

<p>마지막은 구조나 도구가 아닌, 사람의 문제다.</p>

<h2 id="병목-5-사람이-바뀌면-속도가-처음으로-돌아간다">병목 5: 사람이 바뀌면 속도가 처음으로 돌아간다</h2>

<p>팀원이 바뀌면 어떤 일이 일어나는지 경험해본 사람은 알 것이다.</p>

<p>코드는 남아 있어도, 왜 그렇게 설계했는지, 어떤 결정을 어떤 이유로 내렸는지는 사람과 함께 떠난다. 전임자가 떠난 뒤 남긴 코드 한 줄 앞에서 ‘왜 이렇게 했을까’를 30분간 고민한 경험이 있다. 운전자가 바뀌면 길을 다시 익혀야 하는 것처럼, 새로운 팀원이 그 맥락을 이해하는 데 걸리는 시간 동안 팀의 실질적인 속도는 낮아진다. 이직이 잦은 환경일수록, 이 반복이 누적되면서 팀은 만성적인 “온보딩 피로”를 겪게 된다.</p>

<p>사람이 바뀌는 건 막기 어렵다. 하지만 맥락이 사라지는 건 설계로 어느 정도 막을 수 있다. 문서화, 코드 주석, 의사결정 기록 같은 것들이 결국 팀의 장기적인 속도를 지탱한다.</p>

<h2 id="4차선부터-넓히는-법">4차선부터 넓히는 법</h2>

<p>각 병목에 마법 같은 해법이 있다면 좋겠지만, 사실 처방은 단순한 편이다.</p>

<p>비전과 목표의 부재는 명확하고 측정 가능한 목표를 세우는 것부터 해결할 수 있다. “사용자 경험 개선”이 아니라 “이탈률을 10% 줄인다”처럼, OKR이나 SMART 목표 형식으로 정의하면 팀이 같은 방향을 바라볼 수 있다. PO 역량은 하루아침에 키울 수 없지만, 적어도 팀 전체가 “지금 우리가 왜 이걸 만드는가”를 알아야 한다.</p>

<p>조직 투명성 부족과 소통 단절은 개발자를 기획 단계부터 참여시키는 것만으로도 상당히 해소된다. Three Amigos처럼 기획-개발-QA가 함께 요구사항을 검토하는 방식도 효과적이다. 구현을 시작하기 전에 함께 이해하는 시간이 나중에 잘못 만든 것을 고치는 시간보다 훨씬 짧다.</p>

<p>기술 부채는 쌓이지 않게 막는 것도 중요하지만, 꾸준히 갚아나가는 것도 중요하다. 스프린트 용량의 일정 비율을 부채 상환에 고정 배정하는 방식이 실용적이다. AI로 PR은 빨라졌지만 리뷰어가 병목이 되는 상황도 여기서 함께 다뤄야 한다.</p>

<p>릴리스 주기를 줄이는 건 어렵게 느껴질 수 있지만, Feature flag나 CI/CD 자동화를 활용해 작게 자르고 자주 배포하는 습관이 결국 더 안전하고 빠른 개발을 가능하게 한다.</p>

<p>맥락 보존은 결국 글쓰기 문화다. 결정의 이유를 기록하고, 온보딩 문서를 유지하고, 구두로만 공유되던 것들을 텍스트로 남기는 일이다. ADR(Architecture Decision Record) 같은 구체적인 형식을 도입하면 이 문화를 체계화할 수 있다.</p>

<h2 id="마무리">마무리</h2>

<p>솔직히 말하면, 4차선을 넓히는 건 코드를 짜는 것보다 훨씬 어렵다.</p>

<p>AI 덕분에 개발자의 생산성은 올라갔다. 50차선은 더 넓어졌다. 그런데 제품이 사용자에게 닿는 길 어딘가에 여전히 4차선 구간이 있다면, 넓어진 차선은 그 병목 앞에서 막힌다.</p>

<p>빠른 개발이 빠른 제품을 보장하지 않는다. 개발 속도가 올라갈수록, 이제는 그 외의 병목들을 해소하는 것이 더 중요한 과제가 된다.</p>

<p>50차선을 최대로 활용하고 싶다면, 4차선부터 넓혀야 한다.</p>

        
      </section></div>

Veluexer’s Blog

들어가며
중국에는 실제로 50차선 고속도로가 있다. 베이징 인근의 고속도로인데, 명절 연휴에 4차선으로 좁아지는 지점에서 극심한 정체가 발생한다. 50차선이 아무리 넓어도, 그 모든 차가 4차선을 통과해야 한다면 결국 4차선의 속도로 수렴한다.
요즘 AI 도구를 쓰면서 개발 생산성이 몇 배는 올라갔다는 느낌을 받는다. 나도 그렇다. 이전에 며칠 걸리던 작업을 하루 안에 끝내는 경우가 생겼다. 그런데 이상하게도, 팀 전체로 보면 제품의 신규 기능이 나오는 속도는 크게 달라진 것 같지 않다.
개발은 분명히 빨라졌다. 그런데 왜 제품은 느린 걸까.
50차선이 4차선을 만날 때
개발 속도를 50차선이라고 한다면, 제품이 실제로 사용자에게 닿는 데까지의 과정에는 수많은 다른 차선들이 끼어든다. 방향 설정, 팀 간 조율, 요구사항 정의, 릴리스 프로세스, 맥락 공유.
이 중 어느 하나라도 4차선으로 좁아지는 순간, 50차선의 개발 속도는 의미를 잃는다.
아이러니하게도 AI 도구가 개발을 더 빠르게 만들수록, 나머지 병목들이 더 선명하게 드러난다. 예전엔 개발 자체가 느렸으니 다른 것들이 숨어 있었다. 이제는 개발이 빠르게 끝나도 다음 단계에서 막히는 게 눈에 보이기 시작했다.
그 병목들을 하나씩 들여다보면 이렇다.
병목 1: 방향을 모르면 속도는 의미 없다
빠른 차도 목적지가 없으면 그냥 돌아다니는 거다.
제품 개발에서 가장 치명적인 병목 중 하나는 명확한 비전과 목표의 부재다. “이번 분기엔 사용자 경험을 개선한다”는 목표는 목표가 아니다. 실제로 이런 경험을 한 적이 있다. 이번 분기 목표가 ‘사용자 경험 개선’이어서 팀원마다 다른 기능을 만들다가 나중에 합쳐보니 서로 방향이 달랐다. 모두가 다른 곳을 보면서 바쁘게 일하고, 합쳐놓으면 결과는 제각각이 된다.
여기에 더해, 이 방향을 잘게 쪼개서 팀이 실행 가능한 단위로 만들어주는 역할이 있다. 즉 좋은 Product Owner의 부재도 크다. 최단 동선을 설계하는 능력 없이는 팀이 아무리 빠르게 달려도 먼 길을 돌아가게 된다.
방향이 없는 팀에서 속도를 높이면, 엉뚱한 곳에 더 빨리 도착할 뿐이다.
병목 2: 왼손이 하는 일을 오른손이 모른다
실무에서 자주 목격하는 장면이 있다. 개발팀은 기획서를 받아서 구현하고, 기획팀은 구현된 결과물을 보고 “이게 아닌데”라고 한다. 개발자가 2주 만에 구현을 끝냈는데, 기획자가 보고 “이게 아닌데”라고 했을 때의 그 공허함을 경험해본 사람은 알 것이다. 서로 다른 언어로 소통하고 있는 것이다.
개발자가 기획 단계에 참여하지 않으면, 기획자는 기술적 제약을 모른 채 설계하고, 개발자는 의도를 모른 채 구현한다. 게다가 조직 전체의 투명성이 낮으면 누가 무엇을 하고 있는지, 어디서 의존 관계가 생기는지 파악이 안 된다. 옆 차선 차가 어디로 가는지 모르고 달리는 것과 같다. 나중에 통합하려 할 때 맞지 않는 조각들이 나온다.
정보가 파편화된 조직에서는, 빠른 개발보다 잦은 커뮤니케이션이 더 중요한 병목이 된다.
방향과 소통이 만들어내는 병목들을 살펴봤다면, 이번엔 시간과 부채의 문제로 넘어간다.
병목 3: 과거의 빚이 미래를 잡아먹는다
빠르게 만들다 보면 어딘가엔 반드시 빚이 쌓인다.
기술 부채는 처음엔 잘 보이지 않는다. “지금은 이렇게 해두고 나중에 고치자”는 결정이 쌓이면, 어느 순간부터 새 기능을 추가하기 위해 기존 코드를 뜯어고치는 시간이 기능을 만드는 시간보다 길어진다. 최근에 if 분기 하나 추가하려고 영향 범위 파악에 반나절을 쓴 적이 있다. 포장이 망가진 도로에서 빠르게 달리려는 것과 같다. 차가 아무리 좋아도 노면이 울퉁불퉁하면 속도를 낼 수 없다.
AI 시대에 이 문제는 오히려 심화될 수 있다. 빠르게 코드를 생성하는 만큼, 빠르게 부채가 쌓일 수도 있다. 속도의 이면에는 항상 이 대가가 따라온다.
병목 4: 자주 배포하지 않으면 배울 수 없다
한 달에 한 번 릴리스하는 팀과 매주 배포하는 팀은, 같은 시간 동안 얻는 피드백의 양이 다르다. 톨게이트가 한 달에 한 번만 열린다면, 아무리 빠른 차도 그 앞에서 기다릴 수밖에 없다.
장주기 릴리스는 여러 문제를 만든다. 오래 묵힌 기능은 합칠 때 충돌이 많고, 사용자 반응을 늦게 알게 되니 잘못된 방향으로 오래 달리게 된다. 릴리스를 한 달 미루다가 두 달치 변경사항이 한꺼번에 나가고, 문제가 생겼을 때 어디서 터진 건지 찾는 데만 며칠이 걸린 경험이 있다. 릴리스 자체가 큰 이벤트가 되어버리면, 두려움이 생기고, 두려움은 더 긴 주기를 만든다. 악순환이다.
빠른 개발이 의미를 가지려면 배포 주기가 이를 뒷받침해야 한다. 만들고 나서 두 주를 기다려야 한다면, 그 두 주 동안 생산성의 이점은 허공에 떠 있다.
마지막은 구조나 도구가 아닌, 사람의 문제다.
병목 5: 사람이 바뀌면 속도가 처음으로 돌아간다
팀원이 바뀌면 어떤 일이 일어나는지 경험해본 사람은 알 것이다.
코드는 남아 있어도, 왜 그렇게 설계했는지, 어떤 결정을 어떤 이유로 내렸는지는 사람과 함께 떠난다. 전임자가 떠난 뒤 남긴 코드 한 줄 앞에서 ‘왜 이렇게 했을까’를 30분간 고민한 경험이 있다. 운전자가 바뀌면 길을 다시 익혀야 하는 것처럼, 새로운 팀원이 그 맥락을 이해하는 데 걸리는 시간 동안 팀의 실질적인 속도는 낮아진다. 이직이 잦은 환경일수록, 이 반복이 누적되면서 팀은 만성적인 “온보딩 피로”를 겪게 된다.
사람이 바뀌는 건 막기 어렵다. 하지만 맥락이 사라지는 건 설계로 어느 정도 막을 수 있다. 문서화, 코드 주석, 의사결정 기록 같은 것들이 결국 팀의 장기적인 속도를 지탱한다.
4차선부터 넓히는 법
각 병목에 마법 같은 해법이 있다면 좋겠지만, 사실 처방은 단순한 편이다.
비전과 목표의 부재는 명확하고 측정 가능한 목표를 세우는 것부터 해결할 수 있다. “사용자 경험 개선”이 아니라 “이탈률을 10% 줄인다”처럼, OKR이나 SMART 목표 형식으로 정의하면 팀이 같은 방향을 바라볼 수 있다. PO 역량은 하루아침에 키울 수 없지만, 적어도 팀 전체가 “지금 우리가 왜 이걸 만드는가”를 알아야 한다.
조직 투명성 부족과 소통 단절은 개발자를 기획 단계부터 참여시키는 것만으로도 상당히 해소된다. Three Amigos처럼 기획-개발-QA가 함께 요구사항을 검토하는 방식도 효과적이다. 구현을 시작하기 전에 함께 이해하는 시간이 나중에 잘못 만든 것을 고치는 시간보다 훨씬 짧다.
기술 부채는 쌓이지 않게 막는 것도 중요하지만, 꾸준히 갚아나가는 것도 중요하다. 스프린트 용량의 일정 비율을 부채 상환에 고정 배정하는 방식이 실용적이다. AI로 PR은 빨라졌지만 리뷰어가 병목이 되는 상황도 여기서 함께 다뤄야 한다.
릴리스 주기를 줄이는 건 어렵게 느껴질 수 있지만, Feature flag나 CI/CD 자동화를 활용해 작게 자르고 자주 배포하는 습관이 결국 더 안전하고 빠른 개발을 가능하게 한다.
맥락 보존은 결국 글쓰기 문화다. 결정의 이유를 기록하고, 온보딩 문서를 유지하고, 구두로만 공유되던 것들을 텍스트로 남기는 일이다. ADR(Architecture Decision Record) 같은 구체적인 형식을 도입하면 이 문화를 체계화할 수 있다.
마무리
솔직히 말하면, 4차선을 넓히는 건 코드를 짜는 것보다 훨씬 어렵다.
AI 덕분에 개발자의 생산성은 올라갔다. 50차선은 더 넓어졌다. 그런데 제품이 사용자에게 닿는 길 어딘가에 여전히 4차선 구간이 있다면, 넓어진 차선은 그 병목 앞에서 막힌다.
빠른 개발이 빠른 제품을 보장하지 않는다. 개발 속도가 올라갈수록, 이제는 그 외의 병목들을 해소하는 것이 더 중요한 과제가 된다.
50차선을 최대로 활용하고 싶다면, 4차선부터 넓혀야 한다.

우리 제품의 발전이 느린 이유

댓글