Git을 Zig로 재작성하다: AI 토큰 비용을 71% 줄인 Nit의 기술적 고찰
최근 Hacker News에서 꽤 흥미로운 프로젝트를 하나 발견했다. 이름은 Nit. AI 에이전트가 소비하는 토큰을 줄이기 위해 Git을 Zig로 재작성한 프로젝트다.
AI 코딩 어시스턴트가 대세가 된 지금, LLM이 CLI 툴과 상호작용할 때 발생하는 비효율을 짚어낸 점이 꽤 날카롭다. 시니어 엔지니어로서 이런 류의 “바퀴 재발명”을 볼 때마다 보통은 회의적인 시선부터 보내지만, 이 프로젝트는 아키텍처 측면에서 살펴볼 만한 가치가 있었다.
왜 AI에게 Git은 비효율적인가?
저자의 데이터에 따르면 3,156개의 실제 코딩 세션에서 Git 명령어는 전체 쉘 커맨드의 7.4%를 차지했고, 약 45만 개의 토큰을 소비했다고 한다.
생각해보면 당연한 일이다. Git의 출력 결과는 철저히 사람을 위해 디자인되었다. 친절한 안내 문구, 컬럼 패딩, 데코레이션 등 기계 입장에서는 쓸데없는 Latency와 토큰 비용을 발생시키는 쓰레기 데이터일 뿐이다. 저자의 표현을 빌리자면 “모든 답변을 티슈 페이퍼와 선물 봉투로 포장하는 것”과 같다.
Nit의 접근 방식: Zig와 libgit2
저자는 이 문제를 해결하기 위해 Zig를 선택했다. 핵심은 libgit2를 통한 직접 통신이다.
Zig를 사용한 이유는 명확하다. Zig의 C interop은 말 그대로 Zero-cost이기 때문이다. 텍스트 파싱이나 Subprocess overhead 없이 @cImport를 통해 libgit2 헤더를 가져와 객체 데이터베이스를 네이티브하게 읽는다.
- 속도:
status명령어 기준 13.7ms에서 8.4ms로 약 1.64배 빠르다. - 토큰 절약:
log -20의 경우 약 2,273 토큰에서 301 토큰으로 87%나 절약된다.
구현되지 않은 명령어는 어떻게 처리할까? 여기서 저자의 영리함이 돋보인다. execvpe()를 호출해 원래의 Git 프로세스로 Fallback 해버린다. 즉, alias git=nit로 설정해도 기존 기능이 깨질 염려가 없으며, 사용자는 Wrapper overhead 없이 점진적으로 최적화의 이점을 누릴 수 있다.
U1 실험: 컨텍스트는 1줄이면 충분하다
개인적으로 가장 흥미로웠던 부분은 U1 실험이다. Git diff의 기본 Context는 3줄이다. 저자는 이를 1줄(U1)로 줄였다.
“컨텍스트를 줄이면 LLM의 코드 이해도가 떨어지지 않을까?”라는 의문이 당연히 든다. 하지만 27번의 복잡한 다중 파일 diff 테스트 결과, Claude는 U0, U1, U3 환경 모두에서 완벽한 점수를 받았다. 실제 Claude Code 세션 데이터를 봐도 에이전트가 diff 직후에 원본 소스 파일을 읽는 경우는 3.9%에 불과했다. 즉, 변경된 라인과 1줄의 컨텍스트만으로도 기계에게는 충분한 정보가 전달된다는 뜻이다.
HN 커뮤니티의 반응과 나의 시선
Hacker News 스레드에서는 당연하게도 “왜 굳이 새로 짰냐”는 질문이 쏟아졌다.
“그냥 git status --short나 git log --oneline을 쓰면 되는 거 아님? 아니면 간단한 Wrapper 스크립트를 짜든가.”
솔직히 나도 처음엔 같은 생각이었다. 하지만 시스템 엔지니어링 관점에서 보면 단순히 플래그를 추가하는 것과 네이티브하게 최적화하는 것은 차이가 크다. 수천 번 반복되는 AI 에이전트 루프에서 Subprocess overhead를 제거하고, 에이전트 프롬프트에 구질구질하게 “항상 --short 플래그를 써라”라고 지시하는 비용을 줄이는 것은 꽤 합리적인 접근이다.
하지만 간과해선 안 될 점도 있다. 바로 RLHF 문제다. 현재 시장에 나온 대부분의 LLM은 표준 Git의 장황한 출력 결과에 강하게 학습(RLHF)되어 있다. 포맷을 임의로 압축했을 때, 모델의 추론 능력이 미세하게 떨어지거나 예상치 못한 환각(Hallucination)을 일으킬 가능성을 완전히 배제할 수는 없다. 이 부분은 더 많은 스케일의 프로덕션 데이터로 검증이 필요해 보인다.
결론: 도입할 가치가 있는가?
Nit는 단순한 Toy 프로젝트 그 이상이다. AI 에이전트의 I/O를 최적화해야 한다는, 앞으로 우리가 직면할 새로운 엔지니어링 과제를 정확히 짚어냈다.
당장 전사적인 CI/CD 파이프라인이나 백엔드 시스템의 Git을 이걸로 대체하라고 권하진 않겠다. 하지만 로컬에서 돌아가는 AI 코딩 어시스턴트(Cursor, Cline 등)를 헤비하게 사용하는 개발자라면, 토큰 비용 절감과 응답 속도 향상을 위해 충분히 시도해 볼 만한 매력적인 툴이다.
무엇보다, 문제에 접근하고 해결해 나가는 저자의 철학(Fallback 설계, 데이터 기반의 U1 실험)은 우리 모두가 배울 만한 훌륭한 엔지니어링 사례라고 생각한다.
References
- Original Article: https://justfielding.com/blog/nit-replacing-git-with-zig
- Hacker News Thread: https://news.ycombinator.com/item?id=47526276