PAX 564건으로 본 공공 AX의 현재

2026년 10월 16일 현재 PAX 아카이브에는 564건의 사례가 있다. 564건 모두를 카탈로그 스키마로 정독 태깅했고, PAX 사이트의 4축 평가도 564건 전부에 붙어 있다. 그래서 질문 하나에 숫자로 답이 나온다. 공공 AX는 지금 무엇을 만들고 있고, 무엇을 만들지 않고 있는가. 이 장의 수치는 따로 밝히지 않는 한 모두 work/pax557_stats.json에서 가져왔다. 이 집계 파일은 원장(2026-10-16 갱신), 패턴 태깅 564건, 4축 평가 564건을 한데 묶어 다시 센 결과다. 부품 사용은 주·보조 부품을 합쳐 세고, 운영(C)·보안(S)·상호작용(F) 부품은 present와 implemented를 합쳐 사용으로 본다.

16.1 PAX 564건은 무엇을 대표하나

PAX 사례를 만든 주체는 대부분 개인이다. 564건 가운데 개인 개발이 334건(59.2%), 커뮤니티가 104건(18.4%)으로 둘을 합치면 77.7%다. 기관 공식 사례는 55건(9.8%)이고, 민간·해외에서 가져온 참고 사례가 71건(12.6%)이다. 기관 유형으로 다시 나누면 공직 개인이 321건으로 가장 많다. 중앙행정기관·공공기관·지자체·지방의회·교육기관을 모두 합쳐도 78건(13.8%)에 그친다.

이 표본은 자기선택 표본이다. 공무원 오픈채팅방과 SNS에서 자발적으로 공유된 사례를 모았으므로 전국 공공부문의 축소판으로 읽으면 안 된다. 공유할 만큼 완성된 도구, 공유해도 괜찮은 도구가 많이 들어오고, 기관 내부망 안에서만 도는 시스템은 덜 들어온다. 그래서 이 장은 비율을 전국 추정치로 쓰지 않는다. 같은 표본 안에서 어느 계층이 차 있고 어느 계층이 비었는지를 견준다. 그림 16.1은 기관 유형과 전이 단계를 함께 보여 준다.

도구의 모양도 기관 시스템과 다르다. 4축 평가의 도구 유형으로 보면 실행 파일·스크립트 같은 도구·기타가 130건, 웹 서비스가 111건, MCP 서버·도구가 92건이다. 업무 분야는 데이터·통계(128건)와 문서·기안(106건)이 가장 많고, 특정 업무에 묶이지 않는 공통·범용 도구가 96건으로 뒤를 잇는다. 표 16.1은 표본의 윤곽을 한 장에 모은 것이다.

표에서 먼저 볼 것은 근거 수준 행이다. 564건 가운데 391건은 태거가 코드나 저장소를 직접 확인했지만, 운영 중인 공식 주소까지 확인한 사례는 20건뿐이다. PAX 태깅은 공개 요약과 README, 저장소를 읽고 했다. 자료에 근거가 없으면 부품을 달지 않았다. 그래서 이 장의 사용 수치는 공개 자료에 서술된 부품만 센 하한이고, 결손 수치는 실제보다 크게 잡혔을 수 있다.

16.2 계층별 사용 분포

그림 16.2는 계층마다 부품이 하나라도 태깅된 사례의 비율이다. 업무 컴포넌트(B)와 서비스 블록(D)은 태깅 규칙상 모든 사례에 하나 이상 있으므로 100%다. 제어 흐름(B′)과 공통 서비스(A)의 사례 수는 같은 태깅 파일 564건에서 직접 셌다.

양 끝이 뚜렷하다. 공통 서비스는 542건(96.1%)이 갖는다. 거의 모든 도구가 자체 제작 환경, 공공 API, 문서 어댑터, 모델 서빙 가운데 무엇이든 하나는 쓴다는 뜻이다. 반대편에서 보안 계층은 48건(8.5%)이다. 그 사이에 상호작용 215건(38.1%), 제어 흐름 158건(28.0%), 운영 133건(23.6%)이 놓인다. 기반은 넓게 깔려 있다. 그 위에서 산출물을 통제하는 운영 계층은 넷에 하나꼴로만 서술되고, 이용자에게 한계를 알리는 상호작용 계층도 다섯에 둘이 채 안 된다.

