💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — 어느 금요일 밤의 두 사람

같은 회사에 다니던 두 동료가 있었습니다. 편의상 A와 B라고 부르겠습니다. 두 사람은 비슷한 시기에 입사했고, 비슷한 연봉을 받았으며, 기술 트렌드에 대한 관심도 비슷했습니다.

금요일 밤이 되면 두 사람은 비슷한 일을 했습니다. 새로 나온 도구에 관한 글을 읽고, 컨퍼런스 영상을 보고, 화제가 된 오픈소스 저장소를 별표(star)에 추가했습니다. 차이는 단 하나였습니다. B는 토요일 오후가 되면 그중 하나를 실제로 설치하고, 망가뜨리고, 작은 무언가를 만들어 보았습니다. A는 다음 글을 읽었습니다.

2년이 지났습니다. A는 여전히 "요즘 핫한 것들"을 누구보다 잘 알고 있었습니다. 대화를 나누면 박식했습니다. 그런데 B는 그 사이에 사내 도구 세 개를 만들었고, 그중 하나가 팀 전체의 표준이 되었으며, 주말에 만든 작은 사이드 프로젝트가 월 사용자 수천 명을 모았습니다. 승진과 이직 제안은 B에게 갔습니다.

이 글은 A를 비난하려는 글이 아닙니다. 우리 대부분은 A에 가깝게 살고 있고, 저 자신도 오랫동안 A였습니다. 이 글은 A와 B를 가른 그 작은 차이 — **읽는 사람과 만드는 사람의 차이** — 에 관한 이야기입니다. 그리고 그 차이가 왜 생각보다 훨씬 크게 벌어지는지, 어떻게 하면 만드는 사람 쪽으로 한 걸음 옮길 수 있는지를 다룹니다.

이 글에서 말하는 "빌더"는 거창한 창업가나 천재 개발자를 뜻하지 않습니다. 무언가를 끝까지 만들어 세상에 내놓는 모든 사람입니다. 코드일 수도, 글일 수도, 작은 도구일 수도, 동아리 행사일 수도 있습니다. 핵심은 직군이 아니라 태도입니다.

소비자 vs 생산자 — 같은 시간, 다른 복리

우리는 콘텐츠의 황금기에 살고 있습니다. 무료 강의, 뉴스레터, 영상, 트위터 스레드가 무한히 흘러나옵니다. 문제는 이 풍요가 교묘한 함정을 동반한다는 점입니다. 소비는 즉각적인 만족감을 줍니다. "오, 이거 배웠어"라는 느낌이 들죠. 하지만 그 느낌은 실제 능력과 자주 일치하지 않습니다.

생산과 소비의 가장 큰 차이는 **복리의 방향**입니다.

| 구분 | 소비자 모드 | 생산자 모드 |

| --- | --- | --- |

| 주말의 결과물 | 머릿속 지식(휘발성) | 남는 산출물(저장됨) |

| 피드백 | 거의 없음 | 사용자/현실의 반응 |

| 실력 곡선 | 완만, 정체되기 쉬움 | 가파름, 막힐 때 성장 |

| 포트폴리오 | 쌓이지 않음 | 자동으로 쌓임 |

| 운(luck)의 표면적 | 좁음 | 넓음 |

| 1년 후 | 비슷한 자리 | 전혀 다른 자리 |

마지막 줄의 "운의 표면적(luck surface area)"이라는 표현이 핵심입니다. 만든 것을 세상에 내놓으면, 내가 예상하지 못한 방향에서 기회가 찾아옵니다. 누군가 내 도구를 쓰다가 채용 제안을 하고, 내 글을 읽은 사람이 협업을 제안합니다. 소비만 하면 이 표면적이 거의 0에 가깝습니다. 아무도 내가 무엇을 아는지 알 수 없으니까요.

오해는 마세요. 소비가 나쁜 것이 아닙니다. 좋은 입력 없이는 좋은 출력도 없습니다. 문제는 **비율**입니다. 입력만 하고 출력이 없으면, 그것은 학습이 아니라 수집입니다.

소비자 모드: 읽기 → 읽기 → 읽기 → 읽기 → (1년 뒤) 비슷함

생산자 모드: 읽기 → 만들기 → 막힘 → 찾아 읽기 → 만들기 → (1년 뒤) 다른 사람

만들다가 막혀서 찾아 읽는 지식은, 그냥 읽은 지식과 질이 다릅니다. 필요에 의해 들어온 지식은 맥락과 함께 박히기 때문입니다. 이것이 생산자 모드의 숨은 무기입니다. 생산은 학습을 강제하고, 강제된 학습은 오래 남습니다.

아이디어보다 실행 — "그거 내가 먼저 생각했는데"

빌더가 가장 자주 듣는 말이자, 가장 의미 없는 말이 있습니다. "그 아이디어 나도 예전에 생각했었어."

거의 모든 좋은 아이디어는 여러 사람의 머릿속에 동시에 존재합니다. 우버를 떠올린 사람, 배달 앱을 떠올린 사람, 똑같은 SaaS를 떠올린 사람은 수천 명이었습니다. 차이를 만든 건 떠올림이 아니라 **만들어 낸 사람**입니다.

