2026 All-Day-Project (054/365)
기획자의 일상에서 '문제 해결'은 가장 흔하게 쓰이면서도 가장 오염된 단어다. 회의실에서 우리는 종종 이런 요청을 마주한다. "사용자가 가입하기 편하게 구글 로그인 하나 넣어주세요." 이때 기획자가 이 요청을 그대로 백로그에 옮겨 적는다면, 그는 문제를 정의한 것이 아니라 해결책을 수납한 것에 불과하다. 명백히 해결책이다. 하지만 우리는 이를 '풀어야 할 문제'라고 적어 넣는다. 기획자가 마주해야 할 진짜 싸움은 이 지점, 즉 해결책이라는 이름의 색안경을 벗고 문제의 맨얼굴을 마주하는 'Step 0'에서 시작된다.
철학자 데이비드 흄은 '사실(IS)'에서 '당위(OUGHT)'를 직접적으로 이끌어낼 수 없다고 했다. 제품 기획의 영역에서 문제는 바로 이 두 지점 사이의 격차다. 현재 사용자가 처해 있는 기술적, 환경적 현실인 'IS'와, 제품을 통해 도달하고자 하는 이상적인 상태인 'OUGHT' 사이의 거리가 곧 문제의 깊이다.
예를 들어 단순히 "여름이 덥다"는 것은 문제가 아니다. 쾌적한 온도(OUGHT)를 원하는 인간의 욕망과 35도라는 기온(IS)이 충돌할 때 비로소 문제가 발생한다. 기획자는 대시보드의 평균치 뒤에 숨겨진 개별 사용자의 삶으로 내려가 이 간극을 원자 수준에서 관찰해야 한다. 단순한 통계 수치가 아니라, 구체적인 결핍의 현장을 온전한 문장으로 적어 내려갈 때 진짜 문제가 드러난다. "사용자는 현재 A라는 상황(IS)에 처해 있어 B라는 행동(OUGHT)을 하고 싶어 하지만, C라는 제약 때문에 불가능하다"는 식의 정의가 필요하다. 이 격차를 정교하게 측정하는 것이 기획의 본질이며, 이를 수행하는 사람이 바로 '문제 프로파일러'다.
문제가 정의되었다면, 이제 그 깊고 넓은 간극 위에 다리를 놓아야 한다. 여기서 전략과 전술의 개념이 나뉜다.
전략(Strategy)은 '어떤 종류의 다리를 놓을 것인가'에 대한 고수준의 결정이다. 경쟁사보다 압도적으로 저렴하게 간극을 메울 것인지, 아니면 누구도 따라올 수 없는 우아한 경험으로 사용자를 건너게 할 것인지 결정하는 것이다. 전략은 한정된 팀의 에너지를 어디에 집중할지 결정하는 작업이다. 즉, 백로그라는 정원에서 어떤 가지를 쳐내고 어떤 줄기를 키울지 선언하는 고통스러운 과정이기도 하다. 하지 않을 일을 명확히 할 때 비로소 다리의 방향이 흔들리지 않는다. 깊을수록 사용자는 절실해지고, 기획자가 설계한 전략이 유효할수록 제품의 생존 가능성(Viability)은 높아진다.
반면 전술(Tactics)은 그 다리를 만들기 위해 동원하는 구체적인 벽돌과 도구들이다. 스프린트 주기, 백로그 관리, 특정 기능의 UI 컴포넌트 설계 등이 전술에 해당한다. 아무리 전술이 훌륭하여 벽돌을 빠르게 쌓는다 해도, 전략이 틀려 다리가 엉뚱한 방향으로 향하고 있다면 그 속도는 소음일 뿐이다. 반대로 전략이 좋아도 전술적 실행력이 뒷받침되지 않으면 다리는 완공되지 못한다.
기획자가 설계한 이 '다리'의 가치는 경제적 언어로 환산된다. 여기서 가치의 핵심 공식인 WTP와 Price가 등장한다.
WTP(Willingness to Pay)는 사용자가 이 간극을 해소하기 위해 지불할 용의가 있는 최대 금액이다. 고객은 제품의 스펙이 아니라 자신이 처한 곤경에서의 탈출, 즉 진전(Progress)을 구매한다. 기획자가 사용자가 차마 언어화하지 못했던 숨겨진 욕구(Latent Desire)를 건드릴 때, WTP는 단순한 지불 금액을 넘어 제품에 대한 열망으로 변한다.
기획자가 최종적으로 창출하는 가치(Value)는 'WTP - Price'의 크기다. 아무리 훌륭한 전략으로 다리를 놓아도, 사용자가 느끼는 격차 해소의 가치(WTP)보다 제품의 가격(Price)이 비싸다면 그 제품은 선택받지 못한다. 기획자는 사용자의 WTP와 제품의 가격, 그리고 생산 원가(Cost) 사이의 관계를 조율하는 오케스트레이터가 되어야 한다. 때로는 전략적 불균형을 통해 단기적으로 가격을 낮춰 점유율을 확보하고, 장기적으로 더 큰 격차를 해결하여 팬덤을 형성하는 설계가 필요하다.
결국 기획이란 세상의 결핍을 발견하고, 그것을 해결할 수 있는 가설로 치환하는 작업이다. "무엇을 만들까"라는 기술적 질문에 함몰되기 전에, "우리가 어떤 간극을 메우려 하는가"라는 본질적 질문을 먼저 던져야 한다.
글쎄, 문제를 정의하는 과정은 참 고통스럽다. 코드나 디자인처럼 눈에 보이는 결과물이 즉각 나오지 않기 때문이다. 하지만 기획자가 멈춰 서서 문제를 고민하는 시간은 지체가 아니라 투자다. 학습 없는 속도는 방향 잃은 에너지에 불과하지만, 올바른 문제 정의에서 시작된 실행은 지식 복리를 일으키며 누구보다 빠른 학습 속도(Learning Velocity)를 만들어낸다.
문제를 푼다는 것은 단순히 불편함을 제거하는 행위를 넘어, 사용자의 삶에 긍정적인 '진전(Progress)'을 만들겠다는 기획자의 성의(誠意)가 담긴 약속이다. 오늘 당신이 적어 넣은 백로그의 첫 줄은 '기능'인가, 아니면 '간극'인가? 나는 오늘도 다시 묻는다. "우리가 메우려는 진짜 격차는 무엇인가?"