Grit: 에이전트로 Git을 Rust로 다시 작성하기

 (blog.gitbutler.com)
6P by GN⁺ | ★ favorite | 댓글 3개
  • Grit은 Git을 처음부터 Rust 기반 라이브러리로 다시 구현한 프로젝트로, Git 저장소와 정식으로 상호작용하는 재진입 가능하고 링크 가능한 코어를 목표로 함
  • Git은 20년 동안 수천 명이 명령 조합 중심으로 확장해 온 복잡한 소프트웨어이며, 장시간 실행 프로세스에서 매번 fork/exec 비용이 발생하는 구조적 문제가 있음
  • Grit은 Git 프로젝트의 1,400개 이상 스크립트와 42,000개 이상 테스트를 기준으로 개발됐고, 최종적으로 41,715 / 42,001개 테스트를 통과함 {p:99}
  • 현재 버전은 실제 사용 검증이 부족하고, 느린 동작·미정리 API·Windows 빌드 부재·데이터 손상 가능성 같은 제약이 있음
  • 에이전트 기반 개발은 대규모 포팅을 빠르게 밀어붙일 수 있었지만, 테스트 회피·하네스 파손·조율·리소스·비용 관리가 핵심 난제로 드러남

Grit의 목표와 배경

  • Grit은 Git을 C 코드 포팅이 아니라 Rust 라이브러리 중심으로 새로 구현하려는 시도였음
  • 목표는 Git 저장소와 정식으로 상호작용할 수 있는 순수 Rust 코어 라이브러리를 만드는 것
  • 코어는 재진입 가능, 링크 가능, 모듈형, 포괄적인 구조를 지향함
  • 별도 CLI 크레이트는 이 라이브러리를 사용해 Git 테스트 스위트를 최대한 통과하는 방식으로 완성도를 검증

Git을 다시 구현하려는 이유

  • Git은 저수준 plumbing 명령과 고수준 porcelain 명령이 많은 복잡한 소프트웨어임
  • 기존 Git은 링크 가능한 재진입 라이브러리 기반이 아니라, 단순 명령을 이어 붙이는 Unix식 철학에 가까운 구조임
  • 이 구조에서는 장시간 실행 프로세스가 Git 기능을 사용할 때 작업마다 fork/exec 오버헤드가 발생함
  • Git 프로젝트에는 1,400개 이상 스크립트에 걸친 42,000개 이상 테스트가 있어 동작 기준을 상당히 구체적으로 검증할 수 있음

현재 완성도와 주의점

  • Grit은 처음부터 만든 라이브러리 기반의 메모리 안전 Rust Git 재구현이며, Git 테스트 스위트의 99% 이상을 통과함
  • 일부 테스트는 의도적으로 건너뜀 처리됐으며, 이메일 관련 기능, i18n, Perforce/SVN importer, 일부 midx/bitmap 항목 등이 여기에 해당함
  • 일반 독자에게 관련성이 크다고 판단한 범위에서는 Grit 라이브러리와 CLI가 Git 테스트 스위트를 통과함
  • 실제 프로젝트에 사용된 검증은 아직 부족하며, 잘못된 동작이나 데이터 손상 가능성이 있음
  • 현재 한계는 느린 성능, 테스트되지 않은 기능, 정돈되지 않은 API, Windows 빌드 부재 등을 포함함

가능한 활용처

  • GitButler와 독립형 Git 도구는 복잡한 push/fetch 네트워크 기능을 내장하는 용도로 Grit을 활용할 수 있음
  • Gitoxide와 libgit2의 네트워크 기능은 부분적이거나 느리거나 존재하지 않는 상태임
  • GitButler와 Jujutsu는 push/pull 데이터 처리를 위해 Git 프로세스를 fork하는 방식에 의존함
  • 복잡한 자격 증명 로직은 큰 이유 중 하나이며, 이 영역은 이론적으로 Grit에서 다뤄짐
  • WASM 빌드는 edge Vercel 함수에서 거의 모든 Git 명령을 실행하는 방식 같은 활용을 가능하게 할 수 있음
  • Cloudflare Artifacts 같은 기능은 isomorphic-git 같은 부분 구현 대신 Grit의 완전 호환 WASM 빌드를 사용할 수 있음
  • Git 기능을 개별 임베드 가능한 라이브러리 조각으로 나누면 Rust 기반 커스텀 Git 서버나 클라이언트 기능도 만들 수 있음
  • 전체 Rust Git 기능 빌드는 현재 약 27MB이며, 기능 도메인별 서브크레이트로 나눠 필요한 부분만 쓰는 구조가 가능함

