Hacker News 2026.04.20 26

프로그래밍 언어의 '조상 일곱'은 누구인가 — 모든 언어는 결국 이 중 하나의 후예

언어 수백 개, 근본은 몇 개일까

프로그래밍 언어는 지금도 계속 새로 태어나고 있어요. Python, JavaScript, Rust, Go, Kotlin, Swift… 이름만 늘어놔도 끝이 없죠. 그런데 2022년에 공개된 블로그 글 "The Seven Programming Ur-Languages"은 이 수많은 언어들이 사실은 일곱 개의 '원형 언어(ur-language)' 중 하나의 자손이라고 주장해요. 독일어 Ur-는 "원래의, 근원의"라는 뜻이에요. 즉, 모든 프로그래밍 언어는 결국 이 일곱 가문 중 하나에 속한다는 아이디어죠.

일곱 개의 가문

이 글에서 말하는 일곱 ur-language는 ALGOL, Lisp, ML, Smalltalk, Forth, APL, 그리고 Prolog예요. 각각이 대표하는 세계관이 꽤 뚜렷해요.

ALGOL은 블록 구조, 지역 변수, 절차형 제어 흐름의 원형이에요. 우리가 익숙한 C, Java, Python, Go는 전부 이 계열의 후예예요. "블록을 중괄호나 들여쓰기로 묶고, 함수를 정의하고, 문장을 순서대로 실행한다"는 기본 모형이 ALGOL에서 나왔거든요.

Lisp은 코드와 데이터가 같은 형태(S-식)로 표현되는 언어의 원조예요. Scheme, Clojure, Racket이 직계고, 매크로 시스템을 갖춘 수많은 현대 언어가 여기서 영감을 받았어요. "코드가 곧 데이터"라는 철학은 메타프로그래밍의 근본이에요.

ML은 정적 타입 시스템과 대수적 데이터 타입, 패턴 매칭의 원조예요. Haskell, OCaml, F#, Rust, Scala의 타입 시스템 감성은 거의 다 여기서 왔어요. sum type, 제네릭, 타입 추론이 이 가문의 상징이에요.

Smalltalk은 "모든 것은 객체이고, 객체끼리는 메시지를 주고받는다"는 세계관이에요. Ruby, Objective-C가 직계에 가깝고, Java, C#도 객체 모델의 상당 부분을 여기서 빌려왔어요.

Forth는 스택 기반 언어의 원형이에요. 매우 낮은 수준에서 스택에 값을 쌓고 연산 단어를 실행하는 방식인데, PostScript나 JVM 바이트코드, WebAssembly의 평가 모델이 이 계열이에요.

APL은 배열 중심 언어예요. 배열 하나에 연산을 걸면 모든 요소에 자동으로 적용되는 '벡터화' 사고방식이죠. NumPy, MATLAB, J, K, Q 같은 데이터 분석 도구들이 APL의 DNA를 물려받았어요.

Prolog는 논리 기반 언어로, "사실을 선언하면 시스템이 답을 찾아준다"는 접근이에요. Datalog, 규칙 엔진, 일부 쿼리 언어의 뿌리죠.

왜 이런 계보가 중요할까

이 분류를 외우는 것 자체가 목적은 아니에요. 중요한 건, 새로운 언어를 배울 때 어떤 가문에 속하는지 파악하면 학습 시간이 훨씬 짧아진다는 점이에요. Rust를 처음 배울 때 "이건 ALGOL의 문법에 ML의 타입 시스템을 얹은 거구나" 하고 프레임을 잡으면, 매크로는 Lisp적 요소고 lifetimes는 독자적 기여라는 식으로 빠르게 구조가 잡혀요.

또 한 가문 안에서만 프로그래밍을 하면 사고방식이 갇힐 수 있어요. ALGOL 계열만 쓰던 사람이 Lisp의 매크로나 ML의 타입 방식, APL의 벡터화를 접하면 같은 문제에 완전히 다른 해법을 떠올리게 되거든요.

분류의 한계

물론 이 일곱 분류는 깔끔한 수학 정리가 아니라 글쓴이의 관점이에요. 실제로는 JavaScript처럼 Scheme, Smalltalk, ALGOL의 요소가 섞인 혼혈이 훨씬 많고, Kotlin이나 Swift도 마찬가지예요. 어떤 사람은 Erlang 계열(액터 모델)을 여덟 번째 가문으로 넣자고 주장하고, 또 누군가는 Haskell을 ML에서 분리해 순수 함수형 가문으로 세우자고 해요. 분류 자체를 놓고 토론하는 게 더 재미있는 부분이에요.

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

주니어 시기에는 회사에서 쓰는 한두 언어를 깊게 파는 게 당연히 맞아요. 다만 어느 정도 경험이 쌓였다면, 일부러 자기 가문 밖의 언어를 한 번씩 건드려보는 게 장기적으로 큰 도움이 돼요. ALGOL 계열만 써왔다면 주말에 Clojure REPL을 열어보거나, Racket 튜토리얼을 돌려보거나, APL 문법을 맛만 봐도 사고 방식이 확장되거든요. 또 면접이나 설계 토론에서 "이 문제는 본질적으로 논리 프로그래밍에 가깝다" 같은 식으로 가문을 빗대 설명할 수 있으면, 문제를 보는 해상도가 올라가는 느낌을 받으실 거예요.