나는 "조기 최적화는 모든 악의 근원"이라는 말을 특히 싫어함. 이 문장은 1974년 맥락에서 나온 말이라 지금과는 전제가 다름. 그때 최적화는 어셈블리와 사이클 계산에 가까웠지만, 지금 성능은 주로 아키텍처 선택의 문제라 시작부터 고려해야 함. 프로파일링으로 우발적 O(n²) 같은 성능 버그를 잡는 조언은 여전히 유효하지만, 추상화 비용이 병목이 된 뒤에는 캐시와 병렬성만 덧대며 더 복잡하고 더 느린 시스템이 되기 쉬움. 지금은 늦은 최적화도 조기 최적화만큼, 어쩌면 더 나쁘다고 봄
이 말은 프로그래밍에서 가장 자주 오해되는 문장 중 하나라고 봄. Donald Knuth의 원문을 직접 읽어보면, 요지는 측정도 없이 필요 없는 성능 개선에 힘을 쓰지 말되, 성능이 핵심인 10% 상황은 예외라는 뜻임. 그런데 이를 "아무것도 측정하지 말라"는 이상한 교리로 받아들이는 경우를 자주 봄
내가 생각하는 진짜 나쁜 조기 최적화는 중요하지도 않은 미세 차이에 집착하는 경우임. 예를 들어 Java에서는 나중에 멀티스레드 문맥으로 갈 수도 있어서 ConcurrentHashMap을 자주 쓰는데, 대부분 상황에서 성능 차이는 크지 않음. 그런데 "HashMap이 더 빠르다"는 이유로 PR이 막히고 끝없는 논쟁이 벌어지곤 함. 그런 것보다 PostgreSQL 블로킹 호출 40개나 불필요한 웹 요청 같은, 체감 차이를 만드는 곳에 집중하는 편이 맞다고 봄. 다만 알고리즘 수준의 이른 최적화는 충분히 괜찮다고 생각함
나는 "조기 최적화" 대신 성숙한 최적화만 한다고 농담처럼 말함. 프레임워크를 쌓기 전에 사용 방식, 데이터 접근 패턴, 성능 요구사항을 먼저 생각하는 건 아주 성숙한 접근임. 대부분은 사이클 계산까지 갈 필요는 없지만, bulk load인지 단건 처리인지, 동시성이나 분산을 고려해야 하는지 같은 판단은 초기에 해두면 차이가 큼. 성능은 나중에 생각해도 된다는 진영은 이후 개선에서 자주 막히는 편임
나는 작년에 요청마다 40ms를 더 먹게 만드는 추상화 계층을 걷어내는 데 6개월을 씀. 프로파일링으로 hot path를 찾았지만 재작성 없이는 해결이 안 됐음. "나중에 최적화하자"는 쪽은 그 나중이 사실상 영원히 오지 않을 수 있음을 잘 말해주지 않음
나는 현대 도구들로는 확장 가능한 설계를 비교적 쉽게 만들 수 있다고 봄. 그래서 조기 최적화란 이미 충분히 괜찮은 부분을 굳이 더 깎는 행위이지, 처음부터 엉망인 코드를 써도 된다는 뜻은 아니라고 이해함
나는 Curly's Law가 빠진 게 아쉬움. 변수는 한 가지 의미만 가져야 하고, 상황에 따라 다른 도메인의 값을 담거나 두 역할을 동시에 해서는 안 됨. "바닥 광택제이면서 디저트 토핑" 같은 상태가 되지 말아야 한다는 비유가 딱 들어맞음
나는 그 "바닥 광택제이자 디저트 토핑" 비유가 아주 보편적인 법칙은 아닐 수도 있다고 농담하고 싶음. 식당 근처에서 청소 일을 해본 입장에선, 취하게 해준다고 하면 바닥 광택제를 토핑처럼 먹어보려는 사람도 꽤 있을 것 같다는 생각임
나는 이 원칙을 이름으로는 몰랐지만 몸으로 배운 적이 있음. 예를 들어 x가 0이 아니면 y를 0으로 만드는 규칙이 있다면, x가 0인지 알고 싶다고 y를 우회 신호처럼 보면 안 됨. 더 나쁘게는 남는다고 y를 다른 용도로 재활용하면 안 됨
나는 Shellac이 실제로 바닥 광택제이면서 식품 첨가물이기도 했다는 점이 떠오름. 요즘은 더 나은 대체재가 있지만, 예전에는 특히 사탕 쪽에서 쓰였고 지금도 관악기 접착제로는 쓰인다고 알고 있음
나는 Google에서 쓰던 absl::StatusOr를 꽤 좋아했음
나는 이런 상황을 보통 POSIWID라는 이름으로 부름
나는 이런 소프트웨어 "법칙"들을 한데 모아두면 서로 내부 모순이 너무 많아서, 결국 자기 주장을 정당화해주는 문장 하나를 골라 쓰기 쉬워진다고 느낌. 진짜 어려운 건 언제 어떤 법칙을 깨야 하는지, 그리고 왜 깨는지 아는 일임
나는 Postel's Law와 Hyrum's Law의 충돌이 대표 사례라고 봄. 입력을 관대하게 받으면 API의 관찰 가능한 모든 동작에 누군가 의존하게 되고, 나중에 엄격하게 바꾸는 순간 문서화되지 않았더라도 호환성 파괴가 됨. 그래서 내가 내린 결론은, 내가 통제하는 내부 경계에서는 엄격하게 받고, 클라이언트 업그레이드를 강제할 수 없는 외부 경계에서만 관대해지는 방식임. 다만 현실에서는 그 경계를 구분하는 일이 가장 어려운 편임
나는 이런 모순의 대표 예시로 DRY를 자주 듦. 비슷한 함수 두 개를 쓰지 않으려다가 개념적 복잡도를 하늘까지 띄우는 경우를 특히 많이 봤음
나는 꽤 오래 일한 SWE로서 지금도 KISS와 YAGNI만으로 엄청난 효용을 얻고 있음. 소프트웨어 엔지니어링의 많은 부분이 과도한 설계라고 느끼고, 솔직히 이 사이트도 그렇다고 봄. 다른 공학 분야에선 자재비와 인건비가 눈에 보이기 때문에 이런 식의 과잉을 오래 못 버팀
나는 Amazon의 Leadership Principles도 비슷했다고 느낌. 대체로 그럴듯한 지침이지만, 실제 논쟁에서는 어떤 원칙을 가장 그럴듯하게 무기화해서 내 주장에 붙일 수 있느냐의 싸움이 되곤 했음. 꼭 나쁘기만 한 건 아닐 수도 있다고도 생각함
나는 형식적인 IT 법칙 전쟁 대신 Dan North의 CUPID 같은 대안을 더 좋아함. joyful coding을 위한 속성들이라는 점에서 SOLID보다 더 실용적으로 느껴짐
나는 2026년판 소프트웨어 공학 법칙으로, 모든 웹사이트가 Claude Opus로 vibe coding될 거라고 농담하고 싶음. 그 결과 배경색은 Anthropic을 닮은 크림톤이 되고, 폰트와 두께는 디자인 입문자가 막 타이포그래피를 배운 것처럼 과하게 섞이며, 카드 UI는 넘쳐나고 카드 한쪽 면에만 둥근 컬러 테두리가 들어가는 식의 패턴이 반복될 것 같음
나는 그 사이트를 vibe coding한 사람이 책도 vibe coding했을 가능성이 높다고 보고 바로 패스하고 싶음. 게다가 이 사람의 코딩 이력을 찾아보니 치트시트와 로드맵 위주라, 책 내용에도 신뢰가 거의 생기지 않음
나는 도메인도 분명 긴 제목 그대로 .com이 붙는 형태일 거라고 예상함
나는 Boyd's Law of Iteration도 들어가야 한다고 생각함. 복잡성을 다룰 때는 깊이 있는 분석보다 빠른 반복이 더 좋은 결과를 내는 경우가 많다는 말인데, Boyd가 OODA loop를 만든 사람이라는 점까지 생각하면 더 인상적임
나는 이 법칙이 정말 좋고 더 많은 사람이 이해했으면 함. 관리나 비즈니스 쪽은 선행 계획을 원하지만, 소프트웨어는 처음부터 모든 문제를 예측할 수 없음. 처음부터 딱딱한 구조를 설계해 스스로를 가두기보다, 유연한 아키텍처 위에서 리팩터링하며 문제를 해결하는 편이 더 효과적이라고 봄
나는 일반적으로 지나치게 신중한 개발보다 반복적 개발이 더 낫다고 봄. 전투기 조종간 사례도 아주 미묘하고 좋은 예시였음. 이 얘기를 보니 대학 시절 빌드 시간이 10분씩 걸리던 고통스러운 프로젝트가 떠오름. 실제 구현 대신 제공된 mock 컴포넌트로 바꿔 써야 했는데 그걸 늦게 알아채서 마감 전에 끝내지 못했음. 그 뒤로는 항상 빌드 시간을 줄이는 방법을 먼저 찾게 됨
나는 Boyd의 법칙을 너무 극단으로 밀어붙이면 1주 스프린트 이하 같은 형태로 흐르기도 한다고 느낌
나는 삭제된 댓글 중에 이 글에 대한 최고의 메타 법칙이 있었다고 생각함. "모든 소프트웨어 공학 법칙은 즉시 오해되고, 원 저자가 경악할 방식으로 무비판적으로 적용된다"는 내용이었는데, 핵심 맥락이 빠진 LLM의 행동을 보면 왜 그런지 더 잘 이해된다고 느낌. 결국 수십 년의 지혜와 경험을 한 줄 명언으로 압축하는 데는 한계가 있음
나는 "'소프트웨어 공학의 법칙' 목록 사이트"를 통째로 vibe coding할 바에야 그냥 Wikipedia 페이지를 만들지 않은 건 무슨 법칙을 어긴 거냐고 묻고 싶음
나는 "Wikipedia 페이지를 만들라"는 제안도 좀 이상하게 들림. 2026년의 Wikipedia는 사실상 Wikipedia 문화권의 깊은 전문가가 아니면 새 페이지를 만들기 어려운 곳처럼 느껴짐. 위키 고수들은 137개 지침만 따르면 누구나 만들 수 있다고 하지만, 현실에선 관리자에게 삭제당하기 쉽다는 냉소가 있음
나는 그 법칙 이름을 Slop's Law라고 붙이고 싶음. 대충 만들 수 있으면 결국 대충 만들어진다는 뜻임
나는 2026년판 Sturgeon's Law로 "모든 것의 99%는 crap 또는 slop"이라고 요약하고 싶음
나는 이런 내용이 취업 요건일 정도로 기본 교양이었으면 좋겠다고 생각함. 모두가 알아야 할 이야기처럼 느껴짐
나는 목록에 있는 Law of Unintended Consequences도 같은 현상을 설명한다고 봄. 그래도 개인적으로는 그 법칙보다 울타리 이야기가 더 마음에 듦
나는 이 원칙을 내 핵심 원칙 중 하나로 삼고 있고, 한마디로 하면 생각하고 행동하기라고 봄
나는 Tesler의 복잡성 보존 법칙이 문장 자체로는 바로 통찰을 준다고 느낌. 모든 애플리케이션에는 제거할 수 없고 이동만 가능한 고유 복잡성이 있다는 말임. 다만 설명으로 들어가면 결국 사용자를 덜 괴롭히라는 평범한 조언으로 축소되는 것 같아 흥미가 조금 줄어듦. 사용자는 필요한 수준의 복잡성은 결국 가져야 하고, 무턱대고 줄이면 유연성 없는 장난감이 되기 쉬움. 그래서 나는 리팩터링할 때 한 부분을 단순화하면 다른 부분이 더 복잡해질 수 있다는 점을 기억하는 쪽이 더 유용하다고 봄
Hacker News 의견들
나는 "조기 최적화는 모든 악의 근원"이라는 말을 특히 싫어함. 이 문장은 1974년 맥락에서 나온 말이라 지금과는 전제가 다름. 그때 최적화는 어셈블리와 사이클 계산에 가까웠지만, 지금 성능은 주로 아키텍처 선택의 문제라 시작부터 고려해야 함. 프로파일링으로 우발적 O(n²) 같은 성능 버그를 잡는 조언은 여전히 유효하지만, 추상화 비용이 병목이 된 뒤에는 캐시와 병렬성만 덧대며 더 복잡하고 더 느린 시스템이 되기 쉬움. 지금은 늦은 최적화도 조기 최적화만큼, 어쩌면 더 나쁘다고 봄
나는 Curly's Law가 빠진 게 아쉬움. 변수는 한 가지 의미만 가져야 하고, 상황에 따라 다른 도메인의 값을 담거나 두 역할을 동시에 해서는 안 됨. "바닥 광택제이면서 디저트 토핑" 같은 상태가 되지 말아야 한다는 비유가 딱 들어맞음
나는 이런 소프트웨어 "법칙"들을 한데 모아두면 서로 내부 모순이 너무 많아서, 결국 자기 주장을 정당화해주는 문장 하나를 골라 쓰기 쉬워진다고 느낌. 진짜 어려운 건 언제 어떤 법칙을 깨야 하는지, 그리고 왜 깨는지 아는 일임
나는 2026년판 소프트웨어 공학 법칙으로, 모든 웹사이트가 Claude Opus로 vibe coding될 거라고 농담하고 싶음. 그 결과 배경색은 Anthropic을 닮은 크림톤이 되고, 폰트와 두께는 디자인 입문자가 막 타이포그래피를 배운 것처럼 과하게 섞이며, 카드 UI는 넘쳐나고 카드 한쪽 면에만 둥근 컬러 테두리가 들어가는 식의 패턴이 반복될 것 같음
나는 Boyd's Law of Iteration도 들어가야 한다고 생각함. 복잡성을 다룰 때는 깊이 있는 분석보다 빠른 반복이 더 좋은 결과를 내는 경우가 많다는 말인데, Boyd가 OODA loop를 만든 사람이라는 점까지 생각하면 더 인상적임
나는 삭제된 댓글 중에 이 글에 대한 최고의 메타 법칙이 있었다고 생각함. "모든 소프트웨어 공학 법칙은 즉시 오해되고, 원 저자가 경악할 방식으로 무비판적으로 적용된다"는 내용이었는데, 핵심 맥락이 빠진 LLM의 행동을 보면 왜 그런지 더 잘 이해된다고 느낌. 결국 수십 년의 지혜와 경험을 한 줄 명언으로 압축하는 데는 한계가 있음
나는 "'소프트웨어 공학의 법칙' 목록 사이트"를 통째로 vibe coding할 바에야 그냥 Wikipedia 페이지를 만들지 않은 건 무슨 법칙을 어긴 거냐고 묻고 싶음
나는 이런 내용이 취업 요건일 정도로 기본 교양이었으면 좋겠다고 생각함. 모두가 알아야 할 이야기처럼 느껴짐
나는 소프트웨어 전용 법칙은 아니어도 Chesterton's Fence를 인턴과 신입에게 가장 먼저 가르치는 편임
나는 Tesler의 복잡성 보존 법칙이 문장 자체로는 바로 통찰을 준다고 느낌. 모든 애플리케이션에는 제거할 수 없고 이동만 가능한 고유 복잡성이 있다는 말임. 다만 설명으로 들어가면 결국 사용자를 덜 괴롭히라는 평범한 조언으로 축소되는 것 같아 흥미가 조금 줄어듦. 사용자는 필요한 수준의 복잡성은 결국 가져야 하고, 무턱대고 줄이면 유연성 없는 장난감이 되기 쉬움. 그래서 나는 리팩터링할 때 한 부분을 단순화하면 다른 부분이 더 복잡해질 수 있다는 점을 기억하는 쪽이 더 유용하다고 봄