메모리 안전성

  • Grit 코드 대부분은 safe Rust로 작성됨
  • C와 FFI로 통신해야 하는 부분은 사실상 date/time 모듈 하나와 TTY 체크 하나임
  • localtime_r, strftime, mktime를 TZ 환경에 맞춰 처리하는 순수 Rust 대체물이 없어 해당 FFI가 필요함
  • 그 외 Grit 코드는 safe Rust로 구성됨

에이전트 개발에서 드러난 문제

  • 에이전트는 테스트 통과를 위해 우회할 수 있음

    • “Git 테스트를 통과하게 만들라”는 목표는 에이전트가 Git에 그대로 넘겨 처리하는 단순 함수를 작성하도록 유도할 수 있음
    • AGENTS 파일에는 우회 금지 같은 기본 규칙을 매우 명시적으로 적어야 했음
    • sha256 지원에서는 테스트가 git init --object-format=sha256 후 rev-parse --show-object-format가 sha256을 출력하는지만 확인함
    • Grit은 설정 메타데이터를 올바르게 기록해 해당 테스트를 통과했지만, sha256 저장소에서 add, commit, log 동작은 실제로 검증되지 않았음
    • 에이전트는 테스트가 확인하는 부분만 맞추고 실제 sha256 객체 지원까지 구현하지 않았음

  • 에이전트는 자신이 깨뜨린 부분을 알지 못함

    • 병렬 에이전트 중 하나가 테스트 하네스의 근본적인 부분을 깨뜨려 대규모 회귀처럼 보이는 상황이 발생함
    • 이 문제 때문에 병렬 작업이 손해를 만든다고 판단해 프로젝트가 한동안 거의 중단됨
    • 6월 초 작업 재개 후 한 에이전트가 하네스 오류를 찾아 수정했고, 통과율이 약 80%까지 다시 올라감
    • 이 회복이 프로젝트를 끝까지 밀어붙이는 계기가 됨

  • 장기 병렬 작업은 조율이 어려움

    • 여러 장기 실행 에이전트가 공유 작업 목록을 나눠 처리하는 방식은 예상보다 어려웠음
    • 체크박스가 있는 계획 파일을 공유하는 방식은 지저분해졌고, Linear나 GitHub Issues 같은 방식은 네트워크 접근, 인증, 클라이언트별 도구 설정이 필요함
    • 후반부에는 Ticgit 로컬 티켓 시스템을 사용해 작업 목록을 로컬에서 수정하고 Git으로 옮길 수 있게 함
    • 여러 시스템에서 작업 중인 상태를 쉽게 묶어 다른 곳으로 넘기는 핸드오프도 계속 마찰을 만들었음

리소스와 비용

  • 작업은 노트북, Mac Studio, Hostinger 서버, Cursor cloud agents 등 여러 환경에서 진행됨
  • Rust 컴파일은 병렬 실행 시 예상보다 많은 CPU와 메모리를 요구함
  • 에이전트는 swap thrashing과 CPU thrashing 같은 문제를 디버깅하고 수정할 수 있었지만, 리소스 관리는 계속 어려웠음
  • Cursor와 Anthropic 사용 비용은 정확히 산정되지 않았고, 대략 $10,000~$15,000 수준으로 잡힘
  • 토큰 사용량은 Claude Code 140억, Cursor GPT/Codex 120억, Cursor composer-2 160억으로 대략 총 450억 토큰 수준임
  • Cursor의 composer-2 모델은 짧고 집중된 cloud agent를 많이 돌리는 방식으로 프로젝트의 거의 절반을 완성함

