Zero 언어가 보여준 AI 에이전트용 컴파일러의 방향

Zero 언어를 처음 봤을 때 든 생각은 “또 하나의 새 언어인가?”였다. 그런데 조금 읽어보니 포인트가 달랐다. 이건 사람 개발자를 편하게 하겠다는 언어라기보다, AI 에이전트가 코드를 읽고 고치고 다시 검사하는 루프를 언어와 컴파일러 차원에서 줄여보려는 실험에 가깝다.

zerolang 공식 사이트는 아예 “agents are primary users”라는 방향을 전면에 건다. GitHub 저장소도 실험적 언어라고 못 박고 있고, 보안 취약점이 있을 수 있으니 production이나 민감한 인프라에 쓰지 말라고 분명히 말한다. 그래서 이 글은 Zero를 당장 써보자는 추천이 아니다. 오히려 “AI 에이전트용 컴파일러”라는 관점이 왜 이제야 이렇게 노골적으로 나오는지에 대한 메모에 가깝다.

최근에 Gemini CLI 전환과 Antigravity 2.0을 보면서도 비슷한 생각을 했다. 개발 도구의 주 사용자가 사람 한 명에서 사람과 에이전트의 묶음으로 바뀌면, 터미널과 IDE만 바꾸는 걸로는 부족하다. 컴파일러, 문서, 에러 메시지, 권한 모델까지 같이 바뀌어야 한다.

Zero 언어가 건드린 지점

사람 친화적인 에러 메시지는 에이전트에게 애매하다

지금 대부분의 컴파일러 에러는 사람을 향한다. 줄 번호, 설명, 힌트, 가끔은 친절한 예시까지 나온다. 사람 입장에서는 충분히 좋다. 문제는 에이전트가 이걸 읽을 때다. 모델은 prose를 꽤 잘 읽지만, 그래도 매번 문장을 해석해야 한다. 같은 문제도 버전이 바뀌면 표현이 달라지고, 도구가 바뀌면 포맷이 달라진다.

Zero가 재미있는 건 이 부분을 언어 바깥의 플러그인으로 처리하지 않고, 컴파일러의 기본 인터페이스로 다룬다는 점이다. zero check --json, zero graph --json, zero size --json 같은 명령으로 진단, 그래프, 크기 정보를 구조화해서 뽑는다. 공식 문서도 패키지 점검과 그래프 검사를 자연스럽게 CLI 흐름 안에 넣어둔다.

이건 작아 보이지만 꽤 큰 차이다. 에이전트가 “이 에러는 아마 이런 뜻일 거야”라고 추측하는 대신, 안정적인 코드와 span, 수정 단서를 읽을 수 있다. 사람이 보는 에러 메시지는 여전히 필요하지만, 에이전트에게는 prose보다 contract가 더 중요하다.

JSON 출력은 편의 기능이 아니라 경계다

요즘 CLI에 --json 붙는 건 흔하다. 그래서 처음엔 별 감흥이 없었다. 그런데 Zero의 방향은 단순한 출력 옵션과 조금 다르다. JSON 출력이 “자동화하기 편하게 덧붙인 기능”이 아니라, 에이전트 워크플로우의 기본 경계로 설계돼 있다.

예를 들어 에이전트가 컴파일 실패를 만났다고 해보자. 기존 언어에서는 보통 이렇게 돈다. 빌드 실패 로그를 읽고, 원인을 추론하고, 파일을 열고, 고치고, 다시 돌린다. 이 과정에서 로그 파싱이 흔들리면 이상한 수정으로 샌다. 특히 대형 레포에서는 실패 로그가 길고, 여러 에러가 섞이고, 중간에 테스트 프레임워크 출력까지 들어간다.

Zero가 말하는 구조는 좀 다르다. 컴파일러가 에러를 “설명”만 하는 게 아니라, 에이전트가 다음 행동을 고를 수 있는 형태로 내보낸다. CHANGELOG를 보면 0.1.3에서도 structured backend blocker, target readiness facts, diagnostics 같은 표현이 계속 나온다. 아직 초기지만, 방향은 꽤 선명하다.

명시적 효과가 에이전트에게 주는 힌트

World가 시그니처에 드러난다는 점

Zero 예제에서 눈에 띄는 건 world World다. 출력 같은 외부 세계 접근이 함수 시그니처에 드러난다. 공식 getting started의 예제도 world.out.write를 통해 출력하고, 이게 숨은 전역 객체가 아니라 명시적 capability라는 점을 설명한다.

사람이 보기에는 조금 장황할 수 있다. 솔직히 인간 개발자는 이런 걸 매번 쓰는 걸 싫어한다. 편한 문법, 짧은 import, 암묵적 컨텍스트를 좋아한다. 그런데 에이전트 입장에서는 장황함이 꼭 나쁜 게 아니다. 함수가 외부 세계를 건드리는지, 실패할 수 있는지, 어떤 capability를 요구하는지 시그니처에 보이면 탐색 비용이 줄어든다.

