사람이 소스코드를 덜 읽는 것과, 소스코드가 사라지는 것은 다른 이야기입니다
2026년 8월 4일, 개발자 제임스 도우마가 이런 글을 올렸습니다.
"나는 다시는 소스코드를 보지 않을지도 모른다. 거의 반세기 전에 컴파일러가 제대로 처리할 거라고 믿었기 때문에 어셈블리 코드를 보는 걸 멈췄다. 이건 그때와 비슷한 느낌이다."
일론 머스크가 답했습니다.
"정확히 맞습니다. 소스코드는 어셈블리어처럼 되기 직전입니다. 다음 단계는 소스코드를 완전히 없애고 AI로 효율적인 바이너리를 직접 만드는 것입니다."
조회수 430만을 넘겼습니다. 머스크는 올해 초 사내에서도 비슷한 말을 했다고 전해집니다.
비유가 매력적입니다. 그리고 앞쪽 절반은 실제로 맞습니다. 그런데 뒤쪽 절반에는 중요한 것이 빠져 있습니다.
먼저, 이 비유가 무슨 뜻인지
용어부터 풀겠습니다.
컴퓨터가 실제로 실행하는 것은 바이너리, 즉 0과 1의 나열입니다. 사람이 이걸 직접 쓰는 것은 사실상 불가능합니다. 그래서 그 바로 위에 어셈블리어를 두었습니다. 기계어를 사람이 겨우 읽을 수 있게 이름 붙인 것입니다.
그 위에 파이썬이나 자바 같은 고급 언어가 있고, 사람이 쓴 고급 언어를 기계가 실행할 바이너리로 번역해주는 것이 컴파일러입니다.
도우마의 관찰은 이 사다리를 두고 한 말입니다. 우리는 어셈블리를 읽지 않게 됐고, 이제 소스코드도 그렇게 되고 있다는 것입니다. 여기까지는 실제로 벌어지고 있는 일입니다. AI가 만든 코드를 한 줄씩 읽지 않고 결과만 확인하는 개발자가 이미 많습니다.
머스크가 덧붙인 것은 한 걸음 더 나갑니다. 소스코드라는 층 자체를 없애고 AI가 바이너리를 직접 만들자는 것입니다.
컴파일러와 AI는 같은 종류의 물건이 아닙니다
여기가 비유가 깨지는 지점입니다.
우리가 어셈블리를 안 읽게 된 이유는 컴파일러를 믿을 수 있었기 때문입니다. 그리고 믿을 수 있었던 이유가 중요합니다.
컴파일러는 정해진 규칙에 따라 항상 같은 답을 내놓습니다. 문법이 문서로 규정돼 있고, 번역 과정에서 프로그램의 의미가 바뀌지 않는다는 것을 수학적으로 따질 수도 있습니다. 그래서 사람이 결과를 안 봐도 됐습니다.
언어모델은 다릅니다. 그럴듯한 다음 토큰을 고르는 방식이라 맞다는 보장이 원리적으로 없습니다. 같은 요청에 다른 답을 내놓을 수도 있습니다.
한 비평의 표현이 정확합니다. 이건 번역기를 더 좋은 번역기로 바꾸는 일이 아니라, 이미 확실하게 풀린 문제에 확률적 오차를 더하는 일입니다. 컴파일러 출력보다 AI 출력이 더 믿을 만한 경우는 지금으로선 없습니다.
바이너리는 특히 실수에 약합니다. 비트 하나만 틀려도 프로그램 전체가 무너지는데, 그 오류가 눈에 안 보이는 형태로 조용히 남을 수도 있습니다.
소스코드는 기계에 주는 명령서만이 아닙니다
더 근본적인 문제가 있습니다. 소스코드가 하는 일 중 상당수는 실행과 무관합니다.
몇 가지만 짚겠습니다. 깃 같은 버전 관리 도구는 글자 줄이 어떻게 바뀌었는지를 추적합니다. 바이너리끼리 비교하면 사람이 읽을 수 있는 차이가 나오지 않습니다. 모든 버전이 그냥 검은 상자가 됩니다.
코드 검토는 더 직접적입니다. 검토할 것이 없어집니다. 동료에게 "AI가 잘했을 거라고 믿어달라"고 말하는 것 외에 방법이 없습니다.
보안 감사도 마찬가지입니다. 읽을 수 없는 것은 감사할 수 없습니다. 금융이나 공공처럼 코드를 제출하고 검증받아야 하는 영역에서는 이게 규제 문제로 직결됩니다.
그리고 이식성이 있습니다. 바이너리는 특정 칩과 운영체제 전용입니다. 고급 언어가 만들어진 가장 큰 이유 중 하나가 한 번 써서 여러 기계에서 돌리기 위해서였습니다. 바이너리를 직접 만들면 기계 종류마다 다시 만들어야 합니다.
실제로 시켜보면 어떻게 되나
이론만의 이야기가 아닙니다. 언어모델을 컴파일러처럼 써보는 연구가 이미 나와 있습니다.
결론은 조심스럽습니다. 언어모델이 컴파일러 흉내를 내기는 하지만 실제로 돌아가는 결과물을 만드는 비율이 낮습니다. 프롬프트를 다듬고 모델을 키우고 추론을 붙이면 품질이 올라가기는 하지만, 컴파일러를 대체할 수준과는 거리가 있습니다.
이유가 구조적입니다. 언어모델은 토큰을 하나씩 이어붙이는 방식인데, 16진수 숫자와 레지스터 이름의 나열은 이 방식에 특히 안 맞습니다. 의미 있는 덩어리로 묶이지 않기 때문입니다.
그런데 방향 자체가 틀린 것은 아닙니다
여기서 균형을 잡을 필요가 있습니다. 머스크의 결론에는 동의하기 어렵지만, 그가 가리킨 흐름은 실재합니다.
사람이 코드를 덜 읽는 것은 이미 벌어지고 있습니다. 생성된 코드를 한 줄씩 검토하지 않고 동작만 확인하는 방식이 늘고 있고, 사람이 실제로 손대는 것은 점점 프롬프트와 명세 쪽으로 올라가고 있습니다. 도우마의 관찰은 그 지점에서 정확합니다.
그리고 원 게시글에서 짚은 대목이 흥미롭습니다. 웹어셈블리 같은 차세대 중간 형식이 이미 있는데, AI에 맞는 새 어셈블리라는 것도 비슷한 방향 아니겠느냐는 지적입니다. 저는 이 관찰이 문제의 핵심을 정확히 건드린다고 봅니다.
웹어셈블리는 그냥 새로운 기계어가 아닙니다. 형식 문법이 문서로 규정돼 있고, 타입 검사로 실행 전에 안전성을 확인할 수 있으며, 그 검사 체계가 옳다는 것이 기계적으로 증명된 중간 형식입니다. 메모리 밖을 건드리는 동작을 미리 막고, 실행 스택과 데이터 스택을 분리해 공격을 어렵게 만듭니다.
즉 웹어셈블리가 의미 있는 이유는 사람이 안 읽어도 되게 만들어서가 아니라 기계가 대신 검사할 수 있게 만들어서입니다. AI가 만든 결과물을 사람이 안 읽는 세상이 오려면 필요한 것은 소스코드의 소멸이 아니라, 검사 가능한 중간 형식과 그것을 검사하는 도구입니다.
두 문장을 구분해야 합니다
비슷해 보이는 두 문장이 사실은 갈립니다.
"사람이 소스코드를 덜 읽게 된다." 이미 벌어지고 있고 앞으로 더 그럴 것입니다. 어셈블리 비유가 맞는 부분입니다.
"소스코드가 사라진다." 이건 다른 이야기입니다. 소스코드는 사람이 읽으려고만 존재하는 것이 아니라 버전을 추적하고, 검토하고, 고치고, 감사하고, 다른 기계로 옮기기 위해 존재합니다. 읽는 빈도가 줄어도 그 역할은 남습니다.
그리고 이 시리즈에서 반복해 마주친 질문이 여기서도 나옵니다. 컴파일러가 특별했던 이유는 빨라서가 아니라 확실해서였습니다. 말하자면 컴파일러는 번역기이면서 동시에 검증기였습니다. AI로 대체하자는 제안의 진짜 문제는 번역이 부정확해질 수 있다는 것이 아니라, 파이프라인에서 유일하게 보장이 있던 단계를 없앤다는 것입니다.
에이전트가 일을 끝내게 하려면 채점기가 필요하다는 이야기와 정확히 같은 구조입니다. 무엇이 맞는지 기계가 판정할 수 없으면, 사람이 손을 뗄 수도 없습니다. 그래서 소스코드가 사라지기 전에 먼저 나와야 하는 것은 더 좋은 생성기가 아니라 더 좋은 검사기입니다.
본 글은 공개된 소셜미디어 게시물과 관련 연구·기술 문서를 근거로 한 기술 해설이며, 특정 종목에 대한 판단을 담고 있지 않습니다. 인용한 발언은 보도와 원문 게시물 기준이고, 언어모델의 컴파일 능력에 대한 평가는 현재 공개된 연구 시점 기준입니다. 기술은 빠르게 바뀌므로 여기서의 한계 지적이 영구적이라는 뜻은 아닙니다.
주요 출처: 제임스 도우마와 일론 머스크의 2026년 8월 4일 게시물 및 관련 보도, 언어모델을 컴파일러로 쓰는 시도에 대한 연구(arXiv 2511.04132), 소스코드 제거 주장에 대한 기술 비평, 웹어셈블리 명세와 타입 체계 검증 연구.