하나의 언어를 찾는 여정: 프로그래밍의 “성배”는 존재하지 않는다

I’m happy to translate the article for you, but I need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you requested.

Introduction

지난 10년 동안 IT 산업의 변화하는 흐름을 헤쳐 왔습니다. 제 여정은 클라우드‑네이티브의 탑에서 시작된 것이 아니라 Desktop Support의 최전선에서 시작되었습니다. 그때 제 주요 무기는 Visual Basic과 VBA였으며, 이를 사용해 하루를 잡아먹던 반복적인 수작업을 자동화했습니다.

나의 기술 진화

이 여정 내내—대학 시절 Java와 C++를 사용하던 시절부터 현재 Go 작업에 이르기까지—나는 어디서든 사용할 수 있는 단 하나의 진정한 언어를 찾고 있습니다.

현대 건축가의 바벨탑

현대 시스템 아키텍트에게 오늘날의 기술 환경은 종종 디지털 바벨탑처럼 느껴집니다. 하나의 제품을 만들기 위해서는 끊임없는 컨텍스트 전환이 필요합니다:

• Python – 데이터 워크로드
• JavaScript – 프론트엔드
• C++ / Rust – 성능이 중요한 시스템

이러한 전환은 인지적 오버헤드를 발생시키고 조용히 생산성을 저하시킵니다.

왜 업계는 하나의 보편적인 프로그래밍 언어에 결코 합의하지 못했을까?

보편 언어 탐구

4.1. 이론적 가능성

• Church–Turing 논제: 모든 튜링‑완전 언어는 다른 튜링‑완전 언어가 할 수 있는 모든 것을 계산할 수 있다.
• 수학적 보편성은 이미 존재한다.

4.2. 하드웨어를 최하위 “언어”로

• 모든 계산은 논리 게이트로 구성될 수 있다.
• 단일 NAND 게이트만으로 모든 불리언 논리를 표현할 수 있다.
• 실제: 게이트 수준에서 프로그래밍하는 것은 매우 느리고 오류가 잦아 인간에게는 쓸모가 없다.

4.3. UNCOL 실험

• 문제 (1950년대): M개의 프로그래밍 언어와 N개의 프로세서 아키텍처가 있으면 M × N개의 컴파일러가 필요하다.

• 해결책: UNCOL (Universal Computer Oriented Language) – 모든 언어를 UNCOL로 컴파일한 뒤, UNCOL을 각 기계에 맞게 컴파일한다.

• 결과: 기관의 지원에도 불구하고 UNCOL은 다음과 같은 이유로 실패했다:

  • 수백 개의 새로운 수학 기호
  • 형식적인 기계‑독립적 의미론
  • 분야가 충분히 성숙하기 전에 컴파일러 부트스트래핑

• 유산: UNCOL의 실패는 이후 성공에 영감을 주었다:

  • 중간 표현(IR)
  • 이식 가능한 가상 머신(예: JVM, .NET CLR)
  • Niklaus Wirth의 보편 컴파일 전략 연구

API vs. ABI: 실제 장벽

일반적인 오해는 소프트웨어가 환경과 독립적이다는 것이다. 실제로 컴파일된 바이너리는 운영 체제에 얽매인 존재이다.

• 커널 의존성: Windows, Linux, macOS는 각각 시스템 콜을 다르게 구현한다.
• 결과: 동일한 소스 코드라도 근본적으로 다른 바이너리가 생성된다.
• 표준화 시도는 종종 최저 공통 분모에 수렴하여 플랫폼‑특화 기능을 희생한다.

툴박스 역설

우리가 커널/ABI 문제를 해결한다 하더라도 툴박스 역설에 직면하게 됩니다:

• 프로그래밍 언어 ≠ 단순 문법.
• 언어는 특정 사고 모델에 대한 최적화이며, 이를 패러다임이라고 합니다.
• 패러다임은 개발자가 특정 종류의 문제를 사고하고 다루는 방식을 돕는 사고 체계입니다.

6.1. 패러다임 예시

• 마찰은 개발자가 자연스러운 흐름에 반하는 작업을 강요받을 때 발생합니다.
• 예시: C로 복잡한 데이터 시각화 시스템을 구축하는 것은 가능하지만, 고수준 UI 추상화가 부족해 며칠짜리 프로젝트가 수년으로 늘어날 수 있습니다.

인지 부하 및 시스템 신뢰성

• Cognitive load: 패러다임을 전환하면 뇌가 동시에 여러 정신 모델을 유지해야 합니다.
• System reliability: 언어를 설계되지 않은 역할에 강제 적용하면 불일치가 발생해 performance가 저하되고 버그가 증가하며 전달 속도가 느려집니다.

결론

단일 보편 프로그래밍 언어에 대한 꿈은 수학적으로는 가능하지만 실제로는 불가능합니다. 그 이유는 다음과 같습니다:

