유지보수 우선 마인드셋: 3주 만에 버리지 않을 사이드 프로젝트 설계하기

소개

사이드 프로젝트는 보통 조용히 죽습니다.

아이디어가 나빠서도 아니고, 문제에 대한 관심을 잃어서도 아닙니다. 유지보수가 점점 고역이 되기 때문에 죽습니다. 코드베이스는 무거워지고, 버그는 쌓이고, 레포를 여는 것 자체가 두려워집니다. 그러다 보면 “재미로 주말에 시작한 프로젝트”가 어느새 GitHub에 떠도는 죄책감 덩어리 유령이 되어버립니다.

여기서 빠져 있는 것은 의지나 근성이 아니라, “유지보수 우선”이라는 관점입니다.

“이걸 만들 수 있을까?” 대신, 이렇게 물어봐야 합니다.

“내 일상과 본업을 병행하면서 앞으로 6–12개월 동안 이걸 계속 관리할 수 있을까?”

처음부터 유지보수를 고려해서 설계하면, 악명 높은 “3주 차 멘탈 붕괴” 이후에도 프로젝트가 살아남을 가능성이 크게 높아집니다.

이 글에서는 사이드 프로젝트를 살려두기 쉽고, 개선하기 편하고, 나아가 유지할 이유가 생길 만큼 수익까지 낼 수 있게 만드는 실질적인 설계 전략들을 살펴봅니다.

1. 첫날부터 “유지보수”를 핵심 요구사항으로 둔다

많은 사이드 프로젝트는 먼저 기술 스택을 고르거나 화려한 기능 목록을 만드는 것에서 시작합니다. 반면, 유지보수 우선 프로젝트는 이런 질문에서 시작합니다.

“초기 열정이 식는 세 달 뒤에, 이걸 다시 만졌을 때 어떤 기분일까?”

유지보수성(maintainability)을 성능이나 보안과 같은 비협상적 요구사항으로 취급하세요.

초기에 이런 질문을 스스로에게 던져 보세요.

버그를 얼마나 쉽게 고칠 수 있을까?
한 달 동안 손을 안 댄 뒤에, 15분 만에 다시 맥락을 되찾을 수 있을까?
이미 잘 아는 스택인가, 아니면 새 프레임워크 세 개를 추가로 공부해야 하는 선택인가?

유지보수 우선 관점에서 할 수 있는 선택들:

트렌디한 스택보다 검증된 “지루한” 기술을 선호하세요. 익숙한 도구는 시간이 지나 다시 돌아왔을 때 인지 부하를 줄여줍니다.
첫날부터 README를 작성하세요. 로컬에서 실행하는 방법, 배포 방법, 필요한 환경 변수들을 적어 둡니다.
핵심 결정들을 문서화하세요. DECISIONS.md 같은 파일에 "단순함을 위해 Postgres 대신 SQLite 사용" 같은 한 줄짜리 메모만 남겨도 나중에 “괜히 갈아엎고 싶은 충동”을 많이 막아줍니다.

지금 만드는 것은 단순한 프로젝트가 아니라, **앞으로 이 프로젝트와 맺게 될 “일 관계”**입니다.

2. 유지보수를 위한 시간과 비용을 미리 예산으로 잡는다

사이드 프로젝트는 계획은 스프린트처럼 짜고, 버려질 때는 사고처럼 버려집니다.

프로젝트를 오래 가져가고 싶다면, 유지보수를 “정기 비용”으로 취급해야지, 갑자기 터지는 비상사태로 보면 안 됩니다.

시간 예산 세우기

매주 현실적으로 얼마나 시간을 쓸 수 있는지 미리 정하세요.

예:

매주 2시간을 확보해서:
- 이슈나 피드백 확인: 30분
- 작은 버그 수정이나 기술 부채 갚기: 45분
- 자잘한 기능 개선 또는 추가: 45분

캘린더에 정기 미팅처럼 반복 일정으로 넣어 두세요. **“언제든 하면 되지”**가 아니라 **“이 시간에 하는 것”**이 되어야 실제로 꾸준히 하게 됩니다.

비용 예산 세우기

도메인, 호스팅, 외부 API 같은 작은 비용도 모이면 무시 못 할 수준이 됩니다. 처음부터 계획을 세우세요.

상시 관리가 거의 필요 없는 무료 또는 저렴한 요금제를 사용합니다.
요금 구조가 단순한 서비스 제공자를 우선합니다.
가벼운 문서나 노트에 비용을 정리해 두고, 스스로 어떤 약속을 하고 있는지 명확히 인식합니다.

끝까지 유지되는 프로젝트는 운 좋게 돈이 덜 들어서가 아니라, 애초에 지속 비용을 예상하고 설계한 프로젝트입니다.

3. 단순하고 유지보수 부담이 적은 아키텍처를 선택한다

복잡한 시스템은 사이드 프로젝트의 현실 앞에서 무너집니다.

