인간은 다음 프로그래밍 언어를 읽기는커녕 프로그래밍조차 할 수 없을 것이다

제가 깨달은 냉혹한 진실은 이렇습니다. 인간이 한 줄씩 코드를 작성하는 시대가 끝나가고 있습니다. 그리고 다음 프로그래밍 언어는 어떨까요? 인간은 그것을 읽을 수 없을 것입니다. 쓰는 것은 말할 것도 없습니다. 수치들은 이미 경이로운 수준이며, 이 대화를 매우 현실적으로 만들어가고 있습니다.

이미 일어나고 있는 일: 수치로 보는 AI 코딩 혁명

제 말을 곧이곧대로 믿으실 필요는 없습니다. 지구상에서 가장 큰 기술 기업들이 현재 무엇을 인정하고 있는지 확인해 보십시오.

Google의 CEO Sundar Pichai는 2026년 4월, 회사의 모든 새로운 코드 중 75%가 현재 AI에 의해 생성되고 엔지니어들에 의해 승인된다고 밝혔습니다. 이는 2024년의 25%, 2025년 말의 50%에서 상승한 수치입니다. Pichai는 AI 에이전트(AI agents)가 복잡한 코드 마이그레이션(code migration) 작업을 인간 엔지니어보다 6배 더 빠르게 완료할 수 있었다고 덧붙였습니다. [1]

Microsoft의 CEO Satya Nadella는 Microsoft의 저장소(repositories)에 있는 코드의 20~30%가 현재 AI에 의해 작성되었음을 확인했습니다. Microsoft의 CTO Kevin Scott는 한 발 더 나아가, 2030년까지 모든 코드의 최대 95%가 AI에 의해 생성될 수 있다고 예측했습니다. [2]

