컨설턴트의 논리가 1인 개발자의 발목을 잡을 때

1. "진짜 문제가 뭐야?" : 5 Whys라는 완벽주의의 함정

컨설팅의 세계에서 가장 강력한 무기 중 하나는 '왜?'라는 질문을 반복하는 것이다. 흔히 '5 Whys'라 불리는 이 기법은, 표면적인 현상 아래 숨겨진 본질적인 원인을 찾아내기 위해 최소 다섯 번은 깊게 파고들 것을 권한다. 비전공자로서 1인 개발을 시작했을 때, 나는 이 도구를 내 생존 전략으로 삼았다. 개발 숙련도가 낮으니, 기획이라도 완벽해야 실패가 없을 것이라는 방어 기제였다.

예를 들어 "서비스 유입이 적다"라는 문제에 이 사고를 적용해 보자.

1. 왜? - 홍보가 부족해서.
2. 왜 홍보를 안 했을까? - 서비스가 아직 완벽하지 않다고 생각해서.
3. 왜 완벽하지 않다고 느낄까? - 유저가 들어왔을 때 실망할까 봐 두려워서.
4. 왜 실망할까 봐 두려울까? - 내가 만든 기능들이 숙련된 개발자들의 서비스보다 조잡해 보일까 봐.
5. 왜 조잡해 보인다고 생각할까? - 비전공자라는 꼬리표와 부족한 구현 능력을 기획의 화려함으로 덮으려 하기 때문에.

결국 문제는 '홍보'가 아니라 내 안의 '심리적 열등감'으로 귀결되곤 한다. 컨설턴트 시절에는 이런 식으로 문제를 정의하고 나면 해결책이 명확해졌다. 정답이 정해진 게임을 하는 컨설턴트들에게 이 방식은 실패 없는 보고서를 만드는 최고의 필승법이었기 때문이다. 하지만 혼자서 서비스를 만드는 빌더의 세계에서는 이 '완벽한 정의'가 오히려 독이 되어 돌아왔다.

2. 8개월의 정체, 생각의 늪에 빠지다

사실 지금 배포한 서비스를 완성하는 데 순수하게 들어간 시간은 그리 길지 않다. 하지만 이 서비스가 세상에 나오기까지는 무려 8개월이라는 시간이 걸렸다. 그 공백은 기술적 난도가 높아서가 아니었다. 바로 "이게 정말 최선인가?"를 묻는 컨설턴트적 사고와 "일단 배포하고 수정하자"는 개발적 실행력이 내 안에서 격렬하게 충돌했기 때문이다.

비전공자 개발자로서 나는 늘 불안했다. 숙련된 개발자들보다 버그를 잡는 속도가 느리고, 예상치 못한 오류를 개선하는 데 몇 배의 시간이 걸린다는 것을 스스로 너무 잘 알고 있었다. 그러다 보니 자연스럽게 '실수를 줄여야 한다'는 강박이 생겼고, 이는 '더 철저한 기획'과 '더 깊은 문제 정의'라는 핑계로 이어졌다.

"버그를 고치는 데 일주일이 걸릴지도 모르니, 아예 버그가 날 확률이 적은 완벽한 로직을 기획 단계에서 짜야 해."
이런 생각이 나를 8개월 동안 책상 앞에 묶어두었다. 하지만 정답이 없는 시장에서 '생각만으로 내린 정의'는 실제 유저를 만나는 순간 여지없이 깨졌다. 내가 6번의 'Why'를 던져 도달한 결론이, 유저에게는 아무런 의미 없는 기능인 경우도 허다했다.

3. 컨설턴트의 '포장'과 서비스의 '실질 가치'

컨설턴트는 정답이 이미 어느 정도 정해져 있는 상황에서 이를 어떻게 논리적으로 구조화하고, 매력적으로 포장하느냐에 집중한다. 고객사는 컨설턴트가 제시하는 사고의 전환과 새로움에 열광하며 그 가치를 인정해준다. 하지만 서비스의 세계는 다르다. 유저들은 내 논리적 흐름이나 사고의 깊이에 전혀 관심이 없다.

내가 아무리 "이 서비스는 이러이러한 문제 정의를 거쳐 탄생한 본질적인 해결책입니다"라고 포장한들, 유저가 접속해서 3초 안에 자신의 불편함을 해결하지 못하면 그 서비스는 실패한 것이다. 최근 나는 생각을 덜어내고 무작정 만들어보는 린(Lean)한 방식을 시도하며 한 가지 뼈아픈 사실을 깨달았다. 생각을 덜어내니 실행은 빨라졌지만, 그동안 내가 강점으로 가졌던 '서비스를 매력적으로 포장하는 기술'까지 함께 빠져버린 것이다.

