서비스 리뉴얼, 전부 다시 만들어야 할까요?

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• 리뉴얼 범위는 화면의 인상보다 실제 사용과 운영의 불편에서 정합니다.

• 문제가 일부 기능에 모여 있다면 부분 개선부터 검토할 수 있습니다.

• 재개발 견적에는 데이터 이전과 서비스 전환 작업까지 포함해야 합니다.

서비스를 운영하다 보면 화면만 바꿔도 될지, 기능을 고쳐야 할지, 아예 새로 만들어야 할지 고민되실 텐데요. 고객은 사용하기 불편하다고 하고 운영팀은 관리 기능을 늘려달라고 하는데, 어디까지 손대야 할지 정하기가 쉽지 않습니다.

리뉴얼에 쓸 예산과 시간이 한정돼 있다면 지금 가장 필요한 개선부터 골라야 합하는데요. 오늘은 서비스 리뉴얼을 준비할 때 부분 개선으로 충분한 경우와 재개발을 검토할 경우, 견적에서 확인할 전환 작업까지 알아보겠습니다.

1. 새 화면을 그리기 전에 불편이 생기는 곳을 찾습니다

리뉴얼을 논의할 때는 고객과 운영자가 어디서 막히는지 함께 살펴보세요.

아래 예약 서비스 사례는 판단 방법을 설명하기 위한 가정입니다. 고객이 예약을 마치지 못하는 이유부터 구분합니다. 날짜 선택이 복잡한지, 오류가 나는지, 가격이나 취소 조건이 불분명한지 살펴보세요. 화면이 낡아 보인다는 의견만으로는 무엇을 바꿔야 할지 정하기 어렵습니다.

운영자의 작업도 놓치기 쉽습니다. 고객 화면은 무리 없이 작동하지만 담당자가 예약 내용을 매번 엑셀로 옮기고 있을 수 있습니다. 이 경우에는 첫 화면을 새로 디자인하는 것보다 예약 내역을 내려받거나 확인하는 기능을 고치는 일이 더 시급할 수 있습니다.

고객 문의, 오류 기록, 실제 사용 화면을 함께 보면 불편의 원인을 좁히는 데 도움이 됩니다.

방문자가 어느 화면에서 나갔는지는 단서지만 그 이유까지 알려주지는 않습니다. 이탈 기록과 실제 사용 과정을 함께 확인해야 엉뚱한 기능을 고치는 일을 줄일 수 있습니다.

똑똑한개발자팀은 리뉴얼 범위를 정할 때 가장 자주 막히는 작업과 그 불편이 미치는 영향을 함께 봐야 한다고 생각합니다. 예약 완료 자체를 막는 오류인지, 담당자가 한 번 더 클릭해야 하는 불편인지에 따라 우선순위가 달라지기 때문입니다.

2. 문제가 모여 있는 기능부터 고칠 수 있습니다

예약과 결제는 안정적으로 작동하는데 날짜 선택이 불편하다면 해당 화면을 먼저 개선하는 방법을 검토할 수 있습니다. 현재 시스템에서 그 화면을 따로 수정할 수 있는지, 다른 기능에 어떤 영향을 주는지를 개발팀과 확인하는 과정이 필요합니다.

부분 개선에서도 바뀐 화면만 확인하고 끝내면 곤란합니다. 예를 들어 예약 날짜를 바꿨을 때 결제 금액, 확인 문자, 관리자 일정에도 같은 날짜가 반영되는지 살펴봐야 합니다. 겉으로는 작은 수정이어도 연결된 기능을 확인하는 작업이 생깁니다.

개선 전에는 무엇이 달라져야 하는지도 정해둬야 하는데요.

날짜 선택 과정의 오류가 줄었는지, 예약 변경 문의가 줄었는지처럼 문제와 직접 연결되는 항목이 좋습니다. 예약 완료율을 비교한다면 유입 경로나 행사 여부도 함께 봅니다. 수치가 달라졌다는 이유만으로 화면 개선의 효과라고 단정하지 않습니다.

범위를 좁혀 고치면 해당 문제의 변화를 먼저 확인할 수 있습니다. 다만 부분 개선을 반복할 때마다 같은 연결부를 다시 손봐야 한다면 전체 설계를 검토할 이유가 됩니다. 작은 수정이라는 이름만으로 비용과 영향까지 작다고 가정하지 않는 편이 좋습니다.

3. 핵심 기능을 바꿀 때마다 문제가 번진다면 재개발을 검토합니다

예약 규칙 하나를 바꿀 때마다 결제나 정산 오류가 되풀이된다면 화면 밖의 문제를 확인해야 합니다. 기능들이 얼마나 얽혀 있는지, 변경 내용을 검증할 방법이 있는지, 현재 기술을 계속 유지할 수 있는지를 함께 살펴봅니다.

사업 방식이 크게 달라진 경우도 있습니다. 단일 매장의 예약을 받던 서비스를 여러 지점이 사용하는 서비스로 바꾼다고 가정해보겠습니다. 지점별 권한과 상품, 정산 방식까지 달라진다면 기존 설계로 어디까지 감당할 수 있는지 검토해야 합니다. 메뉴 몇 개를 추가하는 견적으로는 필요한 작업이 빠질 수 있습니다.

그렇다고 오래된 코드나 문서 부족만으로 전면 재개발을 결정할 수는 없습니다.

현재 기능 파악과 문서 보완, 핵심 기능 수정, 재개발에 각각 얼마가 드는지 비교해보세요. 새 시스템에도 기존 서비스의 예외 조건을 반영하는 작업은 남습니다.

똑똑한개발자팀은 재개발 제안에 기존 방식을 유지하기 어려운 이유와 새로 만들 범위가 함께 담겨야 한다고 봅니다. 오래됐다는 설명보다 어떤 변경을 감당하기 어려운지 보여줘야 개발 범위와 비용을 판단할 수 있습니다.

4. 견적에는 만드는 비용과 옮기는 비용을 함께 담습니다

새 서비스가 완성돼도 고객 계정과 예약 내역이 제대로 옮겨지지 않으면 운영을 시작하기 어렵습니다. 개발 견적을 비교할 때는 화면과 기능 외에 데이터 이전, 외부 서비스 연동 확인, 운영자 교육, 전환 직후 대응이 어디까지 포함되는지 살펴보세요.

옮길 데이터는 항목별로 확인하는 편이 좋습니다. 진행 중인 예약과 지난 예약을 모두 옮길지, 첨부 파일까지 필요한지, 이전 후 누가 어떤 방법으로 누락을 확인할지 정합니다. 전환 중에도 새 예약이 들어올 수 있습니다. 이 예약을 어느 시스템에서 받을지도 정해두세요.

전체를 한 번에 바꾸는 부담이 크다면 기능을 나눠 옮기는 방법도 검토할 수 있습니다. 기존 시스템과 새 시스템을 함께 운영하며 일부 기능부터 전환하는 방식입니다. 다만 두 시스템의 데이터가 어긋나지 않게 관리하는 작업과 병행 운영 비용이 따릅니다.

똑똑한개발자는 웹·앱부터 관리자 시스템과 SaaS까지 기획·디자인·개발·운영해온 경험을 바탕으로 서비스 개선을 돕습니다. 현재 사용 흐름과 운영상의 불편을 살펴보고 리뉴얼 범위를 구체화할 수 있습니다.

서비스에 맞는 리뉴얼 범위를 정하거나 운영 중 겪는 불편을 개선하고 싶다면 아래 똑똑한개발자 링크로 문의해 주세요! 감사합니다. :)