프로덕트 엔지니어링의 현대 — 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와의 차이

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년의 가장 뜨거운 실험실인 스타트업을, 다음 편에서 속속들이 본다.