창업기 20. 제품 2.0 버전은 언제 만들어야 하는가

재하 창업기

스타트업이 서비스를 출시하고 어느 정도 시장에 안착되면 2.0 버전으로의 업데이트를 고려하는 경우가 많습니다. 그러나 당장 해야 할 일이 많다 보니 도대체 언제, 어느 정도의 리소스로 2.0을 위한 작업을 진행해야 하는지 고민되기도 하는데요. 실제로 2.0 업데이트를 위한 작업을 진행하기로 했는데 너무 오랜 시간이 걸려서 흐지부지되거나, 어렵게 완성했음에도 고객에게 환영받지 못하는 경우도 존재합니다.

저희 프릭스도 2.0 업데이트를 결정하고 2024년 11월에 작업을 시작하면서 여러 고민을 하였고, 다행히 2025년 4월 초에 모든 2.0 업데이트를 마무리할 수 있었습니다. 저희는 2.0 버전의 목표였던 확장성을 고려한 데이터 구조 개편 및 전반적인 UI/UX 업데이트를 진행하면서, 동시에 기존의 로드맵 작업과 프로젝트들도 잘 진행해 왔는데요. 오늘은 해당 경험을 토대로 제품의 2.0 업데이트를 언제, 어떻게 진행해야 하는지에 대해 다루어보고자 합니다.

<지난 타임라인>

- 24. 10. 14. SI 프로젝트를 위한 솔루션팀 신설

- 24. 11. 1. 제8회 G밸리 창업경진대회 금상 수상

- 24. 11. 21. 워크숍

- 24. 12. 4~6 대한민국 소프트웨어대전 부스 운영

- 24. 12. 18-19 솔루션팀 안전교육 및 킥오프 출장

- 25. 1. 7. 솔루션팀 별도 오피스로 출근 시작

2.0 업데이트 시기 : 새로운 목표나 방향이 필요할 때

보통 제품은 처음 출시될 때 가장 많은 고민을 통해서 만들어집니다. 그리고 출시된 이후에는 고객의 피드백을 통해 지속적으로 개선하는 애자일 방식으로 운영됩니다. 그러나 제품을 운영하다 보면 기존의 업무 프로세스로 원하는 목표에 도달하기 어려운 경우가 있는데요, 그런 경우가 바로 2.0 버전을 고려할 시점입니다.

기존의 방식으로 목표에 도달하기 어렵다는 것이 어떤 의미일까요? 이는 프로세스에 문제가 있다거나 방법론의 한계를 이야기하는 것이 아닙니다. 예를 들어 '멋진 자동차'를 만들겠다는 목표를 갖고, '심미성'과 '승차감'이라는 가치를 차별점으로 설정했다고 가정해 봅시다. 애자일 방법론에 따라 사람들이 심미성과 승차감에 가치를 느끼는지 빠르게 확인하기 위해 바로 자동차를 만들지 않고 자전거부터 만들어 보았습니다. 외관이 예쁘고 안장이 편안하니 사람들의 반응이 좋습니다. 조금 더 가치에 대한 가능성을 믿고 제품을 개선하다 보니 어느새 오토바이도 잘 만들게 되었고, 서서히 자동차도 만들어보기 시작하였습니다.

그러나 고객의 목소리를 들으며 오토바이를 개선하는 과정에서 어느 순간 심미성과 승차감을 극도로 높이기 위해서는 내연기관차 대신 전기차로 나아가야 한다는 것을 깨닫게 되었습니다. 그리고 현재의 오토바이를 '개선'하는 방식으로는 전기차로 나아가기 어렵다는 것도 알게 되었습니다. 그때가 바로 버전 업데이트를 고려해야 하는 시점입니다. '멋진 자동차'라는 목표가 달라지지는 않았지만, 해당 목표를 도달하기 위한 방향의 변화가 필요한 것입니다.

(사실 저는 자동차 만드는 법도 모르고, 실제로 오토바이가 만들기 더 쉬운 지도 잘 몰라서 예시로만 생각해 주세요)

많은 스타트업에서는 제품을 운영할 때, 빠르게 고객의 반응을 확인하고 개선할 수 있는 애자일 방법론을 사용합니다.

