기획 부채는 프로젝트를 잡아먹을 수 있다.

2023년 11월, 대한민국 행정이 사실상 멈춰 섰습니다. 전국 주민센터에서는 등본 한 통 뗄 수 없었고, 온라인 정부24 서비스는 접속조차 되지 않았죠. 지방행정전산망이 마비되었기 때문입니다. 기억 나시나요? 며칠 간의 혼란이 있었고, 정부가 발표한 공식 원인은 “라우터라는 네트워크 장비의 케이블 연결 포트의 일부가 불량이기 때문”이었습니다. (출처: 행정안전부, ‘지방행정전산망 장애 원인 및 재발방지 대책’ 브리핑, 2023.11.25.)

여기까지만 들으면 단순한 장비 고장, 즉 어쩔 수 없는 사고처럼 보입니다. 하지만 우리 IT 업계 종사자들은 이 지점에서 한 걸음 더 들어가 봐야 합니다. 우리 모두가 아는 것처럼, 연결 포트와 같은 장비는 당연히 고장날 수 있습니다. 나중에 살펴보면 정말 어이없는 이유로 고장들이 나있곤 하죠. 그 당연한 고장 때문에, 대한민국 행정 전체가 마비되는 게 마땅히 감수해야 하는 일일까요? 브리핑의 질문과 답변에서 우리는 더 본질적인 문제의 실마리를 찾을 수 있습니다. 바로 “이중화에 대한 구성은 다 되어 있었다. 그런데 … 일부 모듈의 이상이 생긴 것은 하나의 장비가 비정상 작동한 것이 아니기 때문에, 이중화가 제대로 작동이 되지 않았다”는 부분입니다.

<출처: 대한민국 정책브리핑, 2023. 11. 25>

저는 이 말을 이렇게 번역하고 싶습니다. 바로 기획 및 설계 단계에서 예외 상황이나 문제 상황이 제대로 정의되지 않았다는 뜻입니다. "이중화 시스템은 갖춰놨으니까", "이중화 조건? 장비가 비정상 작동하는 상황이겠지." 와 같은 안일한 가정이, 결국 최악의 시나리오가 닥쳤을 때 시스템 전체를 멈춰 세운 것입니다.

우리는 ‘기술 부채(Technical Debt)’라는 말에 아주 익숙합니다. 당장의 빠른 개발을 위해 비효율적인 코드를 남겨두면, 나중에 더 큰 비용을 치르게 된다는 뜻이죠. 그런데 저는 오늘, 기술 부채보다 훨씬 더 교활하고 파괴적인, 하지만 우리가 잘 인지하지 못하는 보이지 않는 빚에 대해 이야기해 보려고 합니다. 바로 전국을 멈춰 세운 그 근본 원인, **‘기획 부채(Planning Debt)’**입니다.

1. 기술 부채만 있는 것이 아니다, ‘기획 부채’도 있다

기획 부채가 뭘까요? 간단히 말해, 기획 단계에서 명확하게 정의하지 않고 넘어간 모든 불확실성을 의미합니다.

"이 정책은 민감하니까 지금 여기서 결정할 순 없고요. 다음 회의에서 정하죠." "그 예외 케이스도 있긴 있는데… 일단 거의 발생 안 할 테니 지금은 넘어갑시다." "이 부분은 개발팀에서 센스있게 잘 해주시고요."

이런 말들로 대표되는, 불명확한 결정, 암묵적인 합의, 미뤄진 논의들이 바로 ‘기획 부채’의 원금입니다. 이 원금은 프로젝트가 진행되는 내내 보이지 않는 이자를 불려나가며, 결국 어느 순간 팀 전체의 발목을 잡는 거대한 족쇄가 되어 돌아옵니다. 기술 부채는 코드 속에라도 흔적이 남지만, 기획 부채는 사람들의 머릿속이나 회의록 한구석에 희미하게 존재하기에 더 찾아내기 어렵고 위험하죠.

출처: Gemini 생성

2. 기획 부채가 쌓이는 아주 구체적인 상황

이 기획 부채가 현업에서 어떻게 우리를 괴롭히는지, 아주 구체적인 대화로 한번 살펴볼까요? 아마 많은 분들이 기시감을 느끼실 겁니다.

PM: (기획서를 설명하며) "사용자가 여기서 '포인트 사용하기' 버튼을 누르면, 보유 포인트 내에서 자유롭게 쓸 수 있도록 할 거예요."

개발자: "네. 그런데 혹시 쿠폰이랑 중복 사용은 가능한가요? 그리고 포인트 사용 최소 단위는 어떻게 되죠?"

PM: “음, 그 부분은 아직 정책팀이랑 협의 중이라... 일단 중복 사용은 안 되는 걸로 개발 먼저 해주시겠어요? 정책은 확정되는 대로 바로 공유 드릴게요!"

