Zero 0.1.3, 컴파일러가 에이전트 API가 되는 조건

Vercel Labs가 공개한 Zero는 겉으로 보면 또 하나의 실험적 시스템 프로그래밍 언어입니다. 확장자는 .0이고, 공식 사이트 첫 화면은 "The programming language for agents"라는 문장을 전면에 둡니다. 2026년 5월 16일 v0.1.0이 나온 뒤, 5월 19일에는 v0.1.3이 공개됐습니다. GitHub API 기준 5월 20일 오전에는 3,700개가 넘는 stars와 200개가 넘는 forks를 모았습니다.

하지만 이 뉴스를 "Vercel이 새 언어를 만들었다"로만 읽으면 핵심을 놓칩니다. Zero의 흥미로운 지점은 문법 취향이 아닙니다. 코딩 에이전트가 컴파일러 오류를 읽고, 원인을 분류하고, 안전한 수정 계획을 만들고, 다시 검증하는 반복 루프를 언어와 툴체인 자체가 어떻게 도울 수 있는지를 묻는 데 있습니다. 기존 언어가 사람을 primary user로 두고 에이전트에게는 텍스트 로그를 읽게 했다면, Zero는 처음부터 에이전트가 읽는 출력 형식을 공개 인터페이스처럼 다루려 합니다.

공식 README는 Zero를 아주 조심스럽게 소개합니다. pre-1이고 의도적으로 불안정하며, breaking changes가 계속 날 수 있고, 생산 시스템이나 민감 데이터, trusted infrastructure에는 쓰지 말라고 경고합니다. 즉 지금 Zero를 봐야 하는 이유는 "다음 프로젝트 언어로 당장 채택할 것인가"가 아닙니다. AI 에이전트 시대에 컴파일러와 CLI, 문서, 표준 라이브러리가 어떤 contract를 제공해야 하는지 가늠하는 사례로 봐야 합니다.

에이전트가 막히는 곳은 코드보다 도구 출력입니다

코딩 에이전트가 실패하는 장면을 떠올려보면 원인은 항상 모델의 코드 생성 능력만은 아닙니다. 에이전트는 이미 수많은 언어의 기본 문법을 알고 있고, 대부분의 짧은 함수는 꽤 잘 작성합니다. 문제는 그 다음입니다. 컴파일러가 오류를 냅니다. 테스트 runner가 실패 로그를 냅니다. bundler가 긴 trace를 냅니다. 타입 체커는 여러 파일의 관계를 설명합니다. 에이전트는 이 출력을 읽고, 어떤 줄이 원인인지, 어떤 수정이 안전한지, 어느 명령을 다시 돌려야 하는지 추론해야 합니다.

사람에게도 오류 메시지는 어렵지만, 사람은 문맥을 많이 보완합니다. 최근 변경한 파일을 기억하고, 프로젝트 관례를 알고, "이 메시지는 실제 원인이 아니라 파생 오류일 수 있다"는 감각을 씁니다. 에이전트는 이 감각을 텍스트 패턴과 context window 안에서 흉내 냅니다. 그래서 로그 형식이 길거나 불안정하거나 색상 코드와 terminal control sequence가 섞이면 수리 루프가 흔들립니다. 같은 underlying problem이 compiler version마다 다른 문장으로 표현되면, 에이전트가 안정적으로 분기하기 어렵습니다.

Zero가 겨냥하는 병목은 바로 이 지점입니다. 공식 diagnostics 문서는 기본 출력은 terminal log에 짧고 유용해야 하지만, agents, CI, editors, deep dives에는 --json을 쓰라고 설명합니다. zero check --json이 내는 packet은 schemaVersion, ok, diagnostics 배열, stable code, source span, expected/actual, help, fixSafety, repair 객체를 포함합니다. 사람이 읽는 메시지와 에이전트가 분기할 수 있는 구조화 데이터가 같은 compiler contract 안에 있는 셈입니다.

