일단 문제를 만드는게 중요하다.

대부분의 사람들은 어떤 일을 진행할 때, 무슨 일이 벌어질지부터 걱정합니다.
그러나, 말도 안되는 것 같지만 현업에서는 문제를 일단 '만드는' 것이 가장 중요하다는 것, 알고 계신가요?

물론 여기서 '문제를 만든다'는 것은 단순히 오류나 버그를 일부러 일으키는 것을 이야기 하는게 아니라,
정확히는 해결해야 할 가장 중요한 문제 하나에 집중하는 것이죠.

그리고 해결해야 할 문제가 선정되면, 이후에 나타나는 다른 문제들은 그저 발생하는대로 차근차근 해결해 나가면 됩니다.

'분석 마비'가 발생하는 순간

자주 있을만한 예시를 들어 설명해보겠습니다.
새로운 기술 스택도 익힐 겸, 아이디어가 떠올라서 사이드 프로젝트를 시작하려던 경험은 다들 한 번쯤 있으실겁니다.
제 경우에는 처음에는 '간단한 기능 하나만 구현해보자'라는 생각으로 시작해보곤 합니다.

그런데 조금만 더 깊게 들어가는 순간, 머릿 속이 복잡해지기 시작합니다.
"이왕 만드는거, 소셜 로그인도 붙여보고, 이런 기술스택도 필요할거고, 모니터링도 붙여보자. 하는 김에 클린 아키텍처도 적용해서 포트폴리오로 써볼까?"

결국 최초의 목표는 '아이디어를 구현해서 프로젝트를 완성시키는 것'인데, 우리는 어느샌가 이 본질에서 멀어지고 '완벽한 기술의 집합체'를 만들고자 합니다.
그러나 결국 '완벽한' 구상만 하다가 정작 코드는 더 이상 작성하지 못한 채 소중한 주말 저녁을 고민만 하다 보내고, 그 프로젝트 폴더는 어느샌가 잊혀져 가죠.

우리에게 익숙한 이런 경험이 바로 '완벽한 계획'이라는 환상이 주는 '분석 마비'입니다.
시작도 하기 전에 미래의 모든 문제를 해결하고자 하는 것으로 인해, 가장 중요한 '실행'의 동력을 잃어버리는거죠.

우리가 시작도 전에 모든 문제를 해결하려고 하는 이유는, 미래에 어떤 문제가 다가올지 몰라서 '불안'하기 때문입니다.

그러나 불안감을 이겨내고 일단 문제를 만드는데 집중해야합니다.
수많은 불확실성 속에서, 단 하나의 문제를 명확하게 정의하는거죠.

예를 들어 개인이 공부를 위한 사이드 프로젝트라면, "사용자는 ID와 비밀번호로 로그인에 성공하고, 세션 토큰을 발급받는다"라고 문제를 단순하고 명확하게 만들었다면, 이것이 우리가 해결해야 할 첫 번째 문제입니다.

이 문제를 해결하는 과정에서 '잘못된 비밀번호', '존재하지 않는 ID'와 같은 부차적인 문제들은 자연스럽게 나타날 것이고, 그런 문제들은 그 때 가서 해결하셔도 됩니다.

회사에서도 똑같이 반복되는 문제

이러한 상황은 개인에게만 발생하는게 아닙니다.

내가 쇼핑몰의 '결제 전환율 개선' 프로젝트 담당자라고 상상해봅시다.
이 명확한 목표를 달성하기 위해 기획 회의를 소집할 것이고, 팀 단위의 '분석 마비'가 시작됩니다.

개발자: "이번 기회에 레거시 결제모듈을 걷어내고, UX가 편한 최신 PG사 연동 시스템으로 바꾸면 어떨까요?"
디자이너: "결제 플로우 전체의 UX를 개편해야 의미가 있을 것 같아요! 새로운 방법으로 A/B 테스트를 해보면 어떨까요?"
마케터: "결제 직전의 이탈자를 잡기 위해서 쿠폰 자동발급이나, 친구추천 할인 기능을 추가해보면 어떤가요?"

모두 맞는 말이고, 언젠가는 해야 할 일들일겁니다.
하지만 이 모든 것이 '결제 전환율 개선'이라는 하나의 프로젝트에 포함되는 순간, 이 프로젝트는 대규모 사업으로 변질될 것이고, 그 누구도 손대기 어려워하는 상태가 되어버립니다
마치, 사이드 프로젝트에서 그랬던 것처럼요

이렇듯 수많은 '해야 할 일'들의 목록 속에서 가장 날카롭고 중요한, 단 하나의 문제를 정의해야합니다.

데이터를 살펴본 결과, 가장 많은 고객(40%)이 '복잡한 주소 입력과 배송비 계산' 단계에서 이탈하는 것을 발견했다고 가정해보죠.
그렇다면 우리가 만들어야 할 문제는 명확해집니다.

"이번에는 일단 '주소 입력' 단계의 UI를 간소화하고, '주소 검색 API'를 도입해서 이탈률을 20% 감소시키는 것으로 하시죠."

이 한마디로 인해 기존에 이야기 되었던 다른 기능들은 뒤로 미뤄지고, 모든 팀의 초점이 '주소 입력 단계'에 집중됩니다.
그리고 이 문제를 해결하는 과정에서 아래와 같은 문제들이 자연스럽게 따라붙게되죠.

"주소 검색 API는 어떤 업체의 것을 사용해야 성능과 비용이 합리적일까?"
"간소화된 UI를 모바일 화면에서는 어떻게 최적화해서 보여줄 것인가?"
"새로운 주소 데이터 포맷을 기존 주문 데이터베이스에 어떻게 저장할 것인가?"

이렇듯, 이 문제들은 더 이상 프로젝트의 '장애물'이 되지 않습니다.
단지 핵심 목표를 달성하기 위한 하위 태스크일 뿐이죠.
백로그에 티켓을 등록하고, 담당자를 할당하고, 코드를 작성하며 앞으로 나아갑니다.

일단 문제를 만들어라

이렇게 하나의 문제를 해결하고 나면, 이탈률 감소라는 구체적인 경험과 데이터를 얻습니다.
실패해도 괜찮습니다. 어떤 부분을 놓쳤는지 회고하고, 다시 문제를 정의하면 되니까요.

이것이 바로 현업에서 문제를 만들어내는 행위의 본질입니다.
불확실성의 속에서 가장 중요한 단 하나의 문제를 찾고, 팀 전체가 그 문제를 해결하며 나아가는 것이죠.

완벽한 프로젝트만을 생각하다가 시작도 못하는 것보다, 목적지 하나를 잡고 일단 한발자국 내딛는 것이 훨씬 현명한 일입니다.
그러니 우선, 걱정만 하기보다는 문제를 만들어보세요!