필사 모드: 프로덕트 엔지니어링의 현대 — Shape Up·Dual Track·A/B·Feature Flag·RICE·OKR·JTBD·엔지니어-PM 협업·고객 인터뷰 심층 가이드 (2025)

Product Engineer — 2025년 엔지니어 직군의 분화

2015년까지 "Software Engineer"는 단일 직함이었다. 2020년 전후로 분화가 일어났다 — **Platform Engineer, ML Engineer, Data Engineer, Security Engineer, SRE, DevOps Engineer**. 그리고 2022~2023년 실리콘 밸리에서 "**Product Engineer**"가 전면에 등장했다. Anduril·Linear·Ramp·Stripe·Vercel의 채용 공고에서 이 단어가 최고 연봉 포지션이 됐다.

Product Engineer는 "기술만큼 제품을 아는 엔지니어"다.

- 지표를 본다 (activation, retention, conversion)

- 고객과 직접 대화한다

- A/B 실험을 설계하고 결과를 해석한다

- 디자인·PM과 대등하게 제안·반대한다

- 코드 완성도보다 **가치 전달 속도**를 더 중시한다

반면 전통 Software Engineer는 기술 수월성·시스템 설계·코드 품질에 집중. 둘 다 소중하지만, 2025년 **스타트업·고성장 기업에서 Product Engineer가 가장 귀한 자원**이다. 이 글은 Product Engineer가 되려는, 혹은 Product Engineer와 잘 협업하려는 모든 엔지니어를 위한 2025년 지형도다.

> 이 글은 **테스트**, **코드 리뷰**, **엔지니어링 글쓰기** 시리즈의 위층이다. 기술을 어떻게 잘 하느냐를 넘어 **"무엇을 잘 하느냐"**를 다룬다.

1부. Product Engineer의 정체성

1.1 전통 SWE와의 차이

| 축 | 전통 SWE | Product Engineer |

| --- | --- | --- |

| 1순위 | 시스템 정확성 | 사용자 결과(outcome) |

| 성공 지표 | SLO, 코드 품질 | activation·retention·conversion |

| 고객 접점 | 거의 없음 | 직접 인터뷰 |

| PM/디자인 | "요구를 받음" | 대등하게 제안·반대 |

| 빠름의 의미 | 빠른 배포 | 빠른 학습 |

| 실패 정의 | 버그 | 잘못된 걸 잘 만드는 것 |

1.2 누가 이 역할을 만드나

- Linear의 "Product Engineer" 채용 공고(2022)가 대중화 기점

- Stripe의 기존 "generalist engineer" 개념의 확장

- Ramp, Vercel, Cursor, Vanta 등 고성장 SaaS 표준 포지션

1.3 T자형 vs Pi자형

- T자형: 한 기술 깊이 + 넓은 도메인

- Pi자형: 두 깊이(예: 프런트엔드 + 프로덕트 감각)

- Product Engineer ≈ Pi자형 (기술 + 프로덕트)

1.4 AI 시대의 변화

- LLM이 boilerplate·CRUD 구현 가속

- 엔지니어의 레버리지가 **"무엇을 만들지"** 쪽으로 이동

- Product Engineer 비중이 구조적으로 증가

2부. JTBD (Jobs To Be Done)

2.1 핵심 아이디어

> "사람은 제품을 사는 게 아니라, **해야 할 일(Job)**에 제품을 고용한다."

- Clayton Christensen 밀크셰이크 이야기(2003)

- "아침 출근길에 무언가를 씹으며 1시간을 채우는 Job"을 밀크셰이크가 수행

- 경쟁 상품이 **다른 밀크셰이크가 아니라 바나나/커피**

2.2 Job Statement 템플릿

When [상황]

I want to [동기]

So I can [결과]

예: "When 새 동료가 온보딩할 때, I want to 우리 코드베이스의 구조를 빠르게 이해시킬 수 있기를, So I can 3일 안에 첫 PR을 낼 수 있게."

2.3 Product Engineer에게 의미

- "기능 요청 목록"을 Job으로 재구성 → 진짜 문제 발견

- 경쟁자 분석이 "같은 카테고리"가 아니라 "같은 Job"

- 우선순위 논쟁을 해소 — Job 수행 효과로 줄세우기

