코드에는 README가 있는데, 대한민국 제도에는 왜 없는가

AI가 코드를 생산하는 시대, 실행논리를 이해하는 일이 새로운 병목이 됐다

최근 한 Threads 게시물을 보다가 한동안 첨부 이미지를 들여다봤습니다. 작성자는 Claude Code에 프로젝트 전체를 이해하기 쉬운 HTML 문서로 만들고, 가능하면 글보다 그림으로 설명해달라고 요청했습니다.

결과물은 흔한 코드 설명서와 달랐습니다. 파일 목록이나 함수 이름을 나열하지 않았습니다. 공개데이터를 모으고, 변하지 않는 스냅샷을 만들고, 여러 전략 후보를 같은 조건에서 검증하고, 미리 정한 게이트로 판정한 뒤, 통과한 후보만 동결하는 전체 흐름을 한 장의 구조도로 보여줬습니다. 통과한 후보가 없으면 기준을 낮추지 않고 그대로 끝내는 경로까지 그려져 있었습니다.

게시물의 관심은 어떤 모델이 더 잘 그렸느냐에 가까웠지만, 제 눈에 들어온 것은 다른 장면이었습니다.

AI가 코드를 써주는 단계를 넘어, 복잡한 시스템 전체를 읽고 “이것은 어떤 순서와 조건으로 작동하는가”라는 질문에 시각적으로 답하기 시작한 것입니다.

여기서 코드와 제도의 공통점이 보였습니다. 코드는 파일과 문장의 집합이 아닙니다. 입력을 받고, 권한을 확인하고, 조건에 따라 분기하고, 상태를 바꾸고, 실패하면 되돌아가거나 멈추는 실행체계입니다. 제도도 법령과 서식의 집합이 아닙니다. 국민의 신청을 받고, 기관이 권한을 행사하고, 요건을 판단하고, 문서를 인계하고, 승인·반려·이의제기로 상태를 바꾸는 실행체계입니다.

코드는 기계가 실행하고 제도는 사람과 조직, 정보시스템이 함께 실행한다는 차이가 있습니다. 그러나 둘 다 원문만 읽어서는 전체 작동방식을 알기 어렵다는 점은 같습니다. 필요한 것은 요약이 아니라 실행논리의 지도입니다.

그 순간 제도100을 만드는 이유가 더 선명해졌습니다.

코드 저장소에는 README와 아키텍처 문서가 있습니다. 그런데 국민이 매일 통과해야 하는 대한민국의 제도에는, 전체 구조를 설명하는 README가 거의 없습니다.

AI가 생산을 가속하자, 병목은 이해로 옮겨갔다

AI가 코드를 생산하는 시대를 이야기할 때 우리는 주로 생산성에 주목합니다. 한 사람이 더 많은 기능을 만들고, 더 짧은 시간에 여러 대안을 시험할 수 있게 됐다는 이야기입니다. 실제로 생산의 문턱은 빠르게 낮아지고 있습니다.

한 문장으로 줄이면 이렇습니다.

AI 이전에는 생산이 병목이었습니다. AI 이후에는 이해가 병목입니다. 시각화는 그 이해를 위한 새로운 인터페이스입니다.

하지만 코드를 만들어내는 속도가 빨라진다고 사람이 그 코드를 이해하는 속도까지 저절로 빨라지는 것은 아닙니다. 파일과 함수, 의존성과 분기가 순식간에 늘어날수록 사람은 오히려 더 자주 묻게 됩니다.

이 시스템은 무엇을 전제로 움직이는가.
어떤 입력이 어느 상태를 바꾸는가.
어느 지점에서 누가 승인하는가.
실패하면 어디로 돌아가고, 언제 정상적으로 종료하는가.
무엇을 바꾸면 시스템의 원칙 자체가 훼손되는가.

AI가 만든 코드를 다시 AI에게 요약해달라고 할 수는 있습니다. 그러나 문장 요약만으로는 실행순서와 병렬 흐름, 권한 경계, 예외 경로를 동시에 붙들기 어렵습니다. 특히 성공 경로만 매끄럽게 설명하면 실패·중단·복구 조건이 사라집니다. 이해한 것처럼 느끼지만 실제로는 시스템을 통제하지 못하는 상태가 될 수 있습니다.

그래서 시각화는 장식이 아니라 새로운 이해 인터페이스가 됩니다. 코드를 예쁜 그림으로 바꾸는 일이 아니라, 소스에 흩어진 실행논리를 다음 요소로 다시 컴파일하는 일입니다.

입력 → 행위자와 권한 → 상태 변화 → 판단 게이트 → 산출물과 증거 → 예외·복구 → 종료

