제프슨이 클로저로 작성된 이유

 (aphyr.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Jepsen은 데이터베이스 같은 동시성 시스템을 검증하는 도구라서, 구현 언어도 동시성 모델과 실제 스레드 지원이 중요한 선택 기준이었음
  • Clojure의 불변·영속 데이터 구조와 JVM 동시성 도구는 테스트 코드의 오류 가능성을 줄이고, Java 기반 데이터베이스 클라이언트와도 잘 맞음
  • Jepsen 작업은 정해진 제품 개발보다 실험과 탐색에 가까워 REPL, 매크로, threading macro, EDN 같은 Clojure 기능이 복잡한 데이터 처리에 유리했음
  • 성능은 최상위권은 아니지만 관용적인 Clojure가 보통 Java보다 한두 자릿수 이내로 느린 수준이며, 필요한 지점은 최적화와 JVM 프로파일링 도구로 다룰 수 있음
  • 작은 커뮤니티, 널리 성공한 정적 타입 시스템 부재, primitive 처리 불편, 오류 메시지 같은 약점은 있지만 1~3명이 유지·사용하는 Jepsen에는 감수할 만한 절충이었음

동시성 테스트 도구에 맞는 언어 조건

  • Jepsen은 동시성 시스템을 테스트하기 위해 만들어졌고, 테스트 대상은 대부분 데이터베이스임
  • Clojure는 동시성 테스트 코드를 작성할 때 필요한 기본 조건을 잘 충족함
    • 불변·영속 데이터 구조가 공유 상태를 다루는 코드의 오류 가능성을 낮춤
    • 실제 스레드, promise, future, atom, lock, queue, cyclic barrier, java.util.concurrent 등을 사용할 수 있음
    • Haskell처럼 부작용 제어가 더 엄격한 언어도 검토했지만, Clojure의 덜 교조적인 접근이 Jepsen에는 더 잘 맞았음
  • 데이터베이스 테스트에는 다양한 클라이언트와의 연결이 필요함
    • 거의 모든 데이터베이스가 보통 Java로 작성된 JVM 클라이언트를 제공함
    • Clojure는 Java 상호운용성이 좋아 이런 클라이언트를 활용하기 쉬움

실험과 데이터 탐색에 유리한 Clojure 기능

  • Jepsen 테스트는 실험적 작업이라 간결하고, 바꾸기 쉽고, 프로토타이핑에 적합한 언어가 필요했음
    • Clojure의 간결한 문법과 매크로 시스템이 이런 작업 방식에 잘 맞음
    • threading macro는 연쇄 변환을 읽기 쉽게 만듦
    • 매크로는 재사용 가능한 오류 처리와 리소스 범위 제어를 구현하기 쉽게 함
    • Clojure REPL은 테스트 실행 결과 데이터를 즉석에서 탐색하는 데 유용함
  • 테스트 과정에서는 복잡하고 중첩된 데이터 구조를 표현·변환·검사해야 함
    • Clojure의 데이터 구조와 표준 라이브러리 함수가 이 작업에 강함
    • 콘솔과 파일에 구조화된 데이터를 많이 출력할 때 EDN 데이터 문법이 잘 맞음

성능과 장기 유지보수의 절충

  • Jepsen은 아주 큰 시스템은 아니지만 적당한 양의 데이터를 다루기 때문에 “충분히 좋은” 성능이 필요함
    • Clojure는 가장 빠른 언어는 아님
    • 관용적인 Clojure는 보통 Java보다 한두 자릿수 이내의 성능 차이에 머묾
    • 중요한 병목에서는 차이를 줄일 수 있음
    • JVM의 프로파일링 도구가 Clojure와 잘 작동함
  • Jepsen은 약 10년 된 프로젝트라 성숙한 핵심과 안정성이 중요했음
    • Clojure는 JVM 타깃과 언어 자체 측면에서 안정적임
    • 라이브러리가 Scala나 Ruby만큼 빠르게 “썩지” 않음

감수해야 하는 Clojure의 약점

  • Clojure에는 Jepsen 규모에서는 감당 가능하지만, 더 큰 팀에는 부담이 될 수 있는 단점이 있음
    • 엔지니어링 커뮤니티가 작음
    • 널리 받아들여지고 성공한 정적 타입 시스템이 없음
    • Jepsen은 한 번에 1~3명만 유지·사용하므로 이 제약이 덜 크게 작용함
  • JVM primitive를 다룰 때 Java로 내려가지 않으면 답답할 수 있고, 실제로 가끔 Java를 사용함
  • 다형성 시스템의 일부는 부족하지만 라이브러리로 우회할 수 있으며, 오류 메시지도 좋지 않음
  • Jepsen은 여러 언어로 프로토타입을 만든 뒤 Clojure로 결정됐고, 10년이 지난 뒤에도 꽤 좋은 절충으로 남아 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Clojure/ClojureScript로 SaaS를 10년쯤 운영해 온 입장에서 Kyle의 글에 전적으로 동의함
    추가로 가치가 컸던 건 도메인 코드 대부분을 cljc 파일에 두어 서버와 클라이언트 양쪽으로 컴파일할 수 있다는 점, transducer와 transducer 파이프라인이 성능·조합성·재사용성 면에서 과소평가됐다는 점, 그리고 Rich Hickey가 설계한 언어답게 안정성과 장기 호환성이 뛰어나다는 점임
    하위 호환성이 매우 중요해서 계속 바뀌는 도구에 휘둘리기보다 애플리케이션에 집중할 수 있고, 평균적인 Clojure 프로그래머가 12년 이상 경력에 상위 사분위 보상을 받는 것도 우연은 아니라고 봄

    • 비슷한 상황임. 내 SaaS도 Clojure로 돌리고 있는데, 다른 언어에 비해 유지보수가 꿈같이 편함
      거의 깨지지 않고 업그레이드도 쉬움. HMR, REPL, cljc 파일 덕분에 개발자 경험도 훌륭하고, Clojure 코드는 쓰는 재미가 있음
    • 전체 이점 중 JVM 덕분인 부분과 Clojure 언어 자체 덕분인 부분이 각각 어느 정도라고 봄?
    • Clojure에는 쓸 만한 웹 프레임워크가 있음?
    • 하위 호환성이 그렇게 중요하다면, 왜 C와 C++에 적용될 때만 예외처럼 취급되는지 궁금함
      작동하는 것을 깨지 않으려고 언어와 시스템을 뒤로 휘게 만드는 건 괜찮다면서, 실제로 돌아가는 소프트웨어의 큰 부분을 떠받치는 두 언어에는 찬란한 과거와 현재를 끊어내라고 기대하는 이유가 뭔지 모르겠음

  • Clojure의 가장 큰 문제는 확실히 생태계임
    접근 가능하고 쓸 만한 도구의 분포를 보면, 너무 왼쪽 끝에 있어 끔찍하지만 접근은 쉬운 도구이거나, 너무 오른쪽 끝에 있어 README에 반지의 제왕 인용구가 있고 모든 것이 n차까지 데이터이며 눈가리고 거꾸로 매달려 Emacs 플러그인을 짤 수 있는 용만 접근 가능한 식임
    언어 자체는 훌륭하고 Java 상호운용성도 Aphyr가 말한 것보다 훨씬 낫지만, Clojure에 Rails나 Django, 더 좋게는 Phoenix 같은 것이 있었다면 훨씬 설득하기 쉽고 더 널리 쓰였을 것 같음
    특히 Algol 계열 명령형 언어에서 Lisp로 팀을 옮기도록 설득하려면 얻는 것이 고생보다 커야 하는데, 지금은 HTTP 라우팅 같은 기본 요소를 빼면 거의 모든 프로젝트에서 바퀴를 다시 만들어야 함
    그래도 어떤 Maven 패키지든 쓸 수 있고 jar로 컴파일되므로, jar가 도는 곳이면 Clojure도 도는 건 엄청난 장점임

    • VSCode용 훌륭한 플러그인인 Calva를 꼭 봐야 함. REPL뿐 아니라 실시간 문서 같은 기능도 제공해서 Clojure를 쉽게 쓸 수 있고, 매일 업무에서 쓰고 있음
      https://calva.io
    • Clojure로 생업 코딩을 해본 것 같지는 않음. Clojure 생태계와 커뮤니티는 잘 유지되고 있음
      Clojure는 여러 형태가 있고 주로 Clojure와 ClojureScript가 쓰이며, Babashka, Scittle 등도 있지만 모두 clj나 cljs에서 파생됨
      개발 도구는 플랫폼과 IDE 취향에 따라 달라서 Emacs, Neovim, VSCode, IntelliJ마다 도구가 다르고, 빌드 시스템도 필요에 따라 다름
      clj에서는 deps.edn이 현재 가장 많이 쓰이고 leiningen이 뒤따르며, cljs에는 shadow-cljs 외에도 여러 선택지가 있음
      처음 접하는 사람에게는 압도적일 수 있지만 커뮤니티는 좋고 항상 도와줌. 여러 언어로 생업 프로그래밍을 해왔지만 Clojure가 단연 가장 마음에 듦
    • “끔찍하지만 접근은 쉬운” 도구의 예가 궁금함
      2013년쯤부터 Clojure를 써왔는데 그런 도구가 떠오르지 않음. 인기 있는 라이브러리 대부분은 훌륭하고, 안정성·하위 호환성·단순성 면에서 내가 아는 대부분의 생태계보다 한참 앞서 있음
    • 이건 Jepsen이나 글 본문과 관련 있다기보다 그냥 임의의 Clojure 코멘트처럼 보임
    • Clojure를 잘 모르는 사람을 위해 덧붙이면, 이 스레드에서 /u/jwr가 말했듯 Clojure는 ClojureScript 덕분에 브라우저가 있는 곳에서도 돌아감
      Clojure와 ClojureScript 양쪽에서 공유 가능한 .cljc 소스 파일 덕분에 같은 Clojure 코드를 프런트엔드와 백엔드에서 모두 실행할 수 있음
      Rich Hickey가 말하듯 JVM만 “도달”하는 게 아니라 JavaScript도 도달함
      Emacs를 오래 써왔고 원하는 대로 설정하거나 필요한 elisp 코드를 결국 만들 수는 있지만, elisp를 잘한다고는 전혀 못 하겠음
      Lisp 방언을 전혀 배운 적 없는 사람이 Emacs, elisp, Clojure를 동시에 배우는 건 어렵고 설득도 매우 힘들다는 건 인정함
      지금은 Clojure LSP 서버가 있고 Emacs뿐 아니라 다른 IDE에서도 동작하므로, 많은 Clojure 개발자가 Emacs를 쓰더라도 Clojure 개발에 Emacs가 필수는 아님

  • 7년 동안 Clojure만 써왔고 50만 줄이 넘는 Clojure + ClojureScript 코드베이스를 적극적으로 다루고 있는데, 견고한 타입 시스템이 없다는 게 가장 큰 불만임
    Clojure가 표현력이 좋고 빠르게 진행할 수 있으며 방해하지 않는다는 말에는 동의하지만, 재현과 디버깅이 어려운 지저분한 런타임 오류도 허용함
    널리 받아들여지고 성공적인 정적 타입 시스템이 있었다면 Clojure는 굉장했을 것임. 지금은 Ruby나 Python을 좋아하면서 더 강한 무언가를 원한다면 꽤 괜찮은 정도라고 보고, 이제는 Go가 맞는 길인지 고민하게 됨

    • 정적 타입이 도움이 된다고 측정된 부분에는 Kotlin 같은 다른 JVM 언어를 Clojure 프로젝트에 통합할 수 있음

  • Clojure(Script)는 정말 축복에 가깝고, 작든 크든 많은 프로젝트에 훌륭한 선택지라는 데 완전히 동의함
    C, Python, PowerShell, Java, Bash, SQL을 대학 과제나 시스템 관리, 트래픽 덤프 분석 등에 조금씩 써본 뒤 전문 프로그래밍을 처음 한 언어가 Clojure였음
    OrgPad를 Clojure+ClojureScript로 만들고 있고, 코드가 10만 줄을 넘어도 좋은 결정이었다고 봄
    접근하기 쉽고, 조금 코드를 작성하면 내가 상상한 대로 동작할 거라는 확신이 꽤 있음. Python, PowerShell, Bash에서도 이 정도는 아니었고 완전히 다른 급이라고 느껴짐
    REPL 작업 흐름도 정말 좋고, 동료가 관련 영상을 만들었음: https://www.youtube.com/watch?v=4igO7Qbyj9o
    요즘은 Bash에서 Python으로 넘어갈까 고민할 만한 함수, 짧은 작업, 작은 프로젝트도 Babashka/nbb로 처리할 수 있음

  • 예전에 Clojure와 ClojureScript를 몇천 줄쯤 써보려 했을 때, 가장 큰 문제는 도구 대부분이 꽤 지저분한 오류 상태를 갖고 있다는 점이었음
    Python도 비슷한 면이 있어서 대부분의 Python 프로그램을 Ctrl+C로 끊으면 알 수 없는 내용이 섞인 스택 추적이 나오지만, 막 시작하는 입장에서는 앞으로 나아가기가 힘들었음
    언어와 생태계에는 혁신적이고 흥미로운 아이디어가 많이 들어 있다고 봄. 최소한 Clojure의 역사 논문을 읽고 대부분의 교훈을 내면화할 가치는 있음
    모두에게 이단처럼 들리겠지만, Clojure만큼 성능과 코드 작성 ergonomics에 진지하면서도 괄호는 없는 스크립팅 언어가 들어갈 작은 생태계 공간이 있다고 생각함
    nil을 특수하게 다루는 관행도 없어도 좋겠지만, 적어도 거기에는 약간의 기반은 있음
    (f x y)가 f(x, y)보다 낫다는 건 알지만, 내 문제는 let 폼이 들여쓰기를 유발하는 경우에 더 가까움. 값에 이름을 붙이려고 들여쓰기와 괄호 비용을 동시에 치를 필요는 없다고 봄
    Python처럼 어차피 코드에 넣을 들여쓰기를 정보로 쓰는 언어에서 오면, 이런 것들이 그냥 잡음처럼 느껴질 때가 있음

    • let 폼이 들여쓰기를 만든다는 건 let을 너무 많이 쓰고 있다는 징후에 가까움
      함수형 스타일에서는 함수 사이에 전달되는 중간 인자에 이름을 붙일 필요가 많지 않음
      보통 스레딩 매크로인 ->, ->>로 인자를 다음 함수에 암묵적으로 넘기거나, 변환 자체를 순수 함수로 정의해 최상위에 둠
      다만 일부 상호운용성 코드에서는 let이 많이 필요하다는 건 이해됨. 특히 절차 체인에서 인자를 변경하는 Java JWT 라이브러리들이 그렇다
    • Clojure나 Python에서 REPL 작업 흐름을 쓰다 보면 실수로 배우는 것들이 있음
      한참 디버깅하다가 다시 로드하거나 재초기화하지 않았다는 걸 깨닫는 식임
      대부분은 “이럴 리가 없다”는 상황에서 확인할 목록에 이를 추가하게 된다고 느낌. 예를 들어 “내 코드 변경이 실제로 호출되는지 확인하려고 디버그 출력을 넣자” 같은 것임
      물론 이건 안전망일 뿐이고, 주로 다른 REPL 작업 습관으로 그런 상황을 피하려고 함
    • (+ clojure clojurescript)라고 읽혀야 할 것 같아서 머릿속이 괴로움

  • Clojure는 많은 것을 제대로 하고 있고 그래서 많이 좋아함
    실제 팀이 실제 웹 작업을 Clojure로 만들 때 속도를 늦추는 한 가지는, 각자 방식이 다른 수많은 라이브러리를 조합해서 모든 것을 엮으려는 거의 교조적인 욕구라고 봄
    커뮤니티가 현재 접근 방식에 더해, 적극적으로 유지되고 배터리 포함이며 일반적으로 쓸 만한 웹 프레임워크도 갖추면 Clojure가 훨씬 더 인기 있고 쓰기 좋아질 것 같음. Biff가 그 역할인지 궁금함
    언어는 좋아하지만 직접 괴물을 조립하는 방식은 좋아하지 않는 사람에게도 선택할 대안 경로가 있으면 좋겠음
    Ruby on Rails에 길들여진 탓도 있음

    • 많은 사람에게 Clojure의 매력은 불필요하게 것들을 묶지 않는 데 있다고 봄
      유명한 Rich Hickey 강연처럼, complect하지 말고 compose하라는 접근임: (https://github.com/matthiasn/talk-transcripts/blob/master/Hi...)
    • Biff는 배터리 포함에 매우 가깝지만, 기본값 몇 가지가 주류와는 조금 다름. SQL 대신 XTDB, HTMX/Hyperscript를 쓰기 때문에 새로 온 사람은 여전히 힘들 수 있음
      Clojure와 그래프 데이터베이스, 경우에 따라 HTMX까지 배우는 건 꽤 많음. 그래도 많은 설정이 이미 되어 있고, 인증은 세심하고 쉬우며 서버 설정 파일 주석도 잘 달려 있음
      Linux 서버를 설정하고 프로덕션 REPL에 SSH로 들어가는 배포 스크립트도 있음. XTDB를 쓰고 싶다면 Biff의 문서 검증 설정 방식은 정말 좋음
      개인적으로는 ClojureScript로 돌아가는 앱보다 이쪽을 더 좋아함. React를 감싼 ClojureScript 래퍼가 많고 거의 밈처럼 됐지만, React 개발자로서 그중 어떤 것도 React보다 쉽다고 느끼지 못했음
      오히려 복잡하고 손에 잘 안 맞는 느낌임. 반면 HTMX/Hyperscript는 HTML 문법이 조작하기 쉬운 배열과 객체일 뿐이라 Clojure와 아주 잘 맞음
      Clojure 애호가들이 반복하는 “코드는 데이터다”라는 격언이 처음으로 실제처럼 느껴졌음
    • 위에서도 썼지만 Luminus나 Kit을 확인해보면 좋음
    • 내가 써본 것들 중에는 Biff가 가장 마음에 듦

  • 예전에 OCaml을 여러 번 조금씩 써보려 했는데, 지나치게 엄격한 타입 시스템이 마음에 들지 않았음
    코드를 쓰는 시간보다 컴파일러를 만족시키는 시간이 더 많았음. Clojure, Common Lisp, C에서는 컴파일러나 타입 시스템을 내가 원하는 쪽으로 구부릴 자유가 더 큼
    물론 장단점은 있지만, 코드를 쓸 때 방해받고 싶지 않음. 내 스타일일 수도 있지만 같은 생각을 하는 사람을 많이 만났음
    정적 타입 시스템은 취향의 문제라고 믿고, 반대 진영은 다르게 생각함. 그래도 서로 반대되는 진영이 있으면 서로에게 많이 배우기 때문에 좋음
    Rich Hickey는 Clojure가 호스트 언어이므로 필요할 때 Java나 JavaScript로 내려가도 괜찮다고 여러 번 말했음
    개인적으로 이게 Clojure 생태계의 가장 강력한 기능 중 하나라고 봄. 훨씬 실용적이기 때문임
    “저 더러운 다른 언어로 작성된 라이브러리”를 건드리기 싫다는 이유로 같은 것을 좋아하는 언어에서 반복해서 재구현하려는 시도를 많이 봤음. 느리다, 안전하지 않다, 유연하지 않다 등 이유는 다양함
    이런 일은 Common Lisp에서도, Rust 커뮤니티에서도 자주 있었고 지금도 있음

    • 타입 검사는 실제로 취향의 문제임. 개인적으로는 언어가 사소한 실수를 막아주는 걸 꽤 좋아해서, Common Lisp 코드에 타입 선언을 많이 넣음
      SBCL이 그 선언을 최대한 보장해주면서 프로젝트마다 아마 몇 분씩 두통을 아껴줬을 것임
      그리고 CL은 매우 실용적이라, 예를 들어 woo가 C 라이브러리 기반인 것을 두고 아무도 눈 하나 깜박이지 않음
    • Big Tech에서 고신뢰성 팀을 이끌 때는 엄격한 정적 타입을 어제 당장 모든 곳에 넣고 싶었음
      운영 문제는 전부 작고 미묘한 이슈와 관련 있었음. 런타임 업그레이드로 JSON 키 순서가 바뀌면서 JSON을 수동으로 풀던 오래된 클라이언트가 깨지거나, 스택 깊숙한 라이브러리가 HTTP 코드를 문자열이 아니라 정수로 반환하기 시작해 오류 파싱이 깨지는 식이었음
      운영 규모상 고객의 작은 비율만 영향받아도 수백 건의 문제 보고가 들어왔기 때문에, 모든 장애가 큰일이었음
      지금은 작은 스타트업에서 일하는데 완전히 다름. 관심과 인력이 몰리는 쪽이라 정적 언어를 선택했지만, 동적 언어로 일하던 때가 그리움
      빠르게 출시하다 보니 코드 품질이 정말 나빠짐. 시간 때문에 타입 시스템을 상대하고 깨끗하게 리팩터링하기보다, 조금씩 다른 같은 객체 구조를 여러 개 복사해 곳곳에서 씀
      타입 모양 때문에 일반화가 까다로워서 기능을 분리해 여러 곳에서 참조하기보다 같은 로직을 10군데 복사/붙여넣기함
      문제 영역에 따라 다른 해법이 맞는다고 봄. 미묘한 버그 때문에 한밤중에 호출을 받는다면 엄격한 정적 타입이 맞을 가능성이 높음
      빠르게 반복하고 문제가 이메일이나 Slack 한 통으로 해결될 수 있다면 동적 타입이 더 나을 수 있음
      요령은 성장해서 정적 패러다임으로 옮겨야 할 때를 대비해 동적 패러다임에서 부채를 너무 많이 쌓지 않는 것임
      열성 팬이 많은 언어들은 아쉽게도 “다른 언어 라이브러리는 쓰기 싫다”는 태도로 흘러가기 쉬운 것 같음

  • Clojure는 단연 내가 가장 좋아하는 언어이고 자연스럽게 느껴짐
    다만 다른 언어에서 정말 그리운 두 가지는 이해 가능한 오류 메시지와 타입 힌트임
    회사에서 큰 코드를 리팩터링해야 했는데 고통스러웠음. 어떤 함수가 예외를 던질지 그냥 nil을 반환할지 알기 어렵고, 핵심 함수가 벡터를 반환할지 시퀀스를 반환할지 다른 컬렉션을 반환할지도 알기 어려움
    spec, malli, typed clojure처럼 이를 해결하려는 프로젝트들이 있지만, Python이나 TypeScript의 타입에 가까운 대체재로 느껴지지는 않았음

    • 이런 기능이 있는 현대 언어에 익숙해진 탓일 수도 있고, 없는 언어들이 Python/TypeScript처럼 나중에 붙이는 중이라 그런 걸 수도 있지만, 이걸 어떻게 견디는지 궁금함
      함수에 무엇이 들어가고 무엇이 나오는지 알려주지 못하는 언어는 몇 파일을 넘는 코드베이스에서는 거의 가치가 없게 느껴짐
      현재 코드가 객체에 대해 할 수 있어 보이는 일을 보고 타입을 추론하려는 건 스스로 고통을 자초하는 일임

  • Clojure를 처음 접한다면 이 인터랙티브 튜토리얼을 확인해보면 좋음: https://tryclojure.org

    • https://4clojure.oxal.org/
      쉬운 단계부터 중간, 어려운 단계까지 이어지는 더 나은 인터랙티브 학습 세트임

  • Clojure는 재미있음

    • 이건 과소평가됨. 전문적이지 않게 들릴 수 있지만, 재미는 Basecamp와 Ruby on Rails가 Ruby로 만들어진 이유이기도 함
      Rails는 2010년대 웹 개발을 지배했고, 엄청나게 성공한 스타트업들이 많이 그 위에 세워졌음
      엔지니어가 “장난감으로 논다”고 비웃는 사람이 많지만, 지금 우리가 가진 좋은 것들 중 상당수는 한때 장난감이었음. Linux도 좋은 예임
    • 그 느낌을 완벽하게 잡아낸 표현임. 예전에 그 감정에 대해 글을 쓴 적도 있음 [1]
      아주 “재미있는” 언어의 까다로운 점은 모든 것을 그 언어로 해결할 수 있다고 가정하게 된다는 것임
      결국 코드를 많이 쓰게 되는데, 나중에 보면 코드를 안 쓰는 것이 충분히 괜찮은 해결책이었을 수도 있음
      [1] https://franz.hamburg/writing/clojure-makes-happy.html
답변달기