1978년에 쓰인 짧은 메모 한 장
에츠허르 다익스트라(Edsger W. Dijkstra)라는 이름은 최단 경로 알고리즘 때문에 한 번쯤 들어보셨을 거예요. 구조적 프로그래밍을 주장했고, 'GOTO문은 해롭다'는 유명한 글로 프로그래밍 스타일을 바꿔놓은 컴퓨터 과학의 거장이죠. 그는 평생 'EWD'라는 번호를 붙인 손글씨 메모를 1,300편 넘게 남겼어요. 그중 667번이 바로 「On the foolishness of “natural language programming”」, 우리말로 하면 '자연어 프로그래밍의 어리석음에 대하여'예요.
거의 50년 전 글이 지금 다시 읽히는 이유는 간단해요. 요즘 우리는 진짜로 자연어로 프로그래밍을 하고 있거든요. “가장 핫한 프로그래밍 언어는 영어”라는 말까지 나왔고, 코드는 거의 안 보고 AI에게 말로만 시켜서 만드는 '바이브 코딩'도 유행이죠. 다익스트라가 어리석다고 했던 바로 그 미래에 우리가 살고 있는 셈이에요.
다익스트라의 핵심 주장
첫 번째 주장은 형식 언어는 짐이 아니라 특권이라는 거예요. 형식 언어(formal language)가 뭐냐면, 프로그래밍 언어나 수학 기호처럼 문법과 의미가 엄격하게 정해진 언어예요. 다익스트라는 형식적인 텍스트가 따를 규칙이 몇 개 안 되기 때문에 오히려 온갖 헛소리를 걸러내는 놀라운 도구가 된다고 봤어요. 그래서 형식 기호를 써야 하는 걸 부담으로 여기지 말고, 그 덕분에 예전엔 천재만 하던 일을 학생도 할 수 있게 됐으니 특권으로 여기자고 했죠.
근거는 역사에서 가져와요. 그리스 수학은 말과 그림에 머물러 있다가 정체됐고, 중세 이슬람 세계의 대수학도 기호를 잠깐 써보다가 다시 문장으로 풀어 쓰는 방식으로 돌아가면서 힘을 잃었대요. 근대 과학은 비에트, 데카르트, 라이프니츠, 그리고 나중의 불(Boole) 같은 사람들이 정교한 기호 체계를 만든 뒤에야 꽃필 수 있었고요. “어떤 수에 3을 더하고 2를 곱했더니 20이 됐다”는 문장보다 2(x + 3) = 20이 훨씬 다루기 쉽잖아요. 기호로 쓰면 이항이나 전개 같은 규칙 몇 개만 기계적으로 적용해도 답이 나오니까요.
두 번째 주장은 꽤 날카로워요. 우리가 모국어를 '자연스럽게' 쓴다는 건 결국 말이 안 되는 소리를 해도 티가 잘 안 나는 편리함일 뿐이라고 꼬집거든요. 일상 대화에선 이게 장점이지만, 기계에게 정확한 일을 시켜야 할 때는 치명적인 약점이 돼요.
세 번째는 인터페이스 비용이에요. 기계가 우리 말을 알아듣게 만들면 기계가 일을 더 떠안으니 사람은 편해질 것 같잖아요? 그런데 다익스트라는 인터페이스를 바꾸는 게 정해진 양의 일을 나눠 갖는 문제가 아니라고 했어요. 경계를 넘나들며 소통하는 비용이 새로 붙기 때문에 양쪽 모두 일이 늘어날 수 있다는 거죠. 그리고 이렇게 글을 맺어요. 모국어로 프로그래밍하는 기계는 만들기도 지독하게 어렵겠지만, 쓰기도 그만큼 지독하게 어려울 거라고요.
그래서 다익스트라는 틀렸을까?
절반은 틀렸어요. LLM 덕분에 '만들기 어렵다'는 부분은 사실상 해결됐거든요. 하지만 '쓰기 어렵다'는 부분은 지금도 그대로예요. “사용자 목록을 이름순으로 정렬해줘”라는 요청을 볼까요? 오름차순인지 내림차순인지, 한글과 영문이 섞이면 뭐가 먼저인지, 대소문자를 구분하는지, 이름이 비어 있는 사용자는 어디로 보낼지 아무것도 정해져 있지 않아요. 반면 users.sort((a, b) => a.name.localeCompare(b.name, 'ko')) 한 줄은 이 질문들 대부분에 답을 정해버려요. 코드 자체가 명세인 거예요.
LLM은 이런 빈칸을 그럴듯한 추측으로 채워줘요. 문제는 그 결과물이 그럴듯해 보인다는 거예요. 다익스트라가 말한 '말이 안 되는데 티가 안 나는' 문제가 '틀렸는데 그럴듯해 보이는 코드'로 모습만 바꿔서 돌아온 셈이죠. 의도를 맞추려고 AI와 프롬프트를 몇 번씩 주고받는 그 과정이 바로 그가 말한 인터페이스 너머의 소통 비용이에요.
업계는 다시 형식을 찾고 있어요
역사는 반복돼요. 1959년에 나온 COBOL은 ADD A TO B GIVING C처럼 영어 문장 같은 문법으로 관리자도 읽을 수 있게 하겠다는 목표가 있었지만, 결국 프로그래머의 언어가 됐어요. SQL도 원래 이름이 'Structured English Query Language'를 줄인 SEQUEL이었고요. 영어처럼 보이게 만들어도 정확하려면 결국 형식이 필요했던 거죠.
지금 AI 코딩 도구도 같은 길을 가고 있어요. 요구사항을 구조화된 명세 문서로 먼저 쓰게 하는 '스펙 주도 개발' 도구들이 나왔고, AI 에이전트는 타입과 테스트가 탄탄한 코드베이스에서 훨씬 일을 잘한다는 경험도 쌓이고 있어요. 수학에서는 AI가 만든 증명을 Lean 같은 형식 증명 언어로 검증하는 흐름도 활발해요. 자연어가 입구를 맡고, 형식 언어가 검증을 맡는 구조로 자리 잡아가는 거예요.
한국 개발자에게 주는 시사점
한국어는 주어를 자주 빼고 문맥에 많이 기대는 언어라서, “이거 저번처럼 고쳐줘” 같은 프롬프트는 영어보다 더 모호해지기 쉬워요. AI에게 일을 시킬 때 입력과 출력 예시를 같이 주고, 완료 조건을 분명히 적고, 테스트를 먼저 쓰게 하는 습관만 들여도 결과가 꽤 달라져요.
주니어분들께는 “이제 코드를 몰라도 된다”는 말을 너무 믿지 말라고 말씀드리고 싶어요. AI가 쓴 그럴듯한 코드에서 오류를 잡아내는 힘은 결국 형식 언어를 정확하게 읽는 능력에서 나오거든요. 다익스트라 식으로 말하면, 코드를 읽고 쓸 줄 아는 건 지금도 특권이에요.
마무리
한 줄 정리: 자연어는 의도를 전하는 데 강하고, 형식 언어는 그 의도를 검증하는 데 강해요. AI 시대에도 둘 중 하나만으로는 부족해요.
AI에게 말로 코딩을 시키다가 '그냥 내가 코드로 쓰는 게 더 빠르겠다' 싶었던 적 있으신가요? 그리고 프롬프트가 점점 길고 정교해진다면, 그건 결국 새로운 프로그래밍 언어를 쓰고 있는 걸까요?
🔗 출처: Hacker News