엔지니어링 철학: Rich Hickey, 단순함은 쉬움이 아니다

핵심 요점

• 단순함은 쉬움이 아닙니다. 단순함(simple)이란 엮이지 않은 상태, 즉 한 가지에 하나의 관심사만 담긴 상태를 뜻하며 객관적입니다. 쉬움(easy)이란 익숙하고 손에 가까이 있다는 뜻이며 주관적입니다. 우리는 끊임없이 쉬운 쪽을 고르고는 그것을 단순하다고 잘못 부릅니다.
• 얽음(complecting)이 복잡함의 뿌리입니다. 복잡함은 부품의 개수가 아니라 그것들이 얼마나 뒤엉켜 있는가의 문제입니다. 상태를 시간에, 정체성을 행동에, 정책을 메커니즘에 함께 엮어 놓는 일이야말로, 그저 잘 돌아가기를 빌 수밖에 없는 시스템을 만들어 냅니다.
• 집요하게 풀어 헤치십시오(decomplect). 얽혀 있는 관심사들을 독립적인 조각으로 떼어 내어 의도적으로 조립하십시오. 단순함은 “하나의 선택”이며 “끊임없는 경계”를 요구합니다. 익숙한 도구로 손을 뻗는다고 해서 저절로 찾아오는 법은 결코 없습니다.
• 장소(place)보다 값(value)을, 객체(object)보다 데이터(data)를 택하십시오. 불변성을 기본값으로 삼고, 상태를 제자리에서 덮어쓰는 대신 과거가 불변의 사실로 쌓이도록 하십시오. 이것이 Clojure와 Datomic 양쪽을 떠받치는 규율입니다.

원칙

“이 단어의 어원은 ‘sim’과 ‘plex’인데, 이는 ‘하나의 접힘 또는 엮임’을 뜻합니다 […] 그리고 그 바로 옆에, 혹은 정반대편에 ‘complex’가 있는데, 이는 ‘함께 엮인’ 또는 ‘함께 접힌’을 뜻합니다.” – Rich Hickey, Simple Made Easy¹

소프트웨어 품질을 둘러싼 거의 모든 논쟁은 사실 하나의 단어를 뒤집어쓴 두 개의 논쟁이며, Rich Hickey가 기여한 바는 그 둘을 떼어 놓은 것입니다. 단순함과 쉬움은 동의어가 아닙니다. 심지어 같은 축 위에 있지도 않습니다. 하나는 대상 자체를 재고, 다른 하나는 그 대상으로부터 당신이 떨어진 거리를 잽니다. 단순함은 라틴어 simplex에서 왔습니다. 하나의 접힘, 하나의 엮임, 하나의 꼬임이라는 뜻입니다. 이는 대상 그 자체를 묘사합니다. 그 안에 몇 개의 관심사가 뒤섞여 있는가를 말이죠. 단순함은 객관적이며, 그 반대말은 복잡함(complex) – 함께 엮인, 제 위로 접혀 포개진 상태입니다. 이와 대조적으로 쉬움은 “가까이 놓여 있다”를 뜻하는 어근에서 나왔는데, 이는 인접(adjacent)과 같은 어근입니다.² 쉬움은 그 대상과 당신의 관계를 묘사합니다. 그것이 손에 얼마나 가까운지, 얼마나 익숙한지, 시작하는 데 얼마나 적은 수고가 드는지를 말이죠. 쉬움은 주관적이며, 그 반대말은 어려움(hard)입니다.¹²

이 구분을 한 번 보고 나면 다시는 못 본 척할 수 없습니다. npm install 한 번이면 손에 들어오기 때문에 당신이 손을 뻗는 그 도구는 쉬운 것입니다. 그것이 단순한지 – 영속성을 검증 로직에, 검증 로직을 UI에, UI를 비즈니스 규칙에 뒤엉키게 만드는지 – 는 완전히 별개의 질문이고, 그 답은 대개 아니오입니다. 우리는 끊임없이 쉬운 것을 고르고는 단순하다고 부르며, 그렇게 스스로 불러들인 복잡함 속에 빠져 익사합니다. 뒤엉키게 하는 그 행위를 가리키는 Hickey의 단어가 바로 complect(얽다)입니다. “서로 끼워 넣거나 휘감거나 땋는 것”이죠.³ 얽음은 원죄입니다. 추론할 수 있던 시스템을, 그저 잘 되기를 빌 수밖에 없는 시스템으로 바꿔 놓는 것이 바로 얽음입니다. 일단 두 관심사가 함께 땋이고 나면, 다른 하나를 이해하고 그 위험을 감수하지 않고서는 더 이상 한쪽을 건드릴 수 없게 되기 때문입니다.