현재 배포한 도메인을 보면, 투박한 코드와 기능들 사이에 유저를 설득할 수 있는 '전략적 포장'이 부족하다는 것이 느껴진다. 여기서 딜레마가 발생한다. 기획에 집중하면 실행이 멈추고, 실행에만 집중하면 서비스의 매력이 사라진다. 이 사이에서 밸런스를 맞추는 것이 1인 빌더가 마주하는 가장 높은 벽이다.

4. 정답이 없는 세계에서 시간을 분배하는 법

그렇다면 컨설턴트적 사고와 린 스타트업의 실행력을 어떻게 결합해야 할까? 나는 이 고민 끝에 나만의 시간 분배 원칙을 세우기로 했다.

1. 기획의 골든타임 설정: 문제 정의를 위해 'Why'를 묻는 시간은 딱 3일로 제한한다. 5번 물어보든 6번 물어보든, 그 이상 길어지면 그것은 기획이 아니라 '망설임'이다.
2. 기술적 부채의 인정: 비전공자로서 버그와 오류는 피할 수 없는 숙명이다. "오류 없는 서비스를 만들겠다"는 기획적 오만을 버리고, "오류가 나면 유저와 소통하며 고치겠다"는 실행적 유연함을 갖는 것이다. 기획을 10% 덜어내고, 그 시간을 에러 로그를 읽는 숙련도를 높이는 데 투자하는 것이 훨씬 효율적이다.
3. 핵심 가치와 포장의 분리: 서비스의 핵심 기능은 가장 린하게 만들되, 유저가 처음 마주하는 랜딩 페이지나 브랜딩에는 컨설턴트 시절의 '포장 기술'을 집중적으로 투입한다. 전체를 완벽하게 만들려 하지 말고, 유저의 시선이 머무는 곳에만 전략적 에너지를 쏟는 방식이다.

5. 부딪혀봐야 아는 것과 안 부딪혀도 아는 것의 경계

물론 모든 것을 "일단 부딪혀보자"로 해결할 수는 없다. 전략가로서 안 부딪혀봐도 아는 것들, 즉 상식적인 UI/UX 오류나 시장에서 이미 검증된 실패 사례는 기획 단계에서 냉정하게 쳐내야 한다. 하지만 1인 개발 환경에서 우리가 겪는 대부분의 고민은 '부딪혀봐야만 알 수 있는 것들'이다.

내가 내린 문제 정의가 맞는지, 유저가 이 버튼을 누를지, 이 수익 모델이 작동할지는 코드를 배포하기 전까지는 절대 알 수 없다. 8개월이라는 시간은 나에게 '완벽한 지도는 없다'는 것을 가르쳐주었다. 중요한 것은 지도를 그리는 능력이 아니라, 정글 속에서 나침반을 보며 끊임없이 경로를 수정하는 '생존 근육'이었다.

비전공자 개발자이기 때문에 더 잘 준비하고 싶은 마음은 이해한다. 하지만 그 마음이 당신을 멈추게 한다면, 그것은 더 이상 준비가 아니라 장애물이다. 숙련된 개발자보다 느리다는 사실을 인정하고, 그 느린 속도에 맞춰 더 일찍, 더 자주 시장에 내 서비스를 던져야 한다.

6. 결국 중요한 건 '지속 가능한 균형'

결국 이 세계에 정답은 없다. 컨설턴트의 사고로 내실을 다지되, 그 사고가 내 발걸음을 무겁게 만들지 않도록 경계하는 것. 완벽한 정의보다 중요한 건, 오늘 하루 유저에게 전달할 '작은 가치' 하나를 실제로 구현해내는 일이다.

8개월의 시간은 낭비가 아니었다. 그 시간을 통해 나는 '생각의 속도'와 '손의 속도'를 맞추는 법을 배웠다. 이제 나는 다시는 생각 때문에 멈추지 않을 것이다. 5번의 질문으로 본질을 꿰뚫고, 6번째에는 주저 없이 코드를 입력할 것이다. 그렇게 만들어진 투박한 서비스가 유저의 피드백을 만나 다듬어질 때, 비로소 컨설턴트의 논리와 빌더의 실행력이 하나로 합쳐지는 진정한 '성과'가 나타날 것이라 믿는다.