좋은 기획은 논리를 잘 따르는 것보다, 당연한 논리를 다시 묻는 데서 시작됩니다
논리 구조나 사고의 틀에 갇혀 더 나은 것을 생각하지 못할 때가 있습니다. 특히 PM은 "원래 이렇게 하는 것"이라는 흐름을 너무 빨리 받아들이기 쉬워요. 이번 글에서는 Abstraction, 즉 추상화를 통해 당연하다고 여겼던 흐름을 다시 보고, 고객 관점에서 제품과 문제를 비틀어 생각하는 방법을 함께 고민해보고자 합니다.
작성자: 멘토 Parker
15초 요약
좋은 PM은 논리를 잘 따르는 사람이 아니라, 그 논리가 정말 필요한지 다시 묻는 사람입니다.
기획을 오래 하다 보면 A 다음에는 B, B 다음에는 C가 와야 한다고 자연스럽게 믿게 됩니다. 그런데 고객에게 중요한 건 그 논리 구조가 얼마나 정교한지가 아니라, 불편한 단계를 얼마나 덜어냈는지예요.
Abstraction은 복잡한 세부 구현을 감추고 핵심 개념만 남기는 사고 방식입니다. PM에게는 "이 단계가 정말 고객에게 필요한가?", "이 흐름을 아예 없앨 수는 없나?"라고 묻는 훈련에 가깝습니다. 혁신은 대개 논리를 더 예쁘게 정리하는 데서가 아니라, 당연하다고 믿었던 논리를 의심하는 데서 시작됩니다.
알아두면 좋은 용어
- Abstraction(추상화): 복잡한 대상의 세부 사항을 숨기고 핵심 개념이나 공통 원리만 남겨 더 높은 수준에서 이해하고 작업할 수 있게 만드는 과정입니다.
- 인터페이스(Interface): 사용자가 기능을 활용하기 위해 마주하는 접점입니다. 내부 구현을 몰라도 인터페이스만 이해하면 기능을 사용할 수 있습니다.
- 논리 구조: 특정 목표를 달성하기 위해 단계와 순서를 배열한 흐름입니다. 제품 기획에서는 화면 전환, 업무 프로세스, 결제 플로우 등이 여기에 해당됩니다.
- 고객 관점 설계: 내부 구현이나 조직의 편의가 아니라, 고객이 느끼는 불편과 목적을 기준으로 흐름을 다시 설계하는 방식입니다.
- 단계 제거: 기존 프로세스를 더 보기 좋게 만드는 것이 아니라, 고객에게 필요 없는 단계를 아예 없애는 접근입니다.
Y's Insight
오늘의 Y's Insight는 쿠팡, 카카오, 토스 등 다양한 산업군과 조직을 경험한 현업 PM 14년차 멘토 Parker가 작성하였습니다.
저는 논리적인 기획이 정답이라고 배웠어요
사회 초년생 때, 기획이라는 업무를 배울 때는 논리적인 사고에 맞는 기획을 하는 것이 정석인 시절이 있었어요.
사실 기획이라는 것이 명확한 학문이나 자격증이 있는 영역은 아니잖아요. 실제로는 회사에서 업무를 하면서, 선배에게 배우면서, 어깨너머로 보고 귀동냥과 눈동냥을 하면서 익혔던 것 같습니다.
특히 저의 기획 경험은 시스템이나 앱 기획이었기 때문에 논리 구조가 중요하다고 생각했습니다.
논리 구조라 함은 쉽게 말해 이런 것입니다.
- A 다음에는 B가 있어야 한다.
- B 다음에는 C가 있어야 한다.
- 마지막은 항상 Z로 끝나야 한다.
예를 들어 커머스의 결제 과정을 보면 보통 이런 흐름을 떠올립니다.
- 구매하고자 하는 상품을 장바구니에 담는다.
- 장바구니에 담은 상품 중 실제 결제할 상품을 선택한다.
- 어떤 결제 방식으로 할지 선택한다.
- 결제 방식에 따른 인증을 진행한다.
- 결제 세부 정보를 입력한다.
- 결제 사항이 맞는지 확인한다.
- 결제가 완료된다.
이런 일련의 과정이 너무 당연한 흐름처럼 보입니다. 저도 그렇게 배웠고, 그렇게 일했습니다.
당시 국내 IT 업계는 논리 구조를 중시했습니다. 10년 전만 해도 복잡하고 귀찮은 과정을 획기적으로 줄이는 것보다, 이 번거로운 과정을 어떻게 더 예쁘게 표현할지를 더 많이 고민했던 것 같아요. 디자인 측면에서 더 신경 쓰는 방식이었죠.
그때는 그게 당연했습니다. 기술의 발전이 지금보다는 현저히 낮았으니까요. 그 시절에는 그게 최선의 기획이었습니다.
느린 엘리베이터 속도를 획기적으로 높일 수 없으니 거울을 설치하는 것과 비슷합니다. 사람들이 거울을 보게 해서 엘리베이터 안에서의 기다림을 덜 지루하게 만드는 거예요. 근본 문제를 직접 해결할 수 없으니, 대체 방법으로 문제를 완화하는 식이었죠.
그런데 논리는 사고를 굳게 만들기도 해요
이런 논리로 몇 년씩 일하다 보니, 저는 이 흐름에서 벗어나는 기획이 나오면 이상하다고 생각하기 시작했습니다.
그러면서 점점 제 논리와 사고는 경직되기 시작했던 것 같아요. "왜?"라는 물음을 갖지 않게 되는 거죠. 그냥 당연히 받아들여야 하는 흐름과 과정이라고 생각하니까요.
- 왜 A 다음에는 반드시 B가 나와야 하지?
- C로 한 번에 갈 수는 없나?
- 왜 시작은 항상 A여야 하지?
- C부터 시작하면 안 될까?
- 왜 Z가 마지막이어야 하지?
- 처음의 A가 마지막이 될 수는 없을까?
이와 같은 생각을 할 수가 없게 되었습니다. A 다음에는 당연히 B여야만 한다고 믿었으니까요. 그러니 제 사고 안에서는 다른 흐름이 이상해 보였던 겁니다.
그런데 우리가 일상에서 접하는 좋은 제품들을 보면, 기존의 흐름과 과정을 파괴한 제품이 많습니다.
- 우르오스: 샴푸, 린스, 세안제, 바디워시를 따로 쓰는 단계를 합쳐 샤워의 단계를 줄입니다.
- 쿠팡: 상품을 선택하고 구매하기 버튼만 누르면 복잡한 결제 과정 없이 결제가 완료됩니다. 심지어 배송도 당일 또는 익일에 도착합니다.
- 토스: 송금할 상대방의 계좌번호를 몰라도 됩니다. 계좌번호를 물어보고 복사하고 붙여 넣을 필요 없이 휴대폰 연락처에서 선택하면 송금이 됩니다.
- 테슬라: 제품 제조와 제어 구조를 단순화하기 위해 기계식, 버튼식 제어 부품을 디스플레이 안으로 넣어 시스템화했습니다.
혁신 기업들은 특정 단계를 더 예쁘게 만드는 데서 멈추지 않습니다. 고객에게 필요 없는 단계를 없애버립니다.
물론 고객이 모르는 뒷단에는 엄청나게 복잡한 설계와 시스템이 있습니다. 하지만 고객 앞에서는 불편함과 번거로움을 최소화하는 방향으로 제품을 만들어냅니다.
쿠팡에서 Abstraction을 절실히 배웠어요
이러한 혁신이 가능하려면 갇힌 사고를 밖으로 꺼내야 합니다. 그런데 뇌의 구조를 한 번에 바꾸기는 쉽지 않아요. 성격처럼 굳어지기도 하거든요.
그래서 우리는 늘 Abstraction을 통해 사고를 확장해야 합니다. 더 쉬운 말로 하면, 비틀어서 생각하기 또는 고객 관점의 설계라고도 말할 수 있을 것 같아요.
저는 쿠팡에서 재직할 때 Abstraction에 대해 절실히 느끼기 시작했습니다. 쿠팡은 외국인 임직원이 많았고, 그들은 늘 이런 식으로 질문했습니다.
- A 다음에 C가 올 수는 없습니까?
- E 다음에 C가 올 수는 없습니까?
- C에서 Z로 바로 갈 수는 없습니까?
한국의 주입식 교육의 문제인지는 모르겠지만, 함께 일했던 외국인 동료들은 저의 사고방식과 많이 달랐습니다.
처음에는 이런 사고방식의 차이 때문에 많이 힘들기도 했어요. 누가 봐도 이상하고, 안 된다고 생각했으니까요. 그런데 결국 새로운 사고가 시작되면, 어느새 그 새로운 사고는 제품화되고 혁신이 되었습니다.
쿠팡에서 이런 것들을 많이 배웠던 것 같아요.
추상화는 복잡함을 없애는 게 아니에요
여기서 중요한 점이 하나 있습니다.
Abstraction은 복잡함을 없애는 것이 아닙니다. 고객이 직접 마주해야 할 복잡함을 제품의 뒷단으로 옮기는 것에 가깝습니다.
토스 송금이 쉬운 이유는 송금 시스템 자체가 단순해서가 아닙니다. 고객이 계좌번호를 몰라도 송금할 수 있도록, 복잡한 매칭과 인증과 검증을 제품 안쪽에서 처리하기 때문입니다.
쿠팡 원터치 결제가 쉬운 이유도 결제 시스템이 단순해서가 아닙니다. 결제 수단 저장, 인증, 리스크 관리, 주문 생성, 재고 확인, 배송 연결이 뒷단에서 촘촘히 맞물려 있기 때문입니다.
PM이 해야 할 질문은 "이 단계가 논리적으로 맞는가?"에서 끝나면 안 됩니다.
"이 논리를 고객이 직접 겪어야 하는가?"까지 물어야 합니다.
논리적으로는 맞지만 고객에게는 불필요한 단계가 있습니다. 내부 조직에는 편하지만 고객에게는 번거로운 흐름도 있습니다. 기획서에서는 아름답지만 실제 사용 장면에서는 피곤한 프로세스도 있어요.
좋은 기획은 논리를 없애는 것이 아니라, 고객이 굳이 겪지 않아도 되는 논리를 제품 안쪽으로 숨기는 일입니다.
이런 액션을 취해보세요
다음에 어떤 흐름을 기획하거나 개선할 때, "왜?"라는 질문을 다섯 번만 해보세요.
첫째, 당연한 단계 하나를 고르세요.
예를 들어 회원가입, 장바구니, 결제 인증, 승인 요청, 입력 폼, 확인 팝업 같은 단계입니다. 팀 안에서 "이건 당연히 있어야죠"라고 말하는 단계일수록 좋습니다.
둘째, 그 단계가 필요한 이유를 적어보세요.
"법적으로 필요해서", "운영팀이 확인해야 해서", "개발 구현상 필요해서", "사용자 실수를 막기 위해서"처럼 이유가 나올 거예요. 여기서 멈추지 마세요.
셋째, 그 이유에 다시 왜를 붙이세요.
왜 운영팀이 확인해야 하나요? 왜 사용자가 직접 입력해야 하나요? 왜 실수를 막기 위해 확인 팝업이어야 하나요? 왜 시스템이 대신 판단하면 안 되나요?
넷째, 고객이 보지 않아도 되는 것을 표시하세요.
고객이 반드시 직접 해야 하는 일과, 시스템이 대신 처리할 수 있는 일을 나눠보세요. 여기서 Abstraction의 기회가 보입니다.
다섯째, 한 단계를 없앤 버전을 그려보세요.
완벽한 솔루션이 아니어도 괜찮습니다. "만약 이 단계가 없다면?"이라는 버전을 한 번 그려보는 것만으로도 사고가 확장됩니다.
이 연습을 반복하다 보면 당연한 것이 당연하게 보이지 않게 됩니다. 뜻밖의 생각이 떠오르기도 하고, 오히려 논리가 더 탄탄해지기도 합니다. 그리고 구현까지 해낸다면, 그것이 혁신이 될 수도 있습니다.
근데 말이죠
그렇다고 모든 논리를 파괴해야 하는 것은 아닙니다.
어떤 단계는 고객에게 귀찮더라도 반드시 필요합니다. 보안, 법적 고지, 책임 확인, 고위험 거래의 재확인처럼 사용자를 보호하기 위해 남겨야 하는 단계도 있어요.
문제는 그 단계가 정말 필요한지 검토하지 않은 채, "원래 그런 것"이라고 받아들이는 태도입니다.
단계를 없애는 것이 능사는 아닙니다. 단계를 없앴을 때 고객이 더 불안해지거나, 실수가 늘어나거나, 내부 시스템이 감당할 수 없는 리스크가 생긴다면 그건 좋은 추상화가 아닙니다. 좋은 Abstraction은 고객의 부담을 줄이면서도 시스템의 책임은 더 단단하게 가져가니까요.