[기고] Git으로 법령을 관리해 보니 보인 것들

Legalize-KR 프로젝트 메인테이너 박정환

• 들어가며

세상의 모든 것들은 시간이 지나며 변합니다. 하지만 무엇이, 언제, 얼마나, 어떻게 변했는지까지 기록하고 관리해야 하는 것들은 상대적으로 적습니다. 대부분의 사람들은 지나간 것들보다는 새로운 것에 관심이 많을 테니까요. 법령은 그러한 것들 중 하나입니다. 조문이 제정되고, 개정되고, 삭제되고, 가끔씩은 다른 법령의 개정으로 함께 바뀌곤 합니다. 그래서 법제처에서 제공하는 국가법령정보센터에서는 '지금 찾고자 하는 법령 그 자체'뿐만 아니라, '어떤 조항이 언제 추가되었는지', 또는 '특정 시점에는 어떠한 문구였는지', 그리고 '해당 법령이 개정 전후로 무엇이 달라졌는지' 등을 친절히 알려주고 있습니다.

소프트웨어 개발자에게 이러한 문제는 익숙합니다. 소스 코드는 계속 바뀌고, 변경 이력 자체가 중요한 의미를 갖습니다. 심지어 개발자들은 소프트웨어의 변화를 관리하기 위한 소프트웨어까지 만들어 사용하고 있습니다. 제가 처음 실무를 접했던 2000년대에는 CVS나 SVN이 있었고, 요즘은 대부분 Git을 사용하고 있습니다. `git commit`으로 변경을 기록하고, `git log`로 이력을 보고, `git diff`로 특정한 두 시점의 차이를 확인하며, `git blame`으로 한 줄의 출처를 추적합니다. Legalize-KR은 개발자에게 익숙한 도구를 대한민국 법령 데이터에 적용해 보자는 생각에서 출발했습니다. 모든 법령을 Markdown 문서로, 그리고 모든 개정 내역을 실제 날짜를 가진 Git Commit으로 남기면 법령도 코드처럼 검색하고 비교하고 활용할 수 있지 않을까 하는 실험이었습니다.

처음에는 단순한 호기심에 가까웠습니다. 스페인 법령을 Markdown과 Git으로 관리하는 legalize-dev/legalize-es 프로젝트를 접하고 흥미롭게 느꼈고, 한국 법령에도 비슷한 시도가 있을 것이라고 생각했습니다. 그런데 찾아보니 공개적으로 바로 활용할 수 있는 저장소를 찾기 어려웠습니다. 국가법령정보센터에서는 이미 훌륭한 웹 서비스를 제공하고 있지만, 여기에는 법령 정보를 읽고 비교하는 주체가 사람일 것이라는 가정이 깔려 있었습니다.

<국가법령정보센터에서 제공하는 법령 정보(왼쪽) 및 연혁(오른쪽): 자바스크립트로 다양한 기능을 제공한다>

하지만 AI 에이전트가 대규모로 법령을 읽고, 비교하고, 재현 가능한 방식으로 처리하기에는 한 단계 더 정제된 데이터가 필요했습니다. 이 글에서는 Legalize-KR 프로젝트를 시작하며 마주한 과제들과 그 이면에 숨겨진 새로운 가능성들을 정리하고자 합니다. 프로젝트의 기술적인 부분에 대한 설명보다 인공지능이 주도하는 시대에 공공 데이터가 지향해야 할 바람직한 형태와 더불어, 민간과 공공 부문이 상호 보완하며 나아가야 할 협력의 방향성에 대한 제언을 함께 담으려 합니다.

• 공개된 것과 활용 가능한 것의 차이

대한민국 법령 정보는 이미 잘 정리되어 있고, 공개되어 있습니다. 국가법령정보센터는 법령과 판례 외에도 행정규칙과 자치법규 등 방대한 법률 정보를 제공하고 있으며, OpenAPI를 통해 기계가 접근할 수 있는 방법도 제공하고 있습니다. 애초에 Legalize-KR 프로젝트를 시작할 수 있었던 것도 이러한 공공 데이터가 있었기 때문입니다. 이는 분명히 지난 시간 동안 많은 사람들의 관심과 노력이 있었기에 가능한 것이며, 중요한 성과입니다. 공공 데이터가 닫혀 있었다면 개인 개발자가 이러한 실험적인 프로젝트를 시작조차 할 수 없었을 것입니다.

