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

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

책을 다른 언어로 번역하면 파생 저작물이고, 컴퓨터 프로그램을 다른 프로그래밍 언어로 번역해도 마찬가지라고 봐야 함
다만 책을 번역하면서 줄거리와 인물 성격까지 바꾸기 시작하면 어느 순간 파생 저작물이 아니게 되는지 애매해짐. 법률가는 아니지만, 창작물 관련 판례에서 이런 경계는 꽤 다뤄졌을 것 같음
현재처럼 “지식재산” 범위가 계속 넓어지는 분위기에서, LLM이 Git 소스 코드에 접근했다는 사실을 인정한다면 법적 입지는 약해 보임

여기에는 아마추어 법률가들의 흥미로운 해석이 많지만, 내 입장은 재구현이 보호받는 표현을 복사하지 않았다는 것임
Jplag 기준 코드베이스 간 최대 유사도가 1.8% 미만이고, 선의로 진행됐으며, Git 생태계 전체에도 이롭다고 봄. 물론 Grit이 실제로 쓸 만해진다는 전제가 필요하고, 지금은 그렇게 주장할 단계가 아님
저작권 관점에서는 이 중 첫 번째 논점만 관련 있음. Grit은 Git 호환 동작을 독립적으로 작성한 구현이고, Git 소스 코드와의 유사성은 무시해도 될 정도라고 봄
antirez가 상황을 잘 정리했고 대체로 동의함: https://antirez.com/news/162
지난 20년 동안 Git과 오픈소스 커뮤니티에서 나를 알고 함께 일한 사람들은 내 의도가 기여, 공유, 혁신과 학습의 촉진이라는 걸 알 것임. Git 소스의 주요 작성자들 중 여럿은 내 친구이고, 누군가에게서 무언가를 훔칠 의도는 전혀 없음. 훌륭한 아이디어를 더 널리 유용하게 만들고 싶을 뿐임

자신이 모르는 것을 아는 능력은 인생과 커리어에서 아주 중요함. 저자가 제정신이 아니라는 데 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 저작권자가 위반자를 고소하지 않으니, 라이선스는 이미 꽤 의미가 약했음

나는 다르게 봄. 같은 접근으로 내가 이 코드를 직접 작성했다고 생각해 보면 됨. 문서를 보고, 테스트를 보고, 소스를 보고, 상호운용 가능하지만 접근법은 매우 다른 구현을 만드는 것임
예를 들어 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 사람들에게만 해당한다면 욕조 물과 함께 버려질까 걱정하겠지만, 이건 분명 전반에 적용되는 문제임

실험 목적이라면 오히려 반대 방향이 궁금함. 이런 프로젝트들은 대체로 “성능”을 위해 다시 쓰는 것처럼 보이고, 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 라이선스가 명시적으로 허용하지 않는 일임