40달러 런던 캡슐 호텔에서 배운 '최소 기능 제품(MVP)'과 생존 전략

안녕하세요. 풀링포레스트 CEO 겸 PM 김형철입니다.

최근 흥미로운 기사를 하나 접했습니다. 살인적인 물가로 유명한 런던 한복판에 1박 40달러(약 30파운드)짜리 캡슐 호텔이 등장했고, 이곳이 관광객이 아닌 '직장인'들로 붐비고 있다는 소식입니다. 런던 중심부 호텔의 평균 숙박비가 1박에 265파운드(약 45만 원)에 달하는 상황에서, 교외로 밀려난 직장인들이 사무실 복귀(RTO) 명령을 받고 생존을 위해 이 '닭장' 같은 공간을 선택하고 있다는 내용이었습니다.

저는 이 현상을 보며 우리 개발팀과 제품 조직이 겪는 리소스 문제와 놀랍도록 닮아있다는 생각을 했습니다. 오늘은 런던의 캡슐 호텔 'Zedwell' 사례를 통해, 제한된 리소스 안에서 최적의 가치를 찾아내는 제품 전략에 대해 이야기해보려 합니다.

화려한 스펙 대신 '핵심 가치'에 집중하기

기사에 따르면 이 캡슐 호텔의 방 크기는 가로 1m, 세로 1m, 깊이 2미터에 불과합니다. 창문도 없고, 일어서면 머리가 천장에 닿을 정도입니다. 심지어 짐 보관이나 여성 전용 구역 이용에는 추가 요금이 붙습니다. 하지만 예약이 꽉 찹니다. 왜일까요?

이 호텔은 사용자의 Pain Point(고통점)를 정확히 타격했기 때문입니다.
사용자(직장인)가 원하는 것은 '호텔의 럭셔리함'이나 '탁 트인 전망'이 아니었습니다. 그들의 핵심 니즈는 단 하나, '내일 출근하기 위해 잠만 잘 수 있는 저렴하고 안전한 공간'이었습니다.

우리가 제품을 기획하고 개발할 때도 비슷한 딜레마에 빠지곤 합니다. 기획 초기에는 모든 기능이 중요해 보입니다. 화려한 UI, 확장성 높은 아키텍처, 모든 예외 처리가 완벽한 백엔드 로직을 꿈꿉니다. 하지만 스타트업이나 초기 프로젝트의 현실은 런던의 살인적인 물가처럼 가혹합니다. 개발 리소스는 부족하고, 런런(Runway)은 짧으며, 시장의 요구는 급변합니다.

이때 필요한 것이 바로 이 캡슐 호텔과 같은 철저한 MVP(Minimum Viable Product) 전략입니다. Zedwell은 호텔의 구성 요소 중 '숙면'을 제외한 모든 것(창문, 넓은 공간, 서비스)을 과감히 제거했습니다. 우리도 때로는 "이 기능이 없으면 사용자가 서비스를 아예 못 쓰는가?"라는 질문 앞에 냉정해질 필요가 있습니다.

레거시 시스템과 통근 비용의 상관관계

기사에서 언급된 또 다른 포인트는 '통근 비용'입니다. 런던 근로자의 43%가 직장까지 30분 이상 걸리는 곳에 살고 있고, 도심 집값을 감당할 수 없어 외곽으로 나갔다가 다시 출근 압박을 받고 있습니다. 이때 캡슐 호텔은 높은 주거비용과 긴 통근 시간 사이의 '완충재(Buffer)' 역할을 합니다.

개발자 관점에서 보면 이는 기술 부채(Technical Debt)와 레거시 시스템의 유지보수 비용과 비슷합니다.
시스템이 비대해지고(도심 집값 상승), 트래픽 처리 속도가 느려지면(긴 통근 시간), 우리는 선택을 해야 합니다.

1. 전면 리팩토링 (도심으로 이사): 근본적인 해결책이지만 비용과 시간이 막대하게 듭니다.

2. 임시 패치 및 캐싱 전략 (캡슐 호텔): 완벽하지는 않지만, 당장의 트래픽을 처리하고 시스템 다운을 막아주는 현실적인 대안입니다.

풀링포레스트 팀에서도 비슷한 경험이 있었습니다. 레거시 코드의 복잡도가 높아져 배포 시간이 1시간을 넘기는 상황이 왔을 때, 우리는 당장 마이크로서비스(MSA)로의 전면 전환을 꿈꿨습니다. 하지만 현실적으로 불가능했습니다. 대신 우리는 캡슐 호텔 같은 전략을 택했습니다. 배포 파이프라인에서 병목이 되는 테스트 구간만 분리해 병렬로 처리하는 '중간 단계'를 만든 것입니다. 근본적인 해결은 아니었지만, 개발팀의 야근을 줄이고 운영 효율을 높이는 데는 충분했습니다.

불편함을 감수하더라도 시장의 빈틈을 메우는 용기

Zedwell의 담당자는 "우리는 저가 호스텔과 고급 호텔 사이의 적정 지점(Sweet spot)을 찾았다"고 말합니다. 비록 공사 소음이 들리고, 서비스가 미완성인 부분이 있더라도 시장에는 분명히 그 '불완전한 솔루션'을 간절히 원하는 수요가 존재했습니다.

주니어 개발자나 PM 분들이 가장 두려워하는 것이 바로 '부끄러운 코드' 혹은 '부족한 기능'을 내보내는 것입니다. "아직 준비가 안 됐어", "이런 UI로는 욕먹을 거야"라며 배포를 미루곤 합니다. 하지만 시장은 완벽한 265파운드짜리 호텔만을 원하지 않습니다. 때로는 투박하고 좁더라도, 내 문제를 당장 해결해 줄 40달러짜리 캡슐이 훨씬 더 절실할 때가 있습니다.

마치며

우리가 만드는 프로덕트가 런던의 5성급 호텔일 필요는 없습니다. 사용자가 처한 상황이 '전쟁터 같은 출근길'이라면, 그들에게 필요한 건 따뜻한 환대가 아니라 당장 몸을 뉘일 수 있는 1평 남짓한 공간일 테니까요.

여러분이 지금 고민하고 있는 그 기능, 혹시 너무 많은 것을 담으려 하고 있진 않나요? 과감하게 덜어내고, 사용자가 겪는 문제의 본질(Core)만 남겨보세요. 때로는 그 투박한 결과물이 누군가에게는 가장 합리적이고 고마운 솔루션이 될 수 있습니다.