2.4 JTBD 한계

- Job이 너무 추상적이면 구체화 어려움

- "모든 것을 Job으로 설명"하려는 유혹

- 보완: JTBD + ODI(Outcome-Driven Innovation) + Opportunity Solution Tree

3부. Discovery와 Delivery — Dual Track Agile

3.1 전통 애자일의 한계

- 백로그에 요청이 쌓임 → 스프린트에서 구현 → 출하

- "구현 단계"만 애자일, **발견 단계가 없다**

- 결과: 잘못된 것을 빨리 출하

3.2 Dual Track

- **Discovery Track**: 문제·솔루션을 **지속적으로 탐색**

- **Delivery Track**: 탐색이 완료된 것을 구현

- 같은 팀이 두 트랙을 병행 (Jeff Patton, Marty Cagan 주장)

3.3 Opportunity Solution Tree (Teresa Torres)

Outcome: (사업 목표)

├── Opportunity A

│ ├── Solution A1

│ ├── Solution A2

│ └── Experiment: A2 효과 검증

├── Opportunity B

└── Opportunity C

- Outcome에서 아래로 분기

- "실험"이 잎 노드

3.4 Continuous Discovery 관행

- 주 1회 고객 인터뷰 (Marty Cagan "Empowered")

- Opportunity를 data로 평가

- Solution을 프로토타입으로 검증

4부. Shape Up (Basecamp, 2019)

4.1 Ryan Singer의 제안

- 스프린트 없음, **6주 사이클**

- **Appetite** — "이 문제에 얼마나 쓸 것인가" 결정

- **Pitch** — 해결안의 모양새를 문서로 형상화

- **Betting Table** — 사이클 시작 전 투자 결정

- **Breadboarding** — UI 아닌 구성요소·연결만 그리기

- **Cool-down** — 2주 여유 기간 (버그·리팩토링)

4.2 왜 일부 팀에서 인기인가

- 백로그 지옥 종료

- 엔지니어가 구체 설계를 **직접** 주도

- 완벽 계획이 아닌 **형상(shape)** 중심

4.3 한계

- 장기 로드맵이 필요한 B2B에 덜 맞음

- 6주 내 끝낼 수 없는 작업은 "부적격"

- 작은 팀(10~30명)에 가장 적합

4.4 혼합 사례

- Linear: Shape Up + Quarterly Planning

- Basecamp: 원형 그대로

- Ramp, Vanta: 변형

5부. 실험(Experimentation)의 현대

5.1 A/B 테스트의 왕좌

- Treatment vs Control을 무작위 배정

- "통계적으로 유의미한 차이"를 측정

- Booking.com, Airbnb, Netflix, Meta는 **연간 수만 실험**

5.2 플랫폼들

- **Statsig** — 2024 스타트업 최고 인기, free tier 관대, SQL 지원

- **LaunchDarkly** — Feature Flag 원조, 실험으로 확장

- **Optimizely** — 엔터프라이즈, 웹 A/B 강자

- **GrowthBook** (OSS) — 셀프 호스트 대안

- **Eppo** — 데이터웨어하우스 네이티브

- **Posthog** — 제품 분석 + 실험 통합

- **Amplitude Experiment** — Amplitude 유저에게 자연

- **AB Tasty** — 유럽 강세

5.3 통계 기초 — MDE, Power, Significance

- **MDE (Minimum Detectable Effect)**: "이 실험으로 볼 수 있는 최소 효과 크기"

- **Power (1-β)**: 실제 효과가 있을 때 감지할 확률 (보통 80%)

- **Significance (α)**: 차이가 없는데 있다고 할 오류 확률 (보통 5%)

- 샘플 크기 계산: `16 * σ² / MDE²` 근사

5.4 p-hacking의 함정

- "유의미할 때까지" 기다리기 → p값 자연스럽게 0.05 아래로 내려감

- 해결: 사전 결정한 종료 조건, Sequential Testing

5.5 Sequential Testing

- CUPED (Microsoft), mSPRT (Optimizely), Group Sequential

- "빨리 끝내도 안전한" 통계 방법

- Always-valid p-values (Evan Miller, Ramesh Johari)

5.6 Metric 선택

- **Primary Metric** — 성공/실패 판단

