기획에도 기술부채가 있다

0. 들어가며

안녕하세요. 노머스에서 서비스 기획을 하고 있는 정영수입니다. 저는 빠르게 성장하고 있는 노머스에 비교적 최근 (작년 8월) 서비스 기획자로 합류하게 되었습니다.

이렇게 빠르게 성장하고 있는 서비스가 한발 더 나아가기 위해서 10년차 서비스기획자는 무엇을 해야하는지에 대한 고민이 있었고 그 고민을 정리해보니 기획부채(제품 부채) 라는 단어로 정리가 되어 이에 대한 이야기를 해보려고 합니다.

빠르게 성장하는 스타트업이면 당연히 가질수 밖에 없는 것이 기술부채 입니다.

복잡하게 꼬여있는 코드와 마찬가지로 정리되지 않은 정책은 서비스의 성장과 생산성을 매우 방해하는 요소입니다.

해외에서는 product debt 이라는 단어로 제품 측면에서도 예전부터 이야기가 많이 되었었지만 유독 국내에서는 기술적인 측면에 집중적으로 다뤄지는 것 같습니다.

서비스기획 관점에서 어떠한 행동들이 부채가 되는지 , 이를 해결하기 위해 노머스에서 어떤 방법을 적용할 계획인지 아래에서 천천히 말씀 드려 보겠습니다.

1. 기술부채란?

기술 부채의 사전적 정의는 아래와 같습니다

현 시점에서 더 오래 소요될 수 있는 더 나은 접근 방식을 사용하는 대신 쉬운 설루션을 채택함으로써 발생되는 추가적인 재작업의 비용

해당 개념은 1992년 처음 위키를 만든 개발자 워드 커닝햄(Ward Cunningham) 을 통해서 만들어 졌습니다. 워드 커닝햄은 빠른 출시를 위해 완성도를 포기해야한다는 개발내용을 비즈니스 관계자들에게 설명을 해야했고 가장 쉽게 설명하기 위해 금융의 부채의 개념을 가져오게 됩니다. 이 개념이 뜻하는 바는 명확합니다. 첫째, 빠른 성장을 위해 전략적으로 빚(대출)을 질 수 있다는 것. 둘째, 부채는 제때 상환만 하면 성장의 레버리지가 된다는 것입니다.

하지만 금융 시장의 원칙과 마찬가지로 가장 중요한 점은 제때 원금을 갚지 않으면 결국 파산한다는 점입니다. 그래서 개발 조직에서는 꼬인 코드를 풀고 구조를 개선하는 리팩토링’ 등을 통해 이 부채를 꾸준히 상환합니다.

기획 영역에서도 이러한 부채는 존재하고 갚아야하는 점이 있습니다. 우버의 PM으로 유명한 엔드류 첸은 이러한 것을 제품 부채 (Product debt) 이라는 말로 자주 설명을 했습니다.

우버(Uber)의 성장을 이끌었던 앤드류 첸은 지속적으로 이 것에 대해 언급했습니다. 그는 워드 커닝햄의 기술 부채 개념을 기획과 비즈니스의 영역으로 확장하며 ‘제품 부채(Product Debt)’ 라는 내용으로 개념을 확장했습니다.

기술 부채가 ‘어떻게(How)’ 구현하느냐의 타협이라면, 제품 부채는 ‘무엇(What)‘을 만드느냐에 대한 낡은 의사결정들이 쌓인 결과물이라는 것이죠.

2. 제품 부채에는 어떤것이 있나요?

앞서 다양한 이론적 정의를 빌려 거창하게 설명했지만, 현업에서 기획 부채는 너무나도 자주 겪는 사소한 일입니다. 이런 것들을 4가지 유형의 기획 부채로 정의해보았습니다.

1. 입으로 하는 기획

제품 부채의 가장 흔하면서도 치명적인 유형입니다. 소위 ‘입기획’ 이라고 하죠. 기획서에는 적혀있지 않고, 회의실에서 말로 때우거나 슬랙 댓글로 가볍게 합의하고 넘어가는 경우입니다.

“영수님, 여기 회원가입 실패했을 때 뜨는 에러 메시지 말이에요. 기획서에는 내용이 없던데, 그냥 ‘알 수 없는 오류’라고 띄우면 될까요?”

“네 그렇게 하시죠”

여기서 제품 부채의 진짜 무서움이 드러납니다. 개발자가 만든 ‘기술 부채’는 적어도 코드라는 실체라도 남아있습니다. 코드를 뜯어보면 “아, 이때 급해서 이렇게 짰구나”라고 추적이라도 가능하죠. 하지만 ‘입으로 한 기획’은 잘못하면 그 어디에도 흔적이 남지 않습니다.

