1주일 프로토타입 약속: 당신의 실험을 결국 ‘진짜로’ 출시하게 만드는 작은 의식

사이드 프로젝트는 유령선이 되기 쉽다.

처음엔 짜릿한 설렘과 함께 새 레포지토리, 반짝이는 아이디어로 시작한다. 한 달쯤 지나면, 리팩터링과 아키텍처 결정, “이것만 더 넣자”는 기능들에 파묻혀 버린다 — 그리고 막상 다른 사람에게는 도저히 보여줄 수 없는 상태가 된다.

이 스크립트를 아예 뒤집어 보면 어떨까?

“준비될 때까지 이 사이드 프로젝트를 계속 할 거야” 대신, 아주 작고 잔인할 정도로 명확한 약속을 한다:

딱 1주일 안에, 진짜 사용자가 쓸 수 있는 프로토타입을 출시한다.

이게 바로 **‘1주일 프로토타입 약속(One-Week Prototype Pact)’**이다. 머릿속에서 맴도는 아이디어를 억지로 끌어내서, 코드로 만들고, 세상 밖으로 밀어내게 만드는 작은 의식이다.

이 글에서는 왜 이 방식이 통하는지, 어떻게 실행하는지, 그리고 번아웃이나 무한 정체 없이 많은 아이디어를 빠르게 실험하는 반복 가능한 습관으로 만드는 방법까지 살펴본다.

1주일 프로토타입 약속이란?

약속은 단순하다.

타임박스: 당신에게 주어진 시간은 캘린더 기준 정확히 1주일이다. “대략 일주일쯤”이 아니다.
결과물: 끝날 때까지 실제 사용 가능한 프로토타입을 출시해야 한다. (컨셉 설명, 와이어프레임, 로컬 전용 빌드가 아니다.)
목표: 목표는 학습과 검증이지, 다듬기나 완벽함이 아니다.
결정: 1주일이 끝나면 반드시 결정을 내린다: 계속 다듬는다(iterate), 방향을 튼다(pivot), 아니면 접는다(kill).

이건 생산성 꼼수가 아니다. 사고방식을 재구성하게 만드는 제약이다.

v3를 상상하는 대신, v0.1에 집중하게 만든다.
오버엔지니어링을 멈추고, 투박하지만 돌아가는 것에 만족하게 만든다.
아이디어를 머릿속에 쌓아두지 않고, 검증 가능한 실험으로 계속 바꾸게 만든다.

제품 출시가 아니라 ‘초안’을 만든다고 생각하라

대부분의 사이드 프로젝트가 멈추는 이유는, 우리 마음속에서 그것들을 은근슬쩍 완성된 제품처럼 대하기 때문이다.

“온보딩 플로우를 더 매끄럽게 해야 해.”
“제대로 된 마이크로서비스 구조를 잡아야겠지.”
“일단 로고부터 좀 예쁘게 만들어보자.”

1주일 약속에서 프로토타입은 초안이다. 개발 용어로 말하면 **스파이크(spike)**에 더 가깝다.

목적은 불확실성을 줄이는 것이다. 누가 이걸 정말 쓸까? 핵심 인터랙션은 실현 가능할까?
이 프로토타입은 애초에 **버릴 수 있는 것(disposable)**이다. 1주일 후에 통째로 날려도 된다.
장기적인 고민은 잠시 제쳐두고, 단기적인 학습을 극대화하는 데 집중한다.

이렇게 생각해 보자:

“이 코드는 약속이 아니라 질문이다.”

이 코드는 다시는 안 볼 수도 있다는 마음으로 작성하라. 실제로 안 보게 될 수도 있다.

의견이 분명하고, 레버리지가 큰 도구를 써라

어떤 도구를 쓰느냐에 따라 1주일 약속의 성공 여부가 갈린다.

1주일 안에 할 수 없는 것들:

인증(Authentication)을 직접 구현하기
배포 플랫폼 5개를 비교하며 토론하기
처음부터 커스텀 디자인 시스템을 설계하기

필요한 건 배터리가 포함된(batteries included), 기본값과 의견이 뚜렷해서 인프라 고민에 뇌를 소모하지 않게 해 주는 도구들이다.

예를 들면:

웹 앱?
Next.js + AWS Amplify, Vercel, Supabase 같은 걸 쓰자.
- 인증, 호스팅, API, 데이터까지 며칠이 아니라 몇 시간 단위로 끝낼 수 있다.
모바일 앱?
실제 기기 테스트와 배포가 빠른 Expo 같은 프레임워크를 쓰자.
내부 도구나 어드민 인터페이스?
Retool, Budibase 같은 툴을 활용하자.

간단한 기준은 이렇다:

