사이드 프로젝트의 8할은 죽는다 — 살아남은 두 가지

죽은 프로젝트 목록이 살아남은 목록보다 4배 많다

우리 팀은 결제·정산·자동화를 직접 운영한다. 외주 없이, 작은 팀이, 매일 PG 연동 상태와 정산 파이프라인을 직접 챙긴다. 그러다 보니 사람마다 아이디어가 생기고, 사이드 프로젝트가 주기적으로 생겨났다 사라진다. 지금까지 시작했다가 멈춘 것과 살아남은 것의 비율을 세어보면 대략 4:1이다. 노션 기획서까지 쓴 것도 있고, .com 도메인을 사두고 만료시킨 것도 있고, 커밋 두세 개만 올라간 채 방치된 저장소도 있다.

이 비율 자체가 문제는 아니다. 시도에서 배우는 게 있고, 죽은 프로젝트에서 쓴 코드가 다른 곳에 다시 쓰이기도 한다. 문제는 같은 이유로 계속 죽는다는 것이다. 결제·정산 현장에서는 "왜 이 정산이 틀렸지?"를 매번 추적하는 팀이, 사이드 프로젝트에서는 "왜 이게 죽었지?"를 분석하지 않고 다음 것을 시작했다. 돌아보니 죽은 것들 사이에 뚜렷한 패턴이 있었고, 살아남은 두 개도 공통된 조건이 있었다.

죽은 프로젝트들의 사망 진단서

죽은 프로젝트 대부분은 "있으면 좋겠다"는 가설에서 출발했다. 특정 자동화 도구를 만들면 생산성이 오를 것 같다, 이런 API 래퍼를 만들면 누군가 쓸 것 같다 — 검증이 없었다. 정산 로직을 짤 때는 절대 하지 않는 짓, 즉 "이 계산이 맞겠지"라고 전제하고 그냥 실배포하는 것을 사이드 프로젝트에서는 당연하게 했다. 결과는 예상할 수 있다. 실제로 그 도구가 필요한 사람이 한 명도 없었거나, 있더라도 우리가 만든 방식이 그 사람이 원하는 것과 달랐다.

두 번째 공통점은 "완성 후 오픈" 마인드였다. MVP 배포 → 피드백 → 개선의 흐름이 아니라, 혼자서 완성의 기준을 높이며 외부와 단절된 채로 만들었다. 결제 시스템으로 비유하면 정산 로직을 석 달 개발하고 한 번에 라이브 전환하는 것과 같다 — 실제로 그렇게 했다가 전환 당일 밤을 새운 적이 있다. 그 경험이 있으면서도 사이드 프로젝트에서 같은 실수를 반복했다. 여기에 번아웃이 마지막 타격을 가했다. 월 마감, VAN 점검, PG사 정책 변경이 겹치는 주간에는 사이드 프로젝트를 건드릴 여유가 없고, 한두 달 멈추면 재개 심리 장벽이 예상보다 훨씬 높아져 그대로 묻힌다.

살아남은 두 개의 공통점 — 처음부터 쓰는 사람이 있었다

살아남은 첫 번째 프로젝트는 정산 결과를 슬랙으로 받아보는 내부 알림 도구다. 시작은 쉘 스크립트 40줄이었다. 기획서도, 도메인도, 리드미도 없이 — 팀원 한 명의 "정산 끝나면 자동으로 알려줄 수 있어?"라는 메시지 하나로 시작했다. 그날 오후에 배포했고, 그날 저녁부터 실제로 쓰였다. 두 번째는 PG사별 수수료를 비교하는 계산기다. 아는 스타트업 대표가 "PG 수수료 계산이 너무 귀찮다"고 했고, 그 자리에서 구글 스프레드시트 버전을 먼저 만들어 줬다. 쓰는 사람이 생기자 웹으로 옮겼다.

두 프로젝트 모두 처음 기능이 세 개 이하였다. 슬랙 알림 도구는 정산 완료 여부 + 오류 건수 + 총 정산액, 딱 세 가지만 보여줬다. 계산기도 PG 3사의 수수료율과 예상 수취액만 계산했다. 부족함이 눈에 보였지만, 쓰는 사람이 "이것도 있으면 좋겠다"고 말했고, 그 한 마디가 다음 배포의 티켓이 됐다. 방향을 잃지 않는 가장 확실한 방법은 쓰는 사람이 방향을 알려주게 하는 것이었다.

결제·정산 운영팀에서 사이드 프로젝트가 특히 어려운 이유

