46년 전 글을 지금 읽는 이유
'LISP Comes of Age(LISP, 성년이 되다)'는 1980년에 쓰인 글이에요. 1980년이면 애플 II가 나온 지 3년쯤 지났고, IBM PC는 아직 나오지도 않았을 때거든요. 그런 시기에 이미 20년 넘게 연구실에서 쓰이던 언어를 두고 '이제 어른이 됐다'고 말한 거예요. 흥미롭지 않나요?
옛날 글을 왜 읽나 싶을 수도 있는데요, LISP은 '옛날 언어'로 끝나지 않았어요. 가비지 컬렉션, REPL, 람다처럼 우리가 매일 쓰는 것들이 LISP에서 처음 나왔거든요. 그래서 1980년에 LISP이 어디쯤 와 있었는지, 그리고 그 아이디어들이 지금 어떻게 살아남았는지 같이 따라가 볼게요.
LISP은 어떻게 시작됐나
LISP은 1958년 MIT의 존 매카시(John McCarthy)가 구상한 언어예요. 이름부터 'LISt Processing', 그러니까 리스트를 처리하는 언어라는 뜻이죠. 매카시는 1960년 논문에서 기본 연산 몇 개만으로 계산을 표현할 수 있다는 걸 보였어요. 원래는 수학 이론에 가까운 아이디어였어요. 그런데 함께 일하던 스티브 러셀이 논문 속 eval 함수를 IBM 704에 실제로 구현했고, 그때부터 '진짜 돌아가는 언어'가 됐죠.
지금도 쓰이는 car, cdr라는 독특한 이름도 이때 생겼어요. 이게 뭐냐면, IBM 704의 메모리 한 칸(워드)에서 '주소 부분'과 '감소(decrement) 부분'을 꺼내는 연산의 이름이에요. 하드웨어는 사라졌는데 이름은 60년 넘게 살아남았어요.
핵심: 코드와 데이터가 같은 모양이다
LISP을 처음 보면 괄호가 너무 많아서 당황하게 되는데요, 사실 이 괄호가 LISP의 가장 큰 무기예요.
(+ 1 2 3) ; 결과: 6
(list 1 2 3) ; 결과: 리스트 (1 2 3)
(defun square (x) (* x x)) ; 함수 정의도 리스트
함수 호출도 리스트고, 함수 정의도 리스트예요. 이걸 동형성(homoiconicity)이라고 해요. 쉽게 말하면 “코드가 그 언어로 다루는 데이터와 똑같은 모양”이라는 뜻이에요. 비유하자면 레시피가 재료와 같은 형태로 적혀 있어서, 레시피 자체를 재료처럼 썰고 섞을 수 있는 셈이에요.
그래서 LISP의 매크로는 단순히 문자열을 바꿔 끼우는 수준이 아니에요. 코드를 받아서 코드를 돌려주는 진짜 프로그램이죠. 다른 언어에서는 새 문법을 넣으려면 컴파일러를 고쳐야 하는데, LISP에서는 매크로로 나만의 문법을 직접 만들 수 있었어요.
1980년, LISP은 어디쯤 와 있었나
1980년 무렵 LISP은 연구실을 벗어나 산업으로 넘어가는 문턱에 있었어요. MIT에서는 MacLisp을, BBN과 제록스 PARC에서는 Interlisp를 썼고, 1975년에는 훨씬 간결한 방언인 Scheme도 나왔죠. 무엇보다 LISP만을 위한 전용 컴퓨터인 LISP 머신이 등장했어요. 1979~1980년에는 MIT AI 연구실의 LISP 머신을 바탕으로 LMI와 Symbolics 같은 회사가 세워졌고요. '성년이 됐다'는 말이 딱 어울리는 시기였던 셈이에요.
하지만 그 뒤가 해피엔딩만은 아니었어요. 1980년대 AI 붐을 타고 LISP 머신 시장이 커졌지만, 싸고 빠른 범용 워크스테이션이 나오면서 전용 하드웨어는 경쟁력을 잃었어요. 80년대 후반 'AI 겨울'이 오면서 LISP 머신 회사들도 무너졌고요. 여기저기 흩어진 방언을 하나로 묶으려던 Common Lisp은 1984년에 첫 명세가 나왔고, 1994년에 ANSI 표준이 됐어요.
지금 LISP의 DNA는 어디에 있나
LISP을 직접 쓰는 회사는 많지 않지만, 그 아이디어는 거의 모든 현대 언어에 퍼져 있어요. Java, Go, Python이 당연하게 쓰는 가비지 컬렉션도, Java 8의 람다나 JavaScript 화살표 함수 같은 일급 함수와 클로저도 다 LISP의 계보예요. Rust, Elixir, Julia의 매크로도 '코드를 데이터처럼 다룬다'는 발상을 닮았고, WebAssembly의 텍스트 포맷(WAT)은 아예 괄호로 된 S-표현식을 써요.
LISP 계열 언어도 여전히 현역이에요. JVM 위에서 도는 Clojure, 교육과 언어 연구에 많이 쓰이는 Racket, 그리고 Emacs 설정 언어인 Emacs Lisp까지요.
한국 개발자에게 주는 시사점
솔직히 실무에서 LISP으로 서비스를 만들 일은 드물 거예요. 그래도 LISP을 한 번 제대로 맛보는 건 꽤 남는 장사예요.
첫째, 컴파일러가 코드를 어떻게 다루는지 감이 와요. 우리가 쓰는 언어도 내부에서는 코드를 트리 구조(AST, 추상 구문 트리)로 바꿔서 처리하는데요, LISP은 그 트리를 괄호로 그대로 보여주는 언어거든요. ESLint 규칙이나 Babel 플러그인, 코드 생성 도구를 만들 때 이 감각이 그대로 도움이 돼요.
둘째, 함수형 사고가 자연스러워져요. React의 불변 상태 관리나 map/filter/reduce 위주의 데이터 처리처럼, 요즘 실무 코드에 깔린 패턴들이 어디서 왔는지 이해하게 되죠.
시작해 보고 싶다면 Racket을 설치하고 고전 교재 SICP(Structure and Interpretation of Computer Programs)의 앞부분을 따라가 보세요. Clojure로 간단한 CLI 도구를 만들어 봐도 좋아요. 주말 이틀이면 '괄호 공포증'은 충분히 넘어설 수 있어요.
마무리
한 줄 정리: LISP은 박물관에 있는 언어가 아니에요. 지금 우리가 쓰는 언어들에 스며든 아이디어의 원본이에요.
여러분은 LISP 계열 언어를 써본 적 있나요? 지금 쓰는 언어에서 “이것도 LISP에서 온 거였어?” 싶은 기능이 있다면 댓글로 알려주세요. 실무에서 Clojure를 쓰는 분이 있다면 경험담도 궁금하네요!
🔗 출처: Hacker News