그림 16.3은 부품 하나하나의 사용 사례 수를 센 상위 20개다. 막대 색은 계층이다.

상위 20개는 13장에서 본 세 묶음으로 거의 채워진다. 가장 흔한 짝은 A7자체 제작 환경과 B0결정적 도구로 254건에서 함께 나온다. 바이브 코딩으로 만든 결정적 도구라는 PAX의 저변이 이 한 쌍에 담겨 있다. 그다음이 공공 API와 결정적 도구(133건), 문서 형식 어댑터와 자체 제작 환경(102건)이다. 공공데이터 MCP 묶음(A3·A8·B0), 문서 변환 묶음(A10·D8.9), 스킬 코파일럿 묶음(A2.1·A9·B1)이 모두 이 목록 안에 있다.

운영 부품은 상위 20개에 하나도 들지 못했다. 가장 많이 쓰인 C1검토 큐가 46건으로 공동 21위이고, C5가드레일 필터가 44건이다. 상호작용 부품은 F1출처 표시(88건), F7한계·신뢰도 안내(63건), F2편집 가능한 출력(50건)이 들었다. 사람이 결과를 확인하게 하는 장치는 운영 계층보다 화면 쪽에서 먼저 나타난다.

16.3 주 부품 분포와 B0의 무게

사례마다 가치흐름의 중심에 놓이는 주 부품은 하나다. 그림 16.4는 564건의 주 부품 분포다. B0결정적 도구가 396건(70.2%)이고, B1코파일럿이 77건(13.7%), B3지식 접지 상담이 32건(5.7%), B4인식 파이프라인이 23건(4.1%)이다. 나머지 다섯 부품을 다 합쳐도 36건이다.

B0이 많은 데에는 정당한 이유가 있다. 공직자가 바이브 코딩으로 만드는 도구 대부분은 엑셀을 합치고, 한글 문서를 바꾸고, 공공 API를 불러 표로 정리한다. 만드는 과정에서는 AI를 썼지만 실행할 때는 모델을 부르지 않는다. 카탈로그는 이런 도구를 AI가 아니라며 빼지 않고 Ready 단계의 부품으로 이름 붙였다. 서비스 유형으로 보면 취합·변환 자동화 110건 중 97건, 데이터 에이전트(5b) 78건 중 71건, 분석 대시보드·브리핑(5a) 63건 중 60건이 B0을 주 부품으로 둔다. 5b의 B0은 대부분 공공데이터를 내주는 MCP 서버다. MCP 서버는 결정적 도구이고, AI는 그 서버를 부르는 호스트 쪽에 있다.

그런데 B0의 무게에는 다른 것도 섞여 있다. 1판을 낸 뒤 원장에 새로 들어와 2판에서 태깅한 83건에서 B0은 65건(78.3%)이다. 기존 481건의 B0 비중 68.8%(331건)보다 높다. 신규 사례 가운데에는 업무 도구가 아닌 것이 여럿 들어왔다. 행사 홍보용 러닝 게임, 지역 명소를 도는 보드게임 시안, 책 속 사례를 잇는 시각화, AI 서비스의 시스템 프롬프트를 모은 저장소, 개발 도구의 펫 캐릭터 패키지 같은 사례다. 태깅 규칙은 모든 사례에 주 부품을 하나 달게 되어 있다. 그래서 실행 기능이 없는 자료와 게임, 업무와 무관한 꾸밈 패키지가 전부 B0으로 들어간다.

