작게 그리고 불편하게 시작하기

# 작게 그리고 불편하게 시작하기 이번 주 노마드워커스쿨 오프라인 모임에서 제가 가장 많이 한 말이 있습니다. "조금 더 작게 나누어 해보세요." "조금 더 자주 반복해보세요." "최소 기능만 빠르게 만들어보세요." "사용자에게 직접 피드백을 받아보세요." 참여자들이 가져온 아이디어는 모두 훌륭했지만, 대부분 처음부터 완벽하게 준비하려 했습니다. 완성형 제품을 한 번에 만들겠다는 마음가짐이었죠. 그게 낯설지 않았던 이유는 저희 팀도 예전에 똑같이 그랬기 때문입니다. 체커블에 '늦은 제출 허용' 기능을 만들 때 저희는 아주 큰 그림부터 그렸습니다. 기간 단위를 시간·일·주로 설정하고, 감점 비율을 조정하고, 참여자별 예외 처리와 자동 알림 기능까지 포함된 완전한 시스템을 계획했죠. 기획 문서는 수십 페이지가 되었고, 개발 일정은 최소 3주였습니다. 하지만 막상 시작하려니 불안했습니다. "정말 사용자들이 이 모든 걸 원할까?" "혹시 우리 머릿속에서만 필요한 기능은 아닐까?" "3주나 투자했는데 '이건 아닌데요'라는 반응이 나오면 어떡하지?" 그동안 제품을 만들어 가면서 깨달은 건, 말로만 정리해서는 절대 소통되지 않는다는 점입니다. 같이 오래 일한 사람들끼리도 '간단한 기능'의 기준이 다르고, 사용자와 이야기하면 그 차이는 훨씬 커집니다. 또한 사용자는 불편함을 느끼지만 그것을 '기능'으로 구체화하지 못합니다. 아무리 인터뷰를 하고 요구사항을 정리해도 실제 자신이 원하는 바를 정확히 표현하기 어렵습니다. 대개는 자신의 사고방식에 맞춰 요구사항을 재해석하여 설명하죠. 그래서 저희는 말 대신 프로토타입으로 대화하기로 했습니다. 아이디어를 자유롭게 펼친 다음, 진짜 중요한 한 가지를 골라 아주 작은 단위로 만들었습니다. "무엇을 만들까?"보다 "왜 필요한가?"를 먼저 정리하는 방식이었죠. 핵심은 '의도적으로 불편하게 시작하기'였습니다. 완벽한 기능은 보기엔 좋지만 문제를 찾기 어렵습니다. 반대로 단순하고 약간 불편한 기능은 사용자가 어디가 불편한지 구체적으로 알려줍니다. 첫 번째 버전은 정말 단순했습니다. 운영자가 '늦은 제출 허용 여부'를 켜거나 끄는 스위치 하나뿐이었습니다. 시간 단위 설정도, 예외 처리도, 알림 기능도 없었죠. 하루만에 이 기능을 만들 수 있었습니다. 하지만 그것으로 충분했습니다. 여기서 정말 중요한 부분이 시작됩니다. 저희는 한 번 만들고 끝내지 않았습니다. 작게 만들고, 피드백 받고, 다시 작게 만들고, 또 피드백 받는 반복 사이클을 계속해서 돌렸습니다. 한 번에 완성된 기능을 만들기보다 짧은 주기로 계속 개선하는 방식이었죠. 이 방식의 가장 큰 장점은 불필요한 것에 시간을 낭비하지 않는다는 점입니다. 3주짜리 개발 계획 중 실제 사용자에게 중요한 부분은 절반도 안 되는 경우가 많습니다. 작게 반복하면서 정말 필요한 부분에만 집중할 수 있었습니다. 또한 매 반복마다 방향을 조정할 수 있었습니다. 처음 생각했던 방향이 틀렸다는 것을 발견해도 손실은 최소화됩니다. 3주를 모두 투자한 후에 방향을 바꾸는 것보다, 3일 단위로 방향을 미세 조정하는 것이 훨씬 효율적이었습니다. 실제 사용자들에게 보여주자 반응이 완전히 달라졌습니다. 예전에는 "조금 더 유연했으면 좋겠어요"처럼 애매했는데, 이번에는 "마감 직후 1시간만 허용했으면 좋겠어요" 같은 구체적인 피드백이 즉시 나왔습니다. 이런 피드백을 바탕으로 또 작은 기능을 추가하고, 다시 사용자에게 보여주고, 또 피드백을 받는 과정을 반복했습니다. 매 반복마다 제품은 사용자가 진짜 원하는 방향으로 조금씩 진화했고, 불필요한 기능 개발에 시간을 낭비하지 않을 수 있었습니다. 챌린지 수정 기능을 만들 때도 비슷하게 접근했습니다. 수정 기능을 일부러 만들지 않고, 사용자 요청이 올 때마다 저희가 직접 데이터베이스를 수정해주었습니다. 3개월간 수동으로 처리하면서 모든 요청을 기록했죠. 이 과정에서 두 가지를 얻었습니다. 첫째, 수정 기능 개발을 미루는 동안 우선순위가 높은 다른 기능들을 먼저 만들 수 있었습니다. 둘째, 사용자들이 진짜 필요로 하는 수정 기능이 무엇인지 명확히 파악할 수 있었습니다. 결과는 예상과 완전히 달랐습니다. 텍스트 수정이 가장 많을 줄 알았는데, 참여자 변경 요청이 절반 이상이었습니다. 더 놀라운 건 챌린지 시작 후에 이런 요청이 급증했다는 점입니다. 참여자들이 챌린지 중간에 계속 조정이 필요했던 것이죠. 덕분에 처음 계획했던 범용 수정 기능 대신, 사용자가 실제로 필요로 하는 '참여자 관리' 기능에 집중할 수 있었습니다. 만약 처음부터 "수정 기능이 필요하세요?"라고 물었다면 "네"라는 단순한 답변만 들었을 겁니다. 하지만 실제 데이터는 완전히 다른 이야기를 들려주었습니다. 이렇게 실제 사용 패턴을 파악한 후에야 진짜 필요한 기능을, 필요한 순서대로 개발할 수 있었습니다. 이 경험 이후 저희 팀은 두 가지 원칙을 지키고 있습니다. **1. 크게 생각하되, 작게 시작하고 자주 반복하기** 아이디어는 넓게 펼치되, 실제 구현은 핵심만 남기고 빠르게 반복한다. **2. 불편함을 두려워하지 않기** 완벽한 기능보다 불편한 기능이 더 정확한 피드백을 가져온다. 이 방식은 특히 새로운 기능을 실험하거나 사용자 요구가 불분명할 때, 빠른 시장 검증이 필요할 때 효과적입니다. 아이디어를 모두 쏟아낸 후, 진짜 필요한 한 조각만 뽑아 3일 안에 만들어보세요. 그리고 "무엇이 필요하세요?"가 아니라 "어디가 불편했나요?"를 물어보세요. 그 피드백을 바탕으로 다시 작은 변화를 주고, 이 과정을 계속 반복하세요. 한 번에 완벽하게 만드는 것은 불가능합니다. 대신 작게 나누어 빠르게 만들고, 사용자 반응을 보며 개선하고, 다시 반복하는 게 훨씬 효과적입니다. 이런 반복 과정에서 쓸데없는 기능 개발에 시간을 낭비하지 않고, 사용자가 정말 원하는 방향으로 제품을 조정해 나갈 수 있습니다. 결국, 진정한 제품 성장은 이런 반복적인 소통과 점진적 개선에서 비롯됩니다.