- **Guardrail Metric** — 다른 지표 망치지 않았나

- **Secondary Metric** — 이해를 돕는 보조

- **Leading Indicator** vs Lagging Indicator

5.7 실험이 실패하는 이유

- SRM (Sample Ratio Mismatch) — 배정 불균형

- Novelty effect — 초기 호기심만

- Network effect — treatment가 control에 영향

- Interaction effect — 동시 실험 간섭

6부. Feature Flag — 배포와 릴리스 분리

6.1 왜 필요한가

- 배포(deploy) ≠ 릴리스(release)

- Canary·Progressive rollout

- 빠른 Kill Switch

- A/B 실험의 기반

6.2 Flag 유형

- **Release Flag** — 미완성 기능 숨김

- **Experiment Flag** — A/B 테스트

- **Ops Flag** — 인프라 토글(rate limit, DB region)

- **Permission Flag** — 기업/요금제별 기능

6.3 운영 패턴

- **naming**: `feature.payments.new_checkout_v2`

- **ownership**: 각 flag에 소유팀 명시

- **TTL**: 장기 flag는 정리 의식 (6개월)

- **Evaluation reason**: "왜 이 유저가 이 variant 받았나"를 로깅

6.4 Flag Debt

- 프로덕션에 1,000개 flag가 쌓여 지옥

- Linear·Ramp는 "flag expiration" 강제: 90일 뒤 PR 자동 생성 "flag 정리"

- Statsig/LaunchDarkly도 stale flag 대시보드

6.5 Local Override·Dev Mode

- 개발자가 자기 요청만 variant 강제 전환

- QA가 특정 유저로 검증

- 프로덕션 진단에도 활용

7부. RICE·ICE·WSJF — 우선순위의 수학

7.1 RICE (Intercom)

Score = (Reach × Impact × Confidence) / Effort

- **Reach**: 영향받는 유저 수/기간

- **Impact**: 유저당 크기 (3/2/1/0.5/0.25)

- **Confidence**: 추정 확신도 (100%/80%/50%)

- **Effort**: 인력·주 단위

7.2 ICE (Sean Ellis)

Score = Impact × Confidence × Ease

- 더 단순, 스프린트 수준 결정에 적합

7.3 WSJF (SAFe)

WSJF = Cost of Delay / Job Size

- Cost of Delay = User value + Time criticality + Risk reduction

- 엔터프라이즈 SAFe 환경에서 흔함

7.4 MoSCoW

- Must / Should / Could / Won't

- 릴리스 범위 결정에 유용

7.5 Kano 모델

- Must-be / Performance / Delighter

- Delighter가 너무 많으면 핵심 결함 은폐

7.6 실전

- 한 프레임워크만 고집 금지

- 숫자에 맹신 금지 — "왜 점수가 이렇게 나왔나" 대화 촉발이 진짜 가치

- 3~5개 옵션 비교에 적합, 100개 비교 시 무의미

8부. OKR — 목표와 핵심 결과

8.1 구조

- **Objective**: 정성적 야심 목표

- **Key Result**: 정량 측정 가능 (3~5개)

- **Initiative**: KR 달성 위한 프로젝트

8.2 Input vs Output vs Outcome

- Input: 우리가 하는 일 (feature 수)

- Output: 즉각 산출물 (PR, 배포)

- **Outcome**: 사용자·사업 변화 (retention, revenue)

- 좋은 KR = Outcome 위주

8.3 흔한 실수

- KR을 task로 씀 ("feature X 출시")

- 너무 많음 (분기 7개 KR → 초점 상실)

- Top-down 강제, 팀이 소유감 없음

- 월별 review 없이 분기 끝에만

8.4 대안·보완

- **North Star Metric** (Sean Ellis) — 하나의 핵심 지표

- **Balanced Scorecard**

- **Pirate Metrics (AARRR)** — Acquisition, Activation, Retention, Referral, Revenue

8.5 OKR이 엔지니어 일상에 침투하는 법

- Sprint·Cycle 단위 Initiative가 KR에 연결됐는가

- Standup에서 KR 진행 공유

- 엔지니어가 KR 정의에 참여 (top-down 피하기)

9부. 엔지니어-PM 협업 모델

9.1 Triad Model