우리는 흔히 “스타트업은 속도가 생명”이라며 문서를 최소화한다는 핑계를 댑니다. 하지만 ‘문서의 최소화’와 ‘정책의 부재’는 엄연히 다릅니다. 기획서 수정 없이 메신저나 구두로 스펙을 변경한 후 기록이 되지 않는다면 모두가 모르는 그런 일이 됩니다.

결국 6개월 뒤, 신규 입사자가 “이 버튼은 왜 이렇게 동작하나요?” 라고 물었을 때, 기획자가 대답을 못 하고 “히스토리가 있지 않았을까요? 코드 확인 부탁드립니다 ” 와 같은 주객전도의 상황이 벌어집니다. 코드가 곧 기획서가 되어버리는 상황. 이것이 누적되면 조직 전체의 커뮤니케이션 비용을 급증시키는 가장 악질적인 부채가 됩니다.

(가장 악질적이지만 가장 빈번하게 일어나는 일입니다.)

2. 설마 이걸 하겠어? (모든 사용자가 착한 것은 아닙니다)

기획자는 기본적으로 긍정적인 시나리오로 기획서를 작성하게 됩니다. 사용자가 우리가 의도한 순서대로 버튼을 누르고, 네트워크는 항상 빠르며, 결제는 한 번에 성공할 것이라 믿고 싶어 하죠. 하지만 현실의 사용자는 기획자의 상상보다 훨씬 창의적(?)이거나, 혹은 가혹합니다.

“영수님, 만약에 결제 로딩 중에 유저가 뒤로 가기 버튼을 연타하면 어떻게 처리할까요? 중복 결제될 수도 있는데…”

“에이, 로딩바가 도는데 설마 거기서 뒤로 가기를 누르는 사람이 있을까요? 그건 그냥 두시죠.”

기획서를 작성하면서도 아차 싶은 순간이 옵니다. 이렇게 될 가능성도 있는데… 그렇지만 그때만 갑자기 사용자를 무한 맹신하게 됩니다.

‘설마’ 라는 단어로 퉁치고 넘어간 그 빈칸은, 결국 예견된 CS 폭탄으로 돌아오게 됩니다.

3. 이 기능의 진짜 이름은? (한 기능을 부르는 이름은 다수)

서비스의 기능이 복잡해지고 기획을 하는 인원이 증가할수록 종종 발생하는 일입니다.

같은 대상을 두고 심하게는 기획서 페이지마다 약하게는(?) 프로젝트마다 기능의 이름이 바뀝니다. 이것이 누적되면 한가지 기능을 다수의 이름으로 부르게 되거나 개발자 역시 다른 기능으로 오해해서 DB를 새로 만들거나 하는일들이 발생하죠

개발자: “과거에는 ‘고객(Customer)‘이라고 되어 있고, 이번 기획서에는 ‘회원(User)‘이라고 되어 있는데 둘이 다른 건가요? DB 테이블을 분리해야 하나요?”

“아, 그거 같은 거예요. 통일해 주세요.”

기획 단계에서의 명확하지 않은 용어는 개발의 실패로 이어집니다. 기획자가 용어를 정의하지 않으면, 개발자, 디자이너, 마케터가 같은 내용을 서로 다른 언어로 이야기하게 됩니다. 나중에 데이터를 추출하려고 보면 서로 다른 테이블에 엉뚱한 이름으로 데이터가 쌓여있어 통계조차 낼 수 없는 ‘부채’로 돌아오게 됩니다.

4. 이번에만 이렇게 하시죠? (하드코딩의 함정)

서비스를 만들다 보면 정말 급하게 특정 기능을 배포해야 할 때가 있습니다. 정석대로라면 어드민 기능을 만들고 권한을 나누고 해야하지만, 당장의 속도를 위해 타협을 하게 됩니다.

“시간 없으니까 이 배너 딱 3일만 나오게 코드에 하드코딩으로 박아주시면 안 될까요? 이번만요! 진짜 곧 어드민 만들거에요 ”

“음… 가능은 한데, 나중에 끄려면 다시 배포해야 해요.그리고 다른 곳에 영향을 줄수도 있어 위험해요”

“이번만요” 가 반복되면 시스템은 누더기가 됩니다. 시스템으로 해결해야 할 문제를 인력으로 때우기 시작하면, 나중에는 텍스트 한 줄을 수정하기 위해 앱 심사를 다시 받아야 하거나 긴급 배포를 해야 하는 비효율이 발생합니다.

그리고 비즈니스 영역에서는 “그거 그때 금방되던데? “ 라는 무서운 말로 돌아오게 됩니다.

확장성을 고려하지 않고 당장의 편의를 위해 요청한 하드코딩은 쌓이게 되면 나중에는 새로 만드는 것이 더 나은 상황이 벌어질 수도 있습니다.

하지 말라는 내용으로 작성하면서도 최근까지도 일정을 핑계로 종종 한 것 같아 자기반성의 시간을 가지면서 이 기회를 빌어 사과의 말을 전하도록 하겠습니다. 그렇다면 이러한 이슈들을 조직에서, 시스템으로 어떻게 하면 해결 될 수 있을지를 고민하여 앞으로 노머스 기획에서 만들어 가고 싶은 것들을 정리해보도록 하겠습니다.

