이런 것들은 일을 하는 것이 아니에요
(strangestloop.io)- 일을 준비하고, 계획하고, 공유하고, 자책하는 행동은 "일을 하는 것" 이 아님
- 시간 예약, 할 일 목록 작성, 친구에게 메시지 보내기, SNS에 올리기도 모두 일을 하는 것이 아님
- 정보를 읽거나 상상하는 행위 또한 일을 하는 것이 아님
- 결국, 일을 하는 유일한 방법은 실제로 일을 시작하는 것뿐임
그 일을 할 준비를 하는 것은 그 일을 하는 것이 아님.
그 일을 할 시간을 잡는 것은 그 일을 하는 것이 아님.
그 일을 할 일 목록을 만드는 것은 그 일을 하는 것이 아님.
사람들에게 그 일을 할 거라고 말하는 것은 그 일을 하는 것이 아님.
그 일을 하고 있을지도 모르는 친구들에게 메시지를 보내는 것도 그 일을 하는 것이 아님.
그 일을 할 거라고 멋진 트윗을 쓰는 것은 그 일을 하는 것이 아님.
그 일을 하지 않았다고 자신을 미워하는 것도 그 일을 하는 것이 아님.
그 일을 한 사람들을 미워하는 것도 그 일을 하는 것이 아님.
그 일을 하는 데 방해가 되는 장애물을 미워하는 것도 그 일을 하는 것이 아님.
그 일을 하고 나면 받을 찬사를 상상하는 것은 그 일을 하는 것이 아님.
그 일을 어떻게 하는지 읽는 것도 그 일을 하는 것이 아님.
그 일을 다른 사람들이 어떻게 했는지 읽는 것도 그 일을 하는 것이 아님.
이 글을 읽는 것도 그 일을 하는 것이 아님.
그 일을 하는 유일한 것은 그 일을 직접 하는 것뿐임.
Hacker News 의견
-
“준비하는 것”이 “하는 것”이 아니라는 말에 공감함
하지만 어떤 일에서는 준비 작업이 전체의 90% 를 차지하고 결과의 품질을 결정함
예를 들어 페인팅을 할 때, 그냥 붓을 들고 칠하면 금방 망가짐. 반면 전문가처럼 표면을 샌딩하고 청소하고 작업 공간을 정리하면 오래감
당장은 시간을 아끼는 것 같아도, 나중에 다시 해야 하거나 엉망이 된 걸 치우느라 더 많은 시간을 잃게 됨- 나는 이런 예시에서 준비 작업 자체가 이미 ‘하는 것’ 이라고 생각함
하지만 ‘새로운 제품을 알리는 것’도 ‘하는 것’일 수 있음
결국 ‘무엇이 진짜 하는 것인가’를 정의하는 게 중요하지만, 그 정의에 빠져서 정작 아무것도 안 하게 될 수도 있음
‘thingness’는 이분법이 아니라, 지금 하는 일과 주된 목표의 일치 정도로 봐야 함 - 준비 작업은 정말 힘듦. 그래서 좋은 도구와 워크플로우로 그 고통을 줄이는 법을 배우는 게 중요함
완벽하지 않아도 80% 정도 잘 해내고 그 상태에 평화를 느끼는 사람들이 가장 생산적임
- 나는 이런 예시에서 준비 작업 자체가 이미 ‘하는 것’ 이라고 생각함
-
Viable System Model에서 ‘doing the thing’은 System 1에 해당함
하지만 진짜로 지속 가능한 시스템이 되려면 System 2~5가 필요함- System 2: 여러 System 1 간의 조정과 커뮤니케이션
- System 3: 자원 배분과 프로세스 개발
- System 4: 전략과 리스크 관리
- System 5: 가치와 조직 설계
인간도 이런 시스템처럼 살아야 함. 단순히 ‘하는 것’뿐 아니라 - 어떤 일을 먼저 할지 우선순위를 정하고
- 과거와 미래의 나를 위해 기록을 남기고
- 필요한 자원을 확보하고
- 장기적 성공을 위한 환경과 습관을 만들고
- 일이 끝난 뒤의 전략적 위치를 고려하고
- 머리와 마음을 연결해 ‘올바른 일’을 하고 있는지 확인해야 함
이런 건 ‘하는 것’은 아니지만, 제대로 하는 데 필수적인 요소임 - 그래도 결국엔 직접 시작해야 무엇이 필요한지 알게 됨
- 하지만 착각하지 말아야 함. 진짜로 ‘하는 것’은 실제로 ‘할 때’임
- 이런 모델을 비즈니스 스쿨에서 배웠다면 흥미로웠을 것 같음
- 참고로, 지금 이 댓글을 쓰는 건 ‘하는 것’이 아님
-
어떤 사람들은 Jira 티켓을 만든다고 눈치를 줌
하지만 나는 해야 할 일이 100개라서 우선순위를 정하기 위해 티켓을 만드는 것임
즉흥적으로 처리하면 비효율적임- 물론 절차가 많아지면 오버헤드가 커짐
티켓 생성 → 브랜치 → 테스트 → PR → 리뷰 → 배포 등 모든 단계가 필요하지만, 때로는 이런 절차를 생략하고 스파이크 작업이 필요할 때도 있음 - 이건 Jira 자체를 비판하는 게 아니라, ‘하는 것’ 주변의 일들에 너무 몰입해 정작 실행을 놓치는 문제를 지적하는 것처럼 보임
- 티켓을 만들지 않으면 일이 아예 안 될 수도 있음
계획하고 기록하는 사람들 덕분에 더 많은 일이 실제로 이루어짐 - 나는 티켓을 만드는 이유가, 나중에 왜 이 일을 했는지 추적할 수 있게 하기 위함임
1년 뒤 다른 엔지니어가 코드를 보고 이게 왜 필요한지 알 수 있도록, PR과 티켓, 설계 문서가 연결되어야 함
그렇지 않으면 누군가 기능을 삭제하고 시스템이 망가질 수도 있음
팀마다 PR에 정보를 담거나 테스트로 보완하지만, 왜 이 일이 중요한지는 결국 문서화가 필요함
- 물론 절차가 많아지면 오버헤드가 커짐
-
Ron Jeffries가 Sudoku 프로그램을 망친 사례를 읽었음
그는 문제의 본질이나 적절한 데이터 구조를 고민하지 않고 준비를 완전히 생략한 채 코딩을 시작했음 -
나는 Tesla의 “생각을 많이 하면 땀을 덜 흘린다” 는 쪽에 가까움
충분히 생각하고 나서 빠르게 실행하는 걸 선호함
어떤 사람들은 바로 뛰어들지만, 그게 오히려 더 어렵고 결과도 나쁨
물론 직접 해봐야 이해되는 일도 있지만, 가능한 한 사전 숙고와 정보 수집을 선호함- “옳은 방법, 틀린 방법, 그리고 Max Power 방식이 있음”이라는 농담이 떠오름
결국 그건 틀린 방법이지만 더 빠름
- “옳은 방법, 틀린 방법, 그리고 Max Power 방식이 있음”이라는 농담이 떠오름
-
나는 ‘doing the thing’의 의미를 A→B→C 단계적 과정으로 봄
우리는 종종 “C를 하자”고만 생각하지만, 그 전에 “A(조사)”와 “B(논의)”가 필요함
이걸 잊으면 “C만 가치 있다”고 착각하고, 준비 과정을 무시하게 됨- 하지만 의사에게 진료비를 낸다고 해서 의대 교육비까지 지불하는 건 아님
즉, 준비와 실행은 구분되어야 함
- 하지만 의사에게 진료비를 낸다고 해서 의대 교육비까지 지불하는 건 아님
-
이 글을 공허한 격언으로 느꼈음
시각화, 일정 관리, 작은 단위로 나누기 등은 실제로 효과가 입증된 방법임
반면 “그냥 해라”는 식의 접근은 검증되지 않음- 그래도 시작하지 않으면 끝낼 수 없음
나는 계획은 잘하지만 지속과 완성이 어렵기에 이런 조언이 도움이 됨
Jobs가 말했듯, “진짜 예술가는 출시한다” 는 말이 떠오름
- 그래도 시작하지 않으면 끝낼 수 없음
-
이 개념은 창의적 작업에도 잘 맞음
특히 미루는 습관이 있는 사람들에게 유용함
Cult of Done Manifesto와도 잘 어울림- “아이디어를 일주일 안에 끝내지 못하면 버려라”라는 문구는 현실적이지 않음
아이를 키워보면 그런 말이 얼마나 비현실적인지 알게 됨
- “아이디어를 일주일 안에 끝내지 못하면 버려라”라는 문구는 현실적이지 않음
-
HN에서 낚인 기분임
읽는 것만으로는 아무것도 한 게 아님 -
나는 이 글을 벽에 출력해 붙여둔 ADHD 환자임
1년이 지나도 여전히 ‘그 일’을 못 하고 있음
실행하려다 ADHD를 치료하려 하고, 수면·운동·영양·디지털 자극 줄이기 등으로 균형을 잡으려 함
하지만 가끔은 ‘집행 기능을 개선하려는 노력 자체가 일 미루기’ 처럼 느껴짐- 그 고통은 진짜임. 공감 못 하는 사람들의 말은 너무 심각하게 듣지 말 것