스타트업 엔지니어링 — 0→1·PMF·기술 부채·피봇·엔지니어 채용·스케일링 고통·Founding Engineer 심층 가이드 (2025)

스타트업은 왜 대기업과 완전히 다른 게임인가

2025년 가장 뜨거운 엔지니어링 실험실은 스타트업이다. AI 창업 붐, YC 2024 winter/2025 winter 최대 배치 기록, Cursor/Perplexity/Harvey의 100억 달러 평가가 12개월 만에 이뤄진 사건이 이 판의 속도를 증명한다. 하지만 스타트업 엔지니어링은 대기업 엔지니어링과 완전히 다른 종목이다. 같은 "웹 앱 만들기"라도 전제, 제약, 성공 기준이 모두 다르다.

• 대기업: 시스템은 스케일 증명됨, 목표는 복잡도 관리
• 스타트업: 시스템은 매주 바뀜, 목표는 학습 속도

대기업 엔지니어가 스타트업에 합류해 "아키텍처를 정비"하려다 3개월 만에 번아웃 되는 이유가 여기 있다. 반대로 스타트업 엔지니어가 대기업에 가면 "왜 한 기능 출하에 3개월 걸리느냐"며 절망한다. 이 글은 스타트업 엔지니어링의 2025년을 단계별·역할별로 본다.

이 글은 Product Engineering 가이드의 확장이다. 프로덕트 감각이 있는 엔지니어가 가장 크게 빛나는 무대가 스타트업이다.

1부. 0→1 vs 1→10 vs 10→100 — 각 단계의 다른 법칙

1.1 0→1 — PMF 이전

• 팀 1~5명, 주 단위 방향 전환
• 모든 결정이 속도 대 올바름의 트레이드오프에서 속도를 선택
• 코드 품질 < 학습 속도
• 성공 지표: 10명 고객이 "왜 이 정도로 잘 안 작동하냐"고 화낼 정도로 사용

1.2 1→10 — PMF 직후

• 팀 5~30명, Series A 전후
• 처음으로 처음 만든 걸 다시 만들 여유
• 핫한 스택으로 넘어가거나 유지할 결정
• 성공 지표: ARR 1M→10M, Retention 안정

1.3 10→100 — 스케일업

• 팀 30~300명, Series B+
• 조직 구조·매니지먼트·플랫폼이 의미 생김
• 기술 부채에 본격 지불해야 함
• 성공 지표: ARR 10M→100M, 팀 자율성·플랫폼 자생

1.4 각 단계의 공통 오류

• 0→1에서 1→10 유물 복제 (SOC2, 마이크로서비스 조기 도입)
• 1→10에서 0→1처럼 계속 (기술 부채 폭발)
• 10→100에서 1→10처럼 (플랫폼 팀 없이 모든 팀이 각자 전투)

2부. PMF (Product-Market Fit) 찾기 전과 후

2.1 Marc Andreessen 정의 (2007)

"Product-Market Fit이란, 제품이 시장을 만족시키고 있는 상태. 그 이전도 그 이후도 존재한다."

• 그 이전: 아무리 팔려 해도 안 팔림
• 그 이후: 못 팔게 막으려 해도 팔림

2.2 측정

• Sean Ellis 테스트: "이 제품을 더 이상 못 쓰게 되면 얼마나 실망할까?" 40%+ "매우 실망"
• Cohort retention: 4주 뒤 유지율 안정화 (flat curve)
• Organic growth: 광고 없이 유저 유입 주 5%+

2.3 PMF 이전 엔지니어링

• 기능을 빠르게 덧붙이고 측정
• "완성도"가 아니라 "학습"
• Dockerfile 없이 Railway/Render/Fly.io에 배포
• Supabase/Firebase로 인증·DB 일임
• 코드 삭제가 코드 쓰기만큼 중요

2.4 PMF 이후

• Retention 개선·단위 경제성·복제 가능한 growth loop
• 첫 기술 부채 청산 (큰 덩어리 2~3개)
• 엔지니어 처음 5명 채용
• SOC2, 데이터 거버넌스, 관측가능성 도입

