커피숍 코드 리허설: 키보드를 치기 전에 종이 위에서 기능을 설계하는 법

소개: 왜 노트북을 열지 말고 덮어둬야 할까

코딩을 하려고 커피숍에 앉습니다. 그런데 노트북을 여는 대신, 공책과 펜, 그리고 포스트잇 몇 장을 꺼냅니다. 다음 한 시간 동안, 당신은 새 기능을 전부 종이 위에서 설계하고 "실행"해 봅니다.

이게 바로 커피숍 코드 리허설입니다. 키보드를 치기 전에, 종이 위에서 기능을 연습하는 것.

코드를 부정하는 방식이 아닙니다. 코드 이전(pre‑code) 단계입니다.

기능을 종이로 리허설하면, 여러 가지 설계안을 빠르게 탐색하고, UX와 워크플로 문제를 초기에 드러내며, 구현 디테일에 끌려가지 않고 사용자 여정을 차분히 생각해볼 수 있습니다. 잘만 하면 이 저렴하고 아날로그한 의식(ritual)은 몇 시간, 많게는 며칠 치의 재작업을 줄여줍니다.

이 글에서는 커피숍 코드 리허설이 실제로 어떻게 보이는지, 왜 효과적인지, 그리고 오늘 당장 시작할 수 있는 실전용 반복 프로세스를 살펴보겠습니다.

커피숍 코드 리허설이란 무엇인가?

커피숍 코드 리허설은 의도적으로 온라인에서 벗어나 진행하는 오프라인 설계 세션입니다. 여기서 당신은 다음을 수행합니다.

만들 예정인 기능을 스케치하고
사용자 상호작용을 종이 위에서 시뮬레이션하며
플로우, 엣지 케이스, 상태 변화를 따라가 보고
동료나 잠재 사용자에게 가볍게 피드백을 받고
단 한 줄의 코드를 쓰기 전에 설계를 다듬습니다.

장소는 어디든 상관 없습니다. 책상, 화이트보드, 공원 벤치 어디서나 할 수 있습니다. 다만 커피숍이라는 표현이 주는 느낌이 중요합니다. 캐주얼하고, 부담 낮고, 평소 쓰는 도구들에서 살짝 떨어진 상태.

목표는 픽셀 단위의 완벽한 디자인이 아닙니다. 핵심은 명확성입니다.

이 기능이 정확히 무엇을 해야 하는가?
사용자는 이 기능 안에서 어떻게 이동하는가?
무엇이 잘못될 수 있고, 어떻게 처리할 것인가?
사용자가 헷갈리거나 막힐 수 있는 지점은 어디인가?

에디터를 열 때쯤이면, 머릿속과 종이 위에서 이미 이 기능을 여러 번 리허설해본 상태가 됩니다.

왜 먼저 종이인가? 값싸게 탐색하는 힘

1. 코드를 짜기 전에, 설계를 마음껏 탐색할 수 있다

코딩을 시작하는 순간, 당신은 여러 가지 **커밋(결정)**을 하게 됩니다.

데이터 모델
API 계약(contracts)
UI 컴포넌트
라이브러리 선택

이 결정들을 바꾸는 일은 비용이 큽니다. 반면 종이는 놀라울 정도로 싸죠.

펜과 종이 몇 장만 있으면 이렇게 할 수 있습니다.

10분 안에 서로 다른 레이아웃 아이디어 3개를 그려보기
같은 작업을 위한 경쟁 플로우 2가지를 스케치해보기
리팩터링 없이도 단계를 추가하거나 빼보기

심리적인 효과도 큽니다. 한 시간을 씨름해서 겨우 돌아가게 만든 코드보다는, 대충 그린 스케치를 버리는 편이 훨씬 마음이 편합니다. 덕분에 좋지 않은 아이디어를 초기에 과감히 버리기가 쉬워집니다.

2. 비용이 커지기 전에 UX와 워크플로 문제를 잡는다

많은 프로젝트 지연의 원인은 순수한 기술 난이도보다는 설계에 대한 오해에서 시작됩니다.

