혼자 만든 서비스가 조용히 죽는 이유
서비스는 대개 극적으로 망하지 않습니다. 조용히 방치되다가 어느 날 멈춰 있습니다.
실제로 자주 보는 원인
전부 사전에 알림으로 막을 수 있는 것들입니다.
| 원인 | 언제 터지나 |
|---|---|
| 도메인 만료 | 갱신 알림을 못 봄 |
| 인증서 갱신 실패 | 자동화가 조용히 깨져 있음 |
| 디스크 가득 참 | 로그가 쌓여서 |
| 결제 수단 만료 | 서버 요금이 미납되어 중지 |
| 의존 서비스 종료 | 쓰던 API가 없어짐 |
그리고 가장 흔한 것 — 만든 사람이 지침
사용자가 늘지 않으면 손이 안 갑니다. 손이 안 가면 더 안 늘어납니다. 이 고리를 끊는 것이 기술보다 어렵습니다.
그래서 혼자 유지할 수 있는 크기로 만드는 것이 중요합니다. 복잡하게 만들수록 지치는 속도가 빨라집니다.
접더라도 제대로 접어야 합니다
다음 서비스를 만들 때 평판이 남습니다.
- 미리 공지 — 갑자기 끄면 신뢰를 잃습니다
- 데이터 내보내기 제공
- 결제 중단 및 잔여분 환불
- 개인정보 파기
- 도메인 처리 — 리다이렉트 또는 만료
기술 부채보다 무서운 것 — 운영 부채
코드가 지저분한 것은 견딜 만합니다. 정작 서비스를 죽이는 것은 갱신·결제·인증서처럼 사람이 챙겨야 하는 것들입니다.
이것들은 평소에 아무 신호를 주지 않다가 어느 날 갑자기 전부를 멈춥니다.
| 항목 | 주기 | 실패 시 |
|---|---|---|
| 도메인 | 연 1회 | 즉시 접속 불가 |
| SSL 인증서 | 수개월 | 보안 경고, 접속 차단 |
| 서버 결제 | 월 1회 | 인스턴스 중지 |
| API 키 | 정책에 따라 | 기능 정지 |
| 의존 라이브러리 | 수시 | 보안 취약 |
| 외부 API 버전 | 수시 | 호출 실패 |
한 장짜리 운영 문서를 만드세요
서비스마다 A4 한 장이면 충분합니다. 6개월 뒤의 자신이 읽는다고 생각하고 씁니다.
- 구성 — 어떤 서버에 무엇이 돌고 있는가
- 배포 방법 — 명령어 그대로
- 도메인·인증서 — 어디서 관리하는가
- 외부 서비스 — 무엇을 쓰고 있는가, 결제는 어떻게
- 갱신 일정 — 무엇이 언제 만료되는가
- 장애 시 — 무엇부터 확인하는가
이 문서가 있으면 서버를 옮기거나 남에게 넘길 때 며칠이 몇 시간으로 줄어듭니다.
만든 사람이 지치는 것을 관리하기
사용자가 늘지 않으면 손이 안 갑니다. 손이 안 가면 더 안 늘어납니다. 이 고리가 대부분의 개인 서비스를 끝냅니다.
여기서 중요한 것은 유지 비용을 최소화해 두는 것입니다. 손이 안 가도 몇 달은 굴러가게 만들어 두면, 다시 의욕이 생겼을 때 이어갈 수 있습니다.
- 자동 갱신을 켜둡니다
- 알림을 최소한만 남겨둡니다 — 장애와 만료
- 비용을 줄여둡니다 — 부담이 크면 접게 됩니다
- 코드를 단순하게 유지합니다
종료 절차 — 제대로 접는 법
| 시점 | 할 일 |
|---|---|
| D-60 | 종료 결정, 신규 가입 중단 |
| D-30 | 이용자 공지 (메일·서비스 내) |
| D-30 | 결제 중단, 잔여분 환불 안내 |
| D-14 | 데이터 내보내기 안내 재공지 |
| D-Day | 서비스 종료, 안내 페이지로 전환 |
| D+30 | 데이터 파기, 파기 기록 |
| 이후 | 도메인 리다이렉트 또는 만료 처리 |
갑자기 끄는 것이 가장 나쁩니다. 다음에 무언가를 만들 때 그 평판이 따라옵니다.
접기 전에 한 번 더 볼 것
사용자가 적어도 몇 명이 정말 잘 쓰고 있다면 그 자체로 의미가 있을 수 있습니다. 유지 비용이 낮다면 두는 것도 선택입니다.
반대로 아무도 안 쓰는데 비용만 나간다면 정리하고 다음으로 가는 편이 낫습니다. 붙들고 있는 것이 다음 시도를 막습니다.
자주 묻는 질문
사용자가 적어도 계속해야 하나요?
판단은 각자의 몫입니다. 다만 유지 비용과 배우는 것을 함께 저울질하는 것이 합리적입니다.
인수인계할 사람이 없으면요?
데이터 내보내기와 충분한 공지만 해도 대부분의 이용자는 이해합니다. 절차를 지키는 것이 중요합니다.
코드를 공개해도 되나요?
가능합니다. 다만 키·설정·개인정보가 이력에 남아 있지 않은지 반드시 확인해야 합니다.
같이 보면 좋은 글
혼자 운영할 때 최소한으로 봐야 할 것모니터링을 거창하게 하면 안 봅니다. 정말 필요한 네 가지. 대시보드를 아무리 예쁘게 만들어도 안 보면 소용없습니다. 혼자라면…도메인을 여러 개 갖고 있을 때 생기는 일만료·방치·중복. 도메인이 늘어날 때 실제로 생기는 문제와 정리 기준. 도메인은 사기 쉽고 관리하기 어렵습니다. 특히 쓰지 않…백업, 복구해 본 적 없으면 백업이 아닙니다무엇을 어디에 얼마나 자주. 그리고 반드시 해봐야 하는 것. 백업이 돌고 있다는 사실만으로는 아무것도 보장되지 않습니다. 복구…검색엔진이 들어오게 만드는 최소 설정콘텐츠를 아무리 써도 이게 없으면 발견되지 않습니다. 검색엔진은 발견 → 크롤 → 색인 순서로 움직입니다. 첫 단계에서 막히면…검색에서 읽히는 글의 구조잘 쓴 글과 검색에서 잘 읽히는 글은 구조가 다릅니다. 검색으로 들어온 사람은 답을 찾으러 온 것입니다. 서론이 길면…사용자 데이터를 다룰 때 코드보다 먼저 정할 것수집·보관·파기·이전. 나중에 붙이면 안 되는 설계. 개인정보 관련 기능은 나중에 붙이기 매우 어렵습니다. 시작할 때 정해두면…