AI 에이전트가 낯선 코드베이스를 읽을 때 제일 자주 삐끗하는 지점이 이런 암묵성이다. 어디서 파일을 읽는지, 네트워크를 여는지, 전역 상태를 바꾸는지 따라가려면 call graph를 꽤 깊게 파야 한다. 사람이면 경험으로 눈치채지만, 에이전트는 그 눈치를 매번 토큰과 도구 호출로 산다.

명시성은 속도를 늦추지만 수리 가능성을 높인다

Zero의 철학을 한 줄로 줄이면 “cleverness보다 regularity”에 가깝다. 공식 사이트도 작은 surface area, standard-library first, deterministic repair loop 같은 방향을 반복한다. 이게 인간에게는 가끔 답답해 보일 수 있다. 이미 Rust, Go, Zig, TypeScript에 익숙한 개발자라면 “굳이 새 언어까지?”라는 반응이 나오는 게 자연스럽다.

나도 그 반응이 맞다고 본다. Zero가 지금 당장 Rust를 대체한다거나, Go 서버를 갈아엎을 이유가 된다고 보지는 않는다. 생태계도 작고, 문법도 움직이고, production 준비 상태도 아니다. 공식 문서가 직접 safe environment에서만 쓰라고 한다.

그래도 수리 가능성이라는 관점은 남는다. 사람이 멋지다고 느끼는 추상화가 에이전트에게는 모호할 수 있다. 반대로 사람이 약간 지루하다고 느끼는 규칙성이 에이전트에게는 안전한 발판이 될 수 있다. 이 차이가 앞으로 언어 설계에서 더 자주 논쟁거리가 될 것 같다.

지금 Zero를 보는 현실적인 방법

production 언어가 아니라 실험실 샘플이다

여기서 선을 분명히 긋는 게 좋다. Zero는 아직 production 언어로 보면 안 된다. 저장소 README에도 보안 취약점을 예상해야 하고, 신뢰 인프라나 민감한 데이터에 쓰지 말라고 적혀 있다. gihyo.jp의 소개 글도 실험 단계이며 안정 동작을 보장하는 프로젝트가 아니라고 정리했다.

그래서 팀에서 Zero를 보는 올바른 태도는 “우리 서비스에 붙일까?”가 아니라 “우리 도구 체인은 에이전트에게 어떤 정보를 주고 있나?”에 가깝다. 이 질문은 꽤 실용적이다. 기존 언어를 그대로 쓰더라도 컴파일러 출력, 린터 출력, 테스트 리포트, 코드 리뷰 봇의 피드백을 더 구조화할 수 있기 때문이다.

내가 팀에서 바로 가져갈 만하다고 느낀 건 이런 쪽이다.

이 정도는 새 언어를 쓰지 않아도 가능하다. 오히려 지금은 이쪽이 훨씬 현실적이다.

에이전트가 읽는 문서도 버전 문제를 겪는다

Zero에서 의외로 마음에 들었던 건 zero skills 쪽이다. 컴파일러가 설치된 버전에 맞는 agent guidance를 제공한다는 발상이다. GitHub README에 따르면 zero skills list, zero skills get zero-language, zero skills get zero-diagnostics 같은 흐름으로 현재 바이너리에 맞는 규칙을 읽을 수 있다.

이건 되게 실무적인 문제를 찌른다. 에이전트는 문서를 잘 읽지만, 그 문서가 현재 프로젝트 버전과 맞는지는 별개의 문제다. 예전 API 문서를 보고 새 버전 코드를 고치거나, 블로그 글의 예제를 최신 CLI에 적용하다가 틀리는 일이 생긴다. 사람도 헷갈리는데 에이전트는 더 쉽게 헷갈린다.

그래서 앞으로 좋은 개발 도구는 “공식 문서가 웹에 있다”에서 멈추지 않을 것 같다. 로컬에 설치된 버전이 자기 사용법을 기계가 읽기 좋은 형태로 내보내고, 에이전트가 그걸 먼저 읽는 구조가 필요하다. 이건 Zero 자체보다 더 오래 남을 아이디어일 수 있다.

회의적으로 봐야 하는 부분

새 언어가 진짜 병목을 풀지는 아직 모른다

Zero의 문제의식은 흥미롭지만, 새 언어가 정말 에이전트 코딩의 병목을 풀지는 아직 모른다. 에이전트가 실패하는 이유는 에러 메시지 파싱만이 아니다. 요구사항 이해를 틀리기도 하고, 테스트를 과신하기도 하고, 도구 사용 순서를 잘못 잡기도 한다. 긴 작업에서는 계획 자체가 흔들린다.

그래서 “컴파일러가 JSON을 준다”는 건 중요한 개선이지만 만능은 아니다. 에러를 더 잘 고쳐도, 애초에 잘못된 기능을 만들면 소용없다. 권한 경계가 흐리면 더 빠르게 위험한 작업을 할 수도 있다. agent-native라는 말이 붙었다고 해서 운영 품질이 자동으로 올라가지는 않는다.

이전에 AI 코딩 성과 지표를 다루면서도 같은 얘기를 했다. 생성 속도보다 검증 비용이 더 중요할 때가 많다. Zero 같은 실험도 결국 이 기준을 통과해야 한다. 에이전트가 더 빨리 고친 것처럼 보이는 게 아니라, 사람이 검증해야 할 불확실성을 실제로 줄였는가.