이번 주에 내릴 10개의 결정을 안 해도 되게 해 준다면, 그 도구는 좋은 선택이다.

좋은 도구의 조건:

명확한 기본값을 제공하고
아이디어 → 라이브 URL까지 하루 안에 도달하게 도와주며
피벗할 때 미련 없이 버리고 갈 수 있을 정도로 가볍다

이번 주의 목표는 완벽한 스택을 짜는 게 아니다. 아이디어와 사용자 사이의 거리를 극단적으로 줄이는 것이다.

하나의 명확한 결과를 정하고, 나머지는 가차 없이 잘라라

1주일은 생각보다 훨씬 빨리 사라진다. 목표가 흐리면 작업도 쉽게 표류한다.

시작하기 전에, 단 하나의 결과를 정의하라. 예를 들면:

“사용자가 파일을 업로드하고, 변환된 결과를 볼 수 있는 클릭 가능한 데모 하나.”
“베타 유저 5명이 가입해서 핵심 워크플로우 1개를 끝까지 완료할 수 있는 작동하는 MVP.”
“사람들이 이 아이디어에 관심이라도 있는지 확인하기 위한, 간단한 랜딩 페이지 + 웨이트리스트 폼.”

그리고 이렇게 물어보라:

“핵심 가정을 입증하거나 깨부수기 위해, 우리가 만들 수 있는 가장 작은 것은 무엇인가?”

그 다음에는 스코프를 공격적으로 줄여라.

설정 페이지, 대시보드, 분석 기능은 통째로 날려라.
하드코딩할 수 있는 건 그냥 하드코딩하라.
브라우저 하나, 플랫폼 하나, 해피 패스 하나만 지원해도 된다.

그 일이 당신의 하나의 결과에 직접적으로 기여하지 않는다면, 지금 이 주에는 방해물일 뿐이다.

1주일 약속에서 “있으면 좋을 것 같은 기능”은 사실 “이번 주에는 절대 만들지 않을 기능”이다.

그 결과를 눈에 잘 보이는 곳에 적어 두고, 모든 작업을 이 기준으로 거르라.
“이 작업이 저 결과에 직접적으로 기여하는가?”
아니라면, 이번 주에는 할 일이 아니다.

작고 촘촘한 ‘일일 피드백 루프’로 움직여라

1주일 안에서도, 며칠씩 엉뚱한 방향으로 헤맬 수 있다.

이를 막으려면 하루 단위 피드백 루프를 설계해야 한다.

예시 리듬:

1–2일차: 코어 뼈대와 메인 사용자 플로우 만들기
3–4일차: 투박해도 좋으니, end-to-end로 실제 사용이 가능한 상태 만들기
5일차: 내부 데모와 소규모 사용자 테스트 진행
6일차: 가장 날카로운 불편 요소를 수정하고, 테스트 유저 온보딩
7일차: 공개(또는 타깃 그룹에 배포), 피드백 수집, 회고

매일의 목표는 두 가지다:

뭐라도 데모할 수 있는 것을 만든다. 크기와 완성도는 상관없다.
그걸 누군가에게 보여준다.
친구, 동료, 잠재 사용자, 아니면 최소한 미래의 나에게 보내는 loom/동영상이라도 좋다.
오늘 얻은 걸 바탕으로 내일 계획을 조정한다.

이렇게 하면 스스로를 속이기 어렵다.
“데모하기 어려운 상태”라면, 너무 추상적이거나 과하게 복잡하게 만들고 있다는 신호다.

작은 루프는 완벽주의와 미루기를 동시에 억제한다.

진짜 사용자에게 출시한 뒤, 결정하라: 계속, 피벗, 종료

이 약속은 마지막 커밋을 푸시했다고 끝나는 게 아니다.
프로토타입을 진짜 사용자에게 보여주고, 결정을 내렸을 때 끝난다.

선택지는 세 가지다:

Iterate(계속 다듬기) – 반응이 충분히 괜찮아서, 한 주를 더 투자할 가치가 있다.
Pivot(방향 전환) – 뭔가는 먹히는데, 애초의 가정이 틀렸다는 느낌이 든다.
Kill(종료) – 사용자들이 관심이 없거나, 내가 더 이상 이걸 붙잡고 있을 만큼 열정이 없다.

핵심은 이 결정을 명시적으로 내린다는 점이다.

1주일짜리 프로토타입은, 결과가 “이건 더 이상 내 시간을 쓸 가치가 없다”여도 성공이다.
왜냐하면 그 한 주로 몇 달을 아낄 수 있기 때문이다.

1주일 만에 아이디어를 접는 건 승리다. 몇 달 치의 시간을 번 거니까.

이를 제대로 하려면:

