Scheme 언어에 자꾸 튕겨 나오는 이유 - 함수형 언어의 진입 장벽을 다시 생각하다

"좋다는데 왜 안 익혀지지?"

프로그래밍 언어를 배우다 보면 묘한 경험을 합니다. 분명히 좋은 언어라는 평가를 수없이 들었는데, 직접 써보면 자꾸 튕겨 나오는 거예요. iOS 개발자이자 작가인 Graham Lee가 자신의 블로그에 "나는 Scheme 언어에 자꾸 바운스 오프(bounce off)된다"는 솔직한 글을 올렸습니다. 이게 단순히 한 개발자의 푸념이 아니라, 함수형 언어가 왜 30년이 넘도록 학계와 실무 사이의 다리를 다 못 건넜는지에 대한 좋은 단면이라 흥미롭게 읽힙니다.

Scheme이 뭐냐면, Lisp 계열의 함수형 언어 중 하나예요. MIT의 전설적인 교재 SICP(Structure and Interpretation of Computer Programs)에서 쓰이는 언어로 유명하고, "프로그래밍의 본질을 가장 순수하게 보여준다"는 평가를 받습니다. 괄호로 모든 걸 표현하는 그 특유의 문법, 한 번쯤 보셨을 거예요. (+ 1 2) 이런 식이죠.

무엇이 그를 튕겨 나가게 만들었나

Graham이 지적한 핵심은 "표준"이 사실상 없다는 점입니다. Scheme에는 R5RS, R6RS, R7RS 같은 여러 버전의 표준이 있어요. 그런데 이게 다른 언어처럼 "새 버전이 옛 버전을 대체한다"는 식이 아닙니다. 어떤 사람은 R5RS가 더 우아하다고 주장하고, 어떤 사람은 R6RS가 실용적이라고 하고, 또 어떤 사람은 R7RS-small과 R7RS-large를 구분해서 쓰자고 합니다. 그 결과 구현체마다 따르는 표준이 다르고, 같은 코드가 어떤 Scheme에서는 돌아가고 어떤 Scheme에서는 안 돌아가요.

구현체도 너무 많습니다. Racket, Guile, Chez, Chicken, Gambit, MIT/GNU Scheme, Gauche... 각자 장단점과 생태계가 다르고, 라이브러리도 서로 호환되지 않아요. 파이썬을 배우러 갔는데 "파이썬-A, 파이썬-B, 파이썬-C 중에 뭘 쓸래?" 하고 묻는 상황이라고 생각하면 됩니다. 초보자는 첫 선택부터 막혀버리죠.

Graham이 또 짚은 건 라이브러리 생태계의 빈약함이에요. 웹 요청 하나 보내려고 해도 "이 구현체에는 이 라이브러리가 있고, 저 구현체에는 저 방식으로 해야 하고" 하는 일이 벌어집니다. 파이썬이라면 requests, 자바스크립트라면 fetch로 끝날 일이 Scheme에서는 한참을 헤매야 합니다. 학습 곡선이 "언어 자체의 어려움" 더하기 "환경의 파편화"의 합이 되어버리는 거예요.

그리고 마지막으로 목적의 모호함이 있습니다. 파이썬을 배우면 데이터 분석을 하고, 자바스크립트를 배우면 웹사이트를 만들고, Rust를 배우면 시스템 프로그래밍을 합니다. 그런데 Scheme은 "무엇을 위해 배우는가?"에 대한 답이 잘 안 나옵니다. "프로그래밍의 본질을 이해하기 위해"라는 답은 멋있지만, 실무 개발자에게는 추상적이거든요.

함수형 언어 진영의 비슷한 고민들

사실 이건 Scheme만의 문제가 아닙니다. Haskell도 비슷한 이야기를 자주 듣죠. "우아하다, 강력하다, 그런데 막상 실무 프로젝트 시작하려면 빌드 도구만 stack과 cabal 사이에서 헤맨다" 같은 불평이 항상 있어요. Common Lisp는 더 심하고요.

반면 같은 함수형 계열이라도 Elixir, Clojure, F# 같은 언어들은 비교적 자리를 잘 잡았습니다. 공통점이 있어요. 잘 정의된 단일 구현체, 명확한 타깃 영역(Elixir는 동시성/웹, Clojure는 JVM 위의 데이터 처리, F#는 .NET 생태계), 그리고 현대적인 패키지 매니저(mix, leiningen/deps.edn, paket)가 있다는 점이죠. Scheme이 갖지 못한 것들입니다.

흥미로운 건 Racket의 시도예요. Racket은 사실상 "실용 Scheme"을 표방하면서 자체 표준과 패키지 시스템(raco)을 만들었어요. 덕분에 교육용으로 꽤 자리를 잡았고, DSL(도메인 특화 언어) 만들기에는 거의 독보적입니다. 하지만 "Scheme"이라는 이름의 무게에서 자유롭지 못해 여전히 정체성 혼란이 있어요.

한국 개발자에게 주는 시사점

언어를 고를 때 "순수하게 좋은 언어"라는 기준은 사실 함정일 때가 많습니다. 언어의 품질보다 생태계의 성숙도, 표준의 안정성, 명확한 사용 목적이 학습과 채택을 결정하거든요. 우리가 자바스크립트의 못생긴 부분을 욕하면서도 결국 자바스크립트를 쓰는 이유와, Scheme의 우아함을 칭송하면서도 안 쓰는 이유가 같은 결의 문제입니다.

그렇다고 함수형 언어를 배울 필요가 없다는 건 아니에요. 오히려 정반대입니다. 다만 "실무에 쓸" 함수형 언어와 "사고를 확장할" 함수형 언어를 구분해서 접근하면 좋아요. 실무라면 Elixir나 Clojure, 혹은 Scala·Kotlin의 함수형 기능부터 익히는 게 효율적이고, 사고 확장이 목표라면 SICP를 Racket으로 따라가 보는 게 가장 검증된 길입니다. SICP의 사고방식, 즉 "프로그램을 데이터로 다루고, 추상화 위에 추상화를 쌓는다"는 감각은 어떤 언어를 쓰든 결국 코드 품질을 끌어올려 줍니다.

그리고 Graham의 글이 주는 또 하나의 교훈은, "안 익혀지면 내 잘못이 아닐 수 있다" 는 겁니다. 좋다고 평가받는 기술에 자꾸 튕겨 나간다면, 그 기술의 진입 경로 자체에 문제가 있는 경우가 많아요. 자책하지 말고 다른 입구를 찾아보세요.

마무리

언어는 문법이 아니라 생태계로 살아남습니다. Scheme의 사례는 "좋은 디자인이 곧 성공은 아니다"라는 오래된 진실을 다시 보여줍니다.

여러분이 배우다 "튕겨 나간" 언어가 있나요? 다시 도전해 본다면 어떤 입구로 들어가 보고 싶으세요?