# 일을 하는 것은 일을 하는 것이다 > Clean Markdown view of GeekNews topic #26199. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26199](https://news.hada.io/topic?id=26199) - GeekNews Markdown: [https://news.hada.io/topic/26199.md](https://news.hada.io/topic/26199.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-28T22:33:29+09:00 - Updated: 2026-01-28T22:33:29+09:00 - Original source: [softwaredesign.ing](https://www.softwaredesign.ing/blog/doing-the-thing-is-doing-the-thing) - Points: 3 - Comments: 2 ## Topic Body - **행동 자체**만이 실제 실행이며, 생각이나 준비는 실행이 아님을 강조 - **계획, 학습, 토론, 도구 구매** 등은 모두 ‘일을 하는 것’이 아니라는 점을 반복적으로 지적 - **실패하거나 서툴게라도 직접 시도하는 행위**만이 진짜 실행으로 간주됨 - **작게라도 시작하는 것**이 중요하며, 완벽한 준비나 이상적인 조건은 불필요함 - **실제 행동으로 옮기는 태도**가 창작과 개발의 핵심임을 상기시키는 글 --- ### 실행과 비실행의 구분 - 글은 “생각하는 것, 꿈꾸는 것, 시각화하는 것, 준비하는 것” 등은 모두 **‘일을 하는 것’이 아님**을 나열 - 예: “생각하는 것”, “꿈꾸는 것”, “성공을 상상하는 것”, “준비될 때까지 기다리는 것” 등 - **말하거나 설명하거나 논쟁하는 행위**도 실행으로 간주되지 않음 - “다른 사람에게 설명하기”, “온라인에서 논쟁하기”, “시작하겠다고 발표하기” 등이 포함 ### 준비와 소비의 함정 - **팟캐스트 듣기, 튜토리얼 보기, 다른 사람의 사례 읽기** 등은 모두 실행이 아님 - **완벽한 시스템을 설계하거나 도구를 구매하거나 작업 공간을 정리하는 행위**도 실행으로 보지 않음 - **죄책감이나 바쁨으로 위안받는 태도** 역시 실제 행동이 아님 ### 진짜 실행의 형태 - **실패하면서 하는 것**, **서툴게 하는 것**, **작게라도 하는 것**은 모두 ‘일을 하는 것’으로 인정 - 완벽하지 않아도 실제로 손을 움직이는 행위가 중요함 - 글의 후반부에서 “블로그를 쓰는 것조차 일을 하는 것은 아니다”라고 언급하며 **자기반성적 결론** 제시 ### 핵심 메시지 - **행동만이 진짜 실행**이며, 그 외의 모든 것은 실행의 대체물이 아님 - **작게라도 시작하고, 실패를 감수하며, 직접 해보는 것**이 유일한 진전임 - 글의 마지막 문장 “이제 다시 일하러 가야겠다”는 **즉시 실행의 태도**를 상징함 ## Comments ### Comment 52006 - Author: bobross0 - Created: 2026-02-27T11:36:30+09:00 - Points: 1 저 같이 실행을 잘 못하는 사람들에게 좋은 문구네요. ### Comment 50151 - Author: neo - Created: 2026-01-28T22:33:29+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46776155) - “**Doing it badly**” 원칙이 내 사고방식을 완전히 바꿔놓았음 완벽한 아키텍처를 설계하려고 몇 주를 보냈지만, 결국 계획을 멈추고 내 문제를 해결하는 **투박한 버전**을 만들었음 놀라웠던 건, 그 첫 버전이 계획으로는 절대 배울 수 없는 걸 가르쳐줬다는 점임. 사용자가 실제로 중요하게 여기는 것, 실전에서 중요한 엣지 케이스, 그리고 ‘충분히 좋은’ 기준이 무엇인지 배웠음 가장 어려운 건 결함이 있다는 걸 알면서도 배포를 허락하는 것임. 하지만 실제 사용에서 오는 피드백 루프는 수주간의 가상 논의보다 훨씬 가치가 있었음 - 내용에는 동의하지만, 글의 **톤이 LLM이 생성한 글**처럼 느껴짐 요즘 생산성 관련 서브레딧에 이런 글이 넘쳐남. 개인용 자동화 도구를 만들면서 몇 주 동안 아키텍처를 계획한다는 게 현실적으로 가능한가 의문임 작성자의 댓글 기록을 보면 비슷한 문체가 반복되어 신뢰가 가지 않음 - 예전에 본 뛰어난 개발자는 코드를 여러 번 **완전히 지우고 다시 쓰는 방식**으로 작업했음 그 과정을 보고 정말 흥미로웠음 - 초보자에게 이 감각을 가르치는 게 정말 어려움 실제로 구현하고 리팩터링하는 과정에서 문제와 프로그래밍 전반에 대해 배울 게 많음 처음 생각한 추상화는 대부분 틀림. 구현하다 보면 구조가 완전히 바뀌고, 결국 처음과 전혀 다른 **아름다운 코드**가 나옴 - Fred Brooks의 『The Mythical Man-Month』에 실린 **“Plan to Throw One Away”** 에세이가 떠오름 첫 버전은 버릴 각오로 만들라는 내용인데, 실제로는 대부분 버리지 않고 반복적으로 개선함 지금은 도구와 프로세스 덕분에 계속 **iterate**할 수 있게 되었음 - 중요한 건 상위 기능 설계와 내부 **플러밍(기반 구조)** 을 혼동하지 않는 것임 내부 구조도 반복과 프로토타이핑이 필요하지만, 데이터 구조·에러 처리·로깅·네이밍 같은 부분은 초기에 신중히 결정해야 나중에 빠르게 개선할 수 있음 - “**Doing it badly is doing the thing**”이라는 문장이 마음에 듦 HN에서 배운 교훈인데, 막혔을 때는 완벽하게 하려 고민하지 말고 일단 해보는 게 중요함 처음엔 엉망이라도 조금씩 개선하다 보면 어느새 명확한 그림이 보임. 마치 마법 같음 - “**Everything worth doing is worth doing badly**”라는 말이 어려운 시기를 버티게 해줬음 - 이와 관련해 좋아하는 두 가지 조언이 있음 하나는 Dan Harmon의 [writer’s block 조언](https://www.reddit.com/r/Screenwriting/comments/5b2w4c/dan_harmons_advice_on_writing_and_writers_block/)이고, 다른 하나는 Ira Glass의 [“The Gap”](https://www.reddit.com/r/Screenwriting/comments/c98jpd/the_gap_by_ira_glass_useful_resource_for/)임 핵심은 완벽을 기다리지 말고 **형편없는 초안이라도 쓰고**, 그걸 비평가의 시선으로 고쳐나가라는 것임 - 회사에서는 이런 접근을 하면 오히려 **“그만해도 된다”** 는 말을 듣고, 미완성 버전을 영원히 유지하게 됨 그래서 요즘은 완성될 때까지 일부러 “아직 안 됐다”고 말함 - 소프트웨어는 보통 **alpha–beta–release** 세 단계를 거침 나는 먼저 빠르게 만든 뒤, 다듬고, 마지막엔 새로 다시 쓰는 식으로 함 중요한 건 **beta 단계에서 완벽주의에 빠지지 않는 것**임 - 인간이 이런 식으로 점진적으로 개선하면 긍정적으로 보면서, LLM이 하면 부정적으로 보는 게 흥미로움 사실 **점진적 개선**이 효과적이라면, 인간이든 AI든 상관없음 - 예전 회사에서는 경영진을 “**문제 감탄 협회**”라고 부름 문제를 논의하고 분석하고 책임자를 찾는 데만 몰두했지, 실제로 해결하지는 않았음 결국 중요한 건 **‘실제로 하는 것’** 이었음 - 반대로, 어떤 회사는 기존 **해결책에 집착**해서 문제를 다시 보려 하지 않음 가장 좋은 접근은 문제에 대한 애정과 반복적인 해결 의지를 함께 가지는 것임 내부에서 직접 사용하는 **dogfooding**이 그 균형을 잡는 좋은 방법임 - 결국 일을 직접 하는 사람이 되면, 그 **결정권을 활용**해야 함 가능한 한 자신에게 유리한 방향으로 결정하는 게 중요함 - **중간 관리자**를 없애면 생산성이 오름 업데이트를 위한 조율이 줄고, 실제로 일하는 조직이 더 효율적임 - 문제를 분석한 뒤, **지금 당장 다른 일을 시작할 이유**가 생겼다면 그건 괜찮음 - 이 글은 [strangestloop.io의 에세이](https://strangestloop.io/essays/things-that-arent-doing-the-thing)와 매우 유사함 - 솔직히 거의 **표절 수준**으로 느껴짐 제목을 보고 익숙하다고 생각했는데, 클릭해보니 다른 사이트였고 게시 시점도 며칠 전이라 놀랐음 내용이 너무 비슷해서 우연이라고 보기 어려움 - 나도 이 글을 어디서 봤는지 기억이 안 났는데, 비슷한 내용을 읽은 적이 있었음 - 예전엔 준비가 중요하다고 생각했지만, 어느 순간 **준비가 무한 루프**가 되는 걸 깨달음 우리 팀은 2페이지짜리 스펙으로 4개월 만에 제품을 완성했는데, 경쟁 팀은 8개월 동안 문서만 쓰다 해체됨 계획은 20%만 해도 80%의 문제를 잡음. 그 이후는 **불안이 포장된 엄격함**일 뿐임 결국 부끄러운 걸 내놓고 고치면서 배운 게 대부분임 - 글의 요점을 약간 오해한 듯함. ‘준비’ 자체가 이미 **‘doing the thing이 아님’** 에 포함된다고 봄 - 팀에 따라 다름. 우리 팀은 몇 달간 계획을 세우고도 잘 출시했음. 결국 **상황에 따라 다름** - 계획의 효용은 줄지만, 대부분의 프로젝트는 **계획 부족**으로 더 나빠짐 - Red Dwarf의 Rimmer가 시험 준비만 하다 실패하는 장면이 떠오름 [이전 HN 댓글](https://news.ycombinator.com/item?id=28033747)에 인용되어 있음 - 계획을 완전히 없애는 것도 문제임. **균형이 필요함** - **Analysis paralysis**는 실제로 존재함 멈추지 않으려면 일단 시작해야 함. **해피 패스**부터 처리하고, 나중에 엣지 케이스를 다듬으면 됨 요즘은 프로토타입 비용이 낮으니, 실패를 두려워하지 말고 시도해야 함 LLM이 놀라울 정도로 효과적인 이유도 바로 이 점임 — **분석 대신 즉시 실행**함 결과가 완벽하지 않아도 충분히 쓸 만하고, 필요하면 나중에 최적화하면 됨 프레임워크를 만들기 전에는 최소 세 번 실제 시스템을 만들어봐야 함. 그래야 어디가 과하거나 부족한지 알 수 있음 - 단, **프로토타입을 실제 제품으로 착각**하지 말아야 함 ‘충분히 괜찮다’는 말은 자기기만이 될 수 있음 실패한 프로토타입이 시장이 없다는 증거는 아님. 단지 **무언가 부족했다는 신호**일 뿐임 - 이 글은 [이전 게시물](https://strangestloop.io/essays/things-that-arent-doing-the-thing)과 거의 동일한 메시지를 담고 있음 [이전 HN 토론](https://news.ycombinator.com/item?id=45939431)에서도 다뤄졌음 - 논의가 너무 비슷해서 **중복(dupe)** 으로 표시해야 할 정도임 - 반대로, 때로는 **‘doing the thing’ 자체가 잘못된 선택**일 때도 있음 그래서 나는 여전히 **디자인 문서와 코드 리뷰**를 고집함 GenAI 시대에는 ‘계획 없이 대충 해보기’가 너무 쉬워졌기 때문에, 그만큼 **균형추가 필요함** - 요즘은 해피 패스는 쉬워졌지만, **프로토타입과 프로덕션의 간극**이 더 커졌음 비결정성과 지연(latency) 문제로 시간을 다 쓰게 되고, 결국 **단위 경제성**을 맞추는 게 진짜 도전임 - 『Remains of The Day』에서는 ‘the thing에 대해 말만 하는 것’을 **자기만족적 행위**라고 부름 실제로 아무것도 이루지 못하면서 기분만 좋아지는 대화에 그치는 경우가 많음 - 반면, **계획과 준비, mise-en-place**는 실제 실행에 도움이 될 수 있음 - 단, **실제로 행동으로 옮길 때만** 의미가 있음. 분석 마비에 빠지면 안 됨 - 사람들은 종종 계획이나 논의를 **‘doing the thing’으로 착각**함. 그게 문제임