이 지도가 있어야 사람은 AI가 만든 결과를 검토하고, 틀린 연결을 발견하고, 수정의 영향을 예상할 수 있습니다. AI 시대의 시각화는 발표용 산출물이 아니라 검토와 통제를 위한 작업면에 가깝습니다.

이 문제는 제도에서 이미 오래전부터 존재했습니다. 다만 AI가 코드 생산을 가속하면서, 우리 모두가 뒤늦게 같은 질문을 만나게 된 것입니다. 복잡한 실행체계를 만드는 능력만큼 그것을 사람이 이해할 수 있게 표현하는 능력이 중요하다는 질문입니다.

국민은 제도의 화면만 보고, 업무 논리는 보지 못한다

우리는 제도를 대개 신청 화면과 서류 목록으로 만납니다. 지원금을 신청할 때는 포털에 접속하고, 인허가를 받을 때는 서식을 작성하며, 이의가 있으면 별도의 절차를 찾습니다. 화면만 보면 하나의 서비스처럼 보입니다.

하지만 그 뒤의 업무 논리는 여러 문서에 흩어져 있습니다. 법률은 권한과 의무의 큰 틀을 정합니다. 대통령령은 대상과 절차를 구체화합니다. 시행규칙은 서식과 제출자료를 붙입니다. 훈령·예규·고시와 기관 내부 규정은 실제 처리 기준과 역할을 더합니다. 조직도와 사무분장은 누가 일하는지를 정하고, 정보시스템은 그중 일부만 구현합니다.

소프트웨어로 비유하면 국민은 화면을 보지만 소스코드와 데이터베이스, 권한체계, 배치작업은 보지 못하는 셈입니다. 문제가 생기면 어느 화면을 눌러야 하는지는 알 수 있어도, 누가 판단하고 어디에서 반려되며 어떤 문서가 다음 단계의 입력이 되는지는 파악하기 어렵습니다.

공무원도 사정이 크게 다르지 않습니다. 자기 담당 구간은 잘 알지만 앞 단계와 다음 단계, 다른 기관의 역할까지 한눈에 보기 어렵습니다. 담당자가 바뀌면 법령과 매뉴얼, 전임자의 파일을 다시 읽으며 전체 그림을 복원해야 합니다.

제도에는 코드가 없어서가 아닙니다. 법령 문장이 사실상 코드 역할을 하지만, 실행 구조를 보여주는 아키텍처 문서가 부족한 것입니다.

원문이 공개돼 있다는 것과 구조를 이해할 수 있다는 것은 다르다

대한민국은 법령 원문을 상당히 잘 공개하고 있습니다. 법제처의 국가법령정보 공동활용 API는 현행법령의 본문과 조항·호·목, 개정 이력, 위임법령, 자치법규 연계, 3단 비교 자료 등을 기계가 읽을 수 있는 형태로 제공합니다.

이것은 중요한 기반입니다. 그러나 원문에 접근할 수 있다고 해서 제도를 이해한 것은 아닙니다.

코드 저장소를 모두 내려받았다고 프로젝트의 목적과 실행 흐름을 바로 이해할 수 없는 것과 같습니다. 어느 파일이 핵심인지, 어떤 조건에서 다음 단계로 넘어가는지, 실패하면 어디로 돌아가는지, 최종 상태를 누가 승인하는지는 별도의 구조화가 필요합니다.

법령도 마찬가지입니다. 조문 A가 신청 주체를 정하고, 조문 B가 검토기관을 정하며, 다른 시행령 조문이 기간과 예외를 정할 수 있습니다. 서식은 별표에 있고, 이의절차는 또 다른 법률에 연결되기도 합니다. 원문은 공개돼 있지만 사용자가 경험하는 하나의 여정으로 묶여 있지 않습니다.

그래서 공공정보의 다음 문제는 더 많이 공개하는 것만이 아닙니다. 흩어진 공식 원문을 하나의 검증 가능한 구조로 연결하는 일입니다.

제도100은 대한민국 제도의 README를 만드는 실험이다

제가 제도100을 처음 만들 때는 ‘한 장으로 끝내는 대한민국 제도 지도’라는 설명에서 출발했습니다. 복잡한 법령을 한 장으로 요약해 국민이 쉽게 읽게 하자는 생각이었습니다.

그런데 509개 제도를 구조화하면서 단순 요약보다 더 중요한 것이 보였습니다.

제도 하나를 설명하려면 목적과 법적 근거만 적어서는 부족했습니다. 누가 신청하고, 누가 검토하고, 어느 지점에서 판단하며, 어떤 문서가 오가고, 반려되면 어디로 돌아가며, 이의제기는 어느 경로로 이어지는지를 함께 그려야 했습니다.