그러므로 규율은 풀어 헤치는 것(decomplect) – 얽힌 관심사들을 집요하게 독립적인 조각들로 떼어 내는 것 – 이며, Hickey는 그 대가에 대해 단도직입적입니다. “단순함은 선택입니다.” 그는 말합니다. “단순한 시스템을 갖지 못했다면 그건 당신 탓입니다.”⁴ 그것은 익숙한 도구로 손을 뻗는다고 일어나지 않습니다. “끊임없는 경계”와 의도적인 정성을 통해서만 일어납니다.⁴ 원칙 전체가 다섯 글자에 담겨 있습니다. 단순함은 쉬움이 아니다. 단순함은 더 힘들고, 선택되어야 하며, 엮이지 않은 길이고, 복리로 불어나는 유일한 길입니다. 똑같은 확신이 품질이 유일한 변수다라는 주장 밑에도 깔려 있습니다. 매번 편한 걸음을 택해서는 깔끔한 시스템에 슬그머니 도달하는 법이 없습니다. 경사를 거슬러, 매번, 그것을 선택해야 합니다.

맥락

Rich Hickey는 독립 프로그래머로, 자신을 알린 그것을 만들어 내기 전까지 약 20년간 C++, Java, C# 시스템을 짜며 생계를 꾸렸습니다.⁵ 그는 그 언어들로 큰 시스템을 만드는 법을 알고 있었고, 20년 끝에 내린 그의 결론은 그 언어들에 기능이 부족하다는 게 아니었습니다. 그것들이 얽음 기계라는 것이었습니다. 관심사를 함께 땋는 일은 거의 힘들이지 않게 만들어 주면서, 그것을 다시 풀어 내는 데에는 거의 아무런 도움도 주지 않는 기계 말입니다.

그래서 그는 그 대안을 홀로, 손수 지었습니다. 2005년 무렵부터 Hickey는 약 2년 반 동안 Clojure를 개발했는데, 그 상당 기간을 봉급도 없이 자비로 충당하며 Java Virtual Machine 위에서 도는 Lisp을 만들었습니다. 불변성과 단순함을, 영웅적 행위가 아니라 가장 저항이 적은 길로 만들어 줄 언어를 말이죠.⁵ 그는 그것을 2007년에 공개했습니다. 뒤에 회사도, 위원회도, 보조금도 없었습니다. 그 병을 가까이서 지켜본 한 명의 프로그래머가, 치료제를 짓는 데 자기 자신의 활주로를 몇 년이나 쓰기로 결심한 것이었습니다. 그는 이후 불변 데이터베이스인 Datomic을 만들었고,⁵ 일련의 콘퍼런스 강연들 – Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet? – 을 했는데, 이것들은 통틀어 현대 함수형 프로그래밍에서 가장 영향력 있는 설계 철학의 몸체입니다.⁶

작업

Simple Made Easy: 단순함 대 쉬움, 그리고 얽음

2011년 9월 Strange Loop에서 발표된 Simple Made Easy는 한 세대의 프로그래머들이 복잡함을 이야기하는 방식을 재편한 강연입니다.¹ 그 힘 전체는 단순함과 쉬움이 같은 뜻이기를 거부하는 데서 나옵니다. 단순함은 구성물에 관한 것입니다. 하나의 접힘인가, 아니면 여럿이 함께 땋인 것인가? 쉬움은 당신에 관한 것입니다. 손에 가까운가, 익숙한가, 지금 당신의 능력 안에 있는가? 단순하지만 낯선 것(배우기는 어렵지만 함께 살기는 편한 것)도 있을 수 있고, 쉽지만 복잡한 것(익숙하고 편안하지만 조용히 파멸로 이끄는 것)도 있을 수 있습니다. 업계가 생산성이라며 파는 것의 대부분은 두 번째 부류입니다.¹