태거들도 이 점을 지적했다. 신규 83건 가운데 11건의 태깅 피드백이 "업무 기능이 없는 사례에 B 주 부품을 강제하면 B0 분포가 부풀려진다"고 적었다. 이런 사례를 패턴 통계에서 각주로 빼거나 별도 플래그를 두자는 제안이다. 홍보 게임 세 건에서는 B0과 B7콘텐츠 생성기 사이에서 판단이 갈렸다. B7은 런타임에 콘텐츠를 생성하는 부품인데, AI로 제작한 게임은 완성된 콘텐츠일 뿐 실행 중에 생성하지 않는다. 전남광주통합특별시 서구의 SUNSET RUN은 행사 홍보 게임을 만들고 제작 과정과 요청문을 별도 사이트로 공개했다. 태거는 이 사례를 B0으로 두고, 공개된 제작 레시피는 A9업무 규범 스킬의 신호로 읽었다.

16.4 결손: 무엇이 비어 있나

운영 부품이 없는 사례

564건 가운데 운영 부품이 present나 implemented로 하나도 없는 사례는 431건(76.4%)이다. present만 세면 운영 부품이 있는 사례는 33건(5.9%)으로 줄어든다. 공개 자료에 운영 증거까지 남은 도구는 스무 건에 한 건 남짓이다. 그림 16.5는 운영 부품별 사용 사례 수를 present와 implemented로 나눈 것이다.

운영 부품 태그는 implemented가 134개, present가 39개다. 구현은 있지만 실제로 돌아간 기록이 공개 자료에 없는 경우가 세 배 넘게 많다. 가드레일 필터는 44건 가운데 39건이 implemented다. 입력 형식 검사나 출력 제약을 코드로 넣었다는 서술은 흔하지만, 그 필터가 무엇을 걸렀는지까지 적는 사례는 드물다. 검토 큐는 present가 14건으로 가장 많다. 결과를 사람이 확인한 뒤 쓰라는 안내는 도구 설명에 자주 들어가기 때문이다. 폴백 스위치는 present가 하나도 없다. 환류 파이프라인은 4건이고 present는 1건이다.

기관 공식 사례에서도 사정은 크게 다르지 않다. 행정안전부가 국산 LLM과 오픈웨이트 모델을 행정 내부망에 들인 사례는 검토 큐 하나를 가진다. 광진구가 직원이 만든 AI 도구 6종을 전 직원 업무에 투입한 사례는 검토 큐와 가드레일을 갖추고, 개인정보 입력 금지와 원문·출처 확인 의무, 담당자와 팀장의 최종 판단 책임을 규정으로 함께 내놓았다.

보안 계층은 거의 비어 있다

보안 부품이 하나도 없는 사례는 516건(91.5%)이다. 보안 부품이 있는 48건에서 가장 많은 것은 S12데이터 비도달 설계로 36건이고, 그중 27건이 present다. 그다음이 S13로컬 비식별 게이트(5건)다. 둘 다 적대자를 막기보다 민감 자료를 PC 안에 붙잡아 두는 부품이다. 프롬프트 인젝션을 구조로 막는 S4·S5·S6 가운데 태깅된 것은 S5계획 후 실행 1건뿐이다.

공공 AX는 아직 적대자를 설계 전제로 두지 않는다. 카탈로그 v0.5가 보안 계층을 만들 때 이미 관측한 사실이고, 564건으로 늘어난 지금도 그대로다. 이 빈칸이 아직 큰 사고로 번지지 않은 것은 도구의 권한이 낮아서다. 패턴 태깅에서 시스템 쓰기(P2)로 판정된 사례는 26건(4.6%)이다. 권한이 오르는 순간 이 빈칸은 바로 위험이 된다. 민원인의 자유 입력이나 외부 문서를 읽는 도구가 시스템 쓰기 권한까지 얻으면, 신뢰 불가 입력 규칙에 따라 S4·S5·S6 가운데 하나가 필수가 된다(9장).

상호작용 계층

