솔로 풀스택 완성법 (완성 기준, 기술 스택, AI 협업)

혼자 풀스택 프로젝트 완성하는 법

사이드 프로젝트 공동묘지라는 말이 있습니다. GitHub 레포를 열어보면 마지막 커밋이 "initial commit"인 레포가 줄지어 있는 그곳입니다. 저도 그 묘지에 묻힌 프로젝트가 몇 개인지 세는 게 민망할 정도입니다. 그런데 어느 시점에 처음으로 배포까지 마치고, 유료 사용자까지 얻었습니다. 달라진 건 기술이 아니라, 딱 두 가지였습니다.

완성 기준을 바꾸면 프로젝트 범위가 80% 줄어듭니다

솔직히 이건 예상 밖이었습니다. 제가 오래 붙잡고 있던 가장 큰 문제는 기술 부채나 시간 부족이 아니었습니다. '완성'이 무엇인지에 대한 정의가 잘못돼 있었습니다.

예전에 저는 완성을 기획서에 적힌 모든 기능이 구현된 상태로 봤습니다. 그러니 끝이 없었습니다. 기능 하나를 만들면 두 개가 더 떠올랐고, 데이터 모델링을 하다 보면 엣지 케이스가 무한정 생겼습니다. 지금은 기준이 다릅니다. 완성은 단 한 명의 외부 사용자가 가입해서 핵심 기능을 쓸 수 있는 상태입니다. 이 기준 하나를 바꿨더니 기능 범위가 80%가량 줄었습니다.

이걸 업계에서는 MVP라고 부릅니다. MVP란 시장 검증에 필요한 최소 기능만 담은 초기 버전을 의미하는데, 말로는 쉽지만 실천이 어렵습니다. 제가 직접 써봤는데, 처음엔 이것도 MVP고 저것도 MVP라며 스스로를 합리화하더라고요. MVP의 핵심은 기능을 추가하는 게 아니라 제거하는 과정입니다. 기능 하나를 넣을 때마다 이게 없으면 첫 사용자가 이탈하는가를 물어봤고, 그 질문에 아니오가 나오면 가차 없이 잘랐습니다.

제가 이 과정에서 가장 어려웠던 건, 잘라낸 기능이 사실은 제가 가장 자랑하고 싶었던 기능이었다는 점입니다. 저는 한 프로젝트에서 추천 알고리즘을 만드는 데 거의 3주를 쏟았는데, 결국 그 기능을 첫 배포에서 통째로 뺐습니다. 추천 알고리즘이 없어도 핵심 기능인 데이터 저장과 조회는 정상적으로 동작했기 때문입니다. 그 3주가 아깝다는 생각이 한동안 들었지만, 지금 와서 보면 그 경험 덕분에 다음 프로젝트에서는 처음부터 "이게 핵심인가"를 더 빠르게 판단할 수 있게 됐습니다.

시간 관리 방식도 바뀌었습니다. 처음엔 주말에 몰아서 6시간짜리 집중 세션을 두 번 잡았는데, 결과가 영 좋지 않았습니다. 세션 사이에 맥락이 끊기고, 주말만 기다리다가 중간에 동기가 식어버렸습니다. 제 경험상 이건 좀 다릅니다. 평일 매일 45분씩 꾸준히 하는 방식이 완성률을 훨씬 높여줬습니다. 짧은 세션에 맞게 태스크를 쪼개는 것, 그게 핵심입니다. 인디 해커 커뮤니티에서도 꾸준한 소규모 진행이 완성률에 직결된다는 경험담이 반복적으로 등장합니다.

개발 중반에 반드시 찾아오는 게 있습니다. 아무도 안 쓸 것 같다는 불안감입니다. 제가 직접 겪어보니, 이 구간을 버티느냐 무너지느냐가 완성 여부를 가릅니다. 이건 기술 문제가 아니라 심리 문제입니다. 저는 이 시기를 버틴 방법이 두 가지였는데, 하나는 완성 기준을 낮게 잡아두는 것, 다른 하나는 태스크를 너무 작게 쪼개서 오늘 뭘 했다는 감각을 매일 유지하는 것이었습니다.

덧붙이자면, 저는 이 불안감이 사실 신호로서는 나쁘지 않다고 생각하게 됐습니다. 아무도 안 쓸 것 같다는 생각이 든다는 건 결국 그 제품을 실제로 쓸 사람을 구체적으로 떠올리고 있다는 뜻이기도 합니다. 문제는 그 생각에 멈춰서 손을 놓는 것이고, 해법은 그 불안을 다음 태스크 하나를 끝내는 동력으로 바꾸는 것이었습니다.

솔로 풀스택 개발에서 완성까지 이어지는 체크포인트를 정리하면 다음과 같습니다.

• MVP 정의: 핵심 기능 1~2개만 선택, 나머지는 백로그로 이동
• 일일 세션 확보: 45분 단위 태스크로 분할, 주말 몰아치기 지양
• 배포 기준 설정: 외부 사용자 1명이 쓸 수 있는 순간이 곧 완성
• 중반 슬럼프 대비: 완성 기준을 미리 문서화해두고 흔들릴 때 꺼내보기

기술 스택 선택과 AI 협업이 속도를 결정합니다

