오랜만에 Clojure 콘텐츠를 즐기다 보니, 고전 글 "The Rise of Worse is Better"가 생각난다.
윗글은 기술적으로 우수하다는 평을 받는 Common Lisp/CLOS가 C/Unix에 뒤처지는 이유를 설명하려 공학 철학을 둘로 나눈다:
1) MIT Style (the right thing)
2) New Jersey Style (worse is better)
MIT Style의 공학은 다음과 같은 가치를 찾는다:
• 심플함: 구현과 인터페이스 모두 심플해야 한다. 인터페이스의 심플함이 구현의 심플함보다 중요하다.
• 올바름: 디자인은 측정할 수 있는 모든 면에서 옳아야 한다. 타협은 없다.
• 일관성: 비일관적인 디자인은 무조건 피한다. 심플함과 완전성을 포기해 일관성을 유지해도 좋다. 올바름 만큼 중요하다.
• 완전성: 대부분 상황에 대처할 수 있어야 디자인이 좋다. 완전성이 크게 훼손되는 심플함은 피한다.
반면 New Jersey Style의 접근은 조금 다르다:
• 심플함: 구현과 인터페이스 모두 심플해야 한다. 구현의 심플함이 인터페이스의 심플함보다 중요하다.
• 올바름: 디자인은 측정할 수 있는 모든 면에서 옳아야 한다. 단 심플함을 위해 예외를 둘 순 있다.
• 일관성: 비일관적인 디자인은 피한다. 심플함을 위해 일관성을 타협해도 되지만, 그냥 일관성이 훼손되는 문제를 포기하는 게 낫다. 인터페이스의 일관성은 중요하지 않다.
• 완전성: 현실적인 상황에 대처할 수 있어야 디자인이 좋다. 완전성을 타협하고 다른 가치를 (특히 심플함) 찾는게 중요.
요약해보면
MIT Style: 올바르고 일관성 있는 "아름다운" 디자인. 주어진 문제를 거의 완전하게 풀어낸다. 단 구현이 어려울 수 있다. (Common Lisp/CLOS)
New Jersey Style: 심플하고 현실적인 디자인. 잘 작동하지 않는 예외 케이스가 많지만, 구현은 쉽다. (C/Unix)
저자는 New Jersey Style 구현체는 MIT Style 보다 생존력이 높아 소프트웨어 개발에 더 적합하다 말한다.
C/Unix는 당대 최고의 언어/운영체제는 아니었지만 구현이 간단해 여러 플랫폼에 포팅할 수 있었다. 대부분 유저는 그 조합이 주는 기능에 만족했고 이 조합은 바이러스처럼 퍼져갔다.
대다수 유저의 선택을 받게 되면 부족한 기능은 자연스럽게 채워지기 마련이다.
유저가 필요한 모든 기능을 구현하기엔 디자인 기반이 부족할 수도 있지만, 대다수 유저의 선택을 받은 이상 높은 투자를 해서라도 고쳐내는 게 새로 시작하는 것보다 싸다.
반면 MIT Style 를 추구한 소프트웨어는 2가지 상황으로 흘러간다:
big complex system: 많은 기능을 갖춘 "완벽한" 디자인의 소프트웨어는 구현체가 크고 복잡하다. 마지막 20%의 기능을 구현하기 위해 80% 노력이 필요하다. 오랜 개발 기간이 필요하고 특수 상황에서만 완벽하게 돌아간다 == 안쓴다
diamond-like jewel: 디자인은 오래 걸렸지만 구현의 어려움이 적다. 단, 디자인을 훼손하지 않고 구현체의 성능을 개선하는 건 불가능하거나 보통의 개발자에겐 난이도가 너무 높다 == 안쓴다.
현시대에 적용해보면 Haskell/Ocaml 같은 경우 MIT Style 같고 Javascript, Go는 New Jersey Style 같다.
또 New Jersey Style와 Agile Manifesto 의 비슷함이 느껴진다. 특히나 "Responding to change over following a plan" 는 같은 철학을 다른 말로 표현한게 아닌가?
agilemanifesto.org/
사실 "Worse is Better" vs "The Right Thing" 의 토론은 아직 끝난 게 아니다. Hacker News에 종종 올라오는 떡밥이고, 올라올 때마다 긴 토론이 이어진다.
개인적으로 MIT Style이라고 생각되는 Rust의 성공도 좋은 반론이라 생각한다.
news.ycombinator.com/item?id=31339826
artima.com/weblogs/viewpost.jsp?thread=24807