이걸 거칠게 수식으로 표현하면 이렇습니다.

아이디어의 가치 ≈ 1

실행의 가치 ≈ 1,000

가치 = 아이디어 × 실행

= 1 × 1,000 = 1,000 (실행한 평범한 아이디어)

= 10 × 0 = 0 (실행 안 한 천재적 아이디어)

천재적인 아이디어에 0을 곱하면 0입니다. 평범한 아이디어라도 실행이 곱해지면 의미 있는 값이 됩니다. 그래서 빌더는 아이디어를 비밀로 감추지 않습니다. 오히려 떠벌립니다. 어차피 가치는 만드는 과정에서 생기기 때문입니다.

여기엔 심리적인 함정도 있습니다. 우리는 종종 아이디어를 더 다듬으려고 무한히 미룹니다. "조금만 더 완벽하게 설계하고 시작하자." 하지만 책상 위에서 다듬는 설계는 현실과 만나는 순간 절반이 틀렸음이 드러납니다. 실행은 그 틀린 절반을 빨리 발견하는 가장 효율적인 방법입니다.

> 완벽한 계획을 세운 뒤 실행하는 것이 아니라, 실행하면서 계획을 고쳐 나가는 것이 빌더의 방식입니다.

작게 시작해 출시하라 — 부끄러운 v1의 힘

빌더가 가장 먼저 배우는 기술은 "범위를 줄이는 법"입니다. 머릿속의 그림은 항상 거대합니다. 그 거대한 그림을 한 번에 만들려다 대부분의 프로젝트가 시작도 못 하고 죽습니다.

리드 호프먼(LinkedIn 창업자)의 유명한 말이 있습니다. "출시한 제품의 첫 버전이 부끄럽지 않다면, 너무 늦게 출시한 것이다." 이 말의 핵심은 대충 만들라는 게 아닙니다. **현실의 피드백을 받기 전까지는 무엇이 중요한지 알 수 없으니, 최대한 빨리 현실과 충돌하라**는 뜻입니다.

작게 시작하기의 실전 원칙은 이렇습니다.

- 첫 버전은 "하나의 일"만 제대로 하게 만듭니다. 기능 목록을 적었다면 80%를 지웁니다.

- "있으면 좋은 것"과 "없으면 안 되는 것"을 잔인하게 구분합니다.

- 출시 기준을 "완벽함"이 아니라 "한 명의 진짜 사용자가 쓸 수 있는가"로 잡습니다.

- 데드라인을 인위적으로 짧게 잡습니다. 주말 안에, 또는 2주 안에.

예를 들어 "팀의 모든 회의 노트를 자동으로 정리하고 검색하고 요약하는 시스템"을 만들고 싶다고 합시다. 이건 6개월짜리 프로젝트이고, 십중팔구 죽습니다. 빌더는 이렇게 쪼갭니다.

거대한 비전: 회의 노트 자동 수집 + 검색 + 요약 + 공유 + 알림 ...

↓ (80% 삭제)

v1 (주말): 폴더의 마크다운 파일을 읽어 한 줄 요약을 붙여 출력하는 스크립트

v2 (다음 주): 요약을 슬랙 채널에 자동으로 보냄

v3 (그 후): 검색 기능 추가

v1은 부끄러울 만큼 작습니다. 하지만 v1이 있으면 v2가 생기고, v2가 있으면 v3가 생깁니다. v1이 없으면 영원히 머릿속에만 있습니다. 작게 시작하는 것은 게으름이 아니라 가장 빠르게 무언가를 존재하게 만드는 전략입니다.

빠른 피드백 루프 — 빌더의 진짜 엔진

빌딩의 본질을 한 문장으로 줄이면 이렇습니다. **만들고 → 내놓고 → 반응을 보고 → 고친다.** 이 순환의 속도가 빌더의 성장 속도를 결정합니다.

루프가 빠를수록 좋은 이유는 단순합니다. 우리는 무엇이 맞는지 미리 알 수 없습니다. 추측을 검증하는 횟수가 곧 학습량입니다. 한 번의 큰 출시보다 열 번의 작은 출시가 더 많이 배웁니다.

느린 루프 (1년에 1번 출시)

설계 ──────────── 6개월 ──────────── 출시 ── 반응 ── 망함

빠른 루프 (2주에 1번 출시)

만들기 ─ 출시 ─ 반응 ─ 수정 ─ 출시 ─ 반응 ─ 수정 ─ 출시 ─ 반응 ...

└─ 같은 6개월 동안 12번 배움 ─┘

피드백 루프를 빠르게 만드는 구체적인 방법들이 있습니다.

- **배포를 자동화합니다.** 출시가 귀찮으면 출시 빈도가 줄어듭니다. 한 번의 명령, 한 번의 푸시로 배포되게 만듭니다.

- **사용자를 일찍 끌어들입니다.** 친구 한 명, 동료 한 명에게라도 보여줍니다. 진짜 사람의 한마디가 혼자 하는 백 번의 고민보다 낫습니다.

- **숫자를 봅니다.** 추측 대신 데이터를 봅니다. 몇 명이 들어왔고, 어디서 떠났는지.