하지만 공개되어 있다는 사실이 곧바로 활용 가능하다는 뜻은 아니었습니다. 사람이 웹사이트에서 검색하고 읽기에는 충분한 데이터임에 분명하지만, 전체 개정 내역을 내려받아 시점별로 복원하거나 수십만 건의 문서를 일관된 규칙으로 변환하려고 하면 여러 가지 예상하지 못한 문제들을 마주하게 됩니다.

첫째, 현재 시점의 조회와 전체 이력의 분석은 다른 문제입니다. 법령 포털은 특정 법령의 현행 조문을 확인하는데 매우 유용하며, 지난 개정과의 비교 또한 용이합니다. 하지만 임의의 두 시점 사이에서 조문이 어떻게 달라졌는지, 특정한 표현이 언제 처음 등장했는지, 어느 기간 동안 어떠한 법령들에서 동시에 변화가 있었는지 등을 분석하기 위해서는 데이터의 시간축이 필요합니다. 웹 사이트에서 여러 화면을 오가며 확인하는 것은 가능하지만, 자동화와 대규모 분석에는 적합하지 않았습니다.

둘째, 원천 데이터에는 법령 특유의 구조와 예외가 많습니다. 원천 데이터는 조문, 항, 호, 목뿐 아니라 편, 장, 절, 관 같은 상위 구조가 있고, 일부 문서에는 항, 속, 목 같은 묶음 표제가 별도의 방식으로 사용되고 있었습니다. 오래된 판례에는 단기 연호가 남아 있고, 일부 법령에는 1970-01-01, 즉 Unix Epoch 이전의 날짜가 등장합니다. Git은 1970년 이전의 일자를 그대로 다루지 못하므로 실제 공포일자는 Markdown의 메타 정보(frontmatter)로 보존하고, Commit Date는 보정해야 합니다.

셋째, 행정조직의 개편과 함께 법령 데이터의 소관부처명과 법령 구분이 변화합니다. 부처가 통합되거나 분리되면 같은 법령의 소관부처명과 법령 구분이 변경되며, 같은 법령이 다른 파일로 갈라지거나 과거 파일의 이력이 끊어질 수 있습니다. 행정규칙의 경우에는 이러한 문제가 더 두드러집니다. 현재 기관명으로 합쳐버리면 과거의 발령 주체가 사라지고, 반대로 원천 표기를 모두 보존하면 같은 기관의 표기 흔들림이 전체 이력 관리에 퍼집니다. 어느 쪽도 단순하지 않고, 아직도 가야 할 길이 멀다고 느끼는 부분입니다.

넷째, 공개 API도 완전한 정합성을 보장하지는 않습니다. 일부 데이터는 태그가 맞지 않아 파싱에 실패하고, 판례 목록 API에서 받은 식별자가 상세 API에서는 존재하지 않는 것으로 응답하는 경우도 있습니다. 어떠한 항목은 메타데이터만 있고 본문은 비어 있으며, 어떤 항목은 첨부파일이 있는데도 본문 파서가 이를 구조화하지 못합니다. 물론 여기에는 오랜 기간 동안 켜켜이 쌓여온 공공 데이터를 OpenAPI 서비스를 제공하며 일관된 응답을 제공하려는 여러 고민들이 녹아 있을 것입니다. 어디에서 어떻게 활용하고 있는지 모르는 상태에서 원천 데이터를 변경하게 되면 또 다른 문제가 발생할 수 있을 테니까요. 이는 오히려 공공 데이터를 실제 데이터 파이프라인으로 운용할 때 필요한 검증과 오류 표면화가 얼마나 중요한지를 다시 한번 생각하게 되는 계기가 되었습니다.

