Clojure, 한 달 사용 후 느낀 점은?

커뮤니티에서는 Clojure가 단일 설계자에 의해 만들어져 Common Lisp나 Scheme보다 언어적 응집성(Linguistic Cohesion)이 높다는 점에 주목합니다. 특히 `seq` 추상화를 통해 리스트, 벡터, 해시 테이블 등 다양한 컬렉션 타입에 대해 일관된 함수(`nth`, `map`)를 적용할 수 있다는 점이 장점으로 언급됩니다. 이는 Common Lisp의 `mapcar`나 `remove-if-not`과 같은 혼란스러운 함수명과 대조되며, Scheme의 극단적인 미니멀리즘과 달리 실용적인 라이브러리 생태계를 제공한다는 평가입니다.

Clojure의 핵심 데이터 구조인 리스트, 벡터, 해시맵, 세트가 언어 차원에서 동등하게 취급되는 점은 개발자들에게 긍정적으로 평가됩니다. 하지만 일부에서는 Lisp의 전통적인 '모든 것은 리스트'라는 개념과 달리, 벡터 리터럴(`[]`)이나 해시맵 리터럴(`{}`) 등 다양한 문법 요소(Syntactic Elements)가 오히려 Lisp의 단순성을 해친다는 지적도 있습니다. 특히 매크로에서 리스트 대신 벡터를 사용하는 것에 대한 비판이 제기되었습니다.

Clojure가 JVM 위에서 동작한다는 점은 Java 생태계 활용의 이점을 제공하지만, Java를 모르는 개발자에게는 학습 부담으로 작용할 수 있습니다. 그러나 커뮤니티에서는 ClojureScript(JavaScript), ClojureCLR(.NET), Jank(C++) 등 다양한 런타임(Multiple Runtimes)을 통해 JVM에 종속되지 않고 개발할 수 있다는 점을 Clojure의 강력한 특징으로 꼽습니다. 호스트 인터럽(Host Interop)을 사용하지 않는 코드는 대부분의 방언에서 호환된다는 점이 강조됩니다.

일부 개발자들은 Clojure의 문법적 측면보다 런타임(Runtime)의 중요성을 강조하며, 특히 동시성(Concurrency) 및 병렬성(Parallelism) 측면에서 Erlang이나 Golang의 런타임 성능에 미치지 못한다는 의견을 제시합니다. Clojure의 그린 스레드(Green Threads) 방식이 언급되지만, 실제 대규모 동시성 처리 능력에 대한 의문이 제기됩니다. 이는 언어의 문법적 편안함보다 실질적인 시스템 성능 최적화가 더 중요하다는 주장으로 이어집니다.

Clojure를 이용한 정적 사이트 생성기 개발 경험은 매크로를 활용한 템플릿 엔진 구현 등에서 만족감을 주었으나, 출력 최적화, CSS 스코핑, SSR, Node.js 생태계 통합 등 고도화된 기능 구현의 복잡성이 드러났습니다. 이로 인해 결국 Astro와 같은 전문 SSG로 전환한 사례가 공유되었으며, 이는 Clojure의 유연성에도 불구하고 특정 도메인에서는 기성 솔루션(Off-the-shelf Solutions)의 이점을 무시할 수 없음을 시사합니다.