- **고치기 쉬운 구조로 만듭니다.** 한 번 잘 설계하려고 6개월 쓰는 것보다, 빨리 만들고 자주 고치는 편이 낫습니다.

여기서 중요한 균형이 있습니다. 빠른 루프가 "대충 만들어 던지기"를 뜻하지는 않습니다. 핵심은 **검증할 수 있는 가장 작은 단위**로 자르는 것입니다. 큰 가설 하나를 6개월 만에 검증하는 대신, 작은 가설 열두 개를 2주마다 검증합니다.

무엇을 먼저 만들까 — 간단한 우선순위 프레임워크

"만들어라"는 말을 들으면 다음 질문이 곧장 따라옵니다. "그래서 뭘 먼저?" 머릿속에 떠다니는 아이디어가 열 개라면, 그중 무엇에 다음 주말을 걸어야 할까요. 거창한 점수표는 필요 없습니다. 세 가지 질문이면 충분합니다.

질문 1. 내가 직접 쓰는가? (사용자 = 나 이면 동기와 피드백이 공짜)

질문 2. 주말 안에 v1이 나오는가? (범위가 크면 시작 전에 죽는다)

질문 3. 끝내면 누군가 보게 되는가? (운의 표면적이 늘어나는가)

세 질문에 모두 "예"가 나오는 아이디어가 있다면, 더 고민하지 말고 그것부터 시작하세요. 셋 다 "예"인 프로젝트는 동기, 완결 가능성, 보상이 한 번에 갖춰진 보기 드문 조합입니다.

| 후보 | 내가 쓰는가 | 주말 v1 | 남에게 닿는가 | 판단 |

| --- | --- | --- | --- | --- |

| 내 회고 자동화 | 예 | 예 | 아마도 | 지금 시작 |

| 거대한 SaaS 플랫폼 | 아니오 | 아니오 | 예 | 잘라서 다시 |

| 새 언어로 토이 컴파일러 | 아니오 | 아니오 | 아니오 | 학습용으로만 |

| 동료가 겪는 불편 도구 | 가끔 | 예 | 예 | 좋은 후보 |

이 표의 교훈은 단순합니다. 가장 야심 찬 아이디어가 가장 좋은 첫 프로젝트인 경우는 거의 없습니다. 가장 좋은 첫 프로젝트는 **빨리 끝나고, 내가 쓰고, 남이 볼 수 있는** 작은 것입니다. 야심은 두 번째, 세 번째 프로젝트를 위해 아껴 두세요.

한 가지 덧붙이면, 이 세 질문은 사이드 프로젝트에만 쓰이는 게 아닙니다. 회사에서 "다음에 무엇을 개선할까"를 고를 때도 똑같이 작동합니다. 내가 매일 겪는 불편인가, 한 주 안에 첫 버전을 보여 줄 수 있는가, 끝내면 팀이 알아챌까. 빌더의 우선순위 감각은 직장과 사이드를 가리지 않습니다.

오너십 — "그건 제 일이 아니에요"의 반대말

빌더와 단순 실행자를 가르는 가장 분명한 선이 오너십입니다. 오너십은 직급이나 직함이 아니라 태도입니다. "이건 내가 책임지고 끝까지 만든다"는 마음입니다.

오너십이 있는 사람과 없는 사람의 대화를 비교해 보겠습니다.

| 상황 | 오너십 없는 반응 | 오너십 있는 반응 |

| --- | --- | --- |

| 버그 발견 | "이거 누가 만든 거예요?" | "제가 원인 찾아서 고쳐 둘게요." |

| 명세가 애매함 | "스펙이 불분명해서 못 했어요." | "이렇게 가정하고 진행했고, 맞는지 확인 부탁드려요." |

| 프로젝트 표류 | "방향이 안 잡혀서요." | "제가 초안 짜서 회의 잡았어요." |

| 출시 후 문제 | "QA가 못 잡았네요." | "제가 모니터링 붙이고 핫픽스 준비할게요." |

차이가 보이시나요. 오너십이 있는 사람은 문제를 자기 쪽으로 끌어당깁니다. 없는 사람은 문제를 밖으로 밀어냅니다. 흥미로운 점은, 오너십이 손해처럼 보이지만 사실 가장 빠른 성장 경로라는 것입니다. 책임을 지는 사람만이 전체 그림을 보게 되고, 전체 그림을 보는 사람만이 의사결정의 근육을 키웁니다.

오너십에는 한 가지 주의할 점이 있습니다. 모든 것을 혼자 짊어지라는 뜻이 아닙니다. 오히려 진짜 오너십은 "필요할 때 도움을 요청하는 것"까지 포함합니다. 막혔을 때 사흘을 혼자 끙끙대는 것은 오너십이 아니라 고집입니다. 결과에 책임지되, 과정에서는 영리하게 도움을 끌어오는 것이 성숙한 오너십입니다.

AI 시대의 빌더 — 만들기의 문턱이 무너졌다

지난 몇 년 사이 가장 큰 변화는, 만드는 데 필요한 기술의 문턱이 극적으로 낮아졌다는 점입니다. 예전에는 아이디어를 형태로 만들려면 몇 달의 학습이 필요했습니다. 지금은 자연어로 설명하면 초안이 나옵니다.