사용자 몇 명과 이야기하라. (3–5명만 있어도 충분히 의미 있다.)
직접 사용하는 모습을 보거나, 함께 화면을 보면서 walkthrough를 해 보라.
이렇게 물어보라: “이게 뭘 해 줄 거라고 기대했나요?”, “다음 주에도 이걸 계속 쓰시겠어요?”
칭찬 말고 행동 신호를 보라.

그리고 질문하라: “다음에 걸어볼 수 있는 가장 작은 베팅은 무엇인가?”
또 한 주를 더 쓸 것인가? 방향을 바꿀 것인가? 아니면 완전히 새로운 아이디어로 넘어갈 것인가?

이걸 ‘반복 가능한 습관’으로 만들어라

1주일 프로토타입 약속의 진짜 힘은, 이걸 일회성 이벤트가 아니라 정기적인 의식으로 만들 때 나온다.

한 해를 이렇게 보내는 걸 상상해 보자:

매달(혹은 분기마다) 한 번씩 1주일 약속을 진행한다.
6–12개의 프로토타입을 출시한다.
그 대부분을 과감히 접는다.
진짜 트랙션이 보이는 1–2개에만 집중 투자한다.

이 리듬은 당신이 다음을 할 수 있게 돕는다:

끝도 없이 끌리는 사이드 프로젝트 하나 대신, 훨씬 더 많은 아이디어를 탐색하고
반쯤 만든 레포지토리 더미가 아니라, 실제로 출시해 본 실험 포트폴리오를 쌓고
시장, 기술, 그리고 스스로의 관심사에 대해 훨씬 빠르게 학습할 수 있다.

가벼운 구조를 만들어 두는 것도 좋다:

Day 0 (계획): 아이디어 선택, 결과 정의, 도구 선택
Day 1–6: 매일 마이크로 데모를 만들며 빌드
Day 7: 출시, 피드백 수집, 회고, 결정
약속과 약속 사이: 휴식, 성찰, 다음 아이디어 큐에 쌓기

시간이 지나면 당신만의 도구 세트, 패턴, 직관이 정교해진다.
어떤 도구가 가장 빠르게 움직이게 해 주는지, 반복해서 쓰게 되는 패턴은 무엇인지, 어떤 유형의 아이디어가 **“한 주를 더 쓸 가치가 있는지”**를 점점 더 잘 알게 된다.

첫 번째 1주일 약속, 이렇게 시작하라

완벽한 계획이 필요하지 않다. 필요한 건 출발점 하나뿐이다.

계속 미뤄 온 아이디어 하나를 고른다.
캘린더에 1주일을 블록으로 잡는다.
(평일 저녁 + 주말 정도만으로도 충분하다.)
결과를 한 문장으로 적는다.
스스로 부끄러울 정도로 작게 잡아라.
**두 번 고민하지 않을 ‘의견 강한 스택’**을 선택한다.
누군가에게 이 약속과 출시 날짜를 알린다. (책임감이 생긴다.)
처음부터 거칠게 만들고, 1일차 끝날 때까지 뭐라도 데모할 수 있는 걸 만든다.

그리고 1주일이 끝났을 때, 이렇게 물어보라:

무엇을 배웠는가?
사용자에 대해 뭐가 가장 의외였는가?
이 아이디어에 한 주를 더 쓰고 싶은가?

그 답에 따라 결정을 내리고, 그 결정에 커밋하라. 그게 이 약속의 핵심이다.

결론: 판타지 대신 피드백을 택하라

끝없이 이어지는 사이드 프로젝트는 일종의 판타지다.
우리는 실제로는 세상에 아무것도 내놓지 않으면서도, 머릿속으로는 성공을 상상하는 쾌감을 얻는다.
실제로는 불완전한 무언가를 세상에 내놓는 불편함을 피하고 있을 뿐이다.

1주일 프로토타입 약속은 그 판타지에 대한 해독제다.

자신을 이렇게 제약함으로써:

단 1주일
단 하나의 명확한 결과
실제 사용자 앞에 놓이는 단 하나의 프로토타입

…당신은 판타지를 버리고 피드백을 얻고, 공상 대신 데이터를 얻는다.

더 많은 허술한 코드, 더 많은 못생긴 v0.1을 만들 것이고, 더 많은 아이디어를 과감히 접게 될 것이다.

하지만 거의 필연적으로, 버티고 싶은 무언가를 하나는 발견하게 될 것이다.
그때가 되면, 이미 빠르게 움직이고, 빨리 배우고, 의도를 갖고 출시하는 근육이 길러져 있을 것이다.

스스로에게 이렇게 약속하라:
1주일, 1개의 프로토타입, 1번의 명확한 결정.
그리고, 뭔가가 붙을 때까지 이 리듬을 반복하라.