- **Engineer + Designer + PM** 3각 협력

- 각자 전문성 + 공동 오너십

- Shopify·Gojek·Spotify Squad 원형

9.2 Spotify Squad·Tribe·Chapter·Guild (2012)

- Squad: 미션 중심 작은 팀

- Tribe: 관련 Squad 묶음

- Chapter: 같은 전문성 수평 조직

- Guild: 자발적 관심 그룹

- **현실**: Spotify조차 원형 그대로는 안 씀 — 참고 모델

9.3 Linear 접근

- 엔지니어가 PM 역할 상당 부분 수행

- 이슈가 **생각 + 결정 + 구현**을 한 번에

- 작은 팀·시니어 밀도가 가능케 함

9.4 Stripe의 "Working Backward"

- 내부 PR/FAQ 문서를 먼저

- 고객 입장 가상 발표를 상상

- Amazon의 Working Backward 이식

9.5 GitLab의 공개 매니페스트

- 모든 문서 공개, 비동기 기본

- "Handbook first" — 정책을 먼저 문서화 후 실행

- 원격 팀 모델의 대표

9.6 공통 패턴

- **원 팀 원 백로그** (PM/엔지니어 별도 백로그 금지)

- **측정 가능한 성공 기준** 공유

- **문제 공유 + 해결 자율**

10부. 엔지니어가 고객 인터뷰하는 법

10.1 왜 직접?

- PM 요약본은 **맥락의 90% 손실**

- 엔지니어가 보면 "이거 기술적으로 다르게 풀 수 있다" 인사이트

- 공감대 형성 — 팀 전체 제품 감각 상승

10.2 "Mom Test" 원칙 (Rob Fitzpatrick)

- 미래 얘기 금지 ("쓰시겠어요?")

- 과거 행동을 질문 ("지난번에 이 문제 어떻게 해결했어요?")

- 의견 금지, 사실 수집

- 가설을 말하지 말고 **상대가 말하게**

10.3 인터뷰 준비

- 타겟 5~10명

- 30분 구조: 워밍업 5 + 핵심 20 + 마무리 5

- 녹음 허락 + Fireflies/Grain/Otter 전사

- 구조화 노트 → Airtable/Notion 집계

10.4 인사이트 추출

- 3~5명 인터뷰 후 **주제 분석 (Thematic Analysis)**

- "같은 고통을 3명 이상이 말하면" 신호

- **Opportunity Solution Tree**에 반영

10.5 엔지니어가 조심할 것

- 해결책 설명 충동 억제

- 기술 용어 전혀 쓰지 않기

- 침묵을 견디기 (상대가 말할 시간)

11부. PoC → Prototype → Production 파이프라인

11.1 단계

- **PoC (Proof of Concept)**: "이게 기술적으로 가능한가"

- **Prototype**: "이게 사용자에게 먹히는가" (UX 중심, 엔지니어링 가벼움)

- **MVP (Minimum Viable Product)**: "돈을 벌 수 있는 최소"

- **Production**: 스케일·신뢰성·규모화

11.2 각 단계의 성공 기준

- PoC: 비디오·GIF로 1분 시연 가능

- Prototype: 5명 고객이 "사겠다" (혹은 wait list 가입)

- MVP: 실제 매출 1달러

- Production: SLO·관측·보안 준수

11.3 버려야 할 것

- PoC의 코드를 그대로 production에 (기술 부채 폭발)

- Prototype을 공식 출시 (보안/규제 사고)

- MVP 이후 "더 많은 기능"만 추가 (Retention 개선 누락)

11.4 AI 시대 가속

- LLM으로 Prototype을 하루에

- Cursor/Replit/v0으로 UI 프로토타입 30분

- 기술이 아니라 **발견 속도**가 경쟁 우위

12부. No-code·Low-code와 엔지니어 가치

12.1 No-code 붐 (2020~)

- Airtable, Notion, Webflow, Retool, Zapier, Make(구 Integromat)

- 내부 도구의 80%가 non-engineer에 의해 만들어지는 기업 등장

12.2 엔지니어가 잃는 것과 얻는 것

- 잃는 것: 단순 CRUD·내부 대시보드 수요

- 얻는 것: **고가치 영역 집중** (독창 기술, 규모화, AI/ML)