상호작용 부품이 하나도 없는 사례는 349건(61.9%)이다. 운영·보안보다는 사정이 낫다. 출처 표시가 88건, 한계·신뢰도 안내가 63건, 편집 가능한 출력이 50건, 구조화 입력이 44건이다. 개인 개발 도구의 README에는 "참고용이며 최종 판단은 담당자 몫"이라는 문장이 자주 들어가고, 태거는 그 문장이 화면에도 있으면 F7로 달았다. 태거가 참조 구현 후보로 추천한 부품 가운데에서도 F7이 17건으로 가장 많다.

유형별 필수 부품 결손

검증기는 서비스 유형마다 필수 부품을 대조해 missing_required를 적는다(15장). 결손이 하나라도 있는 사례는 398건(70.6%)이다. 그림 16.6은 결손 부품별 사례 수다.

결손 목록은 두 갈래로 나눠 읽어야 한다. 하나는 도구 쪽의 빈칸이다. 내부 문서·기안 코파일럿이 검토 큐 없이 초안을 내거나, 대민 안내 도구가 한계 안내 없이 답을 내는 경우다. 이런 결손은 실제로 있어야 할 부품이 없는 것이다. 다른 하나는 카탈로그 쪽의 몫이다. 공공데이터 MCP 서버를 5b 유형으로 두면 호스트가 맡아야 할 권한 경계(C8)·감사 로그(C4)·S5|S6이 서버 사례의 결손으로 잡힌다. 비LLM 집계 현황판을 5a 유형으로 두면 모델 서빙(A2.5)·평가 세트(C9)·환류(C6)·판정 근거 표시(F9)가 모두 빠진 것으로 나온다. 그림 16.6의 S5|S6 77건, C6 67건, A2.5 61건 가운데 상당수가 이런 구조적 결손이다. 카탈로그는 v0.7과 v0.7.1에서 이 문제를 고쳤지만, 지금의 스키마와 검증기는 아직 v0.6 규칙으로 돈다(16.9절).

16.5 환경 조건: 어디에서 무엇으로 도는가

환경 조건(E 축)은 부품이 아니라 부품을 고르는 조건이다(4장). 564건의 환경 조건을 모으면 공직자가 어떤 제약 아래에서 도구를 만들고 있는지가 보인다. 표 16.2는 다섯 축의 분포다.

태깅의 네트워크 요건으로 보면 로컬에서 완결되거나 폐쇄망에서도 도는 도구가 181건(32.1%)이다. 행정망과 인터넷망이 나뉜 환경에서 일하는 공직자는 망 밖으로 자료를 내보내지 않는 도구를 스스로 만든다. 태깅의 런타임 환경으로는 브라우저만 있으면 되는 도구가 201건(35.6%)으로 가장 많다. 배포 환경 축으로 세면 로컬 PC 154건과 폐쇄망 15건을 합한 169건이어서, 망 이야기를 할 때는 어느 축으로 셌는지 함께 적는다. 그림 16.7은 모델 의존 분포다.

태깅의 모델 의존 조건으로 보면 298건(52.8%)은 런타임에 모델을 부르지 않는다. 16.3절의 B0과 거의 겹치는 집단이다. 모델을 부르는 도구에서는 모델 중립(BYO)이 90건으로 해외 상용 API 64건보다 많다. MCP 서버와 AI 도구용 스킬은 모델을 정하지 않고, 이용자가 쓰는 호스트의 모델을 그대로 쓰기 때문이다. 해외 오픈웨이트 모델을 로컬에서 돌리는 사례는 30건이고, 국산 독자모델은 8건, 국산 오픈웨이트는 1건이다.

폐쇄망은 부품을 지우지 않고 다른 부품으로 바꾼다. 한국철도공사의 CODERX는 인터넷 없이 내부망 PC에서만 도는 코딩 도구다. 로컬 오픈웨이트 모델을 얹은 A2.2주권형 온프레미스 모델 서빙으로 이 제약을 풀었다. 전북특별자치도의 전북AI도 행정망 안에 자체 생성형 AI 시스템을 세웠다. A2.2를 쓴 사례는 54건이고, 데이터 비도달 설계(S12)는 36건이다. 여러 기관이 각자 만드는 이 부품들이 범정부 공통 부품 개발의 우선순위 후보다.