사용자 플로우에 단계가 너무 많다
중요한 정보가 숨겨져 있거나 애매하다
에러 상태에 대한 처리가 없다
“간단해 보이는” 기능이 사실은 엣지 케이스 덩어리다

종이 프로토타이핑은 이런 것들을 초기에 드러냅니다. 종이로 만든 플로우를 다른 사람에게 보여주고 따라가 보게 했을 때, 그 사람이 “잠깐, 여기서 어떻게 돌아가요?” 혹은 “이 버튼이 뭘 하는지 잘 모르겠어요”라고 말한다면, 코드를 짜기 전에 진짜 문제를 발견하고 있는 겁니다.

이런 문제를 종이 단계에서 잡으면 다음을 아낄 수 있습니다.

며칠짜리 재설계와 리팩터링
개발자가 UI를 다시 뜯어고치는 데 쓰는 시간
애초에 구조가 잘못된 플로우를 QA가 반복해서 검증하는 시간

3. 도구가 아니라 사용자에 집중하게 해준다

Figma에서 디자인을 하거나 바로 React로 구현을 시작하면, 머리가 쉽게 이런 쪽으로 쏠립니다.

컴포넌트 재사용
라이브러리 제약사항
CSS 이슈

커피숍 리허설에서는 이런 걸 전부 내려놓습니다. 오토 레이아웃도 없고, 빌드 에러도 없고, 린터도 없습니다.

대신 이렇게 생각하도록 강제됩니다.

사용자 목표: 사용자는 실제로 무엇을 하려는가?
사용자 플로우: A에서 B, B에서 C로 어떻게 이동하는가?
엣지 케이스: 데이터가 하나도 없으면? 네트워크가 끊기면?
명확성: 클릭이나 탭 했을 때 무슨 일이 일어나는지 직관적으로 보이는가?

이 오프라인 제약은 버그가 아니라 **특징(feature)**입니다. 뇌를 제품과 경험에 고정시키고, 구현 디테일에서 벗어나게 해줍니다.

간단하지만 반복 가능한 종이 프로토타입 프로세스

이 연습을 복잡하게 만들 필요는 없습니다. 다음의 4단계 루프만 반복해도 충분히 잘 작동합니다.

스케치하기(Sketch)
상호작용 시뮬레이션하기
피드백 받기
수정·반복하기(Refine)

각 단계씩 살펴보겠습니다.

1. 스케치: 기능을 종이 위에 펼치기

UI부터 그리지 말고, 사용자 스토리부터 시작하세요. 페이지 맨 위에 한 줄로 적습니다.

“사용자로서, 주간 리포트를 예약해 두고 싶다. 그래야 매번 수동으로 생성하지 않아도 된다.”

그 다음 이 스토리에 관련된 화면이나 상태를 스케치합니다. 박스, 화살표, 라벨이면 충분합니다. 일부러 투박하게 그리세요.

각 화면이나 패널의 대략적인 레이아웃 그리기
주요 액션(버튼, 링크, 제스처)에 라벨 달기
중요한 시스템 상태(로딩, 비어 있음, 에러, 성공 등) 메모하기

플로우의 각 단계를 종이 한 장씩 따로 쓰세요.

1장: 기존 리포트 리스트 화면
2장: “스케줄 생성” 다이얼로그
3장: 완료/관리 화면

목표는 **완성된 디자인이 아니라, 흐름(flow)**을 잡는 것입니다.

2. 상호작용 시뮬레이션: 연극처럼 "실행"해 보기

이제 프로토타입을 작은 시뮬레이션으로 바꿔 봅니다.

자신을 사용자라고 생각하고
클릭이나 탭을 한다고 가정하며 요소를 손가락으로 짚어가고
무엇을 하고 있고, 무엇을 기대하는지 소리 내어 설명합니다.

예를 들어:

