Where to Draw the Line: 전문가용 업무 도구에 채팅·화면·에이전트를 나눠 붙이는 기준
B2B 제품에 일괄로 붙인 채팅창이 숙련자를 오히려 느리게 만들 수 있다는 글입니다. 반복 업무는 화면에 두고, 드문 질문은 채팅으로, 상시 감시는 Ambient Agent로 보내라는 배치 기준과 함께, 티켓 분석·검증 시간·fallback ratio로 판정하는 4주 계획을 붙였습니다.
사내 시스템에 채팅 AI를 붙이기 전에, 그 업무가 하루 수백 번 하는 반복 업무인지, 분기에 한 번 나오는 드문 질문인지, 누군가 계속 지켜봐야 하는 일인지부터 나눠야 합니다. 반복 업무는 화면이 이기고, 드문 질문은 채팅이 이기고, 상시 감시는 에이전트가 맡을 때 숙련자가 느려지지 않습니다. 성과는 생성 속도가 아니라 답을 믿고 행동하기까지 걸린 시간으로 잽니다.
요약
UX 디자이너 Patrick Neeman은 2026년 10월 25일 UX Collective에 쓴 글에서, 요즘 B2B 제품이 채팅창부터 붙이면서 “이게 누구를 위한 것이고 그 사람이 원래 무엇을 하고 있었나”를 묻지 않는다고 지적합니다. 그가 염두에 둔 사용자는 숙련 전문가입니다. 이번 주에만 82번째 파일을 처리하는 손해사정사, 계약서 1만 건을 읽은 변호사, 예외 코드를 외우는 공급 계획 담당자 같은 사람들입니다. 이들은 업무 지식과 함께 그 소프트웨어 쓰는 법도 오래 익혔습니다. 그래서 대화형 레이어(conversation layer)가 초보에게는 도움이 되어도 숙련자에게는 짐이 될 수 있습니다. 저자는 AI를 어디에 둘지 가르는 여섯 가지 시험을 제시합니다. 기존 숙련을 깨는가, 초보만을 위한 것인가, 결과 집합 전체를 봐야 하는가, 숙련자를 느리게 하는가, 검증이 얼마나 어려운가, 그래서 일을 어디로 보낼 것인가입니다.
근거는 세 연구입니다. METR의 무작위 시험에서 숙련 개발자들은 AI를 쓰면 24% 빨라질 거라 예상했지만 실제로는 19% 느려졌고, 끝난 뒤에도 빨라졌다고 믿었습니다. Dell’Acqua·Mollick·Lakhani 등이 컨설턴트 758명을 연구한 결과, AI가 잘하는 과제에서는 25.1% 빨라지고 품질도 높았지만, 그 경계를 살짝 벗어난 과제에서는 정답을 낼 가능성이 19% 낮았습니다. Stanford 연구진은 Lexis+ AI와 Thomson Reuters의 법률 리서치 도구가 17~33% 비율로 환각을 낸다고 보고했습니다. 저자의 결론은 업무를 세 곳으로 나눠 보내라는 것입니다. 반복 업무는 화면에, 드문 질문은 채팅에, 상시 감시는 Ambient Agent(배경에서 계속 지켜보다 결정이 필요할 때만 끼어드는 에이전트)에 맡깁니다. 그의 표현대로 초보에게는 말이, 전문가에게는 지도가 필요합니다
. 아래에서는 이 판단을 떠받치는 메커니즘을 풀고, 사내 ERP·CRM·계약 시스템에 AI를 붙일 때 필요한 설계와 4주 판정 계획을 덧붙였습니다.
핵심 메커니즘
Expertise Reversal Effect: 초보를 돕는 장치가 숙련자에게는 짐이 되는 현상
무엇인가. 학습 연구에서 온 개념입니다. 처음 배우는 사람에게 도움이 되는 안내와 지원이, 이미 아는 사람에게는 오히려 처리할 거리를 늘려 성과를 떨어뜨립니다. 어떻게 작동하나. 초보에게 채팅은 구조 장치입니다. 메뉴 위치나 정확한 용어를 몰라도 원하는 것을 말로 꺼낼 수 있습니다. 저자는 Tesler’s Law(복잡성은 없어지지 않고 누군가에게 옮겨 갈 뿐이라는 원칙)를 들어, 채팅이 그 복잡성을 시스템 쪽으로 옮긴다고 설명합니다. 숙련자는 사정이 반대입니다. 필드명과 상태 코드를 이미 알고 있으니, 아는 것을 문장으로 바꿔 입력하는 통역 단계가 하나 더 생깁니다. 단축키, 저장해 둔 검색 400개, 하루 90초를 아껴 주는 나만의 우회로는 분석 도구에 잡히지 않아서, 화면을 갈아엎으면 소리 없이 사라집니다. 언제 쓰나. 사용자 숙련도 차이가 크거나 숙련자가 주 사용자인 제품을 바꿀 때 이 효과를 먼저 따집니다. 원문의 예. 저자는 Shneiderman의 direct manipulation(보이는 대상을 직접 조작하고 되돌릴 수 있게 하는 원칙, 1983)과 Nielsen의 recognition over recall(기억해 내게 하지 말고 알아보게 하라) 원칙을 근거로 듭니다. 바꿔야 한다면 “세 배 빠르다”처럼 숫자로 이득을 말하고, 숫자를 못 대면 기존 경로 옆에 새 기능을 나란히 두고 시험하라고 권합니다. 작은 예시(가상). 구매 담당자가 단축키 세 번으로 여는 ‘납기 지연 협력사’ 저장 뷰를 채팅으로 바꾸면, 매번 같은 문장을 쳐야 합니다.
Shape of the Set: 답 하나가 아니라 결과 집합의 모양
무엇인가. 사용자가 원하는 것이 답 하나(retrieval)인지, 주변 맥락을 포함한 결과 집합 전체(diagnosis)인지의 구분입니다. 어떻게 작동하나. 필터는 빠르고 되돌릴 수 있는 가설 검증입니다. 숙련자는 필터를 몇 번 바꿔 보며 건수, 몰려 있는 날짜, 튀는 값을 함께 봅니다. 채팅은 답만 돌려주고 그 주변을 지웁니다. 대화는 개인 공간이라 동료가 같은 화면을 가리키며 이야기할 수도, 나중에 감사할 수도 없습니다. 저자는 대화가 정보를 추적하기에 나쁜 형식이며 필요한 상태가 스크롤 뒤로 묻힌다는 Linus Lee(2022)의 지적을 인용합니다. 언제 쓰나. 모니터링, 분류(triage), 운영처럼 이상치와 패턴이 답만큼 중요한 업무입니다. 40명이 함께 큐를 보는 운영팀처럼 공유 화면이 협업의 기준인 곳도 마찬가지입니다. 이런 곳에서는 AI 검색을 주 경로가 아니라 보조로 둡니다.
Verification Time: 생성 시간이 아니라 믿고 행동하기까지의 시간
무엇인가. AI가 답을 내놓는 데 걸린 시간이 아니라, 사용자가 그 답을 믿고 승인·발송·저장하기까지 걸린 시간입니다. 어떻게 작동하나. 전문가의 결과물은 상사·고객·법원 앞에서 설명할 수 있어야 합니다. 그래서 답이 빨리 나와도 근거를 대조하는 시간이 길면 전체는 느려집니다. METR 시험의 개발자들이 체감과 반대로 느려진 이유도 여기서 읽을 수 있습니다. 환각률이 17~33%인 도구라면 모든 답을 다시 확인해야 하니 검증 비용이 생성 이득을 삼킵니다. 저자는 필터로 걸러 낸 결과가 문장으로 된 답보다 감사하기 쉽다고 봅니다. 결과 집합은 한 줄씩 원본 레코드로 돌아가 확인할 수 있기 때문입니다. 언제 쓰나. 틀린 답의 비용이 큰 법무·재무·보험·품질 업무에서 AI 기능의 성과 지표로 씁니다. 저자는 이 시간이 줄어드는지 추적하라고 권합니다.
Routine · Rare · Ongoing: 업무를 세 곳으로 나눠 보내는 기준
무엇인가. 여섯 번째 시험의 답입니다. 업무를 빈도와 성격으로 나눠 화면·채팅·에이전트 중 한 곳에 배치합니다. 어떻게 작동하나. 하루 200번 처리하는 큐 같은 반복 업무는 화면에 둡니다. 속도는 반복에서 나오고, 클릭은 거의 공짜지만 프롬프트는 호출마다 돈이 듭니다. 저자는 Gartner가 AI 프로젝트 중단 이유 상위에 비용을 올렸다는 점을 듭니다. 핵심 루프 앞에 입력창을 세우면 가장 많이 쓰는 사용자에게 세금을 매기는 셈입니다. 드문 질문은 채팅으로 보냅니다. 판단 기준은 Ticket Test(티켓 시험)입니다. 사용자가 원래 티켓을 올렸을 질문이라면 채팅의 경쟁 상대는 며칠짜리 대기이니 쉽게 이깁니다. 원래 클릭했을 일이라면 경쟁 상대는 손에 익은 동작이라 이기기 어렵습니다. 분기에 한 번 나오는 질문이면 호출 비용을 낼 만합니다. 계속 지켜봐야 하는 일은 Ambient Agent에 맡깁니다.
Ambient Agent: 묻기 전에 알려 주되, 확신이 있을 때만
무엇인가. 화면이 보여 주는 것과 같은 데이터를 배경에서 계속 살피다가, 사람이 결정해야 할 일이 생겼을 때만 끼어드는 에이전트입니다. 어떻게 작동하나. 채팅은 pull 방식이라 사용자가 무엇을 물을지 알아야 시작됩니다. Ambient Agent는 push 방식이라 무엇이 주의할 만한지를 시스템이 정합니다. 그래서 설계의 중심은 정밀도(precision)입니다. 엉뚱한 알림이 쌓이면 아무도 알림을 믿지 않으니, 확신이 없으면 조용히 있어야 합니다. 원문의 예. 비표준 책임 한도가 들어간 계약이 도착했을 때, 배송이 약속한 기간을 벗어날 때, 고객 계정의 사용량이 3주 연속 떨어질 때, 사람이 깨어 있지 않은 새벽 3시의 점검이 저자가 든 예입니다. 저자는 이 생각이 Christopher Noessel의 『Designing Agentive Technology』와 Golden Krishna의 『The Best Interface Is No Interface』(2015)로 이어진다고 소개합니다.
통념과 다른 주장
흔히 이렇게 봅니다AI 도구를 쓰면 숙련자도 빨라지고, 써 본 사람의 체감이 그 증거입니다.
저자는 이렇게 봅니다숙련자에게는 AI가 오히려 느릴 수 있고, 본인은 그 사실을 모를 수 있습니다. 그래서 체감 대신 측정이 필요합니다.
근거METR 시험에서 숙련 개발자들은 24% 빨라질 거라 예상했지만 19% 느려졌고, 끝난 뒤에도 빨라졌다고 믿었습니다.
흔히 이렇게 봅니다AI 기능의 가치는 답을 얼마나 빨리 만드느냐로 잽니다.
저자는 이렇게 봅니다전문 업무에서 재야 할 것은 답을 믿고 행동하기까지의 검증 시간입니다.
근거법률 리서치 도구의 환각률 17~33%(Stanford), AI 역량 경계 밖 과제에서 정답 가능성 19% 하락(컨설턴트 758명 연구)을 듭니다.
흔히 이렇게 봅니다새 AI 화면을 거부하는 숙련자는 익숙한 것에 매달리는 매몰비용 오류에 빠졌습니다.
저자는 이렇게 봅니다매몰비용 오류는 오히려 안 먹히는 기능에 계속 돈을 붓는 제품팀 쪽에 있습니다. 숙련자의 저항은 쌓아 둔 기술을 지키는 합리적 판단입니다.
근거실패한 결정에 더 깊이 빠져드는 현상을 다룬 Staw의 연구와, 새 패러다임마다 사용자가 수업료를 낸다는 점을 듭니다.
저자가 든 사례
손해사정사의 큐: 400건에서 12건으로
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 손해사정사 앞에 파일 400건이 쌓인 큐 | 필터로 미결 파일만 남겨 12건으로 좁힘 | 그중 3건이 SLA를 넘겼고, 특정 날짜에 몰린 패턴도 함께 보임 | Shape of the Set. 답 하나로는 보이지 않는 모양 |
계약 400건의 교차 조건 질의
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 계약 400건 중 change-of-control(지배권 변경) 조항과 비표준 책임 한도가 함께 있는 것을 찾아야 함 | 화면에 없는 교차 조건 질문을 채팅으로 처리 | 분석가 티켓으로 3일 걸리던 답을 기다리지 않음 | Ticket Test. 드문 질문은 채팅이 이김 |
상시 감시가 필요한 세 신호
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 비표준 책임 한도 계약 도착, 배송 기간 이탈, 계정 사용량 3주 연속 감소 | 사람이 묻기 전에 배경에서 감지 | 결정이 필요할 때만 담당자에게 알림. 효과 수치는 원문에서 밝히지 않음 | Ambient Agent. pull이 아닌 push |
세 연구: 속도 착각, 역량 경계, 환각
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| METR: 숙련 개발자가 자기 저장소에서 작업 | AI 허용 조건과 비허용 조건 비교 | 24% 빨라질 거라 예상했지만 19% 느려짐 | Expertise Reversal, Verification Time |
| 컨설턴트 758명 | AI 역량 안·밖 과제 비교 | 안에서는 25.1% 빠르고 품질도 높음. 밖에서는 정답 가능성 19% 낮음 | Verification Time |
| Stanford: 법률 리서치 도구 | Lexis+ AI, Thomson Reuters 도구 평가 | 환각률 17~33% | Verification Time |
기술 디테일: 사내 시스템에서 이 배치를 실제로 돌리려면
아래는 글의 기준을 사내 ERP·CRM·계약 관리 시스템에 옮길 때 필요한 설계로, AX Review가 새로 작성했습니다. 필드명과 숫자는 가상 예시입니다.
Ticket Test를 데이터로 돌리려면 최근 90일 동안 분석가·운영팀에 들어온 요청을 모아 LLM으로 분류합니다. 저자가 권한 첫 행동이 이 티켓 분석입니다. 요청 하나를 호출 하나로 처리하고, temperature는 0으로 둡니다. 출력은 JSON으로 고정합니다. request_type(요청 유형), answer_shape(single: 답 하나 / set: 결과 집합), crosses_schema(여러 테이블을 엮는가), lead_time_days(답까지 걸린 일수), existing_screen(이미 답할 화면이 있는가)입니다. 같은 요청을 3회 돌려 answer_shape가 엇갈리는 건은 사람이 봅니다. 결과를 request_type별로 묶으면 건수가 붙은 채팅 기능 후보 목록이 나옵니다. existing_screen이 true인 유형은 채팅이 아니라 화면 개선 대상입니다.
채팅 답이 화면에 떨어지게 하려면 LLM이 문장 대신 view spec(화면 정의)을 내게 합니다. 저자가 말한 ‘모든 답에 착지할 화면을 주라’를 구현하는 방법입니다. 출력 스키마는 다음과 같습니다.
{
"entity": "contract",
"filters": [
{ "field": "clause.change_of_control", "op": "=", "value": true },
{ "field": "liability_cap.is_standard", "op": "=", "value": false }
],
"sort": [{ "field": "renewal_date", "dir": "asc" }],
"columns": ["contract_id", "counterparty", "liability_cap", "renewal_date"],
"explain": "지배권 변경 조항이 있고 책임 한도가 표준과 다른 계약"
}field는 실제 스키마 목록과 대조해, 없는 필드면 실행하지 않고 되묻습니다. 실행은 기존 조회 API가 맡습니다. 그러면 결과 행이 모두 원본 레코드라 환각이 끼어들 자리가 줄고, 사용자는 필터를 고치거나 저장하고 공유할 수 있습니다.
Verification Time과 fallback ratio를 재려면 화면 이벤트 네 개를 남깁니다. answer_shown(답 표시), evidence_open(근거 레코드 열람), action_taken(승인·수정·내보내기), fallback_click(같은 일을 수동 경로로 처리)입니다. 검증 시간은 answer_shown부터 action_taken까지이고, 같은 업무의 기존 수동 처리 시간과 중앙값으로 비교합니다. fallback ratio는 ‘수동 경로 선택 ÷ (수동 + 채팅)‘입니다. 저자는 수동 경로를 남겨 두고 사용자가 실제로 무엇을 고르는지 보라고 권합니다. 인터뷰에서 하는 말보다 정직한 신호이기 때문입니다.
Ambient Agent의 정밀도를 지키려면 규칙과 모델을 겹쳐 씁니다. 1차는 규칙입니다. ‘책임 한도가 표준 조항과 다름’, ‘도착 예정일이 약속일보다 늦음’, ‘주간 사용량이 3주 연속 감소’처럼 조건으로 후보를 거릅니다. 2차는 모델이 맥락을 보고 decision_needed(사람이 결정해야 하나)와 confidence를 냅니다. 알림 JSON에는 trigger, evidence_ids, decision_needed, owner, confidence를 담습니다. confidence 0.9 미만은 알리지 않고 일일 요약에만 넣고, 담당자당 하루 알림 상한(예: 5건)을 둡니다. 알림마다 ‘유용함/불필요’ 버튼을 달아 정밀도를 주간으로 잽니다.
실패하는 경우와 대응. 첫째, 채팅이 스키마 밖 질문을 받으면 그럴듯한 필터를 지어낼 수 있습니다. 필드 대조로 막고 되묻게 합니다. 둘째, 역량 경계 밖 질문에서는 정확도가 떨어집니다. 법무·재무 판단이 섞인 질문은 결과 집합까지만 보여 주고 판단은 사람에게 넘깁니다. 셋째, 알림이 많아지면 무시됩니다. 정밀도가 목표 아래로 떨어지면 규칙 임계값부터 조입니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 4주 동안 하는 일 |
|---|---|---|
| 스폰서 | 대상 업무 부서장 | 대상 시스템 1개와 판정 기준 승인 |
| PM·프로덕트 | PM 1명 | 업무 목록·빈도표 작성, 시제품 범위 결정 |
| 현업 숙련자 | 고참 담당자 3~5명 | 저장 뷰·단축키·아침 점검 목록 공유, 시제품 시험 |
| 현업 신규자 | 입사 1년 미만 2~3명 | 같은 시제품 시험(초보 쪽 비교군) |
| 엔지니어 | 개발자 1~2명 | 티켓 분류, view spec 채팅, 이벤트 계측 |
| 분석 | 분석 담당 1명 | 검증 시간·fallback ratio·알림 정밀도 집계 |
시작 전 준비물: 최근 90일 분석가·운영팀 요청 티켓, 대상 화면의 사용 로그(화면별 일일 사용 횟수), 숙련자들이 저장해 둔 검색·뷰 목록, 시스템 스키마(필드명과 코드값), 업무별 현재 평균 처리 시간입니다.
| 주차 | 할 일 | 산출물 |
|---|---|---|
| 1주 | 업무를 반복·드문·상시로 분류, 숙련자 인터뷰 | 업무 배치표 |
| 2주 | 90일 티켓 분류, 채팅 후보 상위 5개 선정 | 건수가 붙은 후보 목록 |
| 3주 | 드문 질문 채팅 1개, Ambient 알림 1개 시제품, 숙련자·신규자 시험 | 이벤트 로그 |
| 4주 | 검증 시간·fallback ratio·정밀도로 판정 회의 | 판정 보고서 |
숙련자 인터뷰 질문: 하루에 가장 많이 반복하는 작업 세 가지는 무엇이고, 한 번에 몇 초 걸립니까? 저장해 둔 검색이나 나만의 우회로가 있습니까? 매일 아침 손으로 확인하는 것은 무엇입니까? 지난주에 누가 미리 알려 줬으면 좋았을 일은 무엇입니까? 분석가에게 요청하고 며칠씩 기다리는 질문은 무엇입니까? 저자의 다섯 질문도 회의 안건으로 그대로 씁니다. 이 사람은 시스템을 얼마나 아는가, 이 업무는 반복·드문·상시 중 무엇인가, 답이 필요한가 전체 모양이 필요한가, 누가 더 빠르고 누가 더 확실한가, 바꾸는 비용만큼 가치가 있는가입니다.
진행 판정 기준(예시): 검증 시간까지 포함한 총처리 시간이 기존보다 20% 이상 짧고, 티켓으로 3일 걸리던 질문이 당일에 답해지고, 알림 정밀도가 90% 이상이면 확대합니다. 검증 시간이 기존보다 길거나, 숙련자의 fallback ratio가 50% 이상이거나, 알림 정밀도가 70% 아래면 그 기능은 배치를 다시 설계합니다.
AX 적용 제언. 사내 Copilot 프로젝트는 대개 ‘ERP·CRM 모든 화면에 채팅창’으로 시작합니다. 이 글의 기준을 쓰면 순서가 바뀝니다. 먼저 분석가와 운영팀에 쌓인 티켓을 보고 채팅이 이길 자리를 찾습니다. 다음으로 현업이 매일 아침 손으로 하는 점검을 Ambient Agent 후보로 올리고, 하루 수백 번 도는 핵심 화면은 그대로 둡니다. 구매의 납기 지연 감시, 법무의 비표준 계약 조항 탐지, 영업의 계정 이탈 신호가 첫 후보입니다. 성과 보고서에는 ‘생성 시간 몇 초’가 아니라 검증 포함 총시간과 fallback ratio를 올리도록 KPI를 바꾸는 것이 스폰서가 내릴 결정입니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 저자·발표처 | Patrick Neeman, UX Collective(Medium), 2026.10.25 |
| 핵심 주장 | B2B 채팅 AI는 숙련자를 느리게 할 수 있음. 업무를 화면·채팅·Ambient Agent로 나눠 배치 |
| 여섯 가지 시험 | 기존 숙련 파괴, 초보 전용 여부, 결과 집합 필요, 숙련자 속도, 검증 난이도, 업무 배치 |
| METR 시험 | 숙련 개발자, 24% 빨라질 거라 예상했으나 19% 느려짐 |
| 컨설턴트 758명 연구 | 역량 안 25.1% 빠름·품질 향상, 역량 밖 정답 가능성 19% 하락 |
| Stanford 연구 | Lexis+ AI·Thomson Reuters 법률 리서치 도구 환각률 17~33% |
| 현장 예 | 손해사정사 큐 400건 → 미결 12건(3건 SLA 초과), 하루 200번 도는 큐, 40명 운영팀, 계약 400건 교차 조건, 3일 걸리는 분석가 티켓 |
| Ambient 예 | 비표준 책임 한도 계약, 배송 기간 이탈, 계정 사용량 3주 연속 감소, 새벽 3시 점검 |
| 인용 이론 | Tesler’s Law, Shneiderman direct manipulation(1983), Nielsen recognition over recall, Microsoft Research 인간-AI 상호작용 가이드라인 18개(20개 제품으로 검증, 2019), Gartner(비용이 AI 프로젝트 중단 주요 이유) |
| 실행 항목 | 티켓 있는 곳에 채팅, 모든 답에 착지할 화면, 검증 시간 측정, 아무도 설정 안 한 알림 찾기, fallback ratio 추적 |
핵심 개념
- Tesler's Law
- 복잡성은 없앨 수 없고 사용자나 시스템 중 누군가가 떠안는다는 원칙.
- direct manipulation
- 화면의 대상을 보이게 두고 직접 조작하며 언제든 되돌릴 수 있게 하는 설계 원칙(Shneiderman).
- recognition over recall
- 사용자가 기억해 내게 하지 말고 화면에서 알아보게 하라는 Nielsen의 휴리스틱.
- articulation barrier
- 원하는 것은 알지만 그것을 프롬프트로 표현하지 못하는 장벽(NN/g).
- Ticket Test
- 그 질문이 원래 티켓으로 갔을지, 클릭으로 끝났을지로 채팅의 자리를 가르는 기준.
- fallback ratio
- 같은 일을 AI 기능 대신 기존 수동 경로로 처리한 비율. 사용자의 실제 평가.
- pull / push
- 사용자가 물어야 시작되는 방식(채팅)과 시스템이 먼저 알리는 방식(Ambient Agent).
내 메모
TODO: 내 생각 추가
원문: Patrick Neeman, “Where to draw the line before AI reaches professional users”(UX Collective, 2026.10.25). 요약·핵심 메커니즘·통념과 다른 주장·저자가 든 사례·원문 사례 표는 글의 내용을 AX Review가 다시 정리했으며, 연구 수치는 원문이 인용한 대로 옮겼습니다. 기술·현업 디테일, JSON 예시, 이벤트 설계, 일정·판정 기준, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. 원문 전체는 UX Collective에서 볼 수 있습니다.