2.5 PMF 가짜 신호

• 펀딩 받았다 ≠ PMF
• 언론 노출 ≠ PMF
• Hunt/HN front page 1회 ≠ PMF
• 진짜 신호는 유료 고객의 집착

3부. 창업 첫 18개월의 엔지니어링

3.1 0~3개월 — MVP

• 문제 정의 검증을 위한 가장 빠른 것
• Supabase + Next.js + Vercel 조합 4시간 배포
• 결제는 Stripe Checkout — 코드 10줄
• 분석은 Posthog 또는 Plausible

3.2 3~6개월 — 초기 고객

• 10~50명 고객
• CS 자체가 발견 도구 (Slack/Discord 채널)
• 기능 파이프라인이 실제 대화로 결정

3.3 6~12개월 — PMF 탐색

• 5개 가설 빠르게 굽고 버리기
• 가설 1개 성공 → 집중
• 첫 엔지니어 채용 결정

3.4 12~18개월 — 스케일 준비

• Series A 탐색
• 기술 부채 청산 1차 (가장 아픈 3개)
• 플랫폼 코드와 프로덕트 코드 분리 시작
• 데이터 인프라 기초 (BigQuery/Snowflake)

3.5 공통 함정

• Rewrite 유혹 — 프랑켄스타인 1년차, 깔끔해지고 싶어 6개월 날림
• Over-engineering — K8s, 마이크로서비스, CQRS를 10명 때부터

4부. 기술 부채의 전략적 활용

4.1 기술 부채 ≠ 나쁜 코드

• Ward Cunningham 정의: "미래에 지불할 대출로 빨리 출하하는 것"
• 의식적이고 관리되는 부채 = 무기
• 무의식적 부채 = 파산

4.2 유형

• Deliberate & Prudent: "스케일 오기 전엔 이걸로 충분함을 안다"
• Deliberate & Reckless: "돈 먼저, 나중에 갚자" (단기 승부)
• Inadvertent & Prudent: "이제 알았네, 뭘 했어야 하는지"
• Inadvertent & Reckless: "아무도 몰랐다" (교육·코드리뷰 부재)

4.3 갚는 법

• Boy Scout Rule: 손대는 곳만 조금씩
• Dedicated Sprint: 분기마다 1~2주 전용
• Parallel Rewrite: 새 시스템 병렬, 점진적 이관
• Big Bang Rewrite: 위험하지만 때로 유일한 선택

4.4 "기술 부채" 언어로 비기술자와 대화

• 숫자로 바꾸기: "이 부채가 주 8시간 타격"
• 리스크: 보안, 장애, 채용
• 기회비용: "이거 못 고치면 다음 기능 3주 지연"

5부. 2025년 스타트업 기본 스택

5.1 Frontend

• Next.js 15 + React 19 (App Router)
• Tailwind CSS + shadcn/ui — 거의 표준
• TanStack Query + Zustand (로컬) / Zustand → Jotai (신호 기반 이동 추세)
• Form: React Hook Form + Zod
• Animation: Framer Motion / Motion One

5.2 Backend

• tRPC or Next.js API Routes + Server Actions
• 또는 Hono (Cloudflare Workers), Fastify
• ORM: Drizzle (뜨거움), Prisma (여전히 강세)

5.3 DB

• Postgres (Supabase/Neon/PlanetScale for Postgres/Railway)
• 2024 Neon autoscaling·branching이 Dev 편의 새 기준
• Redis (Upstash — serverless)
• Vector: pgvector 기본

5.4 Auth

• Clerk, WorkOS, Supabase Auth, Auth.js
• Passkey 지원 필수

5.5 결제

• Stripe, Polar (OSS 지향), Lemon Squeezy (merchant of record)

5.6 인프라

• Vercel (기본값), Cloudflare Workers (엣지), Railway/Render (full-stack), Fly.io (region)
• 컨테이너 필요 시 Fly.io > Railway > AWS

