이번 문서의 목표: 서비스 제공 모델에 맞는 프로토타입 요소를 실제로 제작하고, 서비스 워킹과 역할극 시뮬레이션을 진행한 뒤 그 결과를 답안에 서술할 수 있게 된다.
왜 실제로 만들고 걸어봐야 하는가
17편에서 프로토타입 기획서를 완성했습니다. 검증 목표, 표현 방식, 필요한 소품까지 다 정했습니다. 하지만 기획서는 여전히 계획일 뿐입니다. 계획대로 실제 화면을 그리고, 대본을 쓰고, 그 대본대로 사람이 직접 움직여 보기 전까지는 진짜 문제가 드러나지 않습니다.
예를 들어 “픽업 시간 선택 화면”을 종이에 그린 계획만으로는 “시간대가 겹쳐 보여서 헷갈린다”는 문제를 알 수 없습니다. 실제로 종이를 넘겨 가며 누군가에게 골라보라고 시켜야 그 순간 머뭇거리는 모습을 볼 수 있습니다.
쉽게 말하면: 지도를 그린 다음에는, 그 지도대로 실제로 걸어봐야 길이 막혀 있는지 알 수 있습니다.
서비스 제공 모델별 특성 기반 모델링
17편에서 서비스 제공 모델을 대면형, 디지털 접점형, 혼합형으로 나눴습니다. 제작 단계에서는 이 구분에 따라 실제로 무엇을 손으로 만들지가 달라집니다.
| 서비스 제공 모델 | 제작해야 할 요소 | 예시 |
|---|---|---|
| 대면 서비스형 | 응대 대본, 공간 배치 모형, 유니폼·소품 | 수거 담당자의 인사말과 확인 절차 대본 |
| 디지털 접점형 | 화면별 종이 목업, 버튼·아이콘 스케치 | 앱 홈 화면, 주소 확인 화면 종이 목업 |
| 혼합형 | 위 두 요소를 접점 순서대로 연결한 세트 | 앱 신청 화면 + 수거 담당자 대본을 하나의 흐름으로 배치 |
모델링에서 중요한 것은 “완성도”가 아니라 “연결성”입니다. 화면 하나, 대본 한 장이 아무리 정교해도 접점끼리 이어지지 않으면 사용자는 전체 서비스 경험을 느낄 수 없습니다. 그래서 제작할 때는 반드시 16편에서 정의한 접점 순서대로 요소를 배치해야 합니다.
시각적 이미지를 포함한 프로토타입 요소 제작
저충실도 프로토타입이라 해도 최소한의 시각 정보는 필요합니다. 글자만 있는 대본은 참여자가 상황을 상상하기 어렵기 때문입니다.
- 아이콘·그림 스케치: 화면 속 버튼이나 이동 경로를 간단한 도형과 화살표로 표현
- 색상 구분: 정상 흐름은 검은색 선, 문제가 예상되는 지점은 빨간색으로 표시해 시뮬레이션 중 관찰 포인트를 미리 표시
- 소품 목업: 실제 물건(세탁물 태그, 영수증, 알림 문자 캡처 등)을 종이로 흉내 내어 손에 쥐고 시연할 수 있게 준비
쉽게 말하면: 연극 무대의 소품과 같습니다. 진짜 세탁기가 없어도 “세탁기”라고 쓴 상자만 있으면 관객은 그것을 세탁기로 받아들입니다.
서비스 워킹과 역할극 시뮬레이션
서비스 워킹(service walkthrough)은 완성한 프로토타입을 가지고 실제 서비스 흐름을 처음부터 끝까지 걸어보듯이 재현하는 활동입니다. 역할극(role-play)은 참여자들이 고객·직원 같은 역할을 맡아 대본대로 행동하며 이 워킹을 진행하는 방법입니다.
- 역할 배정 — 고객 역, 직원 역, 관찰자 역을 나눈다
- 대본 리허설 — 정식 진행 전에 짧게 흐름을 맞춰본다
- 실연 — 처음부터 끝까지 실제로 접점을 순서대로 거친다
- 관찰 기록 — 관찰자가 머뭇거림, 오류, 예상 밖 반응을 그 자리에서 기록한다
- 이슈 로그 정리 — 기록한 내용을 문제점별로 분류해 정리한다
왜 역할극이 효과적인가: 사람이 실제로 몸을 움직이면 머릿속으로만 시뮬레이션할 때는 보이지 않던 문제가 드러납니다. 예를 들어 “수거 담당자가 세탁물 태그를 붙이는 동안 고객이 어색하게 서 있어야 하는 시간”은 종이 위 흐름도에는 나타나지 않지만, 실제로 연기해 보면 바로 느껴집니다.
역할극 시뮬레이션의 한계: 실제 참여자가 진짜 고객이 아니라 연기자이기 때문에, 진짜 감정 반응이나 실제 상황에서만 나오는 예외 상황(예: 갑자기 비가 오는 날의 수거)까지는 완전히 재현하지 못합니다. 이 한계는 답안에서 “한계”로 함께 서술하면 완성도 높은 답안이 됩니다.
사례로 적용하기 — 런드리핏 워크스루 진행 기록
17편에서 세운 기획(신청 화면 3장 + 수거 담당자 대본)을 실제로 제작해 워크스루를 진행했다고 가정합니다.
계산·적용 — 진행 기록표를 채워봅니다.
| 단계 | 배우 | 관찰 포인트 | 발견된 문제 |
|---|---|---|---|
| 1. 앱 홈 화면에서 픽업 신청 버튼 찾기 | 고객 역 | 버튼을 찾는 데 걸린 시간 | 버튼이 화면 하단에 있어 처음에는 지나쳤음 |
| 2. 주소 확인 화면 | 고객 역 | 기존 주소 재확인 여부 | 별문제 없이 통과 |
| 3. 픽업 가능 시간 선택 | 고객 역 | 시간대 선택까지 걸린 시간 | 오전·오후 시간대가 나란히 표시돼 헷갈려 함(기획 단계에서 예상한 지점) |
| 4. 수거 담당자 도착·응대 | 수거 담당자 역 | 인사말과 세탁물 태그 부착 절차 | 태그 부착 순서를 설명하지 않아 고객이 무엇을 하는지 몰라 어색하게 서 있었음 |
해석: 1번과 3번, 4번에서 문제가 발견됐습니다. 17편에서 미리 예상했던 3번(시간대 혼동)은 실제로도 재현됐고, 1번과 4번은 기획 당시에는 예상하지 못했던 새로운 문제입니다. 이것이 바로 프로토타입 시뮬레이션의 가치입니다 — 머릿속 계획만으로는 보이지 않던 문제가 실제로 몸을 움직이자 드러났습니다.
서술 답안 예시 — 시뮬레이션 결과 서술법
실기에서 “프로토타입 시뮬레이션 결과를 서술하시오” 문제가 나오면, 상황–관찰–문제점–개선방향 순서로 답안을 구성합니다.
상황: 런드리핏 앱의 픽업 신청 화면 3장과 수거 담당자 응대 대본으로 구성된 프로토타입을 가지고, 신규 사용자 역할극을 통해 서비스 워킹을 진행했다.
관찰: 픽업 가능 시간대를 선택하는 화면에서 참여자가 약 15초간 머뭇거렸으며, 수거 담당자가 세탁물 태그를 부착하는 동안 고객이 다음 행동을 몰라 어색하게 서 있었다.
문제점: 오전·오후 시간대가 시각적으로 구분되지 않아 선택에 혼란을 주었고, 태그 부착 절차에 대한 안내 멘트가 대본에 빠져 있어 고객이 소외감을 느꼈다.
개선방향: 시간대를 오전·오후 구획으로 시각적으로 분리하고, 수거 담당자 대본에 “태그를 붙이는 동안 잠시만 기다려 주세요”라는 안내 문장을 추가한다.
이 순서로 쓰면 관찰한 사실과 그로부터 도출한 문제, 그리고 개선안이 논리적으로 이어져 채점자가 근거를 따라가기 쉽습니다.
자주 틀리는 점
- 관찰 사실과 문제점을 구분하지 않고 뒤섞어 쓰는 실수. “머뭇거렸다”는 관찰이고 “시간대 구분이 안 된다”는 그로부터 도출한 문제점입니다. 관찰 없이 문제점만 쓰면 근거 없는 주장이 됩니다.
- 개선방향 없이 문제점만 나열하고 끝내는 실수. 실기 답안은 문제 발견에서 그치지 않고 반드시 개선방향까지 요구합니다.
- 역할극의 한계를 언급하지 않아 답안이 지나치게 단정적으로 보이는 실수. “이 방법으로 모든 문제를 완벽히 찾아냈다”는 식의 서술은 지양하고, 연기자와 실제 고객의 차이 같은 한계를 함께 언급하는 것이 더 완성도 높은 답안입니다.
- 17편의 기획 내용을 다시 처음부터 설명하는 실수. 이 편의 답안은 제작·시뮬레이션 결과에 집중해야 하며, 기획 배경은 한두 문장 요약으로 충분합니다.
핵심 정리
- 프로토타입은 기획(17편)에 이어 실제로 제작하고 걸어봐야 진짜 문제가 드러난다
- 제작 요소는 서비스 제공 모델(대면형·디지털 접점형·혼합형)에 맞춰 선택하되, 접점 순서대로 연결하는 것이 중요하다
- 서비스 워킹은 역할 배정 → 대본 리허설 → 실연 → 관찰 기록 → 이슈 로그 정리 순서로 진행한다
- 역할극은 몸으로 움직여야만 보이는 문제를 드러내지만, 진짜 고객이 아니라는 한계가 있다
- 서술 답안은 상황–관찰–문제점–개선방향 순서로 쓴다