그 한가운데 있는 동사가 complect(얽다) – 땋고, 끼워 넣고, 휘감는 것입니다.³ 시스템을 복잡하게 만드는 것이 바로 얽음입니다. 부품의 개수가 아니라 그것들이 얼마나 뒤엉켜 있는가의 문제죠. 상태는 값과 시간을 얽습니다. 객체는 상태와 정체성과 행동을 얽습니다. 상속, ORM, 메서드 곳곳에 흩뿌려진 조건문 – 저마다 따로 설 수 있었던 관심사들을 땋아 버립니다. 그리고 한 번 땋인 대가는 한 번으로 끝나지 않습니다. 앞으로의 모든 변경마다 치러야 합니다. 다른 모든 가닥을 흐트러뜨리지 않고서는 더 이상 한 가닥도 건드릴 수 없기 때문입니다.

해법은 풀어 헤치는 것(decomplect) – 가닥들을 떼어 내어, 나중에 당신만의 조건으로 조립할 수 있는 독립적인 것들로 만드는 것입니다. Hickey의 주장은, 그것도 꽤 강한 주장인데, 풀어 헤친다고 해서 힘을 잃는 게 아니라는 것입니다. “여러분은 극적으로 더 단순한 도구로도 똑같이 정교한 시스템을 쓸 수 있습니다.” 그는 말합니다. 똑같은 프로그램이되, 실제로 추론하고 바꾸고 신뢰할 수 있는 프로그램일 뿐이라는 것이죠.⁴ 단순함은 능력의 초보자용 축소판이 아닙니다. 그것은 땋기를 거부하는 전문가의 규율입니다.

Clojure: JVM을 위한 Lisp, 객체보다 데이터

Clojure는 그 원칙을 실행 가능한 형태로 옮긴 것입니다. JVM 위에서 도는 동적·함수형 Lisp 방언으로, Hickey가 “동시성을 위해 설계된 기성 플랫폼과 공생하는, 함수형 프로그래밍을 위한 Lisp”으로 설계했습니다.⁷ 두 가지 결정이 그 철학을 새겨 넣습니다. 첫째, 불변성은 선택지가 아니라 기본값입니다 – Clojure의 핵심 자료 구조는 불변이며 영속적이라, 가장 자연스럽게 짜게 되는 것이 곧 멀리 떨어진 곳의 변경으로 망가질 수 없는 것이기도 합니다.⁷ 둘째, 객체보다 데이터입니다. 저마다 비공개 상태와 행동을 얽어 놓은 맞춤형 클래스가 끝없이 펼쳐지는 대신, Clojure는 “소수의 주요 자료 구조 위에 정의된 다수의 함수” – 시퀀스, 맵, 벡터, 집합 – 를 선호합니다.⁷ 그냥 맵을 쓰십시오. 그냥 데이터를 쓰십시오.

이 갈라침은 언어 문법 수준에서의 풀어 헤치기입니다. 객체는 상태와 정체성과 행동을 하나의 봉인된 덩어리로 땋아 넣습니다. Clojure는 그것들을 떼어 냅니다 – 어떤 것이 무엇인지에는 불변의 값을, 그것에 무엇을 하는지에는 평범한 함수를, 시간에 걸친 관리된 변경에는 명시적인 참조 타입을 씁니다. JVM과 싸우는 대신 그것을 플랫폼으로 삼음으로써, Hickey는 언어를 런타임으로부터도 풀어 헤쳤습니다. Clojure는 JVM의 성숙함과 라이브러리와 성능을 거저 얻고, 자신의 새로움 예산은 전부 상태와 시간의 모델에 쏟습니다.⁷

The Value of Values: 불변성과 Datomic