현재 제도100 공개 대장에는 509개 제도, 6,883개 절차 노드, 8,746개 법령 인용이 연결돼 있습니다. 법령만으로 확정할 수 없어 현장 확인이 필요한 항목도 1,924개를 따로 남겼습니다. 숫자보다 중요한 것은 각 항목의 문법입니다.

행위주체 레인은 누가 책임지는지를 보여줍니다.
업무 노드는 한 사람이 수행하거나 확인할 수 있는 단위 일을 나타냅니다.
게이트와 분기는 판단과 권한의 경계를 드러냅니다.
문서와 근거는 입력, 산출물, 완료 증거가 됩니다.
핸드오프는 다음 담당자와 인수인계를 보여줍니다.
unverified는 AI와 작성자가 더 나아가면 안 되는 중단점입니다.

이 구조는 사람에게는 제도 설명서이고, 조직에는 업무체계도이며, AI에게는 일을 어디까지 맡길 수 있는지 알려주는 직무기술서가 됩니다.

Threads의 시각 문서가 프로젝트의 데이터, 후보, 검증조건, 게이트, 종료 경로를 드러냈다면, 제도100은 법령 속 행위자, 업무, 판단, 증거, 인계, 예외를 드러냅니다.

둘은 대상만 다를 뿐 같은 일을 하고 있습니다. 복잡한 시스템의 숨은 실행 논리를 사람과 기계가 함께 읽을 수 있는 중간 표현으로 바꾸는 일입니다.

그러나 ‘AI에게 그림을 그려달라’는 것만으로는 부족하다

여기서 중요한 차이도 있습니다. 코드 프로젝트는 저장소 안에 실행되는 원본이 비교적 명확합니다. 테스트를 돌려 함수의 동작을 확인할 수도 있습니다. 반면 제도는 법령 문장만으로 실제 운영 전체를 확정하기 어렵습니다.

법령에는 재량이 있고, 기관 간 협의가 있으며, 공개되지 않은 내부 절차가 있을 수 있습니다. 같은 조문도 사건의 사실관계에 따라 적용이 달라집니다. 개정 전후의 기준일도 중요합니다. 법령상 절차와 현장에서 실제로 돌아가는 절차가 다를 수도 있습니다.

따라서 AI에게 “이 제도를 그림으로 그려줘”라고 바로 요청하면 보기 좋은 거짓말이 나올 위험이 있습니다. 빠진 예외를 자연스럽게 메우고, 연결되지 않은 조문을 연결하며, 애매한 책임자를 단정할 수 있습니다. 그림은 문장보다 확신을 강하게 전달하기 때문에 잘못된 선 하나가 더 위험합니다.

제도100에서 순서가 중요한 이유입니다.

공식 원문 → 구조화 데이터 → 근거 연결 → 기계 검사 → 사람 검토 → HTML·SVG 렌더링

그림은 사실을 만드는 곳이 아니라 검증된 구조를 보여주는 곳이어야 합니다.

현재 제가 생각하는 제도100의 역할 분담도 이 원칙을 따릅니다. 검증된 제도 데이터가 진실의 원본이 되고, MCP는 검색·분기·근거·다음 행동을 계산하며, 렌더러는 전달받은 명세를 HTML과 SVG로 표현합니다. 마지막 승인은 사람이 합니다. 렌더러가 법적 사실과 분기를 스스로 결정하게 두지 않습니다.

AI가 프로젝트를 읽고 시각 문서를 만드는 능력은 강력합니다. 공공제도에서는 그 능력 앞에 출처와 기준일, 뒤에 검증과 책임을 붙여야 합니다.

제도 README는 정적인 설명서에서 끝나지 않는다

소프트웨어 README는 대개 프로젝트가 무엇인지, 어떻게 설치하고 실행하는지를 알려줍니다. 제도 README도 처음에는 목적, 대상, 행위주체, 절차, 필요문서, 기한, 이의경로를 설명할 것입니다.

하지만 구조화된 제도 지도는 그보다 더 멀리 갈 수 있습니다.

국민이 “지금 저는 어느 단계인가”를 물으면 자기 상황과 관련된 경로만 강조할 수 있습니다. 담당자는 다음 단계에 필요한 문서와 근거를 확인할 수 있습니다. 관리자는 부서 사이의 대기와 되돌림이 몰리는 병목을 볼 수 있습니다. 제도가 개정되면 이전 구조와 달라진 노드와 연결선을 비교할 수 있습니다.

