시작하기 전에
저는 한동안 "열심히 하는데 결과가 없는" 상태로 살았습니다. 노트는 가득 찼고, 아이디어 목록은 길었고, 읽은 책도 많았는데, 정작 세상에 내보낸 것은 거의 없었습니다. 어느 날 동료가 무심코 던진 한마디가 오래 남았습니다.
"너는 준비를 정말 많이 하는데, 끝내는 걸 본 적이 없어."
기분이 상했지만 사실이었습니다. 저는 결과물을 내는 사람이 아니라 결과물을 준비하는 사람이었습니다. 이 글은 그 이후로 몇 년간 제가 결과물을 꾸준히 내보내기 위해 만들고 다듬은 시스템을 정리한 것입니다. 동기부여 이야기는 최소화하고, 실제로 손에 잡히는 방법과 사례, 체크리스트 위주로 적었습니다.
먼저 한 가지 짚고 갑니다. 이 글에서 말하는 "Output(산출물)"은 거창한 것이 아닙니다. 블로그 글 한 편, 작동하는 프로토타입, 발표 슬라이드, 머지된 PR, 출시한 기능, 보낸 제안서. 누군가가 보고 평가할 수 있는 형태로 세상에 나온 것이라면 무엇이든 산출물입니다. 핵심은 "내 머릿속"이 아니라 "내 밖"에 존재하느냐입니다.
1. 완벽주의 vs 출시: 진짜 문제는 따로 있다
완벽주의는 흔히 "높은 기준" 때문이라고 오해받습니다. 제 경험상 진짜 원인은 다른 데 있습니다. 바로 평가에 대한 두려움입니다. 내보내지 않으면 평가받지 않고, 평가받지 않으면 실패하지 않습니다. 완벽주의는 사실 실패를 무한히 연기하는 정교한 전략입니다.
이걸 인정하면 해법의 방향이 바뀝니다. "기준을 낮추자"가 아니라 "평가받는 빈도를 높이자"가 됩니다. 작게, 자주 내보내서 평가를 잘게 쪼개면, 한 번의 평가가 주는 두려움이 작아집니다.
다음은 두 가지 사고방식의 차이입니다.
| 항목 | 완벽주의 모드 | 출시 모드 |
| --- | --- | --- |
| 목표 | 흠 없는 결과물 | 평가 가능한 결과물 |
| 피드백 시점 | 다 끝난 뒤 한 번 | 자주, 일찍, 여러 번 |
| 실패의 의미 | 자기 가치의 부정 | 정보의 한 조각 |
| 시간 감각 | 무한 (언젠가) | 유한 (이번 주) |
| 전형적 결과 | 미완성 더미 | 불완전하지만 존재하는 것 |
완벽주의를 "꼼꼼함"과 혼동하지 마세요. 꼼꼼함은 내보낸 다음에도 발휘할 수 있습니다. 완벽주의는 내보내기 전에 모든 것을 끝내려다 아무것도 내보내지 못합니다.
작은 실험: 의도적으로 70점짜리 내보내기
한 달 동안 저는 "70점이면 무조건 내보낸다"는 규칙을 세웠습니다. 블로그 글이든 코드든, 스스로 70점이라고 느끼면 더 만지지 않고 공개했습니다. 결과는 두 가지였습니다. 첫째, 세상은 무너지지 않았습니다. 둘째, 70점에 받은 피드백이 혼자 90점을 향해 갈 때보다 훨씬 정확했습니다. 혼자 상상한 90점은 대부분 엉뚱한 방향이었습니다.
2. 작게 쪼개기: 끝낼 수 있는 크기로 줄이기
산출물이 안 나오는 가장 흔한 이유는 단위가 너무 크기 때문입니다. "앱을 만든다"는 끝낼 수 있는 단위가 아닙니다. "로그인 화면 UI를 그린다"는 끝낼 수 있는 단위입니다.
쪼개기의 기준은 단 하나입니다. 한 번 앉은 자리에서 끝낼 수 있는가. 보통 저는 한두 시간 안에 완료 가능한 크기까지 잘게 나눕니다. 그보다 크면 다시 쪼갭니다.
Anne Lamott는 책 "Bird by Bird"에서 어린 동생이 새 보고서를 앞두고 막막해할 때 아버지가 한 말을 인용합니다. "한 마리씩, 그냥 새 한 마리씩 하면 돼." 코끼리를 통째로 삼킬 수는 없습니다. 한 입씩 잘라야 합니다.
다음은 큰 목표를 끝낼 수 있는 단위로 쪼개는 예시입니다.
큰 목표: "개인 블로그를 만든다"
|
v (쪼개기 1차 — 하루 단위)
+-- Next.js 프로젝트 생성 + 첫 배포
+-- 글 목록 페이지
+-- 글 상세 페이지
+-- 다크 모드
|
v (쪼개기 2차 — 두 시간 단위)
"글 목록 페이지"
+-- 더미 데이터로 목록 렌더링
+-- 마크다운 파일 읽어오기
+-- 날짜순 정렬
+-- 태그 필터
쪼개고 나면 가장 작은 한 조각부터 끝냅니다. 순서는 중요하지 않습니다. 중요한 것은 "오늘 끝낸 조각이 하나 있다"는 사실입니다.
쪼개기가 막힐 때의 신호
쪼개려 하는데도 "이건 못 쪼개겠다"는 느낌이 들면, 보통은 두 가지 중 하나입니다. 첫째, 아직 무엇을 만들지 모릅니다. 이 경우 "30분 동안 손으로 종이에 화면을 그린다" 같은 탐색 과제로 바꿉니다. 둘째, 한 조각 안에 여러 개가 섞여 있습니다. 동사가 두 개 이상이면 (예: "설계하고 구현한다") 쪼갤 수 있다는 뜻입니다.
3. 데드라인과 타임박스: 시간에 일을 맞추기
Parkinson의 법칙은 이렇게 말합니다. "일은 주어진 시간을 모두 채우도록 팽창한다." 마감이 일주일이면 일주일이 걸리고, 한 달이면 한 달이 걸립니다. 그렇다면 의도적으로 시간을 줄이면 일도 줄어듭니다.
타임박스는 "이 일을 끝낼 때까지 한다"가 아니라 "이 일에 90분만 쓴다"로 바꾸는 기법입니다. 시간이 끝나면 완성도와 무관하게 멈추고, 그 시점의 상태를 산출물로 봅니다.
저는 글 쓰기에 이 방식을 씁니다.
타임박스 예시 — 블로그 글 한 편
09:00-09:25 개요와 뼈대 (포모도로 1)
휴식 5분
09:30-09:55 본문 초안 절반 (포모도로 2)
휴식 5분
10:00-10:25 본문 초안 나머지 (포모도로 3)
휴식 5분
10:30-10:55 다듬기 + 발행 버튼 (포모도로 4)
규칙: 10:55에 무조건 발행한다. 다 못 써도 그 상태로 낸다.
포모도로 기법(25분 집중 + 5분 휴식)은 단순하지만 강력합니다. 25분이라는 작은 단위가 "시작"의 장벽을 낮추기 때문입니다. 우리는 보통 일 자체보다 "시작"을 두려워합니다. 25분만 하면 된다고 생각하면 의자에 앉기가 쉬워집니다.
데드라인은 외부에 있을수록 강하다
스스로 정한 데드라인은 스스로 옮길 수 있습니다. 가장 강한 데드라인은 다른 사람이 알고 있는 데드라인입니다. "금요일까지 보낼게요"라고 누군가에게 말한 순간, 그 데드라인은 갑자기 무게를 갖습니다. 이것이 다음 절의 공개 약속으로 이어집니다.
4. 80/20: 가치의 대부분은 일부에서 나온다
파레토 법칙(80/20 법칙)은 결과의 80%가 원인의 20%에서 나온다는 경험칙입니다. 산출물 관점에서 이것은 매우 실용적인 도구가 됩니다. 결과물의 핵심 가치를 만드는 20%를 먼저 끝내면, 나머지 80%의 시간을 들이기 전에 이미 내보낼 수 있습니다.
문제는 그 20%를 식별하는 일입니다. 저는 이렇게 묻습니다. "이것만 있고 나머지가 다 없어도 누군가에게 쓸모가 있는가?" 이 질문에 "예"라고 답할 수 있는 가장 작은 덩어리가 핵심 20%입니다.
| 만드는 것 | 핵심 20% (먼저) | 나중의 80% |
| --- | --- | --- |
| 블로그 | 글 한 편을 읽을 수 있는 페이지 | 댓글, 검색, 추천 |
| 발표 | 핵심 메시지 3장 슬라이드 | 애니메이션, 디자인 통일 |
| 사이드 앱 | 핵심 기능 하나가 작동 | 설정, 온보딩, 다크모드 |
| 제안서 | 문제와 해결책 한 페이지 | 부록, 상세 일정표 |
80/20을 핑계로 대충 하라는 뜻이 아닙니다. 핵심 20%는 오히려 더 잘해야 합니다. 다만 핵심이 아닌 80%에 완벽주의를 쏟지 말라는 뜻입니다.
5. 공개 약속: 도망갈 길을 줄이기
행동을 바꾸는 가장 저렴하고 강력한 방법 중 하나는 공개적으로 약속하는 것입니다. 우리는 일관성을 유지하려는 강한 본능이 있어서, 말한 것과 행동이 어긋나면 불편함을 느낍니다. 이 불편함을 산출물을 내는 연료로 씁니다.
저는 새 프로젝트를 시작할 때 의도적으로 "되돌리기 어려운 약속"을 만듭니다. 예를 들면 이렇습니다.
- 발표 일정을 먼저 잡는다. 내용이 준비되기 전에 행사 날짜부터 확정합니다.
- "다음 주 화요일에 데모 보여줄게"라고 팀에 말한다.
- 연재 글이라면 1편을 올리면서 "매주 수요일 연재"라고 박아둔다.
- 스터디 모임에서 "다음 시간에 제가 만든 거 발표할게요"라고 자원한다.
공개 약속에는 부작용도 있습니다. 너무 큰 약속을 공개하면 부담에 눌려 오히려 시작을 미루게 됩니다. 그래서 약속의 크기는 "조금 무섭지만 도망치고 싶을 정도는 아닌" 수준으로 조절합니다.
약속 대상의 강도
약함 ----------------------------------------> 강함
혼자 일기에 적기
< 친한 친구에게 말하기
< 팀 채널에 적기
< 공개 트윗/블로그로 선언
< 행사 일정 확정 (취소 시 타인에게 피해)
오른쪽으로 갈수록 강하지만 그만큼 부담도 큽니다. 처음에는 가운데쯤에서 시작하는 것을 권합니다.
6. 끝내는 힘: 마지막 10%가 진짜 어렵다
일의 처음 90%는 시간의 절반을 쓰고, 마지막 10%가 나머지 절반을 씁니다. 이건 농담이 아니라 거의 법칙입니다. 그리고 산출물을 내느냐 마느냐는 거의 항상 이 마지막 10%에서 갈립니다.
마지막 10%가 어려운 이유는 그것이 "재미없는 일"이기 때문입니다. 새 기능을 만드는 것은 신나지만, 버그를 잡고, 엣지 케이스를 처리하고, 문서를 쓰고, 배포 설정을 맞추는 것은 지루합니다. 그러나 산출물은 바로 이 지루한 부분을 통과해야 완성됩니다.
제가 쓰는 방법은 "끝내기 목록"을 미리 만들어두는 것입니다. 80% 지점쯤에서, 발행/배포까지 남은 자질구레한 일을 전부 적습니다. 그러면 마지막 10%가 막연한 안개가 아니라 체크박스 목록으로 바뀝니다.
끝내기 목록 — 블로그 글 발행
[ ] 제목 다시 읽고 다듬기
[ ] 오타 한 번 통독
[ ] 코드 블록 언어 표시 확인
[ ] 링크 클릭해서 다 살아있는지 확인
[ ] 대표 이미지 또는 요약 작성
[ ] 발행 후 모바일에서 한 번 보기
이렇게 적어두면 "마무리"라는 거대한 덩어리가 6개의 작은 동작으로 분해됩니다. 작아진 동작은 두렵지 않습니다.
7. 모멘텀: 연속성이 의지보다 강하다
의지력은 믿을 수 없는 자원입니다. 어떤 날은 넘치고 어떤 날은 바닥입니다. 그래서 저는 의지력 대신 모멘텀에 기댑니다. 모멘텀은 "어제 했으니 오늘도 한다"는 관성입니다.
연속성을 시각화하면 모멘텀이 강해집니다. Jerry Seinfeld의 일화로 알려진 "체인을 끊지 마라(Don't break the chain)" 방법이 대표적입니다. 매일 그 일을 하면 달력에 X를 칩니다. X가 길게 이어지면, 그 사슬을 끊고 싶지 않은 마음이 생깁니다.
6월 산출 체인 (매일 최소 1개 산출)
월 화 수 목 금 토 일
X X X X X . X
X X X X X X .
X X X ...
규칙: "큰 것"이 아니어도 된다. 커밋 하나, 단락 하나도 X.
여기서 중요한 균형이 있습니다. 사슬을 너무 신성시하면, 하루 빠진 날 전체가 무너지는 "전부 아니면 전무" 함정에 빠집니다. 저는 "이틀 연속으로는 빠지지 않는다"는 느슨한 규칙을 씁니다. 하루는 쉴 수 있지만 이틀은 안 됩니다. 이 규칙은 완벽한 사슬보다 오래 갑니다.
작은 시작 의식
모멘텀을 다시 붙이는 가장 좋은 방법은 우스울 정도로 작게 시작하는 것입니다. "오늘은 한 문장만 쓴다", "에디터만 연다". 신기하게도 한 문장을 쓰면 대개 열 문장을 쓰게 됩니다. 시작의 마찰만 넘으면 관성이 일을 끌고 갑니다.
8. 측정 가능한 산출: 활동이 아니라 결과를 센다
"열심히 했다"는 측정할 수 없습니다. "글 4편을 발행했다"는 측정할 수 있습니다. 산출 중심으로 살려면 측정 대상을 활동(input)에서 결과(output)로 옮겨야 합니다.
다음 표는 같은 영역에서 활동 지표와 산출 지표가 어떻게 다른지 보여줍니다.
| 영역 | 활동 지표 (약함) | 산출 지표 (강함) |
| --- | --- | --- |
| 글쓰기 | 자료 조사에 쓴 시간 | 발행한 글 수 |
| 개발 | 코딩한 시간 | 머지된 PR 수 |
| 학습 | 읽은 페이지 수 | 만든 요약/예제 수 |
| 운동 | 헬스장에 간 횟수 | 늘어난 중량/거리 |
| 영업 | 보낸 이메일 수 | 잡힌 미팅 수 |
활동 지표가 무의미한 것은 아닙니다. 다만 활동 지표는 자기 위안에 빠지기 쉽습니다. "오늘 세 시간이나 공부했어"는 기분은 좋지만 세상에 남긴 것은 없을 수 있습니다. 산출 지표는 냉정하지만 정직합니다.
저는 주간 단위로 산출을 셉니다. 매주 금요일 저녁, "이번 주에 세상에 내보낸 것" 목록을 적습니다. 비어 있으면 그 주는 활동만 있고 산출은 없었던 주입니다. 이 단순한 회고가 다음 주의 방향을 바꿉니다.
9. 발표와 데모로 마무리: 끝을 강제하는 장치
산출물에 "끝"을 강제하는 가장 효과적인 장치는 발표 또는 데모입니다. 누군가 앞에서 보여줘야 한다는 사실은 마지막 10%를 끝내게 만드는 강력한 압력입니다.
데모에는 또 다른 효과가 있습니다. 만든 것을 남에게 설명하려는 순간, 무엇이 중요하고 무엇이 군더더기인지가 선명해집니다. "이 기능을 왜 만들었더라?"라는 질문에 답하지 못하면, 그 기능은 핵심이 아니었던 것입니다.
데모를 잘 마무리하는 간단한 틀을 소개합니다.
3분 데모 구조
1. 문제 (30초)
"이런 불편이 있었습니다."
2. 해결 (30초)
"그래서 이걸 만들었습니다."
3. 시연 (90초)
실제로 작동하는 모습을 보여준다.
4. 다음 (30초)
"다음엔 이걸 할 겁니다." (= 다음 공개 약속)
마지막의 "다음" 단계가 영리한 부분입니다. 데모를 끝내면서 다음 약속을 공개하면, 이번 데모의 끝이 다음 산출의 시작이 됩니다. 사이클이 저절로 돌아갑니다.
10. 지속 가능한 페이스: 번아웃은 산출의 적이다
지금까지의 내용은 "더 많이, 더 빨리"처럼 들릴 수 있습니다. 그러나 산출을 꾸준히 내는 것의 핵심 단어는 "꾸준히"입니다. 일주일 폭주하고 한 달 쉬는 것보다, 매일 조금씩 오래 가는 편이 누적 산출이 훨씬 큽니다.
Cal Newport는 "Deep Work"에서 깊은 집중은 하루 몇 시간이 한계라고 말합니다. 실제로 고도의 집중을 요하는 창작 작업은 하루 3~4시간을 넘기기 어렵습니다. 그 이상 책상에 앉아 있어 봐야 질이 떨어진 시간을 쌓을 뿐입니다.
지속 가능한 페이스를 위한 제 규칙은 이렇습니다.
- 하루 산출 시간의 상한을 정한다. 무한정 일하지 않는다.
- 하루를 "산출 블록"과 "회복 블록"으로 나눈다.
- 일주일에 하루는 산출 의무가 없는 날을 둔다.
- 잠을 산출의 일부로 취급한다. 못 잔 다음 날의 산출은 질이 낮다.
번아웃은 산출을 잠깐 늘리고 오래 줄입니다. 한 달짜리 폭주의 대가로 석 달의 무기력을 치른 경험이 누구에게나 있을 것입니다. 마라톤 페이스로 달리되, 멈추지만 않으면 됩니다.
두 가지 페이스의 1년 누적 산출 (개념도)
폭주형: ████░░░░░░████░░░░░░░░░░██░░░░ (들쭉날쭉, 총합 작음)
지속형: ██▓██▓██▓██▓██▓██▓██▓██▓██▓██ (꾸준함, 총합 큼)
11. 머릿속 대화: 미루는 목소리에 답하기
산출을 막는 것은 거창한 장애물이 아니라 머릿속의 작은 목소리일 때가 많습니다. 그 목소리는 그럴듯한 핑계를 댑니다. 저는 그 목소리와 나누는 대화를 미리 준비해 둡니다. 다음은 제가 자주 쓰는 응답입니다.
목소리: "아직 더 공부하고 시작해야 해."
응답: "공부는 만들면서도 할 수 있어. 일단 첫 조각을 만들고, 막히는 지점에서 그 부분만 공부하자."
목소리: "이 정도로는 부끄러워서 못 내."
응답: "70점이면 낸다고 정했잖아. 부끄러움은 1주일이면 사라지고, 안 낸 후회는 1년 간다."
목소리: "남들은 훨씬 잘 만들었어."
응답: "남의 완성품과 내 초안을 비교하는 거야. 그 사람의 초안 시절도 분명 엉성했어."
목소리: "지금은 컨디션이 안 좋아."
응답: "그럼 25분만 하자. 25분 뒤에도 아니면 멈춰도 돼."
이 대화들의 공통점은 미루는 목소리를 부정하지 않는다는 것입니다. 부정하면 싸움이 되고, 싸움은 지칩니다. 대신 목소리를 인정하면서 "그래도 아주 작게 시작하자"로 방향만 틉니다. 미루는 마음은 적이 아니라, 두려움이 보내는 신호일 뿐입니다.
12. 산출의 품질: 빠름과 좋음은 적이 아니다
"작게, 자주, 빨리 내라"는 말을 들으면 품질을 포기하라는 뜻으로 오해하기 쉽습니다. 그렇지 않습니다. 꾸준한 산출은 오히려 품질을 끌어올립니다. 이유는 단순합니다. 품질은 반복에서 나오기 때문입니다.
글을 1년에 한 편 쓰는 사람과 1주일에 한 편 쓰는 사람을 비교해 보면, 1년 뒤 후자의 글이 거의 항상 낫습니다. 50번의 발행과 50번의 피드백을 거쳤기 때문입니다. 한 번에 걸작을 쓰려는 사람은 50번 연습할 기회를 스스로 버린 셈입니다.
품질을 산출의 적이 아니라 결과로 보는 관점을 정리하면 이렇습니다.
| 통념 | 실제 |
| --- | --- |
| 천천히 해야 품질이 좋다 | 자주 해야 품질이 는다 |
| 한 번에 완성해야 한다 | 여러 버전을 거쳐 좋아진다 |
| 피드백은 마지막에 받는다 | 피드백은 일찍 자주 받는다 |
| 양과 질은 반비례한다 | 초기엔 양이 질을 끌어올린다 |
도예 수업의 유명한 일화가 있습니다. 한 그룹은 작품의 "양"으로 평가받고, 다른 그룹은 단 하나의 "완벽한 작품"으로 평가받았습니다. 학기말, 가장 뛰어난 작품들은 모두 양으로 평가받은 그룹에서 나왔습니다. 많이 만들면서 자연히 실력이 늘었기 때문입니다. 완벽을 노린 그룹은 이론만 쌓고 손은 굳어 있었습니다.
13. 구체 사례: 주말 사이드 프로젝트를 끝낸 방법
추상론을 줄이기 위해 실제 사례를 하나 풀어보겠습니다. 저는 "북마크를 정리해주는 작은 웹 도구"를 만들고 싶었습니다. 비슷한 아이디어를 6개월간 머릿속에만 굴리고 있었습니다. 이번에는 다르게 했습니다.
먼저 공개 약속을 걸었습니다. 금요일 밤, 친구 셋이 있는 단톡방에 "일요일 저녁에 데모 보여줄게"라고 적었습니다. 도망갈 길이 좁아졌습니다.
다음으로 80/20으로 범위를 잘랐습니다. "북마크를 붙여넣으면 중복을 제거하고 알파벳 순으로 정렬해준다." 이것만 작동하면 누군가에게 쓸모가 있었습니다. 로그인, 저장, 동기화는 전부 80%에 넣고 버렸습니다.
그리고 토요일을 타임박스로 나눴습니다.
토요일 일정
10:00-12:00 입력창 + 붙여넣기 처리 (2시간 박스)
13:00-15:00 중복 제거 + 정렬 로직
15:30-17:00 결과 표시 + 복사 버튼
저녁 끝내기 목록 처리 + 배포
마지막 10%(배포, 도메인 연결, 모바일 확인)는 미리 만들어둔 끝내기 목록 덕분에 막히지 않았습니다. 일요일 저녁, 단톡방에 작동하는 링크를 올렸습니다. 완벽하지 않았습니다. 디자인은 투박했고 기능은 하나뿐이었습니다. 그러나 그것은 존재했습니다. 6개월간 머릿속에만 있던 것이 처음으로 밖으로 나왔습니다.
친구 한 명이 "정렬 옵션 추가되면 좋겠다"고 말했습니다. 혼자 상상하던 기능 목록에는 없던 피드백이었습니다. 그것이 다음 주의 산출이 되었습니다. 사이클이 돌기 시작한 것입니다.
14. 흔한 함정과 대응
산출을 막는 패턴은 사람마다 다르지만, 반복적으로 보이는 것들이 있습니다.
| 함정 | 증상 | 대응 |
| --- | --- | --- |
| 도구 정비 함정 | 시작 전에 환경/툴부터 완벽히 세팅 | 가진 도구로 일단 시작, 정비는 나중 |
| 리서치 무한 루프 | 자료만 계속 모으고 만들지 않음 | 리서치에 타임박스를 건다 |
| 큰 한 방 환상 | 작은 것은 의미 없다고 여김 | 작은 산출의 누적을 측정으로 증명 |
| 비교 마비 | 남의 완성품과 내 초안을 비교 | 남의 초안 시절을 떠올린다 |
| 시작만 반복 | 새 프로젝트만 계속 시작 | 끝내기 전 새것 금지 규칙 |
특히 마지막 "시작만 반복"은 산출이 없는 사람에게 가장 흔합니다. 새로 시작하는 흥분은 끝내는 지루함보다 달콤하기 때문입니다. 저는 "진행 중인 것을 끝내기 전에는 새 프로젝트를 시작하지 않는다"는 규칙을 의식적으로 지킵니다.
15. 한 주를 산출 중심으로 설계하기
마지막으로 모든 조각을 한 주 단위로 엮어 봅니다. 이것이 제가 실제로 쓰는 주간 리듬입니다.
산출 중심 한 주
월: 이번 주 산출 1개 정하기 + 작게 쪼개기 + 공개 약속
화: 핵심 20% 타임박스로 작업
수: 핵심 20% 마무리 (이미 내보낼 수 있는 상태)
목: 끝내기 목록 작성 + 마지막 10% 처리
금: 발행/데모 + 주간 산출 세기 + 회고
토: 회복 또는 가벼운 다음 탐색
일: 쉼 (산출 의무 없음)
이 리듬의 핵심은 수요일에 이미 "내보낼 수 있는 상태"에 도달하는 것입니다. 그러면 목요일과 금요일은 완성도를 높이는 보너스 시간이 됩니다. 만약 목금에 무슨 일이 생겨도, 수요일 버전을 내보내면 그 주는 산출이 있는 주가 됩니다. 항상 "내보낼 수 있는 버전"을 손에 들고 있는 것, 이것이 꾸준한 산출의 비밀입니다.
최종 체크리스트
다음은 새 산출물을 시작할 때 제가 훑는 점검표입니다.
[시작 전]
[ ] 이 산출물은 "한 번 앉아서" 끝낼 크기로 쪼갰는가
[ ] 핵심 20%가 무엇인지 한 문장으로 말할 수 있는가
[ ] 외부에 공개된 데드라인이 있는가
[ ] 끝을 강제하는 발표/데모/발행 시점이 잡혀 있는가
[작업 중]
[ ] 활동이 아니라 산출로 진척을 측정하는가
[ ] 타임박스를 정하고 시간이 끝나면 멈추는가
[ ] 70점이면 일단 내보낼 마음의 준비가 되어 있는가
[마무리]
[ ] 끝내기 목록을 미리 적어두었는가
[ ] 마지막 10%를 작은 동작으로 분해했는가
[ ] 내보낸 뒤 다음 산출의 약속을 공개했는가
[지속]
[ ] 이번 주에 내보낸 것을 셀 수 있는가
[ ] 이틀 연속 쉬지 않는다는 사슬을 지키는가
[ ] 번아웃 없이 다음 주도 갈 수 있는 페이스인가
맺으며
결과물을 내는 것은 재능의 문제가 아니라 시스템의 문제입니다. 완벽주의를 두려움으로 이해하고, 일을 끝낼 수 있는 크기로 쪼개고, 시간에 일을 맞추고, 도망갈 길을 줄이고, 마지막 10%를 미리 분해하고, 활동이 아니라 산출을 세고, 발표로 끝을 강제하고, 무너지지 않는 페이스로 사슬을 이어가는 것. 화려하지 않지만 작동합니다.
처음 동료의 말이 아팠던 이유는, 그것이 제가 바꿀 수 있는 것을 정확히 가리켰기 때문입니다. 준비하는 사람에서 내보내는 사람으로 바뀌는 데는 재능이 아니라 결심과 구조가 필요했습니다. 오늘 70점짜리 무언가를 하나 내보내는 것부터 시작해 보시길 권합니다. 세상은 무너지지 않고, 당신은 산출하는 사람이 됩니다.
참고 자료
- David Allen, "Getting Things Done": [https://gettingthingsdone.com/](https://gettingthingsdone.com/)
- Cal Newport, "Deep Work" 및 블로그: [https://www.calnewport.com/books/deep-work/](https://www.calnewport.com/books/deep-work/)
- Anne Lamott, "Bird by Bird": [https://annelamott.com/books/](https://annelamott.com/books/)
- Basecamp, "Shape Up": [https://basecamp.com/shapeup](https://basecamp.com/shapeup)
- Paul Graham, "How to Do Great Work": [https://paulgraham.com/greatwork.html](https://paulgraham.com/greatwork.html)
- Parkinson's Law (The Economist 원문): [https://www.economist.com/news/1955/11/19/parkinsons-law](https://www.economist.com/news/1955/11/19/parkinsons-law)
- The Pomodoro Technique: [https://francescocirillo.com/products/the-pomodoro-technique](https://francescocirillo.com/products/the-pomodoro-technique)
- Will Larson, "An Elegant Puzzle" 및 블로그: [https://lethain.com/](https://lethain.com/)
- StaffEng, 엔지니어의 산출과 영향력: [https://staffeng.com/](https://staffeng.com/)
- Harvard Business Review, 생산성과 완벽주의: [https://hbr.org/](https://hbr.org/)
현재 단락 (1/209)
저는 한동안 "열심히 하는데 결과가 없는" 상태로 살았습니다. 노트는 가득 찼고, 아이디어 목록은 길었고, 읽은 책도 많았는데, 정작 세상에 내보낸 것은 거의 없었습니다. 어느 날...