혼자 만든 서비스를 접어야 할 때 — 유지·전환·종료 판단 기준 6가지

매달 카드 결제 알림이 옵니다. 서버비 몇만 원, 도메인 갱신비 몇만 원. 금액이 크지 않아서 그냥 넘깁니다. 그런데 그 서비스에 마지막으로 접속한 게 언제였는지는 기억나지 않습니다. 이런 상태로 2년을 끌어본 적이 있습니다.

혼자 만든 서비스를 접는 일이 어려운 이유는 비용이 아니라 감정입니다. 밤을 새워 만든 기억이 있고, 처음 가입자가 생겼을 때의 기분이 남아 있습니다. 그래서 "언젠가 다시 손보면 되지"라는 말로 판단을 계속 미룹니다. 그 사이에 유지비는 계속 나가고, 무엇보다 다음 작업에 쓸 수 있었던 관심이 조금씩 새어 나갑니다.

이 글은 접으라고 권하는 글이 아닙니다. 접을지 말지를 기분이 아니라 기준으로 정하자는 이야기입니다. 아래 여섯 가지를 확인하고, 그 결과에 따라 유지·전환·종료 중 하나를 고르는 방식입니다.

판단 기준 여섯 가지

각 항목에 예/아니오로 답합니다. 애매하면 아니오로 칩니다. 애매하다는 것 자체가 이미 답인 경우가 많습니다.

• 내가 지금 직접 쓰고 있는가: 가장 강력한 기준입니다. 만든 사람이 안 쓰는 서비스는 대개 개선 방향도 잡히지 않습니다. 최근 한 달 안에 사용자로서 접속한 적이 없다면 아니오입니다.
• 월 유지비가 얻는 가치보다 낮은가: 비용에는 서버비뿐 아니라 도메인, 유료 API, 인증서, 모니터링 비용을 모두 넣습니다. 여기에 "이 돈으로 다른 걸 했다면"이라는 기회비용까지 생각해봅니다.
• 최근 6개월 사용자 추이가 유지 이상인가: 늘지 않아도 괜찮습니다. 문제는 꾸준히 줄어드는 경우입니다. 방문자 수보다 재방문자 수를 봅니다. 한 번 왔다 가는 사람만 있다면 서비스가 아니라 페이지에 가깝습니다.
• 유지보수에 드는 시간이 감당 가능한가: 라이브러리 보안 패치, 만료되는 인증서, 바뀌는 외부 API. 새 기능을 하나도 안 넣어도 서비스는 손이 갑니다. 월 몇 시간이 나가는지 실제로 적어봅니다.
• 배운 것이 이미 남았는가: 학습이 목적이었다면 그 목적은 달성됐을 수 있습니다. 배포와 운영을 해봤고 그 감각이 남았다면, 서비스를 유지하는 것과 배움이 남는 것은 별개입니다.
• 코드나 데이터를 다른 곳에 재활용할 수 있는가: 인증 모듈, 결제 연동, 관리자 화면처럼 다음 프로젝트에서 그대로 쓸 조각이 있다면, 서비스를 닫아도 자산은 남습니다. 오히려 닫는 편이 자산을 정리할 계기가 됩니다.

여섯 개 중에서 가장 무겁게 보는 것은 첫 번째와 세 번째입니다. 나머지는 노력으로 바꿀 수 있지만, 만든 사람도 안 쓰고 사용자도 줄어드는 상태는 노력으로 뒤집기가 어렵습니다. 반대로 유지비가 조금 부담스럽더라도 내가 매일 쓰고 재방문자가 유지되고 있다면, 그건 아직 살아 있는 서비스입니다.

답을 세 갈래로 나누기

여섯 개 답을 놓고 다음 표대로 정합니다. 정확한 공식은 아니지만, 결정을 미루지 않게 만드는 데는 충분합니다.

예의 개수	선택	다음에 할 일
4개 이상	유지	다음 6개월 목표를 한 줄로 적고 재점검일을 달력에 등록
2~3개	전환	기능을 줄여 정적 페이지·오픈소스·내부 도구로 축소
1개 이하	종료	종료일을 정하고 아래 절차대로 정리

