리눅스 커널의 전체 Git 히스토리를 PostgreSQL 기반 Git 서버에 넣어봤다

Git 저장소를 통째로 데이터베이스에?

한 개발자가 리눅스 커널의 전체 Git 히스토리를 pgit이라는 PostgreSQL 기반 Git 구현체에 임포트하는 데 성공했어요. 리눅스 커널이라면 Git 역사상 가장 크고 오래된 프로젝트 중 하나인데요, 약 120만 개 이상의 커밋, 수만 명의 기여자, 30년 가까운 역사를 가진 거대한 저장소를 통째로 PostgreSQL 데이터베이스에 넣었다는 거예요.

pgit이 뭔지 먼저 설명하면, 일반적으로 Git은 파일 시스템 위에서 동작해요. .git 폴더 안에 커밋, 트리, 블롭(파일 내용) 같은 객체들을 파일로 저장하죠. pgit은 이 저장 계층을 PostgreSQL 데이터베이스로 바꾼 거예요. Git의 모든 객체(커밋, 트리, 블롭, 태그)를 데이터베이스 테이블에 저장하고, 표준 Git 프로토콜을 통해 접근할 수 있게 만든 프로젝트예요.

왜 이런 걸 만들었을까?

"Git이 잘 되고 있는데 왜 굳이 DB에 넣어?"라고 생각할 수 있는데, 실은 꽤 흥미로운 이유가 있어요. Git 데이터가 데이터베이스에 들어가면 SQL로 쿼리할 수 있게 되거든요. 예를 들어 "특정 개발자가 최근 6개월간 가장 많이 수정한 파일 목록"이나 "특정 디렉토리의 커밋 빈도 변화 추이" 같은 걸 SQL 한 줄로 뽑아낼 수 있어요.

일반 Git 명령어로도 이런 분석이 가능하긴 한데, 복잡한 분석을 하려면 git log를 파이프로 연결해서 awk, sed, sort, uniq 같은 도구들을 조합해야 해요. 반면 SQL은 이런 집계와 필터링에 최적화되어 있으니까, 코드 고고학(code archaeology)이나 프로젝트 분석을 할 때 훨씬 강력한 도구가 되는 거죠.

리눅스 커널 정도의 규모를 임포트할 수 있다는 건 pgit의 확장성을 증명하는 의미도 있어요. 실제로 이 정도 규모의 저장소를 처리하려면 대량의 Git 객체를 효율적으로 파싱하고 데이터베이스에 벌크 인서트하는 과정이 필요한데, packfile 파싱이나 delta 해제(Git은 공간 절약을 위해 객체 간 차이만 저장하는 delta compression을 쓰거든요) 같은 저수준 Git 내부 구현을 제대로 처리해야 해요.

비슷한 프로젝트들과 비교

Git 데이터를 SQL로 분석하겠다는 아이디어는 사실 새로운 건 아니에요. gitqlite는 Git 저장소를 SQLite 가상 테이블로 노출해서 SQL 쿼리를 할 수 있게 해주는 도구예요. MergeStat도 비슷한 접근인데, 좀 더 분석 플랫폼에 가깝고요. go-git은 Go로 구현된 Git 라이브러리인데, 다양한 저장 백엔드를 지원해요.

pgit이 이들과 다른 점은, 단순히 읽기 전용 분석 도구가 아니라 실제 Git 서버로 동작할 수 있다는 거예요. git clone, git push, git fetch 같은 표준 Git 명령어로 이 서버와 통신할 수 있다는 뜻이에요. 이건 Git의 저장 계층을 완전히 대체할 수 있는 가능성을 보여주는 거라 기술적으로 꽤 흥미로워요.

한국 개발자에게 주는 시사점

실무에서 당장 pgit으로 Git 서버를 교체할 일은 아마 없을 거예요. 하지만 이 프로젝트에서 배울 수 있는 게 몇 가지 있어요. 첫째, Git 내부 구조를 이해하는 좋은 교재가 될 수 있어요. Git의 객체 모델(커밋, 트리, 블롭, 태그)이 실제로 어떻게 생겼고 서로 어떻게 연결되는지를 데이터베이스 스키마로 보면 훨씬 직관적으로 이해할 수 있거든요.

둘째, 대규모 프로젝트의 코드 분석이나 메트릭 수집을 해야 하는 상황이라면 이런 접근을 참고할 수 있어요. 예를 들어 "우리 팀의 코드 변경 패턴을 분석해서 리팩토링 우선순위를 정하자" 같은 작업을 할 때, Git 데이터를 DB에 넣고 SQL로 분석하는 게 셸 스크립트를 짜는 것보다 편할 수 있어요.

셋째, 이 프로젝트는 사이드 프로젝트의 좋은 예시이기도 해요. "기존 시스템의 한 계층을 다른 기술로 바꿔보면 어떨까?"라는 호기심에서 시작해서, 실제로 동작하는 것을 만들고, 극한의 스케일(리눅스 커널!)로 테스트해본 거잖아요.

마무리

Git의 저장소 데이터를 SQL로 다룰 수 있다는 건 단순한 기술적 재미를 넘어서, 코드 분석과 프로젝트 관리에 새로운 가능성을 열어주는 아이디어예요. 여러분이 관리하는 저장소의 Git 히스토리를 SQL로 마음껏 쿼리할 수 있다면, 가장 먼저 어떤 질문을 던져보고 싶으세요?