바로 이 순간, 기획 부채가 발생했습니다. 개발자는 이제 선택의 기로에 놓입니다.

• 선택 1 (소극적 대응): PM의 말이 확정될 때까지 하염없이 기다린다. (→ 프로젝트 일정 지연)

• 선택 2 (적극적 추론): '중복 사용 불가'를 전제로, 나중에 변경될 가능성을 염두에 두고 코드를 설계한다. 어쨌든 ‘추론’이다.

• 선택 3 (가장 흔한 경우): "일단 안 되는 걸로 짜고, 나중에 바꾸라고 하면 그때 바꾸지 뭐." 라는 생각으로 가장 빠른 방식으로 코드를 작성한다.
   

정말 이유는 모르겠지만, 꼭 이렇게 하고 나면 반드시 우리 생각과 다른 정책이 내려옵니다. 예를 들어, '쿠폰과 포인트 중복 사용이 가능해야 마케팅 효과가 극대화된다'는 최종 결정이 내려오는 거죠. 이제 개발자는 이미 짜놓은 코드의 상당 부분을 뜯어고쳐야 합니다. 간단한 정책 변경인 것 같지만, DB 설계부터 결제 로직, UI까지 건드려야 할 부분이 한두 군데가 아니죠. 기획 단계에서 1시간만 더 투자해 명확히 정책을 확정했다면 발생하지 않았을, 수십, 수백 시간의 재작업 비용이 청구되는 순간입니다.

3. 기획 부채는 대체 왜 생기는가?

그렇다면 우리는 왜 이런 부채를 쌓게 되는 걸까요? 기획자가 게으르거나 무책임해서? 아니면 원래 우리 회사 구성원의 역량이 부족해서? 절대 그렇지 않습니다. 대부분의 기획 부채는 시스템적인 문제에서 비롯됩니다.

PM은 손이 열 개여도 부족하다. 출처: Gemini 생성

• 첫째, 기획에 투자할 절대적인 시간이 부족합니다. "시장 상황이 급변하고 있으니, 일단 빨리 만들고 생각합시다!" 라는 문화 속에서 기획자는 충분히 고민하고 검증할 시간을 갖지 못합니다. 기획자는 깊이 있는 고민을 하고 싶더라도, 당장 개발팀이나 대표, 클라이언트에 보내야 할 기획 산출물이 우선인 경우가 많죠.

  
  

• 둘째, 기획을 책임질 인력이 한정되어 있습니다. 많은 회사에서는 한 명의 기획자가 여러 개의 프로젝트를 동시에 담당하는 경우가 허다합니다. 물리적으로 모든 회의에 참석하고, 모든 질문에 즉각 답해줄 수가 없죠. 기획자는 자연스럽게 팀의 '병목'이 되고, 개발자는 답변을 기다리다 지쳐 스스로 결정을 내리게 됩니다.
  
  

• 셋째, 비효율적인 커뮤니케이션 구조입니다. 요구사항이 명확히 문서화되지 않고, 구두나 메신저로 파편화되어 전달됩니다. 나중에 문제가 생겼을 때 "그때 그렇게 말씀하셨잖아요" "제 기억엔 없는데요?" 와 같은 책임 공방이 벌어지기 딱 좋은 환경이죠.
  
  

• 넷째, 커뮤니케이션의 부족입니다. 사실은 비효율적인 커뮤니케이션이라도 있으면 다행입니다. 많은 경우, 세세한 부분까지 기획자가 챙기지 못하는 경우가 훨씬 많습니다. 이럴 경우에는 개발/디자인 팀에서 자체적으로 결정해서 실행을 하게 되고, 결국 팀 전체가 같은 기획을 바탕으로 움직이지 못하게 됩니다.
   

사실, 대부분의 회사에서 기획보다는 개발과 디자인 역량에 투자하는 것이 먼저가 될 수밖에 없습니다. 결국 기획 부채는 개인의 역량 문제라기보다, 기획의 중요성을 간과하고 기획 역량에 투자를 미루게 된 조직의 구조적인 문제일 가능성이 높습니다.

4. 쌓여가는 기획 부채, 어떻게 해결해야 할까?

그럼 이 지긋지긋한 빚의 굴레를 어떻게 끊어낼 수 있을까요?

물론 가장 이상적인 해결책은 "실력 있는 기획자를 많이 뽑고, 그들에게 충분한 시간을 주는 것"입니다. 하지만 우리 모두 알다시피, 이는 대부분의 회사에겐 비현실적인 이야기입니다. 그런 해결책을 선택하는 게 가능한 회사가 몇이나 있을지 모르겠네요.