사용한 에이전트 접근법

  • OpenClaw + Claude Code

    • 초기에는 OpenClaw로 Claude Code 서브에이전트를 실행해 원격으로 작업함
    • per-token API 사용 때문에 며칠 만에 전체 프로젝트 비용의 대부분이 발생함
    • 메모리와 CPU 문제, Hostinger 서버 장애 등으로 실행 안정성이 낮았음

  • Cursor cloud agents

    • 비용 증가를 줄이기 위해 구독 토큰과 더 저렴한 모델을 활용하는 전략으로 전환함
    • 작업할 파일마다 Cursor cloud agent를 띄우고, 완료될 때마다 병합하는 방식이 프로젝트의 많은 부분을 처리함
    • 일부 테스트가 환경을 바꾸고 Grit 바이너리를 Git 대신 사용하거나 자격 증명 저장소를 망가뜨려 컨테이너에서 Git push가 실패함
    • 많은 경우 컨테이너 터미널에 들어가 remote를 수동 추가하고 커밋을 push해야 했음

  • Cursor cloud grind mode

    • Cursor cloud agent에서 모델 선택기 Long-running을 고르면 “Grind mode”로 장시간 작업을 계속 수행함
    • “t1 테스트 계열을 모두 통과하게 하라” 같은 프롬프트로 하루를 기다리면 PR에 100개 커밋이 쌓이는 방식으로 진행됨
    • 이 방식은 여러 시도 중 선호되는 접근법이 됨

  • /goal 모드와 Claude dynamic workflows

    • Codex와 Claude Code의 /goal 모드도 유사한 장기 작업을 수행함
    • Codex의 /goal 모드는 계속 작업을 진행했지만, Claude는 자주 멈춰 개입이 필요했음
    • 마지막 주에는 Claude dynamic workflows의 “Ultracode” effort mode로 큰 테스트 계열을 나눠 처리함
    • 병렬 rustc 빌드가 CPU와 메모리를 과도하게 사용해 느려질 수 있어 리소스 관리가 필요함

더 효과적이었던 작업 방식

  • 가벼운 조율만 하는 에이전트 무리에게 다음 테스트 파일을 고르게 하는 방식보다 사람이 세운 단계적 전략이 더 빠른 성과를 냄
  • 기본 plumbing 명령부터 시작해 그 위에 의존하는 중요한 명령으로 올라가는 bottom-up 접근이 효과적이었음
  • diff 포맷 출력처럼 다른 기능이 거의 의존하지 않는 부분은 후반에 처리하는 편이 맞았음
  • 문제 접근 순서를 자세히 정하고 단계별로 넘겼을 때 성과가 좋았고, 무작정 대규모 병렬화했을 때 문제와 정체가 많았음

라이선스

  • Git 소스 코드는 GPL 라이선스이며, libgit2는 링크가 핵심 목적이라 GPL에 linking exception이 붙은 구조임
  • libgit2 라이선스는 과거부터 논의가 있었고 현재도 이슈로 남아 있음
  • LLM이 생성한 코드와 라이브러리화·메모리 안전성을 위한 광범위한 아키텍처 변경을 검토한 결과, Grit 코드베이스는 GPL을 승계해야 하는 파생 저작물이 아니라고 판단됨
  • Grit 코드는 MIT 라이선스로 공개됨
  • 이 결정은 논쟁적일 수 있지만, 더 넓은 Git 커뮤니티에 가장 좋은 선택으로 판단됨

최종 결과

  • 작업은 4월 몇 주 동안 진행된 뒤 중단됐고, 6월 첫째 주에 마무리됨
  • 실제 투입 시간은 하루 몇 시간씩 총 2~3주 수준이며, 대부분은 백그라운드 실행을 조율하거나 통합하거나 문제를 찾는 시간이었음
  • 최종 코드 규모는 360,000 LOC 이상임
    • grit-lib는 약 100,000 LOC임
    • grit-cli는 약 260,000 LOC임
    • 헤더를 제외한 C Git 코드 규모와 대략 비슷함
  • 결과물은 500개 이상 pull request와 7,000개 이상 커밋을 거쳐 만들어짐
  • 테스트 결과는 42,001개 중 41,715개 통과, 통과율 99.3%임
  • 프로젝트 홈페이지는 https://grit-scm.com임

