1인 개발자의 기술 스택 선택 기준

개발
·Dante Chun

들어가며

기술 스택 선택은 프로젝트의 성패를 좌우할 수 있다. 특히 혼자 개발하는 상황에서는 잘못된 선택이 곧바로 생산성 저하와 유지보수 지옥으로 이어진다.

5년간 1인 개발사를 운영하며, 수십 개의 프로젝트를 거치면서 나만의 기술 스택 선택 기준이 생겼다. 단순히 "뭐가 좋다더라"가 아니라, 실제로 검증된 원칙들이다.

핵심 원칙: "지루한 기술을 선택하라"

이 말은 Dan McKinley의 유명한 글 "Choose Boring Technology"에서 따온 것이다. 처음에는 와닿지 않았지만, 몇 번의 실패를 겪고 나서 뼈저리게 느꼈다.

새로운 기술의 함정

2022년, 클라이언트 프로젝트에 당시 막 나온 기술 A를 도입했다. "이거 쓰면 개발 속도가 2배 빨라진다!"는 글을 보고 혹했다.

결과는?

  • 공식 문서가 빈약해서 삽질 시간 증가
  • 버그를 만나면 Stack Overflow에 검색 결과가 없음
  • 메이저 버전 업데이트로 코드 전면 수정 필요

결국 기존 기술로 다시 작성했다. 시간 낭비였다.

지루한 기술의 장점

반면, React, Node.js, PostgreSQL 같은 "지루한" 기술들은:

  • 문제가 생기면 검색으로 해결책을 찾을 수 있다
  • 생태계가 성숙해서 필요한 라이브러리가 있다
  • 장기 지원이 보장된다

혼자 개발할 때는 문제 해결에 쏟는 시간을 최소화해야 한다. 새로운 기술은 팀이 있을 때 실험하자.

내 기준 1: 하나의 언어로 통일

풀스택 JavaScript/TypeScript

프론트엔드와 백엔드를 다른 언어로 작성하면 컨텍스트 스위칭 비용이 발생한다. 혼자 개발할 때 이건 치명적이다.

❌ 피하는 조합
- React (JavaScript) + Django (Python) + PostgreSQL
- Vue (JavaScript) + Spring (Java) + MySQL

✅ 내가 쓰는 조합
- Next.js (TypeScript) + NestJS (TypeScript) + PostgreSQL

같은 언어를 쓰면:

  • 타입을 프론트/백엔드에서 공유할 수 있다
  • 코드 복사-붙여넣기가 가능하다
  • 빌드 도구를 통일할 수 있다
  • 러닝 커브가 없다

예외 상황

물론 예외는 있다. 클라이언트가 특정 기술 스택을 요구하거나, 성능상 다른 언어가 필요할 때. 하지만 선택권이 있다면 항상 TypeScript를 선택한다.

내 기준 2: 관리 포인트 최소화

매니지드 서비스 활용

인프라 관리에 시간 쓰고 싶지 않다. 돈을 좀 더 내더라도 관리형 서비스를 쓴다.

내 선택:
- 데이터베이스: Vercel Postgres, Supabase, PlanetScale
- 호스팅: Vercel, Railway
- 파일 저장: Vercel Blob, Cloudflare R2
- 인증: NextAuth.js (자체 구현 대신)

직접 서버 관리하면 SSL 갱신, 보안 패치, 백업, 모니터링... 이런 것들이 계속 발목을 잡는다.

로컬 개발 환경

하지만 개발 환경에서는 Docker로 필요한 것들을 로컬에서 돌린다. PostgreSQL, Redis 등. 비용도 없고, 인터넷 연결 없이도 개발할 수 있다.

# docker-compose.yml
services:
  postgres:
    image: postgres:15
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: myapp
    ports:
      - "5432:5432"

내 기준 3: 커뮤니티 크기

생태계의 힘

기술 선택 시 GitHub 스타 수보다 중요한 건 활성 커뮤니티다.