그렇다면 현실적인 대안은 무엇일까요? 저는 크게 3가지 해결책을 단계적으로 적용해볼 수 있다고 생각합니다.

해결책 1: '질문 폭탄 세션'을 공식화하기

가장 먼저, 제가 추천하는 방법은 개발 시작 전 '질문 폭탄 세션'을 팀의 공식적인 문화로 만드는 것입니다. 기획자가 기획서를 공유하면, 개발자와 디자이너는 박수를 치며 이해하는 척하는 대신, 의도적으로 '프로불편러'가 되어 집요하게 질문을 던지는 시간을 갖는 겁니다.

• "이 버튼을 1초에 100번 누르면 어떻게 되나요?"

• "사용자 닉네임이 특수문자나 이모티콘이면요?"

• "여기서 API 호출이 실패하면 사용자에게 뭐라고 보여주실 건가요?"

이런 질문들은 기획자를 공격하는 것이 아니라, 미래에 터질 시한폭탄을 함께 제거하는 공동 작업입니다. 이 세션을 통해 우리는 두 가지 중요한 것을 얻을 수 있습니다. 첫째, 기획자는 혼자 모든 것을 책임져야 한다는 부담감에서 벗어나 팀의 집단지성을 빌릴 수 있습니다. 둘째, 개발자는 나중에 "왜 이제 와서..."라고 불평하는 대신, 개발 전에 자신의 우려를 공식적으로 전달할 통로를 갖게 되죠.

해결책 2: '결정 기록부' 작성으로 부채 시각화하기

그럼에도 불구하고 어쩔 수 없이 결정을 미뤄야 하는 순간이 찾아올 수 있습니다. 이때 중요한 것은 그 '빚'을 잊지 않고 투명하게 관리하는 것입니다. 저희는 이걸 '결정 기록부'라고 부르는데요. 회의 중에 "그건 나중에 정하죠"라는 말이 나오면, 즉시 공유된 문서에 기록하는 겁니다.

이렇게 보이지 않는 부채를 모두가 볼 수 있도록 시각화하면, 최소한 잊어버리는 일은 막을 수 있습니다. 또한 "결정 기한"을 명시함으로써, 부채가 무한정 방치되는 것을 막고 책임감을 부여하는 효과도 있죠.

해결책 3: 기획 생산성에 투자하기

앞선 두 가지가 프로세스와 문화를 통해 부채를 '관리'하는 방법이라면, 마지막은 기술을 통해 부채 발생 자체를 '방지'하고 생산성을 극대화하는 방법입니다.

저는 개발 생산성의 역사를 보고 배울 수 있다고 생각합니다. 과거 개발자들이 메모장에 코딩하던 시절을 떠올려보세요. 그랬던 그들이 이제는 GitHub Copilot과 같은 AI 코딩툴의 도움을 받아 순식간에 코드를 완성합니다. 즉, 사람을 무한정 늘리는 대신, 도구와 시스템을 통해 생산성을 극대화하는 방향으로 진화해 온 것이죠.

기획도 마찬가지입니다. 이제는 기획자의 ‘맨파워’에만 의존할 것이 아니라, 기획 생산성 자체를 높이기 위한 체계적인 도구와 시스템에 투자해야 할 때입니다.

• 불분명한 요구사항을 구조화된 기획으로 완성할 수 있도록 자동으로 초안을 작성해주고,

• '질문 폭탄 세션'에서 나올 만한 누락된 정책이나 예외 케이스를 검토해주고,

• 기능 명세서, 스토리보드 등 기획자의 리소스를 잡아먹는 반복적인 기획 문서 작업을 자동화해주는 AI 기반의 기획 도구 말입니다.

개발 생산성을 높이기 위해 수많은 도구에 투자하듯, 이제는 기획 생산성을 높이는 일에 투자해야 합니다. 그것이 결국 미래에 발생할 수십 배의 재작업 비용을 막는, 가장 현명하고 경제적인 선택일 테니까요.

마무리하며: 가장 값싼 투자는 ‘미리 하는 투자’입니다

기획 부채는 조용히, 그리고 아주 빠르게 쌓입니다. 그 빚을 깨닫는 순간은 언제나 프로젝트가 겉잡을 수 없이 흔들릴 때죠. "그때 조금만 더 신경 쓸걸"이라는 후회는 언제나 너무 늦습니다.

우리의 시간과 자원은 한정되어 있습니다. 그 한정된 자원을 가장 효율적으로 쓰는 방법은, 문제가 터진 뒤에 수습하는 것이 아니라 문제가 생기지 않도록 미리 방지하는 것입니다. 기획 생산성에 대한 투자는 비용이 아니라, 미래의 더 큰 비용을 막는 가장 확실한 '보험'입니다.

manyfast.io