1. 하드웨어 다양성 (다양한 ABI)
2. 인간 인지 (다른 패러다임 및 정신 모델)
3. 역사적 시도 (예: UNCOL) 가 보편적인 컴파일의 복잡성을 강조함

코딩의 미래는 새로운 언어를 발명하는 것보다 구문 마찰을 줄이는 데 더 초점이 맞춰집니다—즉, 구문보다 의도에 집중할 수 있게 해주는 도구, 런타임, 추상화를 만드는 것이 핵심입니다.

새로운 언어의 탄생이 아니라 구문의 종말이 다음 소프트웨어 개발 시대를 정의할 것입니다.

보편성, WebAssembly, 그리고 “하나의 진정한 언어”의 종말

보편 언어에 대한 꿈

가장 유망한 현대의 보편성 시도는 **WebAssembly (Wasm)**와 그 Component Model이다. 이 아키텍처는 소프트웨어 모듈을 언어에 구애받지 않는 레고 블록처럼 취급한다.

역사적으로 언어들은 깨지기 쉬운 glue code 없이는 상호 작용할 수 없었다. Wasm은 **WebAssembly Interface Types (WIT)**를 통해 이러한 상황을 바꾸어, 구성 요소가 원래 언어와 관계없이 문자열이나 구조화된 레코드와 같은 고수준 데이터를 교환할 수 있게 한다.

“여러 면에서 이것은 원래 UNCOL 꿈을 실현한다.”

다중 언어 플랫폼의 실제

• Spin 3.0 – Rust 개발자는 고성능 모듈을 작성하고 이를 JavaScript 애플리케이션 안에 손쉽게 배포할 수 있다.
• 다른 신흥 런타임들도 동일한 component‑first 접근 방식을 채택하고 있어, 언어 간 통합이 예외가 아니라 일상이 되고 있다.

성장통

현재 Wasm 런타임(예: Wasmtime)은 아직 눈에 띄는 성능 격차를 보인다:

• 일부 벤치마크에서는 파일 I/O가 네이티브 실행보다 최대 10배 느리다.
• 이 지연은 언어 자체의 실패가 아니라 아키텍처의 결과이다:
  • 보안 샌드박싱이 시스템 콜 오버헤드와 빈번한 컨텍스트 스위칭을 초래한다.
  • Tokio와 같은 async 런타임이 이 비용을 더욱 증폭시킨다.
  • 제한된 네이티브 멀티‑스레딩 지원이 고성능 서버‑사이드 워크로드의 장애 요인으로 남아 있다.

기술적 보편성을 저해하는 인간적 요인

1. 상업적 경쟁 – Sun Microsystems와 Microsoft 간의 Java 소송은 “한 번 작성하고 어디서든 실행한다(Write Once, Run Anywhere)”라는 약속을 크게 훼손했다.
2. Blub Paradox (Paul Graham) – 프로그래머는 이미 알고 있는 언어의 관점으로 더 강력한 언어를 평가하며, 표현력을 불필요한 복잡성으로 오해한다.
3. 분열 위험 – Matt Butcher가 경고하듯, 생태계는 통합이 시작될 때 호환되지 않는 확장으로 인해 무너질 수 있다.

번역가에서 AI‑구동 설계자로

“나는 내 경력을 번역가로 살아왔다. 비즈니스 의도를 PowerShell로, 사용자 워크플로를 JavaScript로, 인프라를 Go로 번역했다.”

이제 번역가는 인간 설계자가 아니라 AI가 된다.

• 이 변화는 종종 Software 3.0이라 불리며, Andrej Karpathy와 연관된 용어이다.
• 이 패러다임에서 자연어가 주요 인터페이스가 된다. 설계자는 영어로 의도를 설명하고, 대형 언어 모델이 상황에 맞는 방언—Python, SQL, Rust 혹은 다른 언어—을 생성한다.

새로운 가치 제안

• 설계자는 쓸모 없어진 것이 아니라 고양된 존재다.
• 그들의 가치는 구문을 외우는 것에서 시스템 설계, 제약 조건, 의도를 마스터하는 것으로 이동한다.
• 우리는 벽돌공에서 지휘자로 변모하며, 단일 자연어 인터페이스를 통해 특화된 도구들을 조율한다.

더 큰 그림

IT 분야에서 10년을 일하며 나는 바벨탑이 결함이 아니라 현실이라는 것을 배웠다. 복잡한 문제는 다양한 도구를 필요로 한다.

변화된 것은 언어의 다양성이 아니라 강력한 다리의 등장이다:

• WebAssembly Component Model – 런타임을 연결한다.
• AI – 인간 사고와 기계 실행을 연결한다.

산업은 플러그‑앤‑플레이 미래로 나아가고 있다.

하나의 진정한 언어를 찾는 탐색은 끝났다—우리가 찾았기 때문이 아니라, 더 이상 필요하지 않게 되었기 때문이다.

그 다리가 바로 성배다.