생태계 없는 언어는 학습 데이터도 적다

또 하나의 현실적인 문제는 학습 데이터다. AI 에이전트는 낯선 언어도 문서를 읽고 따라갈 수 있지만, 대중적인 언어만큼 잘하긴 어렵다. Rust, Python, TypeScript는 이미 코드 예제와 오류 사례와 라이브러리 사용법이 산처럼 쌓여 있다. Zero는 그 반대다. 언어가 작고 규칙적이어도, 실제 사례가 적으면 에이전트가 부딪힐 수 있다.

물론 Zero의 목표는 이 한계를 줄이는 데 있다. 작은 문법, 표준 라이브러리 중심, 구조화된 diagnostics로 “많은 학습 데이터 없이도 즉석에서 배울 수 있게” 만들겠다는 쪽이다. 하지만 그 주장이 실전에서 얼마나 버티는지는 별도 검증이 필요하다.

나 같으면 지금은 작은 샌드박스에서만 본다. 예제 프로젝트 하나 만들고, 에이전트에게 의도적으로 에러를 내게 하고, zero check --json과 수정 루프가 얼마나 안정적인지 관찰하는 정도다. 서비스 코드나 내부 도구에 바로 넣을 단계는 아니다.

개발 도구가 바뀌는 더 큰 흐름

IDE 다음은 compiler interface일 수 있다

올해 개발 도구 흐름을 보면 대부분이 agentic coding을 말한다. Google은 Antigravity를 밀고, GitHub와 OpenAI, Anthropic, Cursor 계열 도구는 각자 비동기 작업과 에이전트 루프를 더 깊게 넣고 있다. 그런데 이 흐름이 IDE에서 끝날 리는 없다.

에이전트가 정말로 코드를 맡는다면, 아래층 도구들이 에이전트에게 더 좋은 인터페이스를 제공해야 한다. 컴파일러는 structured diagnostics를 내보내고, 테스트 러너는 flaky 여부와 실패 원인을 기계가 읽을 수 있게 주고, 배포 도구는 권한과 위험도를 명확히 알려줘야 한다. 지금처럼 사람이 터미널 로그를 읽는 방식에 에이전트를 끼워 넣는 건 오래 못 간다.

Zero는 이 변화를 아주 작은 언어 하나로 과감하게 밀어본 케이스다. 성공할 수도 있고, 그냥 좋은 실험으로 끝날 수도 있다. 하지만 방향은 꽤 선명하다. 앞으로 도구의 CLI는 사람에게 예쁜 출력만 주는 게 아니라, 에이전트에게 안정적인 계약을 줘야 한다.

우리 팀이 지금 볼 질문

그래서 Zero를 보고 나서 내 작업 목록에 남은 질문은 이렇다.

agent_tooling_check:
  build_output: json_available
  test_report: machine_readable
  lint_fix: plan_before_apply
  docs: version_matched
  permissions: explicit_for_file_network_secret
  review: human_checkpoint_required

새 언어를 도입하지 않아도 이 체크는 할 수 있다. 특히 에이전트가 CI를 만지거나, 파일 시스템을 넓게 열거나, 외부 API 키가 있는 작업을 할 때는 이런 경계가 중요하다. AI 에이전트에게 친절한 도구는 사람에게도 대체로 좋다. 로그가 구조화되고, 권한이 명시되고, 수정 계획이 남으면 디버깅과 리뷰도 쉬워진다.

마치며

Zero 자체보다 질문이 더 오래 갈 것 같다

Zero 언어가 널리 쓰일지는 모르겠다. 솔직히 지금 단계에서는 가능성보다 물음표가 더 많다. 언어가 너무 이르고, 생태계도 작고, production 경고도 강하다. 당장 팀에 도입하라고 말하면 무책임하다.

그런데 Zero가 던진 질문은 꽤 오래 갈 것 같다. 프로그래밍 언어와 컴파일러가 사람만 바라보던 시절이 끝나면, 어떤 인터페이스가 필요할까. 에러 메시지는 문장이어야 할까, 구조화된 계약이어야 할까. 함수의 부작용은 편의를 위해 숨겨야 할까, 에이전트가 읽도록 드러내야 할까.

나는 이 질문이 마음에 든다. 요즘 AI 코딩 도구 이야기는 너무 자주 “어느 모델이 더 똑똑한가”로 흘러간다. 하지만 실제 개발팀에서는 모델만큼이나 도구의 표면이 중요하다. 에이전트가 읽는 컴파일러, 에이전트가 읽는 테스트 결과, 에이전트가 읽는 문서가 좋아지면 같은 모델도 덜 헤맨다.

Zero는 아직 답이라기보다 실험이다. 그래도 좋은 실험이다. 새 언어 하나를 배워야 한다는 압박보다, 우리 도구가 에이전트에게 무엇을 얼마나 명확하게 말해주고 있는지 돌아보게 만든다. 지금은 그 정도만으로도 볼 가치가 있다.