Maybe Not -리치 히키의 발표-

이제야 막 발을 담근 함린이지만, 이 영상을 보게 되었습니다. 사실 Clojure도 모르고 Haskell은 더 몰라서 (그리고 여러 선배님들이 말하시는 typed & untyped 의 각각의 고충을 심하게 겪어보지 못했기에) 많이 이해하진 못했지만, 그래도 부분부분 알아들은 부분을 정리해봅니다. 참고로, 발표자 Rich Hickey는 Clojure의 창시자십니다!

1. Optional은 언제 필요할까?

Optional은 값을 가질수도, 가지지 않을 수도 있는 타입입니다. 결국 Null 값이 가지는 문제를 해결하기 위해 나온 타입인데요, 이를 위해 Haskell은 Maybe를, Scalar는 Any, Option 등을 도입했습니다. 그럼 언제 nulls와 options가 필요할까요?
첫번째로는 선택적 요구사항 (optional requirements)을 충족시키기 위해서입니다. 특정한 입력값이 어떤때는 들어올 수도 있고, 어떤 때는 들어오지 않을 수도 있을 때를 대비해서 인자에 null 일 수도 있는 optional을 넣는 것이죠.
두번째로는 조건적 제공 (conditional provision)을 위함입니다. 클라이언트에게 받은 요구사항대로 로직을 실행해서 DB 값을 가져왔을 때, 해당 값이 있을 수도 있고 없을 수도 있습니다. 그 때 리턴을 Optional로 감싸서 분기로 처리할 수 있습니다.
세번째로 부분적 정보를 관리할 때 (particularly interesting and very challenging이라고 하네요!) 입니다. Aggregate 이라고도 하는데요, 뒤에 좀 더 설명이 나옵니다.

Aggregate (ad - “to” + gregare - “herd”) 는 어떤 필요에 의해 (마치 가축들처럼) 한데 몰려 다니는 정보들이라 할 수 있습니다. 그럼 이 Aggregate 정보는 어떻게 코드로 모델링 할 수 있을까요?
를 보면 sets와 slots의 차이가 나옵니다. Aggregate를 모델링 하는 큰 두개의 축이죠. Sets를 사용하는 측은 map 이라는 절대적 함수 (categorical function)을 이용해서, Aggregate의 멤버에 대해 ‘너 있어, 없어?’를 극명하게 나타냅니다. 그도 그럴것이, map 함수란 지극히 단순한 ‘x 를 주면 x’를 돌려준다’ 와 같은 논리를 구현하기 때문이죠.
그에 비해 slots는 직접 해당 슬롯을 열어보기 전까진 가축이 들어있는지 없는지 알 수 없습니다. 마치 Optional 처럼요. 그래서 겉에다 대고 너 있어 없어? 라고 물어보면 아마도(Maybe)라고 하는 것이죠.
그래서 Optional을 안 쓰는 측에서는 가축이 없다면 그냥 없다고 얘기합니다. Clojure 도 마찬가지로, 값이 없다면 그냥 넣지 않습니다. 그리고 그것이 좋다 고 얘기합니다. 이 세상의 그 어느것도 고유하게 불확정적인 (inherently Maybe)는 없다고 하면서 말입니다. ~~양자역학..~~. 그와 동시에 자신이 Clojure 설계에 Optional을 넣은 것을 실수라고 고백합니다.

단점과 나쁜점을 말하는 건 누구나 할 수 있는 얘기라고 합니다. (이 부분이 참 탁월하다고 생각했습니다. 구루는 역시 해결안을 제시하는 사람입니다) 그럼 어떻게 해야 할까요? 해결을 위해 우선 다음 조건들이 충족되어야 한다고 합니다.
schema를 재사용 하는 것이 좋긴 하지만, 단지 맥락 (context)이 다르다고, 그에 상응하는 타입을 무한히 생성하는 것은 원하지 않습니다. 마치 (a,b,c,d,e)와 (a,b,c,d)는 인자 하나밖에 차이나지 않지만 이를 위해, 또는 이들의 모든 부분집합을 하나의 타입으로 만들어 관리하는 것은 코드양을 늘릭고 재사용성을 낮추기 때문입니다.
request와 response의 대칭성을 지원해야 합니다. 많은 경우 응답으로 받는 정보는 입력받는 정보에 약간의 부가적 정보가 추가된 경우가 많은데, 이를 위해 각각을 타이핑 하는 것은 좋은 예가 아닙니다.
Information building 파이프라인을 지원해야합니다. 단계별로 조금씩 정보를 추가할 수 있어야 합니다.

스키마 (Shape)와 Selection(context에서 요구/제공되는 것)을 분리해봅시다.
스키마는 형태만 제공하고, 요구사항에 대해서는 말하지 않아야 합니다. 그렇게 해서 다양한 맥락에서 이 형태를 재사용할 수 있도록 설계가 되어야 한다는군요.
Selection은 이 스키마를 사용한 open system 으로서, Aggregate의 개별 요소들을 제한없이 받아들일 수 있습니다. 최소 조건을 명시함으로써 이보다 더 많은 요소들이 개입될 수 있는 여지를 남긴 것입니다.
이런식으로 Clojure에서는 이 Optional이 가지는 문제를 해결하려고 하는 것 같습니다. 후우~ 넓고 넓은 함수형의 세계입니다.