엔지니어를 위한 제품 감각(Product Sense) 완전 가이드: 고객 공감·JTBD·North Star·AB Test·PMF·우선순위·로드맵까지 (2025~2026)

"Fall in love with the problem, not the solution." — Uri Levine (Waze 창업자)

엔지니어가 Staff+로 가는 길에서 가장 크게 막히는 구간: 제품 감각. 기술 실력으로 L4~L5 도달 후, L6 Staff로 가려면 "무엇을·왜 만들 것인가"의 판단이 필수다.

2024~2025년 AI 코드 생성으로 "어떻게 구현"의 가치는 상대적으로 떨어지고, "무엇을 왜" 판단의 가치가 올라갔다. 이 글은 엔지니어가 매일 쓸 수 있는 제품 감각 시스템을 만든다.

1. 제품 감각이란 무엇인가

1.1 정의

제품 감각 = 사용자의 필요·행동·맥락을 이해하고, 비즈니스 목표와 정렬된 제품 결정을 내리는 능력.

3가지 축:

Customer Empathy: 누가·왜·어떤 상황에서 쓰는가.
Problem Framing: 진짜 문제는 무엇인가.
Solution Judgment: 여러 해법 중 무엇을 왜 선택하는가.

1.2 기술 감각 vs. 제품 감각

기술 감각	제품 감각
어떻게 구현	무엇을 왜
코드 품질	사용자 경험
성능·확장성	Retention·Engagement
"옳은 설계"	"옳은 문제"
Framework·Pattern	User·Market

Staff+ = 두 감각의 통합. 한 쪽만 있는 엔지니어는 Senior에 머문다.

1.3 엔지니어가 제품 감각 얻으면 생기는 것

스펙 리뷰에서 진짜 질문을 함.
PM과 동등한 대화 가능.
기술 부채 논쟁에서 Trade-off 언어 사용.
로드맵 회의에서 우선순위 의견.
창업·사내 창업 가능.

2. Customer Empathy — 고객 공감의 3단계

2.1 Level 1 — Data-based Empathy

Google Analytics·Mixpanel·Amplitude 분석.
Cohort 유지율·Funnel 이탈.
누가 얼마나 오래 머무는가.

한계: 숫자는 "무엇"은 보여주지만 "왜"는 설명 못 함.

2.2 Level 2 — Observational Empathy

User Session Recording: Hotjar·FullStory로 실제 사용 녹화.
Support Ticket 분석: 반복되는 고통.
NPS·설문: 직접 물음.
Sales Call 녹음: Gong·Chorus 듣기.

한계: 사용자가 "말한 것"과 "진짜 원한 것"이 다를 수 있음.

2.3 Level 3 — Immersive Empathy

고객 방문: 그들의 사무실·집에서 실제 사용 관찰.
Dogfooding: 제품을 본인이 매일 사용.
고객 Shadowing: 하루 옆에 붙어 업무 관찰.
고객 역할 수행: PM·개발자 페르소나 제품이면, 직접 해봄.

예: Airbnb 창업자 3명이 한 달간 본인 제품만 써보며 "다시 예약하고 싶은 숙소"가 왜 드문지 발견 → 전문 사진 서비스 무료 도입 → 매출 2배.

2.4 엔지니어가 당장 시작할 수 있는 5가지

매월 고객 5명과 30분 통화. "지난주 언제 이 제품을 쓰셨죠?"
Support 채널 구독. Slack·Zendesk 알림.
자기 제품 매일 사용. Eat your own dog food.
Review 사이트 모니터링. G2·Capterra·Product Hunt·App Store 리뷰.
Sales Call 주 1회 듣기.

3. Jobs-to-be-Done (JTBD) — 문제 프레이밍의 혁명

3.1 Christensen의 "Milkshake Story"

맥도날드 밀크쉐이크 매출 증가 원인 조사:

인구통계적 세분화 실패.
고객 관찰: 오전 7시에 30~40대 남성이 출근길에 구매.
JTBD: "지루한 출근길을 달래고, 배고픔을 10시까지 버텨줄 간편한 것이 필요."
경쟁 상대: 바나나·베이글·커피 (다른 밀크쉐이크 아님).
해법: 아침 전용 진한 밀크쉐이크, 빨리 나오는 장치.

3.2 JTBD Framework

"사람은 제품을 사는 것이 아니라, 본인 삶의 어떤 Progress를 만들려고 제품을 Hire한다." — Christensen