이 변화의 의미를 두 가지로 정리할 수 있습니다.

첫째, **진입 장벽이 낮아졌습니다.** 디자이너가 간단한 앱을 만들고, 마케터가 자동화 스크립트를 짜고, 학생이 주말에 서비스를 출시합니다. "나는 개발자가 아니라서"라는 변명의 유효기간이 끝나가고 있습니다.

둘째, 그래서 역설적으로 **빌더 마인드셋이 더 중요해졌습니다.** 도구가 코드를 대신 써 주는 시대에는, 무엇을 만들지 결정하고, 끝까지 밀어붙이고, 현실의 피드백으로 다듬는 능력이 차별점이 됩니다. AI는 "어떻게"의 비용을 낮췄지만 "무엇을, 왜"는 여전히 사람의 몫입니다.

| 시대 | 희소했던 것 | 흔해진 것 |

| --- | --- | --- |

| 과거 | 기술 구현 능력 | 아이디어 |

| 지금 | 판단력, 취향, 완결성 | 구현 능력 |

여기에 함정도 있습니다. 도구가 쉬워지면 "만든 것 같은 느낌"도 쉽게 듭니다. 데모를 하나 돌려 보고 다 만든 기분이 드는 거죠. 하지만 데모와 출시된 제품 사이에는 여전히 거대한 골짜기가 있습니다. 그 골짜기를 건너는 사람이 빌더입니다. AI는 첫 90%를 빠르게 해 주지만, 진짜 가치가 있는 마지막 10%는 여전히 사람의 끈기를 요구합니다.

끝까지 만들기 — 90%에서 죽는 프로젝트들

빌더와 아마추어를 가르는 가장 잔인한 지점이 여기 있습니다. 시작은 누구나 합니다. 멋진 아이디어로 첫 주말을 불태우는 건 쉽습니다. 어려운 건 **재미없어진 마지막 10%를 끝내는 것**입니다.

프로젝트의 매력 곡선은 대체로 이렇게 생겼습니다.

재미

▲

│ ●●● ← 시작: 모든 게 신남

│ ●●

│ ●● ← 중반: 현실의 자잘한 문제들

│ ●●●●● ← 마지막 10%: 에러 처리, 문서, 마무리 (지루함)

│ ● ← 출시!

└──────────────────────────────▶ 시간

마지막 10%는 화려하지 않습니다. 엣지 케이스 처리, 에러 메시지 다듬기, 배포 설정, 사용 안내 작성 같은 일들입니다. 새 프로젝트의 반짝이는 아이디어가 자꾸 유혹합니다. "이것보다 저게 더 멋질 것 같은데?" 그렇게 90%짜리 시체가 폴더마다 쌓입니다.

끝까지 만드는 사람이 되기 위한 실전 팁입니다.

- **공개적으로 약속합니다.** "이번 달 말까지 출시하겠다"고 사람들 앞에서 말합니다. 약속은 끈기를 빌려줍니다.

- **출시를 작은 단위로 정의합니다.** "완성"이 아니라 "이 정도면 한 명은 쓸 수 있다"를 기준으로 일단 내놓습니다.

- **새 아이디어는 적어만 둡니다.** 끝내기 전에는 시작하지 않습니다. 아이디어 목록은 끝낸 다음의 보상입니다.

- **마지막 10%를 미리 예상합니다.** "다 됐다"고 느낄 때가 사실 절반쯤 온 지점임을 기억합니다.

끝까지 만들어 본 경험은 그 자체로 자산입니다. 하나를 끝까지 만들어 본 사람은 다음 것을 끝낼 확률이 훨씬 높습니다. 완결의 근육은 완결을 통해서만 자랍니다.

사이드 프로젝트 — 가장 안전한 실험실

회사 일로 빌더 근육을 키우긴 어렵습니다. 회사에서는 실패가 비싸고, 범위가 정해져 있고, 처음부터 끝까지 한 사람이 책임지는 경우가 드뭅니다. 그래서 사이드 프로젝트가 중요합니다. 사이드 프로젝트는 **실패해도 안전한 실험실**입니다.

사이드 프로젝트의 진짜 가치는 결과물 자체보다 다음에 있습니다.

- 처음부터 끝까지 혼자 책임지는 경험. 회사에서는 좀처럼 얻기 힘든 경험입니다.

- 회사에서는 못 써 보는 새 기술을 마음껏 시도해 보는 자유.

- 운의 표면적 확대. 내가 만든 것이 어디서 누구에게 닿을지 모릅니다.

- 일이 재미없어질 때 나를 지켜 주는 "내 것"의 감각.

다만 사이드 프로젝트에도 흔한 실패 패턴이 있습니다.

| 실패 패턴 | 증상 | 처방 |

| --- | --- | --- |

| 거창병 | 첫 프로젝트가 너무 큼 | 주말에 끝낼 크기로 줄이기 |

| 도구 수집병 | 만들기 전에 설정만 함 | 익숙한 도구로 바로 시작 |

| 비공개병 | 완벽해질 때까지 숨김 | 부끄러워도 일찍 공개 |

| 변심병 | 매주 새 프로젝트 | 하나를 끝낼 때까지 금지 |