3. 기획부채를 해결하기 위한 방법

부채를 ‘0’으로 만드는 것은 불가능하며 좋은 방법은 아닙니다. 완벽한 기획서를 쓰느라 서비스 론칭 타이밍을 놓치는 것이 더 큰 문제이니까요 . 제 목표는 ‘관리 가능한 수준’ 으로 부채를 통제하는 노력을 하자입니다.

1. 기획에도 컨벤션이 필요하다.

개발자들이 코드의 가독성과 통일성을 위해 ‘코딩 컨벤션’을 만드는 것 처럼 기획에도 컨벤션이 필요하다고 생각 됩니다. 기획서 마다 예외 케이스를 적는 방식과 용어가 제각각이라면, 읽는 개발자는 매번 새로운 회사에 취업한 기분일 겁니다.

기획서 작성의 표준, 즉 ‘기획 컨벤션’ 을 만들어야 합니다. 예를 들어 아래와 같은 것들을 작성 컨벤션으로 정하게 됩니다.

• 특정 기능의 명칭을 무엇으로 통일할지?
• 기획서의 구분은 어떻게 할지?
• 에러 케이스는 어디까지 어떻게 작성할지 ?

작성 기준이 명확해지고 작성 방식이 통일되면 기획의 시간과 그 기획서를 해독하는 개발자의 시간도 줄어들게 될 것 같습니다.

2. 마스터 정책서’ 만들기

프로젝트 단위로 다양한 사람들이 기획서 작성을 하다 보면 파편화가 당연히 발생합니다. A 프로젝트에서는 ‘로그인’ 정책을 이렇게 정의하고, B 프로젝트에서는 저렇게 정의하는 식이죠. 이를 방지하기 위해 서비스의 기준이 되는 ‘마스터 정책서’ 가 필요합니다.

기획할 때마다 매번 처음부터 새롭게 정책을 작성하는 것이 아니라, (보통 스타트업에서는 과거 기획서를 참조하는데 과거 기획서가 없다면 정말 새로운 서비스가 만들어 질수도 있습니다) “마스터 정책서”를 참고하여 작성하는 것은 전체적인 프로젝트의 시간을 줄여주고 안전한 서비스를 만드는 기틀이 될 것입니다.

3. 최종 기획서 정리하기

많은 기획자가 서비스가 배포되고 나면 프로젝트가 끝이라고 생각합니다.

배포 이후 기획자들은 자잘한 이슈나 급하게 나간 것들을 기획서에 작성하는 것을 종종 잊는 경우가 있습니다.이 변경 사항들을 기획서에 반영하지 않고 덮어버리면, 나중에 후임자가 그 기획서를 보고 프로젝트를 진행 했다가 낭패를 보는 일이 생기게 되죠. 이를 방지하고자 프로젝트 프로세스의 마지막 단계에 [최종 기획서 업데이트] 를 필수 과정으로 넣어야 합니다. 현재 라이브 되고 있는 서비스 와 내 기획서가 100% 일치하도록 만드는 작업. 이것을 정식적인 프로세스로 만들고 팀 내 그라운드 룰로 정착시켜야 부채의 고리를 끊을 수 있습니다.

4. 장부 만들기 (부채 백로그)

어쩔 수 없이 부채를 져야 할 때가 있습니다. “이번만 하드코딩으로 가시죠”, “일단 이 예외 케이스는 무시하시죠”라고 타협해야 할 때가 분명히 옵니다. 성장해야하는 스타트업이니까요.

중요한 건 빚을 졌다는 사실을 잊지 않는 것입니다. 코드에 주석을 달듯이, 기획에서도 부채를 기록할 장부가 필요합니다. 이렇게 모아둔 ‘부채 백로그’는 나중에 여유가 생겼을 때나 다음 기획 때, 무엇을 먼저 해결해야 할지 알려주는 기록이 됩니다. 보이지 않는 빚은 문제지만, 장부에 적힌 빚은 계획적으로 갚아나갈 수 있습니다.

4. 나가며

이 글을 쓰면서 하지 말자고 했지만 계속 하고 있는 것 같아 자기점검의 시간이 된 것 같아 조금 부끄럽긴한데요.

2026년에는 더 빠른 성장과 함께 앞서 고민했던 방법들을 지켜나가고 노머스 서비스들의 제품부채를 줄이는 것에 도 신경을 써보려고 합니다.

아직은 시행하고 있는 것도 있고 계획만 하고 있는 것도 있습니다. 시간이 지나 해당 내용들이 잘 지켜져서 제품부채를 줄이게 된 성공기로 다시 찾아뵐 수 있으면 좋겠습니다.

긴 글 읽어주셔 감사합니다.