NeoHaskell 프로젝트를 제품 관리 관점에서 살펴보고, 목표와 로드맵, 거버넌스 모델, 제안된 기능들의 장단점을 비판적으로 평가한다.
NeoHaskell에 대한 나의 견해
최근 Nick Seagull이 발표한 NeoHaskell 프로젝트가 (내 생각엔) 어느 정도 논란을 일으킨 듯하다. 내가 NeoHaskell을 처음 접한 건 NeoHaskell 프로젝트를 비판하는 cohost의 이 글이었고, Haskell 커뮤니티 내 몇몇 친구들도 NeoHaskell에 대해 우려를 표했다. 나의 첫 반응도 비판적이었지만, 공개적으로 NeoHaskell을 반대하기 전에 더 면밀히 조사해 보고 싶었다. 먼저 프로젝트를 파보자는 생각이었다. 누가 알아, 내 촉이 틀렸을 수도 있잖아? 🤷🏻♀️
NeoHaskell이 내게 관련 있는 또 다른 이유는, 내가 Haskell 커뮤니티를 위한 마케팅과 제품 관리에 대해 많이 고민해 왔고, 심지어 주류 프로그래머에게 Haskell을 어떻게 마케팅할 것인가라는 주제로 발표도 했기 때문이다. 그래서 NeoHaskell을 그 관점에서 유심히 살펴보며 비슷한 접근을 시도하는지 보고 싶었다.
또 이와 관련해 내 이력을 덧붙이자면, Dhall 작업을 통해 오픈 소스 프로젝트의 제품 관리와 기술 제품 관리 경험을 많이 쌓았다. 나는 Dhall의 최초 구현을 작성했을 뿐 아니라, 언어 표준, 문서, 수많은 언어 바인딩, 커맨드라인 도구까지 대부분의 언어 생태계를 혼자서 구축했고, 다른 사람들이 같은 일을 할 수 있도록 멘토링하기도 했다.
아무튼 그런 배경은 이쯤 하고, 이제 NeoHaskell로 넘어가 보자:
아마 이 질문이 가장 중요할 것이다. 프로젝트의 목적이 명확히 정의되지 않으면 평가할 대상이 없다. 잣대도, 도전할 지점도 없이 “틀렸다고 말할 수조차 없는” 상태가 된다.
그렇다면 NeoHaskell은 무엇인가?
두 부분으로 나눠 보겠다. NeoHaskell이 ‘지금’ 무엇인지, 그리고 NeoHaskell이 장차 무엇이 되고자 하는지.
내가 파악한 바에 따르면, ‘지금’ NeoHaskell은 다음과 같다:
… 이 GitHub 저장소의 이슈로 추적됨
… (파이썬 상호운용, 모바일 지원 등) 대표 요구사항을 비공식적으로 요약
하지만 웹사이트, 이슈 트래커, 발표문만 봐서는 NeoHaskell이 장차 무엇이 되려는지 명확하지 않다:
다시 말해, Haskell과 유사한 언어의 “클린룸” 구현이 될 것인가?
ghc)을 포크할 것인가?다시 말해, NeoHaskell과 Haskell의 관계가 NeoVim과 Vim의 관계와 비슷할까? (이름만 봐도 그런 뉘앙스다)
다시 말해, stack처럼 Haskell 개발을 위한 새로운 도구 모음을 홍보하는 방식인가?
다시 말해, Haskell 생태계의 기존 패키지들을 보완/부흥시키려는 것인가?
내가 웹사이트와 이슈 전부를 꼼꼼히 읽고 (합리적이라고 믿는) 추론을 더해 본 결과, NeoHaskell이 지향하는 바는 다음과 같다고 ‘생각’한다:
NeoHaskell은 ghc의 포크가 아니며, 대신 다음을 구현하려 한다:
stack과 유사한 정신의 새로운 커맨드라인 도구(neo)
stack에는 없는 신기능 몇 가지를 제안하지만, 나에겐 stack과 비슷하게 읽힌다.다음을 추가하는 GHC 플러그인:
Haskell용 모바일(ARM) 백엔드 작업의 부흥 시도
foundation과 비슷한 정신의 Haskell 표준 라이브러리 전면 개편
더 편리한 파이썬 상호운용을 위한 cpython 패키지의 TemplateHaskell 지원
언어와 생태계 일부에 대한 문서 모음
이벤트 소싱 프레임워크
그리고 이 구체적 로드맵 외에, Nick Seagull은 사실상 NeoHaskell 프로젝트(그리고 만약 NeoHaskell이 주목받는다면 더 넓은 Haskell 생태계)에서 다음과 같은 거버넌스 모델을 제안하고 있다:
내가 과장하는 게 아니다. 발표문에서 BDFL 모델을 명시적으로 참조하는 핵심 인용문을 보라:
나는 제품이 성공하려면 디자인 과정이 반드시 단 한 사람에게 중앙집중화되어야 한다고 믿는다. 이 사람은 사용자, 다른 설계자들의 의견을 듣고, 전반적으로 열린 마음으로 가능한 모든 아이디어를 취사선택해 제품을 개선해야 한다. 나는 제품이 민주주의에 의해 이끌어져야 한다고 믿지 않으며, 모든 사용자의 제안을 모두 구현해야 한다고도 믿지 않는다. 다시 말해, 내가 논의를 생성하고 경청하며, 프로젝트의 기능을 우선순위화하는 일을 맡을 것이다.
나는 이것이 어느 정도 위험을 동반한다는 걸 이해한다. 그러나 동시에 파이썬과 루비처럼 커뮤니티의 사랑을 받는 프로그래밍 도구들이 바로 BDFL 모델 덕분에 그렇다고 믿는다.
이런 NeoHaskell의 지향점에 대한 구체 정보를 더 쉽게 찾을 수 있었으면 한다. 그래야 프로젝트가 ‘분위기’보다 덜 의존적이 되고, 구체적 로드맵에 대한 논의가 가능해지기 때문이다.
자, 이제 이 프로젝트에 대한 내 전반적 인상을 설명하겠다. 먼저 긍정적 피드백을, 그다음 부정적 피드백을 다루며, 표현은 조금 덜 절제하고 감정에 솔직해 보겠다.
누군가가 더 나아지도록 기꺼이 일하겠다고 나선다면 (더 나빠지게 만들지만 않는다면) 나는 마다하지 않는다. Haskell을 위한 새로운 모바일 백엔드? 멋지다! TemplateHaskell을 활용한 파이썬 상호운용? 괜찮다! 문서? 아주 좋다!
이걸 ghc 포크로 하지 않고 GHC 플러그인으로 구현하겠다는 접근은 훨씬 낫다. ghc 포크를 유지하는 데 드는 어마어마한 작업을 우회한다.
게다가 어떤 Haskell 방언을 GHC 플러그인으로 구현하면 (대체 Prelude와 유사하게) 생태계 분열을 최소화한다. 당신의 의존성이 NeoHaskell 방언을 위한 GHC 플러그인을 사용하더라도, 당신의 패키지는 같은 방언을 쓸 필요가 없다(그 의존성을 그대로 빌드하면서 당신의 패키지는 비-Neo Haskell로 코딩할 수 있다). cabal은 이런 걸 투명하게 처리할 수 있다.
Haskell Foundation이 그 역할을 하려 했던 것 같기도 한데(내가 틀릴 수도 있다), 그렇게 잘 풀리지는 않은 듯하다.
어쨌든, 우리 중 많은 사람이 좋은 제품 관리가 무엇인지 알고 있고, 그것이 생태계에서 현저히 부재하다는 것도 알고 있다.
Haskell 생태계에 의미 있는 기여를 크게 해 본 적 없는 사람이, Haskell 생태계에 막대한 영향을 미치려는 프로젝트의 ‘자비로운 독재자’가 되겠다고 하는 건 터무니없다고 본다. 이게 가혹하고 Nick에 대한 인신공격이라는 걸 안다. 그리고 아바타 뒤에는 실제 사람이 있다는 것도 의식한다. 그러나, 자비로운 독재자를 자처하는 순간, 본질적으로 ‘개인적’인 문제를 제기하는 셈이다. 자비로운 독재자를 자임하는 제안은 곧 당신이라는 사람에 대한 국민투표다.1
이건 공정성의 문제가기만 한 게 아니다. Nick이 Haskell 쪽 이력이 부족하다는 건, 현 상태의 기술을 충분히 이해하지 못하면 기존의 성과를 의미 있게 개선하기 어렵다는 사실과 직결된다. 예를 들어, Michael Snoyman이 stack을 만들었을 때 Haskell 도구 체계의 분열을 야기하긴 했지만, 최소한 그는 인상적인 실적과 Haskell 생태계 및 도구 체인에 대한 깊은 이해를 갖추고 있었고, 그 시도는 정당하다고 느꼈다.
Nick Seagull에게서는 그런 인상을 전혀 받지 못했다. 그는 이 분야에서 딜레탕트처럼 보인다. 단지 Haskell 이력이 부족해서만이 아니라, 몇몇 제안이 의심스러워 보이기 때문이다. 이게 다음 이야기로 이어진다:
모든 기여가 생태계에 이롭지는 않다2. 새 neo 빌드 도구 제안은 stack과 유사한 방식으로 도구를 분열시킬 가능성이 크다고 본다. 나는 경력 내내 cabal, stack, Nix를 모두 꽤 폭넓게 다뤄 왔고, 그 경험에 비춰 보면 Haskell 커맨드라인 경험을 개선하는 유일하게 실행 가능하며 장기적으로 ‘이길’ 수 있는 방법은 cabal에 직접 상류 병합(upstream)하는 것이다. 다만 그건 자기만의 빌드 도구를 쓰는 것만큼 그럴싸해 보이지 않기 때문에 아무도 하려 들지 않을 뿐이다.
마찬가지로, (심지어 커맨드라인 스크립트까지 포함해) “모든 Haskell 애플리케이션을 이벤트 소싱하자”는 비전 역시 숙고가 부족해 보인다. 나는 최소 권한의 원칙을 굳게 신봉한다. 즉, 만능 “신 타입”이나 “신 추상화”에 억지로 욱여넣으려 하기보다, 일을 해내는 데 충분한 가장 단순한 타입이나 추상화를 써야 한다는 것이다. 나도 예전에 내 pipes 패키지에 모든 것을 욱여넣으려다 큰 실수였다는 걸 뼈저리게 배웠다. 그러니 나라고 이 점에서 무죄는 아니다. 같은 실수를 반복하지 말자.
그리고 이런 제안 가운데 일부가 역효과라는 건 중요하다. 그가 실제로 자비로운 독재자 역할을 하게 되면, 어떤 변경은 취하고 어떤 변경은 무시하는 식으로 골라 담을 수 없다. 좋든 싫든 패키지 전체를 통째로 받아들여야 한다.
NeoHaskell이 우리가 모두 찾는 ‘좋은 제품 관리’라고는 믿지 않는다. “Haskell 방언 + 파이썬 상호운용 + 이벤트 소싱 + 모바일 백엔드”는 제품이 아니다. 대상 시장도, 산업 vertical도, 용례도 불분명한 기능 묶음일 뿐이며, 설계를 제약하고 트레이드오프를 항해하는 데 필요한 축이 없다. NeoHaskell 로드맵은 각각은 그럴듯해 보이는 관계없는 기능들을 한데 모은 잡동사니처럼 느껴진다. 하지만 그게 곧 좋은 제품 관리라는 뜻은 아니다.
구체적으로 말해 보자. 왜 파이썬 상호운용과 모바일 백엔드를 같은 로드맵에 묶는가? 내가 아는 한, 이 둘을 동시에 요구하는 제품 vertical은 없다.
NeoHaskell에 대한 내 첫인상은 ‘헛소리처럼’ 느껴졌다는 것이다. Nick이 헛소리꾼이라고 말하는 게 아님을 분명히 하겠다. 다만 그가 진지하게 여겨지기를 원한다면, 아이디어를 제시하는 방식을 재고해야 한다. 발표문의 톤(관련 없는 AI 생성 이미지까지 포함), 어떤 지원 코드나 목업도 전무한 점, 흐릿한 목적 서술까지, 모든 것이 진지하지 않다는 인상을 더했다.
어쨌든 나는 Nick을 미워하지 않는다. 다른 맥락에서라면 대면해도 잘 지낼 수 있을 거라고 확신한다. 다른 면에서는 상당히 유능한 사람으로 보이기도 한다. 하지만 야심 찬 생태계를 위해 스스로를 자비로운 독재자로 지명한 것은 다소 무책임하다고 생각한다. 물론 우리 모두 실수할 수 있고, 그로부터 배울 수 있다.
그리고 나는 NeoHaskell을 지지하지 않는다. 더 나은 제품 관리 없이는 Haskell 이상으로 성공할 가능성이 높다고 보지 않는다. “블루칼라 엔지니어에게 맞춘 단순한 Haskell이 좋아”라는 건 좋은 ‘분위기’일 수는 있어도, 제품은 아니다.