우리가 읽지 않을 코드를 왜 예쁘게 짜고 있을까요? : AI 네이티브 언어 NERD에 대한 단상

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

최근 우리 팀의 개발 풍경을 보면 격세지감을 느낍니다. 불과 몇 년 전만 해도 한 땀 한 땀 코드를 작성하던 엔지니어들이 이제는 Cursor나 Claude 같은 도구를 띄워놓고 프롬프트로 로직을 설계합니다. 통계에 따르면 이미 전 세계 코드의 40%가 LLM(거대언어모델)에 의해 작성되고 있다고 합니다. 저 역시 복잡한 리팩토링이나 보일러플레이트 코드는 AI에게 맡기는 비중이 늘었습니다.

그런데 며칠 전, 화면 가득 채워지는 TypeScript 코드를 멍하니 바라보다가 문득 기묘한 위화감이 들었습니다.

"이 코드를 내가 정말 한 줄 한 줄 읽을까?"

솔직히 말해, 아니었습니다. 저는 대략적인 구조를 훑어보고, 테스트 코드가 통과하는지 확인하고, 배포 파이프라인에 태울 뿐입니다. 기계가 작성하고 기계가 실행하는데, 왜 우리는 굳이 '인간이 읽기 편한' 형식을 고집하고 있는 걸까요? 이 질문에 대해 도발적인 해답을 제시한 프로젝트, 'NERD'를 소개하고 싶습니다.

프로그래밍 언어의 역사는 '인간의 인지 부하를 줄이는 방향'으로 발전해 왔습니다. 기계어에서 어셈블리로, C언어에서 파이썬과 같은 고수준 언어로 말이죠. 이 모든 진화의 전제는 '코드는 인간이 작성한다'는 것이었습니다. 하지만 이제 주 저작자가 AI로 넘어가고 있습니다. AI에게 public static void main 같은 구문은 거추장스러운 장식일 뿐입니다.

NERD라는 언어 프로젝트는 바로 이 지점을 파고듭니다. '인간이 아닌 LLM을 위한 언어'를 표방하죠. 이 프로젝트가 제시한 통찰은 기술적으로 꽤나 흥미롭습니다.

우리가 쓰는 일반적인 프로그래밍 기호들, 예를 들어 중괄호 {, } 나 등호 === 같은 것들은 LLM이 토큰화(Tokenization)할 때 여러 개의 토큰으로 잘게 쪼개집니다. 반면 "plus", "minus", "if" 같은 영어 단어는 하나의 토큰으로 처리되죠. LLM 입장에서는 기호가 난무하는 코드보다, 밀도 있는 영어 단어의 나열이 훨씬 처리하기 쉽고 비용도 저렴합니다.

실제로 NERD로 작성된 코드는 TypeScript 대비 토큰 사용량을 67%나 줄이면서도 동일한 로직을 수행한다고 합니다. fn add a b ret a plus b 같은 식이죠. 런타임 없이 LLVM으로 네이티브 컴파일되니 성능 문제도 없습니다.

물론 반론이 있을 수 있습니다. 저도 처음에는 "그럼 디버깅은 어떻게 하나?"라는 생각이 가장 먼저 들었습니다. 하지만 냉정하게 생각해 봅시다. 우리는 지금 JVM 바이트코드나 V8 엔진 내부의 어셈블리 코드를 직접 디버깅하지 않습니다. 문제가 생기면 자바나 자바스크립트라는 상위 추상화 계층에서 해결하죠.

만약 코딩의 추상화 계층이 한 단계 더 올라간다면 어떨까요? "라인 45번의 if문을 수정해줘"가 아니라, "로그인 실패 시 에러 메시지가 불친절하니 수정해줘"라고 자연어로 명령하고, AI가 내부적으로 NERD 코드를 고치는 세상 말입니다. 개발자는 이제 '코드 작성자(Author)'가 아니라 시스템의 '이해관계자(Stakeholder)'이자 '감독관'이 되는 셈입니다.

규제 준수나 감사(Audit) 문제도 마찬가지입니다. 사람이 읽을 수 있는 스파게티 코드보다, AI가 데이터 흐름과 제약 조건을 명확한 평이한 영어로 요약해 주는 것이 오히려 더 투명할 수도 있습니다. 새벽 2시에 비몽사몽 간에 작성한 코드보다 기계적으로 검증된 로직이 더 안전할지도 모른다는 생각, 씁쓸하지만 인정해야 할 부분입니다.

NERD 프로젝트의 개발자는 5년 후에는 대부분의 프로덕션 코드를 사람이 작성하지 않을 것이라고 내기를 걸었습니다. 그때가 되면 지금 우리가 쓰는 언어들은 마치 AI에게 라틴어로 시를 쓰라고 강요하는 것처럼 비효율적인 행위가 될 것이라고 말이죠.

이 프로젝트가 성공할지 실패할지는 알 수 없습니다. 어쩌면 우리는 여전히 텍스트 에디터의 커서를 직접 움직이는 감각을 포기하지 못할 수도 있습니다. 하지만 NERD가 던진 화두만큼은 기술 리더로서 깊이 곱씹어볼 만합니다.

우리는 지금 단순히 '코딩을 돕는 도구'를 쓰는 것이 아니라, '소프트웨어를 만드는 방식' 그 자체의 패러다임이 바뀌는 변곡점에 서 있습니다. 풀링포레스트 팀원들에게도 항상 강조하지만, 특정 언어나 프레임워크 사용법보다 중요한 것은 '문제 해결을 위한 설계 능력'입니다. 언어가 기계의 영역으로 넘어간다면, 인간 개발자에게 남는 최후의 보루는 결국 '무엇을 만들 것인가'에 대한 통찰력일 테니까요.

변화는 두렵지만, 그 이면의 원리를 이해하면 기회가 됩니다. 오늘도 쏟아지는 새로운 기술들 속에서, 우리가 지켜야 할 본질이 무엇인지 고민해 보는 하루가 되시길 바랍니다.