The Value of Values는 불변성 논증을 한 단계 위로, 데이터베이스 그 자체로 끌어올립니다. Hickey의 표적은 그가 장소 지향 프로그래밍(place-oriented programming, PLOP)이라 부르는 것입니다. “새 정보가 옛 정보를 대체할 때마다, 여러분은 장소 지향 프로그래밍을 하고 있는 겁니다.”⁸ 우리는 레코드를 제자리에서 갱신하고, 옛 값은 사라지며, 그와 함께 이력도 사라집니다. 그는 이것이 메모리가 귀하던 시대의 잔재이며, 사업이 추론하는 데 정확히 필요한 것 – 과거 – 을 내다 버린다고 주장합니다. 이와 대조적으로 값(value)은 정의상 불변입니다. 사실(fact)이란 “일어난 어떤 것, 일어났다고 알려진 어떤 것”이며, 사실은 갱신될 수 없고 오직 더 새로운 사실로 대체될 뿐입니다.⁸ 새 대통령은 옛 대통령을 덮어쓰지 않습니다. 덧붙일 뿐입니다.

Datomic은 그 발상을 데이터베이스로 지은 것입니다. 그것은 근본적으로 불변입니다. “Datomic 데이터베이스는 datom이라 불리는 불변의 원자적 사실들의 집합”이며, “Datomic 트랜잭션은 datom을 추가할 뿐 결코 갱신하거나 제거하지 않으므로, 완전한 감사 추적을 갖게 됩니다.”⁹ 아무것도 덮어쓰이지 않으므로, 데이터베이스는 특정 시점의 값으로 다룰 수 있습니다. 현재에 던지는 것과 똑같은 질의를, 아무런 변경 없이 과거의 어느 순간 “기준(as-of)”으로도 던질 수 있습니다.⁹ 데이터베이스는 하나의 가변적 장소이기를 멈추고, 시간에 걸친 값들의 연속이 됩니다. 상태와 정체성과 시간 – 운영 중인 데이터 저장소 안에서, 풀어 헤쳐진 것입니다.

Hammock-Driven Development: 먼저 생각하라

이 모든 것의 동반자는 정작 언제 진짜 작업이 일어나는가에 관한 강연이고, Hickey의 답은 이렇습니다. 키보드에 손을 대기 전에, 입니다. Hammock-Driven Development에서 그는 “버그를 고치는 가장 값싼 장소는 소프트웨어를 설계할 때”이며, 심각한 소프트웨어 실패의 대부분은 오인(misconception)의 실패라고 주장합니다 – 풀기 시작하기 전에 문제를 이해하지 못한 것이죠.¹⁰ 그 처방은 문제를 명시적으로 진술하고, 사실과 제약을 모은 다음, 생각하는 것입니다 – 분석적인 “깨어 있는 마음”이 억지로 만들어 낼 수 없는 연결을 짓는 “배경의 마음”에 문제를 넘겨주는 것까지 포함해서요.¹⁰ 해먹은 방해받지 않고 오직 생각만 하기 위한 말 그대로의 가구입니다.

Hammock-driven development는 단순함을 애초에 가능하게 만드는 실천입니다. 아직 이해하지 못한 시스템은 풀어 헤칠 수 없고, 컴파일을 향해 내달리는 동안에는 그것을 이해할 수 없습니다. Hammock-driven development는 단순함은 쉬움이 아니다의, 화려할 것 없는 앞 절반입니다. 엮이지 않은 설계가 나타나기 전에 반드시 일어나야 하는, 의도적이고 느리며 경계를 늦추지 않는 사고 말입니다.

방법

방법은 하나의 구분 – 단순함은 쉬움이 아니다 – 을, 하나의 언어와 하나의 데이터베이스와 하나의 작업 방식에 걸쳐 보기 드문 고집스러움으로 적용한 것입니다.

모든 결정에 앞서 “단순함”을 “쉬움”으로부터 떼어 놓으십시오. 어떤 도구나 설계에 대해서든 물으십시오. 이것은 엮이지 않은(단순한) 것인가, 아니면 그저 익숙하고 손에 가까운(쉬운) 것인가? 둘은 서로 다른 축이고, 그 둘을 뭉뚱그리는 것이야말로 복잡함이 생산성으로 변장하고 슬쩍 들어오는 길입니다.¹²

얽음을 사냥해 풀어 헤치십시오. 복잡함은 부품의 수가 아니라 그것들이 얼마나 뒤엉켜 있는가입니다. 상태가 시간에, 정체성이 행동에, 정책이 메커니즘에 땋여 있는 곳을 찾아내어 – 가닥들을 의도적으로 조립하는 독립적인 조각들로 떼어 내십시오.³

