LLM이 충분히 똑똑한 상황에서, 《LLM을 위한 프로그래밍 언어》라는 것은 야비한 사업이다

개인 블로그로부터 전재했습니다.

「LLM에 최적화된 언어」 「LLM 친화적인 (LLM-friendly) 구문」 —— 최근 들어 그런 홍보 문구를 내세운 프로젝트가 눈에 띄기 시작했다. 프로그래밍 언어 설계자가 LLM이 쓰기 쉽다는 점을 차별화 요소로 내세운다. 얼핏 보면 시대에 부합하는 소구점으로 보인다. 하지만 잘 생각해 보면, 이것은 상당히 야비한 (こすい) 사업이다.

LLM은 이미 기존 언어로 충분히 작성할 수 있다

먼저 사실부터 확인해 두고 싶다. 지금의 LLM은 Python, TypeScript, Rust, Go, Java —— 주요 언어 대부분을 적절한 수준으로 작성할 수 있다. 타입 추론 (Type inference) 이 얽힌 복잡한 TypeScript도, 라이프타임 (Lifetime) 이 얽힌 Rust도 어느 정도 통한다. 완벽하지는 않지만, 전문 프로그래머의 일상 업무 중 상당 부분은 이미 대신할 수 있는 범위 안에 들어와 있다.

즉, 「LLM이 쓰기 어려우니까, 쓰기 쉬운 언어를 만든다」라는 수요는 이미 희박하다. LLM은 이미 인간이 일상적으로 사용하는 언어로 충분히 작성할 수 있다. 게다가 LLM의 능력은 기반 모델 (Foundation Model) 의 진화와 함께 꾸준히 계속 성장하고 있다. 지금 이 순간에 「LLM용」을 내세운 언어를 설계하기 시작한다 하더라도, 그것이 세상에 나올 때쯤에는 LLM이 그 설계가 상정했던 것 이상으로 똑똑해져 있을 가능성이 높다.

언어는 애초에 인간을 위한 것이다

더 근본적인 이야기를 하자면, 프로그래밍 언어는 인간을 위해 설계되어 왔다. 하드웨어에 가장 가까운 것은 기계어이며, 그 위에 쌓아 올린 추상화 (Abstraction) 계층은 모두 「인간이 쓰기 쉽고, 읽기 쉽고, 생각하기 쉽게 만들기」 위한 것이다. 타입 시스템 (Type system) 도, 구문 설탕 (Syntactic sugar) 도, 모듈성 (Modularity) 구조도 인간의 인지 편의에 맞춰 발명되어 왔다.

「LLM을 위해 설계한다」라는 발상은 이 방향을 반대로 뒤집는다. 본래 보조 대상이었던 LLM을 설계의 중심에 둔다. 이는 지금 LLM이 가진 과도기적인 약점을 언어 설계 안에 영구적인 제약으로 써넣는 것을 의미한다. LLM이 향후에 더 똑똑해진다면, 그 제약은 「단지 표현력이 낮은 언어」로서만 남게 된다.

야비함의 정체

그렇다면 왜 그럼에도 불구하고 「LLM용 언어」라는 프로덕트가 등장하는가. 이유는 몇 가지 상상할 수 있다.

첫 번째는 LLM 하이프 (LLM hype) 에 편승하는 것이다. 「LLM」이라는 키워드를 제목에 붙이는 것만으로 기술 커뮤니티에서의 초기 속도가 달라진다. 마케팅 전술로서 이것은 확실히 유효하다.

두 번째는 차별화 없는 차별화다. 프로그래밍 언어의 설계 공간에서 진정으로 새로운 가치를 내는 것은 어렵다. 기존 언어와 비교해 무엇이 다른지, 왜 기존의 선택지가 아닌 이것을 사용해야 하는지 —— 그 질문에 정면으로 답하는 대신 「LLM이 쓰기 쉽다」라는 라벨을 붙인다. 이것은 답이 되지 않지만, 답이 되는 것처럼 보이게 할 수 있다.

그리고 가장 야비한 것은, 표현력을 제한한 것에 대한 변명으로서의 LLM 언급이다. 「LLM이 쓰기 쉽다」라는 것은 종종 「구문이 한정적이고, 의미론 (Semantics) 이 좁다」라는 것과 동의어가 된다. 제약이 강하기 때문에 쓰기 쉬울 뿐인 언어를 「LLM 친화적 (LLM-friendly)」이라고 부름으로써, 설계상의 한계를 기능으로서 판매한다. 이것이 가장 야비하다.

게다가 프로그래밍 언어를 도입하는 비용은 작지 않다. 에코시스템 (Ecosystem), 툴링 (Tooling), 인재, 커뮤니티 —— 모든 것이 신규 언어 채택에는 무겁게 작용한다. 그것을 지불하면서까지 얻을 수 있는 LLM 고유의 편익이 과연 얼마나 되는가 하는 질문은 대개 정면으로 논의되지 않는다.

반론에 대한 대비

예상되는 반론은 몇 가지 있다.

「형식 검증 (Formal verification) 중심의 언어는 LLM의 추론을 돕지 않는가」 —— 확실히 그렇다. 하지만 그것은 「정확성을 위한 언어」이지, 「LLM을 위한 언어」가 아니다. LLM은 우연히 그 혜택을 받지만, 설계의 주안점은 인간의 정확성 추구에 있다.

「명시적인 타입은 LLM이 코드를 작성하는 데 도움이 된다」 —— 맞는 말이다. 하지만 그것은 인간에게도 도움이 된다. LLM만이 혜택을 받는 기능은 사실 거의 존재하지 않는다. LLM을 돕는 설계는 대체로 인간도 돕는 설계이다. 따라서 「LLM용」이라는 수식어는 거의 항상 과다 청구가 된다.

「토큰화 (Tokenization) 에 유리한 구문이 LLM의 효율이 더 좋다」 —— 효과는 한정적이며, 설계의 주안점으로 삼아야 할 정도의 차이는 아니다. 컨텍스트 길이 (Context length) 도 모델의 추론 효율도 매달 개선되고 있는 영역이다.

요약

LLM이 충분히 똑똑한 세계에서는 「LLM용 언어」는 구조적으로 가치를 잃어간다. LLM이 기존 언어를 능숙하게 다룰수록 전용 언어의 존재 의의는 희박해진다. 반대로 인간의 사고를 확장하는 언어, LLM이라도 어려운 영역을 개척하는 언어의 가치는 LLM의 똑똑함이 진보할수록 상대적으로 높아질 것이다.

그래서 지금 「LLM 친화적 (LLM-friendly)」을 내세운 언어가 나올 때마다, 조금 냉소적인 시선으로 바라보게 된다. 그것은 시대의 흐름을 타고 있는 것처럼 보이지만, 시대의 가장 짧은 파도 위에만 올라탈 수 있는 설계다. '야비하다'는 것은 바로 그런 의미이다.

왜 이런 글을 썼느냐 하면, 다음과 같은 회의감이 있었기 때문이며,

순진한 사람들을 현혹하고 있는 것처럼 느껴졌기에, 경종을 울린다는 의미에서 썼다.

편집 후기

Claude Opus 4.7에게

이런 글을 쓰고 싶다.
↓
LLM이 충분히 똑똑한 상황에서, 『LLM을 위한 프로그래밍 언어』라는 것은 야비한 사업이다

라는 프롬프트로, 단 한 번에 출력된 것을 편집한 것이다.