3년 전에 만든 보고서 내보내기 기능이 있습니다. 쓰는 고객은 전체의 2%입니다. 그런데 새 화면을 만들 때마다 이 기능이 깨지지 않는지 따로 테스트해야 하고, 고객 지원 문의의 상당 부분이 이 기능의 오류입니다. 팀 회의에서 누군가 “이제 빼죠”라고 말하자 다른 누군가가 답합니다. “그 2%가 화내면요?” 이야기는 거기서 끝나고, 기능은 1년 더 남습니다.
기능을 만드는 결정에는 회의와 문서가 따르지만, 기능을 없애는 결정은 대개 미뤄집니다. 그래서 제품은 시간이 갈수록 무거워집니다. 이 글에서는 없앨 기능을 찾는 신호, 없앨지 판단하는 질문, 사용자에게 알리고 실제로 빼는 순서를 정리합니다.
기능을 그대로 두는 데 드는 비용
쓰는 사람이 적은 기능도 그대로 두면 비용이 계속 듭니다. 눈에 잘 띄지 않을 뿐입니다.
표는 가로로 밀어서 볼 수 있습니다.
| 비용 | 내용 |
|---|---|
| 개발과 테스트 | 새 기능을 만들 때마다 기존 기능과의 충돌을 확인해야 하고, 테스트할 경우가 늘어남 |
| 고객 지원 | 잘 쓰지 않는 기능일수록 사용법 문의와 오류 문의가 남음 |
| 화면의 복잡도 | 메뉴와 설정이 늘어 새 사용자가 핵심 기능을 찾기 어려워짐 |
| 보안과 운영 | 오래된 코드와 외부 라이브러리를 계속 점검하고 고쳐야 함 |
| 팀의 집중 | 기능마다 담당과 문서가 필요해 핵심 가치에 쓸 시간이 줄어듦 |
기능을 없애는 것은 실패를 인정하는 일이 아니라, 이 비용을 핵심 기능으로 옮기는 결정입니다.
없앨 후보를 찾는 신호
아래 신호가 겹치는 기능이 검토 대상입니다.
- 사용이 적거나 줄고 있습니다. 그 기능을 한 번이라도 쓴 사용자 비율과, 계속 쓰는 사용자 비율을 함께 봅니다. 한 번 써 보고 다시 안 쓰는 기능은 기대와 다르다는 신호입니다.
- 지원 문의와 오류가 사용에 비해 많습니다. 쓰는 사람은 적은데 문의는 많다면 유지 비용이 큰 기능입니다.
- 다른 기능과 하는 일이 겹칩니다. 같은 일을 두 가지 방법으로 할 수 있으면 사용자는 어느 쪽을 써야 할지 헷갈립니다.
- 제품 방향과 맞지 않습니다. 예전 전략에서 만들었고 지금의 목표 고객에게는 필요 없는 기능입니다.
- 고칠 때마다 다른 곳이 깨집니다. 개발팀이 “이 기능 때문에 일이 늦어진다”고 반복해서 말하는 기능입니다.
사용 데이터가 없으면 판단할 수 없습니다. 기능마다 사용을 기록하고 있는지부터 확인하고, 기록이 없으면 판단 전에 몇 주라도 기록을 쌓습니다.
없앨지 판단하는 질문
후보가 정해지면 아래 질문에 답해 봅니다.
- 누가 쓰는가? 사용자 수만이 아니라 어떤 사용자인지 봅니다. 사용자가 2%여도 그 2%가 매출이 큰 고객이거나 제품을 가장 오래 쓴 고객이면 판단이 달라집니다.
- 그 사람에게 이 기능은 얼마나 중요한가? 가끔 쓰는 편의 기능인지, 그 기능이 없으면 업무가 멈추는 기능인지 사용자 몇 명과 직접 이야기해 확인합니다.
- 대신할 방법이 있는가? 제품의 다른 기능, 데이터 내보내기, 다른 도구와의 연동으로 같은 일을 할 수 있는지 확인합니다. 대신할 방법이 없으면 먼저 그 방법을 만듭니다.
- 약속한 것이 있는가? 계약서, 요금제 설명, 판매 자료에 그 기능을 적어 약속했는지 확인합니다. 약속했다면 영업, 법무 담당과 먼저 정리합니다.
- 남겨 두면 1년에 얼마가 드는가? 개발, 테스트, 지원에 드는 시간을 대략이라도 적습니다. 정확한 숫자보다 “새 기능 하나를 만들 시간” 같은 비교가 결정에 도움이 됩니다.
질문에 답한 결과는 세 가지 가운데 하나입니다. 없앤다, 다른 기능에 합친다, 그대로 두되 더 이상 투자하지 않는다. 세 번째도 결정입니다. 다만 그대로 둘 때는 다시 검토할 시점을 정해 둡니다.
없애는 순서
없애기로 정했으면 한 번에 빼지 않고 단계를 나눕니다.
표는 가로로 밀어서 볼 수 있습니다.
| 단계 | 할 일 |
|---|---|
| 1. 새 사용자에게 숨기기 | 새로 가입한 사용자와 새 고객사에는 기능을 보여 주지 않음. 기존 사용자는 그대로 씀 |
| 2. 알리기 | 기존 사용자에게 종료일, 이유, 대신할 방법을 알림. 제품 안의 안내와 메일을 함께 씀 |
| 3. 이전 돕기 | 데이터 내보내기, 대신할 기능의 사용법 안내, 필요하면 고객 지원 담당의 직접 도움 |
| 4. 끄기 | 종료일에 기능을 끔. 바로 코드를 지우지 않고 일정 기간 다시 켤 수 있게 둠 |
| 5. 정리하기 | 문의와 해지 변화를 확인한 뒤 코드, 문서, 설정을 정리 |
알림과 종료일 사이의 기간은 기능의 중요도에 따라 정합니다. 가끔 쓰는 편의 기능이면 짧게, 업무 절차나 다른 시스템 연동에 쓰이는 기능이면 길게 둡니다. 기업 고객이 많은 제품이면 고객사가 사내 절차를 바꿀 시간을 고려합니다. 계약이나 약관에 알림 기간이 정해져 있으면 그 기간을 지킵니다.
알림에 넣을 내용
알림은 짧고 분명해야 합니다. 아래 다섯 가지가 들어가면 문의를 줄일 수 있습니다.
- 무엇이 바뀌는가: 어떤 기능이 언제부터 사라지는지
- 왜 바뀌는가: 제품을 어떻게 좋게 만들기 위한 결정인지 한두 문장으로
- 무엇으로 대신하는가: 대신할 기능이나 방법, 그 사용법 링크
- 내 데이터는 어떻게 되는가: 내보내는 방법과 기한
- 어디에 물어보는가: 문의 창구
알림 전에 고객 지원과 영업 담당에게 먼저 알리고, 같은 답을 할 수 있도록 자주 묻는 질문(FAQ) 문서를 준비합니다. 사용자가 고객 지원에서 처음 듣게 되면 신뢰를 잃습니다.
흔한 실수
- 사용자 수만 보고 결정합니다. 적게 쓰는 기능이 가장 중요한 고객의 핵심 업무일 수 있습니다.
- 조용히 뺍니다. 알리지 않고 빼면 사용자는 오류로 받아들이고, 다음 변경부터 제품을 믿지 않습니다.
- 대신할 방법 없이 뺍니다. 사용자가 하던 일을 할 방법이 없으면 기능이 아니라 고객이 떠납니다.
- 결정을 기록하지 않습니다. 1년 뒤에 “그 기능은 왜 없앴죠?“라는 질문에 답할 수 없고, 같은 기능을 다시 만드는 일이 생깁니다. 무엇을 근거로 정했는지, 어떤 숫자를 확인했는지 남겨 둡니다.
바로 쓰는 기능 정리 점검 목록
- 기능마다 사용을 기록하고 있습니다
- 사용이 적은 기능의 사용자가 누구인지 확인했습니다
- 그 사용자 몇 명과 직접 이야기해 기능의 중요도를 확인했습니다
- 대신할 방법이 있거나 먼저 만들었습니다
- 계약, 요금제 설명, 판매 자료의 약속을 확인했습니다
- 없앤다, 합친다, 투자하지 않는다 가운데 하나로 정하고 이유를 기록했습니다
- 새 사용자에게 숨기기, 알리기, 이전 돕기, 끄기, 정리하기 순서와 날짜를 정했습니다
- 알림에 무엇, 왜, 대신할 방법, 데이터, 문의 창구가 들어 있습니다
- 고객 지원과 영업 담당이 알림보다 먼저 알고 있습니다
제품을 좋게 만드는 일에는 추가하는 일만 있는 것이 아닙니다. 쓰지 않는 기능을 정리하면 핵심 기능이 더 잘 보이고, 팀은 더 중요한 일에 시간을 쓸 수 있습니다. 없애는 결정도 만드는 결정만큼 근거를 갖추고, 사용자가 놀라지 않게 단계를 나눠 진행하면 됩니다.
참고
- 특정 자료를 옮기지 않고 널리 알려진 개념을 바탕으로 직접 썼습니다. 본문의 보고서 내보내기 기능과 숫자는 설명을 위해 지어낸 예입니다.
- 출시한 기능이 실제로 쓰이는지 확인하는 방법은 이 블로그의 「출시 후 분석」 글을, 사용자가 계속 남는지 읽는 방법은 「리텐션과 코호트 분석」 글을 함께 보세요.