일반 개발팀의 사이드 프로젝트와 달리, 결제·정산 운영을 병행하는 환경에는 구조적 어려움이 따로 있다. 정산 오류는 비동기로 신경을 잡아당긴다. 월 마감, 분기 마감, VAN 점검 일정, PG사 정책 변경이 불규칙하게 끼어든다. 우리 팀 기준으로 한 달에 평균 3~4번은 "지금 당장 봐야 할" 이슈가 생긴다. 이 구조에서 "완성될 때까지 계속 만들자"는 마인드는 치명적이다. 첫 번째 긴급 이슈가 터지는 순간 사이드 프로젝트는 멈추고, 재개 시점을 잃는다.

반대로 이 구조가 살아남은 프로젝트의 특성과 잘 맞는다. 기능이 적고, 유지 비용이 낮고, 한 달을 안 봐도 동작하는 것 — 그런 프로젝트만 살아남는다. 슬랙 알림 도구는 cron으로 돌아가고, PG 계산기는 정적 페이지다. 둘 다 새벽 2시에 긴급 정산 이슈가 터져도 아무 영향을 받지 않는다. 사이드 프로젝트의 생존 조건이 "운영 부담이 0에 가까울 것"임을 이제는 시작 전 체크리스트로 쓴다.

트레이드오프: 작게 빠르게 배포하면 잃는 것도 있다

"처음부터 작게, 실사용자와 함께"가 만능은 아니다. 트레이드오프가 분명히 있었다. 빠르게 배포한 슬랙 알림 도구는 초기에 에러 핸들링이 없었다. 정산 API가 타임아웃 나면 아무 알림도 오지 않았고, 실제로 한 달에 두 번꼴로 조용히 실패하고 있었다는 걸 나중에야 알았다. 빠른 배포의 대가로 신뢰성을 희생했고, 이를 보완하는 데 나중에 예상보다 더 많은 시간이 들었다. PG 계산기도 수수료율을 하드코딩했다가 PG사 정책이 바뀌었을 때 계산 결과가 틀린 채로 두 달 넘게 살아있었다.

이 경험에서 배운 건 "작게 시작하되, 실패 모드는 명시적으로 만들어라"는 것이다. 기능을 최소화하는 건 좋지만, 그 기능이 조용히 틀리는 상황은 결제·정산 맥락에서 신뢰를 빠르게 갉아먹는다. 지금 기준으로는, 사이드 프로젝트가 금액·수수료·정산 결과처럼 숫자를 다루는 순간 에러를 숨기지 않고 명시적으로 드러내는 것을 최소 조건으로 건다. 슬랙에 "오늘 알림 실패"가 뜨는 게 조용히 넘어가는 것보다 100배 낫고, 이건 정산 시스템의 기본 원칙과 같다.

바로 써먹을 수 있는 체크리스트 세 줄

이 경험을 바탕으로 새 사이드 프로젝트를 시작하기 전, 지금은 세 가지를 먼저 확인한다.

1. "지금 당장 필요한 사람" 한 명을 먼저 확보한다. 팀 내부든, 아는 사람이든 상관없다. 그 사람이 일주일 안에 실제로 쓸 수 있는 버전을 먼저 정의한다. 쓸 수 있는 사람이 없으면 시작하지 않는다. 결제 프로덕트에서 "있으면 좋겠다"로 기능을 만드는 팀은 없다 — 사이드 프로젝트에도 같은 기준을 적용한다.

2. 첫 배포까지 이틀 이내, 기능은 최대 세 개. 강제해야 한다. 슬랙 봇이든, 스프레드시트든, 노션 공유 페이지든 형태는 상관없다. 이틀이 지나도 배포가 안 됐다면 이미 "완성 후 오픈" 패턴에 들어간 것이다. 우리 팀은 정산 자동화 스크립트 초안을 두 시간 안에 돌려보는 문화가 있는데, 사이드 프로젝트에서 그 기준을 버릴 이유가 없다.

3. 유지 비용이 월 1시간 이하인지 확인한다. 정산 마감 주간이나 긴급 이슈가 터진 달에도 완전히 방치할 수 있어야 한다. cron + 슬랙 웹훅처럼 관리 포인트가 없거나, 정적 배포처럼 서버가 필요 없는 구조여야 한다. 이 조건을 못 맞추면 범위를 줄이거나 시작을 미룬다. 8할이 죽는 건 막을 수 없다. 하지만 같은 이유로 반복해서 죽는 건 막을 수 있다.