체크리스트:

  • Stack Overflow 질문 수
  • GitHub 이슈 응답 속도
  • Discord/Slack 커뮤니티 활성도
  • npm 주간 다운로드 수
  • 최근 업데이트 날짜
예시 - State Management 라이브러리 비교
Zustand: npm 주간 다운로드 300만+, 활발한 이슈 대응
MobX-State-Tree: 다운로드 적고, 이슈 대응 느림
→ Zustand 선택

대안이 있는지

특정 기술에 의존할 때는 항상 "이게 망하면 어떻게 하지?"를 생각한다. 대안이 있는 기술을 선택하거나, 마이그레이션 경로가 명확한 기술을 선택한다.

내 기준 4: 비용 예측 가능성

클라이언트 프로젝트는 비용이 중요하다

프로젝트 완료 후 유지보수 단계에서 예상치 못한 비용이 발생하면 곤란하다. 클라이언트와의 신뢰 문제로 이어진다.

비용 예측 가능한 서비스:
- Vercel Pro: $20/월 (웬만한 트래픽 커버)
- Railway: 사용량 기반이지만 상한 설정 가능
- Supabase: Free tier 후 $25/월부터

비용 예측 어려운 서비스:
- AWS 종량제 (트래픽 폭발 시 청구서 폭발)
- 시간당 과금 VM (켜놓으면 계속 과금)

내 프로젝트는 무료 티어 활용

개인 프로젝트나 사이드 프로젝트는 무료 티어를 적극 활용한다. Vercel Hobby, Supabase Free, Cloudflare 무료 플랜 조합으로 월 $0에 운영 가능하다.

내 기준 5: 탈출 가능성

Vendor Lock-in 주의

특정 플랫폼에 종속되면 나중에 이전하기 어렵다.

Lock-in 위험 높음:
- Firebase Realtime Database (구조가 독특함)
- AWS Lambda + API Gateway + DynamoDB 조합
- Vercel의 Edge Functions (표준 아닌 API)

Lock-in 위험 낮음:
- PostgreSQL (어디서든 호스팅 가능)
- 표준 Node.js (Express, Fastify 등)
- Docker 컨테이너 (어디서든 실행 가능)

마이그레이션 경험

실제로 Vercel에서 Railway로, Supabase에서 직접 호스팅하는 PostgreSQL로 옮긴 경험이 있다. PostgreSQL을 썼기 때문에 데이터 마이그레이션은 pg_dump/pg_restore로 간단했다.

현재 내 스택

2025년 현재 내가 사용하는 기본 스택:

프론트엔드:
- Next.js (App Router)
- TypeScript
- Tailwind CSS
- React Query (서버 상태)
- Zustand (클라이언트 상태)

백엔드:
- Next.js API Routes (간단한 경우)
- NestJS (복잡한 경우)
- Prisma
- PostgreSQL

인프라:
- Vercel (호스팅)
- Docker (로컬 개발)
- GitHub Actions (CI/CD)

도구:
- VS Code
- pnpm
- Cursor (AI 보조)

새 프로젝트마다 이 스택에서 크게 벗어나지 않는다. 익숙한 도구로 빠르게 시작하고, 필요할 때만 새로운 것을 추가한다.

결론

1인 개발자의 기술 스택 선택은 생존 전략이다.

최신 기술, 멋진 기술보다 중요한 건:

  • 문제를 빨리 해결할 수 있는가
  • 혼자서 유지보수할 수 있는가
  • 비용을 예측할 수 있는가
  • 필요하면 다른 곳으로 옮길 수 있는가

이 기준들을 통과하는 기술을 선택하면, 적어도 기술 때문에 프로젝트가 실패하는 일은 없을 것이다.

새로운 기술이 궁금하면 개인 프로젝트에서 먼저 실험하자. 클라이언트 프로젝트는 검증된 스택으로.

다른 글