“지금 리포트 페이지에 있어요. 이 리포트를 매주 자동으로 받고 싶어요. ‘리포트 예약’이라는 버튼이 보이네요 — 클릭합니다. 그러면 빈도와 시간을 묻는 다이얼로그가 뜰 거라고 예상해요. 주간, 월요일 오전 9시로 설정합니다. 저장을 누릅니다. 이제는 예약된 리포트 목록이 보이거나, 적어도 예약이 성공했다는 확인 메시지를 기대해요.”

이렇게 내레이션하면서, 마찰이 있는 순간을 유심히 보세요.

어디를 클릭해야 할지 바로 알 수 있었는가?
옵션들이 명확했는가?
중간에 길을 잃은 느낌이 있었는가?
놓친 상태(예: 사용자가 취소했을 때)는 없는가?

헷갈리거나 모호한 부분에는 크게 **“?”**를 적거나, “여기서 사용자 혼란” 같은 메모를 남겨 두세요.

3. 피드백 받기: 다른 사람에게 보여주기

단 한 사람만 참여해도 설계 품질은 눈에 띄게 좋아집니다.

동료 개발자, PM, 디자이너, 혹은 옆자리 친구에게 사용자를 부탁하세요. 첫 번째 페이지를 건네며 말합니다.

“지금 당신이 [X를 하고 싶다]고 상상해 보세요. 어떻게 할지 쭉 말로 설명하면서 따라가 주세요.”

상대가 상호작용하는 동안에는:

설명하고 싶어도 최대한 참습니다.
어디서 멈칫하거나 질문하는지 지켜봅니다.
오해의 포인트를 기록합니다. (예: “이건 지금 보내는 건 줄 알았어요. 예약인 줄 몰랐어요.”)

가볍게 **역할극(role‑play)**을 해도 좋습니다.

한 사람은 “컴퓨터”가 되어, 상대가 "클릭"할 때마다 종이를 넘기거나 새 화면을 보여줍니다.
다른 사람은 사용자 역할을 하며, 무엇을 하고 무엇을 기대하는지 말합니다.

이 모든 과정은 커피 한 잔 마시는 사이, 몇 분이면 충분합니다.

4. 수정·반복: 빠르게 돌려보기

새 종이를 꺼내 개선된 버전을 다시 그립니다. 예전 걸 지우고 고치기보다는, 그 버전을 테스트 결과의 스냅샷으로 남겨 둔다고 생각하세요.

배운 것들을 바탕으로 플로우를 다듬습니다.

불필요한 단계를 제거하고
라벨이나 액션을 더 명확하게 만들고
빠졌던 상태나 확인 단계(confirmation)를 추가합니다.

다시 한 번 플로우를 쭉 실행해 봅니다. 시간이 허락한다면 다른 사람에게 한 번 더 보여주세요. 각 반복 루프는 가볍고 빠르게 — 10~20분 정도에 끝내는 게 좋습니다. 며칠짜리 작업이 아닙니다.

효과적인 종이 리허설을 위한 베스트 프랙티스

커피숍 세션에서 최대 효과를 내고 싶다면, 다음 원칙을 기억해 두세요.

1. 의도적으로 저(低)충실도(Low‑fidelity)를 유지하라

정교한 그림은 함정입니다. 고충실도 스케치는 색깔이나 간격 같은 시각적 디테일 논쟁으로 흐르기 쉽습니다. 지금 필요한 것은 구조와 명확성이지, 폴리시(polish)가 아닙니다.

복잡한 UI 요소 대신 박스와 텍스트만으로 표현하세요.
막대기 인간, 대충 그린 아이콘이면 충분합니다.
라벨을 또렷하게 쓰는 데 집중하세요. 의미는 거기에 담깁니다.

투박한 스케치는 보는 사람에게 “아직 얼마든지 바꿀 수 있다”는 신호를 줍니다. 비판과 변경이 훨씬 쉬워집니다.

2. 사용자 시나리오를 입으로 풀어라

항상 구체적인 이야기 위에서 작업하세요.

