GlyphLang – 'AI 최적화 프로그래밍 언어'를 둘러싼 HN 커뮤니티 논쟁

GlyphLang이 뭔가

• AI/LLM의 토큰 처리에 최적화된 독자적인 프로그래밍 언어를 표방함. 자체 렉서, 파서, 타입 체커, 바이트코드 컴파일러, 스택 기반 VM을 갖추고 있음
• 컴파일 파이프라인: .glyph → AST → 바이트코드(.glyphc) → VM
• 사람이 읽기 편한 .glyphx 레이어를 추가해서, 개발자는 .glyphx로 작업하고 LLM은 내부적으로 .glyph 코드를 생성하는 구조로 발전 중임

핵심 반론: 짧은 기호는 오히려 LLM에 독

• 커뮤니티의 가장 강력한 반박은 "짧은 기호가 LLM 어휘의 다른 토큰과 충돌을 일으킨다"는 점임. @ 하나가 파이썬 데코레이터, 셸 패턴, 이메일 패턴 등을 동시에 활성화시킴
• C 코드를 XML로 변환했더니 중괄호를 쓸 때보다 벡터 검색 결과가 훨씬 정확해졌다는 사례가 공유됨. 길고 서술적인 이름이 짧은 기호보다 LLM에 더 잘 먹힌다는 근거임
• Perl의 밀집된 구두점 문법이 트랜스포머 토큰화와 추론에 "반(反)최적화"되어 있다는 비유도 등장함

YAML vs JSON: LLM 생성에서의 차이

• Groundlight AI의 Sunil Kumar가 모델의 툴 콜 인터페이스를 JSON에서 YAML로 바꿨더니 "생성 엔트로피 안정성이 대폭 개선됐다"고 보고함
• JSON의 엄격한 구문({}, [], 필수 콤마, 이스케이프, 주석 불가)이 소형 모델의 탐색·추론 능력을 제약해서 "엔트로피 붕괴"를 유발함
• YAML은 들여쓰기가 곧 구조이고, 구분자가 적고, 주석을 쓸 수 있어서 엔트로피를 보존함. 주석에 맥락 정보를 담으면 LLM이 그걸 읽고 활용함

토큰 비용 절감이 의미 있을까

• "12~18개월 안에 토큰 비용이 급격히 낮아질 텐데 이게 필요한가"라는 현실적 의문이 제기됨
• 제작자 반론: 비용만의 문제가 아니라, 같은 컨텍스트 윈도우에 2배 더 많은 코드를 넣으면 추론 품질이 올라가고, 기호가 명확해서 def/fn/func/function 같은 언어 간 혼동에 의한 환각도 줄어든다고 주장함
• 하지만 "LLM이 이미 잘 아는 Python/JS/YAML을 쓰면 가르치는 데 토큰이 0인데, 새 언어는 매 프롬프트마다 매뉴얼·예제를 넣어야 한다"는 재반박이 핵심을 찌름

결론적 분위기

• 커뮤니티 다수 의견은 "LLM에 최적화된 문법은 마크다운, YAML, 타입스크립트처럼 이미 학습 데이터에 풍부한 언어"라는 쪽으로 수렴함. 토큰 수 절감보다 이해 충실도(comprehension fidelity)가 진짜 병목이라는 시각이 우세했음