Zero 4.4k 스타, 에이전트가 읽는 언어의 조건

AI 요약

• 무슨 일: Vercel Labs의 zerolang이 에이전트 우선 시스템 언어 실험으로 공개됐습니다.
  • GitHub API 기준 저장소는 2026년 5월 15일 생성, 5월 23일 기준 약 4.4k stars입니다.
• 핵심 변화: 컴파일러가 사람용 오류문만 내는 대신 --json 진단, graph, size, typed repair plan을 제공합니다.
• 의미: AI 코딩 경쟁이 IDE 플러그인에서 언어, 표준 라이브러리, compiler contract 설계로 내려가고 있습니다.
• 주의점: Zero는 pre-1 실험이며, 공식 문서도 production과 sensitive data 사용을 금지에 가깝게 경고합니다.

Vercel Labs가 공개한 zerolang은 겉으로 보면 또 하나의 작은 시스템 프로그래밍 언어입니다. 파일 확장자는 .0이고, 구현 언어는 C이며, Apache-2.0 라이선스의 공개 저장소로 배포됩니다. 하지만 이 뉴스의 핵심은 "새 언어가 하나 더 나왔다"가 아닙니다. Zero는 프로그래밍 언어의 1차 독자를 사람에서 AI 에이전트로 바꿨을 때 컴파일러와 표준 라이브러리, 오류 메시지, 수리 루프가 어떻게 달라져야 하는지를 묻는 실험입니다.

공식 사이트의 문장은 노골적입니다. Zero는 에이전트가 첫날부터 1차 사용자라는 가정에서 언어를 다시 생각합니다. 목표는 작업 중 즉석에서 배울 수 있고, 검사와 수리가 결정적이며, 표준 라이브러리를 우선하고, 대부분의 작업에 하나의 명확한 길이 있는 언어입니다. 기존 언어의 풍부함을 줄이고, 대신 에이전트가 덜 추측하게 만드는 방향입니다.

저장소 지표도 초기 관심을 보여줍니다. GitHub API 기준 vercel-labs/zerolang은 2026년 5월 15일 만들어졌고, 2026년 5월 23일 21:59 UTC 무렵 4,401 stars, 274 forks, 103 open issues를 기록했습니다. 최신 main 커밋도 같은 날 들어왔습니다. 아직 언어 생태계라고 부르기에는 너무 이르지만, "agent-first programming language"라는 문제 제기가 개발자 커뮤니티에서 빠르게 주목받고 있다는 신호로 보기에는 충분합니다.

언어보다 중요한 것은 compiler contract입니다

Zero의 가장 흥미로운 부분은 문법 자체가 아닙니다. 공식 README가 강조하는 것은 zero check --json, zero parse --json, zero graph --json, zero size --json, zero fix --plan --json 같은 명령입니다. 이 명령들은 컴파일러 내부 상태를 사람이 읽는 산문이 아니라 구조화된 계약으로 밖에 내보냅니다.

예를 들어 zero check --json은 diagnostic code, source span, expected/actual, repair metadata, compile-time sandbox facts, target readiness를 포함할 수 있습니다. zero graph --json은 module, import, public symbol, capability, effect, ownership fact, helper use, interface fingerprint를 노출합니다. zero fix --plan --json은 파일을 직접 고치기 전에 typed repair plan을 설명합니다. zero size --json은 어떤 helper가 왜 binary에 남았는지, profile policy와 artifact budget을 보여주는 방향입니다.

이것은 기존 개발 도구의 "AI 통합"과 다릅니다. 보통 코딩 에이전트는 TypeScript, Rust, Python 같은 기존 언어를 다룹니다. 컴파일러 오류나 테스트 로그를 자연어처럼 읽고, 정규식이나 LSP 응답, 에디터 플러그인, 웹 검색, 프롬프트 규칙을 엮어 다음 수정을 추론합니다. Zero의 접근은 반대입니다. 컴파일러가 처음부터 에이전트가 바로 먹을 수 있는 구조화된 사실과 수리 후보를 내보내도록 만들겠다는 것입니다.

