요즘 제 코드는 대부분 Claude Code가 씁니다. 저는 무엇을 만들지 말하고, 결과를 리뷰하고, 테스트가 진짜 통과했는지 확인합니다. 그렇게 몇 달을 지내다 보니 이상한 질문이 하나 생겼습니다.
프로그래밍 언어는 왜 사람이 읽기 편하게 생겼을까?
답은 단순합니다. 사람이 쓰고 사람이 읽으니까요. 중괄호, 들여쓰기, if/for/while, 친절한 컴파일 에러 메시지까지 전부 키보드 앞에 앉은 사람을 위한 장치입니다. 그리고 사람이 쓴 그 글을 기계가 알아듣게 바꾸는 과정이 컴파일이죠.
그런데 코드를 쓰는 쪽이 LLM으로 바뀌면 이야기가 달라집니다. 사람이 읽기 편한 문법, 그리고 그걸 기계어로 번역하는 컴파일이라는 단계가 과연 계속 필요할까요? 이 의문을 붙잡고 2026년 7월 28일에 첫 커밋을 했고, 지금까지 3개월 동안 만든 게 linkly라는 LLM 네이티브 프로그래밍 플랫폼입니다.
먼저 결론부터 말하면, 3개월 동안 만들면서 얻은 제 답은 이렇습니다.
사람이 읽는 소스 코드는 중심에서 내려옵니다. 중심에는 "이 코드가 무슨 의미인가"를 담은 시맨틱 IR이 올라갑니다. 문법은 그 IR을 적는 표기법 중 하나일 뿐입니다.
컴파일은 없어지지 않습니다. 오히려 LLM에게 더 필요합니다. 다만 역할이 바뀝니다. 사람의 글을 기계어로 옮기는 번역기에서, LLM이 쓴 것이 정말 무언가를 하는지 따지는 검사관으로요.
사람이 읽는 일도 사라지지 않습니다. 쓰는 사람에서 리뷰하는 사람으로 자리만 옮깁니다.
처음 질문에 "필요 없다"고 답하려고 시작했는데, 만들다 보니 절반은 "아니, 필요하다"로 바뀌었습니다. 그 과정을 순서대로 적어 보겠습니다.
출발점은 비용이었습니다. 사람에게는 공짜인 가독성이 LLM에게는 공짜가 아닙니다. 한 연구에 따르면 공백·들여쓰기·줄바꿈이 코드 토큰의 약 24.5%를 차지하는데, 의미에는 거의 기여하지 않습니다. 중괄호 언어는 포맷팅을 걷어내 토큰을 크게 줄일 수 있지만, Python처럼 들여쓰기가 곧 문법인 언어는 걷어낼 수가 없습니다(The Hidden Cost of Readability, arXiv:2508.13666).
그래서 linkly의 표면 언어 LNPL은 이렇게 생겼습니다.
service LoginService
policy
retry 3
timeout 3s
security
jwt
performance
response < 50ms
cache 5m
workflow Login
validate user
authenticate user
cache user
create session어떻게 검증하고 어떻게 캐시할지는 어디에도 없습니다. 무엇을 할지만 선언합니다. 그리고 몇 가지를 일부러 뺐습니다.
if / for / while / switch가 없습니다. 제어 어휘는 when / repeat / parallel / until / pipeline뿐입니다.
들여쓰기는 의미가 없습니다. 블록은 키워드로 나눕니다. 그래서 중괄호 짝 오류나 들여쓰기 오류는 문법적으로 존재할 수가 없습니다.
동사 어휘가 닫혀 있습니다. 정해진 목록 밖의 단어는 아무 동작도 만들지 않습니다.
기존 컴파일러의 중심은 AST, 즉 "소스 코드가 어떻게 생겼나"를 담은 나무입니다. linkly는 이걸 버리고 BusinessRule, Validation, NetworkCall, Transaction 같은 의미 단위를 1급 노드로 둡니다.
개발자 → Intent(무엇을) → LLM → Semantic IR → Native Optimizer → Machine Code이 IR도 LLM에 맞췄습니다. 중첩된 나무가 아니라 id로 서로를 가리키는 평평한 노드 테이블입니다. LLM이 정해진 스키마대로만 출력하게 강제하는 구조화 출력 기능은 중첩 깊이에 제한이 있는데(OpenAI Structured Outputs는 5단계), 평평한 테이블이면 그 제한에 걸리지 않습니다. AI 에이전트들도 소스를 고치는 게 아니라 IR 노드를 제안합니다.
처음엔 "LLM이 IR을 바로 쓰면 컴파일이 왜 필요하지?"라고 생각했습니다. 그런데 실제로 LLM에게 LNPL을 쓰게 해 보니 문제가 바로 보였습니다.
사람은 오타를 냅니다. 오타는 컴파일러가 바로 잡아 줍니다. LLM은 오타를 내지 않습니다. 대신 그럴듯한 단어를 지어냅니다. create를 써야 할 자리에 persist를 쓰는 식이죠. 문법적으로는 멀쩡하게 파싱되고, 런타임에는 아무 일도 일어나지 않습니다. 이 위험은 이전 글에서 오답을 일부러 주입해 확인했습니다.
그래서 linkly의 컴파일러가 가장 공들이는 일은 번역이 아니라 말해 주기입니다.
목록 밖 동사에는 unknown-verb 진단이 붙고, persist → create 같은 "혹시 이거였나요?" 제안이 같이 나옵니다.
선언했지만 실제로 집행되지 않는 것도 진단으로 알려 줍니다. 예를 들어 performance response는 측정만 하고 막지는 않는데, 컴파일러가 그렇다고 말합니다.
번역도 그대로 합니다. IR을 바로 실행하는 인터프리터(모드 A)와, IR → MLIR → LLVM → 네이티브 바이너리로 내리는 컴파일러(모드 B)가 있고, lnpl diff가 두 방식의 실행 결과가 같은지 비교합니다. 결국 컴파일은 남았습니다. 다만 "사람의 글을 기계어로"가 아니라 "LLM이 쓴 의미를 검사하고 기계어로"가 됐습니다.
가장 인상 깊었던 건, 사람용 가독성을 버리겠다고 시작한 언어가 결국 사람의 눈을 다시 신경 써야 했다는 점입니다.
들여쓰기는 의미가 없다고 정했습니다. 그런데 이슈 #211에서, 재고 확인 가드 아래에 들여 써 놓은 단계가 재고가 부족해도 실행되는 사례가 나왔습니다. 들여쓰기만 보면 가드 안에 있는 것처럼 보이는데, 실제로는 아니었던 거죠. 결국 "블록 구조와 모순되는 들여쓰기는 컴파일 에러로 거부한다"는 규칙(RFC-0019, RFC-0058)을 넣었습니다. README에 이 RFC를 요약한 문장이 이렇습니다. 스코프에 대한 조용한 거짓말이 관례 부재보다 나쁘다. 들여쓰기는 기계에게는 의미가 없어도, 그걸 읽는 사람과 LLM에게는 의미가 있었습니다.
테스트도 그랬습니다. 초록불인 테스트가 아무것도 확인하지 않는 경우가 있었습니다. 규칙 이름을 그대로 단 테스트가 있었는데, 준비 데이터를 아무것도 실패하지 않게 깔아 둬서 런타임이 무슨 짓을 해도 통과했습니다. 그래서 지금은 일부러 코드를 망가뜨려 테스트가 정말 실패하는지 보는 뮤테이션 검사 77종을 같이 돌립니다. 리뷰 게이트는 다섯 번 뚫렸고, 알려진 실패 사례별로 막는 대신 IR 구조 규칙에서 검사를 다시 쓰고 나서야 닫혔습니다. 사례별로 만든 게이트는 사례별로 뚫린다는 걸 배웠습니다.
커밋 626개, RFC 65편(46편 Accepted)
테스트 5,390여 개 전부 통과 + 뮤테이션 검사 77종
.lnpl이 인터프리터에서 실행되고, MLIR을 거쳐 네이티브 바이너리로도 컴파일됩니다
그리고 지금 열려 있는 이슈 중 하나가 이 글의 질문에 대한 마지막 답 같습니다. 이슈 #254의 제목은 "에디터 지원이 없다"이고, 본문 첫 줄은 이렇습니다.
LNPL은 LLM이 쓰지만 사람이 리뷰·승인한다.
LLM 네이티브 언어를 만들고 있는데, 다음 할 일이 사람을 위한 에디터 지원(LSP, 문법 하이라이트)입니다. 사람이 읽기 좋은 언어가 필요하냐는 질문에, 지금은 이렇게 답하겠습니다. 쓰기 좋을 필요는 없어졌지만, 리뷰하기 좋을 필요는 남았습니다.
솔직하게 말씀드리면, linkly는 아직 프로토타입 단계입니다. 예제 서비스를 돌려 보고 언어 설계의 가설을 검증하는 데는 쓸 수 있지만, 실제 회사 서비스처럼 엔터프라이즈급 개발을 맡길 수 있는 상태는 아닙니다. 사람이 리뷰할 에디터 지원도 없고, 열려 있는 이슈 중에는 DB·인프라·CI/CD 연동성 감사에서 나온 숙제들이 쌓여 있습니다. 틀린 가정도 계속 나오고 있고요.
그래도 방향은 분명합니다. 이슈를 하나씩 닫아 가면서, "LLM이 쓰고 사람이 리뷰하는 언어"가 실제 서비스를 감당할 수 있는 수준까지 계속 개선해 나갈 생각입니다.
정리하면 이렇습니다.
LLM이 쓰는 언어는 사람의 타이핑 편의가 아니라 LLM의 토큰·구조 제약에 맞춰 설계할 수 있습니다.
그래도 컴파일러는 필요합니다. LLM의 실수는 오타가 아니라 그럴듯한 거짓말이라, 그걸 잡아 주는 검사관이 있어야 합니다.
사람은 작성자에서 리뷰어로 자리를 옮길 뿐, 사라지지 않습니다.
👉 저장소: github.com/choiyounggi/linkly (MIT)
설계가 궁금하면 RFC 목록부터 읽어 보세요. 중심 문서는 RFC-0001 Semantic IR입니다.
직접 써 보고 싶다면 README의 "실행해보기" 절을 따라 examples/login.lnpl을 바로 실행해 볼 수 있습니다.
같은 고민을 하는 분이라면 반론이든 제안이든 이슈로 남겨 주세요. Star도 큰 힘이 됩니다.
관련 글:
이 글은 제 벨로그에 먼저 올린 글입니다. 원문: LLM이 코드를 다 쓰는 시대에, 사람이 읽기 좋은 언어와 컴파일이 아직 필요할까