Legalize-KR 프로젝트를 시작하고 2개월 남짓 개선하며 가장 먼저 배운 것은 '공개 데이터'와 'AI가 안정적으로 읽고 재사용할 수 있는 데이터' 사이에는 제법 간격이 있다는 점이었습니다. AI 시대의 공공 데이터 정책은 단순히 API를 열어두는 것을 넘어, 변경 이력, 식별자, 구조, 첨부자료, 오류 상태까지 함께 다루어야 합니다.

• 왜 Markdown과 Git인가

Legalize-KR의 기술 선택은 복잡하지 않습니다. 본문은 Markdown으로 변환하고, 변경 사항은 Git Commit으로 남깁니다. Markdown은 사람이 읽기 쉽고, AI 모델도 안정적으로 처리할 수 있으며, 전용 프로그램 없이도 일반적인 텍스트 편집기와 웹에서 바로 확인할 수 있습니다. 또한 Git은 텍스트 데이터의 변화 이력을 저장하고 비교, 관리하는데 있어 이미 검증된 도구입니다.  그리고 이러한 기술 선택이 주는 장점은 명확합니다.

첫째, 개정 이력이 명령어 한 줄로 드러납니다. 예를 들어 특정 법령 파일에 대해 `git log -- kr/민법/법률.md` 명령을 실행하면 민법이 어떤 날짜에 어떤 commit으로 바뀌었는지 확인할 수 있습니다. `git diff`를 사용하면 두 시점 사이의 문구 차이가 줄 단위로 나타납니다. 법령의 변경은 결국 텍스트의 변경이므로, 개발자들이 오랫동안 써온 도구가 그대로 작동합니다.

  <민법의 Git Log(왼쪽)와 Diff 비교(오른쪽) 화면>

둘째, 특정 시점의 법령을 재현할 수 있습니다. 법률 문제에서는 현재 조문만큼이나 과거의 조문이 중요하다고 알려져 있습니다. 특히, 어떤 행위가 일어난 시점의 법률을 적용하는 경우에는 행위 시점의 법령을 확인해봐야 합니다. 이때 Git Commit 이력이 있다면 특정 날짜 이전의 마지막 Commit을 기준으로 파일을 꺼내 볼 수 있습니다. 이는 AI 모델이 '현재 법령'과 '사건 당시의 법령'을 혼동하지 않도록 하는데 도움을 줄 수 있습니다. 

셋째, 전체 법령 데이터를 로컬에서 다룰 수 있습니다. 저장소를 복제(clone)하면 네트워크 없이도 `grep`, `ripgrep`, `git grep` 같은 도구로 법령을 검색할 수 있습니다. 원천 데이터의 API 호출 제한(rate limit)이나 서비스 장애에 덜 의존하고, 연구자나 기업은 필요한 시점의 스냅샷(snapshot)을 자체 보관할 수 있습니다. 여기에 GitHub API 기반 CLI와 MCP 서버를 활용하면 저장소 전체를 내려받지 않고도 필요한 문서를 조회할 수도 있습니다.

넷째, 변경 알림과 자동화가 쉬워집니다. 특정 법령 파일의 변경을 GitHub Actions나 웹훅(webhook)으로 감지하면 규제 모니터링 시스템을 만들 수 있습니다. 예를 들어, 개인정보나 금융, 보건의료 등과 같이 법령이나 행정규칙의 변화가 중요한 분야에서는 특정 법령과 행정규칙을 감시하고 변경이 생길 때 내부 검토 프로세스를 자동으로 시작할 수 있습니다. 기존에도 사람이 할 수 있는 일이지만, Git은 이를 소프트웨어 개발과 같은 방식으로 자동화할 수 있게 합니다.

물론 Git이 모든 문제의 답은 아닙니다. 데이터 저장소는 일반 코드 저장소와 달리 파싱 규칙이 개선되면 전체 이력을 재구성해야 할 수 있습니다. 이 경우 Commit Hash 값이 바뀌게 되어 장기 인용에는 적합하지 않습니다. Legalize-KR은 이 점을 명시하고, 법령ID나 판례일련번호 같은 원천 식별자와 날짜, 원문 URL을 함께 보존하도록 안내하고 있습니다. Git은 강력한 버전 관리 도구이지만, 공공 법률 데이터에서는 안정적 식별자와 출처 메타데이터가 함께 있어야 합니다.