이 표가 Zero의 뉴스 가치를 가장 잘 설명합니다. Zero는 "에이전트가 코드를 더 잘 쓰게 하자"는 목표를 모델 쪽이 아니라 언어 도구 쪽에서 풀어보려 합니다. 에이전트가 매번 오류 메시지를 읽고 다음 조치를 추측하게 하지 말고, 컴파일러가 수리 가능한 오류의 구조를 정식 출력으로 주자는 주장입니다.

zero skills get이 보여주는 묘한 역전

Zero README에서 눈에 띄는 명령은 zero skills get zero-language, zero skills get zero-diagnostics, zero skills get zero-stdlib입니다. 컴파일러 binary가 자신과 버전이 맞는 언어 규칙, 진단 규칙, 표준 라이브러리 규칙을 skill text로 내보낸다는 뜻입니다.

이것은 최근 agent skill 흐름과 연결됩니다. Claude Code, Codex, Cursor 같은 에이전트 환경에서는 저장소의 AGENTS.md, .agents/skills, 프로젝트별 규칙 파일이 점점 중요해지고 있습니다. 하지만 대부분의 규칙은 repo 바깥의 사람이 작성하고 갱신합니다. 언어와 도구 버전이 바뀌면 문서와 프롬프트가 뒤처질 수 있습니다. Zero는 이 간극을 줄이기 위해 컴파일러가 직접 현재 버전의 규칙을 에이전트에게 내보내는 방향을 택했습니다.

여기에는 중요한 함의가 있습니다. 앞으로 에이전트가 쓰는 개발 도구는 단순 CLI가 아니라 "자기 설명 가능한 CLI"가 되어야 할 수 있습니다. --help 출력은 사람에게 충분할지 몰라도, 에이전트에게는 안정적인 필드, 오류 코드, 예시, 수리 범위, 위험도, target readiness가 더 중요합니다. Zero의 skills get은 그 문서화 책임을 도구 자체로 끌어당기는 시도입니다.

물론 이 아이디어가 Zero만의 전유물은 아닙니다. TypeScript language service, Rust compiler diagnostics, LSP code action, ESLint fixer, IDE quick fix도 이미 구조화된 정보를 제공합니다. 차이는 우선순위입니다. 기존 생태계는 사람이 IDE에서 이해하고 승인하는 흐름을 중심에 두고, 그 옆에 에이전트를 붙입니다. Zero는 처음부터 에이전트가 읽고, 계획하고, 수정하고, 다시 검사하는 루프를 제품 표면으로 둡니다.

명시적 capability는 보안 언어가 아니라 에이전트 언어의 문법입니다

공식 사이트는 Zero가 "regularity over cleverness"를 선호한다고 설명합니다. hidden allocator, implicit async, global magic 같은 사람에게 편한 축약이 에이전트에게는 추론 비용이 될 수 있다는 문제의식입니다. 파일, 네트워크, 외부 세계 접근, 실패 가능성, resource use는 독자와 도구 모두에게 보여야 합니다.

이 대목은 AI 에이전트 보안 논의와 닿아 있습니다. 최근 코딩 에이전트는 로컬 파일을 읽고, 셸 명령을 실행하고, 브라우저를 열고, MCP 서버를 호출합니다. 에이전트의 위험은 모델이 틀리는 데서 끝나지 않습니다. 어떤 코드가 어떤 capability를 요구하는지, 어떤 API가 외부 세계를 건드리는지, 실패가 타입과 제어 흐름에서 보이는지가 중요해집니다.

Zero가 당장 보안 언어라는 뜻은 아닙니다. 오히려 공식 문서는 보안 취약점이 예상된다고 말합니다. production system, sensitive data, trusted infrastructure에 쓰지 말고 isolated, disposable environment에서 실험하라는 경고도 반복합니다. 그러므로 Zero를 "안전한 AI 코딩 언어"로 포장하면 사실을 과장하는 셈입니다.

정확한 해석은 이렇습니다. Zero는 아직 안전하지 않은 실험이지만, 에이전트 시대의 안전한 개발 환경이 어떤 정보 구조를 필요로 하는지 일부를 보여줍니다. capability가 signature에 보이고, 오류가 stable code로 식별되고, 수리 계획이 typed metadata로 나오면, 인간 승인과 정책 엔진이 개입할 위치가 더 명확해집니다.