장소와 객체보다 값과 데이터를 택하십시오. 불변성을 기본값으로 삼으십시오. 정보를 평범한 데이터 – 맵, 벡터 – 로 나타내고, 상태와 행동을 객체 안에 함께 봉인하는 대신 함수로 그 위에서 작동하십시오.⁷⁸

과거를 덮어쓴 상태가 아니라 값으로 다루십시오. 새 정보는 파괴하는 게 아니라 덧붙여야 합니다. 불변의 사실을 시간에 걸쳐 쌓아 가는 시스템은 추론하고, 감사하고, 어느 순간 기준으로든 질의할 수 있습니다 – 제자리에서 덮어쓰이는 장소는 결코 그럴 수 없는 일이죠.⁸⁹

타자하기 전에 생각하십시오. 결함을 고치는 가장 값싼 장소는 설계 단계입니다. 문제를 진술하고, 그것을 당신의 배경의 마음에 먹이고, 먼저 문제를 이해함으로써 단순한 설계를 벌어들이십시오.¹⁰

단순함은 힘들고 선택되는 것임을 받아들이십시오. 그것은 쉬운 것으로 손을 뻗는다고 찾아오지 않습니다. “단순함은 선택”이며 “끊임없는 경계”를 요구합니다. 편한 길과 단순한 길이 같은 길인 경우는 드뭅니다.⁴

영향의 사슬

그를 빚은 이들

Lisp과 John McCarthy. Clojure는, Hickey 자신의 표현을 빌리면, “하위 호환성에 얽매이지 않은 Lisp”입니다 – 코드가 곧 데이터인 동형성(homoiconicity)과 매크로의 힘은 McCarthy의 계보에서 곧장 나왔고, 그것을 단지 리스트가 아니라 맵과 벡터로까지 확장한 것입니다.⁷ (직접적 영향)

John Backus와 함수형 프로그래밍 전통. Backus의 1977년 튜링상 강연 Can Programming Be Liberated from the von Neumann Style?는 대입 중심의, 장소 지향적 계산에 반대하는 정전과도 같은 논증입니다. Hickey가 장소 지향 프로그래밍과 가변 상태에 맞서 벌이는 전쟁은 그 논증을 운영 환경으로 끌고 들어온 것입니다. (형성적 영향)

Java Virtual Machine. 런타임을 추상화로 치워 버려야 할 적으로 다루는 대신, Hickey는 JVM을 플랫폼으로 삼고 그 위에 언어를 지었습니다 – “언어”를 “런타임”으로부터 의도적으로 풀어 헤친 것이며, 그 덕에 Clojure는 첫날부터 성숙함과 도달 범위를 얻었습니다. (직접적 영향)

관계형 및 값 지향적 사고. 시간에 걸쳐 쌓인 불변의 사실로 데이터를 보고 어느 시점 기준으로든 질의할 수 있다는 Datomic의 관점은, 사실을 그 저장소로부터 분리하는 관계형 전통 – 정보는 지금 그것을 담고 있는 장소와 무관하게 독립적으로 존재한다는 발상 – 에서 내려왔습니다.⁸⁹ (형성적 영향)

그가 빚은 것들

함수형 프로그래밍의 르네상스. Clojure는 JVM 위의 Scala 등과 더불어 함수형 프로그래밍을 학술적 호기심에서 주류 운영 환경으로 옮기는 데 일조했고, Hickey의 강연들은 일하는 프로그래머들이 이제 설계를 논할 때 쓰는 공통 어휘 – “simple”, “easy”, “complect” – 가 되었습니다.

주류로 들어온 불변성. 불변을 기본으로 하는 데이터가 별난 제약이 아니라 제정신인 기본값이라는 발상은 Clojure를 한참 넘어 퍼져 나갔습니다. 그것은 이제 업계 전반의 언어·라이브러리 설계에서 기본 전제입니다.