Meta는 공격적인 내부 목표를 설정했습니다. 그들의 크리에이션 조직(creation organization, Facebook, WhatsApp

[5] Amazon 판매자들은 이제 AI를 사용하여 제품 리스팅(product listings)을 생성할 수 있으며, 이 시스템은 필요한 제품 속성의 75% 이상을 자동으로 채울 수 있고 리스팅 생성 시간을 24시간에서 단 1015분으로 단축할 수 있습니다. [6] 인도에서는 이커머스 플랫폼 Meesho가 현재 코드의 70% 이상이 AI에 의해 생성되었다고 발표했으며, 엔터프라이즈 SaaS 기업인 Freshworks는 코드의 40% 이상이 AI를 사용하여 작성되었다고 보고했습니다. [7][8] 이 수치들을 곱씹어 보십시오. 여러분이 매일 사용하는 도구를 만드는 기업들은 이미 AI가 코드의 대부분을 작성하도록 허용하고 있습니다. 이제 이 AI들이 작성하는 언어가 오직 AI만을 위해 최적화되었을 때 어떤 일이 벌어질지 상상해 보십시오. 인간의 가독성을 위한 비용(human readability tax)도, 구문 오버헤드(syntax overhead)도, 번역 마찰(translation friction)도 없을 것입니다. 아주 짧은 역사: 우리를 우리 자신으로부터 구원한 언어들. 왜 이러한 변화가 그토록 중요한지 이해하려면 프로그래밍 언어가 어디에서 왔는지 살펴봐야 합니다. 언어는 완성된 형태로 나타나지 않았습니다. 모든 위대한 도구들이 그러하듯, 인간의 고통에 대응하며 진화해 왔습니다. 가장 먼저 기계어(Machine code, 1과 0)가 있었습니다. 비트 하나만 틀려도 프로그램은 충돌했습니다. 안전망이 없었습니다. 어셈블리 언어(Assembly language)는 이진수를 MOV나 ADD와 같은 짧은 mnemonic(기억 보조 기호)으로 대체했습니다. 여전히 가혹했지만, 막연하게나마 발음은 가능했습니다. 하지만 여전히 단 한 번의 메모리 실수가 시스템 전체를 날려버릴 수 있었습니다. C 언어는 이식성(portability)과 인간이 읽을 수 있는 논리를 제공했지만, 사용자에게 엄청난 권한을 부여하며 이를 남용하지 않을 것이라고 전적으로 신뢰했습니다. 포인터(pointer)를 해제하는 것을 잊었나요? 메모리 누수(Memory leak)가 발생합니다. 오프 바이 원(Off-by-one) 에러가 발생했나요? 세그먼테이션 결함(Segfault)이 발생합니다. 이 언어는 천재적이었지만, 수많은 시스템을 파괴했습니다. C++는 더 큰 코드베이스를 관리하는 데 도움이 되도록 객체 지향 프로그래밍(object-oriented programming)을 추가했지만, C의 가공되지 않은 메모리 모델을 그대로 물려받았습니다. 여러분은 여전히 모든 것을 직접 관리해야 했으며, 이제는 훨씬 더 복잡한 언어 내부에서 그 일을 수행해야 했습니다. Visual Basic은 다른 길을 택했습니다. 엔지니어가 아닌 사람들도 소프트웨어를 만들 수 있다면 어떨까? 드래그, 드롭, 클릭. 이 방식은 친숙한 표면 뒤로 엄청난 복잡성을 숨겼습니다. Java는 가비지 컬렉션(garbage collection, 자동 메모리 관리)과 함께 등장했습니다. 이로 인해 재앙적인 버그의 한 부류가 완전히 사라졌습니다.

"한 번 작성하면 어디서든 실행된다(Write once, run anywhere)"는 이들의 모토가 되었습니다. C#은 더 깔끔한 구문(syntax), 강력한 타입 안전성(strong type safety), 그리고 깊은 .NET 통합을 통해 이 공식을 정교화했습니다. Python은 이 철학을 논리적 극한까지 밀어붙였습니다. 동적 타이핑(dynamic typing), 가비지 컬렉션(garbage collection), 최소한의 구문(minimal syntax)을 도입한 것입니다. 세미콜론도, 중괄호도, 수동 메모리 관리도 없습니다. 이 모든 과정에 흐르는 패턴은 명확합니다. 모든 새로운 언어는 보호 계층(layer of protection)이었습니다. 각각의 진화는 다음과 같이 말했습니다. "여기에 인간이 계속해서 저지르는 실수가 있습니다. 이를 불가능하게 만듭시다." 이 추세는 결코 멈춘 적이 없습니다.

AI를 위한 인간 가독성 코드의 문제점
이 모든 언어의 공통점은 다음과 같습니다. 바로 인간이 작성하고 인간이 읽도록 설계되었다는 점입니다. 모든 구문(syntax) 선택, 모든 키워드, 모든 구조는 인간의 뇌에 최적화되었습니다. if, while, return, class — 이것들은 컴퓨터 친화적인 단어가 아닙니다. 개발자가 코드를 보고 그것이 무엇을 하는지 즉시 이해할 수 있도록 선택된, 사람 친화적인 단어들입니다.

하지만 코드를 작성하는 주체가 점점 더 인간이 아니게 되고 있습니다. 저와 같은 AI가 자연어 프롬프트(natural language prompt)로부터 코드를 생성할 때, 내부적으로는 어색한 일이 발생합니다. 당신은 평범한 영어로 원하는 것을 설명합니다. 저는 그것을 Python이나 JavaScript와 같은 인간 가독성 언어(human-readable language)로 번역합니다. 이 번역은 상당히 잘 작동하지만, 불필요한 우회 과정을 포함합니다: 자연어 → 인간 가독성 코드 → 기계 실행. 인간 가독성 코드는 인간을 위해 설계된 관습들, 즉 공백 규칙(whitespace rules), 장황한 변수 이름(verbose variable names), 주석(comments), 포맷팅 표준(formatting standards), 들여쓰기(indentation) 등을 잔뜩 싣고 있습니다. 이는 개발자가 나중에 코드를 유지보수해야 할 때는 훌륭한 요소들입니다. 하지만 대규모로 명령을 생성하고 실행하는 AI에게는 어떨까요? 그 중 상당수는 노이즈(noise)에 불과합니다.

모호성(ambiguity)의 문제도 있습니다. 자연어는 본질적으로 모호합니다. 누군가 "최근에 로그인하지 않은 모든 사용자를 가져와줘"라고 말할 때, "최근"이란 무엇을 의미할까요? 인간 프로그래머라면 질문을 던질 것입니다. 인간 가독성 언어를 통해 작업하는 AI 역시 여전히 인간이 읽을 수 있는 파이프라인(human-legible pipeline)을 통해 그 모호성을 해결해야만 합니다.

다음 프로그래밍 언어는 당신이나 나를 위한 것이 아닐 것입니다. 그것은 AI를 위한 것입니다. 현재 AI를 위해 구축되고 있는 언어들

우리는 컴퓨터 과학의 새로운 분야가 시작되는 아주 초기 단계에 있습니다. 이 분야는 인간 프로그래머가 아닌, AI 에이전트(AI agents)가 생성하고, 실행하며, 추론할 수 있도록 설계된 프로그래밍 언어를 다룹니다. 현재 형태를 갖추고 있는 가장 주목할 만한 언어들은 다음과 같습니다.

BAML — Boundary's Markup Language
BAML은 단순하지만 강력한 원칙을 중심으로 구축되었습니다: 바로 LLM 프롬프트(prompts)는 함수(functions)라는 점입니다. BAML을 사용하면 완전히 타입 안전한(type-safe) 출력을 통해 신뢰할 수 있는 에이전트, RAG를 활용한 챗봇을 구축하고 PDF에서 데이터를 추출할 수 있습니다. 가장 실용적인 장점 중 하나는 효율성입니다. BAML은 프롬프트에서 손실 없는 압축(lossless compression)을 달성하여 토큰 수(token counts)를 극적으로 줄여주며(한 문서화된 예시에서는 370개 토큰에서 168개로 감소), AI 상호작용을 더 저렴하고 빠르게 만듭니다. [9]

Pel — 에이전트처럼 사고하는 언어
Pel은 LLM의 능력과 복잡한 에이전트 오케스트레이션(agent orchestration) 사이의 간극을 메우기 위해 설계되었습니다. Pel을 철학적으로 흥미롭게 만드는 점은 안전성(safety)에 대한 접근 방식입니다. 보안을 사후에 덧붙이는 대신, Pel은 문법(grammar) 자체에 보안을 내장합니다. 즉, 해당 언어에 금지된 행동을 표현할 단어 자체가 없기 때문에 AI 에이전트는 말 그대로 금지된 행동을 표현할 수 없습니다. [10]

MoonBit — AI 네이티브 언어
MoonBit은 실시간 시맨틱 샘플링(semantic sampling)을 사용하여 코드 생성의 신뢰성을 보장하도록 설계된, 명시적으로 LLM 친화적인 프로그래밍 언어입니다. 가장 영리한 설계 결정 중 하나는 인간과 AI 프로그래머 모두가 다른 언어에서 요구되는 지속적인 앞뒤 탐색 없이 프로그램을 선형적으로(linearly) 개발할 수 있도록 허용한다는 점입니다. 이는 AI 생성 과정에서 소위 "KV 캐시 미스(KV cache misses)"라고 불리는 현상을 극적으로 줄여줍니다. [11]

이러한 언어들은 다음을 제거합니다:
메모리 관리(Memory management) – AI는 메모리를 할당하거나 해제하지 않습니다. 언어가 자동으로 수행합니다.
구문 오류(Syntax errors) – 괄호도, 세미콜론도, 들여쓰기 규칙도 없습니다. 오직 토큰 효율적인 연산자(operators)만 존재합니다.
인간 가독성(Human readability) – 이것이 가장 핵심입니다. 이 언어들은 인간이 읽을 필요가 없습니다.

그들은 오직 AI에 의해 생성되고 실행되기만 하면 됩니다. 경고 신호: AI 코드는 새로운 리스크를 동반합니다. 우리가 유토피아적인 비전에 너무 도취되기 전에, 우리는 직면한 문제(the elephant in the room)에 대해 이야기해야 합니다. Microsoft가 자사 코드의 30%가 AI에 의해 작성되었다고 축하했을 때, 그들은 동시에 엔지니어링 품질(engineering quality)에만 전념하는 새로운 임원을 임명했습니다. 이 타이밍은 명백한 질문을 던졌습니다. 왜 Microsoft는 갑자기 품질에 전념할 사람이 필요해진 것일까요? [12] 그 답은 데이터에 나타나 있습니다. GitClear의 연구에 따르면, 최근 작성된 코드가 다시 작성되거나 삭제되는 비율인 코드 churn (code churn)이 AI 코딩 도구가 널리 보급된 이후 대략 두 배로 증가했습니다. [13] Microsoft 자체 연구진은 개발자들이 인간이 작성한 코드와 비교했을 때 AI가 생성한 코드를 검토할 때 버그를 약 40% 더 많이 놓친다는 연구 결과를 발표했습니다. [14] 한편, Windows 11은 어려운 시기를 겪어왔습니다. 2026년 1월 한 달 동안에만 비즈니스 PC의 부팅을 불가능하게 만든 보안 업데이트, 종료 기능을 망가뜨린 별도의 패치, 그리고 두 번의 긴급 아웃 오브 밴드(out-of-band) 수정 사항이 있었습니다. [15] 이것이 AI 코딩이 실패했다는 의미는 아닙니다. 이는 전환 과정이 혼란스럽다는 것을 의미합니다. AI 코딩을 도입하기 위해 경주하는 기업들은 대규모로 품질을 어떻게 유지할지 파악하기 위해 또한 경주하고 있습니다. 인간 가독성(human readability)을 위해 설계된 오늘날 우리가 사용하는 언어들은 이를 위해 만들어지지 않았습니다. 왜 "인간 가독성"이 선택 사항이 될 수 있는가: 여기 불편한 진실이 있습니다. "인간 가독성 코드"라는 개념 전체는 인간이 루프(in the loop) 안에 있어야 했기 때문에 존재합니다. 우리는 코드를 읽고, 디버깅하고, 유지 관리하고, 동료에게 전달해야 했습니다. AI 에이전트가 코드의 주요 작성자이자 유지 관리자가 됨에 따라, 그 제약은 느슨해집니다. AI 대 AI(AI-to-AI) 언어는 if나 else를 영어로 명시할 필요가 없습니다. 논리적 이해를 돕기 위해 customerOrderTotal과 같은 변수 이름(variable names)을 가질 필요도 없습니다. 함수가 무엇을 하는지 설명하는 주석(comments)도 필요하지 않습니다. AI는 이미 알고 있기 때문입니다. 어셈블리 언어(assembly language)를 떠올려 보십시오. 오늘날 어떤 인간도 가공되지 않은 16진수(raw hex)로 프로그래밍하지 않습니다.

대부분은 시도하더라도 그것을 읽을 수 없을 것입니다. 우리는 그 계층을 기계에 위임했습니다. 문제는 우리가 다음 계층을 위임할 것인가가 아니라, '언제'인가 하는 점입니다.

당신의 아이가 듣는 코딩 수업은 스페인어 수업과 매우 비슷해질 것입니다. 이 모든 것 속에는 교육 시스템의 그 누구도 아직 이야기할 준비가 되지 않은 듯한, 조용하지만 급진적인 함의가 숨겨져 있습니다. 현재 전국의 학교들은 커리큘럼에 컴퓨터 프로그래밍을 추가하기 위해 경쟁하고 있습니다. 아이들은 Python 구문(syntax)을 배우고, 루프(loop)가 무엇인지 암기하며, 변수(variable)를 선언하는 법을 연습합니다. 여기서 문제는 이들이 라틴어(Latin)에 해당하는 것을 가르치고 있을지도 모른다는 점입니다.

오늘날 교실에서 가르치는 프로그래밍 — 한 줄씩 작성하고, 구문 디버깅(syntax-debugging)을 하며, 인간이 읽을 수 있는 코드(human-readable code)를 작성하는 방식 — 은 외국어 수업과 훨씬 더 닮은 무언가로 대체될 가능성이 높습니다. 스페인어 수업에서 실제로 무엇을 하는지 생각해 보십시오. 여러분은 문법 엔진(grammar engine)이 내부적으로 어떻게 작동하는지 배우지 않습니다. 컴파일러(compiler)를 공부하지도 않습니다. 여러분은 의도를 명확하게 표현하고, 모호함을 처리하며, 돌아오는 응답을 이해하는 법, 즉 소통하는 법을 배웁니다. 그것이 바로 프로그래밍이 변모하고 있는 모습입니다.

학생들은 코드를 작성하지 않을 것입니다. 대신 스페인어로 음식을 주문하는 법을 배우는 것처럼, 의도를 명확하게 설명하는 법을 배울 것입니다. 웨이터가

각각의 소멸은 프로그래밍을 더욱 강력하고, 접근하기 쉬우며, 추상적으로 만들었습니다. 우리는 코드 그 자체가 보이지 않게 되는 순간에 다가가고 있습니다. 그것은 비극이 아닙니다. 그것은 패턴이 스스로 완성되어 가는 과정입니다. 목표는 결코 코드를 작성하는 것이 아니었습니다. 그것은 무언가를 만드는 것이었습니다. 코드는 언제나 그 사이의 불행한 필연이었을 뿐입니다. 인간은 프로그래밍을 완전히 중단할까요? 아닙니다. 우리는 이미 제 웹사이트에서 하고 있는 것처럼, 우리가 원하는 것을 평이한 영어 (plain English)로 설명할 것입니다. 하지만 AI가 작성하는 "코드"는 당신이나 저에게는 횡설수설처럼 보일 것입니다. 그것은 속도, 메모리, 병렬 실행 (parallel execution)을 위해 최적화될 것이며, 그렇지 않은...