호환성을 버릴 수 있다는 pre-1의 특권

Zero의 AGENTS.md는 흥미로운 개발 철학을 적고 있습니다. pre-1 실험이므로 breaking change는 허용됩니다. 더 명확한 agent-facing design이 있다면 compatibility shim, migration layer, 오래된 path를 기본값으로 보존하지 말라고 합니다. 예제, 문서, 테스트, command contract가 하나의 현재 시스템을 설명해야 한다는 지시도 있습니다.

기존 언어 생태계에서는 이런 태도가 거의 불가능합니다. TypeScript, Python, JavaScript, Go, Rust는 이미 수많은 프로젝트와 패키지, 빌드 시스템, 교육 자료, 기업 배포에 묶여 있습니다. 에이전트를 위해 문법이나 diagnostics contract를 크게 바꾸고 싶어도 호환성 비용이 큽니다.

Zero는 반대로 아무것도 없는 상태에서 출발합니다. 그래서 "에이전트가 더 쉽게 고치는 언어"라는 목표를 위해 문법과 표준 라이브러리, CLI contract를 갈아엎을 수 있습니다. 장점은 실험 속도입니다. 단점은 생태계 부재입니다. 에이전트가 언어를 잘 쓰려면 언어가 단순한 것만으로는 부족합니다. 충분한 예제, 표준 라이브러리, 실패 사례, 실제 프로젝트, 벤치마크, 유지보수 규칙이 쌓여야 합니다.

Reddit 반응에서도 이 회의론이 보입니다. 에이전트에게 좋은 언어가 되려면 학습할 큰 코드베이스가 필요하다는 지적입니다. 이 반론은 타당합니다. Zero가 아무리 구조화된 repair plan을 제공해도, 실제 작업이 대부분 기존 Python, TypeScript, Rust, shell, SQL, YAML과 맞물린다면 에이전트는 결국 기존 생태계와 통합해야 합니다. Zero의 장기 과제는 "새 언어"가 아니라 "새 언어가 기존 시스템과 만나는 접점"입니다.

왜 Vercel Labs가 이런 실험을 하나

Vercel Labs가 Zero를 낸 맥락도 중요합니다. Vercel은 이미 v0, AI SDK, agent skills, browser automation, sandbox와 같은 에이전트 개발 표면을 넓혀 왔습니다. 최근 개발자 도구 시장에서 AI 에이전트는 웹 앱을 만들고, 브라우저에서 검증하고, 배포 로그를 읽고, CI를 고치고, PR을 제안하는 쪽으로 이동했습니다.

그런데 이런 흐름이 깊어질수록 병목은 모델 답변에서 도구 계약으로 내려갑니다. 에이전트가 코드를 생성해도 컴파일러가 모호한 문자열만 내보내면, 모델은 다시 추측해야 합니다. 패키지 선택이 너무 자유로우면 검색과 의존성 판단이 비용이 됩니다. 문법이 여러 스타일을 허용하면 diff는 맞아도 local convention이 깨질 수 있습니다. 에러가 사람에게 친절해도 기계에게 안정적인 필드가 아니면 자동 수리 루프를 만들기 어렵습니다.

Zero는 이 병목을 언어 설계에서 풀어보는 연구개발 성격의 프로젝트입니다. 공식 README가 "zero dependencies", "fast startup", "fast builds", "low runtime latency"를 내세우는 것도 같은 맥락입니다. 에이전트가 수십 번 check, explain, plan, rerun을 반복하려면 도구 호출이 빠르고 출력이 작아야 합니다. token efficiency가 언어의 목표 목록에 들어간다는 점이 특히 2026년다운 장면입니다.

실제 개발자가 지금 무엇을 봐야 하나

Zero를 지금 실무 언어로 검토할 단계는 아닙니다. 공식 문서가 그렇게 말합니다. syntax와 API는 계약이 아니며, breaking change가 예상됩니다. 보안 취약점도 예상됩니다. production과 민감 데이터에는 쓰지 말아야 합니다. 이 점을 흐리면 Zero의 의미를 오히려 놓칩니다.

