기능을 없애는 게 더 어려운 이유 | SaaS 4종 운영 기준 3가지

기능을 새로 넣자는 회의는 대체로 활기차요. 그런데 “이 기능, 이제 없애죠”라는 말이 나오면 분위기가 확 가라앉아요. 이미 누군가 쓰고 있는 기능이라 손대는 순간 항의로 돌아올 수 있거든요. 저희가 자체 SaaS 4종(D:VALUEUP·Likepro·Globing·Linkmix)을 함께 운영하며 세운 기준은 세 가지예요 — 얼마나 자주 쓰이는지, 없앴을 때 대신할 방법이 있는지, 남겨뒀을 때 드는 유지 비용이 얼마나 되는지. 실제로 정리한 사례와 없애는 절차까지 정리했어요.

“혹시 누가 쓰고 있으면 어떡하죠”라는 질문이 항상 먼저 나와서, 저희도 이 앞에서 여러 번 멈춰 섰어요. 오늘은 그 앞에서 어떤 기준으로 판단을 내렸는지 풀어볼게요.

1. 기능을 없애는 결정이 추가하는 결정보다 어려운 이유

새 기능은 아직 아무도 안 써봤으니 반대할 근거가 약해요. 반대로 이미 붙어 있는 기능은 적더라도 그 화면을 매일 열어보는 사람이 있고요. 그 사람 입장에서는 어느 날 갑자기 버튼이 사라지는 셈이에요. 그래서 없애는 결정에는 항상 “누가 얼마나 쓰는지 확인했나”라는 질문이 따라붙어요. 저희는 이 질문에 감으로 답하지 않으려고 판단 기준을 따로 만들었어요.

2. SaaS 4종을 운영하며 “이제 없애야 하나” 고민이 시작되는 신호

네 서비스를 같이 굴리다 보면 어떤 기능이 슬슬 걸리기 시작하는 순간이 있어요. 문의가 들어와도 담당자가 옛날 문서부터 뒤지는 기능, 업데이트 때마다 “이거 아직도 쓰나요”라는 질문이 나오는 화면, 다른 기능을 고치려다 얽혀서 손대기 껄끄러운 코드. 이 세 신호가 겹치면 정리 후보 목록에 올려요. 신호가 하나만 있을 때는 아직 판단을 서두르지 않고요.

3. 없애기 전에 저희가 확인하는 기준 3가지

정리 후보에 오른 기능은 아래 세 가지를 순서대로 확인해요.

• 얼마나 자주, 누가 쓰나요? 아예 안 쓰이는 것과 소수만 꾸준히 쓰는 것은 완전히 다른 문제예요. 후자라면 없애는 대신 더 단순한 방식으로 바꾸는 쪽을 먼저 검토해요.
• 없앴을 때 대신할 방법이 있나요? 대체 경로 없이 기능만 지우면 그 사용자는 목적 자체를 못 이뤄요. 대체 수단을 먼저 마련한 뒤에야 제거를 진행해요.
• 남겨뒀을 때 드는 유지 비용이 계속 늘어나고 있나요? 사용자는 적은데 업데이트할 때마다 함께 점검해야 하는 기능이라면, 남겨두는 쪽이 오히려 더 큰 위험이 돼요.

세 질문에 모두 답이 나와야 없애는 결정을 내려요. 하나라도 불확실하면 좀 더 지켜봐요.

4. 실제로 걷어낸 기능 — 무엇을, 왜 정리했는지

저희 서비스 중 하나에는 초기에 만든 오래된 형식의 데이터 내보내기 기능이 남아 있었어요. 처음 만들 때는 필요해서 넣었지만, 시간이 지나며 더 편한 방식이 자리를 잡았는데도 옛날 방식은 화면 한쪽에 계속 남아 있었죠. 실제로 그 옛날 방식을 여전히 쓰는 사용자를 확인해보니 극소수였고, 새 방식으로도 같은 결과를 낼 수 있었어요. 그래서 미리 공지하고 유예 기간을 둔 뒤에 정리했어요. 없앤 뒤로 관련 문의는 거의 없었고, 오히려 화면이 한결 단순해졌다는 반응이 있었어요.

