Reddit Proto: UX·제품 조직 전원이 쓰는 Reddit의 사내 AI 프로토타이핑 도구
Reddit은 디자이너와 PM이 Git 없이 실제 디자인 시스템과 자기 계정 데이터로 프로토타입을 만드는 사내 도구 Reddit Proto를 만들었습니다. UX·제품 조직 150명 이상이 모두 쓰고 프로토타입은 약 700개입니다. 주석·PRD 필드, 8주 도입 일정을 붙였습니다.
Reddit은 디자이너와 PM이 Git을 몰라도 실제 디자인 시스템과 자기 계정 데이터로 돌아가는 프로토타입을 몇 분 만에 만들게 했고, UX·제품 조직 전원이 이 도구를 씁니다. 옮기려면 도구보다 디자인 시스템과 실제 코드를 잇는 지도, 그리고 사람이 PRD를 확인하는 관문을 먼저 갖춰야 합니다.
요약
Lenny’s Newsletter의 팟캐스트 How I AI에서 진행자 Claire Vo는 2026년 10월 26일 Reddit의 수석 UX 엔지니어(principal UX engineer) Blair Metcalf와 대담했습니다. 주제는 Blair가 만든 Reddit Proto입니다. 에피소드 소개는 이 도구를 사내 vibe-coding harness(말로 시켜 AI가 코드를 짜게 하되 회사 규칙 안에서 돌게 하는 틀)라고 부릅니다. 디자이너나 PM이 데스크톱 launchpad(출발 화면)에서 프로젝트 이름을 넣으면 앱이 저장소를 복제하고 출발점을 잡아 줍니다. 작업은 Cursor 같은 AI 코드 편집기에서 이어집니다. 편집기 뒤에는 Reddit 디자인 시스템을 실제 코드에 연결한 사내 MCP(Model Context Protocol, AI 도구가 외부 지식과 기능을 불러 쓰는 표준 연결 방식)가 붙어 있습니다. 완성된 프로토타입은 사내 배포 환경에 올라가 URL 하나로 리더에게 공유됩니다.
녹화 시점에 대시보드에는 프로토타입이 약 700개 있었고, Blair는 UX·제품 조직 150명 이상이 모두 쓴다고 밝혔습니다. 디자인과 제품 인력은 거의 반반입니다. Blair가 꼽는 효과는 리뷰 자리에서 곧바로 합의가 난다는 점입니다. 실제 컴포넌트와 리뷰어 본인의 데이터가 화면에 뜨니 가짜 데이터 탓에 생기던 곁가지 반론이 줄었다고 합니다. 측정한 리드타임이 아니라 Blair가 체감한 효과입니다. Reddit은 같은 틀을 프로덕션 쪽으로도 넓히는 중입니다. 고해상도 Figma 화면을 feature capsule(디자인 한 장을 구현 단위로 묶은 꾸러미)로 만들어 PRD를 뽑고, 사람이 확인한 뒤 draft PR(병합 전 검토용 코드 변경 요청)까지 생성합니다. 아래에서는 여섯 가지 작동 방식, 통념과 다른 주장, 사례를 차례로 보고 우리 조직에 옮길 기술·현업 디테일을 붙였습니다.
핵심 메커니즘
Launchpad와 scaffold: Git은 숨기고 제품 판단 손잡이만 남기기
디자이너와 PM이 개발 환경을 몰라도 프로토타입을 시작하게 해 주는 데스크톱 앱과 공통 뼈대(scaffold)입니다. 프로젝트 이름을 넣으면 앱이 저장소를 복제하고 브랜치와 설정을 대신 처리합니다. scaffold에는 Reddit 디자인 시스템, 컴포넌트, UX 패턴, 기능 예시가 들어 있고 플랫폼 팀이 한곳에서 관리합니다. 화면에는 제품 가설을 시험하는 손잡이만 남깁니다. 기능 켜기·끄기, 기기와 테마 전환, 모더레이터 같은 사용자 상태, 화면 이동 허용·막기, mock 데이터와 로그인 데이터 전환입니다. 화면 이동을 막아 두면 리뷰어가 지금 판단할 화면에만 집중합니다. 에피소드 정리 글은 이 원칙을 selective simplicity(골라서 단순하게)라고 부릅니다. 이 방식은 같은 디자인 시스템 위에서 여러 팀이 화면을 만드는 조직에 맞습니다. 디자인 시스템이 없거나 제품마다 따로 놀면 scaffold에 넣을 공통 부품이 부족합니다. 가상 예시를 들면 보험사 앱 팀 PM이 launchpad에서 ‘청구 진행 알림’을 만들고, 우수 고객 상태로 바꿔 보며 화면 차이를 확인합니다.
Signed-in 데이터: 리뷰어 본인의 계정으로 보는 프로토타입
프로토타입에 로그인하면 리뷰어 자신의 Reddit 피드, 검색, 커뮤니티가 그대로 뜨게 하는 방식입니다. 데이터 출처를 mock과 signed-in 중에서 고를 수 있습니다. 대담의 검색 시연에서는 실제 데이터를 가져와 LLM에 넘기고 순위를 매겼습니다. ‘How I AI’를 검색하자 팟캐스트로 알아봤습니다. 어떤 모델을 썼는지는 대담에서 밝히지 않았습니다. 이렇게 하는 이유는 제품 성격에 있습니다. Reddit은 사람마다 화면이 다른 개인화 제품입니다. mock 데이터는 겉보기엔 깔끔해도 리뷰어에게 남의 화면처럼 느껴집니다. 정리 글은 이 방식이 사내에서 개인정보 통제 아래 돌아가는 것이고 제한 없는 프로덕션 접근을 권하는 뜻은 아니라고 덧붙입니다. 개인화가 강한 피드·추천·검색 화면에 효과가 큽니다. 모두에게 같은 화면이 보이는 설정 페이지라면 mock으로도 충분합니다.
Contextual annotation: 화면 주석에 코드 맥락을 붙여 Cursor로 보내기
프로토타입 화면 위에 남긴 짧은 메모를 AI가 정확히 고칠 수 있는 요청으로 바꾸는 기능입니다. 사용자가 요소를 고르고 메모를 답니다. 시연에서 Blair는 검색 typeahead(입력 중 뜨는 추천 목록)에 인기 커뮤니티와 최근 방문 커뮤니티를 넣으라고 적고, 로그인 데이터와 실제 typeahead를 쓰라는 방향도 덧붙였습니다. 주석마다 코드 위치, 대상 요소, 요청한 변경, 전체 방향이 함께 묶입니다. 이어 Cursor에 ‘Apply annotations’라고 지시하면 묶음이 통째로 넘어갑니다. 요소 하나를 골라 글꼴을 기울이는 간단한 수정도 같은 길로 처리합니다. 이 방식은 화면이 대부분 맞고 몇 군데만 손볼 때 효과가 큽니다. 화면 구조를 처음부터 바꿀 때는 주석보다 새 프롬프트가 낫습니다.
Design-system map과 Proto MCP Ultra: AI가 어떤 부품을 어디에 쓸지 아는 근거
Reddit의 디자인 언어 RPL(Reddit Product Language)의 토큰(색·간격 같은 디자인 값), 컴포넌트, 서피스, 사용자 여정을 실제 코드와 짝지어 둔 지도입니다. 사내 MCP인 Proto MCP Ultra가 이 지도를 읽습니다. 팀은 Reddit Proto의 디자인 시스템에서 출발해 프로덕션 코드를 읽고 둘을 맞췄습니다. Figma의 Code Connect(디자인 컴포넌트와 코드 컴포넌트를 잇는 기능)도 이 연결에 썼습니다. 지도에서 토큰 하나는 Figma, iOS, 프로덕션 GitHub, 프로토타이핑 GitHub의 값으로 이어집니다. Cursor가 화면을 만들 때 MCP가 지도에서 맞는 토큰, 컴포넌트, 예시 코드를 찾아 줍니다. 처음부터 맞지는 않았습니다. 시도하고 실패하고 엔지니어 피드백으로 다듬기를 되풀이했습니다. harness 안에 정확히 무엇이 들어 있느냐는 질문이 계속 나와서 지도를 눈으로 볼 수 있게 만들었습니다. 같은 토큰의 실제 값이 플랫폼마다 다른 곳도 지도에서 드러납니다. AI가 만든 화면을 프로덕션 모양에 가깝게 만들고 싶을 때 가장 먼저 투자할 곳입니다.
Feature capsule: Figma 화면 한 장을 PRD와 draft PR로 넘기기
고해상도 Figma 프레임 하나를 구현 단위로 묶어 엔지니어링에 넘기는 흐름입니다. Blair는 프로덕션 인계를 가장 큰 퍼즐 조각이라고 표현했습니다. 사용자가 Figma 위치를 launchpad에 붙여 capsule을 만듭니다. Figma MCP가 고른 프레임과 컴포넌트를 분석하고, Reddit 시스템이 지도와 과거 CI 리뷰·엔지니어 피드백을 참고해 알려진 프로덕션 컴포넌트에 매핑합니다. 그다음 사용자 목표, 인수 기준(acceptance criteria), 작업 세부, Figma 링크가 담긴 PRD가 나옵니다. 사람이 해석이 맞는지 확인해 수락하면 PRD가 로컬에 저장되고 Cursor로 넘어갑니다. 코드는 프로덕션을 깨끗하게 지키려고 sibling repository(본 저장소 옆에 둔 별도 저장소)에 쓰입니다. 결과물은 draft PR이고 병합 여부는 엔지니어 리뷰가 정합니다. 이 흐름은 화면이 확정된 고해상도 UI에 맞습니다. 팀은 기능 아이디어 전체를 한꺼번에 넣는 방식을 먼저 시도했다가 고해상도 UI로 범위를 좁혔습니다.
사내 배포와 발견: 700개를 찾을 수 있게 만들기
만든 프로토타입을 사내에서 바로 띄우고 공유하고 찾게 하는 기반입니다. 배포는 Kubernetes 위에서 돌고, Blair는 이를 “basically like an internal Vercel”이라고 설명했습니다. 보안 관문이 있는 공유 링크를 Slack 등으로 돌리고, 휴대폰에는 PWA(앱처럼 설치하는 웹)로 깔아 볼 수 있습니다. 프로토타입은 사내에서 기본 공개이고 비공개 프로젝트는 앞으로 더할 기능입니다. 리더는 동작하는 프로토타입을 열어 보고 그 자리나 Slack에서 의견을 줍니다. 프로토타입 위 실시간 댓글, 댓글이 빌드로 이어지는 기능은 만드는 중입니다. 약 700개가 쌓이자 찾기가 문제가 되어 사람, 영역, 태그, 팀, 유형으로 거르는 검색 콘솔을 만들고 있습니다. 여러 팀이 비슷한 실험을 따로 하는 조직이라면 처음부터 태그 규칙을 정해 두는 편이 낫습니다.
통념과 다른 주장
흔히 이렇게 봅니다AI 프로토타이핑은 코드를 아는 사람이 가장 잘한다.
Blair는 이렇게 봅니다가장 잘하는 사람은 제품 맥락과 분명한 그림을 가진 좋은 연출가다.
근거Reddit에서 손꼽히는 프로토타이퍼 중에는 엔지니어링 배경이 없는 비주얼 디자이너와 애니메이터가 있습니다.
흔히 이렇게 봅니다프로토타입은 그럴듯한 mock 데이터면 충분하다.
Blair는 이렇게 봅니다개인화 제품은 리뷰어 본인의 데이터로 봐야 판단이 선다.
근거로그인 데이터와 실제 컴포넌트를 쓰자 리뷰에서 곁가지 반론이 줄고 곧바로 합의가 났다고 Blair는 말합니다.
흔히 이렇게 봅니다AI가 헛돌면 더 구체적으로 지시해야 한다.
Blair는 이렇게 봅니다좁은 프로젝트에서 한 발 물러나 사실과 의도를 더 넓게 다시 말한 뒤 돌아온다.
근거Blair는 영화감독처럼 장면의 의도를 설명하는 방식을 권합니다. 목표는 정확히 하되 해법은 지나치게 정해 주지 않는 것입니다.
저자가 든 사례
검색 프로토타입: 실제 데이터와 주석으로 고치기
| 항목 | 내용 |
|---|---|
| 상황 | Blair는 검색 화면 프로토타입을 시연했습니다. 디자인 작업은 아직 하지 않은 상태였습니다. |
| 한 일 | typeahead에 인기·최근 커뮤니티를 넣으라는 주석과 함께 로그인 데이터와 실제 typeahead를 쓰라고 지정하고 ‘Apply annotations’로 Cursor에 넘겼습니다. 검색은 실제 데이터를 LLM으로 정렬합니다. |
| 결과 | ‘How I AI’를 검색하자 팟캐스트로 알아봤습니다. 모델 이름과 검색 품질 평가는 원문에서 밝히지 않음. |
| 연결 | Signed-in 데이터와 contextual annotation의 사례입니다. |
게시물 폴더 저장: Figma에서 draft PR까지
| 항목 | 내용 |
|---|---|
| 상황 | 게시물을 폴더에 저장하는 기능의 고해상도 Figma 디자인이 있었습니다. |
| 한 일 | Figma 위치를 launchpad에 붙여 feature capsule을 만들고, MCP 매핑으로 나온 PRD를 확인·수락해 Cursor로 넘겼습니다. |
| 결과 | 코드는 sibling repository에 쓰이고 draft PR이 만들어집니다. CI 리뷰를 통과하는 PR도 있고 못 하는 PR도 있다고 Blair는 말합니다. 통과 비율은 원문에서 밝히지 않음. |
| 연결 | Feature capsule과 design-system map의 사례입니다. |
조직 확산: UX·제품 조직 전원으로
| 항목 | 내용 |
|---|---|
| 상황 | 디자인 시안은 Figma 폴더에 흩어져 있어 다른 팀의 실험이 잘 보이지 않았습니다. |
| 한 일 | 디자이너와 PM이 같은 harness로 만들고 사내 공개를 기본으로 배포했습니다. |
| 결과 | 150명 이상, 사용률 100%, 프로토타입 약 700개. 도입 기간은 원문에서 밝히지 않음. |
| 연결 | Launchpad와 사내 배포·발견의 사례입니다. |
기술 디테일: 우리 제품 조직에 이 구조를 옮기려면
Contextual annotation을 돌리려면 주석 하나를 구조화된 기록으로 저장합니다. 화면 메모만 넘기면 AI가 어느 파일을 고칠지 추측합니다. Reddit의 주석 묶음에 들어가는 네 가지(코드 위치, 대상 요소, 요청, 전체 방향)를 필드로 고정하고, 디자인 시스템 참조를 하나 더 붙입니다. 아래는 가상 예시입니다.
{
"annotation_id": "ann-0142",
"file": "src/features/search/Typeahead.tsx",
"element": "TypeaheadList > Row[2]",
"request": "최근 방문 커뮤니티를 맨 위에 표시",
"direction": "signed-in 데이터 사용, 실제 typeahead 결과로 채움",
"design_system_refs": ["color.text.secondary", "ListItem"],
"data_source": "signed_in",
"status": "open"
}
에디터에 넘길 때는 열린 주석을 한 번에 묶어 보내고, 수정이 끝나면 status를 applied로 바꿉니다. 같은 요소에 주석이 둘 이상이면 먼저 사람이 합칩니다.
Design-system map은 표 하나로 시작합니다. 열은 token_or_component, figma_name, web_import_path, ios_name, prototype_path, last_verified입니다. 처음에는 화면에 가장 많이 나오는 컴포넌트 30개와 색·간격 토큰부터 채웁니다. Code Connect 같은 연결 기능이 있으면 Figma 쪽 이름은 거기서 가져옵니다. 값이 플랫폼마다 다르면 지우지 말고 mismatch 표시를 달아 디자인 시스템 담당이 정하게 합니다. Reddit이 지도를 시각화한 이유도 이런 차이를 사람 눈으로 확인하기 위해서였습니다.
MCP는 지도를 검색하는 도구 세 개면 됩니다. Proto MCP Ultra의 실제 도구 구성은 원문에서 밝히지 않았습니다. 같은 역할을 하려면 예를 들어 find_token(query), find_component(query), get_examples(component)를 둡니다. 앞의 둘은 지도 표의 행을 돌려주고, 세 번째는 그 컴포넌트를 실제로 쓴 코드 조각과 과거 리뷰 의견을 돌려줍니다. Cursor 규칙 파일에는 컴포넌트를 새로 만들기 전에 반드시 find_component를 먼저 부르라고 적습니다.
Feature capsule의 PRD는 고정 필드로 받습니다. 원문의 PRD 항목(사용자 목표, 인수 기준, 작업 세부, Figma 링크)에 매핑 결과와 매핑하지 못한 요소 목록을 더합니다. 아래는 가상 예시입니다.
{
"capsule_id": "cap-save-to-folder",
"figma_frames": ["https://figma.com/file/...node-id=12-340"],
"user_goal": "읽은 게시물을 폴더별로 저장해 다시 찾기",
"acceptance_criteria": ["저장 버튼에서 폴더 선택", "새 폴더 만들기", "저장 후 토스트 표시"],
"component_map": [{"figma_node": "SaveSheet", "component": "BottomSheet", "confidence": 0.9}],
"unmapped": ["FolderChip"],
"status": "awaiting_review"
}
PRD 생성은 temperature 0~0.2로 낮게 두고 두 번 돌려 component_map과 unmapped가 같은지 봅니다. 다르면 그 요소만 사람이 확인합니다. 원문 workflow도 PRD 확인을 가장 중요한 사람 관문으로 둡니다. unmapped가 비지 않은 PRD는 수락하지 않게 막아 둡니다.
코드는 sibling repository에서 draft PR로만 나오게 합니다. 생성 코드가 본 저장소 기본 브랜치에 바로 들어가지 않도록 권한을 나눕니다. draft PR에는 capsule_id와 PRD 링크를 넣어 디자인에서 코드까지 거꾸로 따라갈 수 있게 합니다. CI에서 떨어진 이유는 지도의 해당 행이나 get_examples 예시에 붙여 다음 생성에 쓰이게 합니다.
Signed-in 데이터는 읽기 전용 위임 토큰으로만 엽니다. 리뷰어 본인 계정 범위에서 읽기만 허용하고, 쓰기 행동(게시, 투표, 결제 등)은 mock으로 돌립니다. 프로토타입 서버는 응답 본문을 저장하지 않고 접근 기록만 남깁니다. 사내 SSO 뒤에서만 열리게 하는 것도 기본입니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 하는 일 |
|---|---|---|
| 스폰서 | 디자인 또는 프로덕트 총괄 | 파일럿 범위와 리더 리뷰 방식 승인 |
| 플랫폼 담당 | UX 엔지니어 1~2명 | Launchpad·scaffold, MCP, 사내 배포 운영 |
| 디자인 시스템 | 디자인 시스템 담당 1명 | 지도 작성, 토큰 불일치 판정 |
| 엔지니어 리뷰어 | 프론트엔드 엔지니어 1~2명 | draft PR 리뷰, 반려 사유 기록 |
| 보안·개인정보 | 1명 | signed-in 데이터 접근 범위와 기록 확인 |
| 파일럿 사용자 | 디자이너·PM 6~8명 | 실제 안건으로 프로토타입 제작·공유 |
시작 전에 모을 것. 디자인 시스템 토큰·컴포넌트 목록, Figma 라이브러리, 프로덕션 컴포넌트 코드 위치, 사내 배포 환경, 읽기 전용 데이터 API와 접근 정책, 다음 분기 리더 리뷰에 올라갈 안건 3~5개입니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | Launchpad와 scaffold 구축, 손잡이(기기·테마·사용자 상태·데이터 전환) 정의 | 출발 화면, scaffold 저장소 |
| 3~4주 | 상위 컴포넌트 30개와 토큰을 지도에 매핑, MCP 도구 연결 | 지도 표, 불일치 목록 |
| 5~6주 | 파일럿 6~8명이 실제 안건으로 제작, 리더 리뷰에 프로토타입 URL로 상정 | 프로토타입, 리뷰 기록 |
| 7~8주 | feature capsule 시범 3건, draft PR 리뷰, 확대 판정 | PRD 3건, PR 리뷰 결과, 판정 보고서 |
파일럿 사용자와 리더에게 물을 것.
- 지난 분기 리뷰에서 mock 데이터 때문에 결정을 미룬 안건이 있었나요?
- 프로토타입을 만들다 막힌 곳은 Git, 설정, 부품 찾기 중 어디였나요?
- 주석으로 요청한 수정 중 한 번에 맞은 것과 다시 고친 것은 몇 건인가요?
- PRD에서 사람이 고친 항목은 주로 무엇이었나요?
- 리뷰어로서 이 프로토타입 URL 하나로 결정할 수 있었나요?
진행 판정 기준(예시). 8주 차에 네 조건을 보고 확대합니다. 파일럿 사용자의 80% 이상이 프로토타입을 2개 이상 만들어 공유했는지, 리더 리뷰 안건 중 절반 이상이 프로토타입 URL로 결론이 났는지, feature capsule 3건 중 2건 이상이 PRD 확인 뒤 CI를 통과했는지, signed-in 데이터 접근 위반이 0건인지입니다. 기준은 파일럿 전에 정해 둡니다.
AX 적용 제언. 자체 앱이나 고객 포털을 운영하고 디자인 시스템이 있는 기업이라면 금융·유통·통신 어디든 옮길 수 있습니다. 시작은 플랫폼 전체가 아니라 세 가지입니다. 출발 화면, 맥락 붙은 주석, 사람이 확인하는 PRD입니다. 실제 데이터는 접근 통제를 갖춘 뒤에 붙입니다. 가장 오래 남는 자산은 디자인 시스템 지도이므로 예산과 인력을 여기에 먼저 둡니다. 성과 지표는 아이디어에서 리뷰 가능한 URL까지 걸린 시간, 리뷰에서 결론 난 안건 비율, PRD 수정 항목 수, draft PR 통과율로 잡습니다. 맥락이 강한 디자이너와 PM이 가장 좋은 사용자가 될 수 있으니 파일럿 인원을 개발 경험으로 고르지 않습니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 에피소드 | How I AI(Lenny’s Newsletter), 진행 Claire Vo, 2026.10.26, 약 30분 |
| 화자 | Blair Metcalf, Reddit 수석 UX 엔지니어, Reddit Proto 제작자 |
| 도구 | Reddit Proto(launchpad·scaffold), Cursor, Figma, Figma MCP, Code Connect, Proto MCP Ultra, RPL, Kubernetes 사내 배포 |
| 규모 | 프로토타입 약 700개, UX·제품 조직 150명 이상 사용, 사용률 100%, 디자인·제품 거의 반반 |
| 핵심 흐름 | 출발 화면 → 실제 디자인 시스템·데이터로 제작 → 주석으로 수정 → 사내 URL 공유 → 리더 리뷰 |
| 프로덕션 인계 | Figma 프레임 → feature capsule → PRD 확인 → sibling repository 코드 → draft PR |
| 진행 중 | 검색 콘솔(사람·영역·태그·팀·유형), 실시간 댓글, 비공개 프로젝트, iOS·Android 방향 |
| 쇼노트 항목 | 리더와 안전하게 공유하기, 실제 데이터, feature capsule, ‘Rosetta stone’, AI가 헛돌 때의 해법, 최고의 프로토타이퍼 |
핵심 개념
- vibe coding
- 원하는 결과를 말로 설명하고 AI가 코드를 짜게 하는 작업 방식.
- harness
- AI 코딩을 회사의 부품·규칙·배포 안에서 돌게 묶어 주는 틀. Reddit Proto가 이 역할을 합니다.
- scaffold
- 새 프로젝트가 처음부터 갖고 시작하는 공통 뼈대. 디자인 시스템과 예시 기능이 들어 있습니다.
- RPL
- Reddit Product Language. Reddit의 디자인 언어이자 디자인 시스템 이름입니다.
- Code Connect
- Figma 컴포넌트와 실제 코드 컴포넌트를 짝지어 개발자 화면에 코드를 보여 주는 Figma 기능.
- sibling repository
- 본 저장소 옆에 따로 둔 저장소. AI가 만든 코드를 프로덕션과 떼어 시험합니다.
- PWA
- Progressive Web App. 웹 페이지를 휴대폰에 앱처럼 설치해 쓰는 방식입니다.
- CI
- Continuous Integration. 코드 변경마다 자동으로 빌드·검사를 돌리는 절차입니다.
내 메모
TODO: 내 생각 추가
원문: Claire Vo, 「Why Reddit built its own AI prototyping tool | Blair Metcalf」(Lenny’s Newsletter, How I AI, 2026.10.26). 에피소드 페이지의 소개·쇼노트와 YouTube 설명, 진행자 Claire Vo가 운영하는 ChatPRD의 에피소드 정리 글(「Inside Reddit Proto」)과 workflow 문서(「Generate a Draft Pull Request from a Figma Design with Reddit Proto」)를 근거로 했습니다. 요약·메커니즘·사례는 대담에서 언급된 내용을 AX Partners가 다시 정리했고, 기술·현업 디테일, JSON 예시, 일정과 판정 기준, 인포그래픽, 표는 새로 작성했습니다. 대담 전체는 원문 에피소드에서 볼 수 있습니다.