“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이 그 균형을 잡는 좋은 방법임
결국 일을 직접 하는 사람이 되면, 그 결정권을 활용해야 함
가능한 한 자신에게 유리한 방향으로 결정하는 게 중요함
중간 관리자를 없애면 생산성이 오름
업데이트를 위한 조율이 줄고, 실제로 일하는 조직이 더 효율적임
솔직히 거의 표절 수준으로 느껴짐
제목을 보고 익숙하다고 생각했는데, 클릭해보니 다른 사이트였고 게시 시점도 며칠 전이라 놀랐음
내용이 너무 비슷해서 우연이라고 보기 어려움
나도 이 글을 어디서 봤는지 기억이 안 났는데, 비슷한 내용을 읽은 적이 있었음
예전엔 준비가 중요하다고 생각했지만, 어느 순간 준비가 무한 루프가 되는 걸 깨달음
우리 팀은 2페이지짜리 스펙으로 4개월 만에 제품을 완성했는데, 경쟁 팀은 8개월 동안 문서만 쓰다 해체됨
계획은 20%만 해도 80%의 문제를 잡음. 그 이후는 불안이 포장된 엄격함일 뿐임
결국 부끄러운 걸 내놓고 고치면서 배운 게 대부분임
글의 요점을 약간 오해한 듯함. ‘준비’ 자체가 이미 ‘doing the thing이 아님’ 에 포함된다고 봄
팀에 따라 다름. 우리 팀은 몇 달간 계획을 세우고도 잘 출시했음. 결국 상황에 따라 다름
계획의 효용은 줄지만, 대부분의 프로젝트는 계획 부족으로 더 나빠짐
Red Dwarf의 Rimmer가 시험 준비만 하다 실패하는 장면이 떠오름 이전 HN 댓글에 인용되어 있음
계획을 완전히 없애는 것도 문제임. 균형이 필요함
Analysis paralysis는 실제로 존재함
멈추지 않으려면 일단 시작해야 함. 해피 패스부터 처리하고, 나중에 엣지 케이스를 다듬으면 됨
요즘은 프로토타입 비용이 낮으니, 실패를 두려워하지 말고 시도해야 함
LLM이 놀라울 정도로 효과적인 이유도 바로 이 점임 — 분석 대신 즉시 실행함
결과가 완벽하지 않아도 충분히 쓸 만하고, 필요하면 나중에 최적화하면 됨
프레임워크를 만들기 전에는 최소 세 번 실제 시스템을 만들어봐야 함. 그래야 어디가 과하거나 부족한지 알 수 있음
단, 프로토타입을 실제 제품으로 착각하지 말아야 함
‘충분히 괜찮다’는 말은 자기기만이 될 수 있음
실패한 프로토타입이 시장이 없다는 증거는 아님. 단지 무언가 부족했다는 신호일 뿐임
Hacker News 의견들
“Doing it badly” 원칙이 내 사고방식을 완전히 바꿔놓았음
완벽한 아키텍처를 설계하려고 몇 주를 보냈지만, 결국 계획을 멈추고 내 문제를 해결하는 투박한 버전을 만들었음
놀라웠던 건, 그 첫 버전이 계획으로는 절대 배울 수 없는 걸 가르쳐줬다는 점임. 사용자가 실제로 중요하게 여기는 것, 실전에서 중요한 엣지 케이스, 그리고 ‘충분히 좋은’ 기준이 무엇인지 배웠음
가장 어려운 건 결함이 있다는 걸 알면서도 배포를 허락하는 것임. 하지만 실제 사용에서 오는 피드백 루프는 수주간의 가상 논의보다 훨씬 가치가 있었음
요즘 생산성 관련 서브레딧에 이런 글이 넘쳐남. 개인용 자동화 도구를 만들면서 몇 주 동안 아키텍처를 계획한다는 게 현실적으로 가능한가 의문임
작성자의 댓글 기록을 보면 비슷한 문체가 반복되어 신뢰가 가지 않음
그 과정을 보고 정말 흥미로웠음
실제로 구현하고 리팩터링하는 과정에서 문제와 프로그래밍 전반에 대해 배울 게 많음
처음 생각한 추상화는 대부분 틀림. 구현하다 보면 구조가 완전히 바뀌고, 결국 처음과 전혀 다른 아름다운 코드가 나옴
첫 버전은 버릴 각오로 만들라는 내용인데, 실제로는 대부분 버리지 않고 반복적으로 개선함
지금은 도구와 프로세스 덕분에 계속 iterate할 수 있게 되었음
내부 구조도 반복과 프로토타이핑이 필요하지만, 데이터 구조·에러 처리·로깅·네이밍 같은 부분은 초기에 신중히 결정해야 나중에 빠르게 개선할 수 있음
“Doing it badly is doing the thing”이라는 문장이 마음에 듦
HN에서 배운 교훈인데, 막혔을 때는 완벽하게 하려 고민하지 말고 일단 해보는 게 중요함
처음엔 엉망이라도 조금씩 개선하다 보면 어느새 명확한 그림이 보임. 마치 마법 같음
하나는 Dan Harmon의 writer’s block 조언이고,
다른 하나는 Ira Glass의 “The Gap”임
핵심은 완벽을 기다리지 말고 형편없는 초안이라도 쓰고, 그걸 비평가의 시선으로 고쳐나가라는 것임
그래서 요즘은 완성될 때까지 일부러 “아직 안 됐다”고 말함
나는 먼저 빠르게 만든 뒤, 다듬고, 마지막엔 새로 다시 쓰는 식으로 함
중요한 건 beta 단계에서 완벽주의에 빠지지 않는 것임
사실 점진적 개선이 효과적이라면, 인간이든 AI든 상관없음
예전 회사에서는 경영진을 “문제 감탄 협회”라고 부름
문제를 논의하고 분석하고 책임자를 찾는 데만 몰두했지, 실제로 해결하지는 않았음
결국 중요한 건 ‘실제로 하는 것’ 이었음
가장 좋은 접근은 문제에 대한 애정과 반복적인 해결 의지를 함께 가지는 것임
내부에서 직접 사용하는 dogfooding이 그 균형을 잡는 좋은 방법임
가능한 한 자신에게 유리한 방향으로 결정하는 게 중요함
업데이트를 위한 조율이 줄고, 실제로 일하는 조직이 더 효율적임
이 글은 strangestloop.io의 에세이와 매우 유사함
제목을 보고 익숙하다고 생각했는데, 클릭해보니 다른 사이트였고 게시 시점도 며칠 전이라 놀랐음
내용이 너무 비슷해서 우연이라고 보기 어려움
예전엔 준비가 중요하다고 생각했지만, 어느 순간 준비가 무한 루프가 되는 걸 깨달음
우리 팀은 2페이지짜리 스펙으로 4개월 만에 제품을 완성했는데, 경쟁 팀은 8개월 동안 문서만 쓰다 해체됨
계획은 20%만 해도 80%의 문제를 잡음. 그 이후는 불안이 포장된 엄격함일 뿐임
결국 부끄러운 걸 내놓고 고치면서 배운 게 대부분임
이전 HN 댓글에 인용되어 있음
Analysis paralysis는 실제로 존재함
멈추지 않으려면 일단 시작해야 함. 해피 패스부터 처리하고, 나중에 엣지 케이스를 다듬으면 됨
요즘은 프로토타입 비용이 낮으니, 실패를 두려워하지 말고 시도해야 함
LLM이 놀라울 정도로 효과적인 이유도 바로 이 점임 — 분석 대신 즉시 실행함
결과가 완벽하지 않아도 충분히 쓸 만하고, 필요하면 나중에 최적화하면 됨
프레임워크를 만들기 전에는 최소 세 번 실제 시스템을 만들어봐야 함. 그래야 어디가 과하거나 부족한지 알 수 있음
‘충분히 괜찮다’는 말은 자기기만이 될 수 있음
실패한 프로토타입이 시장이 없다는 증거는 아님. 단지 무언가 부족했다는 신호일 뿐임
이 글은 이전 게시물과 거의 동일한 메시지를 담고 있음
이전 HN 토론에서도 다뤄졌음
반대로, 때로는 ‘doing the thing’ 자체가 잘못된 선택일 때도 있음
그래서 나는 여전히 디자인 문서와 코드 리뷰를 고집함
GenAI 시대에는 ‘계획 없이 대충 해보기’가 너무 쉬워졌기 때문에, 그만큼 균형추가 필요함
비결정성과 지연(latency) 문제로 시간을 다 쓰게 되고, 결국 단위 경제성을 맞추는 게 진짜 도전임
『Remains of The Day』에서는 ‘the thing에 대해 말만 하는 것’을 자기만족적 행위라고 부름
실제로 아무것도 이루지 못하면서 기분만 좋아지는 대화에 그치는 경우가 많음
반면, 계획과 준비, mise-en-place는 실제 실행에 도움이 될 수 있음