기획은 속도가 생명이다

"기획은 속도가 생명이다"

제가 주니어 기획자였을 때의 일입니다. 새로운 기능 개발을 맡게 되었는데, 정말 ‘완벽한 기획서’를 써서 모두를 놀라게 해주고 싶었죠. 사용자 정책부터 온갖 예외 케이스, 심지어는 버튼 위에 마우스를 올렸을 때의 색깔 변화까지… 거의 모든 예외 상황과 디테일을 잡아내겠다고 2주 넘게 기획서만 붙잡고 있었습니다.

드디어 제가 생각하는 ‘완벽한’ 기획서를 들고 개발팀에 찾아갔던 날을 잊을 수가 없네요. 뿌듯한 마음으로 설명을 마쳤는데, 시니어 개발자분께서 갸우뚱하시며 첫 질문을 던지셨습니다.

“그런데 이 기능을 구현하려면 유저 DB 테이블 구조를 좀 바꿔야 할 것 같은데요? 혹시 기존 데이터 마이그레이션 정책도 고려되신 건가요?”

‘마이그레이션…?’

그 질문을 시작으로, 제가 미처 생각지 못했던 기술적 제약, 비즈니스적 허점들이 터져 나오기 시작했습니다. 결국 그 ‘완벽했던’ 기획서는 3일 만에 누더기가 되었고, 저는 거의 처음부터 다시 시작해야 했죠.

아마 많은 기획자, 혹은 디자이너, 개발자분들이 비슷한 경험을 해보셨을 겁니다. 우리는 왜 이런 ‘삽질’을 반복하는 걸까요? 오늘은 기획에서는 완벽함보다는 빠른 속도가 중요하다는 내용을 말씀드리고자 합니다.

1. 처음부터 완벽한 기획은 ‘허상’입니다

많은 주니어 기획자들이, 심지어 시니어 기획자까지도 ‘완벽한 기획서’에 대한 환상을 가지고 있습니다. 빈틈없는 논리로 쓰여져 이 기획서만 읽으면 개발자들이 바로 일을 시작할 수 있고, 대표님의 감탄사를 자아내는 그러한 기획서요. 아마도 개발자나 디자이너 같은 팀원들이 기획에 말을 얹기 시작한다면, 기획자인 내 전문성은 무엇인가 하는 불안감이 생겨서 그럴지도 모르죠. 하지만 불운하게도, 이 세상에는 그러한 ‘처음부터 완벽한 기획’은 존재하기 어렵습니다.

기획자: “이번 신규 기능 기획서입니다. 모든 예외 처리와 정책까지 상세하게 담았습니다.”

개발자: “음… 기획은 좋은데, 이걸 기획서대로 구현하려면 서버 비용이 지금보다 2배는 더 나올 것 같아요. 이 부분은 로직을 좀 단순화해야겠는데요?”

마케터: “기능은 좋은데, 요즘 사용자들은 이렇게 복잡한 가입 절차를 싫어해요. 중간에 이탈이 너무 많을 것 같은데요?”

대표: “핵심 기능은 좋은데, 우리 회사의 장기적인 비전과는 조금 안 맞는 부분이 있네요. 이 부분은 다시 생각해 봅시다.”

기획자가 머릿속에서 아무리 완벽한 시뮬레이션을 돌려도, 막상 밖으로 기획을 꺼내 놓는 순간 수많은 변수와 마주하게 됩니다. 각자의 입장에서 나오는 예상치 못한 피드백들이 쏟아지죠.

결국 진짜 ‘완벽한 기획’을 향한 길은, 혼자 머리를 싸매고 있는 시간이 아니라, 일단 불완전한 초안이라도 빠르게 공유하고, 팀원들과 함께 완성도를 높여가는 과정에 있습니다. 내 기획서는 완성본이 아니라, 똑똑한 동료들의 지혜를 모으기 위한 ‘재료’일 뿐이라고 생각하는 순간, 일의 속도는 완전히 달라지기 시작합니다.

2. 기획은 ‘커뮤니케이션의 시작’입니다

기획이 늦어지는 가장 큰 비용은 기획자 한 명의 시간이 아닙니다. 바로 팀 전체가 멈춰 서는 시간입니다.

기획자가 ‘완벽’을 위해 일주일을 더 고민하는 동안, 개발자는 무엇을 할 수 있을까요? 디자이너는 어떤 화면을 그려야 할까요? 기획서가 나와야 할 일이 생기는 동료들은 하염없이 기다리며 귀한 시간을 흘려보내게 됩니다(물론 다들 그 시간을 활용해서 공부도 하고, 여러 미뤄뒀던 일을 처리하겠지만요!). 이건 정말 엄청난 자원 낭비죠.

빠른 기획은 이 모든 것을 바꿔 놓습니다.

• 기획 초안 공유 (1일 차): “여러분, 제가 생각하는 큰 그림은 이거예요. 상세한 정책은 미정이지만, 핵심 사용자 흐름은 이렇습니다. 어떻게 생각하세요?”