5.7 분석·실험·관측

• Posthog (분석 + 실험 + 세션 리플레이 + feature flag)
• Statsig (실험 특화)
• Sentry (에러 + 성능)
• Axiom / Baselime (로그)
• Grafana Cloud Free Tier

5.8 LLM

• OpenAI·Anthropic·Google·Groq·Together·OpenRouter
• Vercel AI SDK (2024~2025 폭발적 성장)
• Mastra / LangGraph / Claude Agent SDK

5.9 이메일·오퍼레이션

• Resend (Trans), Loops (마케팅)
• Linear (이슈), Notion (문서), Slack/Discord

6부. 피봇 — 무엇을 얼마나 바꾸는가

6.1 Lean Startup 피봇 10가지 (Eric Ries)

• Zoom-in/Zoom-out, Customer Segment, Customer Need, Platform, Business Architecture, Value Capture, Engine of Growth, Channel, Technology pivots

6.2 피봇 타이밍

• Retention이 6개월 개선 안 됨
• 세 번의 큰 실험 모두 실패
• 팀 에너지 고갈
• "이 방향이 맞을까" 의심을 창업자가 3개월 이상

6.3 피봇에서 엔지니어의 역할

• 기술 자산 인벤토리 (무엇을 재사용 가능한가)
• 피봇 속도 측정 — "새 방향을 얼마 만에 빌드 가능한가"
• 코드의 30%를 버릴 용기

6.4 유명 피봇 사례

• Slack (Glitch 게임 → 사내 채팅)
• Instagram (Burbn → 사진 공유)
• Discord (OpenFeint → 게이머 채팅)
• Twitch (Justin.tv → 게임 스트리밍)
• Cursor (Python gym → VSCode IDE)

7부. 첫 엔지니어 채용

7.1 Founding Engineer vs Early Employee

• Founding Engineer: 코파운더 수준의 지분 (1~5%), 모든 결정 참여, 실패 시 0 리스크 큼
• Early Employee #1~5: 지분 0.3~1%, 기술 리드 역할, 스타트업 경험 필요
• 경계는 모호 — 문화·권한이 실질

7.2 채용 신호

• 오너십: 업무가 아니라 결과로 사고
• 속도: 코딩 속도가 아니라 문제 해결 속도
• 커뮤니케이션: 비동기 글쓰기 강함
• 애매함 견디기: 사양 없이도 진행

7.3 인터뷰 구성 (스타트업 특화)

• 1~2시간 페어 프로그래밍 (실제 문제)
• 이전 프로젝트 depth interview
• 가치관 대화 (작은 팀 스트레스 시나리오)
• 창업자가 1on1

7.4 피해야 할 것

• 화이트보드 알고리즘 5시간 → 스타트업 실무와 무관
• Take-home 48시간 → 현직자 불이익
• PhD 필터 → 실전 능력과 상관 적음

7.5 보상

• 지분 스칼라가 큼 (현금 + 지분 조합)
• 2024 ISO 유효기간·early exercise·83(b) 조언 중요
• 투명한 option pool 문서화

8부. 채용이 망가지는 10가지

1. 이상적 후보 스펙만 나열 (실재 안 함)
2. 합격 후 3주 연락 없음 → 경쟁사로 이직
3. 인터뷰어 훈련 없음 (면접관마다 다른 질문)
4. Take-home과 실무 불일치
5. 레퍼런스 체크 생략
6. 연봉 공개 회피
7. "Team culture fit"을 차별 구실로
8. Onboarding 첫 주 방치 → 3개월 내 퇴사
9. 시니어만 고용 → 주니어 성장 트랙 없음
10. Ghosting — 탈락자에게도 통보 안 함

9부. 스케일 고통 — Scaling Pains

9.1 10명 → 50명

• 모두가 모든 걸 알던 시절 끝
• 첫 EM 지명 (내부 or 외부)
• 코드 오너십 → 팀 오너십
• Slack 채널 폭발