가장 좋은 첫 사이드 프로젝트는 "내가 직접 겪는 불편함"을 푸는 것입니다. 내가 사용자이면 피드백 루프가 즉각적이고, 동기가 떨어지지 않습니다. 거창한 시장 조사보다 "내가 매주 짜증 나는 그 일"이 훨씬 좋은 출발점입니다.

처음부터 끝까지 — 작은 사이드 프로젝트 한 바퀴

말로만 "작게 시작하라"고 하면 와닿지 않습니다. 그래서 아주 작은 프로젝트 하나가 머릿속의 짜증에서 출시까지 가는 과정을 그대로 따라가 보겠습니다.

상황은 이렇습니다. 저는 매주 월요일 아침마다 지난주에 닫힌 깃 저장소의 이슈들을 손으로 모아 회고 노트에 붙여 넣고 있었습니다. 매번 10분, 한 달이면 40분, 무엇보다 지루했습니다. 전형적인 "내가 매주 짜증 나는 그 일"입니다.

먼저 v1의 범위를 잔인하게 줄였습니다. 검색도, 웹 UI도, 설정 화면도 없습니다. "지난 7일간 닫힌 이슈 제목을 한 줄씩 출력"만 합니다. 그게 전부입니다.

v1: 30분 안에 돌아가게 만드는 것이 목표

mkdir weekly-recap && cd weekly-recap

gh issue list --state closed --limit 50 --json title,closedAt > issues.json

그다음 닫힌 날짜로 거른 뒤 제목만 뽑는 짧은 스크립트를 붙였습니다. 익숙한 도구로, 새로 배우지 않고.

from datetime import datetime, timedelta, timezone

cutoff = datetime.now(timezone.utc) - timedelta(days=7)

with open("issues.json") as f:

issues = json.load(f)

for it in issues:

closed = datetime.fromisoformat(it["closedAt"].replace("Z", "+00:00"))

if closed >= cutoff:

print("- " + it["title"])

토요일 밤, 이게 돌아갔습니다. 부끄러울 만큼 단순했지만 분명히 "존재"했습니다. 머릿속에만 있던 것이 처음으로 폴더 안에 생긴 순간입니다.

여기서 끝내지 않고 루프를 한 바퀴 돌렸습니다. 동료 한 명에게 보여 줬더니 첫 피드백이 즉시 왔습니다. "제목만 있으니 어떤 게 중요한지 모르겠는데, 링크도 있으면 좋겠어." 혼자 백 번 고민해도 안 나왔을 한마디였습니다.

v1 (토요일 밤): 지난 7일 닫힌 이슈 제목을 출력

↓ 동료 피드백: "링크도 필요해"

v2 (일요일): 제목 + 링크를 마크다운으로 출력, 클립보드로 복사

↓ 내 피드백: "매주 명령어 치는 것도 귀찮네"

v3 (다음 주말): 월요일 아침마다 자동 실행되도록 예약

핵심은 코드가 아닙니다. **머릿속 짜증 → 부끄러운 v1 → 한 명의 피드백 → 다음 버전**으로 이어지는 한 바퀴가 돌았다는 것입니다. 이 한 바퀴를 돌고 나면, 두 번째 프로젝트는 거짓말처럼 가벼워집니다. 무거운 것은 언제나 첫 바퀴입니다.

이 예시에서 주목할 것은 "안 한 것들"입니다. 저는 데이터베이스를 붙이지 않았고, 로그인을 만들지 않았고, 화면을 그리지 않았고, 다른 깃 서비스도 지원하지 않았습니다. 그 모든 것은 "있으면 좋은 것"이었고, v1에는 단 하나도 들어가지 않았습니다. 빌더의 절제는 무엇을 넣느냐가 아니라 무엇을 빼느냐에서 드러납니다. 작게 끝낸 프로젝트 하나가, 거대하게 시작해 멈춘 프로젝트 열 개보다 당신을 더 멀리 데려갑니다.

멘토와의 대화 — 코드 리뷰에서 배운 것

빌더 마인드셋은 글로만 배우기 어렵습니다. 종종 한 번의 짧은 대화가 책 한 권보다 많은 것을 바꿉니다. 제가 주니어였을 때, 한 시니어와 나눈 코드 리뷰 대화를 옮겨 봅니다. (기억을 재구성한 것입니다.)

주니어: "이 기능, 아직 출시 못 하겠어요. 엣지 케이스가 다섯 개나 남았고 코드도 더 깔끔하게 정리하고 싶어서요."

시니어: "그 다섯 개 중에 실제 사용자가 이번 주에 마주칠 게 몇 개죠?"

주니어: "음... 솔직히 하나? 나머지는 거의 안 일어날 것 같아요."

시니어: "그럼 하나만 막고 나머지 넷은 주석으로 '알려진 한계'라고 적어 두고 내보내죠. 안 일어나는 문제를 미리 푸는 건 도박이에요. 진짜 어떤 게 터지는지는 사용자가 알려줄 거예요."

주니어: "그래도 코드가 부끄러운데요."