• 구현 과정에서 드러난 문제들

프로젝트 초기에는 '원천 데이터를 Markdown으로 바꾸고 Git Commit하면 되는 일'처럼 보였습니다. 그러나 실제로는 변환 규칙보다 예외 처리가 더 많은 시간을 차지했습니다. 몇 가지 사례를 소개하면 다음과 같습니다.

첫 번째는 조문 구조의 문제입니다. 법령 XML에는 `<조문여부>`라는 값이 있고, 여기에는 대체로 '조문'과 '전문'이 등장합니다. 처음에는 '전문'을 단순한 본문으로 생각했지만, 실제로는 편, 장, 절, 관 같은 구조 단위도 여기에 들어오고, 원천 데이터에서 드물게 발견되는 항, 속, 목 같은 묶음 표제도 포함됩니다. 이를 잘못 처리하면 같은 조 번호가 두 번 헤더로 나타나거나, 헌법 전문이 `제0조`처럼 표시되는 문제가 생깁니다. 결국 '전문' 단위는 조문번호를 헤더로 쓰지 않고, 본문 내용이 구조 단위인지 먼저 판별해야 한다는 규칙을 세워야 했습니다.

두 번째는 파일 경로의 안정성입니다. 법령은 이름이 같아도 법령ID가 다를 수 있고, 반대로 같은 법령ID라도 정부조직 개편으로 법령구분과 소관부처 표기가 바뀔 수 있습니다. 처음에는 사람이 보기 좋은 경로가 중요해 보였지만, 시간이 지나면서 이력의 연속성이 더 중요하다는 점이 드러났습니다. 사람이 보기 좋은 파일명과 기계가 추적하기 좋은 안정적 식별자 사이의 균형을 잡아야 했습니다.

세 번째는 누락과 실패의 관리입니다. 일부 데이터가 누락된 이슈를 조사하면서, 원천 캐시는 존재하지만 변환 과정에서 빈 본문을 성공처럼 처리하거나 예외를 로그만 남기고 계속 진행하면 문제가 누적될 수 있다는 점을 확인했습니다. 데이터 파이프라인에서는 '대부분 성공'은 충분하지 않습니다. 어느 항목이 왜 실패했는지, 실패가 허용 가능한 원천 결함인지, 파서의 결함인지를 구분해 기록해야 합니다. 특히 매일 자동으로 갱신되는 파이프라인이라면 실패 목록과 검증 기준이 산출물만큼 중요합니다.

<법령에 포함된 이미지 예시: 여러 이미지에 걸쳐진 표, 한자, 수식, 이미지 등이 혼재되어 있다>

네 번째는 텍스트가 아닌 데이터입니다. 법령에는 생각보다 많은 이미지, 별표, 서식, 첨부파일이 포함됩니다. 어떤 규정은 핵심 내용이 본문 조문이 아니라 별표 PDF나 HWP에 들어 있습니다. 행정규칙과 자치법규로 범위를 넓히면 이 문제는 더 커집니다. 단순히 '본문은 첨부파일을 참조하세요'라고 표시하는 것은 최소한의 보존일 뿐, 검색 가능한 데이터로는 부족합니다. 이 문제는 원본 데이터의 무결성과 기계가 읽기 쉬운 텍스트 사이에서 적절한 절충이 필요합니다.

다섯 번째는 규모와 성능입니다. 법령 하나를 변환하는 것은 어렵지 않지만, 수만 개의 원본 XML과 수십만 건의 문서를 이력까지 포함해 재구성하는 것은 다른 문제입니다. 초기에는 전체 컴파일에 몇 시간이 걸렸지만, Rust 기반 컴파일러를 도입하고 Git Object 작성 방식을 개선하면서 전체 재구성 시간을 크게 줄일 수 있었습니다. Python 파이프라인은 수집과 캐시 갱신, 검증에 적합하고, Rust 컴파일러는 원천 데이터 캐시(cache)로부터 Git Bare 저장소를 빠르게 재구성하는 역할을 맡았습니다. 하나의 언어로 모든 문제를 해결하기보다, 데이터 흐름의 성격에 맞게 역할을 나누는 편이 유지보수에 유리했습니다.