당신에겐 풀타임 Ops 팀이 있는 게 아니라, 저녁 먹고 남은 화요일 밤 한두 시간이 있을 뿐입니다.

우아함이나 유연성을 조금 포기하더라도, 단순함에 최적화하세요.

실질적으로 할 수 있는 단순화 예시:

마이크로서비스보다 모놀리식(monolith)을 선택하세요. 레포 하나, 배포 타깃 하나, 문제 생기면 들여다볼 곳도 하나.
데이터베이스 하나, 리전 하나. 샤딩, 멀티 리전, 분산 큐는 사이드 프로젝트 스케일에서 거의 필요 없습니다.
가능하면 정적(Static)으로. 정적 사이트, 서버리스 함수, 프리렌더링 페이지는 유지해야 할 표면적을 획기적으로 줄여줍니다.
외부 의존성을 줄이세요. 서드파티 API 하나하나가 또 하나의 리스크입니다. 가격 변경, 기능 폐기, 호환성 이슈가 생길 수 있습니다.

좋은 리트머스 테스트는 이것입니다.

“이 아키텍처를 친구에게 2–3문장 안에 설명할 수 있을까?”

답이 “아니오”라면, 사이드 프로젝트를 오래 가져가기엔 이미 너무 복잡한 구조일 가능성이 큽니다.

4. 가볍고 부담 없는 피드백 루프를 만든다

유저 피드백은 금광과 같습니다. 하지만 모든 피드백에 다 반응해야 한다는 압박을 느끼기 시작하면, 그 자체가 스트레스의 원인이 됩니다.

작고, 부담이 적은 피드백 채널을 설계하세요. 개선 방향을 알려주되, 당신을 압도하지 않는 형태로요.

아이디어 몇 가지:

사이트나 앱에 아주 단순한 피드백 폼을 둡니다. “어떤 점이 좋았나요? 어떤 점이 별로였나요?” 정도로 묻고, 응답은 스프레드시트나 이메일로 모읍니다.
필수 최소한의 분석 도구만 사용합니다. 예를 들어 페이지뷰나 간단한 전환율 정도만 보고, 복잡하고 프라이버시 이슈를 키우는 거대한 분석 스택은 피합니다.
몇 명의 핵심 사용자와는 이메일이나 채팅으로 가끔씩 가벼운 체크인을 합니다.

무엇보다 중요한 건, 피드백을 어떻게 활용할지 미리 규칙을 정해두는 것입니다.

매주 유지보수 시간에 한 번 피드백을 모아 봅니다.
각 피드백에 bug, nice-to-have, out-of-scope 같은 라벨을 붙입니다.
유저에게 직접 보이는 변경사항은 주당 1–2개로만 제한합니다.

당신이 만드는 것은 저녁 시간을 지배하는 피드백 시스템이 아니라, 로드맵을 도와주는 조용한 도우미여야 합니다.

5. 특히 본업이 있다면, 기능 범위를 보수적으로 잡는다

사이드 프로젝트를 죽이는 건 실력 부족이 아니라 과한 욕심인 경우가 훨씬 많습니다.

스코프를 공격적으로 잡으면 이런 결과를 맞게 됩니다.

반쯤만 완성된 기능들
부서지기 쉬운 코드베이스
항상 밀려 있다는 감각, 뒤처진다는 스트레스

대신, **“작지만 바로 쓸 수 있는 것(small and shippable)”**을 목표로 삼으세요.

보수적인 스코핑을 위한 전술들:

처음 생각한 아이디어의 더 좁은 버전을 먼저 만듭니다.
- “완전한 커뮤니티 플랫폼” 대신, “심플한 Q&A 보드”부터.
버전 번호 관점으로 생각하세요.
- v0.1: 핵심 가치만 구현한 최소 UI
- v0.2: UX 개선과 주요 버그 수정
- v0.3: 가장 많이 요청받은 기능 1–2개 추가
한 주에 진행할 새로운 작업량에 상한을 둡니다.
- 엉성한 시도 네 개보다, 의미 있는 개선 한 개가 낫습니다.

각 기능을 추가하기 전, 이렇게 물어보세요.

“지금 내 시간 예산으로, 이 기능을 1년 동안 꾸준히 관리할 수 있을까?”

대답이 애매하게 “아마도…”라면, 지금은 “아니오”라고 보는 편이 안전합니다.

6. 반복적인 작업을 자동화해서 마찰을 줄인다

유지보수를 힘들게 만드는 건 어려운 버그 자체가 아니라, 오히려 그 주변의 반복적인 잡일인 경우가 많습니다.

수동으로 해야 하는 단계가 하나 늘어날 때마다, “이건 나중에 하지 뭐”라는 말도 한 번씩 더 나옵니다. 자동화는 그 “나중에”를 “이미 완료”로 바꿔 줍니다.

다음 영역에 자동화를 집중해 보세요.

테스트

작지만 믿을 만한 테스트 스위트를 만듭니다. 10–20개의 테스트라도, 없는 것보다는 훨씬 낫습니다.
GitHub Actions, GitLab CI 같은 CI 도구로 커밋할 때마다 자동으로 테스트를 돌리게 하세요.