시니어: "부끄러운 게 정상이에요. 6개월 뒤에 이 코드를 보고 부끄럽지 않다면, 그동안 안 자란 거예요. 지금 할 일은 완벽한 코드가 아니라, 내일 누군가 쓸 수 있는 코드예요."

이 대화에서 저는 두 가지를 배웠습니다. 첫째, 완벽주의는 종종 두려움의 가면이라는 것. "더 다듬고 싶다"는 말 뒤에는 "현실의 평가가 무섭다"가 숨어 있을 때가 많습니다. 둘째, 좋은 멘토는 답을 주는 사람이 아니라 **질문의 범위를 줄여 주는 사람**이라는 것. "다섯 개 중 몇 개가 진짜냐"는 질문 하나가 막힌 저를 움직이게 했습니다.

> 좋은 코드 리뷰는 코드를 고치는 자리가 아니라, 무엇을 고치지 않아도 되는지 합의하는 자리입니다.

그날 저는 그 기능을 "알려진 한계" 주석 네 줄과 함께 내보냈습니다. 그리고 한 달 동안 그 넷 중 단 하나도 실제로 문제가 되지 않았습니다. 제가 막으려던 것은 일어나지 않을 미래였고, 시니어가 막아 준 것은 영영 출시 못 할 현재였습니다. 그 뒤로 저는 "완벽해질 때까지"라는 말이 입에서 나오려 할 때마다, 그 질문을 스스로에게 던집니다. "지금 막으려는 이 문제, 진짜 이번 주에 일어나는가?"

구체 사례 — 만들기가 만든 차이들

추상적인 이야기가 길었으니, 만들기가 실제로 어떤 차이를 만드는지 몇 가지 패턴으로 보겠습니다. (특정 개인이 아니라 자주 보이는 유형을 묶은 것입니다.)

**사례 1. 내부 도구가 표준이 된 개발자.** 팀원들이 반복하던 수작업을 보다 못해 주말에 작은 스크립트를 만들었습니다. 처음엔 본인만 썼지만, 동료에게 보여 주자 다들 쓰기 시작했고, 결국 팀의 공식 도구가 되었습니다. 그 사람은 "도구를 만든 사람"으로 자리 잡았고, 자연스럽게 더 큰 결정에 참여하게 되었습니다. 시작은 30줄짜리 스크립트였습니다.

**사례 2. 블로그가 커리어가 된 사람.** 배운 것을 정리해 꾸준히 글로 남긴 사람이 있었습니다. 처음 6개월은 방문자가 거의 없었습니다. 하지만 1년이 지나자 그 글들이 검색에 노출되기 시작했고, 그 글을 읽은 회사에서 면접 제안이 왔습니다. 글쓰기도 명백한 빌딩입니다. 머릿속의 것을 밖으로 꺼내 남기는 행위니까요.

**사례 3. 주말 프로젝트가 부업이 된 경우.** 본인이 겪던 불편을 풀려고 만든 작은 도구를 공개했더니, 같은 불편을 겪던 사람들이 돈을 내고 쓰기 시작했습니다. 거대한 사업 계획이 있었던 게 아닙니다. 그냥 "내 문제"를 풀어 내놓았을 뿐입니다.

이 사례들의 공통점은 두 가지입니다. 첫째, 시작이 모두 **작았다**는 것. 둘째, 머릿속에 머물지 않고 **세상에 나왔다**는 것. 거창한 계획이 아니라 작은 출시가 차이를 만들었습니다.

시작 가이드 — 다음 주말에 무엇을 할까

여기까지 읽고 "그래서 뭘 만들지?"가 막막하다면, 구체적인 출발선을 드리겠습니다.

**1단계: 불편 목록 만들기 (15분)**

이번 주에 "아, 이거 좀 짜증 나네"라고 느낀 순간을 다섯 개 적습니다. 반복되는 수작업, 매번 까먹는 것, 찾기 귀찮은 정보 같은 것들입니다. 가장 좋은 프로젝트는 여기서 나옵니다.

**2단계: 가장 작은 하나 고르기 (5분)**

다섯 개 중 "주말 안에 흉내라도 낼 수 있을 것 같은" 하나를 고릅니다. 큰 걸 고르고 싶은 유혹을 참습니다.

**3단계: v1 정의하기 (10분)**

그 하나를 "한 가지 일만 하는" 형태로 줄입니다. 기능을 적었다면 80%를 지웁니다. 남은 것이 v1입니다.

**4단계: 일단 만들기 (주말)**

완벽하지 않아도 됩니다. 익숙한 도구로 시작합니다. 새 도구 배우는 것은 다음으로 미룹니다. 목표는 "토요일 밤에 돌아가는 무언가"입니다.

**5단계: 한 명에게 보여 주기 (10분)**

완성도와 무관하게 친구나 동료 한 명에게 보여 줍니다. 첫 피드백 루프를 닫는 순간, 당신은 이미 소비자에서 생산자로 넘어왔습니다.

빌더 시작 체크리스트

[ ] 이번 주 불편 5개를 적었다

[ ] 그중 가장 작은 1개를 골랐다

[ ] 기능의 80%를 지우고 v1을 정의했다

[ ] 익숙한 도구로 일단 시작했다

[ ] 완벽하지 않은 상태로 한 명에게 보여 줬다