이 구조는 language server protocol이나 TypeScript service, Rust JSON diagnostics와 완전히 무관한 발명은 아닙니다. 중요한 차이는 Zero가 이것을 보조 기능이 아니라 language experiment의 중심 메시지로 둔다는 점입니다. "에이전트가 코드를 잘 쓰게 하려면 모델을 더 키우면 된다"가 아니라 "에이전트가 사용할 언어와 도구도 agent-readable해야 한다"는 주장입니다.

fixSafety는 작은 필드처럼 보이지만 큰 계약입니다

Zero diagnostics 문서에서 특히 눈에 띄는 부분은 fix safety입니다. 문서는 수정 라벨을 format-only, behavior-preserving, local-edit, api-changing, requires-human-review처럼 나눕니다. 이것은 단순한 친절한 설명이 아닙니다. 에이전트가 어느 수준까지 자동으로 행동해도 되는지 판단하는 정책 입력입니다.

예를 들어 formatting만 바꾸는 수정은 에이전트가 바로 적용해도 됩니다. 현재 local scope 안에서 이름을 선언하는 수리는 상대적으로 작지만, 그래도 테스트가 필요합니다. public API signature가 바뀌거나 call sites를 건드려야 한다면 팀 정책에 따라 사람의 리뷰가 필요할 수 있습니다. destructive command, package upgrade, migration처럼 위험한 작업은 compiler diagnostic 바깥의 승인 체계까지 필요합니다. fixSafety는 이런 판단을 코드와 자연어 사이에 흩어 두지 않고 도구 출력의 일부로 끌어옵니다.

이 지점이 코딩 에이전트 제품들과 연결됩니다. Codex, Claude Code, Cursor, Copilot 같은 도구는 모두 "어떤 수정은 자동으로 하고, 어떤 수정은 멈춰서 물어볼 것인가"라는 문제를 가집니다. 지금은 많은 판단이 agent harness, prompt, allowlist, 테스트 결과에 의존합니다. Zero식 접근은 언어와 compiler가 그 판단에 필요한 원시 신호를 더 강하게 제공합니다. 에이전트가 로그를 읽는 것이 아니라, compiler가 에이전트에게 수리 계획의 타입을 알려주는 방향입니다.

물론 이것이 모든 문제를 해결하지는 않습니다. behavior-preserving이라고 표시된 수정도 실제 프로젝트 의미에서는 위험할 수 있습니다. 반대로 requires-human-review가 붙었다고 항상 사람이 깊게 봐야 하는 것도 아닙니다. 그래도 도구가 안정적인 분류를 제공하면 agent orchestration layer는 더 나은 정책을 만들 수 있습니다. CI에서는 local-edit까지 허용하고, main branch에서는 api-changing을 막고, 보안 민감 패키지에서는 모든 write action을 승인하도록 하는 식입니다.

Zero의 언어 설계는 권한 경계를 노출하려 합니다

Zero가 에이전트를 위한 언어라고 말할 때, diagnostics만 이야기하는 것은 아닙니다. 공식 getting started와 language reference는 아주 작은 main 예제를 반복해서 보여줍니다.

pub fun main(world: World) -> Void raises {
    check world.out.write("hello from zero\n")
}

이 예제는 너무 단순해 보이지만, Zero가 강조하는 방향을 잘 담고 있습니다. 출력은 global print 함수가 아니라 World capability를 통해 일어납니다. write는 실패할 수 있으므로 check가 필요하고, main은 raises를 선언합니다. 외부 세계와의 접촉, fallible operation, 프로그램 entry point의 capability가 모두 시그니처와 문장에 드러납니다.

AI 에이전트 관점에서 이것은 중요합니다. 에이전트가 작은 도구를 만들 때 가장 무서운 부분은 코드가 무슨 일을 할 수 있는지입니다. 파일 시스템을 읽는지, 네트워크를 여는지, 환경 변수를 보는지, 프로세스를 실행하는지, randomness를 쓰는지, time에 의존하는지 알아야 합니다. Zero의 target capability 문서는 zero targets --json이 target별 hosted flag, aliases, mapped C target, capabilities를 보여준다고 설명합니다. 현재 host target만 full hosted capability set을 제공하고, non-host target에는 net이 없을 수 있습니다. 그런 경우 TAR002처럼 명확한 diagnostic으로 실패합니다.

