법 개정안은 사실 ‘패치 파일’이에요
혹시 법률 개정안 원문을 읽어본 적 있으세요? 처음 보면 꽤 당황스러울 거예요. 바뀐 법 전체가 적혀 있는 게 아니라 “제5조 제2항 중 ‘30일’을 ‘60일’로 한다” 같은 문장만 잔뜩 나열돼 있거든요. 개발자 눈으로 보면 이건 딱 패치(patch) 파일이에요. 원본 파일이 따로 있고, 거기에 적용할 변경 사항만 적어둔 거죠. 문제는 이 패치를 사람이 머릿속으로 직접 적용해야 한다는 점이에요.
미국도 똑같아요. 의회를 통과한 법안은 대부분 “Section 101(a)는 ‘X’를 삭제하고 ‘Y’를 삽입하는 것으로 개정한다” 같은 수정 지시문(amendatory instructions)으로 쓰여 있어요. 이번에 소개할 글은 바로 여기서 출발해요. 미국 연방법전(US Code)을 Git 저장소처럼 다뤄서, 법이 바뀐 이력은 커밋으로, 개정 내용은 diff로 보자는 거예요.
US Code는 어떻게 생겼나
US Code가 뭐냐면, 미국 연방 법률을 주제별로 정리해둔 거대한 법전이에요. 50개가 넘는 Title(편)로 나뉘어 있는데, 예를 들어 Title 26은 세법이고 Title 17은 저작권법이에요. 관리는 미국 하원 산하 법률개정자문실(Office of the Law Revision Counsel, OLRC)이 맡고 있어요. 새 법이 통과될 때마다 그 내용을 법전에 반영하고, 특정 시점의 스냅샷을 release point라는 이름으로 공개해요. 게다가 USLM(United States Legislative Markup)이라는 XML 포맷으로 기계가 읽을 수 있게 제공하고 있고요.
여기까지 들으면 감이 오시죠? 시간순으로 스냅샷이 쌓여 있으니까 그대로 Git 커밋 히스토리로 바꿀 수 있다는 뜻이에요.
Git으로 옮기면 뭐가 달라질까
매핑은 대략 이렇게 생각해볼 수 있어요.
- release point → 커밋: 법전이 갱신된 시점 하나하나가 커밋이 돼요.
- 반영된 법률(Public Law 번호) → 커밋 메시지: 어떤 법 때문에 바뀌었는지가 기록돼요.
- Title/Chapter/Section → 디렉터리와 파일: 조항 하나가 파일 하나가 되는 식이에요.
git log -- title-26/ 하면 세법이 바뀌어 온 역사가 쭉 나오고, git blame을 돌리면 특정 문장이 언제 어떤 법으로 들어갔는지 한 줄 단위로 알 수 있어요. 두 시점 사이에 git diff를 걸면 ‘2015년 저작권법과 지금 저작권법은 정확히 뭐가 다르지?’ 같은 질문에 바로 답할 수 있고요.물론 생각보다 까다로운 부분도 있어요. XML을 그대로 넣으면 태그나 속성이 바뀔 때마다 diff가 지저분해지니까, 사람이 읽을 수 있는 텍스트로 정규화하는 단계가 필요해요. 법 하나가 여러 Title을 동시에 건드리는 경우가 많아서 커밋 하나가 수십 개 파일에 걸치기도 하고, release point 하나에 여러 법이 한꺼번에 반영되면 ‘커밋 하나 = 법 하나’라는 깔끔한 구조가 깨지기도 해요. 조항마다 시행일이 다른 것도 골치 아픈데요, Git으로 치면 브랜치나 태그를 어떻게 설계할지의 문제예요.
법을 Git에 넣으려는 시도는 처음이 아니에요
사실 꽤 오래된 아이디어예요. 2012년쯤 독일에서는 연방 법률을 마크다운으로 바꿔 GitHub에 올린 bundestag/gesetze 프로젝트가 나왔고, 프랑스에서도 법전을 Git 히스토리로 재구성한 시도가 있었어요. 제일 재밌는 사례는 미국 워싱턴 DC예요. DC는 아예 자기 법전을 공식적으로 GitHub에 올렸고, 2018년에는 한 시민이 법전의 오타를 고치는 Pull Request를 보내서 실제로 반영되기도 했어요. 법전에 PR을 보낸다니, 개발자 입장에선 꽤 낭만적인 이야기죠.
요즘 이 주제가 다시 중요해진 건 법률 AI 때문이에요. LLM에게 “2019년 기준으로 이 계약이 유효했어?”라고 물었는데 현행법으로 답하면 틀린 답이 되거든요. RAG(검색 증강 생성, 쉽게 말해 AI가 답하기 전에 관련 문서를 먼저 찾아보게 하는 방식)를 할 때도 ‘어느 시점의 법’인지가 정확해야 해요. 이 글을 쓴 Lexifina처럼 법률 기술을 다루는 팀한테는 시점별로 정확하게 버전 관리된 법률 데이터가 일종의 기반 인프라인 셈이에요.
한국 개발자에게 주는 시사점
한국은 이 분야에서 꽤 좋은 환경이에요. 국가법령정보센터에 있는 ‘신구조문대비표’가 사실상 법률판 diff 뷰거든요. 법제처는 법령 데이터를 Open API로도 제공하고 있어서, 마음만 먹으면 주말 사이드 프로젝트로 ‘대한민국 법령 Git 저장소’를 만들어볼 수 있어요. 데이터 파이프라인, 텍스트 정규화, 버전 관리 설계를 한 번에 연습할 수 있는 좋은 주제예요.
실무에서도 쓸 데가 많은 패턴이에요. 서비스 이용약관, 개인정보처리방침, 사내 규정처럼 ‘언제 뭐가 바뀌었는지’가 중요한 문서는 전부 같은 방식으로 관리할 수 있어요. 외부 웹페이지를 주기적으로 긁어와 Git에 커밋해서 변경 이력을 남기는 ‘git scraping’ 기법도 같은 맥락이고, 데이터 자체를 Git처럼 다루는 Dolt 같은 도구도 있으니 같이 찾아보세요.
마무리
핵심 한 줄: 법률도 결국 버전 관리가 필요한 텍스트이고, Git은 그 문제를 이미 잘 풀고 있는 도구예요.
여러분이라면 법률 Git 저장소의 커밋 단위를 ‘법 하나’로 잡을 건가요, ‘시행일’로 잡을 건가요? 한국 법령으로 이런 프로젝트를 만든다면 어떤 기능을 제일 먼저 넣고 싶으세요?
🔗 출처: Hacker News