9.2 50명 → 200명

• 부서 생김 (Eng/Product/Design/GTM)
• 플랫폼 팀 등장
• OKR·1on1·퍼포먼스 리뷰 체계
• "문화"를 의식적으로 기록하기 시작

9.3 200명 → 1000명

• Engineering Org 층 분리 (IC·EM·Director·VPE)
• Enterprise Sales와 엔지니어링 합의 필요
• 보안·규제(SOC2 Type 2, ISO 27001, HIPAA)
• 인수합병·국제화

9.4 각 단계의 전형적 DB 고통

• 10명: SQLite or Postgres on Supabase, 괜찮음
• 50명: 쿼리 느림 → 인덱스 공부 긴급
• 200명: 리드 레플리카 + 캐시
• 1000명: 샤딩 / CQRS / 서비스 분리

9.5 기술이 아닌 고통들

• 일관성 상실 — 같은 문제 두 팀 다르게 해결
• 의사결정 병목 — CEO/CTO 승인 없으면 정지
• 미팅 지옥 — 25% 이상 시간 회의
• 문화 희석 — 초기 가치가 신규 입사자에게 전달 안 됨

10부. IC vs EM — 진로 분기점

10.1 EM 전환 신호

• 팀 조율을 즐김
• 기술보다 사람 문제에서 에너지 얻음
• 다른 엔지니어 성장에 관심

10.2 EM이 되면 안 되는 신호

• 코드 작성이 정체성
• 관리 업무가 드러운 일로 느껴짐
• 1on1을 부담스러워함

10.3 전환 경로

• Tech Lead (팀 리드 + 코딩 병행)
• EM (사람 1차, 코드 2차)
• Staff Engineer (최고 IC, 사람 관리 없음)
• Principal Engineer (조직 영향)

10.4 Staff/Principal 역할의 확산

• Will Larson "Staff Engineer" 책(2021) 기점
• "맥리저도 IC 트랙 최고"라는 인식 확산
• Meta·Google·Stripe는 Distinguished Engineer (CTO 급)

10.5 EM→IC 복귀 (glide path)

• 점점 합법화
• Shopify·Stripe·Meta에서 공식 경로
• "관리자 이후 다시 코딩"이 약점 아님

11부. 원격·하이브리드·오피스 — 2025 현실

11.1 2020~2022 원격 호황

• 풀원격이 기본값이 됨

11.2 2022~2024 RTO 파동

• Apple·Google·Meta·Amazon 오피스 복귀 강제
• 이로 인한 인재 유출

11.3 2024~2025 합의

• 하이브리드 2~3일이 중간값
• 풀원격 스타트업 여전히 강함 (GitLab, Linear, Ramp 일부)
• 시간대·문화 정렬 문서화가 성패 가름

11.4 글로벌 팀

• Deel, Rippling, Remote로 국가 간 고용
• 급여 벤치마크: Carta, Levels.fyi

11.5 한국 스타트업 특수성

• 오피스 회귀 강함
• 원격 스타트업이 글로벌 경쟁에서 유리 (Sendbird, Coupang 일부)

12부. 스타트업 엔지니어의 커리어 전략

12.1 시점별 합류 이득

• Pre-seed (1~3명): 지분 최대, 리스크 최대
• Seed (5~15명): 지분 풍부, 일 재미
• Series A (20~50명): 적당한 지분, 빠른 학습
• Series B+ (50~200명): 지분 감소, 시스템 학습
• Pre-IPO (200~1000명): 스케일 경험, 지분 작음

12.2 리스크 감수와 보상

• 1~3명 합류, 7년 후 IPO = 수십억 달러 upside
• 반면 실패 확률 80%
• 분산: 한 회사 평생 vs 4~5개 순회

12.3 언제 떠나야 하나

• 학습 곡선 평평해짐 (6개월+)
• 시장 기회가 정체
• 리더십과 신뢰 결정적 균열
• 더 좋은 자리 명확

12.4 이력서에 쓰는 법