예전에 저는 사이드 프로젝트에도 마이크로서비스 아키텍처를 얹으려 했습니다. 마이크로서비스란 하나의 큰 애플리케이션을 독립적으로 배포 가능한 작은 서비스 단위로 분리하는 소프트웨어 설계 방식입니다. 확장성은 좋지만, 솔로 개발자에게는 오버엔지니어링, 즉 실제 필요 이상으로 복잡한 구조를 설계하는 함정에 빠지기 딱 좋습니다. Docker와 k8s까지 붙이다가 정작 핵심 기능을 한 줄도 못 만든 적이 한두 번이 아닙니다.

지금 와서 생각해보면, 그때 제가 마이크로서비스를 고집했던 이유는 사실 기술적 필요가 아니라 불안감이었습니다. 나중에 사용자가 늘어나면 어쩌지 하는 걱정이 먼저였고, 그 걱정을 해결하겠다고 처음부터 복잡한 구조를 짠 겁니다. 그런데 사용자가 0명인 상태에서 확장성을 걱정하는 건 순서가 완전히 뒤바뀐 일입니다. 이걸 인정하기까지 시간이 꽤 걸렸습니다.

지금은 Next.js와 Supabase, Vercel 조합으로 거의 모든 걸 해결합니다. 이 스택의 장점은 단순히 빠른 게 아닙니다. Supabase는 PostgreSQL 기반의 오픈소스 BaaS입니다. BaaS란 인증, 데이터베이스, 스토리지 같은 백엔드 기능을 미리 구현된 서비스 형태로 제공하는 플랫폼을 의미합니다. 데이터베이스 스키마 설계부터 인증, 스토리지까지 백엔드 기능 대부분이 여기서 해결되고, Vercel에 연결하면 CI/CD 파이프라인까지 자동으로 구성됩니다. CI/CD란 코드 변경이 발생할 때마다 자동으로 테스트하고 배포하는 개발 운영 방식입니다. 배포까지 걸리는 시간이 처음 경험하면 반나절도 안 걸린다는 게 믿기지 않을 정도입니다.

AI 협업 방식은 이 스택과 맞물려서 더 강력해졌습니다. 제가 직접 써봤는데, AI는 이 스택에 대한 학습 데이터가 풍부해서 질문과 답변 사이클이 눈에 띄게 빠릅니다. 구체적으로 어떻게 쓰냐면, 기획 단계에서는 이런 앱을 만들려는데 MVP 기능 리스트를 짜달라고 요청하는 것으로 시작합니다. 설계 단계에선 데이터베이스 스키마 초안을 요청하고, 개발 중엔 특정 기능 구현을 요청하고, 막히면 에러 원인을 물어봅니다. 사실상 페어 프로그래밍을 AI와 하는 셈인데, 피로가 없고 24시간 응답한다는 점이 혼자 작업할 때 심리적으로 상당한 도움이 됐습니다.

단, 여기서 제 생각을 하나 덧붙이고 싶습니다. AI는 기술 문제는 잘 해결해줍니다. 그런데 이 기능이 충분한가를 판단하는 기준, 즉 충분함의 정의는 스스로 내려야 합니다. 솔로 풀스택이란 모든 것을 잘 한다가 아니라 모든 것을 충분히 한다는 의미입니다. 디자인, 인프라, 마케팅을 완벽하게 하려는 순간 프로젝트는 멈춥니다. AI는 각 영역에서 충분한 수준에 빠르게 도달하게 해주는 도구이지, 그 기준점을 대신 잡아주는 도구가 아닙니다. 이 기준 설정이 솔로 개발자에게 가장 어려운 일이기도 합니다.

제가 추가로 느낀 비판적인 지점은, AI와의 협업이 너무 매끄러워지면서 오히려 의사결정을 미루는 습관이 생길 수 있다는 점입니다. 막히면 바로 AI에게 묻는 게 습관이 되다 보니, 가끔은 제가 직접 고민해서 더 좋은 답을 낼 수 있는 상황에서도 AI에게 먼저 묻고 그 답을 그대로 받아들이는 경우가 있었습니다. 저는 이걸 깨닫고 나서, 적어도 5분은 스스로 생각해보고 그 다음에 AI에게 묻는 규칙을 정했습니다.

사이드 프로젝트 동기 유지에 관한 분석에서도 완성을 경험한 개발자들이 공통적으로 언급하는 요소로 범위 제한과 배포 우선 사고방식을 꼽았습니다. 제 경험과 정확히 일치했습니다. 첫 유료 사용자 1명을 3개월 만에 얻었을 때, 금액 자체는 작았습니다. 그런데 그 경험이 다음 프로젝트의 기준점이 됐습니다. 한 번 됐으니 다음에도 된다는 감각은 생각보다 강력합니다.

사이드 프로젝트를 완성까지 끌고 가는 건 기술력보다 판단력의 문제입니다. 무엇을 만들지보다 무엇을 만들지 않을지를 결정하는 것, 완성의 기준을 낮게 잡는 것, 그리고 중반의 불안감을 버티는 것. 이 세 가지가 갖춰지면 기술 스택과 AI는 실제로 강력한 도구가 됩니다. 공동묘지에 레포 하나를 더 추가하기 전에, 먼저 완성의 정의부터 다시 써보시길 권합니다.

---

참고:
Pieter Levels – Make (2019) / Daniel Vassallo – "The Side Project Checklist" (2023) / Indie Hackers – https://www.indiehackers.com / Thoughtbot Blog – "How to Ship Side Projects" (2023) / Smashing Magazine – "Side Projects: Staying Motivated" (2023)