8장. 인터랙티브 프로토타입
8장. 인터랙티브 프로토타입
정적인 화면이 아니라, 움직이는 가설을 만든다
앞 장에서 우리는 기능 흐름을 와이어프레임과 목업으로 그리는 법을 봤습니다. 거기까지가 "보여주기 위한 화면"이라면, 이번 장부터는 "시험해 볼 수 있는 경험"으로 넘어갑니다. 차이는 생각보다 큽니다. 정적 목업은 말 그대로 잘 찍은 사진에 가깝습니다. 보기에는 그럴듯하지만, 사용자가 어디를 누를지, 무엇을 헷갈릴지, 다음 화면으로 자연스럽게 넘어갈지는 알기 어렵습니다.
인터랙티브 프로토타입은 그 사진에 손잡이를 달아 주는 작업입니다. 버튼을 누르면 화면이 바뀌고, 탭을 누르면 내용이 전환되고, 모달이 열리고 닫히며, 때로는 간단한 입력과 상태 변화까지 흉내 냅니다. Anthropic은 Claude Design의 대표 활용 사례로, 정적 목업을 코드 리뷰나 PR 없이도 쉽게 공유 가능한 인터랙티브 프로토타입으로 바꾸는 흐름을 직접 내세우고 있습니다.1 즉, 엔지니어링 리소스를 본격적으로 쓰기 전에 아이디어를 먼저 움직여 볼 수 있다는 뜻입니다.
핵심은 "예쁘게 보이게 하는 것"이 아닙니다. 클릭해 봤을 때 사용자가 실제로 이해하는가, 길을 잃는가, 망설이는가를 확인하는 것입니다. 회의실에서 모두가 고개를 끄덕이던 기능이, 막상 클릭해 보면 세 번째 단계에서 갑자기 길을 잃는 경우가 정말 많습니다. 인터랙티브 프로토타입은 그 민망한 진실을 빨리 드러내 주는 도구입니다. 민망하지만, 아주 유익한 종류의 민망함입니다.
인터랙티브 프로토타입은 정확히 무엇인가
Claude Design에서 만드는 프로토타입은 단순한 이미지 묶음이 아닙니다. 실제로 브라우저 안에서 열리고, 클릭하고, 넘겨 보고, 수정하고, 공유할 수 있는 HTML 기반 결과물에 가깝습니다.2 그래서 팀 리뷰 때 화면 캡처를 넘기는 대신, "이 링크 열고 직접 눌러 보세요"라고 말할 수 있습니다. 이 한마디가 회의의 온도를 꽤 바꿉니다.
정적 목업과 인터랙티브 프로토타입의 차이는 단순히 애니메이션 유무가 아닙니다. 더 중요한 차이는 사용자의 행동이 들어오고, 그 행동에 대한 시스템 반응이 있다는 점입니다. 사용자가 필터를 누르면 결과가 바뀌고, 카드를 누르면 상세 패널이 열리고, 다음 버튼을 누르면 다음 단계로 넘어갑니다. 아주 복잡한 로직이 아니어도 됩니다. 중요한 것은 사용자가 "아, 이 제품은 이렇게 동작하겠구나"를 몸으로 이해하는 것입니다.
그래서 좋은 프로토타입은 종종 훌륭한 발표 자료보다 더 유용합니다. 발표 자료는 설득합니다. 프로토타입은 검증합니다.
시작하기 전에, 먼저 하나의 질문만 정한다
인터랙티브 프로토타입을 만들 때 가장 흔한 실수는 욕심을 내는 것입니다. 화면도 다 넣고 싶고, 상태도 다 넣고 싶고, 멋진 전환도 넣고 싶습니다. 그러다 보면 정작 무엇을 검증하려는지 흐려집니다.
그래서 시작은 항상 질문 하나면 충분합니다. 예를 들면 이런 식입니다.
신규 사용자가 온보딩을 끝까지 무리 없이 완료할 수 있는가
관리자가 승인 요청을 빠르게 처리할 수 있는가
검색 결과에서 원하는 항목을 쉽게 좁혀 갈 수 있는가
결제 플로우에서 어느 단계에서 가장 많이 망설이는가
질문이 하나로 정리되면, 프로토타입의 범위도 자연스럽게 줄어듭니다. 모든 기능을 다 보여줄 필요가 없어집니다. 검증하고 싶은 핵심 행동에 필요한 화면만 남기면 됩니다. 프로토타입은 축소판 제품이 아닙니다. 제품의 가장 위험한 가설을 시험하는 실험 장치에 가깝습니다.
1단계: 정적 화면을 재료로 모은다
인터랙티브 프로토타입은 빈 캔버스에서만 시작하지 않아도 됩니다. Claude Design은 텍스트 프롬프트뿐 아니라 스크린샷, 문서, Figma 파일, 코드베이스, 웹 캡처 같은 다양한 맥락을 받아들입니다.13 이 말은 곧, 이미 있는 정적 목업을 버리지 말고 재료로 쓰라는 뜻이기도 합니다.
가장 쉬운 방법은 앞 장에서 만든 와이어프레임이나 목업을 바탕으로 시작하는 것입니다. 여기에 한 걸음만 더 보태면 됩니다. "이 화면들을 클릭 가능한 흐름으로 연결해줘"라고 요청하는 것이죠. 만약 팀 디자인 시스템이나 코드베이스가 연결되어 있다면 더 좋습니다. Claude는 실제 컴포넌트와 스타일 패턴을 이해한 상태에서 프로토타입을 만들 수 있어서, 결과물이 훨씬 덜 공중에 뜹니다.3
여기서 중요한 것은 재료의 양보다 재료의 방향입니다. 화려한 레퍼런스를 잔뜩 넣는 것보다, 현재 제품 화면 한두 장, 핵심 플로우 설명, 그리고 꼭 지켜야 할 제약을 분명히 주는 편이 더 낫습니다. 예를 들어 "우리 제품은 왼쪽 사이드바 구조를 유지해야 함", "모바일에서는 1열 카드만 허용", "관리자만 접근 가능" 같은 조건이 훨씬 큰 힘을 발휘합니다.
2단계: 프롬프트를 '화면 설명'이 아니라 '행동 명세'로 쓴다
정적 목업을 만들 때는 "어떤 화면이 보이게 할까"가 중심이었다면, 인터랙티브 프로토타입에서는 "사용자가 무엇을 하면 무엇이 일어나는가"가 중심이 됩니다. 즉, 시각 설명보다 행동 설명이 중요해집니다.
예를 들어 이런 프롬프트가 좋습니다.
우리 SaaS의 신규 알림 센터 목업을 기반으로 클릭 가능한 데스크톱 프로토타입으로 바꿔줘. 사용자는 팀 관리자야. 시작 화면은 알림 목록이고, 사용자가 필터를 누르면 우선순위와 상태별로 결과를 좁힐 수 있어야 해. 알림 카드를 클릭하면 오른쪽 상세 패널이 슬라이드로 열리고, 그 안에서 '해결됨으로 표시'를 누르면 목록 상태가 즉시 바뀌어야 해. 빈 상태, 로딩 상태, 에러 상태도 포함해줘. 회의용 시연이 아니라 실제 사용자 테스트에 쓸 수 있게 현실적인 예시 데이터와 문구를 넣어줘.
이 프롬프트가 좋은 이유는 예쁜 형용사가 거의 없기 때문입니다. 대신 시작점, 사용자 행동, 시스템 반응, 필요한 상태가 분명합니다. Claude Design의 프로토타이핑 가이드도 개별 화면보다 전체 사용자 여정을 문맥 속에서 설명할수록 더 유용한 결과가 나온다고 안내합니다.3
한마디로 정리하면 이렇습니다. 목업 프롬프트는 장면을 묻고, 프로토타입 프롬프트는 장면 사이의 이동을 묻습니다.
3단계: 클릭 지점을 먼저 만들고, 장식은 나중에 넣는다
인터랙티브 프로토타입에서 가장 먼저 살아나야 하는 것은 아름다움이 아니라 길입니다. 사용자가 어디를 눌러야 앞으로 가는지, 어디를 누르면 정보가 더 열리는지, 무엇이 선택 가능한지부터 분명해야 합니다.
그래서 첫 번째 수정은 대개 이런 것들입니다. 탭을 실제로 눌렀을 때 내용이 바뀌게 만들기, 카드 클릭 시 상세 패널 열기, 다음과 이전 버튼 연결하기, 모달 열고 닫기, 단계 표시기와 진행 상태 보여 주기 같은 것들입니다. Claude Design은 대화, 인라인 코멘트, 직접 편집, 커스텀 조절 도구를 함께 써서 이런 수정을 빠르게 반복하도록 설계되어 있습니다.12
이 단계에서는 화려한 전환 효과보다, 사용자가 행동 결과를 즉시 이해할 수 있는 피드백이 더 중요합니다. 버튼을 눌렀는데 아무 일도 안 일어나면, 그 화면은 아무리 예뻐도 테스트 가치가 떨어집니다. 반대로 단순한 페이드 전환 하나만 있어도 사용자는 "아, 다음 단계로 넘어갔구나"를 자연스럽게 받아들입니다.
쉽게 말해, 이 단계의 목표는 "멋진 앱처럼 보이기"가 아니라 "길 잃지 않는 앱처럼 보이기"입니다.
4단계: 행복한 경로만 두지 말고, 현실도 넣는다
회의용 데모는 보통 모든 것이 잘되는 버전만 보여 줍니다. 하지만 사용자 테스트는 그렇게 친절하지 않습니다. 검색 결과가 없을 수도 있고, 네트워크가 느릴 수도 있고, 입력값이 틀릴 수도 있고, 권한이 없을 수도 있습니다. 프로토타입이 정말 검증 도구가 되려면 이런 상태를 일부러 포함해야 합니다.
Claude Design의 공식 프로토타이핑 자료는 핸드오프 전에 빈 상태, 에러 상태, 로딩 상태, 데이터 양이 달라졌을 때의 동작까지 점검하라고 권합니다.3 이 조언은 디자이너만을 위한 것이 아닙니다. PM에게는 더 중요합니다. 왜냐하면 실제 제품에서 사용자 불만이 터지는 지점은 대개 아름다운 첫 화면이 아니라, 예외 상황을 만났을 때이기 때문입니다.
예를 들어 결제 프로토타입을 만든다면 카드 입력 성공 화면만 넣지 말고, 카드 번호 오류, 결제 승인 대기, 실패 후 재시도 흐름도 같이 넣어야 합니다. 검색 경험이라면 "결과 없음" 상태가 있어야 하고, 승인 센터라면 "처리할 항목이 없음" 상태가 있어야 합니다. 이런 상태를 넣는 순간 프로토타입은 발표 자료에서 제품 실험으로 성격이 바뀝니다.
현실을 조금 넣는다고 해서 프로토타입이 덜 멋져지는 것은 아닙니다. 오히려 훨씬 더 믿을 만해집니다.
5단계: 실제 테스트처럼 보이게 만드는 작은 디테일
인터랙티브 프로토타입은 작동만 한다고 끝이 아닙니다. 테스트에 쓸 수 있으려면 사용자가 상황을 믿어야 합니다. 그래서 작은 디테일이 중요합니다.
첫째, 가짜처럼 보이지 않는 예시 데이터를 넣어야 합니다. "User 1", "Item A", "Lorem ipsum" 같은 문구는 테스트 몰입을 깨뜨립니다. 실제 사용 맥락과 비슷한 이름, 숫자, 제목, 상태값을 넣어야 사용자의 반응도 진짜에 가까워집니다.
둘째, 버튼 문구를 행동 중심으로 바꾸는 것이 좋습니다. "Submit"보다 "승인 요청 보내기", "Continue"보다 "다음: 결제 정보 입력"처럼 다음 결과가 드러나는 문구가 테스트에 유리합니다. 사용자가 버튼을 누르기 전에 결과를 예측할 수 있기 때문입니다.
셋째, 필요한 경우 아주 가벼운 지연과 전환을 넣을 수 있습니다. 로딩 스피너가 0.8초만 보여도 사용자는 시스템 반응을 더 자연스럽게 받아들입니다. 물론 남용하면 답답해집니다. 프로토타입은 영화가 아니라 실험 도구이니, 연출보다 이해가 앞서야 합니다.
넷째, 디바이스 조건을 미리 정해야 합니다. 데스크톱에서 테스트할지, 모바일에서 테스트할지에 따라 버튼 크기, 정보 밀도, 전환 방식이 달라집니다. 필요한 경우 데스크톱과 모바일 두 버전을 따로 요청하는 편이 깔끔합니다.
6단계: 수정할 때는 도구를 나눠 쓴다
Claude Design을 잘 쓰는 사람은 수정 방식도 구분합니다. 구조를 바꾸는 일은 채팅으로 하고, 특정 요소 수정은 캔버스에서 바로 처리합니다.12
예를 들어 "상세 패널 대신 전체 화면 전환으로 바꿔줘"는 구조 수정이니 채팅이 맞습니다. 반면 "이 버튼 텍스트를 더 확실하게", "이 카드 여백을 조금만 줄여줘", "이 경고 문구를 덜 공격적으로" 같은 요청은 인라인 코멘트나 직접 편집이 더 빠릅니다.
이 구분이 중요한 이유는 속도 때문만이 아닙니다. 프로토타입 작업은 생각보다 리듬이 중요합니다. 작은 수정 하나 하려고 매번 전체를 다시 설명하면 흐름이 끊깁니다. 반대로 큰 구조 문제를 사소한 댓글로 해결하려고 하면 전체 맥락이 흔들립니다.
좋은 리듬은 이렇습니다. 먼저 채팅으로 전체 행동 구조를 맞춥니다. 그다음 화면 위에서 마찰이 큰 부분을 줄입니다. 마지막으로 다시 채팅으로 "이 변경을 비슷한 모든 화면에 적용해줘"라고 확장합니다. 이렇게 하면 수정이 국소적이면서도 일관되게 쌓입니다.
7단계: 공유할 때는 '설명'보다 '과업'을 준다
인터랙티브 프로토타입을 만들고 나면, 이제 진짜 중요한 단계가 남습니다. 남에게 눌러 보게 하는 일입니다. Claude Design은 조직 내 링크 공유와 HTML 같은 형식으로의 내보내기를 지원하므로, 팀 안팎에서 비교적 쉽게 시연과 리뷰에 활용할 수 있습니다.14
이때 많이 하는 실수가 "여기 보시면 이 버튼을 누르고요, 그다음에는…" 하고 옆에서 해설을 너무 많이 하는 것입니다. 그러면 테스트가 아니라 가이드 투어가 되어 버립니다. 좋은 프로토타입 리뷰는 설명이 아니라 과업으로 시작해야 합니다.
예를 들어 이렇게 말하는 편이 낫습니다. "당신은 지금 팀 관리자입니다. 우선순위 높은 알림만 골라서 하나를 해결 처리해 보세요." 또는 "무료 플랜 사용자로 업그레이드까지 완료해 보세요." 이렇게 과업을 던지면, 사용자가 어디서 멈추고, 어디서 되돌아가고, 무엇을 놓치는지 훨씬 선명하게 보입니다.
회의에서도 마찬가지입니다. "예쁘죠?" 대신 "첫 10초 안에 어디를 누르겠어요?"라고 묻는 순간, 대화 수준이 확 달라집니다.
코드 리뷰와 PR 없이 진행한다는 말의 진짜 의미
Anthropic이 말하는 "코드 리뷰나 PR 없이 인터랙티브 프로토타입을 만든다"는 표현은, 엔지니어를 무시해도 된다는 뜻이 아닙니다.14 뜻은 훨씬 실용적입니다. 아직 아이디어를 검증하는 단계에서 저장소를 흔들 필요가 없다는 말입니다.
이 방식의 장점은 큽니다. 첫째, 엔지니어링 백로그를 늘리지 않고도 아이디어를 시연할 수 있습니다. 둘째, 아직 확정되지 않은 방향을 코드로 만들었다가 버리는 낭비를 줄일 수 있습니다. 셋째, 사용자 테스트에서 얻은 반응을 바탕으로 구조를 먼저 다듬고, 그다음에야 구현 우선순위를 논의할 수 있습니다.
특히 PM이나 창업자에게 이 점이 중요합니다. 예전에는 "이걸 테스트하려면 엔지니어 시간을 며칠 써야 하나요?"가 먼저 나왔습니다. 이제는 "먼저 프로토타입으로 눌러 보게 해보고, 반응이 좋으면 구현합시다"가 가능합니다. 아이디어가 제품이 되기 전에 한 번 더 살아남을 기회를 얻는 셈입니다.
어디까지 만들면 충분한가
인터랙티브 프로토타입도 끝없이 다듬을 수 있습니다. 하지만 어느 순간부터는 더 다듬는 것이 아니라, 진짜 제품 개발을 미루는 일이 되기도 합니다. 그래서 멈추는 기준이 필요합니다.
다음 조건이 충족되면 대개 충분합니다.
사용자가 핵심 과업을 큰 설명 없이 완료할 수 있다
주요 전환 지점이 모두 클릭 가능하다
빈 상태, 로딩 상태, 에러 상태가 최소한으로 포함되어 있다
이해관계자가 구조를 보고 토론할 수 있다
엔지니어가 구현 범위를 대략 가늠할 수 있다
여기까지 오면 프로토타입의 역할은 이미 충분히 해낸 것입니다. 그다음은 더 예쁜 프로토타입이 아니라, 더 좋은 의사결정이 필요합니다. 이후 구현 단계로 넘어갈 때는 Claude Code 핸드오프 같은 흐름이 이어질 수 있지만, 그 이야기는 다음 부에서 더 자세히 다루겠습니다.3
자주 하는 실수 다섯 가지
인터랙티브 프로토타입은 빠르게 만들 수 있는 만큼, 빠르게 엇나가기도 합니다. 특히 아래 다섯 가지는 자주 보이는 함정입니다.
화면 수를 너무 많이 잡는다. 처음부터 전체 제품을 재현하려 하면 검증 질문이 흐려진다.
행복한 경로만 만든다. 실제 사용성 문제는 대개 빈 상태, 오류, 권한 문제에서 드러난다.
동작보다 미감을 먼저 다듬는다. 길이 안 보이는 프로토타입은 예뻐도 테스트 가치가 낮다.
가짜 데이터를 대충 넣는다. 사용자는 생각보다 빨리 "이건 가짜네"를 알아차린다.
테스트를 해설로 덮는다. 옆에서 계속 설명하면 사용자의 자연스러운 망설임을 놓치게 된다.
이 다섯 가지만 피해도 프로토타입의 품질은 눈에 띄게 좋아집니다. 결국 좋은 프로토타입은 기술 과시가 아니라 이해 실험에 가깝습니다.
회의용 시안에서 테스트 가능한 경험으로
정적 목업은 아이디어를 보여 주는 데 훌륭합니다. 하지만 인터랙티브 프로토타입은 그 아이디어를 시험대에 올립니다. 이 차이는 아주 큽니다. 보여 주는 단계에서는 모두가 쉽게 동의합니다. 눌러 보는 단계에 들어가면, 그제야 진짜 문제가 드러납니다.
Claude Design이 주는 가치는 바로 이 전환 속도에 있습니다. 막연한 시안을 클릭 가능한 흐름으로 바꾸고, 팀과 공유하고, 사용자 반응을 보고, 다시 고칠 수 있습니다. 그것도 저장소를 건드리기 전에 말입니다.14
프로덕트 팀이 원하는 것은 원래부터 완벽한 화면이 아닙니다. 더 빠르게 배우는 것입니다. 인터랙티브 프로토타입은 그 배움을 눈에 보이는 형태로 압축합니다. 이제 회의실에서 "대충 이런 느낌입니다"라고 말하는 대신, 이렇게 말할 수 있습니다.
"한 번 직접 눌러 보세요."
참고
1Introducing Claude Design by Anthropic Labs
2Claude Design Tutorial: Generate Decks, Wireframes & Prototypes
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.