대신 개발자와 AI 제품 팀이 봐야 할 것은 interface pattern입니다. 에이전트가 사용하는 CLI는 어떤 JSON을 내보내야 하는가. 오류 코드와 span은 얼마나 안정적이어야 하는가. repair plan은 파일을 직접 수정하기 전에 어떤 안전도와 범위를 표시해야 하는가. 언어 규칙과 표준 라이브러리 문서는 어떻게 버전과 함께 배포되어야 하는가. capability와 effect는 policy engine과 human approval에 어떤 단서를 줄 수 있는가.

이 질문들은 Zero를 쓰지 않아도 오늘의 프로젝트에 적용됩니다. 자체 CLI를 가진 팀이라면 --json 출력이 모델에게 안정적인지 점검할 수 있습니다. 내부 framework를 가진 팀이라면 에이전트가 읽는 diagnostics와 human-readable logs를 분리할 수 있습니다. 보안 팀이라면 도구 호출 전후가 아니라 코드의 capability 요구를 어디서 포착할지 고민할 수 있습니다. 플랫폼 팀이라면 에이전트가 설치된 도구와 같은 버전의 규칙 문서를 어떻게 받을지 설계할 수 있습니다.

커뮤니티의 초기 신호와 한국어권 맥락

GeekNews에도 Zero가 빠르게 올라왔습니다. 2026년 5월 24일 KST 기준 약 21시간 전 등록됐고, "Vercel Labs에서 에이전트가 주 사용자가 되는 환경을 가정해 처음부터 다시 설계된 실험적 프로그래밍 언어"라는 요약이 붙었습니다. 아직 토론 규모가 크지는 않지만, 한국 개발자 커뮤니티도 이 주제를 단순 언어 뉴스가 아니라 에이전트 시대 개발 환경 변화로 받아들이고 있습니다.

일본 gihyo.jp는 2026년 5월 18일 기사에서 Zero를 Apache 2.0으로 공개된 언어로 소개하며, Chris Tate의 발표와 함께 explicit capabilities, JSON diagnostics, typed safe fixes를 짚었습니다. 영어권 일부 글은 "compiler speaks JSON to AI agents"라는 프레임을 씁니다. 표현은 조금 과하지만, 핵심 문제는 맞습니다. 인간이 읽는 오류 문장을 모델이 다시 해석하는 번역층을 줄이려는 시도입니다.

다만 초기 흥분은 조심해야 합니다. "AI 에이전트를 위한 언어"라는 문구는 강하지만, 실제 언어 채택은 훨씬 느립니다. 새 언어가 성공하려면 compiler, formatter, debugger, package manager, editor support, CI, docs, examples, community, security review가 모두 필요합니다. 에이전트 우선 설계가 이 모든 비용을 상쇄할지는 아직 알 수 없습니다.

Zero가 남기는 질문

Zero의 가장 큰 의미는 답보다 질문에 있습니다. 앞으로 에이전트가 코드를 많이 쓴다면, 프로그래밍 언어는 사람의 미감과 표현력만 최적화해도 충분한가. 컴파일러 오류는 사람이 읽는 문장이어야 하는가, 아니면 모델과 정책 엔진이 검증할 수 있는 데이터 구조여야 하는가. 표준 라이브러리는 인간 개발자의 생산성만이 아니라 에이전트의 dependency search 비용까지 고려해야 하는가. 문법 설계에서 "여러 스타일을 허용하는 유연함"은 에이전트에게 이득인가, 비용인가.

Zero는 아직 답을 증명하지 못했습니다. 그러나 에이전트 시대의 개발 도구가 단순히 더 큰 모델을 붙이는 방향만으로 가지 않을 것임은 분명히 보여줍니다. 언어, 컴파일러, CLI, 문서, 권한 모델이 모두 에이전트와 협업하는 형태로 다시 설계될 수 있습니다.

그래서 Zero를 볼 때 중요한 것은 "이 언어를 배워야 하나"가 아닙니다. 더 중요한 질문은 "내가 만드는 도구는 에이전트가 읽고 고칠 수 있는 계약을 갖고 있는가"입니다. Zero의 4.4k stars는 새 언어에 대한 기대라기보다, 그 질문에 개발자들이 반응하기 시작했다는 작은 신호에 가깝습니다.