Lisp가 뛰어나도 주류가 되지 못한 이유, 코딩보다 마무리가 어려웠어요

Lisp가 뛰어나도 주류가 되지 못한 이유, 코딩보다 마무리가 어려웠어요

AI 뉴스 썸네일

Lisp는 가비지 컬렉션과 대화형 개발 환경 같은 아이디어를 일찍 보여 줬어요. 그런데 기술적 영향력만큼 널리 쓰이는 언어가 되지는 못했어요. Mark Tarver는 그 간극을 언어의 성능보다 개발자의 성향과 공동체 문화에서 찾았어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
언어	Lisp는 적은 코드로 큰 아이디어를 시험하기 좋은 언어예요	빠른 구현이 완성도와 보급까지 보장하지 않는다는 사례예요
공동체	개인의 독창성은 강했지만 문서화와 유지보수가 약했다는 비판이에요	오픈소스와 사내 도구가 사라지는 이유를 돌아볼 수 있어요
제품	시장은 기술적 순수성보다 호환성, 협업, 인수인계를 함께 봐요	좋은 프로토타입을 오래 쓰는 제품으로 바꾸는 조건이 보여요
주의점	글의 성격 유형은 의학적 진단이 아니라 저자의 비유예요	개발자 집단을 하나의 성격으로 일반화해 읽으면 곤란해요

1. Lisp의 실패를 언어 밖에서 찾은 오래된 논쟁

Tarver는 뛰어난 학생 가운데 짧은 시간에 어려운 문제를 풀지만 반복 작업과 마무리에는 쉽게 흥미를 잃는 유형이 있다고 써요. 그는 이런 사람을 `BBM(brilliant bipolar mind)`이라고 불렀어요. 여기서 양극성이라는 말은 의학적 진단이 아니라 몰입과 침체가 번갈아 나타나는 모습을 설명하려고 쓴 비유예요. 지금 기준으로는 실제 질환과 성격을 섞어 말한다는 점에서 조심해서 읽어야 해요. 2

글은 이 유형과 Lisp가 서로 잘 맞았다고 봐요. Lisp는 추상화 능력이 높고 실행 중에도 프로그램을 고칠 수 있어서 한 사람이 큰 아이디어를 빠르게 구현하기 좋아요. 저자는 이 힘을 팔의 힘을 키우는 지렛대에 비유했어요. 가비지 컬렉션, 리스트 처리, 개인용 컴퓨팅, 윈도 시스템에서 Lisp 공동체가 일찍 아이디어를 내놓은 배경도 여기에 있다고 설명해요.

728x90

문제는 아이디어가 돌아가는 순간과 다른 사람이 안심하고 쓰는 순간 사이에 긴 거리가 있다는 점이에요. Tarver가 과거 Lisp용 그래픽 인터페이스를 찾았을 때 선택지는 9개였지만, 문서가 충분하고 버그가 적은 도구를 찾기 어려웠다고 회고해요. 각 개발자에게는 작동했지만 설치, 설명, 인수인계, 장기 유지보수까지 이어지지 못한 셈이에요.

이 대목은 지금의 오픈소스 프로젝트에도 익숙해요. 저장소를 공개하고 데모를 만드는 일은 시작에 가까워요. 사용법을 적고, 호환성을 관리하고, 이슈에 답하고, 릴리스를 반복해야 비로소 다른 팀의 기반이 돼요. 구현 속도가 빨라질수록 이런 후반 작업이 전체 품질을 좌우해요.

C와 C++를 든 비교는 그대로 받아들이기 어려워요

원문은 C와 C++로 큰 시스템을 만들려면 여러 사람이 협력해야 하므로 문서화와 분업이 자연스럽게 생긴다고 주장해요. 반면 Lisp는 개인이 많은 일을 해낼 수 있어 고립된 개발을 부추길 수 있다고 봐요. 언어의 불편함이 조직의 규율을 만든다는 설명이에요.

다만 이 비교에는 저자의 경험과 선호가 강하게 들어가 있어요. C와 C++ 프로젝트도 문서가 없거나 한 사람에게 의존할 수 있어요. Lisp 프로젝트도 꾸준한 관리와 협업으로 오래 살아남을 수 있어요. GeekNews 댓글에서도 뛰어난 개발자는 언어를 가리지 않는다는 반론이 나왔어요. 언어가 팀 문화를 결정한다기보다, 언어의 특성과 공동체의 보상 구조가 특정 작업 방식을 더 쉽게 만들 수 있다고 읽는 편이 맞아요. 1

기술적으로 옳은 선택만으로는 생태계를 만들기 어려워요

Tarver는 Lisp 머신을 기술적 이상과 시장 현실이 충돌한 사례로 들어요. 전용 하드웨어와 소프트웨어를 한데 묶은 완성도 높은 환경을 추구했지만, 더 널리 보급된 플랫폼과의 경쟁에서는 고립됐다는 설명이에요. Richard Gabriel이 말한 `Worse is Better` 논쟁도 같은 질문을 다뤄요. 단순하고 불완전하더라도 다른 시스템에 쉽게 퍼지는 기술이 정교하지만 닫힌 기술보다 빠르게 자랄 수 있다는 관점이에요.

개발팀이 여기서 가져갈 교훈은 천재성을 경계하자는 얘기가 아니에요. 독창적인 구현 뒤에 누가 문서와 테스트를 맡을지, 담당자가 떠나도 운영할 수 있는지, 기존 도구와 연결되는지를 제품 계획에 넣어야 해요. 프로토타입을 만든 사람에게 배포와 지원까지 무기한 떠넘기면 좋은 아이디어도 개인 프로젝트로 남기 쉬워요.

왜 중요한가요

AI 코딩 도구가 구현 시간을 줄이는 지금, 이 글의 질문은 더 현실적으로 들려요. 코드를 빨리 만들 수 있어도 요구사항 정리, 테스트, 보안 검토, 사용자 지원, 버전 호환은 사라지지 않아요. 생성 속도가 빨라지면 미완성 도구의 수도 함께 늘 수 있어요. 2

새 도구를 팀에 들일 때는 데모의 인상보다 운영 조건을 먼저 확인해 보세요. 설치 절차를 처음 보는 동료가 따라 할 수 있는지, 오류가 났을 때 원인을 찾을 로그가 있는지, 릴리스와 지원 정책이 적혀 있는지 보면 돼요. 핵심 기능을 만든 사람 외에 2명 이상이 수정과 배포를 할 수 있는지도 확인할 만해요.

원문의 인물 묘사는 날카롭지만 모든 Lisp 개발자나 재능 있는 학생에게 적용할 수는 없어요. 특히 정신건강 용어를 생산성의 오르내림과 같은 뜻으로 쓰는 방식은 현재의 임상적 의미와 달라요. 그 한계를 걷어 내고 보면, 뛰어난 아이디어를 공동 자산으로 바꾸려면 마무리와 협업에 별도의 시간과 보상이 필요하다는 주장만큼은 여전히 쓸모가 있어요.

참고 자료

1. 양극성 LISP 프로그래머 — GeekNews
2. the bipolar Lisp programmer — Mark Tarver