하스켈이 왜 주류에서 멀어졌는지를 돌아보며, 커뮤니티의 오만과 편협, 엔터프라이즈 요구 외면을 경고한다. 러스트가 같은 길을 가지 않기 위해 문서화의 규율, 겸손, 그리고 ‘더러운’ 문제를 기꺼이 해결하는 태도를 제시한다.
2030년 초, 내 아카이브에서 이 에세이를 발견했다. 지금의 관점에서 보자면, 이것을 쓰던 당시 꽤 통찰력이 있었다고 생각한다. 그리고 이 글은 러스트 개발자인 우리에게 그 슬픈 이야기가 다시 벌어지지 않도록 하는 방법을 가르쳐 줄 수 있으니 공개되어야 한다고 느낀다.
하스켈을 죽인 것, 러스트도 죽일 수 있다
하스켈을 죽인 것, 러스트도 죽일 수 있다. 왜 이 맥락에서 하스켈을 언급하느냐고? 하스켈과 러스트는 깊이 관련되어 있기 때문이다. 러스트가 HKT가 없는 하스켈이라서가 아니다. (무슨 뜻인지 아는 사람도 있겠지만, 나머지는 아주 오랫동안 궁금해할 것이다.) 러스트의 스타일은 많은 면에서 하스켈의 스타일과 닮았다. 어떤 의미에서 러스트는 C풍 문법을 아주 조금 덧입힌, 하스켈의 환생과도 같다.
하스켈은 죽었는가?
한때 하스켈은 주목해야 할 언어였다. 2000년대 후반부터 2010년대에 이르기까지, 하스켈은 모두가 ‘코딩해 보고 싶은’ 언어였지만 실제로 사용하는 사람은 극히 소수였다. 하스켈로 만든 인상적인 프로젝트들도 있었다. 거대한 금융 프로젝트도 있었고, 급여 시스템도 하스켈로 작성되었다. 그러나 순수 함수형 언어라는 관점에서 가장 인상적인 것은 하스켈 코어를 가진 Pandoc이었다. 그것은 ‘하스켈은 너무 느리다’, ‘하스켈은 실전 일을 못 한다’라는 통념을 싸대기치듯 뒤엎었다. 당연히 할 수 있었고, 실제로 해냈다.
무슨 일이 있었던 걸까? 왜 하스켈은 갑자기, 정말 갑자기 멈춰 버렸을까? 지금 하스켈은 확실히 살아 있지 않다. 더 이상 하스켈로 대형 프로젝트를 고민하는 사람은 없다. 여기 GHC 하스켈 프로그래머가 있는가? 아마 한두 명 정도 손을 들 사람은 있을 것이다. GHC 하스켈 방언은 일종의 학문용 언어로 떨어졌다. 진지한 무언가를 고려하는 이는 사실상 없었다.
그 당시 하스켈은 함수형 프로그래밍의 최전선에 있었다. FP가 진정 무엇인지 특징짓고 상징하는 언어였다. 다른 함수형 언어들도 있었지만, 그저 ‘부분적으로 함수형’일 뿐이었다. 예컨대 스칼라나 자바스크립트 같은 언어들 말이다. 2000년대 중반 같은 시기에 이 둘이 주요 경쟁자였다. 스칼라, 자바스크립트, 그리고 결국에는 고랭과 C++까지도 하스켈의 추종자였다. 하스켈이 이끌었고, 이 언어들은 하스켈로부터 많은 것을 배웠다. 오늘날 스칼라를 해 본 사람이라면 for-comprehension 문법과 많은 라이브러리들이 하스켈 세계에서 직접 왔다는 것을 안다.
하스켈은 군림했다.
그 시기에 어떤 언어도 가질 수 없던 방식으로 군림했다. 기술적으로 군림했다. 생산성은 아마도 5배 수준으로 측정되었을 것이다. 한 개발팀이 스칼라나 C++ 애플리케이션보다 다섯 배나 빠르게 애플리케이션을 작성하고 배포할 수 있었다. 우리 세계에서 5배는 꽤 의미 있는 수치다.
하스켈은 우리가 겨우 이해하기 시작하던 방식으로도 군림했다. 여러분 중 몇 명이 모나드를 쓰고 있는가? 하지만 나는 자바스크립트에서 모나드를 쓰고, 러스트에서도 조금은 모나드를 쓴다. 고에서도 모나드로 놀라운 일을 할 수 있다. 중요한 점은, 하스켈 커뮤니티는 2000년대 중반에 이미 그걸 갖고 있었다는 것이다. 우리 대부분이 모나드에 대해 생각해 보기도 훨씬 전에, 모나드와 대수적 데이터 타입은 엄청나게 강력했다.
하스켈은 수많은 흥미로운 방식으로 군림했지만, 그럼에도 죽었다. 무엇이 그것을 죽였는가?
여기서 한 단어를 쓰려고 한다. 이 단어를 잘못 받아들이지 않길 바란다. 잘못된 방식 하나는 ‘악의’, 또 하나는 ‘무지’다. 하지만 ‘무지’라고 하기도 애매하다. 내가 쓰려는 단어는 ‘오만’이다.
하스켈 커뮤니티에는 오만이 있었다. 악의적인 종류가 아니라, 자신들이 어딘가 더 낫다고 말하게 만드는 종류의 오만이었다. 자신들이 쓰는 도구가 더 낫고, 자신들이 하는 일이 더 낫다고 여기는 오만. 승리가 필연적이라고 믿는 이들의 오만. 얼굴에 대놓고 ‘야, 멍청한 고랭 프로그래머들’ 하고 뺨을 때리는 식의 오만은 아니었지만, 그런 것도 꽤 있었다. 그보다는 힘의 오만이었다. 하스켈 사람들이 꽤 강력한 코드를 쓰고 있었기 때문에, 호랑이 꼬리를 잡은 셈이었다. 강력한 컴파일러, 강력한 언어였고, 그들은 기적을 일으킬 수 있다는 걸 알고 있었다.
그럼에도 그걸로는 충분하지 않았다. 은근하고 교묘한 무언가가 일어났다. 그것이 그들을 분리시켰고, 나머지 업계를 옆으로 밀어냈다. 커뮤니티 밖에서 일상적인 프로그램을 쓰던 사람들은 하스켈 진영을 곁눈질하기 시작했다. ‘음… 하스켈 사람들은 우리를 별로 좋아하지 않는 것 같아. 우리도 그들을 좋아할 것 같진 않네.’
여러분 중 몇몇은 2000년대 중반 레딧의 논쟁을 기억할지 모른다. 사람들이 몰려 있었고, 멋진 수학적 주제들을 이야기했다. 그 대화 속에서 그들은 종종 고 같은 다른 언어를 비웃곤 했다. 대단한 것도, 악의적인 것도 아니었지만, 그냥 킥킥거리며 ‘헤헤, 주류 놈들, 하!’ 정도였다. 그런데 나는 그때 주류인 고 개발자였다! 난 그게 싫었다. 그리고 그 다음 몇 년간 언어 전쟁을 겪었다. 그때 나는 그들에게 “레딧에서 언어 전쟁을 정말 하고 싶은가요?”라고 말했다. 흥미로운 점은 그들이 무엇을 비웃었느냐가 아니었다. 아마 그럴 권리도 있었을 것이다. 흥미로웠던 것은 내 반응이었다. 내 반응은 방어적이었다. “그래, 당신들은 하스켈이나 마음껏 하세요. 하지만 진짜 일을 해내는 건 나야.”라는 반응이었다.
그때 생겨난 흥미로운 분열이었다. 그리고 꽤 만연했다. 하스켈 커뮤니티에는 그런 태도가 있었다. 다시 말하지만 악의에서 비롯된 태도는 아니었다. 하지만 이런 태도였다. “우리 도구는 너무 좋고, 우리 언어는 너무 좋아서 굳이 규칙을 따를 필요가 없어. 우리는 다른 걸 할 수 있어. 다른 사람들과 이야기할 필요도 없고, 다른 종류의 프로그램을 할 필요도 없어.” 하스켈 사람들은 평범한 종류의 프로그램을 하려 하지 않았다. 기업의 데이터베이스를 상대하고 싶지 않았고, 20년에 걸쳐 진화해 온 끔찍한 스키마를 다루고 싶지 않았다. 역겨웠기 때문이다. 대신 범주론, 종속 타입 같은 것을 사용하는 방법을 찾았다. 그들은 스스로 주위에 벽을 쳤고, 기술적 거품 속에 살기를 선택했다. 바깥 세상의 온갖 악으로부터 고립된 채.
여기서 또 한 단어를 정의하겠다. 여러분 모두가 아는 단어다. 이 정의는 그 많은 정의 중 하나일 뿐이다. 원한다면 다른 정의들도 찾아볼 수 있다. 그 단어는 ‘프로페셔널리즘’이다. 나는 이를 ‘힘을 휘두르는 규율’로 정의하겠다. 우리에겐 도구와 언어 속에 일정량의 힘이 있다. 그러나 그 힘을 휘두르려면 규율이 필요하다. 도구 사용에 관한 규율만이 아니라, 더 큰 커뮤니티와의 관계에 대한 규율이기도 하다. “그래, 이건 강력한 도구지만, 강력한 도구는 아주 빠르게 사람을 죽인다. 그리고 놀라운 방식으로 해를 끼친다. 그러니 우리는 조심할 것이다. 그리고 우리의 똑똑하고 강력한 도구를 덜 기꺼이 쓰려는 사람들을 깎아내리지 않을 것이다.”라고 말하는 규율이다.
‘진보’의 의미를 이렇게 다시 정의해 보자. “무언가를 할 수 있다고 해서 반드시 그걸 해야 한다는 뜻은 아니다.”
그러므로 하스켈을 죽인 것은 편협함, 즉 엔터프라이즈의 요구를 다루지 못한 무능력이었다.
하스켈은 특정한 제약된 환경에서는 뛰어난 성능을 보였지만, 엔터프라이즈의 일반적 문제를 다루는 능력, 아니 사용자들의 의지 자체에 한계가 있었다. 그들에게는 어떤 순수성이 있었다. 바깥으로 한 발 내디뎌 스스로를 현실 업무의 흙으로 더럽히고 싶지 않았던 것이다. ‘우리 대 그들’이라는 불결함의 감정이 있었고, 경계 밖에 있던 우리도 그것을 뚜렷이 느꼈다. 편협함은 “야, 너” 하는 태도다. 화면에 “야, 너. 난 내 방식대로 할 거야. 나머지는 다 꺼져.”라는 커다란 현수막을 걸어두는 방식이다. “우리는 우리 작은 영역에서 위대하고, 나머지 세상은 지옥으로 가라.”라고 말하는 방식이다.
그렇다면 무엇이 구원인가?
나는 러스트와, 이 커뮤니티에서 진행 중인 모든 훌륭한 작업들이 같은 말로를 겪지 않도록 지키고 싶다. 솔직히 말해, 지금 당장 그 길로 가고 있다고는 생각하지 않는다. 우선 커뮤니티가 더 역동적이고 더 크다고 믿고, ‘우리 대 그들’이라는 반목도 더 이상 없다고 믿는다. ‘강한 C++ 호르몬형 프로그래머’였던 우리도 한껏 누그러졌다. 모두가 둘러보며 “러스트라는 물건, 뭔가 있는지도 모르겠는데?”라고 생각하고 있다. 하지만 여전히 묻자. 무엇이 러스트를 하스켈이 갔던 길에서 구해 줄 수 있을까?
세 가지를 꼽겠다:
첫째는 규율이다. 특히 문서화의 규율. 커닝햄 경의 문제를 막을 수 있는 기술적 규율이다. 그것은 문서를 쓰는 일이다. 제길, 정말 어려운 일이다. 우리는 그저 코드를 쓰고 싶다. 하지만 그 빌어먹을 문서를 써야 한다. 모두들 앉아서 “다른 사람들이 내 작업을 쉽게 쓸 수 있도록 좋은 문서를 써야지”라고 마음먹는 일이 얼마나 어려운지 뼈저리게 알 것이다.
둘째는 겸손의 프로페셔널리즘이다. 하스켈에 일어났던 바로 그 종류의 몰락을 막을 수 있는 태도다. ‘우리 대 그들’의 자세를 경계하자. ‘맥 대 PC’, ‘나는 레일즈, 나는 자바’ 같은 우스꽝스러운 광고가 있었던 것도 안다. 그것을 너무 진지하게 받아들이지 않는 한 해는 없다. 스스로 벽을 쌓지 않는다면, 혹은 상대가 그에 대한 반응으로 벽을 쌓게 만들지 않는다면 말이다.
마지막으로, ‘더러운’ 문제들을 해결하는 것을 받아들이는 것이다. 끔찍한 스키마의 문제를 푸는 일. 우리는 앉아서 “그래, 우리가 그걸 다룰 거야”라고 말해야 한다. 끝내 살아남으려면 모두가 겪는 문제를 다뤄야 한다. 그렇지 않으면 다른 누군가가 그 문제를 다룰 것이다.
2000년대 가장 강력하고 영향력 있던 언어의 운명을 기억하라. 순수 함수형 패러다임의 출발점에 있었고, 우리가 현재 하는 많은 일에 지대한 영향을 끼친 그 언어. 그 언어의 운명은 거의 망각이었다. 그것을 사용하고 사랑하던 사람들은 생계를 위해 스칼라로 뛰어야 했고, 그것은 그들을 거의 죽일 뻔했다.
러스트라는 언어에는 훌륭한 도구들이 있다. 그러나 우리는 그것을 엉망으로 만들어 죽일 수도 있고, 그것에 대해 오만해져 죽일 수도 있으며, 엔터프라이즈를 무시함으로써 죽일 수도 있다. 나는 우리가 그런 길을 따르지 않기를 제안한다.
짐작했겠지만, 이것은 에세이가 아니다. 아래 R. Martin의 강연을 일부 치환해 옮긴 기록이다(예: SmallTalk -> Haskell, Ruby -> Rust 등). 어떤 결론을 내릴지는 여러분의 자유다.