16.6 전이: 개인 PC를 넘는 도구

전이 단계는 도구가 만든 사람의 손을 얼마나 멀리 떠났는지를 적는다. 그림 16.1의 오른쪽 판이 그 분포다. 개인 사용이 361건(64.0%)이고 부서 공유가 115건(20.4%)이다. 기관 공식으로 올라간 것이 57건, 다른 기관이 가져다 쓴 것이 7건, 범정부 탑재가 3건이다. 부서를 넘어선 도구를 모두 합치면 67건(11.9%)이다.

타 기관 재사용은 7건뿐이지만 카탈로그가 바라는 흐름을 가장 잘 보여 준다. 전북특별자치도가 행정망 안에 세운 생성형 AI 시스템 전북AI, 다른 기관이 만든 법령 도구를 경기도의회가 가져다 지능형 법령정보시스템으로 구축한 사례가 여기에 든다. 전이 단계가 기관 공식으로 적혔지만 같은 흐름에 놓인 사례도 있다. 화성특례시 AI스마트전략실이 정부 AI 실험실 GitLab에 공개한 신규자 지식창고를 광진구 실무자가 자기 기관 버전으로 포팅하면서, 원본에 없던 조례 개정 자동 감시와 첫 30일 체크리스트를 더했다. 이 포팅 사례는 C1.2심의 게이트와 C6환류 파이프라인을 함께 가진 몇 안 되는 사례다. C1.2는 564건 가운데 3건, C6은 4건에만 있다.

반대쪽 끝에서는 X9담당자와 함께 사라지는 도구가 PAX 전체에서 가장 많이 태깅된 안티패턴이다(16.8절). 전이 범위를 넓히려면 기능보다 운영 서술이 먼저 붙어야 한다. 검토 절차와 사용 기록, 라이선스, 저장소가 적혀 있을 때 도구가 부서를 넘는다.

16.7 4축 평가: AX 단계와 S·C·M·P

PAX 사이트는 사례마다 AX 단계와 S·C·M·P 눈금을 매긴다(2장). 이 평가는 패턴 태깅과 따로 이루어졌고, 태깅은 AX 단계를 입력으로 쓰지 않았다. 564건의 AX 단계는 AI-Ready 362건(64.2%), AI-Enabled 171건(30.3%), AI-First 5건(0.9%), AI-Native 계획 1건이다. 업무나 AI와 무관해 단계를 매기지 않은 AX 단계 외가 25건(4.4%)이다. 표 16.3은 나머지 눈금의 분포다.

업무 범위와 완결성이 같은 이야기를 한다. 도구의 59.2%는 조회나 변환 같은 단일 기능(S1)이고, 55.5%는 결과를 내주고 그다음은 사람에게 맡기는 완결성 C1에 머문다. 입력에서 검증과 완료까지 닫히는 완결성 C3은 1건뿐이다. 파급력 축은 MCP 관련 사례에만 매긴다. 4축 평가에서 MCP 역할이 있는 사례는 88건(서버 80건, 클라이언트·호스트 7건, 계획 1건)이다. A8 MCP 서버·호스트 태깅 95건이나 MCP 검증 페이지의 93건(17장)과는 세는 대상이 다르다. 88건 가운데 공개되어 다른 이용자가 재사용하는 M2가 60건이고, 실제 업무 시스템과 연결된 M3은 15건, 기관이 공식 제공하는 M4는 4건이다. 권한 축은 4축 평가에서 잠정값이어서, 4축 평가의 P2 20건은 패턴 태깅의 권한 범위(P2 26건)와 조금 다르다. 두 값의 차이는 평가 시점과 기준의 차이로 읽는다.

그림 16.8은 주 부품과 AX 단계를 교차한 것이다.