5. 없애기로 했을 때 밟는 절차

기준을 통과했다고 바로 지우지는 않아요. 먼저 사용 중인 계정에 미리 안내하고, 대체 방법을 함께 알려요. 그다음 일정 기간 두 방식을 같이 열어둬서 옮겨갈 시간을 줘요. 유예 기간이 지나면 실제로 남아 있는 사용 흔적을 다시 한번 확인한 뒤에야 기능을 완전히 내려요. 이 순서를 지키지 않고 곧바로 지우면, 기준이 맞았더라도 사용자 입장에서는 “예고 없이 사라졌다”는 느낌만 남거든요.

자체 서비스를 운영하며 세운 이 기준은 외주로 만드는 시스템에도 그대로 적용돼요. 지금 쓰는 시스템에 정리가 필요한 기능이 있는지, 아니면 처음부터 이런 판단 기준을 넣어 설계하고 싶으신지 편하게 상담받아보세요. 기능 정리 기준 상담받기 →

6. “운영해본 회사”만 보이는 것 — 외주 프로젝트에 적용하면

납품하고 끝나는 프로젝트에서는 이 판단이 아예 생길 일이 없어요. 만든 쪽은 이미 손을 뗐고, 운영은 다른 팀 몫이니까요. 저희는 기능 욕심을 줄이는 법 3가지에서 신규 기능을 무작정 받지 않는 기준을 다룬 적이 있는데, 이번 글은 그 반대편이에요 — 없는 기능을 거절하는 것보다 이미 쓰이는 기능을 정리하는 쪽이 훨씬 조심스럽거든요. 그래서 새 프로젝트를 설계할 때도 “이 기능이 안 쓰이면 누가 정리할지”를 미리 물어봐요. 답이 있는 설계와 없는 설계는 몇 년 뒤 유지보수 부담에서 갈려요.

7. 자주 묻는 질문

기능을 없애면 기존 사용자가 이탈하지 않나요?

일부는 불편함을 느낄 수 있어요. 그런데 저희 경험으로는 공지 없이 조용히 없앨 때 불만이 커지지, 미리 이유를 설명하고 유예 기간을 주면 대부분은 납득해요. 문제는 ‘없앤다’는 사실보다 ‘왜, 언제’를 안 알려주는 쪽이에요.

사용률이 낮으면 그냥 없애도 되나요?

사용률만으로는 부족해요. 소수만 쓰더라도 그 소수에게 대체 수단이 없다면 함부로 없애면 안 돼요. 저희는 사용 빈도와 함께 ‘없앴을 때 대신할 방법이 있는가’를 같이 봐요.

외주로 만든 시스템도 기능을 없애는 판단이 필요한가요?

네, 오히려 더 필요해요. 외주는 만든 쪽과 운영하는 쪽이 다른 경우가 많아서, 왜 만들었는지 기록이 없으면 손대기가 더 겁나거든요. 착수 단계부터 ‘이 기능이 안 쓰이면 누가, 어떻게 판단할지’를 정해두면 나중이 훨씬 수월해요.

8. 마무리 — 없애는 결정도 결국 설계의 일부예요

기능을 없애는 판단은 화려하지 않고, 성과 보고서에 넣기도 애매해요. 그런데도 이 기준을 계속 지키는 건, 정리되지 않은 기능이 쌓일수록 서비스 전체가 무거워진다는 걸 직접 겪어봤기 때문이에요. 저희는 10년 이상 50개가 넘는 프로젝트를 진행하면서 동시에 자체 SaaS 4종을 직접 운영해왔어요. 롯데·캐논 같은 기업과도 함께 일해 봤고요. 그 경험 덕분에 “일단 만들어두자”는 제안만큼이나 “이건 이제 정리하자”는 판단도 소홀히 하지 않을 수 있었어요. 정리가 필요한 기능이 있거나, 새 프로젝트부터 이런 기준을 넣고 싶으시다면 편하게 문의해주세요.

없앨 기능부터 함께 정리해보기 →

관련해서 함께 보면 좋은 글이에요. 기술 부채, 언제 갚고 언제 미룰까요 | SaaS 4종 운영 기준 3가지도 참고해보세요.