[ ] 새 아이디어는 적어만 두고 이걸 먼저 끝낸다

중요한 것은 규모가 아니라 **루프를 한 바퀴 도는 것**입니다. 작더라도 만들고 → 내놓고 → 반응을 받는 한 바퀴를 끝내면, 그 다음은 훨씬 쉬워집니다. 첫 바퀴가 가장 무겁습니다.

그런데 말입니다 — 흔한 반론들

빌더 마인드셋 이야기를 하면 거의 항상 같은 반론들이 돌아옵니다. 무시하지 않고 하나씩 정직하게 답해 보겠습니다.

**"시간이 없어요."** 가장 흔하고, 가장 진심인 반론입니다. 답은 "시간을 내라"가 아닙니다. 빌딩은 비어 있는 주말 이틀을 요구하지 않습니다. 하루 30분, 일주일에 두세 번이면 충분히 한 바퀴를 돕니다. 문제는 시간의 총량이 아니라, 그 30분을 소비가 아니라 생산에 쓰느냐입니다. 넷플릭스 한 편이면 v1이 하나 나옵니다.

**"제 아이디어는 이미 누가 만들었어요."** 좋은 신호입니다. 누군가 만들었다는 건 수요가 있다는 증거이니까요. 검색, 메모, 채팅 앱 — 세상에 처음 나온 카테고리는 거의 없지만 계속 새 제품이 성공합니다. 차이는 아이디어가 아니라 실행의 디테일에서 납니다. "이미 있다"는 출발하지 말아야 할 이유가 아니라, 무엇을 다르게 할지 고민할 이유입니다.

**"못 만들면 창피할 것 같아요."** 이건 솔직하게 인정합시다. 창피합니다. 하지만 아무도 당신의 v1을 당신만큼 오래 기억하지 않습니다. 사람들은 자기 일로 바쁩니다. 그리고 "공개적으로 시도하고 다듬는 사람"에 대한 세상의 평가는, 생각보다 훨씬 너그럽습니다. 진짜 위험은 창피가 아니라, 아무도 모르게 사라지는 것입니다.

**"실력이 부족해서 더 배운 다음에 시작하려고요."** 가장 위험한 반론입니다. "준비가 되면"이라는 조건은 영원히 충족되지 않기 때문입니다. 실력은 만들기 전에 채워 넣는 게 아니라, 만들면서 채워지는 것입니다. 막혀서 찾아 읽은 지식이 가장 오래 남는다는 것을 기억하세요. 시작이 곧 학습 계획입니다.

**"회사 일만으로도 벅차요."** 그렇다면 회사 일 자체를 빌딩의 장으로 바꾸는 편이 낫습니다. 사이드 프로젝트가 필수는 아닙니다. 반복되는 수작업 하나를 자동화하고, 애매한 명세를 먼저 정리하고, 아무도 안 만드는 작은 도구를 만드는 것 — 이 모두가 빌딩입니다. 빌더 마인드셋은 별도의 시간이 아니라, 같은 시간을 대하는 태도입니다.

**"끝까지 만들 자신이 없어요."** 정직한 두려움입니다. 그래서 첫 프로젝트는 일부러 우습게 작아야 합니다. 끝낼 자신이 없다면, 그건 프로젝트가 너무 크다는 신호입니다. "30분 안에 돌아갈 무언가"로 줄이면, 끝내지 못할 이유가 사라집니다. 완결의 근육은 거대한 한 번이 아니라, 작은 완결을 여러 번 반복하면서 자랍니다. 작게 끝내는 연습이 곧 크게 끝내는 능력의 토대입니다.

이 반론들을 관통하는 공통점이 있습니다. 대부분 사실이지만, 대부분 시작하지 않을 이유는 아니라는 것입니다. 반론은 보통 진짜 장애물이 아니라, 시작의 두려움이 입은 합리적인 옷입니다.

그래서 반론이 떠오를 때 던질 좋은 질문이 하나 있습니다. "이건 시작을 막는 진짜 벽인가, 아니면 시작하지 않아도 되게 해 주는 변명인가?" 진짜 벽이라면 우회로를 찾으면 됩니다. 범위를 줄이고, 도구를 바꾸고, 시간대를 옮기면 됩니다. 하지만 변명이라면, 그것을 정직하게 변명이라 부르는 순간 힘이 빠집니다. 빌더는 반론을 무시하지 않습니다. 다만 반론을 핑계가 아니라 풀어야 할 또 하나의 문제로 다룹니다.

균형 — 빌더의 가장 흔한 함정, 번아웃

여기까지 읽으면 "그래, 무조건 만들어야지!"라는 의욕이 솟을 수 있습니다. 그래서 이 글은 가장 중요한 경고로 마무리하려 합니다. **지속 가능하지 않은 빌딩은 빌딩이 아니라 소진입니다.**

빌더 문화에는 위험한 신화가 있습니다. "주 100시간 일하고, 잠은 죽어서 자고, 모든 주말을 갈아 넣어라." 이런 서사는 멋져 보이지만, 대부분 끝이 좋지 않습니다. 번아웃은 빌더의 가장 흔한 사망 원인입니다. 한 번 크게 타오르고 식어 버린 사람보다, 작게 꾸준히 타는 사람이 결국 더 멀리 갑니다.