Job Story 포맷:

When [situation], 
I want to [motivation], 
So I can [expected outcome].

예:

Bad: "고객은 모바일 앱을 원한다."
Good: "출장 중 공항 대기실에서, 빠르게 일정 확인하고 싶다, 회의 직전 준비되었음을 느끼려고."

3.3 Functional/Emotional/Social Jobs

Functional: 기능적 과제 (할 일 추적).
Emotional: 감정 (불안 감소·성취감).
Social: 사회적 (전문적으로 보이기).

예 — Tesla 구매:

Functional: A에서 B로 이동.
Emotional: 환경 죄책감 해소, 미래감.
Social: 환경 친화적 이미지, 얼리어답터 지위.

Functional만 보면 제품 설계 실패.

3.4 엔지니어를 위한 JTBD 실전

내가 만들고 있는 기능에 대해:

이 기능을 쓰는 사용자는 어떤 상황인가?
이 기능으로 어떤 Progress를 만들려 하는가?
Functional·Emotional·Social 각각 무엇인가?
같은 Progress를 주는 다른 해법은? (경쟁)
이 기능이 이 Progress를 정말로 만드는가?

이 5 질문만 해도 스펙의 50%를 개선할 수 있다.

4. North Star Metric — 모두가 동일 방향

4.1 North Star Metric의 정의

"The one metric that best captures the core value your product delivers to customers." — Sean Ellis

단 하나의 지표가 올라가면, 제품·회사가 성공하는 지표.

4.2 유명 NSM 예시

회사	North Star
Facebook	DAU
Airbnb	Nights Booked
Slack	Paid Teams with 2,000+ Messages
Spotify	Time Spent Listening
Zoom	Weekly Hosted Meetings
Duolingo	DAU with Lessons Completed
Stripe	Payment Volume Processed

공통점:

고객이 실제 가치를 경험하는 행동.
회사 매출과 상관.
측정 가능.
향상 가능.

4.3 NSM 안티패턴

Revenue 자체: 후행지표, 팀이 직접 못 움직임.
PV·클릭: 양적 증가 쉬우나 가치와 상관 없음 (Yahoo 시대의 실패).
여러 개: 4개 이상이면 북극성 아님.

4.4 엔지니어 실전 적용

기능 단위 NSM 설계:

팀이 만드는 기능의 NSM은 무엇인가?
이 기능이 본인 팀 NSM에 어떻게 기여하는가?
NSM을 올리지 못하는 기능은 왜 만드는가?

스펙 리뷰에서 "이 기능의 NSM 기여는?" 한 질문만 던져도 팀의 의사결정 수준이 달라진다.

5. Product-Market Fit (PMF) — 존재 여부와 단계

5.1 PMF의 정의

"Product-Market Fit means being in a good market with a product that can satisfy that market." — Marc Andreessen

PMF는 On/Off가 아니라 Spectrum이다.

5.2 Rahul Vohra의 PMF Survey

"만약 이 제품을 더 이상 쓸 수 없다면?"

Very Disappointed: ≥ 40%면 PMF.
< 40%: 아직 PMF 아님.

Superhuman은 이 방법으로 PMF 경로 설계.

5.3 PMF 4단계

Idea Fit: 아이디어가 실제 문제를 다루는가.
Problem Fit: 사용자가 그 문제를 실제로 느끼는가.
Solution Fit: 우리 해법이 그 문제를 푸는가.
Market Fit: 시장이 지불 의지가 있는가.

엔지니어가 자주 빠지는 함정: 3번에서 많은 시간을 쓰고 1·2번 검증 없이 달림.

5.4 PMF 이후 — Scale Fit

PMF 후도 성공 아님. Go-to-Market Fit·Channel Fit·Pricing Fit 각각 확보해야.

많은 Tech 스타트업이 PMF는 있는데 GTM이 없어 실패.

6. AB Test — 실험의 기술

6.1 AB Test가 실패하는 이유 (60% 이상)

Sample Size 부족: 통계적 유의성 안 됨.
단기 측정: 일주일 실험으로 장기 영향 못 봄.
Novelty Effect: 초기 효과를 지속 효과로 오해.
Metric 잘못: 대리 지표(Proxy)만 봄.
Segmentation 무시: 평균은 좋아도 일부 그룹은 망함.
외부 변수: 계절·이벤트·마케팅 변화.
Implementation 버그: A와 B가 의도대로 분리 안 됨.
Selection Bias: 그룹 할당이 무작위 아님.