React, Redux, 그리고 프런트엔드 세계. 값 지향 모델 – 불변 상태, 데이터 위의 순수 변환, 정체성과 상태의 분리 – 은 React, 특히 Redux의 개념적 척추입니다. 한 세대의 프런트엔드 엔지니어들이, 그것이 누구의 것인지는 늘 알지 못한 채로 Hickey의 값 사고를 흡수했습니다.

관통하는 선

John Carmack은 렌더러를 빠르고 단순한 핵심으로 벗겨 내고, 안쪽 루프에 느림을 땋아 넣을 모든 기능을 거부합니다. Hickey는 시스템을 엮이지 않은 관심사들로 벗겨 내고, 그것들을 얽을 모든 추상을 거부합니다. 둘 다 단순함을 기본값이 아니라 힘들고 선택되는 것으로 다룹니다. 그리고 Linus Torvalds가 특수한 경우를 일반적인 경우 속으로 사라지게 만드는 “좋은 취향”을 귀히 여긴다면, Hickey는 뒤엉킨 두 관심사를 따로 떼어 세우는 풀어 헤치기를 귀히 여깁니다 – 같은 직감을 반대편 끝에서 본 셈입니다. 올바른 구조란 문제 위에 얹은 장식이 아니라, 문제를 그 진짜 부분들로 올바르게 분리해 낸 것입니다. Yukihiro Matsumoto는 Ruby를 짜는 느낌 – Hickey의 어휘로는 쉬움 – 에 맞춰 최적화했고, Hickey는 그 대상이 무엇인가 – 단순함 – 에 맞춰 최적화했습니다. 둘이 함께, Hickey가 강연 하나를 통째로 들여 우리에게 그만 혼동하라고 다그쳤던 그 두 축을 지도 위에 그려 놓습니다. (시리즈 가교)

내가 여기서 얻는 것

내가 간직하는 교훈은, 쉬움이란 미덕으로 차려입은 함정이라는 것입니다. 코드베이스의 거의 모든 후회는 손에 가까운 것으로 손을 뻗는, 그럴듯해 보이는 동작에서 시작되었습니다 – 편리한 라이브러리, 빠른 변경(mutation), 이미 있던 클래스에 슬쩍 접어 넣은 책임 하나. 그 어느 것도 실수처럼 느껴지지 않았습니다. 쉬움은 결코 그렇게 느껴지지 않으니까요. Hickey가 준 선물은 그것을 그 순간에 붙잡을 어휘입니다. 멈춰 서서 이것은 단순한가, 아니면 그냥 쉬운가?를 묻고, 정직한 답은 대개 불편한 쪽이라는 것을 아는 것 말입니다. 그것은 품질이 유일한 변수라는 것과 똑같은 기준입니다 – 질문은 결코 “무엇에 가장 빨리 닿을 수 있는가?”가 아니라 “여기서 실제로 엮이지 않은 것은 무엇인가?”입니다.

지금 내가 짓는 세계에서 – 에이전트, 도구 루프, 상태와 프롬프트와 재시도와 부수 효과가 하나의 다스릴 수 없는 덩어리로 서로를 땋아 대기 좋아하는 하네스 코드에서 – 유혹은 최대치의 쉬움입니다. 프레임워크를 쌓아 올리고, 상태를 루프 전체에 문질러 바르고, 결정 로직을 입출력에, 로깅에 얽어, 아무도 전체를 위험에 빠뜨리지 않고는 한 부분도 바꿀 수 없게 만드는 것이죠. Hickey의 수순은 풀어 헤치는 것입니다. 정책을 메커니즘에서 빼내고, 가능한 곳에서는 상태를 불변으로 만들고, 매 실행을 내가 덮어쓰는 장소가 아니라 하나의 값으로 다루는 것입니다. 그 확신 – 취향이란 하나의 기술 시스템이며, 가까이 있는 것으로 손을 뻗어 물려받는 분위기가 아니라 경계를 늦추지 않고 선택하는 것이라는 확신 – 이 2007년의 자비로 지은 Lisp에서 2026년의 에이전트 하네스까지를 관통하는 선입니다. 단순함은 쉬움이 아닙니다. 그래도, 그것을 선택하십시오.

자주 묻는 질문

단순함과 쉬움의 차이는 무엇인가요?