이처럼 새로운 버전 업데이트는 주요 비즈니스 모델이나 타겟고객 및 방향 등이 달라지는 경우에 필요합니다. 저희 래티스의 경우에는 ‘올인원 계약관리 솔루션’ 프릭스를 출시한 이후 꾸준히 고객을 만나서 이야기를 듣고 개선하는 과정을 반복해 왔습니다. 그렇게 점차 고객사와 기능은 많아졌지만, 동시에 기존 구조로는 제공하기 어려운 한계점도 조금씩 나타나기 시작했습니다. 예를 들어 사용성(UX) 측면에서 고객들은 자유롭게 계약서를 관리하고 싶어 했으나 구조적으로 계약서 데이터가 하나의 고객에만 연결될 수 있었고, 인터페이스(UI) 측면에서는 기존의 레이아웃으로 전보다 늘어난 다양한 기능과 데이터를 효율적으로 표현할 수 없었습니다.

이러한 제약은 시간이 지날수록 제품 개선에 큰 어려움으로 다가왔고, 구조를 우회하여 기능을 제공하거나 화면에 억지로 여러 버튼과 데이터를 표현하는 등 기획 및 개발의 생산성을 저해하는 경우도 발생했습니다. 그래서 저희는 ‘올인원’이라는 가치를 제대로 제공하기 위해 2.0 업데이트를 진행하기로 결정했습니다.

프릭스 2.0 업데이트 이후의 계약서 상세 예시 화면입니다.

2.0 업데이트 범위 : 목표에 부합하는 작업 선별

그렇다면 업데이트 작업 범위는 어느 정도로 설정해야 할까요? 2.0 업데이트라고 하니 뭔가 거창해야 할 것 같기도 하고, 또 이런 큰 작업을 언제 하게 될지 모르니 그동안 생각했던 작업들을 다 포함해야 할 것 같기도 합니다. 실제로 이처럼 큰 프로젝트가 진행되는 경우, 테크 스택 변경이나 어드민 기능 등 그동안 '우선순위' 때문에 미뤄진 여러 팀들의 요청 작업이 포함되는 경우가 많습니다.

임팩트가 큰데 시급하지 않다는 이유로 우선순위에서 밀린 작업을 챙기는 것은 중요합니다. 다만 그게 꼭 '2.0 업데이트'에 포함되어야 하는지에 대해서는 곰곰이 생각할 필요가 있습니다. 실제로 2.0 업데이트의 목표에 부합하는 작업이라면 같이 진행하는 게 효율적일 수 있지만, 작업 범위가 증가할수록 업데이트에 소요되는 시간은 계속해서 늘어날 것입니다.

결국 2.0 업데이트를 시작하게 된 근본적인 이유를 잊지 않고, 해당 목표에 부합하는 작업인지 판별하는 것이 중요합니다. 저희 프릭스의 경우에는 ‘올인원’의 가치를 효율적으로 제공하기 위해 1) 데이터 구조를 확장성 있게 변경하는 것과 2) 다양한 기능과 데이터를 표현하기 적합한 UI로 변경하는 것을 주된 목표로 설정하였습니다. '하는 김에' 포함하고 싶은 기능도 무수히 많았지만 해당 목표에 직접적인 연관이 없는 것은 모두 프로젝트 범위에서 제외하였습니다.

고객들이 업데이트를 자연스럽게 받아들일 수 있도록 처음에는 내비게이션 UI만 먼저 변경하였습니다.

2.0 업데이트 방법 : 사용자의 적응 기간 줄이기

목표와 범위를 설정했다면 이제 마지막으로 어떻게 작업하여 고객에게 전달할지에 대한 '방법'을 결정할 차례입니다. 제품을 운영하는 입장에서 2.0 업데이트와 같이 대대적인 변화는 한 번에 공개하고 싶어 하는 경우가 많습니다. 그러나 이는 만드는 사람의 욕심일 수 있습니다. 사실 대부분의 기존 고객들은 이미 제품을 잘 사용하고 있으며, 불편함이 있더라도 이미 적응해서 불편하다고 인지하고 있지 못하는 경우가 많습니다.

