10년 동안 개발자로 일하고, 퇴근 후와 주말에 여러 서비스를 혼자 만들면서 정말 많은 기술을 사용해봤습니다.
새로운 프레임워크가 나오면 한 번씩 써보고, 유명하다는 서비스도 붙여봤어요. 요즘은 ChatGPT, Claude, 제미나이(Gemini) 같은 인공지능 도구를 활용해 아이디어를 정리하고, 코드 초안을 만들고, 오류의 원인을 찾는 일도 자연스러운 개발 과정이 됐습니다. 흔히 말하는 바이브코딩 덕분에 혼자서도 기능을 구현하는 속도는 확실히 빨라졌어요.
하지만 인공지능이 코드를 만들어준다고 해서 서비스가 저절로 운영되는 것은 아니었습니다. 생성된 코드를 검토하고, 데이터 구조와 보안을 결정하고, 배포 이후의 문제까지 책임지는 일은 여전히 개발자의 몫입니다. 그래서 1인개발에서는 기술의 기능만큼이나 혼자서 오래 운영할 수 있는가가 중요하더라고요.
개발 속도가 아무리 빨라도 배포가 복잡하거나, 장애가 날 때 확인할 곳이 너무 많거나, 매달 고정 비용이 크게 나가면 프로젝트를 계속 유지하기 어렵습니다.
지금은 새로운 서비스를 시작할 때 아래 조합을 먼저 검토합니다.
- 배포: Cloudflare Pages
- 데이터베이스와 인증: Supabase
- 웹 프론트엔드: SvelteKit
- 앱 개발: Flutter
- 버전 관리와 협업: GitHub
- Redis 캐싱: Upstash
- Supabase 외 별도 DB가 필요할 때: NeonDB
이 글은 모든 프로젝트에 통하는 정답을 소개하는 글이 아닙니다. 1인개발자가 개발 속도, 운영 부담, 비용을 함께 고려하면서 정착한 현재의 선택에 가깝습니다.
기술을 고르는 기준부터 단순하게 정했습니다
예전에는 성능과 기능을 먼저 비교했습니다. 지금은 아래 질문을 먼저 봅니다.
- 혼자서 설정하고 운영할 수 있는가?
- 작은 서비스로 시작할 때 비용 부담이 적은가?
- 사용자가 늘어나도 자연스럽게 확장할 수 있는가?
- 문제가 생겼을 때 확인할 문서와 커뮤니티가 충분한가?
- 다른 서비스로 옮겨야 할 때 데이터와 코드를 가져갈 수 있는가?
1인개발에서는 가장 강력한 기술보다 관리할 것이 적은 기술이 더 좋은 선택이 되는 경우가 많았습니다.
ChatGPT로 요구사항과 테스트 항목을 정리하고, Claude로 긴 코드의 흐름을 검토하고, 제미나이로 다른 구현 방법을 비교해보기도 합니다. 이런 인공지능 기반 바이브코딩은 개발 속도를 높이는 좋은 보조 수단이지만, 어떤 도구가 만든 코드든 제가 이해하고 운영할 수 있는 범위 안에서 사용한다는 원칙은 지키고 있습니다.
1. 배포는 Cloudflare Pages
웹서비스 배포에는 Cloudflare Pages를 사용합니다.
GitHub 저장소와 연결해두면 코드를 푸시할 때 빌드와 배포가 이어지고, 브랜치별 미리보기 환경도 만들기 편합니다. 작은 프로젝트를 시작할 때 서버를 직접 구성하거나 배포 스크립트를 복잡하게 관리하지 않아도 된다는 점이 좋았습니다.
특히 정적 자산을 전 세계에 빠르게 제공할 수 있고, 도메인과 HTTPS 설정까지 한 흐름에서 관리할 수 있어 1인개발에 잘 맞았습니다.
제가 Cloudflare Pages를 선택하는 가장 큰 이유는 화려한 기능보다 배포를 잊고 제품 개발에 집중할 수 있기 때문입니다.
2. 웹 프론트엔드는 SvelteKit
웹 프론트엔드는 SvelteKit으로 만들고 있습니다.
Svelte는 작성해야 하는 코드가 비교적 간결하고, 컴포넌트 안에서 화면과 로직의 흐름을 이해하기 편했습니다. 혼자 개발할 때는 며칠 뒤 다시 코드를 열어도 빠르게 맥락을 되찾는 것이 중요한데, 이 부분에서 만족도가 높았습니다.
SvelteKit을 사용하면 라우팅, 서버 렌더링, 데이터 로딩, API 처리처럼 웹서비스에 필요한 기본 구조를 한 프레임워크 안에서 다룰 수 있습니다.
- 빠르게 화면을 만들기 좋음
- 컴포넌트 코드가 비교적 단순함
- 서버와 클라이언트 로직을 한 프로젝트에서 관리 가능
- 작은 서비스부터 실제 운영 서비스까지 확장 가능
유행하는 기술을 계속 바꾸기보다 지금은 SvelteKit으로 빠르게 기능을 만들고 사용자 반응을 확인하는 쪽을 선택하고 있습니다.
3. 데이터베이스와 인증은 Supabase
대부분의 프로젝트에서는 Supabase를 먼저 사용합니다.
PostgreSQL 데이터베이스뿐 아니라 인증, 파일 저장소, 실시간 기능, 서버 함수처럼 서비스 초기에 필요한 기능을 함께 제공하기 때문입니다. 회원가입과 로그인부터 직접 만들기 시작하면 생각보다 확인할 보안 항목과 예외 상황이 많습니다.
Supabase를 사용하면 아래 기능을 한곳에서 관리할 수 있습니다.
- PostgreSQL 데이터베이스
- 이메일과 소셜 로그인
- 파일 업로드와 스토리지
- Row Level Security를 이용한 접근 제어
- 실시간 데이터 처리
- 간단한 백엔드 함수
1인개발에서 백엔드 전체를 처음부터 구성하는 시간을 줄여준다는 점이 가장 큽니다. 또한 기반이 PostgreSQL이라 SQL을 그대로 활용할 수 있다는 점도 마음에 듭니다.
4. 앱 개발은 Flutter
모바일 앱은 Flutter를 사용합니다.
iOS와 Android 앱을 각각 따로 개발하기에는 1인개발자의 시간이 너무 부족합니다. Flutter는 하나의 코드베이스로 두 플랫폼을 함께 관리할 수 있고, UI를 원하는 형태로 빠르게 구성하기 좋았습니다.
처음에는 플랫폼별 세부 차이를 처리해야 하는 부분이 낯설었지만, 프로젝트가 길어질수록 하나의 코드와 디자인 시스템을 유지하는 장점이 더 크게 느껴졌습니다.
- iOS와 Android 코드를 함께 관리
- 일관된 UI 구현
- 빠른 수정과 확인
- 웹에서 사용하던 API와 백엔드 구조를 그대로 활용
웹은 SvelteKit, 앱은 Flutter로 역할을 나누면 각 플랫폼의 장점을 살리면서도 Supabase 같은 백엔드를 함께 사용할 수 있습니다.
5. 버전 관리는 GitHub
GitHub는 소스 코드를 보관하는 곳을 넘어 개발 작업의 중심으로 사용합니다.
기능별 브랜치를 만들고, 이슈에 해야 할 일을 적고, GitHub Actions로 반복 작업을 자동화합니다. 혼자 개발하면 코드 리뷰를 해줄 동료가 없기 때문에 커밋과 Pull Request 기록이 나중의 나를 위한 문서가 되기도 합니다.
서비스별 저장소를 GitHub에 모아두면 Cloudflare Pages 같은 배포 서비스와 연결하기도 쉽습니다. 결국 코드 작성부터 기록, 자동화, 배포까지 하나의 흐름으로 이어집니다.
6. Redis 캐싱은 Upstash
캐시나 간단한 대기열이 필요할 때는 Upstash의 Redis를 사용합니다.
Redis 서버를 직접 설치하고 관리하지 않아도 되고, 요청 기반으로 시작할 수 있어 트래픽이 크지 않은 초기 서비스에 부담이 적습니다.
제가 주로 사용하는 경우는 다음과 같습니다.
- 자주 조회하는 데이터 캐싱
- API 호출 횟수 제한
- 일회성 토큰과 짧은 상태 저장
- 중복 작업 방지
- 간단한 작업 대기열
처음부터 모든 데이터를 캐싱하지는 않습니다. 실제로 느린 구간이 확인됐을 때 필요한 부분에만 Upstash를 추가하는 편이 구조도 단순하고 비용을 관리하기 좋았습니다.
7. 별도 PostgreSQL이 필요하면 NeonDB
Supabase의 인증이나 스토리지는 필요하지 않고 PostgreSQL 데이터베이스만 별도로 필요한 프로젝트라면 NeonDB를 검토합니다.
프로젝트마다 데이터베이스를 분리하고 싶거나, 기존 백엔드에서 사용할 서버리스 PostgreSQL이 필요한 경우에 선택하기 좋았습니다. 브랜치 기능을 활용하면 개발과 테스트 환경을 나누는 작업도 편리합니다.
정리하면 제 기준은 단순합니다.
- 인증, 스토리지, 데이터베이스를 함께 빠르게 만들 때는 Supabase
- PostgreSQL 데이터베이스만 독립적으로 필요할 때는 NeonDB
둘 중 무엇이 더 좋다기보다 프로젝트에서 필요한 범위에 맞춰 선택합니다.
지금 사용하는 전체 구성
새로운 웹서비스를 만든다면 보통 아래 순서로 시작합니다.
- GitHub에 저장소를 만들고 작업을 기록합니다.
- SvelteKit으로 웹 화면과 서버 로직을 구성합니다.
- 회원과 데이터가 필요하면 Supabase를 연결합니다.
- 반복 조회나 호출 제한이 필요해질 때 Upstash를 추가합니다.
- 별도의 PostgreSQL이 필요하면 NeonDB를 사용합니다.
- Cloudflare Pages에 연결해 자동으로 배포합니다.
- 모바일 앱이 필요해지면 같은 백엔드를 사용하는 Flutter 앱을 만듭니다.
이렇게 역할을 정해두면 프로젝트를 시작할 때마다 기술 조사에 너무 많은 시간을 쓰지 않아도 됩니다. 어떤 도구를 사용할지 고민하는 시간보다 실제 사용자가 필요한 기능을 만드는 데 시간을 쓸 수 있습니다.
10년차가 되어 알게 된 것은 기술보다 운영입니다
오랫동안 사용할 기술을 고르는 기준은 결국 “이 기술이 얼마나 멋진가”보다 “내가 이 프로젝트를 계속 운영할 수 있는가”였습니다.
혼자 개발하다 보면 기획, 디자인, 개발, 배포, 고객 대응을 모두 해야 합니다. 그래서 한 영역에서라도 관리할 것이 줄어들면 전체 프로젝트를 유지하기가 훨씬 쉬워집니다.
지금의 기술 조합도 영원한 정답은 아닐 겁니다. 다만 새로운 도구가 나올 때마다 바로 교체하기보다, 현재 서비스의 문제를 실제로 해결해주는지 확인한 뒤 천천히 바꾸려고 합니다.
소개한 기술 링크 한곳에서 보기
이번 글에서 소개한 Svelte, Flutter, Supabase, Upstash, NeonDB, Cloudflare 관련 링크는 아래 Urlala 공유 폴더에 모아두었습니다.
프로젝트를 시작할 때 필요한 공식 사이트를 각각 검색하는 대신 공유 폴더에서 한 번에 확인해보세요. 자신에게 맞는 기술 조합을 정리할 때 참고 자료로 활용하셔도 좋습니다.
기술 선택에 쓰는 시간을 줄이고, 실제로 만들고 싶은 서비스를 완성하는 데 더 많은 시간을 사용할 수 있기를 바랍니다.