2026년 5월 24일 현재, Legalize-KR 생태계는 법령 5,672건, 법령 개정 이력 83,722회, 판례 123,734건, 행정규칙 21,103건, 자치법규 159,867건까지 확장되어 있습니다. 수치는 기준일과 파싱 정책에 따라 달라질 수 있지만, 한 가지는 분명합니다. Legalize-KR이 다루는 법령 데이터는 몇 개의 대표 법령만 잘 정리하면 끝나는 데이터가 아니라, 살아 움직이는 거대한 공공 텍스트 시스템입니다.

• Git으로 관리하면 달라지는 것

법령을 Git으로 관리한다고 해서 법이 쉬워지는 것은 아닙니다. 법률 해석은 여전히 전문가의 영역이고, 문맥과 판례, 행정 실무, 사실관계가 함께 고려되어야 합니다. 하지만 데이터 접근 방식은 분명히 달라집니다.

첫째, 변경을 '문서'가 아닌 '이벤트' 단위로 볼 수 있습니다. 공포일자와 발령일자가 Commit Date가 되면 법령의 변화는 시간 순의 이벤트 스트림이 됩니다. 특정 기간 동안 어떤 법령군이 동시에 바뀌었는지, 행정 부처의 소관 규정이 어떠한 속도로 개정되는지, 특정 용어가 언제 확산되었는지 분석할 수 있습니다. 법률 및 정책 연구에서 시계열 분석의 문턱이 낮아질 것으로 기대합니다.

둘째, 비교가 쉬워집니다. 법령 개정은 종종 설명자료나 신구조문대비표로 제공되지만, 임의의 두 시점을 자유롭게 비교하기는 어렵습니다. Git Diff는 이 문제를 보편적인 방식으로 해결합니다. 특정 조문이 1987년과 2024년 사이에 어떻게 바뀌었는지, 시행령과 시행규칙의 변경이 법률 개정과 어떤 시간 차를 두고 따라왔는지, 지자체별 조례 문구가 어떻게 다른지 비교할 수 있습니다.

셋째, 인용과 재현 가능성이 좋아집니다. 연구자나 개발자는 특정 날짜의 데이터를 기준으로 분석한 뒤, 같은 스냅샷을 다시 불러와 결과를 재현할 수 있습니다. 다만 앞서 언급했듯이 데이터 저장소의 Commit Hash는 파싱 규칙 개선으로 바뀔 수 있으므로, 장기 보존이 필요한 경우 원천 식별자와 날짜 등을 함께 기록해야 합니다. 이는 프로젝트가 더 강화해야 할 부분이기도 합니다.

넷째, AI 활용이 구체화됩니다. AI에게 법령을 읽히려면 단순한 텍스트 덩어리보다 구조화된 문서와 출처가 필요합니다. Markdown 메타정보(frontmatter)에는 법령ID, 공포일자, 시행일자, 소관부처, 출처 URL이 들어가고, 본문은 조문 구조를 최대한 보존합니다. CLI와 MCP 서버를 통해 AI 에이전트가 특정 법령, 특정 조문, 특정 판례를 도구 호출로 가져올 수 있습니다. 이는 모델이 기억에 의존해 답하는 것이 아니라, 공개 원천 데이터에 근거해 답하도록 만드는 기반입니다.

다섯째, 공공 데이터 활용의 진입장벽이 낮아집니다. 법령 데이터가 Git과 Markdown으로 제공되면 개발자는 새로운 데이터베이스를 따로 설계하지 않아도 됩니다. 각종 법령 저장소를 복제해서 검색하고, 필요하면 JSON으로 변환하고, RAG 파이프라인에 넣고, 변경 감지를 붙이면 됩니다. 법률가가 직접 Git을 쓰기는 어려울 수 있지만, 개발자와 AI 도구가 중간 계층을 만들기 쉬워집니다. CLI 도구와 MCP를 포함하는 cli-tools 저장소와 agent-skills 저장소는 바로 이러한 중간 계층을 만들기 위한 시도입니다.

• AI가 읽기 쉬운 데이터(AI Readable Data)의 조건