12.3 엔지니어의 새 역할

- Low-code 도구의 한계 해결 (custom block, API 확장)

- 생산성 도구 플랫폼화 (Retool + 내부 GraphQL)

- 비엔지니어가 만든 프로토타입을 **production 이식**

12.4 Cursor·Claude Code 시대

- 엔지니어 스스로가 "AI + 사람" 하이브리드

- **프로덕트 감각 있는 엔지니어**의 생산성은 10배

- 감각 없는 엔지니어 = 쓸모없는 코드 10배

13부. Product Engineer로 성장하는 법

13.1 매일

- 지표 대시보드 1분 (활성 유저, 에러율, NPS)

- 사용자 피드백 채널 훑기 (Slack, Intercom, Zendesk)

13.2 매주

- PM과 1on1 또는 동기 싱크

- 한 달 로드맵 재확인

- 한 실험 결과 리뷰

13.3 매월

- 고객 인터뷰 1~2건

- 경쟁 제품 체험

- 개인 노트에 "이 주에 배운 프로덕트 교훈"

13.4 학습 자료

- 책: Inspired (Marty Cagan), Hooked (Nir Eyal), The Mom Test (Rob Fitzpatrick), Shape Up (Ryan Singer), Escaping the Build Trap (Melissa Perri)

- 블로그: Lenny's Newsletter, Reforge, Product Hunt stories

- 사례: Stripe Press, First Round Review

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

✅ 체크리스트 12

1. 팀이 **Outcome 지표**(activation/retention 등)로 평가되는가?

2. **JTBD** 또는 유사한 문제 프레임워크로 로드맵을 구성하는가?

3. **Dual Track**으로 Discovery가 지속적으로 일어나는가?

4. **A/B 실험 플랫폼**이 있어 2주 내 실험 돌릴 수 있는가?

5. **Feature Flag**가 모든 신기능에 기본 적용되는가?

6. **MDE·Power·SRM**을 실험 설계 시 점검하는가?

7. **Guardrail metric**이 실험에 필수 포함되는가?

8. **RICE/ICE** 등으로 우선순위가 수치화되는가?

9. **OKR**이 Output이 아니라 **Outcome**으로 쓰이는가?

10. 엔지니어가 분기 1회 이상 **고객 인터뷰**에 직접 참여하는가?

11. **PoC / Prototype / Production** 단계가 명확히 구분되는가?

12. Flag·실험 **Debt**가 분기 정리되는가?

⚠️ 안티패턴 10

1. PM이 요구사항 던짐 → 엔지니어는 기계적 구현

2. 지표 없이 "느낌상 좋은 것" 출하

3. 실험 없이 전면 롤아웃

4. Feature Flag 없이 "hotfix" 반복

5. p-hacking (유의미할 때까지 기다림)

6. Novelty effect 무시 (1주 데이터로 결론)

7. SRM 체크 안 함

8. OKR이 task 목록

9. 고객과 한 번도 대화해보지 않은 엔지니어

10. No-code 도구로 PoC → production에 그대로 노출

다음 글 예고 — "스타트업 엔지니어링: 0→1 빌드·기술 부채·피봇·엔지니어 채용·급성장기 스케일" — 스타트업의 현실

프로덕트 엔지니어링 다음은 더 큰 캔버스 — **스타트업**이라는 환경 자체. 다음 글은 스타트업에서 엔지니어가 살아남고 승리하는 법.

- **0→1 vs 1→10 vs 10→100** 엔지니어링의 다른 법칙

- **PMF (Product-Market Fit)** 찾기 전과 후

- **기술 부채의 전략적 활용**

- **스타트업 기술 스택** 선택 (Next.js·Supabase·Vercel·Railway·PlanetScale)

- **창업 첫 18개월의 엔지니어링**

- **피봇할 때 코드는 어떻게 되나**

- **엔지니어 1호 채용** vs **100호 채용**

- **YC·Series A·Series B 스케일 고통**

- **버즈펜즈(Scaling Pains)**: DB, 조직, 문화

- **Engineering Manager 전환** 타이밍

- **Founding Engineer vs Early Employee**

2025년의 가장 뜨거운 실험실인 스타트업을, 다음 편에서 속속들이 본다.