단순함은 작음과 다르다: Unix 파이프라인은 작지만 단순하지 않다
Simple Is Not Small
이 글은 '단순함(simple)'과 '작음(small)'을 구분합니다. Rich Hickey의 'Simple Made Easy' 개념을 인용하며, Unix 파이프라인이 각 명령어는 작지만 서로 결합(coupled)되어 있어 복잡하다고 주장합니다. 반대로 Google Drive는 거대하지만 사용자에게는 단순합니다. Rust의 struct와 Clojure의 map 비교를 통해 데이터 표현과 타입 검사의 결합을 분리(decoupling)하는 것이 중요함을 보여줍니다. 저자는 프로그램은 작게 만드는 것보다 단순하게 만드는 것이 항상 더 좋다고 결론짓습니다.
Unix 도구는 작지만 단순하지 않습니다.
HN 토론
16- getnormality
유명한 에세이 "Worse is Better의 부상"[1]과 강하게 공명합니다. 그 에세이는 (더 나은) "MIT/스탠포드 스타일의 설계"와 (더 나쁜) "뉴저지 접근법"을 대조했습니다.
MIT/스탠포드:
> 단순함 -- 설계는 구현과 인터페이스 모두에서 단순해야 한다. 인터페이스가 단순한 것이 구현이 단순한 것보다 더 중요하다.
뉴저지:
> 단순함 -- 설계는 구현과 인터페이스 모두에서 단순해야 한다. 구현이 단순한 것이 인터페이스가 단순한 것보다 더 중요하다. 단순함은 설계에서 가장 중요한 고려 사항이다.
TFA는 "단순함"을 "MIT/스탠포드식 단순함"(사용자를 위한 단순함)에, "작음"을 "뉴저지식 단순함"(개발자를 위한 단순함)에 매핑합니다.
두 학파 사이의 긴장의 근원이 사용자/개발자 구분의 모호함으로 귀결되는지 궁금합니다. 개발자도 사용자입니다. 구현의 단순함은 개발자가 구현 작업을 직접 할 때 도움이 되고, 인터페이스의 단순함은 개발자가 다른 개발자의 작업을 사용할 때 도움이 됩니다.
- hankbond
훌륭한 글입니다. 예시가 매우 직관적이지만, Closure 부분을 이해하는 데는 꽤 오래 골똘히 생각해야 했습니다.
저는 현재 매우 모듈식 소프트웨어를 구축 중인데, 제 경력 전체에서 설계하기 가장 어려운 프로젝트였습니다. 제가 다녔던 어떤 직장에서도 이렇게 견고하고 명확하게 정의된 무언가를 만들기 위해 이 정도의 시간과 노력을 할애받을 수 없었을 것입니다. 이 프로젝트의 많은 측면은 복잡하지 않은 추상화를 얻기 위해 3~5번의 시도와 폐기를 거쳤습니다.
이것이 바로 vibe 코딩이 작고 고립된 스크립트를 만드는 데는 그렇게 성공적이고, 다른 모든 것에는 그렇게 재앙적인 이유입니다. 크고 단순한 무언가를 만드는 것은 정말 어렵습니다.
- jerf
솔직히, 지난 10년 동안 사람들이 '단순함'이 무엇인지에 대해 논쟁하는 것을 지켜보면서, 저는 그것이 잘 정의된 용어가 아니라는 결론에 꽤 도달했습니다. 우리는 복잡함을 확실히 알아보지만, 적어도 그것이 다량으로 존재할 때는 그렇습니다. 그러나 단순함은 단지 복잡함의 부재가 아닙니다. 우리 모두가 같은 단어에 밀어 넣으려는 개념이 적어도 세 가지 있으며, 그것들은 단지 '직교적'이지 않을 뿐만 아니라 종종 서로 충돌합니다. 저는 그것이 재활될 수 있다고 생각하지 않으며, 실제로는 버려져야만 우리가 이 한 단어에 밀어 넣으려는 여러 개념을 특성화하는 길을 열 수 있다고 생각합니다.
특히 어떤 것이 '좋은' 것이고 사람들이 그 용어를 차용하여 그 용어의 좋음을 차용하려 할 때 위험합니다. 마치 좋음이 용어에서 그것에 붙은 대상으로 흐르는 것처럼, 그 반대가 아니라요. '단순함'은 좋으므로 내 좋은 것은 '좋은' 것이 되기 위해 '단순'해야 합니다. 하지만 그렇지 않습니다. 단순함은 잘못된 위치에 있거나 주어진 작업에 대해 잘못된 종류의 '단순함'일 때 나쁠 수도 있습니다.