최근 여러 곳에서 'AI Readable Data'라는 표현이 들려오고 있습니다. 저는 Legalize-KR을 진행하면서 이 말이 단순히 '텍스트로 되어 있음'을 뜻해서는 안 된다고 생각하게 되었습니다. AI가 쉽게 읽을 수 있기 위해서는 최소한 다음 조건을 갖추어야 합니다.

첫째, 구조가 명시되어야 합니다. 법령에서 제목, 조문, 항, 호, 목, 부칙, 별표, 첨부파일은 서로 다른 의미를 갖습니다. 이 구조가 사라진 평문은 검색에는 쓸 수 있어도 정확한 인용과 조문 단위 처리는 어렵습니다.

둘째, 출처와 식별자가 있어야 합니다. 법령명만으로는 부족합니다. 같은 이름의 문서가 다른 시점에 존재할 수 있고, 같은 경로가 재구성될 수도 있습니다. 법령ID, 판례일련번호, 공포일자, 선고일자, 원문 URL 같은 원천 식별자를 함께 보존해야 합니다.

셋째, 간축이 있어야 합니다. 법률 AI에서 '현재'는 충분한 기준이 아닙니다. 질문이 과거 사건에 관한 것인지, 현행 규제 준수에 관한 것인지, 개정 예정 사항에 관한 것인지에 따라 참조해야 할 데이터가 달라집니다. 따라서 데이터셋은 특정 시점의 상태를 복원할 수 있어야 합니다.

넷째, 실패 상태가 보여야 합니다. 어떤 문서의 본문이 비어 있다면, 그것이 원천 API의 한계인지, 첨부파일만 제공되는 문서인지, 파서가 실패한 것인지 구분해야 합니다. AI 시스템에서는 결측과 오류가 조용히 지나갈수록 위험합니다. '해당 데이터가 없다'와 '아직 파싱하지 못했다'는 전혀 다른 의미입니다.

다섯째, 사람이 검토할 수 있어야 합니다. AI가 읽는 데이터라고 해서 사람에게 불투명해져서는 안 됩니다. Markdown과 Git을 선택한 이유도 여기에 있습니다. 문제가 생겼을 때 사람이 원문과 변환 결과를 비교하고, Diff를 보고, 이슈(Issue)를 열고, 수정 규칙을 검토할 수 있어야 합니다. AI 친화성과 사람 친화성은 서로 반대가 아니라 함께 가야 합니다.

• 사회적 의미: 법령 데이터는 공공 인프라다

Legalize-KR은 정부나 공공기관이 운영하는 공식 서비스가 아닙니다. 개인과 커뮤니티가 함께 만들어 가고 있는 오픈소스 데이터 저장소이자 하나의 실험입니다. 법령 해석을 대신하지도 않고, 법률 자문을 제공하지도 않습니다. 그럼에도 이 프로젝트가 많은 관심을 받은 이유는 아마도 많은 분들이 비슷한 불편을 느끼고 있었기 때문일 것입니다. 즉, 데이터는 공개되어 있지만, 내가 원하는 방식으로 사용하기는 어려웠습니다. AI 도구는 빠르게 발전하지만, 한국의 공공 데이터를 안정적으로 활용할 수 있는 기반은 아직 충분하지 않습니다.

법령은 사회의 운영 규칙입니다. 누구나 법을 지켜야 한다면, 누구나 법에 접근할 수 있어야 합니다. 그리고 AI와 자동화가 일상화되는 시대에는 '사람이 웹에서 읽을 수 있음'만으로는 충분하지 않습니다. 기업의 컴플라이언스 시스템, 지방자치단체의 행정 자동화, 연구자의 정책 분석, 시민단체의 감시 활동, 스타트업의 법률 서비스 모두가 공통으로 사용할 수 있도록 AI가 쉽게 접근할 수 있는 법령 데이터가 필요합니다.

이러한 인프라는 특정 기업의 폐쇄형 데이터베이스만으로 충분하지 않습니다. 상용 서비스는 훌륭한 사용자 경험과 부가가치를 만들 수 있지만, 사회 전체의 기반 데이터는 가능하면 모두에게 열려 있고, 또 재현 가능해야 합니다. 공공 원천 데이터, 오픈소스 변환 규칙, 투명한 이슈 추적, 누구나 검증할 수 있는 스냅샷이 함께 있어야 장기적으로 신뢰를 얻을 수 있습니다.