• 피드백 미팅 (2일 차): 개발자는 기술적 리스크를, 디자이너는 UX 허점을, 마케터는 시장의 반응을 예측하며 아이디어를 쏟아냅니다. 혼자서는 절대 볼 수 없었던 것들이 보이기 시작하죠.

• 기획 구체화 (3일 차): 함께 나눈 논의를 바탕으로 기획서를 구체화합니다. 이제 이 기획서는 더 이상 기획자 한 명의 것이 아니라, ‘우리 팀 모두의 기획’이 됩니다.

기획서는 토론을 위한 ‘의제’입니다. 의제가 빨리 나와야 회의가 시작되고, 회의가 활발해야 더 좋은 결론이 나옵니다. 빠른 기획은 팀에게 더 많은 커뮤니케이션 기회를 제공하고, 이는 곧 제품의 퀄리티와 성공 확률을 높이는 가장 확실한 길입니다.

3. 매몰 비용은 적을수록 좋습니다

혹시 ‘매몰 비용의 오류(Sunk Cost Fallacy)’라는 말을 들어보셨나요? 이미 투입한 시간이나 돈이 아까워서, 전망이 없는 일인 줄 알면서도 계속 끌고 나가는 심리적 편향을 말합니다.

이는 기획에서도 똑같이 적용됩니다.

상황 A (느린 기획): 기획자가 한 달 동안 모든 것을 쏟아부어 100페이지짜리 기획서를 만들었습니다. 중간에 시장 상황이 바뀌어 이 프로젝트가 성공하기 어렵다는 걸 모두가 어렴풋이 느끼고 있습니다. 하지만 누구도 쉽게 말을 꺼내지 못합니다. “저분이 한 달을 고생했는데…”, “이미 들어간 시간이 얼만데…” 결국 팀은 잘못된 길인 줄 알면서도 어쩔 수 없이 프로젝트를 시작합니다.

상황 B (빠른 기획): 기획자가 3일 만에 핵심 아이디어만 담은 5페이지짜리 기획서를 공유했습니다. 팀원들과 논의하던 중, 이 아이디어의 치명적인 약점을 발견했습니다. 팀은 빠르게 방향을 수정하거나, 더 나은 아이디어를 탐색하기로 결정합니다. 잃은 것은 기획자의 3일뿐입니다.

빠르게 내놓은 기획은 실패하더라도 부담이 적습니다. 언제든 쉽게 방향을 틀거나 버릴 수 있죠. 매몰 비용이 적기 때문입니다. 실패는 나쁜 것이 아니라, 더 큰 실패를 막기 위한 ‘값싼 학습’입니다. 빠른 기획은 우리 팀에게 이런 ‘값싼 학습’의 기회를 더 자주 제공해 줍니다.

4. 느린 100%보다 빠른 80%

물론 제가 ‘아무렇게나 생각나는 대로 기획안을 던지라’고 말하는 것은 절대 아닙니다. 빠른 기획에도 반드시 지켜야 할 최소한의 원칙이 있습니다. 바로 ‘핵심 80%에 집중하는 것’이죠.

제품 기획의 100%를 채우는 과정은 보통 이렇습니다.

• 0% → 80%: 이 제품을 왜 만드는가? (목표), 누구를 위한 것인가? (타겟), 핵심 기능은 무엇인가? (주요 플로우), 비즈니스 모델은? (수익 구조) 등 제품의 뼈대를 잡는 과정

• 80% → 100%: 회원 탈퇴 시 안내 문구, 비밀번호 찾기 실패 시 에러 메시지, 로딩 아이콘 모양 등 세부적인 예외 처리와 디테일을 다듬는 과정

0에서 100까지 모든 것을 기획자가 완성하려 한다면, 십중팔구 길을 잃기 마련입니다. 일단 80%까지만 빠르게 달리는 게 중요합니다. 가장 중요한 제품의 뼈대와 방향성에 대한 합의를 먼저 이끌어내는 거죠. 그 후에 나머지 20%는 개발, 디자인을 진행하면서 팀원들과 함께 채워나가도 늦지 않습니다.

마무리하며: 기획자는 ‘완성가’가 아닌 ‘촉진자’입니다

과거의 기획자가 건축의 ‘설계사’처럼 완벽한 도면을 책임지는 사람이었다면, 현대의 기획자는 팀의 집단지성을 이끌어내는 ‘토론의 촉진자(Facilitator)’에 가깝습니다.

내 손에서 완벽한 결과물을 내놓으려는 욕심을 조금만 내려놓아 보세요. 대신, “어떻게 하면 우리 팀의 똑똑한 동료들을 더 빨리, 더 자주 대화하게 만들 수 있을까?”를 고민해 보세요. 그 고민의 끝에 ‘빠른 기획’이 있고, 그것이 곧 당신과 당신의 팀을 성공으로 이끄는 가장 강력한 무기가 될 것입니다.