• "feature X 구현"보다 "ARR 3M → 10M 기간 feature X가 기여"
• 지분·보상은 적지 말고 영향으로
• 스타트업 경험은 "여러 모자 쓴" 걸 강조

13부. 2025년 스타트업 트렌드 관찰

13.1 AI-native 스타트업

• Cursor, Perplexity, Harvey, Character, Hugging Face
• "AI 기능"이 아니라 AI가 핵심 제품
• 소수 엔지니어로 수억 ARR 달성 (Cursor 2023 창업, 2024 $100M ARR)

13.2 Vertical SaaS 복귀

• General horizontal SaaS 포화
• 특정 산업 특화(법률, 건설, 의료, 수의과)

13.3 Open Source Commercial

• Supabase, Posthog, Resend, Cal.com, Plausible, Infisical, Documenso
• OSS 커뮤니티가 GTM이 됨
• 2024~2025 Dub, Trigger.dev, Inbox Zero 새 물결

13.4 Edge·Distributed

• Cloudflare Workers, Fly.io, Deno Deploy
• D1/Turso·SQLite at the edge

13.5 크리에이터 도구

• Notion, Figma 이후 AI 네이티브 문서
• Cursor, Granola, Arc Search, Dia

14부. 체크리스트 12 · 안티패턴 10

✅ 체크리스트 12

1. 현재 단계(0→1 / 1→10 / 10→100)가 정의됐는가?
2. PMF 지표(Sean Ellis, retention)가 가시화되는가?
3. 기술 부채가 의식적이고 문서화됐는가?
4. 모노레포가 하나의 큰 덩어리가 되기 전 경계를 정의했는가?
5. MVP 스택(Next.js + Supabase + Vercel 등)을 선택하고 고수했는가?
6. 첫 엔지니어 채용이 신중한 인터뷰 과정을 거쳤는가?
7. Feature flag + 분석이 Day 1부터 있는가?
8. CEO/CTO 의사결정 병목을 점검했는가?
9. Weekly metrics review 관행이 있는가?
10. 30-60-90일 계획이 각 신입에게 있는가?
11. SOC2 준비는 PMF 이후에만 시작했는가(조기 투자 방지)?
12. IC vs EM 진로 대화가 시니어에게 있는가?

⚠️ 안티패턴 10

1. Pre-PMF에 마이크로서비스 도입
2. SOC2·GDPR을 MVP에 적용 (출하 3개월 지연)
3. 10명 때 K8s 클러스터 운영
4. 창업자가 코드 리뷰 독점
5. "아키텍처가 예뻐질 때까지" Rewrite
6. Founding Engineer에게 지분·계약 애매
7. PMF 전에 영업팀 채용
8. 분석 없이 "느낌"으로 피봇
9. 원격 vs 오피스 방침 매달 변경
10. 퍼포먼스 리뷰 없이 시니어 해고 → 법적 분쟁

다음 글 예고 — "엔지니어의 건강과 장기 지속: 번아웃·수면·운동·명상·재정·피로 회복" — 기술 커리어 40년을 뛰는 법

여기까지 기술·제품·조직·스타트업을 다 훑었다. 마지막 편(이자 시리즈의 인간적 마무리)은 그 모든 걸 지탱하는 몸과 정신이다.

• 번아웃 — 원인·단계·회복
• 수면 — 8시간이 엔지니어 IQ에 미치는 영향
• 운동 — 걷기·근력 운동·심폐
• 명상·집중 — Headspace·Apple·Calm·Waking Up
• 영양 — 카페인·알코올·혈당
• 자세·눈·손목 — RSI 예방
• 재정 자립 — 지분·옵션·FI 운동
• 사회 관계 — 고립 위험
• AI 시대 번아웃 — 항상 따라잡아야 한다는 압박
• 40세 이후의 엔지니어 — Staff·Principal·Founder 길

40년의 커리어는 지속 가능해야 하고, 그 지속의 기반은 사람이다. 다음 편에서 그 기반을 단단히 한다.