이 지점에서 공공 부문과 민간의 역할은 서로 다르지만, 상호 보완적일 수 있습니다. 공공 부문은 안정적인 원천 데이터, 식별자, 변경 이력, 오류 상태, 첨부자료 메타데이터를 신뢰할 수 있는 기준으로 제공할 수 있습니다. 민간과 오픈소스 커뮤니티는 이를 바탕으로 변환 규칙을 실험하고, 오류를 발견해 되돌려 주며, 실제 활용 사례와 도구를 빠르게 만들어낼 수 있습니다. Legalize-KR은 이 두 역할이 경쟁 관계가 아니라 상호 보완 관계가 될 수 있음을 보여주는 작은 사례입니다.

또 하나의 의미는 참여 가능성입니다. Legalize-KR이 기사와 커뮤니티에 소개된 이후 여러 이슈와 제안을 받았습니다. 어떤 분은 특정 조문 파싱 오류를 제보했고, 어떤 분은 판례 파일명 규칙을 지적했으며, 어떤 분은 행정규칙과 자치법규까지 확장할 필요를 이야기했습니다. 한 개인이 모든 법률 데이터를 완벽하게 정리할 수는 없습니다. 그러나 공개된 저장소와 이슈 트래커가 있으면 문제를 발견한 사람이 개선의 출발점을 만들 수 있습니다. 이것이 오픈소스 방식이 갖는 장점입니다.

• 앞으로 필요한 것들

Legalize-KR이 앞으로 더 유용한 공공 데이터 인프라가 되려면 몇 가지 과제가 남아 있습니다.

첫째, 데이터 품질 검증을 더 체계화해야 합니다. 단위 테스트뿐 아니라 전체 데이터셋 수준의 검증이 필요합니다. 예를 들어 법률 없이 시행령만 남은 경로, 본문이 비어 있는 문서, 첨부파일이 있는데도 frontmatter에 보존되지 않은 문서, 같은 식별자가 여러 경로로 갈라진 사례 등을 탐지하고 정리해야 합니다. 데이터 프로젝트에서 테스트는 단순히 코드만 검증하는 것이 아니라 산출물의 무결성까지도 검증할 수 있어야 합니다.

둘째, 첨부파일과 이미지 처리를 개선해야 합니다. 별표, 서식, 도표, PDF, HWP, HWPX는 법령과 행정규칙에서 부수 자료가 아니라 핵심 본문일 때가 많습니다. 가능한 범위에서 텍스트 추출을 자동화하고, 추출이 어려운 경우에도 원문 링크와 파일 메타데이터를 안정적으로 보존해야 합니다. AI가 법령 본문만 보고 별표를 놓치면 잘못된 답변을 만들 수 있습니다.

셋째, 안정적인 스냅샷과 스키마 버전이 필요합니다. 변환 규칙이 개선되면 전체 Git 이력을 재구성할 수밖에 없지만, 사용자 입장에서는 특정 분석이 어떤 데이터 버전을 기준으로 했는지 고정할 수 있어야 합니다. 이를 강화하면 연구와 산업 활용에서 신뢰도가 높아질 것입니다.

넷째, 법령/판례/행정규칙/자치법규 사이의 연결을 강화해야 합니다. 실제 법률 문제는 한 문서 안에서 끝나지 않습니다. 법률 조문은 시행령과 시행규칙으로 구체화되고, 판례에서 해석되며, 행정규칙과 자치법규에서 현장 규칙으로 이어집니다. 각 데이터셋을 단순히 나란히 두는 것을 넘어, 조문 인용, 참조조문, 위임 관계, 판례 인용 관계 등을 구조화하면 훨씬 높은 가치가 생깁니다.