빌딩은 단거리 경주가 아니라 마라톤입니다. 복리는 시간이 필요하고, 시간을 벌려면 살아남아야 합니다. 지속 가능한 페이스를 위한 원칙들입니다.

- **작게, 자주.** 한 달에 몰아서 80시간보다, 매주 4시간씩 꾸준히가 낫습니다. 복리는 빈도를 좋아합니다.

- **끝을 정해 둡니다.** "주말 안에"처럼 시한을 정하면 무한정 갈아 넣는 것을 막을 수 있습니다.

- **쉬는 것을 죄책감 없이.** 쉼은 게으름이 아니라 다음 라운드를 위한 투자입니다.

- **재미를 지킵니다.** 사이드 프로젝트가 또 하나의 의무가 되면 본래 의미를 잃습니다. 재미없어지면 잠시 멈추거나 바꿉니다.

- **몸을 챙깁니다.** 잠, 운동, 사람. 이것들이 무너지면 어떤 결과물도 의미가 없습니다.

> 가장 생산적인 빌더는 가장 오래 일하는 사람이 아니라, 가장 오래 *계속* 일하는 사람입니다.

만드는 것과 자신을 소진하는 것은 다릅니다. 진짜 빌더 마인드셋은 "더 많이, 더 빨리"가 아니라 "꾸준히, 오래"에 가깝습니다.

마치며 — 만드는 사람으로 산다는 것

다시 처음의 A와 B로 돌아가 봅니다. 두 사람을 가른 것은 재능도, 시간도, 운도 아니었습니다. 토요일 오후에 무언가를 설치하고, 망가뜨리고, 작은 것을 만들어 본 그 작은 습관이었습니다.

빌더 마인드셋의 핵심을 한 문장으로 줄이면 이렇습니다. **세상을 읽기만 하는 대신, 세상에 무언가를 더하는 사람으로 사는 것.** 그 무언가는 거창할 필요가 없습니다. 30줄짜리 스크립트, 한 편의 글, 작은 도구 하나면 충분합니다.

이 글도 결국 하나의 출력입니다. 읽기만 하셨다면, 이 글은 또 하나의 소비일 뿐입니다. 다음 주말, 아주 작은 무언가 하나를 끝까지 만들어 세상에 내놓을 때 — 그때 비로소 이 글은 의미를 갖습니다.

작은 제안 하나로 마무리하겠습니다. 이 글을 닫은 뒤, 다른 탭을 열어 또 다른 글을 읽지 마세요. 대신 메모 앱을 열고 이번 주에 짜증 났던 일 다섯 개를 적으세요. 그 5분이, 읽는 사람과 만드는 사람을 가르는 첫걸음입니다. 거창한 결심도, 완벽한 계획도 필요 없습니다. 필요한 것은 그저 한 줄을 적고, 다음 주말에 그중 가장 작은 하나를 손으로 만져 보는 것뿐입니다.

만드는 사람이 세상을 바꿉니다. 그리고 그 "만드는 사람"은 거창한 누군가가 아니라, 다음 주말의 당신일 수 있습니다. 세상은 더 많은 독자를 필요로 하지 않습니다. 세상은 더 많은, 끝까지 만드는 사람을 기다립니다.

참고 자료

- Paul Graham, "How to Do Great Work" — [https://paulgraham.com/greatwork.html](https://paulgraham.com/greatwork.html)

- Paul Graham, "Maker's Schedule, Manager's Schedule" — [https://paulgraham.com/makersschedule.html](https://paulgraham.com/makersschedule.html)

- Reid Hoffman, "If You're Not Embarrassed By the First Version, You've Launched Too Late" — [https://www.linkedin.com/pulse/20130829003652-1213-six-lessons-i-learned-the-hard-way-about-scaling-a-startup/](https://www.linkedin.com/pulse/20130829003652-1213-six-lessons-i-learned-the-hard-way-about-scaling-a-startup/)

- Carol Dweck, "Mindset: The New Psychology of Success" (book) — [https://www.penguinrandomhouse.com/books/44330/mindset-by-carol-s-dweck-phd/](https://www.penguinrandomhouse.com/books/44330/mindset-by-carol-s-dweck-phd/)

- Will Larson, "An Elegant Puzzle" and essays — [https://lethain.com/](https://lethain.com/)

- StaffEng, "Stories of reaching Staff-plus engineering roles" — [https://staffeng.com/](https://staffeng.com/)

- Amy Edmondson on psychological safety — [https://hbr.org/2023/02/what-is-psychological-safety](https://hbr.org/2023/02/what-is-psychological-safety)

- Harvard Business Review, "The Power of Small Wins" — [https://hbr.org/2011/05/the-power-of-small-wins](https://hbr.org/2011/05/the-power-of-small-wins)

- Cal Newport, "Deep Work" (book) — [https://www.calnewport.com/books/deep-work/](https://www.calnewport.com/books/deep-work/)

- Jack Butcher, "Build Once, Sell Twice" / Visualize Value — [https://visualizevalue.com/](https://visualizevalue.com/)