자연어 코딩이라는 환상에 속아 GPU 수천만 원 태우고 깨달은 것

새벽 3시였습니다. AWS 비용 대시보드를 확인하다가 문득 헛웃음이 나왔습니다.

클라이언트의 요청은 간단했습니다. "우리 서비스 내에서 사용자가 말하는 대로 코드가 짜지고 실행되게 해주세요." 흔히 말하는 Text-to-SQL이나 Code Interpreter 같은 기능을 원했던 거죠. 우리는 최신 LLM을 파인튜닝하고, 프롬프트 엔지니어링에 수천 시간을 쏟아부었습니다. 하지만 결과는 처참했습니다. 모델은 확률적으로 그럴듯한 '거짓말 코드'를 뱉어냈고, 우리는 그걸 수습하느라 인스턴스 비용만 수천만 원을 태웠습니다.

머리를 식힐 겸 습관처럼 깃허브 트렌드를 뒤적이다가, 기이한 프로젝트 하나를 발견했습니다.

kip-dili/kip

터키어의 '격(Grammatical Cases)'을 프로그래밍 언어의 타입 시스템으로 녹여낸 실험적인 프로젝트였습니다.

처음에는 그저 흔한 이색 언어(Esoteric Language)인 줄 알았습니다. 하지만 리드미(README)를 읽어 내려가면서, 저는 묘한 패배감을 맛보았습니다. 우리가 수십억 개의 파라미터를 가진 모델로 그토록 구현하고 싶어 했던 '자연어 프로그래밍'의 본질이, 고작 수천 라인의 하스켈(Haskell) 코드와 유한 상태 오토마타(Foma) 라이브러리 속에 더 우아하게 담겨 있었기 때문입니다.

이 언어는 단순히 자연어 흉내를 내는 것이 아닙니다. 터키어라는 언어가 가진 엄격한 형태소 규칙을 컴파일러의 문법으로 승화시켰습니다.

예를 들어, Kip에서는 인자의 순서가 중요하지 않습니다.
(5'le 3'ün farkını) yaz. (5와 3의 차이를 써라)
(3'ün 5'le farkını) yaz. (3의 5와의 차이를 써라)

이 두 문장은 완벽하게 동일한 코드로 작동합니다. 왜냐하면 숫자 5와 3 뒤에 붙은 접미사(Suffix)가 해당 데이터의 역할(격)을 명확하게 정의하기 때문입니다. 목적격(-i), 도구격(-le) 같은 문법적 표지가 곧 타입이자 변수의 의미가 되는 구조입니다.

우리가 LLM에게 "자연스럽게 코딩해줘"라고 명령할 때, 우리는 AI가 문맥을 '대충 알아듣고' 처리해주길 기대합니다. 그건 엔지니어링이 아니라 도박입니다. 반면, 이 프로젝트는 자연어조차도 엄밀한 규칙(Rule-based) 위에서 작동할 때 비로소 실행 가능한 논리가 된다는 사실을 보여줍니다.

이 프로젝트를 보며 뼈저리게 느꼈습니다. 저는 그동안 '자연어 처리'라는 마케팅 용어에 취해, 프로그래밍 언어가 가져야 할 엄밀함(Rigidity)을 잊고 있었습니다.

개발자들은 흔히 코드를 '유연하게' 만들고 싶어 합니다. 하지만 시스템의 안정성은 유연함이 아니라 '제약(Constraint)'에서 나옵니다. Kip이 보여준 '모음 조화(Vowel Harmony)'나 '격 변화'는 언어 사용자에게는 제약이지만, 시스템 입장에서는 완벽한 파싱 가이드라인입니다.

수천만 원을 태워 만든 우리의 LLM 에이전트는 사용자가 "그거 계산해줘"라고 모호하게 말하면 엉뚱한 테이블을 조회하다 뻗어버립니다. 하지만 이 실험적 언어는 명사 뒤에 붙은 조사가 틀리면 컴파일조차 되지 않습니다. 역설적이게도, 가장 인간적인 언어(터키어)를 차용했음에도 가장 기계적인 엄격함을 유지하고 있는 셈입니다.

솔직히 말해, 당장 현업에서 이 언어를 쓸 일은 없을 겁니다. Haskell 스택을 깔고 foma 라이브러리를 설치해서 터키어로 코딩할 개발자가 어디 있겠습니까. 하지만 이 프로젝트가 던지는 메시지는 LLM 시대를 사는 우리에게 시사하는 바가 큽니다.

우리는 지금 너무 쉽게 코드를 짜려고 합니다. Copilot이 탭(Tab) 키 하나로 완성해 주는 코드가 편리하긴 하지만, 그 이면에 있는 논리의 구조(AST)를 이해하려는 노력은 점점 사라지고 있습니다.

데이터 전처리의 지옥을 경험해 본 엔지니어라면 알 겁니다. 결국 문제를 해결하는 건 화려한 모델의 추론 능력이 아니라, 지루할 정도로 꼼꼼하게 정의된 규칙과 데이터 파이프라인이라는 것을요.

오늘 밤은 주니어 개발자가 짠 프롬프트를 수정하는 대신, 이 낯선 언어의 소스 코드를 조금 더 뜯어볼 생각입니다. 확률에 기대지 않고, 명확한 규칙으로 대화하는 법을 다시 배우고 싶어졌거든요.

혹시 지금 "AI가 알아서 다 해주겠지"라는 생각으로 막연하게 아키텍처를 그리고 계신가요? 그렇다면 잠시 멈추고, 당신의 시스템이 '격'을 갖추고 있는지부터 확인해 보시기 바랍니다. 엔지니어링의 본질은 비용을 태워 마법을 부리는 게 아니라, 명확한 제약 속에서 예측 가능한 결과를 만들어내는 것이니까요.