6.2 제대로 된 AB Test 프로토콜

Hypothesis: "If X, then Y, because Z."
Sample Size 계산: Power Analysis로 사전.
기간: 최소 2주~1개월, 주간 Cycle 고려.
Primary Metric + Guardrail: 주 지표 + 나빠지면 안 될 지표.
Segmentation 계획: 사전에.
MDE (Minimum Detectable Effect): 감지하려는 최소 효과.
Analysis Plan 사전: 사후 p-hacking 방지.

6.3 Airbnb·Booking.com 사례

Booking.com: 동시 1,000개 실험 운영. 연 1,000개 중 90%는 NULL·Negative. 10%만 개선.
교훈: 실험 대부분은 실패한다. 실험 문화는 실패를 빠르게 발견하는 것.

6.4 엔지니어의 실험 Mindset

매 기능 전에 "실험으로 검증 가능한가?"
실패 실험을 학습으로 재프레이밍.
Confidence Interval 이해 (통계 기본 알기).
Launch = 실험 종료 아님, 지속 모니터링.

7. 우선순위 프레임워크

7.1 RICE 프레임워크

Reach: 얼마나 많은 사용자가.
Impact: 얼마나 큰 영향 (1·2·3점).
Confidence: 얼마나 확신 (0.5·0.8·1.0).
Effort: 얼마나 큰 노력 (Person-Month).

RICE Score = (R × I × C) / E.

7.2 Kano Model

사용자 관점 기능 분류:

Must-be (필수): 없으면 불만, 있어도 당연.
Performance (성능): 많을수록 만족.
Attractive (매력): 없어도 되지만, 있으면 놀람.
Indifferent: 신경 안 씀.
Reverse: 있으면 싫어함.

전략: Must-be는 확보, Attractive에 투자로 차별화.

7.3 ICE — 가벼운 버전

Impact, Confidence, Ease 각 10점.
Sum이 높은 것 먼저.

RICE보다 빠르고 회의에서 쓰기 좋음.

7.4 엔지니어가 우선순위 회의에서 기여하는 법

엔지니어만 볼 수 있는 비용: 기술 부채 누적·유지 비용.
엔지니어만 볼 수 있는 가치: Future Optionality·Platform 효과.
숫자로 내놓기: "이걸 지금 안 하면 6개월 후 X 리팩토링 Y주 필요."

8. Roadmap 설계 — 3개월·6개월·2년

8.1 Now / Next / Later 프레임

Now (Next 1~3 months): Commit, 구체적.
Next (3~6 months): 우선순위, 변동 가능.
Later (6+ months): 방향성, 유연.

8.2 Outcome-based Roadmap

Feature list 대신 Outcome + 실험으로:

Q1 Outcome: Free→Paid 전환율 10%→15%.
Experiments:
- Onboarding checklist 개선
- Paid Trial 친구 초대 인센티브
- Usage-based pricing 실험

장점: 특정 기능이 실패해도 Outcome 달성 집중.

8.3 Lean Roadmap (Opportunity Solution Tree)

Teresa Torres의 Continuous Discovery:

Outcome: 목표.
Opportunities: 문제·기회 3~5개.
Solutions: 각 기회당 2~3개 아이디어.
Experiments: 각 솔루션 검증.

Top-down 로드맵의 경직성을 해소.

8.4 2년 Vision + 90일 Tactical

2년 Vision: 바뀌지 않음, 팀 방향.
90일 Tactical: 3개월마다 Review·Adjust.
매월: Progress 체크.
매주: Blocker·Shift.

9. 엔지니어 + PM 관계 디자인

9.1 최악 vs. 최고 관계

최악	최고
PM이 Spec 던지고 엔지는 구현만	함께 Problem·Solution 탐색
마감만 보는 PM + "왜?"를 안 묻는 엔지	"왜"부터 같이 논의
PM이 기술을 모르는 척	PM도 기본 기술 이해
엔지가 유저를 모르는 척	엔지도 유저 공감

9.2 엔지니어가 PM과의 관계에서 투자해야 할 것