“처음 로그인하는 완전 신규 사용자”
“작업을 최대한 빨리 끝내고 싶은 숙련 사용자”
“방금 네트워크 에러가 나서 짜증이 난 사용자”

내레이션을 통해 생각하면 추상적인 기능이 아니라, 실제 행동에 계속 초점을 맞출 수 있습니다.

3. 상호작용을 역할극처럼 연기하라

정적인 도면이 아니라, 작은 연극처럼 다루세요.

한 명은 사용자, 한 명은 시스템 역할을 맡습니다.
액션이 일어날 때마다 종이를 넘기거나 포스트잇을 떼어내어 다음 상태를 보여줍니다.
1인칭으로 말합니다. “지금 이걸 클릭해요”, “이제 이런 화면이 나오길 기대해요” 같은 식으로.

역할극을 하면, 문서만 보고는 지나쳤을 숨은 가정들이 튀어나옵니다.

4. 빠른 반복을 받아들여라

한 번에 완벽하게 만들려 하지 마세요. 첫 스케치는 유용하게 틀린 상태일 거라고 기대하는 편이 낫습니다.

전체 세션에 시간을 정하세요. 예: 30~45분
최소 2~3번의 반복을 하겠다고 마음먹으세요.
각 버전은 사진으로 찍어 두고, 나중에 아이디어를 되돌아볼 수 있게 합니다.

이 단계에서는 완벽함보다 속도가 훨씬 중요합니다.

AI는 어디에 쓰면 좋을까? — 리허설 이후에

AI 도구는 사람 중심, 종이 우선 설계를 한 뒤에 투입할 때 진가를 발휘합니다.

종이로 플로우를 충분히 정리하고 나면, AI는 이런 부분을 도와줄 수 있습니다.

스케치를 기반으로 한 여러 UI 변형안 생성
대체 플로우나 단순화 아이디어 제안
손으로 그린 화면을 저충실도 디지털 와이어프레임으로 변환
피드백 메모들을 분석해 반복해서 등장하는 이슈를 도출

하지만 처음부터 AI로 시작하면, 자칫 너무 이른 단계에서 높은 충실도, 도구 중심의 디자인으로 끌려들어가기 쉽습니다. 그러면 더 근본적인 질문이 가려집니다.

이 플로우 자체가 정말 맞는 방향인가?
애초에 올바른 사용자 문제를 해결하고 있는가?

AI는 **대체재가 아니라 증폭기(multiplier)**로 쓰세요. 먼저 커피숍 리허설로 사람 중심의 뼈대를 만들고, 그 다음에 AI를 데려와 다듬고 확장하고 체계화하도록 하는 것이 좋습니다.

결론: 한 번의 이벤트가 아니라, 습관으로 만들기

커피숍 코드 리허설은 구조가 단순합니다.

에디터 대신 종이와 펜을 집어 들고
기능을 일련의 상태와 플로우로 스케치하고
상호작용을 시뮬레이션하며 사용자 시나리오를 내레이션하고
빠른 피드백을 받은 뒤, 다시 그려보는 것.

이 아날로그한 루틴은 다음을 가능하게 합니다.

더 많은 아이디어를, 훨씬 더 싸게 탐색하고
UX와 워크플로 문제를 “코드 문제”로 번지기 전에 잡아내며
프레임워크와 툴이 아니라, 사용자에게 집중하게 해 줍니다.

대규모 리디자인이나 공식 워크숍을 기다릴 필요도 없습니다. 다음과 같은 경우에 가볍게 종이 리허설을 써보세요.

새로운 온보딩 플로우를 설계할 때
복잡한 설정 페이지를 만들 때
여러 단계를 거치는 까다로운 기능을 구현할 때

다음에 “코딩하러” 커피숍에 갈 일이 있다면, 처음 45분은 노트북을 닫아둔 채로 시작해 보세요. 기능을 종이 위에서 리허설해 보세요. 그러고 나서 키보드를 두드릴 때쯤이면, 최소한 리허설 단계에서는 이미 한 번 작동해 본 것을 코드로 옮기고 있을 겁니다.