사람 말고 기계가 쓰라고 만든 언어, 'Vera'의 실험

프로그래밍 언어를 "기계용"으로 만든다는 발상

지금까지 모든 프로그래밍 언어는 사람이 잘 쓰고 잘 읽도록 설계되어 왔어요. Python이 사랑받는 이유는 문법이 영어와 비슷해서 읽기 편해서고, Rust가 욕먹으면서도 쓰이는 이유는 사람이 실수하기 쉬운 부분을 컴파일러가 잡아주기 때문이죠. 사람의 인지적 부담을 줄이는 게 언어 설계의 큰 축이었어요.

그런데 최근 LLM이 코드를 점점 더 많이 쓰게 되면서 이상한 질문이 떠올랐어요. "코드를 쓰는 게 사람이 아니라 LLM이라면, 언어를 그쪽에 최적화해야 하는 거 아닌가?" Vera는 이 질문에 진지하게 답하려는 실험적인 언어 프로젝트예요.

사람이 좋아하는 것 vs LLM이 좋아하는 것

사람과 LLM은 코드에서 좋아하는 게 좀 달라요. 사람은 짧고 간결한 걸 좋아해요. 같은 말을 반복하는 걸 싫어하죠(DRY 원칙). 추상화를 통해 디테일을 숨기고 싶어 하고, 함수 이름만 봐도 동작을 추측할 수 있길 원해요.

반면 LLM은 명시적이고 반복적인 게 더 잘 맞아요. 토큰 단위로 다음 토큰을 예측하는 모델이라, 컨텍스트가 명확할수록 정확도가 올라가거든요. 변수 타입이 코드에 그대로 드러나 있으면 추론이 쉽고, 매크로처럼 "보이지 않는 곳에서 무슨 일이 일어나는" 코드는 어려워해요. 그리고 사람은 한 화면에 들어가는 코드 양에 한계가 있지만, LLM은 컨텍스트 윈도우 안에서는 멀리 있는 정보도 잘 활용해요.

Vera의 설계 방향

Vera는 이런 차이에서 출발해서 몇 가지 원칙을 세워요. 우선 암시적인 동작을 최대한 줄여요. 연산자 오버로딩이나 매크로처럼 "이 기호가 사실은 다른 동작을 한다"는 식의 트릭을 배제하죠. 모든 동작이 코드 표면에 드러나야 LLM이 헛소리를 덜 한다는 가정이에요.

또 타입과 의도를 항상 명시하게 해요. 사람이라면 "문맥상 당연하잖아" 하고 넘어갈 부분도 Vera에서는 적어줘야 해요. 타이핑이 늘어나는 건 사람에겐 단점이지만, LLM에겐 비용이 거의 0에 가깝죠.

그리고 에러 메시지를 LLM이 읽기 좋게 설계한다는 아이디어도 있어요. 사람을 위한 에러 메시지는 "음, 이쯤에서 뭔가 잘못됐을 거야" 하는 친절한 톤인데, LLM에겐 정확한 위치, 정확한 타입 정보, 가능한 수정 후보가 구조화된 형태로 주어지는 게 더 좋다는 거예요.

비슷한 흐름들

Vera만 이런 고민을 하는 건 아니에요. Mojo(Modular가 만든)는 Python 문법을 따르되 컴파일러와 타입 시스템을 강화했고, Gleam은 정적 타입과 명시적 에러 처리로 LLM이 다루기 쉬운 면이 있어요. Rust도 의도치 않게 LLM 친화적이라는 평가를 받기도 해요. 컴파일러가 워낙 까다로워서 잘못된 코드를 빨리 잡아주거든요. 일종의 "피드백 루프"가 짧은 거죠.

또 다른 방향으로는 DSL(도메인 특화 언어)이 있어요. SQL이나 정규표현식처럼 좁은 영역에 특화된 언어들이요. LLM이 좁고 명확한 문법 안에서는 거의 실수를 안 해요. "기계용 언어"의 한 형태로 볼 수도 있죠.

솔직히 말하면, 회의적인 시각도 있어요

반론도 있어요. "LLM이 점점 똑똑해지는데 왜 언어를 LLM에 맞춰? 똑똑한 LLM은 사람이 쓰는 언어도 잘 쓰잖아"라는 거죠. 일리가 있어요. GPT-4가 나온 뒤로 LLM이 Haskell이나 Rust 같은 어려운 언어도 곧잘 다루기 시작했거든요.

반대편 의견은 "하지만 LLM이 잘 쓴다고 해도 비용과 정확도가 다르잖아. 같은 작업을 더 적은 토큰으로, 더 안정적으로 할 수 있다면 그게 결국 이득이다"예요. AI 인프라 비용이 문제가 되는 시대니까 이 논리도 무시 못 해요.

한국 개발자에게는

당장 Vera로 프로덕션 코드를 짜게 될 일은 없을 거예요. 실험적 프로젝트니까요. 하지만 이 흐름이 던지는 질문은 곱씹어볼 만해요. "코드를 누가 더 많이 쓰는 시대가 오고 있나? 그 환경에서 좋은 언어란 뭔가?" 코드 리뷰 문화도, 좋은 코드의 기준도 조금씩 바뀌고 있어요. 가독성보다 검증 가능성이 더 중요해질 수도 있고요.