생성형 AI가 코드를 대신 써 주는 시대에, 정작 사람이 고민해야 할 질문은 "어떤 언어를 타깃으로 삼을 것인가"로 옮겨가고 있다. 한 리스프 계열 블로그(funcall.blogspot.com)의 글쓴이는 이 질문을 두 번이나 받았다고 한다. "AI가 문법을 대신 써 준다면, 왜 굳이 커먼 리스프(Common Lisp) 같은 비주류 언어를 고르느냐"는 것이다. 파이썬, 타입스크립트, 자바처럼 학습 데이터가 방대한 주류 언어라면 모델이 훨씬 높은 통계적 정확도로 코드를 뽑아낼 텐데 말이다. 글쓴이의 대답은 오래된 리스프 논쟁의 재현이면서, 동시에 AI 코딩 시대에 새롭게 읽어볼 만한 관점을 담고 있다.
인기와 유용성은 다른 축이다
글의 핵심 주장은 단순하다. 언어의 인기는 유용성이나 표현력을 재는 좋은 척도가 아니라는 것이다. 리스프 진영이 오래전부터 인기와 무관하게 리스프를 택해 온 이유가 바로 여기에 있다고 글쓴이는 말한다. 그는 다소 도발적인 비유를 든다. 인기를 기준으로 언어를 고르는 것은 "언제든 유지보수할 사람을 구할 수 있게 하려는 중간관리자의 선택"이지, 뛰어난 해커의 선택은 아니라는 것이다. 뛰어난 해커에게는 그에 걸맞은 도구를 쥐여 줘야 하며, AI가 코드 몽키가 아니라 엘리트 해커처럼 일하기를 기대한다면 엘리트의 도구를 줘야 한다는 논리로 이어진다.
이 주장은 감정적 수사가 강하지만, 그 밑에는 나름의 기술적 직관이 깔려 있다. 리스프는 코드와 데이터가 같은 형태(S-표현식)를 공유하고, 매크로를 통해 언어 자체를 확장할 수 있는 동형성(homoiconicity)을 특징으로 한다. 즉 표현력의 상한이 높고, 추상화를 쌓아 올릴 여지가 크다. 문법을 짜는 노동을 AI가 떠맡는 상황이라면, 인간에게 남는 가치는 오히려 "얼마나 강력하게 추상화된 결과물을 다룰 수 있느냐"에 있다는 발상이다.
AI 코딩이 언어 선택의 계산식을 바꾼다
실무자 입장에서 주목할 대목은, 생성형 AI가 전통적인 언어 선택 기준을 흔든다는 점이다. 그동안 비주류 언어를 피하는 가장 현실적인 이유 중 하나는 "작성하고 유지보수할 인력을 구하기 어렵다"는 조직적 제약이었다. 그런데 코드 생성을 LLM이 상당 부분 담당하게 되면, 이 인력 수급 논리의 무게가 줄어든다. 문법의 진입장벽이 낮아지는 만큼, 언어의 표현력이나 런타임 특성 같은 본질적 요소를 더 우선순위에 둘 수 있다는 논지가 성립할 여지가 생기는 것이다. 글쓴이가 참고 자료로 제시한 skewed-emacs 프로젝트(github.com/gornskew/skewed-emacs)는 LLM 에이전트로 커먼 리스프 코드를 생성하려는 구체적 시도의 사례다.
반대편의 계산도 잊지 말아야
다만 이 논리를 그대로 받아들이기 전에 짚어야 할 한계가 분명하다. 글 자체가 인정하듯, 주류 언어가 높은 통계적 정확도로 코드를 생성해 내는 이유는 방대한 학습 데이터에 있다. 커먼 리스프처럼 공개 코드가 상대적으로 적은 언어에서는 모델의 생성 품질, 최신 라이브러리 대응, 오류 패턴 회피 능력이 떨어질 가능성이 크다. 즉 "엘리트 도구를 주면 AI가 엘리트처럼 일한다"는 명제는 아직 검증된 사실이라기보다 글쓴이의 신념에 가깝다. 이 글에는 리스프 타깃이 실제로 더 나은 결과를 낸다는 정량적 근거나 비교 실험이 제시되어 있지 않다.
또한 언어의 표현력이 팀 전체의 생산성으로 곧장 이어지는 것도 아니다. 아무리 AI가 문법을 써 준다 해도, 생성된 코드를 읽고 검증하고 디버깅하는 최종 책임은 사람에게 남는다. 리스프에 익숙하지 않은 조직이라면 오히려 리뷰 비용이 커질 수 있고, 생태계·도구·채용 측면의 현실적 마찰도 사라지지 않는다. 이 글이 다루지 않는 부분이 바로 그 지점이다.
그럼에도 이 주장을 흘려듣기 어려운 이유는, AI 코딩이 "어떤 언어를 왜 쓰는가"라는 질문의 전제를 실제로 바꾸고 있기 때문이다. 인기 기반 선택이 지배하던 관성에 균열이 생긴 것은 분명하다. 결국 남는 것은 취향 싸움이 아니라 검증 가능한 질문이다. 특정 언어를 타깃으로 삼았을 때 AI의 생성 품질과 인간의 검증 부담이 실제로 어떻게 달라지는지를, 각 팀이 자신의 맥락에서 측정해 볼 만한 시점이 됐다.