요약
LLM이 코드를 빨리 쓰는 지금은 고치고 확인하는 주기가 빠른 Common Lisp가 가장 나은 언어라는 주장입니다.
개인 블로그 vivienhenz.com에 올라온 글입니다. 작성자는 LLM이 코드를 대신 쓰면서 병목이 코드 작성에서 컴파일과 디버깅으로 옮겨 갔다고 봤습니다. 그래서 언어를 고르는 기준도 바뀌어야 한다고 했습니다.
왜 중요한가
- 언어의 장단점을 사람의 취향이 아니라 LLM이 일하는 방식에 맞춰 다시 따져 보자는 시각입니다.
- 라이브러리와 인력이 부족하다는 Lisp의 오랜 약점을 LLM이 메워 준다고 봤습니다.
핵심 내용
- Common Lisp는 읽기·컴파일·실행 시점의 구분이 없어 프로그램을 재시작하지 않고 코드를 바로 바꿀 수 있다고 했습니다.
- 오류가 나도 프로그램이 죽지 않고 스택과 변수가 남은 채 디버거가 열려, LLM이 원인을 바로 찾을 수 있다고 했습니다.
- 작성자가 만든 앱은 Python판보다 6~7배 짧아 토큰 비용이 줄고 코드 전체가 컨텍스트 창에 들어간다고 했습니다.
- 코드와 데이터가 같은 리스트 구조라서 매크로(코드를 받아 다른 코드로 바꾸는 기능)로 전용 언어를 만들기 쉽다고 했습니다.
- 라이브러리는 LLM이 새로 쓰거나 옮겨 오면 되고, 사람은 배우는 능력을 보고 뽑으면 된다고 반박했습니다.
HN 반응
- 여러 이용자가 Python, Rust, Go 쪽도 저마다 LLM을 근거로 자기 언어가 최고라고 한다며, 쓰임새를 빼고 최고 언어를 따지는 논쟁 자체를 꼬집었습니다.
- 토론은 다른 언어로 번졌고, 타입이 엄격한 Scala에서 LLM이 덜 헤맨다는 경험담과 컴파일이 빠른 Go가 유리하다는 주장이 이어졌습니다.
다들 "LLM이 이래서 더 잘 다루니까 이제 내가 좋아하는 언어가 최고"라며 저마다 이유를 하나씩 갖다 붙이는 것 같아요.
Javascript/Python은 LLM이 학습할 코드가 워낙 많고, 테스트도 잔뜩 짜서 다 맞는지 확인할 수 있으니 최고라고 하죠. 컴파일할 것도 없으니 LLM이 빠르게 반복할 수 있고요.
Rust는 타입 시스템이 탄탄해서 컴파일러가 LLM에게 훌륭한 피드백을 주고, 빌림 검사기(borrow checker)도 대신 상대해 주니까 최고래요.
Go는 언어가 단순하고 타입 시스템도 쓸 만해서 LLM이 추론하기 좋고,
err반환값 검사를 깜빡하는 일도 없으니 최고라고 합니다. 컴파일러가 빨라서 LLM이 빠르게 반복할 수 있다는 건 덤이고요.C, C++, Java에 대해서도 비슷한 찬사를 얼마든지 쓸 수 있어요.
이쯤 되면 "LLM 때문에" 최고인 언어는 없다고 봐요. LLM이 잘 못 다루는 언어도 꽤 있겠지만, 잘 다루는 언어를 원한다면 고를 수 있는 선택지는 많으니까요.
Python에서는 제 경험이 다릅니다. 규모가 큰 기능을 Python으로 짜게 하면 제가 쓰는 LLM(Claude)이 자주 같은 자리를 맴돌며 헤어나오지 못하더군요. Scala로도 작업을 많이 하는데, 이쪽은 인터넷에 올라온 코드가 훨씬 적은데도 Claude가 훨씬 잘합니다. 막히는 일이 거의 없습니다.
제 가설은 이렇습니다. Python 코드가 인터넷에 아주 많긴 해도 그중 상당수는 쓰레기입니다. 그러니 LLM이 쓰레기 같은 해법에 빠져들고, 결국 그게 발목을 잡는 거죠.
또 특히 규모가 큰 코드베이스에서는 강한 타입 시스템이 사람뿐 아니라 LLM에게도 도움이 된다고 믿습니다.
일반적으로도 Python 코드를 형편없이 짜요. 전역 변수에 최상위 함수 투성이고요. Claude가 객체지향을 싫어하거나 프로젝트 컨벤션을 따르기 싫어하는 것 같다니까요.
최상위 함수가 뭐가 문제인데요?
LLM 입장에서 억울할 수도 있어요. 현업 개발자 중에도 그렇게 짜는 사람이 많거든요. 아마추어와 프로가 짠 소스 코드로 학습했으니, 쓰레기를 넣으면 쓰레기가 나오는 것도 놀랄 일은 아니죠.
Scala가 잘 맞았다니 반갑습니다. 저는 에이전트에게 Gala로 코드를 짜게 해 보고 싶었습니다. Scala에서 영감을 받아 Go로 트랜스파일되는 언어인데, Go의 약점(특히 에이전트 개발에서의 약점)을 보완하면서도 컴파일 속도, 독립 실행되는 단일 정적 바이너리, 표준 라이브러리와 백엔드 라이브러리/생태계, 훌륭한 도구는 그대로 가져가려는 언어입니다.
Go가 최고인 이유는 런타임이 꽤 빠르고, 컴파일이 아주 빠르고, 생태계가 풍부하고, 배포가 간단해서입니다.
덤빌 테면 덤비세요. 저는 전통적인 소프트웨어 엔지니어로서 Go를 싫어하지만, 이 새로운 시대에는 Go가 너무 쉽게 이겨요. 적어도 웹에서는요. 언어가 어떤 느낌이냐 하는 주관적인 부분은 이제 다 창밖으로 날아갔습니다.
그 장점은 전부 Java/Kotlin에도 해당되고, 오히려 더 그렇습니다. 그러면 LLM은 다 Java로 써야겠네요.
이런 논쟁은 제대로 결론이 나는 법이 없습니다. AI가 바꾸는 건 별로 없다고 봅니다. AI도 우리와 비슷한 방식으로 생각하고 속도만 더 빠를 뿐이라서, 사람에게 어렵거나 비생산적인 일은 AI에게도 어렵고 비생산적일 수 있습니다. 예외도 몇 가지 있긴 합니다. 날 어셈블리나 바이트코드를 읽는 것처럼 사람에게는 어리석은 짓인 일이 AI에게는 빠르게 추론할 수 있어서 별일 아닌 경우죠. 하지만 대체로 똑같습니다.
상위 댓글에서 이것도 말했습니다.
또 제 경험상 Java 프로그램은 메모리 오버헤드가 Go보다 더 큽니다. Go는 GOGC=100이 기본값이라 프로그램이 힙에 들고 있는 양의 약 2배 정도인데도요.
제 경험으로는 배포가 더 어렵지 않습니다. 이렇게 말하는 사람들은 보통 배포를 "scp binary user@host"로 떠올리죠. 그럼,
새 버전을 올릴 때는 이걸 반복하면 됩니다. rsync가 scp보다 어렵지도 않고, Java 쪽이 (증분 전송이라) 더 빠릅니다. 호스트에 JVM이 설치되어 있지 않다면, 뭐... apt-get으로 설치하세요. 배포판이 알아서 최신으로 유지해 줍니다. 명령어 하나면 됩니다.
하지만 현실에서는 대부분의 소프트웨어를 바이너리를 복사해서 배포하지 않습니다. 최소한 systemd나 kubernetes로 실행하고 싶을 테니까요. Docker 컨테이너를 원한다면 그것도 꽤 쉽습니다. 프레임워크가 기본으로 설정해 줄 겁니다.
호스트에 푸시하고 시작하면 됩니다.
결국 더 어렵지 않은 이유는, 위 방식이 실제 배포에서 튀어나오는 귀찮은 세부 사항을 많이 해결해 주기 때문입니다. 이를테면 호스트의 CPU와 CPU 확장 기능이 뭔지 알아야 하는가? 전체를 다시 복사하지 않고 증분으로 배포할 수 있는가, 아니면 그게 상관없는가? 같은 문제요.
위는 서버 얘기지만 CLI 도구에서도 크게 어렵지 않습니다. Fat JAR가 있으니까요. 사용자에게 JVM이 없다면, 이번에도 패키지 관리자로 쉽게 설치하면 끝입니다. 세상에 있는 온갖 OS와 CPU 조합마다 여섯 개씩 바이너리를 만들어 배포할 필요가 없습니다.
그래도 AOT 컴파일 바이너리를 만들고 메모리 사용량도 낮추고 싶다면, 둘 다 해 주는 GraalVM이 있습니다. 선택은 여러분 몫이죠.
위의 논쟁이 AI 때문에 전혀 바뀌지 않는다는 점에 주목하세요. AI의 약점은 약점으로, 강점은 강점으로 남습니다. 저라면 기능이 빈약하고 디버깅 지원이 부실해서(에러가 스택 트레이스를 안정적으로 만들어 주지 않죠) Go는 쓰지 않을 겁니다. 하지만 LLM의 등장은 이런 취향과 선택을 하나도 바꾸지 않습니다. 기껏해야 이론상 토큰 효율을 얘기할 수 있겠지만, 그것이 실제로 미치는 영향을 측정하려는 시도에서 결정적인 증거가 나온 것 같지는 않습니다.
JAR를 빌드해서 실행하는 것도 딱히 더 어렵지 않죠.
그리고 Go와 비교하면 프로덕션 관측성(observability)이 아주 좋습니다.
저는 Clojure도 쓰는데, 실행 중인 앱을 완전한 REPL로 관찰할 수 있습니다.
Go에는 부족하고 Java는 훌륭한 사례를 들어 주실 수 있나요? (되도록 내장된 기능으로요. 내장이 아니라면, Go에 외부에서 개발된 대안조차 없는 것으로요.)
이게 Java 같은 다른 JVM 언어에서도 되나요?
특히 이 논쟁은 쉽게 결론이 납니다. 모든 용도에 맞는 "최고"의 언어는 없고, LLM이 그걸 바꾸지 못했다는 데에 저도 동의합니다. 어떤 상황에 가장 좋은 언어는 전적으로 그 상황에 달려 있으니, 상황을 염두에 두지 않고 최고의 언어를 논하는 건 애초에 잘못된 논의입니다.
전적으로 동의해요. "최고"요? 뭐에 최고인데요? 프로그램 작성에? 그런데 어떤 프로그램이요? "범용 프로그래밍"이요?
저는 평생 범용 프로그램은 한 번도 짜 본 적이 없어요. 구체적인 프로그램은 잔뜩 짜 봤지만요. 제가 신경 쓰는 건 지금 이 프로그램을 짜기에 어떤 언어가 가장 좋으냐예요. 제가 짜지도 않는 프로그램을 짜기에 어떤 언어가 가장 좋은지를 왜 신경 써야 하죠?
저는 Go로 은하 문명 시뮬레이션을 만들고 있는데, 시뮬레이션을 아주 많이 반복해도 컴파일도 실행도 엄청나게 빠르고, 위험한 서드파티 라이브러리 같은 건 의존성이 0개예요.
저는 Java, C#, PHP 등으로 복잡한 계산 시스템과 웹서비스를 오랫동안 만들어 온 꽤 경험 많은 소프트웨어 엔지니어인데, Go는 여러 면에서 그냥 더 낫다는 느낌이 듭니다. 예를 들어 Java가 아직 더 편하게 느껴진다면, 그건 순전히 제가 Java에 훨씬 더 많은 시간을 썼기 때문이고요.
그래서 말씀하시는 바는 저도 공감하고, 정말 공감해요. (다만 저는 Go가 싫지는 않아요. 기회를 줘야 한다고 생각합니다.)
웹 개발이라면 그럴 수 있겠네요. 그런데 수치 물리 시뮬레이션을 하는 입장에서, 저수준은 C/C++/Fortran, 고수준은 Python, 아니면 둘 다 Julia로 하는 대신 정말 Go를 추천하시겠어요?
아주 저수준의 C++ 수동 메모리 최적화까지 하는 게 아니라면 둘 다 Go를 추천합니다. 속도가 C/C++/Fortran과 같은 수준이고 컴파일 시간이 엄청나게 빨라서, Python 같은 고수준 스크립트 언어로 프로토타이핑할 필요가 굳이 없습니다.
고루틴(Goroutine)으로 병렬 처리가 아주 쉽고, 생태계도 훌륭하고, 어떤 프로그래밍 언어와 비교해도 손꼽히는 프로파일러인 pprof도 있습니다.
흥미롭네요. 병렬 처리와 프로파일링은 둘 다 확실한 장점이네요.
예전에는 꽤 저수준의 C++와 Fortran도 해 봤지만, 요즘은 솔직히 계산에 NumPy나 CuPy를 곁들인 Python을 주로 써서 저수준과는 거리가 멀어요. 그래도 코드가 성능에 꽤 민감해서, 핵심 연산을 NumPy나 CuPy 기본 연산으로 깔끔하게 표현할 수 없으면 저수준으로 내려가야 했습니다.
행렬 대각화, 희소 행렬, 그런 계산을 CUDA(나 다른 GPU 프레임워크)로 넘기는 것 같은 전형적인 과학 계산용 Go 라이브러리 지원은 어떤지 아세요? 요즘 Go에 탄탄한 수치 계산 커뮤니티가 있나요, 아니면 필요한 걸 대부분 직접 구현해야 하나요?
찾으시는 건 아마 Gonum일 겁니다. 필요한 최적화된 선형대수 기능은 대부분 갖추고 있을 거예요.
https://github.com/gonum/gonum
희소 행렬은 여전히 CPU용 Intel MKL의 희소 라이브러리가 가장 낫다고 생각합니다. 밀집 SGEMM에 비하면 GPU에서 잘 돌아가는 워크로드가 아니거든요. CGo로 호출하면 됩니다.
GPU 오프로딩은 지금 Go용 CUDA 바인딩이 꽤 있을 텐데, 저는 Vulkan으로 제 GPU 컴퓨트 런타임을 만들고 있어서 그쪽에는 익숙하지 않습니다. 그 작업도 아직 한창 실험 중이고요.
저는 최근까지 Go를 피해 왔습니다.
AI와 더 작아진 Docker 이미지 때문에 다시 보게 됐어요.
sccache나 worktree를 건드리지 않고도 같은 저장소에서 Rust보다 훨씬 빠르게 테스트와 빌드를 동시에 돌릴 수 있다는 점 때문에, 웹이나 자체 완결형 시나리오에서는 어렵지 않게 Go가 승자입니다.
전통적인 소프트웨어 엔지니어라서 Go가 싫다니, 대체 뭐가 문제인가요?
아마 이 패턴 때문이겠죠:
C에서는 이렇게 쓰는데,
...
...
별로 다르지 않잖아요.
C는 1972년, golang은 2007년에 나왔습니다. 그 사이에 새로운 개념이 하나도 발견되지 않은 게 아니거든요. <cough>예외 처리</cough> 같은 거 말이죠. 펜이 끌보다 우아한 것과 마찬가지입니다.
그럼 별로 전통적인 사람은 아닌가 보네요.
C도 싫어하지 않는다고 말한 적은 없잖아요.
맞는 말이네요. 제 머릿속에서 "전통적인 소프트웨어 엔지니어"는 C를 뜻하는데, 잘못된 가정일 수도 있겠어요.
어떤 사람들에게는 Fortran이죠. 하지만 맞는 말씀입니다. :-)
Go가 다른 대안보다 배포가 어떻게 더 간단하죠? C++도 정적 링크 바이너리로 컴파일하는 건 옛날부터 됐는데요.
Go의 컴파일 시간은 AI 시대에 아주 훌륭하다고 생각하지만, "꽤 빠른 런타임"은 그렇지 않아요.
저는 임베디드 시스템용으로 C++를 많이 짜 봤고 Go는 거의 안 써 봤습니다만, C++를 웹에 연결하려는 사람을 보면 사이버 보안 위반으로 해고당하게 만들려고 애쓸 겁니다.
런타임은 Go도 합리적인 목적에는 충분히 가깝습니다.