결국 서비스를 사용하는 입장에서 업데이트는 아무리 좋은 변화라도 '익숙한 방식'에서 '익숙하지 않은 방식'으로의 변화입니다. 일상적인 업데이트는 변경이 많지 않다 보니 고객들이 빠르게 적응하는 것일 뿐입니다. 그러나 업데이트의 범위가 클수록 사용자가 새롭게 적응하는데 필요한 시간은 길어지고, 그 기간 동안 사용자는 학습을 강요받고 있다고 느낄 수도 있습니다.

새로운 내비게이션 화면을 먼저 배포한 이후 목록 화면을 하나씩 변경해 나갔습니다.

그렇다면 2.0 업데이트는 어떻게 진행하는 것이 좋을까요? 저는 큰 프로젝트라도 작업을 나누어서 진행하는 방식을 선호합니다. 예를 들어 화면 작업의 경우에는 페이지나 기능 단위로 나누어서 개발하고 배포할 수 있으며, 테크 작업의 경우에도 충분히 세분화하여 진행이 가능합니다.

저희 프릭스의 경우에도 데이터 구조 변경 작업을 세분화하여 하나씩 순차적으로 진행했으며, 화면 작업도 레이아웃과 목록 페이지, 상세 페이지, 인풋 등을 나누어서 작업하고 단계적으로 서비스에 반영하였습니다. 그렇게 진행하니 기존 사용자도 큰 어려움 없이 새로운 기능에 하나씩 적응하였고, 업데이트 작업 중간에 다른 급한 프로젝트가 진행되는 경우에도 유연하게 대응이 가능했습니다.

2.0 업데이트와 별개로 3월에는 정보보호 국제표준 인증 'ISO 27001'을 획득했습니다.

<2025년 1월 ~ 2025년 4월 초 타임라인>

- 25. 1. 7. 솔루션팀 별도 오피스로 출근 시작

- 25. 1. 22. 래티스 첫 B2B마케터 입사

- 25. 1. 23. 래티스 첫 PM 입사

- 25. 2. 3. 솔루션팀 1차 프로젝트 테스트 서버 구성

- 25. 3. 7. 프릭스 2.0 UI 업데이트 마무리

- 25. 3. 10. 솔루션팀 1차 프로젝트 운영서버 배포

- 25. 3. 26. 정보보호 국제 표준 ISO 27001 인증 획득

- 25. 4. 4. 프릭스 2.0 UI/UX 업데이트 프로젝트 완료

제품 기획이나 개발을 하다 보면 ‘완벽’이라는 것은 없다는 사실을 자주 느끼게 됩니다. 기획할 때는 레거시 화면이나 정책을 최대한 빠르게 없애고 싶고, 개발할 때는 과거의 디렉토리 구조를 빠르게 정리하여 완전한 형태로 만들고 싶다는 욕심이 생깁니다. 그러나 막상 제품을 운영하다 보면 이상적이라고 생각하는 형태가 계속해서 달라지게 됩니다.

실제로 시대나 상황에 따라 사람들의 취향이 달라지기도 하고, 고객과 기술도 매번 변화하기 때문에 제품이 추구하는 형태가 달라지는 것은 당연한 이치입니다. 예를 들어 저는 저희 프릭스 1.0의 디자인이 그 당시에는 이상적이었다고 생각합니다. 기능이 많지 않은 초기 프릭스의 특징과 여백이 포함된 개성 있고 깔끔한 디자인이 잘 어우러졌기 때문입니다. 다만 기능이 많아지고 복잡해지면서 데이터와 기능을 효율적으로 표시하기 위한 새로운 방식이 필요해진 것뿐입니다.

완벽할 수 없기 때문에 현상을 유지해야 한다거나 변화가 의미 없다는 말을 하려는 것은 아닙니다. 저는 실제로 제품이 변화하는 과정 속에서 계속 진화한다고 생각합니다. 결국 중요한 것은 완전함만을 추구하기보다는 균형을 잘 잡고 유연하게 나아가는 것이라고 생각합니다. '내가 원하는 것이 아니라 고객이 원하는 것을 만들어야 한다'라는 사실은 창업할 때나 초기 제품을 만들 때만 중요한 것이 아니라 제품을 운영하는 과정에서 항상 기억해야 하는 대원칙이라 생각하며, 앞으로도 이러한 원칙을 잊지 않고 좋은 제품을 만들기 위해 노력하고자 합니다.