이런 설계는 "예쁜 문법"과 다른 종류의 언어 설계입니다. 사람에게는 다소 장황할 수 있습니다. 매번 capability와 error flow를 명시해야 하고, hidden convenience를 줄입니다. 하지만 에이전트에게는 장점이 됩니다. 숨은 전역 상태와 암묵적 async, 보이지 않는 allocator, 관례로만 관리되는 side effect가 적을수록 코드를 읽고 고치는 비용이 줄어듭니다. Zero README가 "regularity over syntax"를 목표로 든 것도 같은 맥락입니다. 한 가지 obvious path를 주는 대신, 사람이 좋아하는 축약을 일부 포기합니다.

v0.1.3은 실험의 방향을 더 분명히 합니다

최신 changelog를 보면 v0.1.3은 단순 버그 수정만은 아닙니다. hosted HTTP client runtime support, use declarations의 syntax graph facts, import diagnostics와 fix plans, backend blocker와 target-readiness facts, BOR001 borrow trace facts가 들어갔습니다. allocation failure를 deterministic하게 다루기 위한 hardening도 여러 compiler path에 적용됐습니다.

여기서 반복되는 단어는 runtime feature보다 "facts"입니다. import source range, backend blocker, target readiness, borrow trace처럼 에이전트가 수리 루프에서 알고 싶어 하는 정보를 structured output으로 밀어내는 방향입니다. borrow conflict가 생겼을 때 에이전트에게 단지 "borrow error"라고 말하는 것과, active borrow root, path, kind, live binding, declaration range, repair shape를 packet으로 주는 것은 다릅니다.

이는 Zero가 agent-first라는 슬로건을 단순 마케팅으로만 쓰지 않는다는 신호입니다. 언어 자체가 아직 작고 불안정해도, 툴체인이 어디를 향하는지는 꽤 분명합니다. 에이전트가 추측해야 하는 정보를 줄이고, 수리 루프의 각 단계에 타입이 있는 신호를 제공하려는 것입니다.

커뮤니티의 질문은 꽤 타당합니다

이런 실험에는 당연히 회의적인 반응도 따릅니다. "에이전트용 언어가 왜 필요한가"라는 질문은 가볍지 않습니다. 기존 Rust, Go, Zig, TypeScript에 machine-readable diagnostics와 better repair metadata를 붙이면 충분하지 않을까요? 오히려 코퍼스가 작은 새 언어는 에이전트가 학습한 예제가 적어 불리하지 않을까요? 팀이 이미 운영하는 ecosystem, package registry, editor tooling, hiring pool을 버릴 만큼 가치가 있을까요?

Reddit r/WebAfterAI 쪽 반응에서도 비슷한 질문이 보입니다. 새 언어 자체보다 structured diagnostics와 explicit capabilities에는 관심이 있지만, 실제 사용성은 아직 검증 전이라는 분위기입니다. Qiita의 실험 글도 v0.1.1 시점 macOS arm64 direct backend가 제한적이라고 짚으면서, 동시에 zero explain, zero fix --plan --json, structured JSON은 구현된 아이디어라고 평가합니다. Digg cluster는 원 게시물 주변 반응을 긍정과 부정이 거의 반반인 것으로 요약했습니다.

이 회의는 Zero를 더 정확히 보게 해줍니다. Zero가 지금 Rust를 대체할 가능성은 핵심 뉴스가 아닙니다. 오히려 반대입니다. Zero가 성공하지 못하더라도, 다른 compiler와 build tool이 Zero의 일부 아이디어를 흡수할 수 있습니다. stable diagnostic code, repair object, fix safety, target capability facts, graph JSON, size JSON, agent-readable docs는 특정 언어에만 묶일 필요가 없습니다.