배포

원커맨드(one-command) 또는 원클릭 배포를 목표로 합니다.
매번 수동으로 따라야 하는 긴 체크리스트는 사이드 프로젝트의 에너지와 어울리지 않습니다.

모니터링과 알림

서비스가 죽었는지 알려주는 기본적인 Uptime 모니터링을 설정하세요.
Sentry, Rollbar 같은 에러 트래킹 도구를 사용하면, 직접 로그를 뒤지지 않고도 어떤 에러가 나는지 파악할 수 있습니다.

처음부터 완벽한 자동화를 만들 필요는 없습니다. 자동화의 목표는 완벽이 아니라, 자주 하는 일을 “귀찮지 않을 만큼”만 매끄럽게 만드는 것입니다.

7. 지속 가능성과 수익을 일찍부터 고민한다

돈이 전부는 아니지만, 유지보수를 계속할 이유를 만들어 주는 강력한 신호이긴 합니다.

사이드 프로젝트가 자기 유지 비용을 스스로 감당하거나, 조금이라도 수익을 내기 시작하면, 그 프로젝트를 건강하게 유지하기 위해 시간을 쓰는 게 훨씬 설득력 있는 선택이 됩니다.

유지보수를 더 지속 가능하게 만드는 방법들:

유료 플랜이나 “프로(Pro)” 기능을 제공해 보세요. 아주 낮은 가격이라도, 프로젝트에 대한 태도가 달라집니다.
후원이나 기부를 받게 설정하세요. GitHub Sponsors, Patreon, Buy Me a Coffee 같은 플랫폼을 이용하면 고정 비용을 상쇄하는 데 도움이 됩니다.
비즈니스를 위한 라이선스를 제안하세요. 직장에서 유용하게 쓸 수 있는 도구라면, 기업이 지원이나 추가 기능을 위해 비용을 지불할 가능성이 있습니다.

사이드 프로젝트를 스타트업으로 키우려는 야심까지는 필요 없습니다. 다만, 유지보수가 봉사활동이 아니라 “투자”처럼 느껴질 만큼의 최소한의 지속 가능성만 있으면 됩니다.

8. “미래의 나”에게 친절한 경험을 설계한다

유지보수 우선이라는 건 결국, 미래의 나를 위해 설계하는 일입니다.

3주 동안 손을 안 대다가 다시 돌아왔다고 상상해 보세요. 그때 무엇을 발견하고 싶나요?

몇 분 안에 개발 환경을 띄울 수 있는 깔끔한 README
우선순위 2–3개만 정리된 TODO 또는 ROADMAP 파일
다시 읽어도 이해할 수 있는, 적당히 정리된 코드
그냥 실행만 하면 되는 단순한 배포 스크립트

이를 위해 도움이 되는 습관들:

작업 세션을 마칠 때, 이슈 트래커에 “미래의 나”를 위한 메모를 남깁니다. 방금 무슨 일을 했는지, 다음에 무엇을 하면 될지, 주의할 점은 무엇인지 적어 두세요.
작은 단위의 Pull Request를 유지해서, 나중에 내가 쓴 코드를 내가 리뷰하기 쉽게 만듭니다.
**CHANGELOG(변경 기록)**를 관리해서, 언제 무엇이 바뀌었는지 빠르게 파악할 수 있게 합니다.

미래의 나는 이 프로젝트의 가장 중요한 협업자입니다. 동료에게 하듯, 그 사람에게도 친절하게 대하세요.

결론

사이드 프로젝트가 죽는 이유는 당신이 게을러서가 아닙니다. 애초에 유지보수를 전제로 설계되지 않았기 때문입니다.

유지보수 우선 마인드셋은 이 흐름을 완전히 뒤집습니다.

몇 달 뒤의 나도 이해할 수 있는 단순한 아키텍처를 선택합니다.
시간과 비용을, 유지보수가 “당연히 필요할 것”이라는 전제하에 미리 예산으로 잡습니다.
기능 범위를 보수적으로 잡아, 프로젝트가 스트레스가 아니라 재미로 남게 합니다.
반복 작업을 자동화해서, 진짜 의미 있는 개선에 시간을 쓸 수 있게 합니다.
지속 가능한 수익 구조를 탐색해, 프로젝트가 내 삶 속에서 차지하는 자리를 스스로 정당화하도록 만듭니다.

목표는 모든 마찰을 없애는 것이 아닙니다. 퇴근 후 지친 상태로 앉았을 때도, 이 프로젝트가 여전히 “만지고 싶은 것”으로 남을 만큼만 마찰을 줄이는 것입니다.

다음 사이드 프로젝트를 **단거리 달리기(sprint)가 아니라 관계(relationship)**로 설계해 보세요. 3주 차에 “어떻게 빠져나가지?”를 고민하는 대신, “다음에는 뭘 해볼까?”를 기대하게 될 것입니다.