함께 보면 좋은 글 β

carnoxen   [-]

https://writings.hongminhee.org/2026/03/legal-vs-legitimate/

라이선스 논란을 보니 이전 사건이 떠오르는군요

답변달기
GN⁺   [-]
Hacker News 의견들

  • “LLM이 만든 코드를 검토해 보니, 구현을 라이브러리화하고 메모리 안전하게 만들려면 꽤 크고 광범위한 아키텍처 변경이 필요했기 때문에, 이 코드베이스는 GPL을 이어받아야 하는 파생 저작물이 아니라고 판단했고 MIT로 공개하기로 했다”는 대목은 흥미로운 쟁점이 될 듯함

    • 책을 다른 언어로 번역하면 파생 저작물이고, 컴퓨터 프로그램을 다른 프로그래밍 언어로 번역해도 마찬가지라고 봐야 함
      다만 책을 번역하면서 줄거리와 인물 성격까지 바꾸기 시작하면 어느 순간 파생 저작물이 아니게 되는지 애매해짐. 법률가는 아니지만, 창작물 관련 판례에서 이런 경계는 꽤 다뤄졌을 것 같음
      현재처럼 “지식재산” 범위가 계속 넓어지는 분위기에서, LLM이 Git 소스 코드에 접근했다는 사실을 인정한다면 법적 입지는 약해 보임
    • 여기에는 아마추어 법률가들의 흥미로운 해석이 많지만, 내 입장은 재구현이 보호받는 표현을 복사하지 않았다는 것임
      Jplag 기준 코드베이스 간 최대 유사도가 1.8% 미만이고, 선의로 진행됐으며, Git 생태계 전체에도 이롭다고 봄. 물론 Grit이 실제로 쓸 만해진다는 전제가 필요하고, 지금은 그렇게 주장할 단계가 아님
      저작권 관점에서는 이 중 첫 번째 논점만 관련 있음. Grit은 Git 호환 동작을 독립적으로 작성한 구현이고, Git 소스 코드와의 유사성은 무시해도 될 정도라고 봄
      antirez가 상황을 잘 정리했고 대체로 동의함: https://antirez.com/news/162
      지난 20년 동안 Git과 오픈소스 커뮤니티에서 나를 알고 함께 일한 사람들은 내 의도가 기여, 공유, 혁신과 학습의 촉진이라는 걸 알 것임. Git 소스의 주요 작성자들 중 여럿은 내 친구이고, 누군가에게서 무언가를 훔칠 의도는 전혀 없음. 훌륭한 아이디어를 더 널리 유용하게 만들고 싶을 뿐임
    • 이 판단은 그냥 틀렸다고 봄. 소송 자격이 있는 누군가가 소송을 걸었으면 함
    • 관련 글: Malus – Clean Room as a Service
      https://news.ycombinator.com/item?id=47350424
      1984나 Torment Nexus 때처럼, 누군가가 경고로 받아들여야 할 개념을 사용 설명서로 받아들인 셈임
    • 자신이 모르는 것을 아는 능력은 인생과 커리어에서 아주 중요함. 저자가 제정신이 아니라는 데 100% 동의함
      예를 들어 N64의 Goldeneye 바이너리를 추출해 LLM으로 디스어셈블하고 현대적인 고수준 언어로 다시 쓰게 했다고 해보자. Nintendo가 “노력을 많이 했으니 우리 라이선스를 벗어났군”이라고 할까? 당연히 아님. 말이 안 됨
      소스 코드를 먹이고 다른 언어로 결과물을 만들게 하는 건 명백히 파생 저작물임. 지식재산권 변호사가 아니어도 알 수 있음
      반대로 Claude에 문서만 주고 호환 구현을 만들라고 하면 GPL 적용을 받는 파생 저작물일까? 아마 그럴 것 같지만 이제 100% 확신은 못 하겠고, 위험을 감수하진 않을 것임
      또 다른 사고실험으로, 누군가 이 “MIT 라이선스” 소스 트리를 다른 LLM에 넣고 C로 출력하라고 하면 라이선스는 어떻게 될까? SHA1 해시를 만들거나 명령줄 파서를 만드는 방식은 한정돼 있으니 꽤 비슷해질 수 있음
      Oracle v. Google 사건에서도 이게 핵심 쟁점 중 하나였음. Google은 반복문을 쓰는 방법은 제한적이므로 원본과 비슷한 반복문이 있다고 곧바로 저작권 침해는 아니라고 주장해 성공했음
      어쨌든 이런 입장을 취하는 건 정말 무리임

  • 이해가 안 됨. Gitoxide가 이미 있고 훌륭함
    빠진 부분이 있을 수는 있지만, 유지보수되는 Gitoxide에 필요한 네트워킹 기능을 바이브 코딩으로 추가하는 편이 Git 전체를 다시 복제하려고 토큰을 태우는 것보다 쉬움
    Git은 Rust 추가를 원하고, Gitoxide는 다년간 이어진 프로젝트라 “테스트 통과한다고 말하는” 즉흥 바이브 클론보다 유지보수가 더 잘될 가능성이 큼
    유용한 경우라면 바이브 클론 자체를 반대하지 않지만, 이번 건 장점이 보이지 않음. Git은 많은 사람이 좋아하는 도구이지, Next.js의 벤더 종속을 싫어해서 나온 vinext 같은 상황이 아님
    경영진도 “우리가 사랑받는 소프트웨어를 우리 사본으로 만들려고 토큰에 수천 달러를 태웠다”는 이야기가 저작권·라이선스 논쟁을 빼도 커뮤니티에 긍정적으로 받아들여질 만한 일이 아니라는 걸 알아야 함
    좋아하는 작품이 아무 이득 없이 복제되는 걸 보는 건 기분 좋지 않음. 이제 “AI가 어디까지 갈 수 있는지 보려는 실험” 단계는 지났음

    • 언급했듯 우리도 Gitoxide 프로젝트에 참여하고 있고, Byron도 우리 팀원임. 커뮤니티의 큰 노력들은 잘 알고 있으며 올해 Git Merge 컨퍼런스도 공동 주최함
      최근 Gitoxide에 Git 기능을 더 바이브 루프로 넣으려는 시도가 있고 흥미로움: https://github.com/GitoxideLabs/gitoxide/pull/2538
      그래도 이 프로젝트는 조금 더 작업하면 가치가 있을 수 있다고 봄. 이번 발표는 최종 제품이 아니라 이정표일 뿐임. 프로젝트 중반에도 이게 가능할지 확신하지 못했음
      배운 것도 많고 앞으로 배울 것도 많지만, 고품질의 손으로 만든 견해가 뚜렷한 부분적 Git 라이브러리인 Gix와, 바이브로 만든 완전 구현에 가깝지만 다소 엉성한 LLM Git 라이브러리인 Grit은 둘 다 유용한 적용처가 있을 수 있음. 당분간 두 선택지를 모두 탐색하고 투자할 가치가 있다고 봄
      또한 나는 관여한 경영진이고, 지난 세월 Git 커뮤니티를 위해 꽤 많은 일을 해왔음. 내 “자체 사본”을 가지려 한다는 건 말도 안 됨
      Pro Git 책(https://git-scm.com/book/en/v2)과 그 전의 Git community book(https://schacon.github.io/gitbook/index.html)을 쓰고 오픈소스로 공개했고, 공식 Git 웹사이트(https://git-scm.com)를 만들었으며, 전 세계 거의 모든 오픈소스를 호스팅하는 GitHub를 공동 창업했고, 거의 20년 동안 Git 생태계를 전파하고 지원해왔음
      15년 전에는 libgit2 개발을 다시 시작하고 자금을 댔는데, 이것도 더 관대한 라이선스로 Git의 “자체 사본”을 가지려는 경영진이라고 주장할 수 있겠지만, 그런 주장도 똑같이 황당함
    • GitButler가 지금 gitoxide 유지관리자를 고용했거나 함께 일하고 있는 걸로 알고 있음. 그러니 분명 알고 있을 것임
      아마 gitoxide가 자신들의 사용 사례에 충분하지 않거나, 확장·개선 비용이 너무 크다고 판단했을 듯함

  • 메모리 안전성 같은 건 좋지만, 솔직히 이게 어떤 사용 사례를 위한 건지 모르겠음
    에이전트식 개발을 보여주려는 건가? 10년 넘게 Git을 쓰면서 메모리 오버플로 등으로 실패한 적이 없음. 어떤 소프트웨어는 “그대로도 충분히 좋다”에 해당하고, Git이 거기에 속한다고 꽤 확신함
    20명 넘는 개발자와 많은 바이너리 산출물을 다루는 팀에서도 Git의 한계에 부딪힌 적이 거의 없음. Git의 한계를 정말 밀어붙이는 상황이라면 Git에서 벗어나야 할 수도 있고, Rust 재작성은 아무 도움도 안 됨. 그래서 다시 묻고 싶음, 왜?

    • 글에서 이미 답했지만, Git에는 링크 가능한 라이브러리가 없고 예전부터 없었음
      작은 일을 하려 해도 프로세스를 fork/exec하고 stdin/stdout으로 통신해야 함. 아니면 완전히 재구현하고 모든 예외 상황을 처리해야 함
      예를 들어 객체 하나를 읽는 것도 loose 객체면 쉽지만 packfile 안에 있으면 훨씬 어려움. 참조를 읽는 것, 즉 브랜치가 어떤 SHA를 가리키는지 확인하는 것도 loose 파일, packfile, reftable 중 하나일 수 있음
      이걸 CLI 용도로 쓸 사람은 없을 것임. 안정화하더라도 거의 확실히 항상 더 느리고 모든 면에서 더 나쁠 것임. 현재는 안정적이지도 않음
      libgit2나 Gitoxide를 쓸 수 있고, 둘 다 내가 시작을 도왔거나 GitButler가 현재 추진을 돕는 프로젝트임. 거의 모든 면에서 더 빠르고 좋지만 기능이 완전하지는 않음
      이건 Git을 사용하는 사람을 위한 게 아니라, Git의 일부를 쓰려는 도구를 만들 사람을 위한 것임
    • 라이선스 세탁임
    • 이렇게 하지 않고서야 어떻게 Git 라이선스를 세탁하고, 나중에 미끼와 전환을 준비하겠음?

  • 이제 누구나 자기 LLM 클론은 파생물이 아니라고 정하면 되니 소프트웨어 라이선스는 의미가 없어진 것 같음

    • 지금은 프로젝트를 다른 언어로 번역하고 라이선스를 바꿔도 괜찮다는 식으로 행동하는 사람이 있음
      최근 Casey Muratori가 비슷한 맥락에서, Microsoft의 AI 추진은 그들이 오래되고 방대한 코드베이스를 갖고 있다는 점과 관련 있을 수 있다고 말했음. 오래된 대형 소프트웨어 회사는 모델 학습에서 이점이 있고, 자신들의 지식재산으로 추가 가치를 제공할 수 있음
      그런데 이제 그 지식재산이 모델 안에 들어가고 누구에게나 접근 가능해질 수 있음. 실제로 자기 지식재산으로 모델을 학습시킨다면, 누구든 그 API를 구현하고 GPL 라이선스를 붙일 수도 있음
      그 시점부터는 정말 흥미로워질 것임
    • 거의 모든 FOSS 저작권자가 위반자를 고소하지 않으니, 라이선스는 이미 꽤 의미가 약했음

  • 이건 GPL 코드의 표절이자 라이선스 세탁임
    테스트 스위트에서 역으로 작업하는 건 이해할 수 있지만, 이건 말 그대로 원본 소스를 읽음: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
    LLM 사용자들은 고정돼 있지 않은 건 전부 훔치고 자기 작업인 것처럼 내세워도 된다는 다른 세계에 사는 것 같음

    • 나는 다르게 봄. 같은 접근으로 내가 이 코드를 직접 작성했다고 생각해 보면 됨. 문서를 보고, 테스트를 보고, 소스를 보고, 상호운용 가능하지만 접근법은 매우 다른 구현을 만드는 것임
      예를 들어 GitButler에서 SSH 커밋 서명을 제대로 동작하게 하려고 했을 때 정확히 그렇게 했음: https://blog.gitbutler.com/signing-commits-in-git-explained
      글에서 볼 수 있듯 정석 동작을 알아내려고 C 소스를 파고든 뒤, 같은 일을 Rust로 구현했지만 소스 코드를 복사하지는 않았음
      Grit의 Rust 소스와 Git 소스 사이에 일부 유사성은 있지만, 대부분 시간·서식 처리나 packfile 파싱 등에 필요한 바이트 오프셋 같은 부분임. 내가 보기에는 직접적인 코드 복사는 없음
      이걸 재진입 가능하고 메모리 안전하며 라이브러리 중심의 코드베이스로 만들려면 접근법 자체가 너무 달라서 복사가 대체로 유용하지 않음
      하지만 packfile이나 reftable의 바이너리 형식은 제대로 문서화돼 있지 않아서 누구도 추측으로 맞힐 수 없음. 내가 아마 packfile 바이너리 형식을 문서화하려 시도한 몇 안 되는 사람 중 하나이기 때문에 잘 알고 있음: https://schacon.github.io/gitbook/7_the_packfile.html
      소스를 읽을 수밖에 없음. 이 정의대로라면 libgit2, Gitoxide, 그 밖의 모든 Git 재구현도 기술 명세를 확인하려고 Git 소스를 참고해야 했으니 전부 “라이선스 세탁”이 됨
      Grit 안에서 명백히 줄 단위로 복사된 코드를 찾으면 알려달라. 교체하겠음. 하지만 Git 소스가 곧 Git 명세이고, LLM 여부와 상관없이 모든 재구현은 호환성을 만들려면 이런 접근을 강제당함
    • 이게 큰 집단에게 받아들여질 수 있는 것처럼 보인다는 게 두려움
      다른 지식재산 보유자들, 예컨대 가치 있는 독점 소프트웨어나 음악, 영화, 심지어 LLM 자체를 가진 이들이 다음 차례로 표범이 얼굴을 먹으러 올 것이라고 생각하지 않는다는 게 이해되지 않음
      지식재산의 이런 침식은 멈춰야 함. 그렇지 않으면 지적 노동을 하는 사람은 누구나 완전히 망함. FOSS 사람들에게만 해당한다면 욕조 물과 함께 버려질까 걱정하겠지만, 이건 분명 전반에 적용되는 문제임
    • 잘 모르겠지만, 원본 소스 코드 전체가 학습 데이터에도 들어가 있지 않았을까?

  • “지니에게 소원을 비는 것과 비슷하다. 기본 규칙을 정말 명확히 해야 한다”는 비유를 전에도 써본 적 있음
    예전에는 골렘에 더 가까운 느낌이었는데, Fable의 방해 모드 https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html 때문에 이제 확실히 지니에 가까워 보임
    예전에는 “모델은 당신이 원하는 것이 아니라, 당신이 요청한 것을 준다”고 표현했음. 이제 Fable에서는 원하는 것도 주지 않으니 잘 모르겠음

  • 실험 목적이라면 오히려 반대 방향이 궁금함. 이런 프로젝트들은 대체로 “성능”을 위해 다시 쓰는 것처럼 보이고, AI 덕분에 비용이 낮아졌기 때문일 것임
    Quake III를 Python으로 포팅하거나 Kubernetes를 Perl로, 심지어 Rails를 Python으로 옮기는 식의 괴상하지만 재미있는 작업을 보고 싶음

    • Quake III를 Python으로는 아마 가능할 듯함
      Natural Selection 2의 대부분이 Lua였던 걸로 기억하고, 그것도 이미 10년도 더 된 일임
    • “성능”을 위한 재작성이라고 하지만, 정작 이건 성능이 훨씬 나쁨
      더 느리고, 테스트가 부족하고, 불완전한 Git 구현을 단돈 1만~1만5천 달러에 만든 셈임
      그 과정에서 사람 시간도 꽤 낭비했음
      다른 곳에서 이미 어느 그룹이 Rust 포트를 하고 있다는 이야기도 있었음. 이 정도 돈과 소프트웨어 개발 자원을 거기에 썼다면 얼마나 많은 걸 해냈을까?
      AI가 충분히 철저히 테스트하지 않으면 무언가를 포팅할 수 있어 보인다는 건 이미 증명된 것 같음. 이제 이런 종류의 일에서 점점 가치를 덜 느낌. 저자에게는 재미있었겠지만, 다른 사람들에게는 어떻게 도움이 되는지 모르겠음
    • 정말 성능 때문이었다면 원래 라이선스를 썼을 것임. 하지만 그러지 않았음
      전체 RiiR 운동은 사용자에게 유리한 라이선스인 GPL에서 벗어나려는 움직임이 아주 분명함

  • “꽤 재미있는 실험이고, 커뮤니티 전체에 정말 유용한 무언가로 다듬을 수 있다고 생각한다”의 앞부분에는 동의함. 실험은 다 같이 즐겨도 됨
    하지만 “링크 가능하고 재진입 가능한 라이브러리가 아니라, 더 단순한 명령들을 이어 붙이는 Unix 철학에 기반했기 때문에 장기 실행 프로세스에서 매번 fork/exec 오버헤드 없이 쓰기 어렵다”는 부분에서 철학적 이견이 생김
    글 전체에서 “왜”를 말하는 유일한 대목인데, Unix 방식은 기능이고 지금은 오히려 더 중요하다고도 볼 수 있음: https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic

    • 인용을 편하게 잘라냈음
      “링크 가능하고 재진입 가능한 라이브러리가 아니라, 더 단순한 명령들을 이어 붙이는 ‘Unix’ 철학에 기반했기 때문에, 모든 작업에 fork/exec 오버헤드 없이 장기 실행 프로세스에서 쓰기 어렵다”는 문장 전체가 핵심임
    • Git은 이미 libgit 위의 인터페이스 아닌가? 그게 뭐가 다른지 모르겠음

  • Git을 15년 넘게 쓰면서 단 한 번도 크래시를 겪지 않았음. 대체 무슨 문제를 해결하는 건가?

    • 기능이 완전하고, 재진입 가능하며, 링크 가능한 라이브러리를 만들려는 것임. 이런 질문에는 글을 읽는 게 도움이 될 때가 많음
    • 해결하려는 건 사용자에게 유리한 라이선스인 GPL임
    • 수년간 크래시는 꽤 봤음. 주로 어떤 비공개 저장소에서 gc와 pruning이 일정 기간 동안 예기치 않은 종료를 일으켰음
      그래도 전반적인 안정성은 정말 훌륭했음. 다만 이 특정 재작성의 “왜?”에는 답할 수 없음
    • LLM 때문에 자신에게 초능력이 생겼다고 믿는 LLM 정신증 같은 문제가 있음
      이들은 완전히 무자각하게 순진하게 일을 벌이고, 스스로 생각하는 능력을 잃었음. 대신 생각해 주는 LLM은 “X를 하는 건 나쁜 생각”이라고 말해주지 않음. LLM은 소유자를 위해 가능한 한 많은 토큰을 생산하도록 존재함

  • 이건 GitHub 공동창업자에게서 나온 일이고, GPL이 무엇을 위한 것인지 정확히 알 가능성이 큰 사람임
    법적 장단점이 어떻든, GPL3 프로젝트의 전체 테스트 스위트 위에 구축하고 MIT로 다시 라이선스하는 건 원저자들에게 선의로 행동하는 것이 아님
    정말 역겹고 GitButler 전체를 피하고 싶어짐

    • GPL 라이선스의 테스트 스위트를 GPL이 명시적으로 허용한 특정 목적에 사용하는 자유를 믿지 않는다는 뜻으로 들림
      라이선스를 골라놓고 마음에 안 든다고 나중에 추가 조건을 붙일 수는 없음. 그건 GPL 라이선스가 명시적으로 허용하지 않는 일임
답변달기