▲

일을 하는 것은 일을 하는 것이다

 (softwaredesign.ing)
3P by GN⁺ 6일전 | ★ favorite | 댓글 1개
  • 행동 자체만이 실제 실행이며, 생각이나 준비는 실행이 아님을 강조
  • 계획, 학습, 토론, 도구 구매 등은 모두 ‘일을 하는 것’이 아니라는 점을 반복적으로 지적
  • 실패하거나 서툴게라도 직접 시도하는 행위만이 진짜 실행으로 간주됨
  • 작게라도 시작하는 것이 중요하며, 완벽한 준비나 이상적인 조건은 불필요함
  • 실제 행동으로 옮기는 태도가 창작과 개발의 핵심임을 상기시키는 글

실행과 비실행의 구분

  • 글은 “생각하는 것, 꿈꾸는 것, 시각화하는 것, 준비하는 것” 등은 모두 ‘일을 하는 것’이 아님을 나열
    • 예: “생각하는 것”, “꿈꾸는 것”, “성공을 상상하는 것”, “준비될 때까지 기다리는 것” 등
  • 말하거나 설명하거나 논쟁하는 행위도 실행으로 간주되지 않음
    • “다른 사람에게 설명하기”, “온라인에서 논쟁하기”, “시작하겠다고 발표하기” 등이 포함

준비와 소비의 함정

  • 팟캐스트 듣기, 튜토리얼 보기, 다른 사람의 사례 읽기 등은 모두 실행이 아님
  • 완벽한 시스템을 설계하거나 도구를 구매하거나 작업 공간을 정리하는 행위도 실행으로 보지 않음
  • 죄책감이나 바쁨으로 위안받는 태도 역시 실제 행동이 아님

진짜 실행의 형태

  • 실패하면서 하는 것, 서툴게 하는 것, 작게라도 하는 것은 모두 ‘일을 하는 것’으로 인정
    • 완벽하지 않아도 실제로 손을 움직이는 행위가 중요함
  • 글의 후반부에서 “블로그를 쓰는 것조차 일을 하는 것은 아니다”라고 언급하며 자기반성적 결론 제시

핵심 메시지

  • 행동만이 진짜 실행이며, 그 외의 모든 것은 실행의 대체물이 아님
  • 작게라도 시작하고, 실패를 감수하며, 직접 해보는 것이 유일한 진전임
  • 글의 마지막 문장 “이제 다시 일하러 가야겠다”는 즉시 실행의 태도를 상징함
