Systems thinkers, not specialists: 넷플릭스 CPTO가 말하는 AI 시대에 뽑는 사람과 일하는 방식
AI로 직군 경계가 흐려진 지금, 넷플릭스는 좁은 전문가보다 시스템 전체를 보는 사람을 더 뽑고, 공통 paved path와 guardrails로 AI 산출물의 품질을 지킵니다. 8주 도입안을 붙였습니다.
AI 덕분에 누구나 남의 일을 어느 정도 할 수 있게 되면서, 지금 조직은 역할이 뒤섞인 혼란기를 지나고 있습니다. 넷플릭스는 이 시기를 시스템 전체를 보는 사람, 모두가 함께 쓰는 공통 기반, 사람이 끝까지 지는 결과 책임으로 넘기려 합니다. 다른 회사가 따라 하려면 도구를 나눠 주는 것보다, 무엇이 정답 데이터이고 어디까지 혼자 배포해도 되는지부터 정해야 합니다.
요약
넷플릭스의 CPTO(Chief Product and Technology Officer, 제품·기술 총괄)로 엔지니어링, 제품, 디자인을 이끄는 엘리자베스 스톤(Elizabeth Stone)이 2026년 7월 Lenny’s Podcast에 두 번째로 나온 대화입니다. 스톤은 리프트(Lyft)의 과학 부문 VP, 경제 컨설턴트, 트레이더를 거쳤고, 약 2년 반 전 첫 출연 때보다 제품 조직까지 맡으며 역할이 넓어졌습니다. 그녀가 보는 지금의 모습은 이렇습니다. AI로 PM이 코드를 배포하고, 디자이너가 PRD(제품 요구 문서)를 쓰고, 엔지니어가 기획을 하게 되면서 누가 무엇을 책임지는지가 흐려졌습니다. 그녀는 이것을 새 기술이 들어올 때마다 거치는 혼란기(storming)로 보고, 역할이 다시 자리 잡는 시기(forming)가 그 뒤에 온다고 말합니다. AI를 되돌릴 생각은 없고, 이점은 살리면서 비용을 줄이는 것이 목표입니다.
그래서 넷플릭스가 더 찾는 사람은 좁은 분야의 전문가보다 여러 사업 영역을 가로질러 공통 구성 요소를 뽑아내는 systems thinker(시스템 전체를 보고 생각하는 사람)입니다. 팀마다 자기 기술 스택을 만들던 예전 방식 대신, 모두가 쓰는 공통 기반(paved path), 공유 guardrails(안전장치), 디자인 템플릿에 투자합니다. AI fluency(AI를 능숙하게 다루는 정도)는 직급별 요건을 새로 쓰지 않고, 모든 직급 위에 덧씌우는 기대치로 정했습니다. 이 모든 것을 받치는 것이 넷플릭스가 말하는 “excellence as an operating system”입니다. 뛰어난 사람을 모으고, 결정을 깊숙이 맡기고, 문제가 생겨도 절차를 덧붙이지 않는 문화입니다. 아래에서는 이 다섯 가지가 어떻게 작동하는지와, 다른 조직이 8주 동안 시험해 보는 방법을 정리합니다.
핵심 메커니즘
1. Storming before forming: 역할 혼란을 정리하는 네 가지 장치
무엇인가. AI 때문에 직군 경계가 흐려진 지금을 새 역할이 자리 잡기 전의 혼란기로 보고, 그 혼란에서 오는 비용을 줄이는 장치를 먼저 깔자는 관점입니다.
어떻게 작동하나. Stone은 네 가지를 듭니다. 첫째, 정답으로 쓸 데이터(source of truth)를 분명히 정해 둡니다. 둘째, 배포와 테스트에 guardrails를 둡니다. 셋째, AI가 만든 결과물을 검토하는 절차를 둡니다. 넷째, 코드를 에이전트가 짰든 분석을 사람이 했든 결과에 대한 책임은 사람에게 있다는 원칙을 다시 세웁니다. 그녀는 비개발자가 프로토타입을 만드는 것은 탐색에 좋지만, 모두가 운영 환경에 직접 배포해야 한다고 보지는 않습니다. 그리고 프로토타입이 중요한 사업 문제를 겨냥하고 엔지니어와 미리 맞춰져 있을 때만 의미가 있다고 덧붙입니다.
언제 쓰고 언제 안 쓰나. 생성형 AI 도구를 전사에 풀었는데 “누가 이걸 책임지냐”는 질문이 나오기 시작한 조직에 맞습니다. 아직 일부 팀만 실험하는 단계라면 네 장치를 한꺼번에 깔 필요는 없습니다.
작은 예시 (가상). 영업기획 담당자가 AI로 대시보드를 만들어 경영 회의에 올리기 전에, 지표가 데이터팀이 인증한 정의를 썼는지 자동으로 확인되고, 운영 시스템에 연결하려면 데이터 담당자의 승인을 받게 합니다.
2. Systems thinking: 한 단계 물러서서 전체를 보는 능력
무엇인가. 눈앞의 작업을 넘어 “내가 정말 풀고 있는 문제는 무엇이고, 이 일이 전체 안에서 어디에 놓이나”를 묻는 능력입니다. Stone은 이것을 지금 모든 직군에서 가장 찾는 능력으로 꼽습니다.
어떻게 작동하나. 그녀는 이 능력이 중요해진 이유를 네 가지로 설명합니다. 공통 플랫폼이 있으면 대부분 팀이 해법의 약 80%까지 바로 갈 수 있어 속도가 오릅니다. 넷플릭스가 동시에 벌이는 사업이 많아졌습니다. 비전문가까지 더 많은 종류의 일을 하게 되면서, 접근 권한, 보안, 품질 기준을 사람의 경험에 기대지 않고 시스템에 새겨 넣어야 합니다. 에이전트가 더 많은 일을 할수록 사람이 전체 시스템을 이해하고 방향을 잡아야 합니다. 기르는 방법으로는 “one click” 습관을 권합니다. 문제마다 한 단계만 물러서서 더 넓은 범위에 대해 무엇을 가정하고 있는지 묻는 것입니다. 너무 많이 물으면 일이 멈추므로 한 단계면 충분하다고 덧붙입니다. 상사처럼 생각해 보는 것, 곧 제품·기술·재무·콘텐츠를 함께 보는 연습도 같은 맥락입니다.
언제 쓰고 언제 안 쓰나. 여러 팀이 같은 고객과 같은 데이터를 건드리는 곳일수록 중요합니다. 인코딩이나 재생 시스템처럼 아는 사람이 극소수인 분야에서는 여전히 깊은 전문가가 필요하다고 Stone도 말합니다.
3. Paved paths와 공유 guardrails: 각자 만들던 것을 함께 쓰는 기반으로
무엇인가. 팀마다 따로 만들던 기술 스택과 화면 요소를, 모두가 그 위에서 일하는 공통 기반과 템플릿으로 바꾸는 투자입니다.
어떻게 작동하나. Stone은 넷플릭스가 그동안 팀별로 자기 스택을 만들어 성공했지만, 에이전트가 여러 시스템을 넘나드는 지금은 그 방식이 다음 단계로 데려가 주지 못한다고 봅니다. 그래서 세 방향으로 투자합니다. 인프라 팀은 공통 paved path와 공유 guardrails, 재사용 가능한 기능을 만듭니다. 디자인 팀은 비디자이너도 일관된 제품을 만들 수 있게 템플릿과 디자인 시스템을 만들어, 조각조각 이어 붙인 듯한 경험을 막습니다. 데이터 팀은 정답 데이터, 접근 규칙, 올바른 사용법을 시스템에 새겨 넣습니다.
언제 쓰고 언제 안 쓰나. AI로 만드는 사람이 늘어날수록 효과가 커집니다. 만드는 사람이 소수 전문가뿐인 조직이라면 공통 기반을 서둘러 만들 이유가 작습니다.
4. AI fluency overlay: 직급 사다리를 새로 쓰지 않고 덧씌우기
무엇인가. 직급별 기대 역량을 하나하나 고치는 대신, AI fluency를 모든 직급에 공통으로 덧씌운 기대치로 둔 방식입니다.
어떻게 작동하나. 넷플릭스는 AI fluency를 느슨하게 정의합니다. 실험하는 태도, AI가 도움이 되는 곳과 안 되는 곳을 구분하는 감각, 그리고 실제로 무언가를 만들어 본 경험입니다. AI를 쓰는 것 자체가 목표는 아닙니다. 코드를 매일 쓰지 않는 고위 리더까지 모든 직급과 직군에 적용하되, 어떻게 드러나는지는 직군과 경력 단계에 따라 다르고, 기술이 빨리 바뀌어 정의도 자주 바뀝니다. 채용 면접에서는 지원자가 AI를 어떻게 생각하는지, 어떤 도구를 쓰는지, 변화와 탐색에 얼마나 익숙한지를 묻고, 코딩 면접에서는 실제 일과 같게 AI 도구를 쓰게 합니다.
언제 쓰고 언제 안 쓰나. 기술이 몇 달마다 바뀌어 직급별 상세 요건을 고쳐 쓰는 속도가 따라가지 못할 때 맞습니다. 특정 도구 숙련도가 법적 자격처럼 필요한 직무라면 별도 요건을 두는 편이 낫습니다.
5. Excellence as an operating system: 절차 대신 사람과 결정 위임
무엇인가. 넷플릭스 문화의 바탕을, 뛰어난 사람에게 권한과 책임을 함께 주고 결정을 조직 깊숙이 맡기며 무거운 절차를 피하는 하나의 운영 체제로 보는 관점입니다. Stone은 예전 넷플릭스 컬처 덱에 있던 높은 자율성, talent density(뛰어난 인재의 밀도), 시장 최고 수준의 보상 같은 생각이 지금 프런티어 AI 연구소들이 스스로를 설명하는 방식과 닮았다고 말합니다.
어떻게 작동하나. 그녀가 드는 요소는 이렇습니다. talent density는 양보할 수 없는 조건입니다. 이것이 없으면 모든 층위의 결정을 믿을 수 없기 때문입니다. 실패를 피하려 하기보다 빨리 회복하는 쪽을 택합니다. 결정은 개인의 선호가 아니라 회원과 사업의 결과로 판단합니다. 리더는 중요하지 않은 결정을 자기가 다르게 했을 것 같아도 뒤집지 않고, 끝난 뒤 어땠는지 돌아보게 합니다. 실패하면 탓하지 않는 회고(blameless retro)를 하고 절차를 덧붙이지 않습니다. 그녀의 경험으로는 계획이나 직급 평가가 어려울 때 절차를 더해도 시간만 늘고 결과는 나아지지 않았습니다. 그래서 우선순위를 분명히 하고 실행할 수 있을 만큼만 절차를 두는 “high alignment, loose coupling”을 유지합니다.
이 문화의 상징인 keeper test(지금 이 사람을 뽑는다면, 또는 이 사람이 떠난다고 하면 붙잡으려 애쓸 것인가를 묻는 기준)에 대해 Stone은 대부분 긍정적인 대화라고 설명합니다. 팀원이 “제 keeper test는 어떤가요”라고 물으면 대개 “붙잡겠다”고 답하고 강점과 성장할 부분을 함께 이야기합니다. 물론 통과하지 못한다는 솔직한 답과 이정표를 주는 어려운 대화에도 쓰이며, 그녀는 이것을 리더가 어려운 피드백을 피하지 않게 하는 점검 장치로 봅니다.
통념과 다른 주장
흔히 이렇게 봅니다AI로 누구나 남의 일을 하게 되면 직군과 전문성의 경계는 결국 사라진다.
Stone은 이렇게 봅니다직군은 살아남는다. 모두가 여러 언어를 하게 됐을 뿐, 무엇이 좋은 결과인지 판단하는 전문성은 대체되지 않는다.
근거데이터를 믿어도 되는지는 데이터 과학자가, 풀 문제를 정하는 것은 PM이, 규모와 품질과 배포 위험은 엔지니어가 판단한다는 직군별 강점을 들고, 뛰어난 엔지니어링·데이터 과학·창작은 여전히 드물다고 말합니다.
흔히 이렇게 봅니다에이전트가 코드를 쓰는 시대에는 주니어를 뽑을 이유도, 기본기를 깊이 익힐 필요도 줄어든다.
Stone은 이렇게 봅니다기본기는 덜 중요해지지 않는다. 에이전트가 많이 써도 결과물의 품질 책임은 사람에게 있고, 넷플릭스는 오히려 인턴과 신입을 뽑기 시작했다.
근거넷플릭스는 예전에 경력자만 뽑았지만 몇 년 전부터 신입을 채용하고 있고, 젊은 직원이 새 방식에 더 익숙해 선배에게 가르치는 일도 기대한다고 설명합니다.
흔히 이렇게 봅니다일이 꼬이면 절차와 승인 단계를 더해 통제해야 한다.
Stone은 이렇게 봅니다절차를 더해도 결과는 나아지지 않고 시간만 는다. 뛰어난 사람에게 결정을 맡기고, 실패하면 탓하지 않고 돌아본다.
근거계획 수립과 직급 평가에서 절차를 더해 본 경험, 완벽하지 않을 것을 알고도 시작해 빠르게 배운 라이브 이벤트 사례를 듭니다.
저자가 든 사례
과거 실험과 연구를 바로 찾아 쓰기
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 넷플릭스에는 오랜 기간 쌓인 실험, 지표, 소비자 조사가 있음 | AI로 과거 학습을 요약·검색하고, 재무·콘텐츠·광고 담당자도 가설을 먼저 세워 데이터 과학자·엔지니어에게 가져옴 | Stone은 지난 조사를 거의 바로 찾게 됐다고 말함. 결과는 정답 데이터와 담당 데이터 과학자로 검증 | 메커니즘 1 (source of truth), 2 |
라이브 이벤트에 뛰어들기
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 넷플릭스가 라이브 콘텐츠라는 새 영역에 진입 | 완벽하지 않을 것을 예상하고 시작 | 빠르게 배우며 회복하는 방식으로 진행 (세부 수치는 원문에서 밝히지 않음) | 메커니즘 5 (빠른 회복) |
InterPositive 인수와 제작 현장의 AI
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 창작자마다 AI를 대하는 태도가 거부부터 적극 활용까지 다양 | 촬영 후 조명·구도·대사를 바꿀 수 있는 모델을 만든 InterPositive(벤 애플렉이 창업)를 인수, 사전 시각화·자막·더빙·예고편 제작에도 AI 활용 | 창작 결정은 감독이 쥐고 AI는 제작을 돕는 creator enablement 입장. Stone은 완전히 AI로 만든 작품을 관객이 그냥 받아들일 것이라는 생각에는 동의하지 않음 | 메커니즘 1 (사람의 결과 책임) |
공통 기반으로 방향 전환
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 팀별로 자기 스택을 만들던 방식으로 성장했지만, 에이전트가 여러 시스템을 넘나들게 됨 | 공통 paved path, 공유 guardrails, 재사용 기능, 디자인 템플릿에 투자하고 systems thinker를 더 채용 | 대부분 팀이 해법의 약 80%까지 바로 도달 | 메커니즘 2, 3 |
기술 디테일: guardrails와 공통 기반을 만들려면
Source of truth를 만들려면, 인증된 지표 목록부터 둡니다 (메커니즘 1). AI가 만든 분석이 서로 다른 숫자를 내는 가장 흔한 이유는 같은 지표를 다르게 계산하기 때문입니다. 지표마다 정의, 계산식, 원천 테이블, 담당자를 등록하고, AI 도구는 인증된 지표만 쓰게 합니다. 필드 이름은 설계 예시입니다.
{
"metric_id": "weekly_active_members",
"definition": "최근 7일 안에 1회 이상 재생한 유료 회원 수",
"sql_ref": "metrics/weekly_active_members.sql",
"source_tables": ["dw.playback_events", "dw.memberships"],
"owner": "team:data-core",
"certified": true,
"certified_at": "2026-09-30",
"allowed_dimensions": ["country", "plan", "device"]
}AI가 만든 리포트에는 쓴 지표의 metric_id가 자동으로 붙게 하고, 인증되지 않은 지표가 섞이면 “검증 필요” 표시를 달아 경영 회의 자료에 바로 쓰지 못하게 합니다.
과거 실험 검색을 붙이려면, 답마다 원본과 검증 상태를 함께 냅니다 (사례: 연구 검색). 실험 보고서와 조사 문서를 검색 대상으로 넣고, 답에는 근거 문서 링크, 실험 날짜, 그 결과를 데이터 과학자가 확인했는지(validated_by)를 함께 보여 줍니다. 2년이 넘은 실험 결과에는 “환경이 바뀌었을 수 있음” 표시를 붙입니다.
Guardrails를 두려면, 프로토타입과 운영 배포 사이에 승격 관문을 둡니다 (메커니즘 1, 3). 누구나 프로토타입은 만들 수 있게 하되, 프로토타입 환경은 가명 처리된 데이터와 읽기 전용 권한만 씁니다. 운영 환경으로 올리려면 아래 항목을 모두 통과해야 합니다.
{
"prototype_id": "proto-ads-pacing-v2",
"author_role": "product_manager",
"business_problem": "광고 집행 속도 편차 축소",
"engineering_partner": "user:lee.eng",
"checks": {
"uses_certified_metrics_only": true,
"tests_pass": true,
"security_review": "approved",
"access_scope": "read_only -> service_account:ads-pacing",
"owner_signoff": "user:lee.eng"
},
"ai_generated_share": 0.7,
"promote": true
}business_problem과 engineering_partner가 빈 프로토타입은 승격 대상에서 뺍니다. Stone이 말한 “중요한 사업 문제를 겨냥하고 엔지니어와 맞춘 프로토타입만 의미가 있다”를 관문으로 바꾼 것입니다.
AI가 만든 코드를 리뷰하려면, 사람이 서명하는 칸을 비워 두지 않습니다 (메커니즘 1). 변경 요청마다 AI가 쓴 비율을 기록하고, 비율이 높을수록 테스트 범위 기준을 올립니다(예: 50% 이상이면 변경된 함수마다 테스트 필수). 승인자는 “이 변경이 무엇을 바꾸는지 한 줄로 설명”을 남겨야 승인할 수 있게 합니다. Stone도 AI가 만든 코드는 따라 읽기 어렵다고 말했는데, 이 한 줄이 이해했다는 최소한의 증거가 됩니다.
디자인 템플릿을 공통 기반으로 만들려면, 토큰과 컴포넌트를 AI 도구에 먼저 물립니다 (메커니즘 3). 색, 글꼴, 간격 같은 디자인 토큰과 승인된 컴포넌트 목록을 AI 코딩 도구의 기본 지침으로 넣어, 비디자이너가 만든 화면도 처음부터 같은 부품을 쓰게 합니다. 새 컴포넌트가 필요하면 디자인 팀에 요청이 쌓이게 하고, 요청이 많은 순서로 템플릿을 늘립니다.
현업 실행 디테일: 누가, 언제, 무엇을
8주 동안 한 본부에서 시험합니다.
| 역할 | 누가 | 맡는 일 |
|---|---|---|
| 스폰서 | 본부장 또는 CTO | 범위 승인, 절차를 늘리지 않는다는 원칙 선언 |
| 데이터 오너 | 데이터팀 리드 | 인증 지표 목록, 접근 규칙 |
| 플랫폼 오너 | 개발 리드 1명 | 프로토타입 환경, 승격 관문, 리뷰 규칙 |
| 디자인 오너 | 디자인 리드 1명 | 토큰·컴포넌트를 AI 도구 지침으로 |
| 인사 | HR 파트너 | AI fluency overlay를 평가·면접에 반영 |
시작 전에 모을 것. 지난 3개월 동안 AI로 만들어진 산출물 목록(대시보드, 문서, 코드, 화면)과 그 산출물로 생긴 혼선 사례, 회의마다 숫자가 달랐던 지표 목록, 현재 직급별 평가표입니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1주 | AI 산출물과 혼선 사례를 모아 “누가 무엇을 책임지나”가 흐린 지점 정리 | 역할 혼선 지도 |
| 2~3주 | 회의마다 숫자가 달랐던 지표부터 20개를 인증 | 인증 지표 목록 |
| 3~5주 | 프로토타입 환경과 승격 관문, AI 코드 리뷰 규칙 | 관문 체크리스트, 리뷰 규칙 |
| 4~5주 | 디자인 토큰·컴포넌트를 AI 도구 지침에 연결 | 공통 지침 파일 |
| 5~6주 | 평가표에 AI fluency overlay 문장 3개 추가, 면접 질문 반영 | 개정 평가표 |
| 6~7주 | 팀 회고에서 one click 질문 연습 | 회고 기록 |
| 8주 | 지표 평가, 확대 결정 | 한 장 보고서 |
AI fluency overlay에 넣을 문장 (예시). 직급과 상관없이 모두에게 같은 세 문장을 기대치로 둡니다.
- 지난 분기에 AI로 직접 만들어 본 것과, 그중 버린 것과 이유를 말할 수 있다.
- 자기 업무에서 AI를 쓰지 않는 편이 나은 일 하나를 근거와 함께 말할 수 있다.
- AI가 만든 결과물에 대해 자신이 무엇을 확인했는지 설명할 수 있다.
확인할 질문.
- AI로 만든 산출물 중, 지금 누구 이름으로 책임이 걸려 있는지 모르는 것은 무엇인가?
- 회의에서 같은 지표가 다른 숫자로 나온 적이 있다면, 그 지표의 정답 정의는 누가 정하나?
- 비개발자가 만든 프로토타입 중 운영에 올라간 것이 있다면, 어떤 관문을 거쳤나?
- 최근 문제가 생겼을 때 절차를 하나 더했다면, 그 절차가 실제로 결과를 바꿨나?
진행 판정 기준 (예시). 경영 회의 자료에서 미인증 지표 사용이 0건이 되고, 승격 관문을 거치지 않은 운영 배포가 0건이며, 프로토타입에서 운영으로 가는 평균 기간이 시범 전보다 늘지 않으면 다른 본부로 넓힙니다. 관문 때문에 오히려 느려졌다면 체크 항목을 줄입니다.
AX 프로젝트에 쓸 때. 많은 기업이 생성형 AI 도구를 전사에 나눠 준 뒤 지금 Stone이 말한 혼란기에 있습니다. 이때 AX 프로젝트의 첫 산출물은 도구 교육이 아니라 공통 기반이어야 합니다. 온톨로지로 회사의 핵심 개념(고객, 제품, 계약, 지표)과 정답 정의를 정하면 그것이 source of truth가 되고, 그 위에 프로토타입 관문과 리뷰 규칙을 얹으면 누구나 만들되 아무나 배포하지 않는 구조가 됩니다. FDE는 첫 8주 동안 현업과 함께 인증 지표와 관문을 만들고, 경영진은 “문제가 생겨도 절차부터 늘리지 않는다”는 원칙을 먼저 약속해야 합니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 에피소드 | Lenny’s Podcast, 2026년 7월 19일, 약 72분. 진행 Lenny Rachitsky |
| 출연 | Elizabeth Stone, Netflix CPTO(엔지니어링·제품·디자인 총괄). 전 Lyft 과학 부문 VP, Nuna COO, Analysis Group 경제학자, Merrill Lynch 트레이더 |
| 핵심 주장 | AI로 역할이 뒤섞인 storming 시기, 좁은 전문가보다 systems thinker, AI fluency는 모든 직급의 기대치, excellence as an operating system |
| 더 뽑는 사람 | systems thinker, 공통 인프라 인력, 템플릿·디자인 시스템을 만드는 디자이너, 호기심과 모호함에 익숙한 사람 |
| 덜 뽑는 사람 | 아주 좁은 분야의 전문가(단, 인코딩·재생·스튜디오 제작 도구 같은 영역은 여전히 필요) |
| AI 활용 | 과거 실험·조사 검색, 비개발 부서의 가설 수립, 사전 시각화, 자막·더빙, 예고편·이미지 제작, InterPositive 인수 |
| 채용 | AI 사고방식과 도구를 묻는 면접, 코딩 면접에서 AI 도구 허용, 몇 년 전부터 신입 채용 |
| AI 이력 | 추천 개인화의 오랜 ML 활용, Netflix Prize(진행자에 따르면 상금 100만 달러), 시각효과·현지화의 ML |
| 문화 | talent density, 빠른 회복, selflessness, 결정 위임, blameless retro, 절차 덧붙이지 않기, high alignment·loose coupling, keeper test |
| 추천 도서 | Thinking in Systems, Into Thin Air, Liar’s Poker |
핵심 개념
- CPTO
- Chief Product and Technology Officer. 제품과 기술 조직을 함께 이끄는 임원.
- PRD
- Product Requirements Document. 무엇을 왜 만드는지 적은 제품 요구 문서.
- Paved path
- 회사가 공식으로 닦아 둔 개발·배포 경로. 이 길을 따르면 보안·품질 기준이 기본으로 지켜집니다.
- Keeper test
- 지금 이 사람을 뽑는다면, 또는 떠난다면 붙잡으려 애쓸지를 묻는 넷플릭스의 피드백 기준.
- Creator enablement
- AI를 쓰는 방식을 정해 주지 않고, 창작자가 원하는 만큼 쓰도록 돕는 넷플릭스의 입장.
- InterPositive
- 벤 애플렉이 세운 회사로, 촬영 뒤 조명·구도·대사를 바꿀 수 있는 모델을 만들었고 넷플릭스가 인수했습니다.
내 메모
TODO: 내 생각 추가
원문은 Lenny’s Podcast의 「Why Netflix is betting on systems thinkers, not specialists, in the AI era | Elizabeth Stone (CPTO)」입니다. 뉴스레터의 대본은 유료라, 공개된 에피소드 음성에서 만든 대본을 바탕으로 읽었습니다. 요약·메커니즘·사례는 Stone이 말한 내용을 AX Review가 다시 정리한 것이고, 기술·현업 실행 디테일, JSON 설계 예시, 8주 시범 일정, 평가표 문장, 인포그래픽, 표는 새로 작성했습니다. 대화 전체는 원문 영상에서 볼 수 있습니다.