경쟁 구도는 언어가 아니라 도구 계약입니다

Zero를 Rust, Go, Zig의 경쟁자로만 놓으면 구도가 흐려집니다. 실제 경쟁은 "에이전트가 코드를 고칠 때 어떤 도구 계약을 믿을 수 있는가"입니다. TypeScript language service는 오래전부터 editor와 tool이 이해할 수 있는 구조화 정보를 제공합니다. Rust compiler도 JSON diagnostics를 지원합니다. Bazel이나 Buck 같은 build system은 dependency graph를 machine-readable하게 노출합니다. MCP 서버와 language server protocol은 도구를 구조화된 인터페이스로 연결합니다.

Zero의 차별점은 이 조각들을 하나의 agent-first 언어 실험으로 묶었다는 데 있습니다. compiler, docs, standard library, target model, fix plan, skill guidance가 모두 "에이전트가 읽을 수 있어야 한다"는 같은 방향을 봅니다. 이는 Vercel이 웹 프레임워크 회사라서 더 흥미롭습니다. 프론트엔드 배포, AI SDK, v0, agentic 개발 흐름을 다루던 회사가 이제 작은 native toolchain과 compiler output까지 에이전트 경험의 일부로 보는 셈입니다.

개발팀 입장에서는 "Zero를 써야 하나"보다 "우리 도구는 에이전트에게 어떤 contract를 주고 있나"를 물어야 합니다. 내부 CLI가 실패할 때 exit code와 JSON error를 주는지, migration tool이 위험한 변경과 안전한 변경을 구분하는지, codegen 도구가 어떤 파일을 왜 바꿨는지 machine-readable하게 남기는지, build graph와 artifact size가 agent에게 안정적으로 전달되는지 봐야 합니다. 이런 질문은 Zero를 쓰지 않아도 바로 실무적입니다.

지금의 결론은 채택이 아니라 관찰입니다

Zero의 공식 문서는 스스로 선을 긋습니다. pre-1이고 불안정하며, 현재 syntax와 API를 외워야 할 대상으로 보지 말라고 합니다. production system이나 sensitive data에는 쓰지 말라는 경고도 분명합니다. 그러므로 devlery 독자에게 필요한 결론은 "새 언어를 배우자"가 아닙니다.

더 중요한 결론은 코딩 에이전트의 병목이 점점 모델 밖으로 나온다는 것입니다. 더 좋은 모델은 여전히 중요합니다. 하지만 에이전트가 실제 저장소에서 오래 일하려면, compiler와 CLI가 안정적인 오류 코드와 수리 metadata를 주고, docs가 machine-readable하게 정리되고, capability boundary가 코드와 target facts에 드러나야 합니다. 사람을 위한 좋은 DX와 에이전트를 위한 좋은 contract가 같은 제품 요구사항이 됩니다.

Zero는 그 요구사항을 과장 없이 보여주는 초기 실험입니다. 성공한다면 작은 native tool을 에이전트가 더 쉽게 만들고 고치는 길을 열 수 있습니다. 실패하더라도, 컴파일러 출력이 agent API가 되어야 한다는 문제 제기는 남을 가능성이 큽니다. 앞으로의 코딩 도구 경쟁은 "누가 더 자연스러운 채팅 UI를 만들었는가"만으로 끝나지 않습니다. 에러 메시지, build graph, fix plan, target capability 같은 낮은 층의 인터페이스가 에이전트에게 얼마나 명확한지도 경쟁력이 됩니다.

그래서 Zero 0.1.3의 뉴스 가치는 작은 release number보다 큽니다. 새 언어가 나왔다는 사실보다, 언어와 컴파일러가 에이전트에게 어떤 약속을 해야 하는지 공개적으로 실험하기 시작했다는 점이 중요합니다. 코딩 에이전트가 사람의 IDE 옆 보조 기능에서 실제 수정자와 운영자로 이동할수록, 이런 약속은 점점 더 비싸고 중요한 인프라가 됩니다.