▲
GN⁺ 6일전  [-]
Hacker News 의견들

  • “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 조언이고,
      다른 하나는 Ira Glass의 “The Gap”임
      핵심은 완벽을 기다리지 말고 형편없는 초안이라도 쓰고, 그걸 비평가의 시선으로 고쳐나가라는 것임
    • 회사에서는 이런 접근을 하면 오히려 “그만해도 된다” 는 말을 듣고, 미완성 버전을 영원히 유지하게 됨
      그래서 요즘은 완성될 때까지 일부러 “아직 안 됐다”고 말함
    • 소프트웨어는 보통 alpha–beta–release 세 단계를 거침
      나는 먼저 빠르게 만든 뒤, 다듬고, 마지막엔 새로 다시 쓰는 식으로 함
      중요한 건 beta 단계에서 완벽주의에 빠지지 않는 것임
    • 인간이 이런 식으로 점진적으로 개선하면 긍정적으로 보면서, LLM이 하면 부정적으로 보는 게 흥미로움
      사실 점진적 개선이 효과적이라면, 인간이든 AI든 상관없음

  • 예전 회사에서는 경영진을 “문제 감탄 협회”라고 부름
    문제를 논의하고 분석하고 책임자를 찾는 데만 몰두했지, 실제로 해결하지는 않았음
    결국 중요한 건 ‘실제로 하는 것’ 이었음

    • 반대로, 어떤 회사는 기존 해결책에 집착해서 문제를 다시 보려 하지 않음
      가장 좋은 접근은 문제에 대한 애정과 반복적인 해결 의지를 함께 가지는 것임
      내부에서 직접 사용하는 dogfooding이 그 균형을 잡는 좋은 방법임
    • 결국 일을 직접 하는 사람이 되면, 그 결정권을 활용해야 함
      가능한 한 자신에게 유리한 방향으로 결정하는 게 중요함
    • 중간 관리자를 없애면 생산성이 오름
      업데이트를 위한 조율이 줄고, 실제로 일하는 조직이 더 효율적임
    • 문제를 분석한 뒤, 지금 당장 다른 일을 시작할 이유가 생겼다면 그건 괜찮음

  • 이 글은 strangestloop.io의 에세이와 매우 유사함

    • 솔직히 거의 표절 수준으로 느껴짐
      제목을 보고 익숙하다고 생각했는데, 클릭해보니 다른 사이트였고 게시 시점도 며칠 전이라 놀랐음
      내용이 너무 비슷해서 우연이라고 보기 어려움
    • 나도 이 글을 어디서 봤는지 기억이 안 났는데, 비슷한 내용을 읽은 적이 있었음

  • 예전엔 준비가 중요하다고 생각했지만, 어느 순간 준비가 무한 루프가 되는 걸 깨달음
    우리 팀은 2페이지짜리 스펙으로 4개월 만에 제품을 완성했는데, 경쟁 팀은 8개월 동안 문서만 쓰다 해체됨
    계획은 20%만 해도 80%의 문제를 잡음. 그 이후는 불안이 포장된 엄격함일 뿐임
    결국 부끄러운 걸 내놓고 고치면서 배운 게 대부분임

    • 글의 요점을 약간 오해한 듯함. ‘준비’ 자체가 이미 ‘doing the thing이 아님’ 에 포함된다고 봄
    • 팀에 따라 다름. 우리 팀은 몇 달간 계획을 세우고도 잘 출시했음. 결국 상황에 따라 다름
    • 계획의 효용은 줄지만, 대부분의 프로젝트는 계획 부족으로 더 나빠짐
    • Red Dwarf의 Rimmer가 시험 준비만 하다 실패하는 장면이 떠오름
      이전 HN 댓글에 인용되어 있음
    • 계획을 완전히 없애는 것도 문제임. 균형이 필요함

  • Analysis paralysis는 실제로 존재함
    멈추지 않으려면 일단 시작해야 함. 해피 패스부터 처리하고, 나중에 엣지 케이스를 다듬으면 됨
    요즘은 프로토타입 비용이 낮으니, 실패를 두려워하지 말고 시도해야 함
    LLM이 놀라울 정도로 효과적인 이유도 바로 이 점임 — 분석 대신 즉시 실행함
    결과가 완벽하지 않아도 충분히 쓸 만하고, 필요하면 나중에 최적화하면 됨
    프레임워크를 만들기 전에는 최소 세 번 실제 시스템을 만들어봐야 함. 그래야 어디가 과하거나 부족한지 알 수 있음

    • 단, 프로토타입을 실제 제품으로 착각하지 말아야 함
      ‘충분히 괜찮다’는 말은 자기기만이 될 수 있음
      실패한 프로토타입이 시장이 없다는 증거는 아님. 단지 무언가 부족했다는 신호일 뿐임

  • 이 글은 이전 게시물과 거의 동일한 메시지를 담고 있음
    이전 HN 토론에서도 다뤄졌음

    • 논의가 너무 비슷해서 중복(dupe) 으로 표시해야 할 정도임

  • 반대로, 때로는 ‘doing the thing’ 자체가 잘못된 선택일 때도 있음
    그래서 나는 여전히 디자인 문서와 코드 리뷰를 고집함
    GenAI 시대에는 ‘계획 없이 대충 해보기’가 너무 쉬워졌기 때문에, 그만큼 균형추가 필요함

    • 요즘은 해피 패스는 쉬워졌지만, 프로토타입과 프로덕션의 간극이 더 커졌음
      비결정성과 지연(latency) 문제로 시간을 다 쓰게 되고, 결국 단위 경제성을 맞추는 게 진짜 도전임

  • 『Remains of The Day』에서는 ‘the thing에 대해 말만 하는 것’을 자기만족적 행위라고 부름
    실제로 아무것도 이루지 못하면서 기분만 좋아지는 대화에 그치는 경우가 많음

  • 반면, 계획과 준비, mise-en-place는 실제 실행에 도움이 될 수 있음

    • 단, 실제로 행동으로 옮길 때만 의미가 있음. 분석 마비에 빠지면 안 됨
    • 사람들은 종종 계획이나 논의를 ‘doing the thing’으로 착각함. 그게 문제임
답변달기