AI가 코드를 작성할 때 사용하는 언어를 새로 설계하면 무엇이 달라질까요? Vera와 GlyphLang은 생성하기 쉬운 표현, 명시적인 규칙과 도구 지원을 실험하지만 방향은 서로 다릅니다. AI를 위한 언어라는 이름만으로 비용 절감이나 오류 없는 실행이 보장되지는 않습니다.
AI가 코드를 쓰기 좋은 언어란 무엇일까?
일반적인 프로그래밍 언어는 사람이 읽고 수정하기 편한 문법과 생태계를 중심으로 발전해 왔습니다. AI가 코드를 생성하는 환경에서는 모델이 올바른 구조를 만들기 쉬운지, 오류 메시지를 받아 수정할 수 있는지, 결과를 기계적으로 검사하기 쉬운지도 설계 기준이 됩니다.
여기서 중요한 것은 ‘사람이 읽을 수 없게 만들기’가 아닙니다. 언어마다 목표가 다르고, AI가 작성한 프로그램도 실제 요구사항을 충족하는지 확인할 사람이 필요합니다. 간결한 코드가 반드시 적은 토큰이나 빠른 실행을 뜻하지도 않습니다. 토큰 수는 모델의 분할 방식과 전체 문맥에, 실행 속도는 구현과 작업 조건에 영향을 받습니다.
Vera: 변수 이름 대신 타입과 위치를 사용
Vera 프로젝트 저장소는 대규모 언어 모델이 작성하도록 설계된 언어라고 소개합니다. 프로젝트에 따르면 프로그램은 WebAssembly로 컴파일되며, 일반적인 변수 이름 대신 타입과 위치를 나타내는 참조를 사용합니다. 함수에는 사전 조건, 사후 조건과 부작용 범위를 명시하도록 설계했습니다.
예를 들어 나눗셈 함수가 허용할 입력과 결과 조건을 적으면 검증 도구가 일부 조건을 정적으로 확인할 수 있습니다. 프로젝트는 정적으로 결론 내리지 못한 조건을 실행 시 검사로 넘기는 경우와, 일부 조건은 실행 검사로 만들지 못하는 한계도 설명합니다. 따라서 명세가 있다고 해서 개발자가 의도한 요구사항이 자동으로 옳아지거나 모든 버그가 사라지는 것은 아닙니다.
Vera가 모델에 도움이 되도록 오류의 원인과 수정 방향을 설명하는 진단을 제공한다는 점도 흥미롭습니다. 다만 프로젝트 자체의 벤치마크와 사례는 해당 버전과 과제의 결과입니다. 새로운 언어에 익숙하지 않은 팀의 학습·검토 비용까지 포함해 판단해야 합니다.
GlyphLang: 반복적인 백엔드 구성 줄이기
GlyphLang 프로젝트는 백엔드 개발에서 반복 코드와 설정을 줄이고 AI와 사람이 함께 더 빠르게 작업하도록 만드는 것을 목표로 소개합니다. 저장소는 HTTP 서버와 데이터베이스 접근을 포함하는 런타임과 단일 바이너리 배포 방식을 설명합니다.
즉 Vera의 계약·검증 중심 설계와 GlyphLang의 백엔드 구성 간소화는 강조점이 다릅니다. 이름이 비슷한 다른 Glyph 프로젝트도 있으므로 설치나 비교 전에 저장소와 문서를 확인해야 합니다. 두 언어의 제작자 주장을 동일한 실험 조건에서 독립적으로 비교한 것은 아닙니다.
| 질문 | Vera의 공개 설계 | GlyphLang의 공개 설계 |
|---|---|---|
| 주요 관심 | 모델이 작성할 코드와 계약 검증 | AI를 고려한 간결한 백엔드 구성 |
| 표현 방식 | 타입·위치 참조, 함수 계약과 효과 | 백엔드 작성에 맞춘 문법과 런타임 |
| 확인할 점 | 계약이 실제 요구를 표현하는지 | 필요한 운영 기능과 유지보수가 가능한지 |
| 공통 한계 | 프로젝트·버전·과제에 따라 결과가 달라짐 | 비용·안전·성능의 보편적 우위는 별도 검증 필요 |
컴파일 성공은 요구사항 충족과 다르다
컴파일러가 코드를 받아들였다는 사실은 문법과 도구가 확인하는 일부 규칙을 통과했다는 의미입니다. 예를 들어 할인율 계산 함수가 정상적으로 실행돼도 잘못된 정책을 정확히 구현했을 수 있습니다. 계약 조건이나 테스트 자체가 틀리거나 빠진 경우에도 같은 문제가 생깁니다.
실행 피드백 연구 RLEF는 모델이 코드 실행 결과를 활용해 여러 단계에 걸쳐 수정하도록 강화학습하는 방법을 연구했습니다. 논문의 대상은 경쟁 프로그래밍 과제이며, 단순히 AI에게 오류 메시지를 다시 보내는 모든 절차가 해당 학습 방법이 되는 것은 아닙니다. 실행 성공과 실제 서비스의 보안·정확성도 별도로 평가해야 합니다.
실무에 도입하기 전 비교할 기준
다음은 작은 시험을 설계하기 위한 편집 제안입니다.
- 동일한 과제: 기존 언어와 새 언어에 같은 입력·출력과 실패 조건을 제공합니다.
- 전체 비용: 생성 토큰뿐 아니라 문서 제공, 재시도, 테스트와 사람의 리뷰 시간도 기록합니다.
- 검증 가능성: 명세와 테스트가 실제 업무 규칙을 확인하는지 살핍니다.
- 운영 환경: 오류 추적, 배포, 라이브러리, 보안 업데이트와 팀의 유지보수 역량을 확인합니다.
- 실패와 복구: 잘못된 결과나 부작용이 생겼을 때 영향 범위와 되돌리는 방법을 정합니다.
새 언어의 짧은 데모는 가능성을 보여 주지만, 그 결과를 모든 프로젝트의 비용 절감률로 확대할 수는 없습니다. AI가 작성한 변경을 검토하는 일반적인 방법은 AI 코딩 결과 검토에서도 살펴볼 수 있습니다.
자주 묻는 질문
AI 전용 언어는 사람이 읽을 수 없나요?
반드시 그렇지 않습니다. 프로젝트마다 설계가 다르고 인간과 AI가 함께 사용하도록 목표를 세운 경우도 있습니다. 읽기 난도는 언어와 독자의 경험에 따라 다릅니다.
새 언어를 쓰면 토큰 비용이 80% 줄어드나요?
이 글에서 확인한 자료는 모든 작업에 적용되는 그런 절감률을 뒷받침하지 않습니다. 같은 모델과 작업에서 재시도와 검토 비용을 포함해 직접 비교해야 합니다.
계약 검증을 통과하면 안전한 코드인가요?
검증한 조건에 대해서만 근거를 얻습니다. 계약이 잘못됐거나 표현되지 않은 요구사항과 실행 환경의 문제는 따로 살펴야 합니다.
자료 확인일: 2026년 11월 7일.
다음 한 걸음
내 환경에서 막힌 부분은 실행 단계와 함께 질문해 주세요. 바꿔 만든 결과도 함께 나눌 수 있습니다.