지난 수년간 프로그래밍 언어 연구와 커뮤니티에서 활동해 온 필자가 열정의 변화, PL의 근본적 난점과 사회적 요인, 하스켈 커뮤니티에 대한 솔직한 소회, 지난 10년의 성찰과 앞으로의 방향을 정리한 글.
오랫동안 쓰기를 고민해 온 글이다.
지난 몇 년간 내 일을 가까이서 지켜본 사람이라면, 내 산출물이 점점 느려졌다는 것을 눈치챘을 것이다. 이 블로그에 마지막으로 글을 올린 것은 4년이 훨씬 넘었다. 마지막으로 발표한 강연은 거의 2년 전이고, 그때 소개한 일은 막 마무리했지만 몇 년 전에 시작했던 것이었다.
내 취미에 대한 열정은 늘 들쑥날쑥했다. 작년 초 정신적·신체적 건강 문제를 함께 겪으며 관리하던 시기에는 그 기복이 유난히 심했다. 그래도 대개는 시간이 지나면 동기가 돌아오곤 했기에, 스스로에게 시간을 주기로 했다. 다행히 지난 1년은 쉬고, 돌아보고, 회복할 시간이 충분히 있었고(오히려 정신 건강은 수년 만에 최고에 가깝다), 그럼에도 내가 결국 마주하게 된 결론은 예전만큼 강렬했던 많은 열정이 돌아올 기미가 보이지 않는다는 사실이다.
이 글은 내 감정을 개인적으로 탐색하는 글이다. 다소 자기만족적이기도 하다. 우선은 나 자신을 위한 글로, 내 생각을 모으고 정리하는 수단이다. 나에게 일종의 마침표를 주었고, 다음에 내가 어디로 가야 할지 이해하는 데 도움이 되었다. 그럼에도 부차적인 목적도 있기를 바란다. 왜—그리고 어쩌면 더 중요하게, 왜 아닌지—내가 인생의 이 장을 덮기로 했는지, 그리고 그 과정에서 내가 배운 교훈을 설명하려 한다.
나는 프로그래밍 언어를 쓰기 시작한 때만큼이나 오래전부터 개인적으로 매료되어 있었다. 본격적으로 프로그래밍을 시작한 건 5학년 때였고, ActionScript 3로 (매우 단순하고 대체로 형편없는) 플래시 게임을 만들었다. 고등학교 2학년 때는 처음으로 프로그래밍 언어 인터프리터를 만들었다. 동적 타입에, 프로토타입 기반 상속을 가진 객체지향 리스프였다. 인터프리터는 C로 작성했고, 그 언어로 하는 첫 진지한 프로젝트였음에도 전처리 매크로를 써서 setjmp.h를 이용한 예외 비슷한 것을 구현했다. 지금 와서 돌이켜보면 내 최종적인 설계 감각과는 꽤 동떨어진 재미있는 프로젝트지만, 적어도 십 대였던 내게 이 주제가 머릿속을 얼마나 많이 차지하고 있었는지 엿볼 수 있다.
나는 언제나 프로그래밍을 깊이 즐겨 왔다. 그건 15년 전이나 지금이나 마찬가지다. (그땐 치료받지 못한) ADHD가 있었던 내게 반복 작업의 자동화는 본능적으로 매력적이었지만, 곧 프로그래밍 그 자체를 즐긴다는 걸 알게 되었다. 약간의 생각과 키보드 앞에서의 시간만 있다면, 무한히 재구성 가능한 기계를 내가 원하는 어떤 목적으로든 이끌 수 있다는 사실은 그 자체로 즐겁다. 프로그램 설계—심지어 큰 설계—는 처음부터 내게 매력적이었다. 그것은 종종 생각을 컴퓨터가 이해할 수 있는 형태로 번역하는 일만큼이나, 생각을 정리하는 과제로서의 성격이 강하고, 그 전자가 아니라 _후자_가 내가 언제나 보람을 느끼는 도전이었다.
그렇더라도, 모든 프로그래머가 결국 깨닫게 되듯, 머릿속 생각과 실행 가능한 코드 사이의 간극은 우리가 바라는 만큼 좁지 않다. 곧 나는 내가 바랐던 바로 그 종류의 반복 작업—지극히 단순해 보이는 일을 하기 위해 기계적으로 산더미 같은 보일러플레이트를 타이핑하는 일—에 지독하게 많은 시간을 쓰고 있다는 사실을 깨달았다.1 도구를 스스로 만들어낼 수 있는 행운의 분야가 바로 프로그래머라고들 하면서, 우리가 쓰는 도구는 왜 이렇게 자주 만족스럽지 못한 걸까 하는 의문이 들었다.
프로그래밍은 놀랄 만큼 젊은 분야다. 아마도 처음으로 ‘프로그래밍 언어’다운 모습을 갖춘 FORTRAN은 70년이 채 안 되었고, 저장 프로그램 컴퓨터도 그보다 겨우 10년 앞선다. 컴퓨팅이 시작된 이래로, 프로그래머들은 우리가 떠올리는 프로그램의 개념과 (대개 고된) 프로그래밍 행위 사이의 간극을 메우려 애써 왔다. 존 배커스(John Backus)는 1979년에 이렇게 말했다.
내 많은 작업은 게으름에서 나왔다. 난 프로그램을 쓰는 게 싫었다. 그래서 IBM 701에서 미사일 궤적을 계산하는 프로그램을 작성하던 중, 프로그램을 더 쉽게 쓸 수 있는 프로그래밍 시스템을 만들기 시작했다.
내 경험상, 이 말은 많은 프로그래밍 언어 애호가들이 우리 기술과 맺는 묘한 관계를 정확히 포착한다. 우리는 프로그래밍을 너무나 사랑하기 때문에, 바로 그 고통스러운 프로그램 작성의 짐에서 우리 자신을 해방하기 위해 프로그래밍 시스템에 엄청난 시간과 생각, 노력을 쏟아붓는다.
겉보기 모순을 화해시키는 하나의 가설은, 나나 배커스 같은 프로그래머들이 프로그램을 쓰는 과정은 좋아하지 않고 _결과_만 좋아한다는 것이다. 우리는 일을 해내고 싶고, 컴퓨터는 최대한 빨리, 최대한 방해가 되지 않게 물러나 있어야 하는 필요악이라고 보는 것이다. 물론 그런 부류의 프로그래머들도 많겠지만, 나는 내 스스로를 그 범주에 넣지 않는다. 그리고 평생을 더 정교한 방법으로 프로그램을 표현하는 수단을 설계하는 데 바친 배커스가, 근본적으로 프로그래밍에 관심이 없는 사람이었다고 믿기도 어렵다.
오히려, 나는 프로그래밍 언어에 대한 많은 작업이—종종 헛되이—프로그래밍을 너무 사랑한 나머지 그 불행한 결함들에서 해방시키고자 하는 몸부림이라고 본다. 우리는 머릿속의 아름답고 플라톤적인 프로그램을 차갑고 이질적인 실리콘 계산기의 언어로 번역할 때 마주치는 방해물과 장애물을 없애려고 애쓴다. 프로그래밍 언어가 주로 기계어 위에 얹힌 추상화라는 신화가 널리 퍼져 있지만, 그런 관점은 프로그래밍 언어가 등장한 지 얼마 되지 않아 이미 빗나가 있었다. 프로그래밍 언어는 생각의 도구이며, 실행 가능한 아이디어를 정확하게 명세하는 틀이고, 거의 전적으로 _인간_을 위해 설계된다. 컴퓨터는 종종 그저 느슨하고 불편한 제약 조건을 제공할 뿐이다.
초기의 컴퓨터는 ‘계산’이라는 단 하나의 목적을 위해 개발되었다. 프로그램은 본질적으로 수행할 계산을 담은 일련의 명령이었다. 프로그램을 요리 레시피나 조립 설명서에 비유하는 인식은 오늘날까지도 이상하리만큼 끈질기게 남아 있다.
현대의 복잡한 프로그램은 거의 어떤 것도 요리 레시피처럼 생기지 않았다. 가장 명령형적인 언어로 작성된 프로그램조차, 반자율적 반응형 하위 시스템들 사이에서 데이터 흐름, 접근 정책, 상호작용 패턴을 규정하는 복잡한 논리의 그물이다. 미시적으로 보면 프로그램이 일련의 단계를 지정한다는 말이 사실이긴 하지만, 이마저도 인간의 편의를 위해 현대 컴파일러가 유지하는 허구에 가깝다. 컴파일러의 눈으로 보면, 진짜 프로그램은 그 편안한 허구를 끓여 날리고 나서 남는 균질한 SSA와 데이터 흐름 그래프의 더미이며, 그것이 다시 아무렇게나 짜깁기 되어 대부분의 프로그래머가 이해하지 못할 언어의 베이식 블록으로 재조립된다.
정반대로, 프로그래머를 ‘실리콘의 속삭임꾼’으로 보는 심상과 달리, 실제로 대부분의 소프트웨어 엔지니어는 컴퓨터 _그 자체_가 아니라 그 결과의 일관성에서 엄격함이 비롯되는 방대한 행위 명세를 유지한다고 나는 믿는다. 다시 말해, 우리는 문제의 해법을 정당한 해석이라면 언제나 우리의 기대에 부합하도록 표현할 수 있는 정밀함을 갖춘 언어를 유창하게 구사하도록 훈련받는다. 중요한 점은, 이런 명세가 작업을 어떻게 수행할지까지 온전히 규정하지는 않는다는 것이다. 최적화 컴파일러는 우리가 허용하는 범위에서 자신의 선택을 할 자유가 있다. HTML/CSS 사용자 에이전트는 웹 표준이 요구하는 바를 보존하는 방식으로 우리의 지시를 해석할 수 있다. 수십 년간 본질이 크게 바뀌지 않은 토대 기술인 RDBMS 쿼리 플래너조차, 변화무쌍한 조건 아래에서 검색과 조회를 가장 잘 수행하는 방법을 그때그때 결정하도록 설계된 전문가 시스템이다.
그렇다고 해서, 프로그래밍이 결국 우리의 지시를 실행하는 기계와 완전히 동떨어진 작업이라는 말은 아니다. 그래야 한다는 주장도 아니다. 성능과 디버깅은 기반 시스템에 대한 일정 수준의 친숙함을 요구한다. 그 내부의 모든 복잡함이 전문가에게조차 조심스럽게 감춰져 있다고 해도 말이다. 내 요지는 단순하다. 프로그램은 판에 박힌 알고리즘이 아니며, 프로그래밍 행위의 본질도 알고리즘적 사고가 아니다. 오히려 프로그래밍은 근본적으로 도메인 모델링과 시스템 설계의 게임이며, 그 사이사이에 알고리즘적 논리가 접착제로 들어갈 뿐이다.
내가 프로그래밍 언어 설계의 최전선을 밀어붙이고자 한 관심은 예나 지금이나, 프로그램을 설계하는 일과 작성하는 일이 더 가까워지게 만들고자 하는 관심이었다. 이상적으로는, 내 머릿속의 컴퓨터 프로그램(나의 경우는 대개 시각적 형태를 띤다)을 거의 그대로 충실한 디지털 구조로 옮겨, 컴퓨터가 신실하게 실행할 수 있게 해주는 언어가 있었으면 한다. 이 과제는 내가 열다섯 살의 앳된 나이에 사로잡혔고, 그 후 십 년 가까운 시간 동안 내 마음을 붙들어 왔다.
나는 올해 스물여덟이 되었다. 딱 10년 전쯤 첫 직장 소프트웨어 엔지니어 일을 시작했다. 루비 온 레일스와 자바스크립트를 쓰는 평범한 자리였지만, 그때도 진짜로 마음을 사로잡은 건 프로그래밍 언어 관련 취미 프로젝트여서, 많은 여가 시간을 거기에 쏟았다. 하스켈을 직장에서 처음 쓰게 된 건 그로부터 1년도 되지 않아였고, 그 경험은 곧 Racket 매크로 시스템 안에 하스켈 스타일의 타입 시스템을 구현하는 취미 연구 프로젝트로 이어졌다. 지금까지 내 경력의 대부분은 그 형성기에서 거의 곧장 뻗어나왔다고 해도 과언이 아니다.
십 년이 지난 지금, 내가 무엇을 배웠는지, 무엇을 성취했는지, 그리고 어쩌면 더 중요하게 무엇을 하지 못했는지 돌아보는 게 공정하리라. 프로그래밍 언어를 진지하게 파기 시작하면 아주 빨리 배우는 사실 하나는, 이 분야가 놀랄 만큼, 용서할 수 없을 만큼 _어렵다_는 것이다. 아찔할 만큼 똑똑한 사람들이 70년 동안 프로그램 명세화라는 문제에 매달려 왔다. 더는 낮게 달린 과실이 많지 않고, 새로운 성과는 대개 피나는 싸움 끝에 얻어진다.
그래도 프로그래밍 언어 설계가 어렵다 해도, 우리가 예술의 경지를 서서히라도 꾸준히 높여, 지금 가진 도구와 미래의 궁극적 언어 사이의 간극을 조금씩 깎아내릴 수 있다면 위안이 될 것이다. 안타깝게도 그 실용적 비전조차 현실과 맞닥뜨리면 버티지 못한다. 실제로 프로그래밍 언어 설계의 도전은 잘 정의된 최전선을 확장하는 일이 아니라, 서로 양립하기 어렵거나 불가능한 기능들 사이의 근본적 _트레이드오프_의 끝없는 목록과 씨름하는 일이다.
서브타이핑은 매혹적일 만큼 유용하지만, 완전한 타입 추론을 엄청나게 어렵게(그리고 일반적으로는, 가능하지 않게) 만든다. 구조적 타이핑은 흥미롭지 않은 중간 형태마다 _이름_을 붙여야 하는 부담을 크게 줄여주지만, 사실상 하스켈식 타입클래스나 러스트식 트레잇을 활용하기 어렵게 만든다. 동적 디스패치는 소프트웨어 컴포넌트의 결합을 느슨하게 하는 데 큰 도움이 되지만, JIT가 없다면 상당한 성능 비용을 치를 수 있다. JIT 컴파일은 런타임 정보를 이용해 더 유연한 코딩 패턴을 허용하는 방식으로 코드를 최적화할 수 있지만, JIT 성능은 예측하기 어렵고 최적화 JIT의 오버헤드는 크다. 정교한 메타프로그래밍 시스템은 보일러플레이트를 획기적으로 줄이고 프로그램의 간결성과 심지어 가독성까지 개선할 수 있지만, 런타임이나 컴파일 타임 오버헤드가 상당할 수 있고 자동화 도구를 방해하는 경향이 있다. 이런 예시는 끝도 없이 이어진다.
프로그래밍 언어의 본질적이고 가장 완고한 문제는, 상충하는 욕구와 요구 사이의 피할 수 없는 긴장에서 비롯된다. 우리는 재사용하기 쉬운 느슨하게 결합된 소프트웨어 컴포넌트를 원하면서, 동시에 강한 결합과 특수화가 주는 성능상의 이점을 원한다. 우리는 표현의 자유를 침해하지 않는 유연한 언어를 원하면서, 동시에 정적 분석과 강력한 안전 보장을 원한다. 우리는 점점 더 복잡한 불변식을 명세할 수 있는 정교한 타입 시스템을 원하면서, 동시에 코드보다 더 길어지지 않는 읽을 만한 타입 시그니처를 원한다.
우리는 ‘유일무이한 참된 프로그래밍 언어’를 만들 수 없다. 모든 것을 한꺼번에 가질 수 없고, 어디서 어떤 트레이드오프를 할지가 보편적으로 정해질 수 없기 때문이다. 그래서 작업에 가장 적합한 도구를 고를 수 있도록, 여러 언어로 짜깁기된 태피스트리 같은 시스템을 떠올리는 게 자연스럽게 매력적으로 보인다. 하지만 그 역시 (종종 가혹한) 대가가 따른다. 언어 경계에서의 임피던스 불일치, 폴리글랏 시스템에 필요해지는 훨씬 더 복잡한 도구 체인, 수많은 방식으로 구축된 시스템을 유지하는 데 따르는 지식 부담 등이다.
프로그래밍 언어를 10년 동안 만들고 생각해 온 끝에 나는 겸허한 진실을 받아들이게 되었다. 나는 더 나은 프로그래밍 언어를 만드는 방법을 모른다. 개인적으로 나는 미래의 프로그래밍이 더 많은 도메인 특화 언어를 포함하리라는 생각에 깊이 공감하고, 업계 전체도 꽤 오랫동안 (매우 천천히) 그 방향으로 가고 있다고 본다. 하지만 나 역시 그걸 정확히 어떻게 해야 하는지는 엄청나게 복잡한 문제이고, 쉬운 답이 전혀 없다는 사실을 인정한다.
그렇다고 일이 희망이 없다고 말한다면 지나치게 암울할 것이다. 이 일이 중요하지 않다고 믿는 것도 아니다. 비록 십 대의 내가 바랐던 것보다 훨씬 어려운 문제로 드러났더라도, 열매를 맺을 때 이 일은 확실히 보람이 있다. 안타깝게도 수년간의 고된 노력을 넘어 실무의 어려운 문제들을 풀고 나면, 모든 프로그래밍 언어 애호가가 마주해야 하는 훨씬 더 좌절스러운 적이 기다린다. 바로 _프로그래머들_이다.
프로그래밍 언어 설계가 크게는 사회적 문제라는 사실은 놀랍지 않다. 언어 선택은 강한 네트워크 효과의 지배를 받는 경향이 있고, 프로그래머는 이미 아는 언어와 비슷한 것을 선호한다. 새로운 것을 배우는 데 대한 프로그래머의 무관심과 노골적인 적개심은 늘 나를 좌절하게 했지만, 그 감정이 어디서 오는지는 결국 이해한다. 엔지니어로서 우리의 업무 대부분은 _위험_을 관리하는 일이니까. 이국적인 기술 선택은 위험하고, 그에 경계하는 태도는 책임감 있는 충동이다.
그럼에도 주류 프로그래밍 언어의 역사는, 나중에 이 분야 역사상 가장 놀라운 성공으로 증명된 혁신들을 프로그래머들이 처음에는 크게, 분명하게 거부한 이야기의 연속이다. 어셈블리 프로그래머들은 대체로 FORTRAN을 비웃었지만, 몇십 년이 흐르자 어셈블리 프로그래머는 거의 사라졌다. 일급 함수는 불필요하게 복잡하고 혼란스럽다며 널리 폄하되다가, 역사적 우연으로 자바스크립트가 하중을 떠받치는 언어가 되자 마지못해 배우기 시작했고, 불과 10년 만에 모든 주요 프로그래밍 시스템의 필수 기능이 되었다. 정교한 타입 시스템은 여전히 과공학적이고 상아탑 같은 엘리트주의라는 인식을 많이 받지만, 그런 생각을 가진 프로그래머들 중 다수가 러스트를 열광적으로 받아들였고, 러스트의 타입 시스템은 전형적인 러스트 코드가 손쉽게 하스켈을 능가할 정도로 복잡하다.
프로그래밍 언어 논쟁은 대체로 일화와 직감에 기대어 감정적으로 고함을 주고받는 일이다. 놀랍게도(혹은 당연하게도), 대부분의 프로그래밍 언어 이론가와 컴파일러 엔지니어는 이 주제에 훨씬 더 해박한 관점을 가지고 있고 (적어도 하찮은 논쟁은 자제하는 편이지만), 학회에서도 취향에 맞지 않는 언어를 깎아내리는 농담이 전혀 없는 것은 아니다. 이것이 커뮤니티의 독성을 보여준다고 말하려는 건 아니다—그들은 전반적으로 놀라울 만큼 훌륭하고 따뜻하며 창의적이고 포용적이다. 그런 발언은 대개 농담 반 진담 반으로 나온다. 그럼에도 내 요지는, 프로그래밍 언어는 그 장인정신의 속성상 감정적이고 주관이 강한 주제라는 것이다. 2019년에 나는 이 주제를 길게 다룬 적이 있다.
나는 소프트웨어 엔지니어링 분야가 새로운 아이디어에 더 개방적이고 새로운 기술을 실험하려는 의지가 더 커지면 분명 이득을 볼 것이라고 진심으로 믿는다. 또한 프로그래머들이 스치듯 접한 주제에 대해 거의 예외 없이 전문가의 확신으로 말하지 않게 된다면 정말 상쾌하리라 생각한다.2 그럼에도 프로그래머들의 부족주의가 곧 사라질 거라고 기대하지는 않는다. 그래서 실용주의자인 내게는, 그들의 성향이 우리가 이 분야에서 의미 있게 성취할 수 있는 것에 현실적인 한계를 부과한다는 사실이 분명하다.
내 경험상 대부분의 프로그래밍 언어 연구자들은 사실상 이 사실을 받아들였고, 일의 가치와 그 영향력을 거의 완전히 분리하는 것이 지혜라는 태도가 지배적이다. 오늘날 프로그래머들이 전반적으로 무시한다 해도, 아이디어가 충분히 좋다면, 언젠가 먼 미래에 어떤 언어에는 스며든다. 실제로 많은 아이디어가 그렇게 되었다. 렉시컬 클로저는 1975년에 언어에 처음 도입되었지만 널리 받아들여지기까지 30년이 걸렸다. 대수적 데이터 타입도 같은 시기에 처음 소개되었고, 러스트를 통해 최근에서야 주류의 인정을 받았다. 이 분야에서는 혁신이 연구에서 실무로 건너오는 데 오래, 아주 오래 걸린다. 주류 프로그래머들의 변덕스러운 기호와 선호에 자신의 직업적 성취감을 맡기는 것은 개인적 불행으로 가는 지름길이다.
이 태도에 나는 진심으로 존경을 보낸다. 이 연구 커뮤니티는 놀랄 만큼 친근하고, 따뜻하고, 창의적이며, 재미있고, 포용적이다. 이런 주제가 대중 프로그래머들에게 늘 냉소를 받는다는 점을 생각하면 더욱 그렇다. 나는 그들과 직접 협업할 기회를 가졌던 것을 큰 영광으로 느끼고, 매년 주요 PL 학회마다 쏟아지는 끝없이 매혹적인 아이디어와 흥미진진한 프로젝트들에 늘 영감을 받는다. 그럼에도, 그 자체의 이유로 묵묵히 이 문제들에 매달리는 사람들에 대한 존경이 아무리 커도, 이제 내가 그들 중 하나로 계속 남을 수 있을지 잘 모르겠다. 이 분야는 흥미롭고 나름의 보람이 있다. 하지만 지난 몇 년 동안 나는 그것이 내가 바랐던 만큼 충분히 보람 있지는 않다는 사실을 서서히 받아들이고 있다.
나는 소프트웨어 쓰는 것을 좋아한다. 때로는 그런 말이 꽤 급진적으로 들리는 게 이상할 정도다. 많은 프로그래머가 자신이 하는 일을 거의 혐오하는 듯이 말한다. 나는 그런 마음가짐에 공감하지 못한다. 프로그래밍은 재미있고, 당면한 문제를 단호하게 해결하는 코드를 쓸 때 독특한 기쁨을 느낀다. 꼭 특별히 흥미로운 문제일 필요도 없고, 블록을 맞춰 끼우는 수준의 해결책이어도 상관없다. 장인정신과 결과물에 자부심과 만족을 느낄 수 있다면, 나는 대개 충분히 행복하다.
내가 라이브러리, 도구, 컴파일러에 끌리는 이유는 개인적 동기와 동료들의 환경을 개선한다는 만족감이 뒤섞인 결과였다. 소프트웨어 엔지니어링에서 내가 가장 좋아하는 것 중 하나는, 문제를 풀되 그 풀이가 대체로 계속 풀린 채로 남도록 만드는 일이다. 물론 요구 사항이 바뀌면 수정해야 하지만, 한 번 노동을 마치고 나면 그 해결책은 계속 작동한다. 내 삶의 다른 과제들은 이런 성취감을 주지 못한다. 빨래를 하면 일주일이나 보름쯤은 깨끗한 옷을 입을 수 있지만, 곧 다시 해야 한다는 걸 안다. 소프트웨어 엔지니어링은 다르다. 소프트웨어—심지어 아주 평범한 소프트웨어—를 만드는 일은 잘그리고 진짜로 _완료_될 수 있는 다양한 작업을 제공한다. 그런 진척의 감각이 좋고, 코드라는 은유적 정원을 가꾸고 돌보는 과정을 편안하고 거의 명상적으로 느낀다.
이 모든 걸 고려하면, 내가 프로그래밍 언어 작업에서 만족을 느끼기 어려웠던 이유는 명확하지 않다. 컴파일러를 만드는 일은, 앞서 말한 욕구를 내가 매일 하는 일에 가장 궁극적으로 적용하는 일처럼 보인다. 성가시거나 반복적인 작업이 있다면, 내 프로그래밍 시스템을 확장해 더 나은 방법을 제공할 수 있고, 그러면 그 일을 다시는 하지 않아도 된다. 게다가 수천 명이 실제로 쓰는 컴파일러를 만든다면, 이는 나만 이득을 보는 게 아니라 모두에게 이득이 된다. 그런 영향력을 갖는 건 기분 좋은 일이고, 내 노력이 그것을 쓰는 사람 수만큼 곱절이 된다는 사실도 좋다.
겉으로 보기에, GHC 같은 컴파일러에서 일하는 것은 엄청난 만족을 줄 것 같다. 비록 주류의 프로그래밍 언어 태도에 좌절을 느낀다 해도, 하스켈 프로그래머는 다르다. 하스켈러들이 쓰고 고마워하는 것을 만드는 일은 분명 보람 있어야 한다. 하지만 실제로는 그랬다고 말하기 어렵다. 좋은 순간들도 있었고, 문제는 대개 흥미로웠다. 그러나 내가 바랐던 의미의 _보람_을 느끼지는 못했고, 심지어 평범한 소프트웨어를 만드는 일과 비교해도 크게 우월하다고 느끼지 못했다. 왜일까?
이 섹션을 쓰는 일이 가장 어려웠다. 내가 사랑하는 것과 존경하는 사람들에 대해 쓰는 건 쉽다. 내가 혐오하는 것과 경멸하는 사람들에 대해 쓰는 건 어쩌면 더 쉽다. 하스켈 커뮤니티는 그 어느 쪽도 아니다. 나는 그것을 싫어하지 않는다. 구성원 중 몇몇은 내가 매우 좋은 친구라고 여기는 사람들이기도 하다. 그럼에도 나는 그 커뮤니티에 특별한 애정을 느끼지 못했고, 그게 그들의 잘못이 아니더라도, 이렇게 고백해야 한다는 사실은 조금 슬프다.
나는 하스켈 커뮤니티나 그 안의 어떤 사람들을 비난하려는 의도가 전혀 없다는 점을 정말 분명히 하고 싶다. 많은 사람이 하스켈러를 불친절하고 엘리트주의적이라고 선입견을 갖고 있는데, 과거 그런 인식을 만든 몇몇 문제적 행위자가 있었던 것으로 보이지만, 내 전반적인 인상은 그들이 철저히 배제되었다는 것이다. 나는 기억에 남을 만큼 무례한 대우를 받은 적이 없고, 편견이나 차별의 표적이 된 적도 없으며, 오히려 내가 참석한 모든 밋업과 컨퍼런스에서 늘 따뜻하게 환대받았다. 물론 나는 나 자신 외에는 누구도 대변할 수 없고, 내 경험은 필연적으로 제한적이다. 내가 참여해 본 적 없는 하스켈의 무수한 사회적 공간에서 학대가 전혀 없었다고, 혹은 지금도 없다고 단언할 수는 없다. 그럼에도 개인적으로 나는 불친절을 겪은 적이 없었고, 그것이 내가 커뮤니티에 애착을 느끼지 못한 이유는 아니다. 오히려 오랜 세월 동안 내가 받은 사랑스러운 지지에 진심으로 _감사_하고 싶고, 그런 지지와 열정이 종종 나를 오래도록 버티게 해 주었다.
내가 하스켈 커뮤니티에 애정이 부족한 건 특정 누구의 _잘못_이라고 생각하지 않는다. 아마 단지 내가 그 문화에 특별히 공감하지 못하는 것일지도 모른다. 사실 나는 그런 식으로 공감할 수 있는 커뮤니티가 많지 않다. 그것은 하스켈이나 하스켈러보다도 나 자신에 대해 더 많은 것을 말해준다.
인식하고 동일시할 수 있는 사람들이 부족해서 소외감을 느낀다고 말하고 싶은 유혹도 있다. 사실 하스켈 커뮤니티는 압도적으로 남성 중심이고, 그건 때로 정말 외로웠다. 또 하스켈 커뮤니티에는 하스켈을 지적으로 흥미롭기 때문에 좋아하거나 범주론을 좋아해서 lens 같은 라이브러리에서 그런 아이디어를 탐구하는 것을 즐기는 사람들이 많이 모이지만, 나는 하스켈이 유용한 소프트웨어를 쓰기 위한 실용적 수단일 때에만 관심이 있다. 그럼에도 하스켈을 쓰는 여성도 있고, 하스켈로 유용한 소프트웨어를 쓰는 것에 매우 관심 있는 사람도 있다. 그런데도 내 커뮤니티에 대한 감정이 크게 달라지지 않았으니, 그 둘이 주요 원인이라고 말하는 건 솔직하지 못할 것이다.
하스켈에 대해서 내가 표현할 수 있는 실질적인 좌절이 하나 있다면, 그건 ‘돈이 어디에서 오는가’이다. 내가 관여한 내내 하스켈은 주로 핀테크와 암호화폐가 사용하고 자금을 댔다. 나는 핀테크에 딱히 반감이 없지만, 특별히 흥미롭지도 않다. 반면 크립토에 대해서는 반감이 있다. 트위터가 비운 자리가 생기기 전까지 나를 팔로우했던 사람들은 내가 항상 그 점을 공개적으로 밝혀 왔다는 걸 알 것이다. 여기에선 자세히 늘어놓고 싶지 않다. 다만, 사용자들이 그 언어를 내가 최선의 경우 무관심하고 최악의 경우 적대감이 드는 방식으로 적용하는 것을 보는 것이, 그 언어에 동기부여가 되지 않는다는 사실만큼은 분명하다. 여기에 쉬운 해법이 있는 건 아니지만, 이것이 내가 GHC에 대한 흥미를 잃은 가장 크고 구체적인 이유라고 할 수 있다. 만약 내가 떠나는 것을 안타까워한다면, 적어도 반쯤은 실행 가능한 이유 하나는 드릴 수 있겠다.
오해하지 말자. GHC는 정말 놀라운 프로젝트이고, 여전히 때때로 ‘미래에서 온 컴파일러’처럼 느껴진다. 그걸 직업의 일부로 다룰 기회를 얻은 건 기술적으로 내가 바랄 수 있는 것 중 가장 자극적인 경험이었다. 그럼에도 Tweag에서 일하던 동안 나는 내가 궁극적으로 하스켈 프로그래머—그 집단에 내가 과연 포함되는지조차 모르겠다—를 위해 일하고 있다는 생각을 자주 했다. 개인 프로젝트는 많지만, 나는 하스켈을 선택해서 쓴 적이 한 번도 없다. 단 한 번도. 무언가를 하려고 코드를 써야 하면 언제나 Racket이었다. 이 블로그도 Racket으로 되어 있다. 내 개인 쉘 유틸리티도 Racket이다. 웹을 긁거나 어떤 라이브러리를 감쌀 때도 Racket으로 한다. 하스켈은 늘 직장에서만 썼고, 내가 하스켈의 많은 점을 진심으로 사랑한다 해도, 순수한 열정만으로 기여하고 싶을 정도로 소중하진 않았다. 내가 만든 도구를 하스켈 사용자들이 더 영감적이고 흥미로운 일에 쓰고 있었다면, 그 일들에 간접적으로 기여하고 싶다는 동기가 훨씬 컸을 것이다. 하지만 하스켈은 소수가 쓰는 틈새 언어이고, 거의 아무도 혜택을 보지 못할 기술적 경이를 내 삶 대부분을 바쳐 만드는 것은 내게 쉽지 않다.
마지막으로 하나 덧붙이자면: 함수형 프로그래밍과 프로그래밍 언어 커뮤니티는 인구통계학적 다양성이 훨씬 더 필요하다고 나는 진심으로 믿는다. 소프트웨어 엔지니어링 전체와 비교해도 성비는 솔직히 믿기 힘들 정도로 암울하다. 나는 대개 남성 쪽으로 기운 관심사와 취미에 끌리는 편이고, 그것이 늘 나를 괴롭힌 적은 없었다. 그런데 _나_조차 다른 여성의 부재를 너무 뚜렷이 느껴서—과거에는 그 이유만으로 하스켈을 그만둘까 고민했을 정도로—그렇다면 상황이 극히 심각하다고 말해도 무리가 아닐 것이다. 더 넓은 관점이 이른바 ‘산업 하스켈’이라는 침체된 생태계에 신선한 창의성을 주입할 수 있을 것이다. 물론 그 목표를 어떻게 달성할 수 있는지는 나도 전혀 모르고, 이 문제는 이 글에서 다루기에는 너무 넓고 복잡하다. 지금은 여기까지만 하겠다. 다만 내 목소리가 충분히 신뢰받길 바라며, 몇몇 독자들이 이 말을 마음에 새겨 주길 바란다.
이 글을 쓰기 전, 나는 친구들에게 이 글을 ‘일종의 사과문’처럼 소개했다. 때때로 나는 끝내지 못한 모든 시도, 결실을 맺기 전에 멈춰 버린 모든 일의 무게에 짓눌린다. 그럼에도 지금 이 글을 쓰며 지난 10년 동안 해낸 일들을 떠올리니, 내가 남긴 자취가 생각만큼 음울하지만은 않다는 생각이 든다.
십 년의 축적을 돌아보고 그 안에서 진정한 자부심을 느낄 것이 꽤 있다는 사실은 위안이 된다. 나는 Racket과 하스켈에 대한 내 기여, 그 각각에서 만든 수많은 라이브러리가 자랑스럽다. Hackett과 eff 같은 실험들, 그리고 그것들이 다른 이들에게 불러일으킨 훌륭한 작업들도 자랑스럽다. 이 블로그 자체도 자랑스럽다. 내가 쓴 글들 중 가장 큰 영향력을 준 글들부터 훨씬 더 틈새적인 글들까지. Programming Languages Stack Exchange에 한 기여도 자랑스럽고, 그곳의 모더레이터 역할은 계속할 생각이며 앞으로도 분명 기여를 이어 갈 것이다. 그리고 수년간 발표했던 수많은 강연 역시, 모두 사랑으로 빚은 결과물이라 자랑스럽다.
나는 늘 목표한 것을 다 이루지는 못했다. 어떤 것들은 이러저러한 이유로 내 역량을 넘어섰다. 수학 조판 시스템에서 GHC의 화살 표기법 개선에 이르기까지, 언젠가 결승선을 넘기고 싶은 일들이 많다. 하지만 지금은 내 마음이 더 이상 진심으로 그곳에 있지 않다는 게 분명하다. 그래서 놓아줄 때가 되었다고 생각한다. 어쩌면 다른 이들이 거기에서 영감을 얻을지도 모른다. 어쩌면 당신이 내가 못한 것을 이룰지도 모른다.
이처럼 내 삶의 큰 장을 떠난다는 생각은 조금 슬프다. 지금껏 나는 거의 전 경력을 이 전문적인 틈새에서 보냈고, 아마도 완전히 떠나지는 못할 것이다. 수많은 똑똑하고 사랑스럽고 영감을 주는 사람들과 함께 일한 것은 기쁨이었다. 언젠가 다시 돌아오고 싶어질지도 모른다. 하지만 지금은 내 관심사가 다른 곳에 있고, 씁쓸함과 달콤함이 함께 있지만, 동시에 새로운 것을 할 수 있다는 유혹적인 기회가 주는 설렘이 분명히 있다.
십 년 동안 점점 더 이국적인 프로젝트를 좇다가, 지금 내가 가장 끌리는 것이 아주 평범한 것이라는 사실이 조금 우습다. 나는 지극히 보통의 소프트웨어를 쓰고 싶다. 사람들이 어떤 일을 해내는 데 쓰는 소프트웨어를 만들고, 그것을 잘 해냈다는 자부심과 만족을 느끼고 싶다.
그게 정확히 어떤 모습일지는 아직 모르겠다. 그런 일을 마지막으로 했다고 느낀 지 6년이 넘었고, 그때도 일의 일부였을 뿐이다. 십오 년을 큰 진흙 공을 자바 IDE에서 씨름하는 일을 피하려 온갖 방법을 다 써 왔는데, 이제 와서 그 경험이 편안하게 느껴진다면 그게 그렇게 이상한가?
2022년 말, 나는 즉흥적으로 2008년 자바 브라우저 게임인 Shattered Plans를 리버스 엔지니어링하고 되살리기로 했다. 그러는 동안 IntelliJ에서 엄청나게 많은 시간을 보냈고, 몇 년 동안 그럴싸한 언어로 평문 편집기와 터미널 에뮬레이터, 그리고 꿈만 갖고 코드를 쓰던 내게 그 경험은 거의 본능을 자극할 만큼 짜릿했다. 흔히 남의 떡이 커 보인다지만, 설령 그렇다 해도 나는 직접 확인해 보고 싶다.
더 중요한 것은, 내 삶이 스무 살 내내와는 아주 달라졌다는 것이다. 그때 나는 싱글이었고, 근무 시간이건 아니건 하루 종일 코드를 생각하는 데 시간을 쏟는 것이 쉬웠다. 열두 시간, 심지어 열여섯 시간을 책상 앞에서 보내며 마음을 사로잡은 무언가를 만지작거리는 일이 예사였다. 재미있었고, 그렇게 해서 좋았다. 하지만 지금 나는 내 영혼의 한 덩이를 영구히 바치지 않아도 되는, 단순하고 규칙적인 일을 할 준비가 되어 있다. 낭만적이진 않지만, 낭만은 다른 데 쓸 게 있다.
만약 당신이 위의 (확실히 매우 폭넓은) 기준을 충족하는 자리를 가지고 있고, 나를 채용하고 싶다고 생각한다면, 언제든지 이메일을 보내 달라. 내가 할 수 있는 최악은 답장을 하지 않는 것이다. 그리고 누가 알겠는가? 나 자신에 대한 기대의 짐을 내려놓고 나면, 이 오래된 블로그의 먼지를 털어내고 다시 글을 쓰기 시작할지도. 다음에 무엇을 쓸지, 내 일과 마찬가지로 지금은 알 수 없다. 어느 쪽이든, 백지에서 시작할 수 있다는 건 조금 설레는 일이다.
이 주제에 대해 빙빙 돌며 2만 자를 더 쓸 수도 있겠지만, 솔직히 그러고 싶지 않다. 이 글이 전하듯, 이제는 끝내고 싶다. 그러니 이 정도면 충분하리라. 어수선한 중언부언을 끝까지 읽어 준 모든 분께 개인적으로 감사드린다.
오랜 시간이었고, 다음 10년을 위하여.