Rich Hickey가 Simple Made Easy에서 제시한 틀에서, 단순함(simple)과 쉬움(easy)은 완전히 다른 축입니다. 단순함은 라틴어 simplex – “하나의 접힘 또는 엮임” – 에서 왔으며 대상 자체를 묘사합니다. 그 안에 얼마나 적은 관심사가 뒤섞여 있는가를 말이죠. 그것은 객관적이며, 반대말은 복잡함(“함께 엮인”)입니다.¹ 쉬움은 “가까이 놓여 있다”를 뜻하는 어근, 곧 인접(adjacent)과 같은 어근에서 나왔으며 그 대상과 당신의 관계 – 얼마나 익숙하고 손에 가까운가 – 를 묘사합니다.² 그것은 주관적이며, 반대말은 어려움입니다. 어떤 것은 단순하지만 낯설 수도, 쉽지만 깊이 복잡할 수도 있습니다. Hickey의 요점은, 우리가 끊임없이 쉬운 쪽을 고르고는 그것을 단순하다고 잘못 부르며, 그 복잡함의 대가를 나중에 치른다는 것입니다.¹

“complect”란 무슨 뜻인가요?

Complect는 Hickey가 Simple Made Easy에서, 관심사들을 함께 땋는 행위를 가리키려 되살린 동사입니다. 그는 직접 정의합니다. “서로 끼워 넣거나 휘감거나 땋는 것을 뜻합니다.”³ 시스템을 복잡하게 만드는 것이 바로 얽음입니다 – 부품의 개수가 아니라 그것들이 얼마나 뒤엉켜 있는가의 문제죠. 두 관심사가 얽히면(가령 상태와 시간, 혹은 정체성과 행동), 다른 하나를 이해하고 그 위험을 감수하지 않고서는 더 이상 한쪽을 바꿀 수 없습니다. 그 처방이 풀어 헤치기(decomplect)입니다. 가닥들을 의도적으로 조립할 수 있는 독립적인 조각으로 떼어 내는 것이죠. Hickey는 풀어 헤치기를 단순한 시스템을 짓는 핵심 규율로 다룹니다.³

Rich Hickey는 무엇을 만들었나요?

Rich Hickey는 독립 프로그래머로, Java Virtual Machine 위에서 도는 동적·함수형 Lisp 방언인 Clojure를 만들었습니다. 그는 약 2년 반에 걸쳐 대체로 혼자, 그 상당 기간을 봉급도 없이 자비로 충당하며 그것을 개발했고, 2007년에 공개했습니다.⁵⁷ 그는 이후 Datomic을 만들었는데, 이는 데이터를 결코 덮어쓰지 않고 불변의 사실(“datom”)을 시간에 걸쳐 쌓아 가는 불변 데이터베이스로, 데이터베이스를 과거 어느 시점 기준의 값으로 질의할 수 있습니다.⁹ 그는 또한 일련의 콘퍼런스 강연 – Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet? – 으로도 널리 알려졌는데, 이 강연들은 업계가 복잡함과 불변성과 설계를 이야기하는 방식을 빚었습니다.⁵⁶

Rich Hickey가 “프로그래머는 모든 것의 이점은 알지만 그 무엇의 대가도 모른다”고 말했나요?

이 한 줄짜리 경구는 Hickey의 것으로 매우 널리 인용되고 그의 사고를 정확히 담고 있지만, 그의 주요 강연 녹취록에 글자 그대로 등장하지는 않습니다. 책과 콘퍼런스 강연을 거치며 떠돌아다닌, 결정화된 의역입니다.¹¹ 글자 그대로의 1차 출처에 가장 가까운 형태는 Design, Composition, and Performance에 있는데, 거기서 그는 해법을 분해해 “이점뿐 아니라 – 이점은 보통 꽤 명백하죠 – 대가까지 보라, 즉 이것의 어느 부분이 잘 작동하지 않을 것인가를 보라”고 촉구합니다.¹² 그 정서가 명백히 그의 것이라는 점 – 엔지니어들이 도구가 주는 것에는 과하게 쏠리고 그 비용은 덜 따져 본다는 것 – 에는 의심의 여지가 없지만, 그 날렵한 격언은 직접 인용이 아니라 의역으로 다루는 것이 가장 낫습니다.

출처