PRODUCT × PEOPLE × AI
AI NativeProductTeam.
AI 시대에 제품팀은 어떻게 일하게 되는가
기획자·디자이너·개발자의 역할은 어디로 이동하는가
우리는 어떤 제품팀을 만들어야 하는가
AI Native
Product Team
Product Team
Context
Delegation
Verification
문제 정의 → 구현 → 검증
01 / SIGNALS
이미 변화하고 있는 팀들
Decagon
디자인 ↔ 구현
Nash
Build → Test
Retell AI
Prototype → Production
Figma
PM → Prototype
하나의 정답보다 사례에서 반복해서 나타나는 변화의 패턴
01 / CASE 01
디자인과 구현을 하나의 흐름으로
TRANSLATION LOOP
Figma 디자인
→
개발자의 재해석
→
구현
CONNECTED CONTEXT
Figma + MCP
→
Coding Agent
Storybook /
Production Component
→
실제 구현
디자인과 구현 사이의 경계가 점점 얇아짐
↗ Figma · Decagon 사례01 / CASE 02
문서보다 먼저 작동하는 것을 만든다
기존 방식
Define
→
Design
→
Build
→
Test
→
Ship
NASH
Define
→
Build
→
Test
→
Design
→
Ship
← 작동하는 소프트웨어로 가설 검증
구현 비용이 낮아지면서 Build 자체가 탐색의 도구
↗ Nash · Product Designer 채용 공고01 / CASE 03
Prototype → Production
React
Prototype
Cursor / Claude Code
→
사용자 테스트
실제 사용자에게 검증
→
Design System
Storybook / Component
→
Production
PR / 품질 검토
← 검증된 결과를 실제 제품으로 연결 →
Prototype과 Production의 경계가 가까워짐
↗ Retell AI · Design Engineer 채용 공고01 / CASE 04
PM도 직접 작동하는 것을 만든다
직렬 전달
PM
→
Designer
→
Engineer
아이디어를 문서로 설명
공동 탐색
Executable Artifact
Figma Make · Interactive Prototype
PMDesignerEngineer
모두가 함께 볼 수 있는 실제 동작을 중심으로 협업
↗ Figma · Prototypes are the new PRDs01 / PATTERNS
반복해서 나타나는 변화의 패턴
Working Software
문서보다 커지는 비중
직접 탐색
모든 직군의 실행 영역 확대
Prototype → Production
가까워지는 거리
문제 정의 → 구현 → 검증
직군 간 전달 과정 감소
← 더 짧아지는 Loop
02 / PROCESS
구현 비용이 낮아지면,
Build가 탐색의 방법이 된다
Build cost
↓
구현 자체가 사고와 탐색의 방법
문제 정의
→
구현
→
검증
가능성 A
가능성 B
가능성 C
← 여러 가지 가능성을 직접 만들어 비교
기획 → 디자인 → 개발의 고정된 직렬 프로세스 약화
02 / ROLES
그렇다면 역할은 사라지는가?
기획자
자신의 영역에서 AI 활용
디자이너
자신의 영역에서 AI 활용
개발자
자신의 영역에서 AI 활용
↓
각 직군 → AI에게 더 많은 실행 위임
기획자·디자이너가 개발자로 바뀌는 것이 아니라, 실행을 나누는 방식의 변화
02 / BUILDER
모두가 Builder가 된다
Builder
직접 만들어 검증할 수 있는 사람
직군 간 실행 영역의 겹침
각 직군의 전문성 유지
반복 실행 감소 → 전문성의 중요성 증가
모두가 직접 무언가를 만들어 검증할 수 있다
02 / DEFINITION
AI Native Product Team의 목적
AI에게
더 많은 일을
위임할 수 있는 팀
팀 전체의 생산성
더 빠르게 고객을 만나고
더 좋은 제품을 만들고
수익 · 비즈니스 임팩트
단순한 산출물의 양보다 고객과 비즈니스의 변화
02 / FRAMEWORK
AI Native Product Team을 결정하는 3가지 축
Context
AI가 제대로 일하기 위해
얼마나 많은 맥락을
제공할 수 있는가
Delegation
실제 업무를
AI에게 어디까지
위임할 수 있는가
Verification
AI의 결과를
얼마나 정확하고 빠르게
검증할 수 있는가
Context · Delegation · Verification
02 / CONTEXT
AI가 제대로 일할 수 있는 환경
목적 · 문제 · 고객 · 비즈니스
제품 · 도메인
Design System · Codebase · Docs
팀의 규칙 · 의사결정 기준
→
SHARED CONTEXT
AI가 사용할 수 있는 맥락
개인에게만 존재하던 암묵지
→ 팀과 AI가 활용하는 지식
02 / DELEGATION
얼마나 많은 일을 위임할 수 있는가
단순 작업
하나의 Task
하나의 Workflow
반복 업무 전체
더 큰 문제 해결
AI Native가 된다는 것은 위임의 범위를 계속 넓혀가는 과정
02 / VERIFICATION
더 많이 위임할수록, 더 강한 검증
좋은 결과의 기준
무엇이 충분히 좋은 결과인가
빠른 확인
결과를 얼마나 빨리 판단할 수 있는가
VERIFICATION
테스트
사용자 피드백
Design System
Eval
Verification이 없는 Delegation은 확장하기 어렵다
02 / RELATIONSHIP
Context + Verification
→ 더 많은 Delegation
Context
충분한 맥락
→ AI가 제대로 일할 조건
+
Verification
강한 검증
→ 결과를 신뢰할 조건
↓
더 많은 Delegation
팀의 AI 활용 수준 → 위임할 수 있는 업무의 범위
02 / HUMAN WORK
반복 실행을 넘어, 더 상위의 문제로
AI
반복적인 실행
더 많은 업무 수행
↑
사람은 더 상위의 문제로 이동
무엇을 해결해야 하는가
어떤 방향이 좋은가
무엇을 시스템화해야 하는가
무엇이 충분히 좋은 결과인가
어떤 결정을 내려야 하는가
03 / CONDITIONS
회사 시스템 × 개인 역량
회사의 시스템
AI가 사용할 수 있는 Context
Tool / Workflow / Infrastructure
권한과 프로세스
조직 구조와 협업 방식
×
개인의 역량
문제를 정의하는 능력
업무를 시스템화하는 능력
결과를 판단하는 능력
AI Native Product Team을 만드는 두 가지 조건
03 / GREENFIELD
이번에는 Greenfield에서 생각한다
GREENFIELD
처음부터 AI Native하게
회사를 설계한다면
현재 조직의 제약을 내려놓고
기존 프로세스·역할을 유지한다는 전제도 없이
회사 시스템에는 제약이 없다고 가정
가장 큰 제약은
개인의 역량
03 / CAPABILITY 01
① 문제 정의 능력
문제 · 목적
무엇을 만들어야 하는가
필요한 Context
어떤 맥락이 필요한가
모호한 요청
AI가 해결 가능한 문제로 구체화
→
문제 정의 능력
더 좋은 Context
03 / CAPABILITY 02
② 시스템화 능력
반복 패턴
반복되는 일 발견
→
구조화
같은 일을 직접 하지 않도록
→
시스템화
Workflow / Rule
Skill / Agent / Tool
← 자신의 일을 점점 AI에게 위임
시스템화 능력 → Delegation의 범위 확장
03 / CAPABILITY 03
③ 판단력
AI가 만든 여러 결과
좋은 결과의 기준
Trade-off 판단
선택 · 책임
판단력
무엇이 좋은
결과인지
판단하는 능력
Verification의 수준을 결정하는 역량
03 / CONNECTION
개인의 역량 → 팀의 AI Native 수준
| 개인의 역량 | 팀의 세 축 | |
|---|---|---|
| 문제 정의 능력 | 더 좋은 맥락 → | Context |
| 시스템화 능력 | 더 많은 위임 → | Delegation |
| 판단력 | 더 강한 검증 → | Verification |
개인의 역량이 올라갈수록 팀 전체의 AI Native 수준도 올라간다
04 / PM
기획자 → 문제와 비즈니스, 제품 의사결정
요구사항 문서 작성
산출물 생산 중심
↓
Prototype + AI
직접 여러 가능성 탐색
PRODUCT DECISION
Problem · Business
Priority · Trade-off
조직 Alignment
실제 고객과 현실에서의 검증
04 / DESIGNER
디자이너 → 경험의 판단과 품질 책임
AI와 함께하는 실행
더 많은 Solution 탐색
AI에게 생성 · 반복 수정 위임
Prototype으로 Experience 검증
Design System · 기존 작업물을 Context로 제공
사람에게 남는 핵심
Taste · Experience
무엇이 좋은 디자인인지에 대한 기준
최종적인 피니싱과 품질 책임
04 / ENGINEER
개발자 → 시스템과 Production
AI에게 위임
단순한 코드 생성
전달받은 요구사항의 반복 구현
더 상위 영역으로 이동하는 전문성
System · Domain
Architecture
Production
Reliability
AI가 지속적으로 개발할 수 있는 환경 설계
04 / OVERLAP
직군의 경계는 겹치지만 전문성은 더 깊어진다
PM
Designer
Engineer
함께 만드는 Prototype · 실제 동작 · 제품과 UX 의사결정
↓
Problem
Business
Product Decision
Problem
Business
Product Decision
↓
Taste
Experience
Design Quality
Taste
Experience
Design Quality
↓
System
Architecture
Reliability
System
Architecture
Reliability
실행 영역은 겹치고, 전문 영역의 판단은 더 깊어진다
04 / MOVING FRONTIER
AI는 사람의 영역을 계속 밀어 올린다
더 많은
Context
Context
더 많은
실행
실행
더 넓은
Delegation
Delegation
↑ 더 상위의 문제
↑ 더 어려운 판단
↑ 더 높은 수준의 기준
↑ 더 새로운 문제
05 / STARTING POINT
모든 팀의 출발선은 다르다
Coding Agent 활용부터
Context 정리부터
Verification 체계부터
이미 위임한 업무의 확장부터
우리 팀의 현재 위치에 따라 서로 다른 출발점과 전환 방법
05 / REFERENCE
Best Practice = Reference Point
우리 팀의 현재 위치
Reference Point
Decagon · Nash · Retell AI · Figma
Decagon · Nash · Retell AI · Figma
우리가 원하는 목표 상태
사례는 미래의 가능한 모습 · 목표 상태는 우리 팀이 직접 정의
05 / TEAM DESIGN
우리가 만들 AI Native Product Team은?
| 역할 | Context | Delegation | Verification |
|---|---|---|---|
| 기획자 | 어떤 맥락을 제공할 것인가 | 어떤 업무까지 위임할 것인가 | 어떻게 검증할 것인가 |
| 디자이너 | 어떤 맥락을 제공할 것인가 | 어떤 업무까지 위임할 것인가 | 어떻게 검증할 것인가 |
| 개발자 | 어떤 맥락을 제공할 것인가 | 어떤 업무까지 위임할 것인가 | 어떻게 검증할 것인가 |
각자가 직접 할 일과 위임할 일 · 우리 팀만의 운영 방식 설계
05 / OPERATING MODEL
Tool을 넘어, 팀의 운영 방식으로
AI와 사람이
일을 나누는 방식을
다시 설계한다
더 많은 Context
더 강한 Verification
더 많은 Delegation
더 강한 Verification
더 많은 Delegation
AI → 반복적인 실행
사람 → 문제 정의 · 시스템화 · 판단
팀 전체는 더 빠르게 고객과 수익을 향해 움직인다