카탈로그의 단계 함의가 독립 판정과 같은 방향을 가리킨다. B0 396건 가운데 329건(83.1%)이 Ready이고, B1 77건 가운데 61건(79.2%), B3 32건 가운데 28건(87.5%), B4 23건 가운데 18건(78.3%)이 Enabled다. 런타임 AI가 없으면 Ready, 사람이 확정하는 산출물을 내면 Enabled라는 함의가 그대로 맞는다. AX 단계 외 25건 가운데 23건이 B0이라는 점도 16.3절의 지적과 맞물린다. 업무와 무관한 사례가 B0 칸에 쌓인다.

Enabled 171건의 구성도 볼 만하다. B1이 61건으로 가장 많지만 B0도 44건이다. 4축 평가는 런타임에 모델을 부르는지보다 검증 가능한 업무 산출물이 나오는지를 본다. 직제 정보를 API로 받아 조직도를 한글 문서로 만들어 내는 생성기처럼, 모델 없이 연속 처리로 업무 산출물을 만들면 B0이라도 Enabled를 받는다. 주 부품은 가치흐름의 중심을 보고, AX 단계는 업무가 얼마나 바뀌었는지를 본다. 두 판정이 어긋나는 칸은 두 축이 서로 다른 것을 잰다는 표시로 읽는다.

First 이상은 6건이다. 광진구의 AI 도구 6종 전면 투입은 지식 접지 상담을 주 부품으로 두고 완결성 C3, 업무 범위 S3, 파급력 M3을 받았다. 나머지 First 4건은 인용 대조 스킬 paper-verify, 로컬 마크다운 작업 공간 Liberaflow, 정책 여론 시뮬레이터 MiroFish-Ko, 정책 카드뉴스 스킬 Public Cardnews로, 모두 개인 개발이나 커뮤니티 도구다. 이 넷은 완결성 C2(부분 완결)에 머문다. 과학기술정보통신부·NIPA의 모두의 AI는 사업 계획 단계라 AI-Native 계획으로 분류됐다. First 5건 가운데 4건이 개인·커뮤니티 도구다. 단계를 가른 것은 예산 규모보다 업무 흐름을 다시 짰는지였다.

16.8 안티패턴 분포

안티패턴이 하나라도 태깅된 사례는 37건(6.6%)이다. 가장 많은 것이 X9담당자와 함께 사라지는 도구로 15건이다. 그다음이 X10평가 없는 RAG, RAG 없는 튜닝 6건, X6데모웨어와 X1AI 스티커 각 4건, X2설계도만 있는 운영과 X4단일 모델 인질 각 3건이다. X13도구 출력이 지시가 되는 에이전트가 2건, X8MCP 서버 개수 세기와 X7도구 설명 ≠ 실제 권한이 1건씩이다.

이 숫자는 실제보다 작게 잡혔다. 태깅 규칙이 공개 자료에 근거가 있을 때만 안티패턴을 달게 했기 때문이다. RAG 평가 근거가 없다는 이유만으로 X10을 달지 않았고, 미확인을 부재로 단정하지 않았다. X9가 가장 많은 것은 PAX의 성격 그대로다. 한 사람이 자기 업무를 줄이려고 만든 도구는 그 사람이 자리를 옮기면 멈춘다. 서무 업무 자동화 프로그램, 인수인계 정리본 도구, 초과근무 기록 리마인더가 모두 이 태그를 받았다. 셋 다 개인 사용 단계에 머문 도구다.

16.9 카탈로그가 다음에 고칠 것

564건의 태깅은 모두 v0.6 스키마로 이루어졌다. 카탈로그 본문은 v0.7에서 R10~R17을, v0.7.1에서 R18~R28을 더했지만, 이 개정은 문서에만 반영되었고 스키마와 검증기는 아직 v0.6 그대로다. 그래서 태거는 문서가 이미 고친 문제를 다시 만났다. 1판 이후 새로 들어와 2판에서 태깅한 83건의 피드백을 읽으면 같은 요청이 되풀이된다. 표 16.4는 신규 83건에서 다시 확인된 개정 사항이다.