AI에게는 더 직접적인 의미가 있습니다. 업무구조도가 있으면 AI가 할 수 있는 일과 해서는 안 되는 일을 단계별로 나눌 수 있습니다. 자료를 정리하고 근거를 찾는 보좌 업무, 서식을 채우고 시스템에 입력하는 제한적 보조 업무, 사람의 판단을 독립적으로 검증하는 업무를 서로 분리할 수 있습니다. 게이트는 사람이 승인해야 하는 지점이 되고, unverified는 자동화를 멈추는 안전장치가 됩니다.

제도100은 국민에게 제도를 설명하는 사이트이면서 동시에 인간과 AI의 업무분장 원본이 될 수 있습니다.

한 장의 그림은 끝이 아니라 공통 대화면이다

시각화가 모든 문제를 해결하는 것은 아닙니다. 한 장에 담기 위해 세부사항을 줄이면 중요한 예외가 사라질 수 있습니다. 기관 관점의 업무흐름과 국민이 겪는 실제 여정도 다를 수 있습니다. 법령상 절차가 정확해도 현장에서는 시스템 제한과 관행 때문에 다른 병목이 생깁니다.

그래서 제도 지도에는 두 층이 필요합니다.

첫 번째는 공식 원문으로 만든 ‘법령상 업무구조도’입니다. 근거와 기준일이 있고, 재현할 수 있어야 합니다.

두 번째는 담당자와 이용자가 확인한 ‘현상 업무구조도’입니다. 실제 대기, 반복입력, 비공식 인계, 시스템 사이의 단절을 반영합니다.

두 지도를 비교할 때 비로소 AX의 대상이 보입니다. 법령이 요구한 사람의 판단인지, 시스템이 연결되지 않아 사람이 메우는 가짜일인지, AI가 보좌할 수 있는 검색과 정리인지, 사람에게 남겨야 할 권한과 책임인지를 구분할 수 있습니다.

GOV.UK의 서비스 매핑 가이드도 복잡한 공공서비스를 개선하려면 온라인·오프라인 접점, 백엔드 절차, 관여 조직, 사용자가 제출할 증거를 전체 여정으로 함께 봐야 한다고 설명합니다. 지도는 정답지가 아니라 서로 다른 조직과 이용자가 같은 문제를 놓고 대화하게 만드는 공통 화면입니다.

AI 시대에는 모든 중요한 시스템에 ‘살아 있는 설명서’가 필요하다

Threads의 사례가 인상적이었던 이유는 문서가 예뻐서만은 아닙니다. 코드와 데이터, 평가규칙 속에 숨어 있던 프로젝트의 사고방식을 한 장에 드러냈기 때문입니다. 성공 경로만이 아니라 탈락과 정상 종료까지 보여주면서, 무엇을 바꾸면 프로젝트의 원칙이 훼손되는지도 알게 했습니다.

대한민국의 제도도 그런 설명서가 필요합니다.

제도가 왜 존재하는지, 누가 무엇을 결정하는지, 어떤 증거로 다음 단계로 넘어가는지, 어디에서 사람의 판단이 필요한지, 실패와 이의제기는 어디로 이어지는지를 한눈에 볼 수 있어야 합니다. 그리고 법령이 바뀌면 그림도 함께 바뀌어야 합니다.

코드에는 README가 있습니다. 좋은 프로젝트에는 아키텍처 다이어그램과 테스트, 변경 이력이 있습니다.

제도에도 같은 것이 필요합니다. 다만 더 엄격해야 합니다. 공식 원문과 기준일, 불확실성 표시, 현장 검증, 사람의 책임이 함께 있어야 합니다.

AI가 복잡한 프로젝트를 읽고 시각 HTML로 설명하기 시작한 지금, 제도100의 목표도 ‘법령을 쉽게 요약하는 사이트’에 머물 수 없습니다.

사람이 코드의 모든 줄을 직접 쓰는 일은 줄어들 수 있습니다. 그렇다고 사람의 역할이 사라지는 것은 아닙니다. 오히려 AI가 만든 시스템의 전제와 분기, 권한과 예외, 실패와 종료 조건을 이해하고 검증하며 책임지는 일이 더 중요해집니다. 제도에서도 마찬가지입니다. 조문을 요약하는 것보다 그 조문이 현실에서 어떤 실행 경로를 만드는지 읽어내야 합니다.

대한민국의 제도를 사람과 AI가 함께 읽고, 검증하고, 개선할 수 있는 살아 있는 README를 만드는 일이어야 합니다.

제도100은 그 README의 첫 번째 초안입니다.

참고한 자료

※ 제도100은 법령 기준일에 따른 참고자료이며 법률 자문이나 정부기관의 공식 유권해석을 대신하지 않습니다. 법령만으로 확인할 수 없는 실제 운영정보는 별도 현장 검증이 필요합니다.