PM의 Why 이해: OKR·NSM 체화.
Customer Empathy 공유: Session·Ticket 같이 봄.
Tech Constraint 설명: PM이 이해할 언어로 Trade-off.
Proactive Proposal: "이거 어때요?" 먼저 제안.
Respect Product Thinking: "PM은 그냥 Spec 쓰는 사람" 편견 버리기.

9.3 PM 없는 팀의 엔지니어

스타트업·작은 팀에서 엔지니어가 PM 역할 겸:

Customer Call 직접 Lead.
OKR·로드맵 초안.
우선순위 결정권.
성과 측정.

이런 경험은 Staff+ or 창업으로 강력한 자산.

10. 제품 감각 학습 자료 Top 15

10.1 책

"Inspired" — Marty Cagan (제품 팀 원칙).
"The Lean Startup" — Eric Ries (실험 문화).
"Escaping the Build Trap" — Melissa Perri (Outcome).
"Competing Against Luck" — Clayton Christensen (JTBD).
"Hooked" — Nir Eyal (습관 설계).
"The Mom Test" — Rob Fitzpatrick (고객 인터뷰).
"Measure What Matters" — John Doerr (OKR).
"Trustworthy Online Controlled Experiments" — Kohavi.

10.2 블로그·Newsletter

Lenny's Newsletter.
First Round Review.
Reforge Blog.
Stratechery (Ben Thompson).

10.3 Podcast

Lenny's Podcast.
Acquired (Ben Gilbert, David Rosenthal).
This Week in Startups (Jason Calacanis).

11. 90일 제품 감각 스타터

11.1 Month 1 — Empathy Foundation

주 5명 고객 통화.
매일 자기 제품 사용.
Support 채널 매일 10분.
고객 Review 사이트 1주 1회.

11.2 Month 2 — Framing

JTBD 포맷으로 3개 기능 재작성.
NSM·Guardrail 팀과 논의.
Session Recording 주 1시간.

11.3 Month 3 — Judgment

RICE로 로드맵 재우선순위.
실험 1개 직접 설계.
90일 Outcome 문서 작성.

12. 제품 감각 체크리스트 12

13. 제품 감각 안티패턴 10

"엔지니어는 구현만": Staff+ 불가.
Feature 요청을 그대로 구현: JTBD·Opportunity 무시.
"안 팔리는 건 마케팅 탓": PMF 부재 인식 없음.
단기 지표만 쫓음: Retention·LTV 무시.
AB Test 결과 체리피킹: 원하는 결과만 골라 보기.
NSM 없이 일함: 방향 없이 기능 만들기.
고객 "말한 것" 그대로: Ford "더 빠른 말" 함정.
Feature Factory: 기능 수 = KPI.
"No Time for Discovery": 실행에 바빠 검증 안 함.
PM 적대시: 배울 기회 포기.

14. 마무리 — 제품 감각은 근육이다

"Good judgment comes from experience. Experience comes from bad judgment." — Mulla Nasrudin (추정)

제품 감각은 타고나지 않는다. 사용자와 보낸 시간의 함수다.

1주일 고객 통화 5회 × 10년 = 2,500회 통화. 이 경험이 당신을 다른 엔지니어로 만든다.

2026년 엔지니어에게 제품 감각은 Staff+로 가는 Tier-1 경로다. 기술 실력은 AI로 상쇄되지만, 사용자·시장·비즈니스 이해는 여전히 사람의 영역.

시작은 3가지면 된다:

이번 주 고객 1명과 30분 통화.
JTBD Job Story로 다음 PR description 작성.
본인 팀 NSM을 읽고 다음 스프린트 기여를 한 문장으로 정리.

3개월 후, 당신의 스펙 리뷰는 다른 품질이다.

다음 글 예고 — "엔지니어의 정치력: 조직·권력·의사결정·Alliance·Political Capital 설계까지"

제품 감각이 "무엇"이라면, 조직 정치력은 "어떻게 통과시키는가"다. 다음 글은:

권력(Power)의 정의 — Jeffrey Pfeffer "Power" 책
Political Capital의 축적과 지출
Alliance와 Stakeholder Mapping
갈등의 종류와 해소 — Lencioni 5 Dysfunctions
"Push vs Pull" 영향 전략
Good Politics vs. Bad Politics
Promotion·Reorg·예산 확보의 실전
엔지니어가 흔히 잊는 정치력 5가지

"정치는 더러운 것" 편견을 버리고, 선하고 효과적인 정치력을 설계한다. 다음 글에서 이어진다.