표의 개정 사항은 모두 문서가 이미 답을 정해 둔 것이다. 그런데도 같은 피드백이 나온다면 고칠 곳은 스키마와 검증기다. 스키마의 열거값과 검증기의 필수 부품 표가 문서를 따라가지 않으면, 태거는 문서를 읽고도 옛 값으로 적을 수밖에 없다. 16.4절에서 본 구조적 결손과 16.3절의 B0 부풀림도 이 지연에서 나온다. 카탈로그의 다음 작업은 새 부품을 더하는 일보다 v0.7·v0.7.1 개정을 스키마와 검증기에 옮기고 564건을 다시 검증하는 일이다.

신규 83건은 새 부품 후보도 남겼다. 다른 에이전트의 루프·이탈·허위 완료를 감지해 경고하고 멈추는 행동 감시 하네스, 바이브 코딩으로 만든 코드를 배포하기 전에 거치는 정적 점검 관문, LLM 출력을 기관 서식 문서로 바꾸는 후처리 어댑터, 국회 요구자료 대응처럼 공공 특유의 반복 업무 흐름이 그 예다. 이런 후보는 15장의 등재 규칙대로 사례가 쌓일 때까지 후보로 둔다.

16.10 가람시 회고

가람시의 여정은 1장에서 부서마다 챗봇을 따로 만들려던 장면으로 시작했다. 4장에서 첫 패턴 서명을 썼고, 5~11장에서 부품을 하나씩 끼웠다. 12~13장에서는 조립과 종합 조립도를 그렸다. 14장에서 안티패턴을 점검한 뒤, 15장에서 태깅과 레지스트리를 기관 안에 들였다. 그림 16.9는 그동안 다섯 줄기가 사다리 위에서 어떻게 움직였는지를 정리한다.

16.11 다음 단계

PAX 564건의 현재와 가람시의 회고는 같은 결론을 가리킨다. 공공 AX의 다음 단계는 새 업무 컴포넌트를 더 만드는 일보다 이미 만든 조립의 빈칸을 메우는 일에 가깝다. 기관마다 사정은 달라도 순서는 대체로 같다.

1. 운영 부품을 implemented에서 present로 옮긴다. 폴백은 실제로 한 번 절체해 보고, 환류는 실제로 한 번 돌려 기록을 남긴다. PAX에서 폴백 스위치 12건 가운데 present는 하나도 없다. 설계 문서만으로는 First를 받지 못한다.
2. 권한이 오르기 전에 보안 부품을 끼운다. P2로 가는 계획이 나오면 untrusted_inputs부터 적는다. 탐지 필터 하나로 신뢰 불가 입력 규칙을 충족했다고 보지 않는다.
3. 자생 도구에는 운영 서술을 붙여 전이시킨다. 검토 절차, 사용 기록, 라이선스, 저장소가 서술되어야 개인 도구가 부서를 넘는다. 화성특례시의 신규자 지식창고는 원본이 정부 AI 실험실 GitLab에 공개되어 있었기에 광진구로 건너갔다.
4. 공유 계층은 기관 경계를 넘어 함께 만든다. 폐쇄망 모델 서빙(A2.2 54건), 데이터 비도달 설계(S12 36건), MCP 서버·호스트(A8 태깅 95건)처럼 여러 기관이 각자 만드는 부품은 범정부 공통 부품의 후보다.
5. 카탈로그와 태깅을 함께 고친다. v0.7·v0.7.1 개정을 스키마와 검증기에 옮기고 564건을 다시 검증한다. 그 뒤로는 분기마다 재태깅해 구현 상태의 이동을 기록하고, 맞지 않는 지점을 피드백으로 보낸다. PAX 사이트의 격차 지도와 관측소가 이 기록을 공개하는 자리다(17장).

© 2026 전종홍. 이 책은 CC BY-NC-SA 4.0 (저작자표시-비영리-동일조건변경허락) 라이선스를 따릅니다. 저작자를 밝히고 비영리 목적으로만 쓸 수 있으며, 고치거나 덧붙인 저작물은 같은 조건으로 배포해야 합니다.