다섯째, 공공 데이터 제공 단계에서부터 AI 친화적 표준을 고민해야 합니다. 민간 프로젝트가 사후 변환을 계속하는 것도 의미가 있지만, 가장 좋은 것은 원천 기관이 처음부터 Markdown, JSON, CSV, 스키마, 변경 이력, API 명세 등을 함께 제공하는 것입니다. 특히 변경 이력과 첨부자료, 오류 상태, 안정적인 식별자는 공공기관이 제공할 때 가장 신뢰도가 높습니다. 정부가 이런 표준을 갖추면 사회적 비용을 줄이고, 더 많은 사람이 상위 응용 서비스와 연구에 집중할 수 있습니다.

앞서 언급했듯이 이것은 한 개인이 다 할 수 있는 일이 아닙니다. 오픈소스라는 방식으로 많은 사람들의 관심과 참여, 그리고 노력이 더해질 때 계속 유지되고 발전해 나갈 수 있습니다.

• 맺으며

Legalize-KR을 시작할 때는 '이런 프로젝트 하나쯤 있으면 좋겠다'는 생각이 컸습니다. 그런데 법령을 Git으로 옮겨 보니, 이것은 단순히 저장소 하나를 만드는 일이 아니라 공공 데이터의 형식을 다시 정리하는 일이었습니다. 법령은 본질적으로 시간에 따라 변하는 텍스트이고, 그 변화는 사회의 의사결정과 함께 권리와 의무의 변화를 담고 있습니다. 따라서 법령 데이터는 현재 조문을 보여주는 것을 넘어, 그 변화의 과정까지 기계와 사람이 함께 읽을 수 있어야 합니다.

Git과 Markdown은 새롭거나 거창한 기술이 아닙니다. 오히려 매우 평범한 도구입니다. 그러나 공공 법률 데이터에 적용했을 때, 그 평범함이 장점이 됩니다. 누구나 저장소를 가져올 수 있고, 변경 사항을 볼 수 있고, 자신이 쓰는 도구와도 연결할 수 있습니다. AI 시대의 데이터 인프라는 반드시 복잡한 플랫폼에서만 시작되는 것은 아닙니다. 잘 구조화된 텍스트, 안정적인 식별자, 투명한 변경 이력, 공개된 검증 과정에서 시작될 수 있습니다.

앞으로 법령뿐 아니라 판례, 행정규칙, 자치법규, 국회 의안, 예산, 고시, 표준, 통계 등 더 많은 공공 데이터가 사람과 AI 모두에게 읽기 좋은 형식으로 제공되기를 기대합니다. 공공 데이터가 더 잘 열리고, 더 잘 구조화되고, 버전 관리가 잘 될수록 시민과 기업, 연구자와 공무원 모두가 더 나은 도구를 만들 수 있습니다. Legalize-KR은 그 가능성을 확인한 작은 실험입니다. 이 실험이 공공 데이터의 다음 형식을 논의하는 하나의 계기가 되기를 바랍니다.

• 참고 및 확인 자료

- 국가법령정보센터: https://law.go.kr/ 

- 국가법령정보 공동활용: https://open.law.go.kr/ 

- Legalize-KR 웹사이트: https://legalize.kr/ 

- Legalize-ES 스페인 법령 저장소: https://github.com/legalize-dev/legalize-es 

- Legalize-KR GitHub 페이지: https://github.com/legalize-kr 

- Legalize-KR 법령 데이터 저장소: https://github.com/legalize-kr/legalize-kr 

- Legalize-KR 판례 데이터 저장소: https://github.com/legalize-kr/precedent-kr 

- Legalize-KR 행정규칙 데이터 저장소: https://github.com/legalize-kr/admrule-kr 

- Legalize-KR 자치법규 데이터 저장소: https://github.com/legalize-kr/ordinance-kr 

• 작성자 소개

Legalize-KR 프로젝트를 시작한 박정환(@9bow)은 2018년부터 딥러닝 프레임워크 PyTorch 공식 튜토리얼 문서를 한국어로 번역하고 공개하며 파이토치 한국 사용자 모임(PyTorchKR)의 대표 운영자로 활동하고 있다. 오픈소스와 커뮤니티, 시계열 예측 분야에 관심이 많으며, 최근에는 1인칭 영상 분석을 위한 모델 및 서비스를 개발하고 있다.