가운데 칸을 특히 권합니다. 접는 것과 유지하는 것 사이에는 축소라는 선택지가 있습니다. 로그인과 결제를 걷어내고 정적 페이지로 남기면 서버비가 거의 사라집니다. 코드를 공개해 오픈소스로 넘기는 방법도 있고, 남에게 공개하지 않고 나 혼자 쓰는 내부 도구로 낮추는 방법도 있습니다. 저도 예전 프로젝트 하나를 이렇게 정리했는데, 완전히 지우는 것보다 마음이 훨씬 편했습니다.

종료하기로 했다면 이 순서로

종료는 서버를 그냥 내리는 일이 아닙니다. 사용자가 한 명이라도 있었다면 지켜야 할 최소한의 절차가 있습니다. 개인 서비스라도 남의 데이터를 받아뒀다면 책임의 성격은 회사 서비스와 크게 다르지 않습니다. 저는 이 순서대로 처리합니다.

1. 데이터부터 백업합니다: 데이터베이스 덤프와 업로드된 파일을 통째로 내려받아 두 곳 이상에 보관합니다. 나중에 "그때 그 데이터 어디 있지"라고 후회하는 일이 자주 생깁니다.
2. 사용자에게 종료일을 알립니다: 최소 한 달 전이 무난합니다. 공지에는 종료일, 데이터 내보내기 방법, 대안이 될 만한 서비스를 적습니다. 사과문처럼 길게 쓸 필요는 없습니다.
3. 내보내기 기능을 열어둡니다: 사용자가 자기 데이터를 가져갈 수 있는 최소한의 방법을 제공합니다. 간단한 JSON이나 CSV 다운로드면 충분합니다.
4. 결제를 먼저 끊습니다: 유료 서비스였다면 신규 결제와 자동 갱신부터 막습니다. 남은 기간에 대한 처리 방침도 공지에 함께 적습니다.
5. 코드를 정리해 보관합니다: 재활용할 조각을 따로 떼어내고, 저장소는 비공개 아카이브로 남깁니다. 삭제는 하지 않는 편이 좋습니다.
6. 도메인과 계정을 정리합니다: 자동 갱신을 끄고, 외부 API 키를 폐기하고, 메일 발송 도메인 설정도 함께 내립니다. 방치된 도메인이 나중에 엉뚱한 사이트로 연결되는 일을 막기 위해서입니다.
7. 기록을 한 편 남깁니다: 무엇을 만들었고, 왜 접었고, 무엇을 배웠는지 정리해둡니다. 이 글이 다음 프로젝트의 기획서 첫 장이 됩니다.

접는 것은 실패가 아닙니다

21년째 개발을 하면서 제가 만든 것 중 지금도 살아 있는 서비스는 많지 않습니다. 처음에는 그게 부끄러웠는데, 지금은 다르게 봅니다. 접힌 프로젝트들은 각각 한 가지씩 배움을 남기고 갔습니다. 어떤 건 배포 자동화를, 어떤 건 결제 연동의 함정을, 어떤 건 "사람들은 내가 만든 걸 생각만큼 궁금해하지 않는다"는 사실을 알려줬습니다.

진짜 손해는 접는 것이 아니라 결정하지 않은 채로 끌고 가는 것입니다. 결정을 미루는 동안에는 그 프로젝트도, 다음 프로젝트도 제대로 나아가지 못합니다. 머릿속 한구석에 "저거 언젠가 손봐야 하는데"가 계속 켜져 있으면, 새로 시작하는 일에도 그만큼 자리가 줄어듭니다.

한 가지 덧붙이면, 종료를 결정한 뒤에도 곧바로 지우지 말고 한 달쯤 여유를 두는 편이 좋습니다. 그사이에 마음이 바뀌어 다시 살리는 경우도 있고, 반대로 한 달 동안 한 번도 열어보지 않았다면 그것 자체가 결정이 옳았다는 확인이 됩니다. 어느 쪽이든 급하게 지우고 후회하는 것보다는 낫습니다.

마치며

여섯 가지 기준으로 점검하고, 유지·전환·종료 중 하나를 고르고, 종료를 택했다면 백업부터 도메인 정리까지 순서대로 밟습니다. 중간에 축소라는 선택지가 있다는 점만 기억해도 결정이 한결 가벼워집니다.

오늘 할 수 있는 한 가지는 이겁니다. 지금 돌아가고 있는 개인 서비스의 월 유지비를 실제 금액으로 적어보는 것입니다. 머릿속 어림값 말고 카드 명세서에 찍힌 숫자로요. 그 숫자를 보고 나면 나머지 판단은 훨씬 빨리 끝납니다.