범정부 AI와 한 공무원이 만든 도구 사이에 빠진 한 층

지금 공공 AX에는 서로 반대처럼 보이는 두 장면이 동시에 나타납니다.

위에서는 범정부 공통 AI 기반을 만듭니다. 기관마다 모델과 GPU를 따로 구축하다 생기는 중복투자와 기술 파편화를 줄이고, 여러 부처가 공통기반을 우선 활용하도록 합니다. 한국지능정보사회진흥원이 2026년 공개한 공공부문 AI 도입·활용 가이드가 보여주는 방향입니다.

아래에서는 현장의 한 사람이 자기 업무를 바꾸는 도구를 만듭니다. 행정안전부 혁신24에 공개된 ‘범정부오피스’ 사례는 간호직공무원 한 사람이 만든 문서 자동화 도구에서 출발했습니다. 공개 페이지에 따르면 기능이 천 개를 넘었고, 보안성 검토를 거쳐 온나라 커뮤니티에서 내부 버전이 제공됐으며 중앙·지방기관은 맞춤형 버전을 요청할 수 있게 됐습니다. 2023년에도 행정안전부는 한 지방공무원이 만든 보고서 편집 자동화 프로그램과 사용 안내를 공유한 바 있습니다.

두 장면은 어느 쪽이 옳으냐를 겨루는 관계가 아닙니다. 중앙은 공통 인프라를 공급하고, 현장은 실제 문제와 예외를 발견합니다. 둘 다 필요합니다.

문제는 그 사이입니다.

개인이 만든 프로토타입이 언제부터 기관의 자산이 되는가. 누가 품질을 보증하고, 어떤 권한을 허용하며, 누가 다음 버전을 관리하는가. 만든 사람이 부서를 옮기면 누가 장애 문의를 받는가. 가치가 사라지거나 위험이 커졌을 때 누가 사용을 중단하는가.

저는 이 사이의 빈칸이 공공 AX의 다음 병목이라고 생각합니다. 이제 필요한 것은 더 많은 제작 독려만이 아니라, 개인의 발명을 조직이 책임지는 서비스로 바꾸는 승격 계층입니다.

배포됐다고 기관 자산이 된 것은 아니다

파일이 온나라에 올라갔다고, 많은 동료가 내려받았다고, 보안검토를 한 번 통과했다고 곧바로 기관 서비스가 되는 것은 아닙니다. 배포는 사건이지만 운영은 계속되는 책임이기 때문입니다.

개인 도구는 빠릅니다. 만든 사람이 문제와 해법을 모두 알고 있어 의사결정 비용이 작습니다. 기능을 고치고 다시 시험하는 데 결재선도 길지 않습니다. 이 속도는 보호해야 합니다.

하지만 이용자가 늘면 성격이 달라집니다. 도구의 오류가 다른 부서의 업무를 지연시키고, 입력자료에 민감정보가 섞이며, 운영체제나 문서 형식의 변경이 다수 이용자에게 영향을 줍니다. 지원 요청이 생기고, 버전이 갈라지고, 누군가는 예전 파일을 계속 씁니다. 이때부터 도구는 제작자의 편의품이 아니라 조직의 의존성이 됩니다.

기관 자산의 기준은 소유권 표시에만 있지 않습니다. 기관이 다음 질문에 답할 수 있어야 합니다.

이 도구가 해결하는 공식 업무는 무엇인가.
허용된 이용자·데이터·행동의 범위는 어디까지인가.
어떤 시험을 통과한 버전이 현재 지원 버전인가.
장애와 오류를 누가 접수하고, 누가 수정할 권한을 갖는가.
유지보수에 필요한 시간과 비용을 누가 부담하는가.
언제 재검토하고, 어떤 조건에서 중단하는가.

답이 없다면 널리 쓰이는 개인 프로젝트일 수는 있어도, 조직이 책임지는 서비스라고 부르기 어렵습니다.

공공 AI의 생애주기는 작은 도구에도 필요하다

NIA 가이드는 공공 AI 도입을 개념 정의, 예산, 계약, 구현, 운영·고도화로 이어지는 생애주기로 봅니다. 중앙조달이나 정식 정보화사업에는 자연스러운 순서입니다. 그러나 현장 도구는 대개 옆문으로 들어옵니다. 예산을 세우고 사업을 발주한 뒤 만들어지는 것이 아니라, 누군가 자기 일을 해결하려고 이미 만들어 쓴 뒤 조직에 발견됩니다.

그래서 현장 도구에 정규 정보화사업의 순서를 그대로 소급 적용하면 문제가 생깁니다. 수십 쪽 문서와 긴 심의를 요구하면 사람들은 도구를 숨겨 쓰거나 공유를 포기할 수 있습니다. 반대로 “좋은 사례”라는 이유로 바로 확산하면 소유자 없는 소프트웨어와 유지보수 부채가 늘어납니다.

필요한 것은 면제도, 동일규제도 아닙니다. 이미 작동하는 프로토타입을 대상으로 한 짧고 비례적인 승격 경로입니다.

저라면 다음 여덟 단계를 기본형으로 삼겠습니다.

1. 발견과 등록

먼저 작은 도구가 있다는 사실을 조직이 알아야 합니다. 등록은 허가 신청서가 아니라 한 페이지짜리 표지면 충분합니다. 해결하는 문제, 이용자, 입력자료, 외부 연결, 만든 사람, 현재 이용범위, 알려진 한계를 적습니다. 등록됐다는 이유만으로 공식 승인을 뜻해서는 안 됩니다.

2. 제한된 현장시험

몇 명의 이용자와 되돌릴 수 있는 업무에만 범위를 제한합니다. 개인정보를 처리하거나 국민의 권리·의무를 바꾸거나 외부 발송을 실행하는 기능은 처음부터 분리합니다. 기존 업무의 처리시간, 오류, 재작업, 지원부담을 먼저 재야 합니다. 기준선이 없으면 빨라졌다는 인상만 남습니다.

3. 효과와 실패의 증거

잘된 사례만 모으지 않습니다. 어떤 입력에서 실패했는지, 사람이 얼마나 고쳤는지, 절약한 시간보다 검수시간이 더 늘지는 않았는지 기록합니다. 여기서 가치가 없다고 판단되면 실험을 끝내도 됩니다. 모든 프로토타입을 살려야 한다는 압박이 없어야 승격 절차가 정직해집니다.

4. 권한 명세

AI 시대의 도구는 문서를 읽는 데서 끝나지 않습니다. 파일을 저장하고, 메시지를 발송하고, 시스템의 상태를 바꿀 수 있습니다. 조회, 생성, 외부전송, 상태변경을 나누고 각각 필요한 권한을 적어야 합니다. 위험한 행동은 사람 승인 뒤에만 실행하고, 승인과 실행의 기록을 남깁니다.

5. 보안·법무·품질 게이트

위험에 비례해 검사합니다. 공개문서 서식변환과 개인정보를 사용하는 의사결정 지원을 같은 기준으로 심사할 이유는 없습니다. 다만 기관 서비스로 승격할 버전에는 최소한 입력 검증, 대표 업무 테스트, 실패 처리, 접근권한, 로그, 개인정보 경계, 복구 방법이 있어야 합니다.

6. 공식 소유자와 유지보수자 지정

이 단계가 가장 중요합니다. 만든 사람을 평생 고객센터로 만드는 것은 조직화가 아닙니다. 서비스의 범위와 우선순위를 결정할 권한이 있는 소유자, 실제로 수정할 수 있는 유지보수자, 최소 두 명의 인수인계 가능한 담당자를 지정해야 합니다. 유지보수 시간도 업무로 인정해야 합니다.

영국 정부의 서비스 팀 역할 지침은 서비스 소유자를 개발·운영·지속적 개선에 대한 의사결정 권한과 책임을 가진 사람으로 둡니다. 정부 소스코드의 공개·재사용 지침도 코드 소유권을 명확히 하고, 버전 관리, 이용자 소통과 지원, 유지보수 시간, 공개 이슈 목록까지 책임의 일부로 봅니다. 핵심은 코드가 공개됐느냐보다 누가 계속 책임지느냐입니다.

7. 지원되는 배포

공식 저장소, 지원 버전, 변경 이력, 설치·사용 안내, 문의 채널을 하나로 정합니다. 같은 이름의 파일이 메신저와 공유폴더를 떠돌지 않게 해야 합니다. 기능을 새로 추가할 때는 어느 테스트를 다시 돌려야 하는지도 연결합니다. 배포 수보다 지원 가능한 이용범위를 먼저 정하는 편이 낫습니다.

8. 갱신 또는 폐기

서비스가 됐다고 영구 존속하는 것은 아닙니다. 문서 형식, 모델, 보안정책, 법령, 이용수요가 바뀌면 다시 검토합니다. 소유자가 사라졌거나 효과가 없거나 안전한 유지가 어려우면 종료하고 대체 경로와 데이터 처리 방법을 안내합니다.

NIST의 AI 위험관리 프레임워크 핵심은 AI 시스템의 목록, 역할과 책임, 지속적 모니터링뿐 아니라 안전한 단계적 종료까지 생애주기 거버넌스에 포함합니다. 시작을 승인하는 절차만 있고 끝내는 절차가 없다면 오래된 위험이 계속 남습니다.

승격은 인증서가 아니라 책임의 이동이다

이 여덟 단계를 체크리스트로만 운영하면 또 하나의 통과의례가 됩니다. 승격의 핵심은 도구 앞에 ‘공식’ 스티커를 붙이는 것이 아니라 책임의 위치를 바꾸는 데 있습니다.

개인 실험 단계에서는 제작자가 사용범위를 통제하고 결과를 직접 확인합니다. 팀 지원 도구가 되면 한 부서가 사용규칙과 지원을 맡습니다. 기관 서비스가 되면 조직이 소유자, 예산, 권한, 품질, 장애대응, 폐기를 책임집니다.

따라서 모든 도구는 세 상태 가운데 어디에 있는지 보여야 합니다.

개인 실험: 제작자 또는 소수 이용자가 전수 확인하며 사용
팀 지원 도구: 정해진 부서·업무에서 공동관리하며 제한 배포
기관 서비스: 공식 소유자와 지원·갱신·폐기 체계를 갖춰 운영

이 구분은 낮은 단계를 열등하게 보려는 것이 아닙니다. 일회성 자료변환이나 개인 생산성 도구는 개인 실험으로 남는 편이 합리적일 수 있습니다. 문제는 개인 실험에 기관 서비스 수준의 신뢰를 부여하거나, 기관 서비스가 사실상 한 개인에게 의존하면서도 그 사실을 숨기는 것입니다.

공통기반이 커지면 이 층은 필요 없어질까

강한 반론이 있습니다. 범정부 공통기반의 기능이 충분히 좋아지면 개인 도구를 일일이 승격할 필요가 없다는 주장입니다. 공통 문서요약, 검색, 번역, 보안, 로그 같은 기능은 중앙에서 제공하는 편이 중복을 줄일 수 있습니다.

맞습니다. 중앙은 인증, 모델, 공통 데이터 연결, 로그, 보안정책, 평가도구, 배포환경 같은 레일을 제공해야 합니다. 그러나 중앙팀이 모든 기관의 서식과 예외, 승인선, 현장 언어까지 미리 알 수는 없습니다. 공통기반이 모든 차량을 직접 만드는 공장이 되려 하면 현장의 긴 꼬리 업무는 다시 대기열에 갇힙니다.

중앙의 역할은 현장 도구를 없애는 것이 아니라, 현장 도구가 안전하게 올라탈 표준 레일을 만드는 데 가깝습니다. 등록 형식, 권한 등급, 테스트 방식, 배포 채널, 소유자 역할, 종료 절차를 공통화하면 기능은 현장에서 만들고 책임은 조직으로 옮길 수 있습니다.

OECD의 Digital Government Outlook 2026은 정부 AI 도입이 넓어지는 한편, 영향 측정의 어려움이 확장 가능성이 낮은 파일럿의 증가로 이어질 수 있다고 지적합니다. 인프라뿐 아니라 거버넌스, 역량, 조직 능력이 함께 필요하다는 진단입니다. 파일럿을 더 많이 만드는 것과 서비스를 더 잘 운영하는 것은 다른 능력입니다.

절차가 현장 혁신을 죽인다는 반론

승격 경로를 만들자고 하면 곧바로 서류와 심의가 늘어날 수 있습니다. 실제로 모든 매크로와 프롬프트에 보안성 검토와 서비스 소유자를 요구하면, 이 제안은 실패합니다. 사람들은 공식 경로를 피하고 혁신은 다시 비공식 영역으로 숨어듭니다.

그래서 규율은 제작 단계가 아니라 승격 단계에서 강해져야 합니다. 공개자료를 정리하고 결과를 사람이 전수 확인하는 개인 실험은 가볍게 시작하게 둡니다. 이용자가 늘고, 민감한 데이터를 읽고, 외부로 보내고, 시스템 상태를 바꿀수록 요구사항을 단계적으로 늘립니다.

승격을 신청하지 않는 도구까지 모두 중앙에서 통제할 필요는 없습니다. 다만 조직이 그 도구에 의존하기 시작했다면, “개인이 알아서 만든 것”이라는 말로 책임을 다시 개인에게 돌려서는 안 됩니다.

영국 정부의 신뢰할 수 있는 서비스 운영 기준은 자동화된 테스트만 믿지 않고 서비스 팀이 품질을 감독하며, 실제 환경과 가까운 시험, 모니터링, 지속 가능한 장애대응을 요구합니다. 이는 거대한 대국민 시스템에만 필요한 원칙이 아닙니다. 동료들이 매일 의존하는 내부도구도 멈추면 실제 업무가 멈춥니다.

30일 안에 시험할 수 있는 승격 파일럿

새 위원회부터 만들 필요는 없습니다. 한 기관에서 이미 쓰이고 있는 직원 제작 도구 10개를 모아 30일 동안 분류해볼 수 있습니다.

먼저 각 도구를 개인 실험, 팀 지원 도구, 기관 서비스 후보로 나눕니다. 이용자 수가 아니라 업무 의존도, 데이터 민감도, 상태변경 권한, 오류 영향, 대체 가능성을 기준으로 봅니다. 기관 서비스 후보 가운데 최대 두 개만 승격 파일럿에 넣습니다.

두 도구에는 각각 공식 소유자 한 명과 유지보수자 두 명을 지정합니다. 기준선을 재고, 대표 업무와 실패 사례로 테스트하며, 지원 버전과 문의 채널을 하나로 모읍니다. 조회·저장·발송 권한을 분리하고, 업데이트 뒤 재검증할 항목을 정합니다. 30일이 끝나면 확대, 팀 도구 유지, 개인 실험 복귀, 종료 가운데 하나를 결정합니다.

측정할 것은 화려하지 않아도 됩니다.

기존 방식과 비교한 실제 절감시간
사람이 수정한 핵심 오류와 재작업률
이용자 한 명당 지원 요청과 처리시간
한 달 유지보수에 든 담당자 시간
운영환경 변경에 대응한 시간
소유자 부재 때 인수인계가 가능한지
중단 뒤 수동 업무로 돌아갈 수 있는지

승격된 도구의 숫자 자체는 성과가 아닙니다. 조직이 책임질 가치가 있는 도구를 가려내고, 가치가 없는 도구를 부담 없이 종료하는 능력이 성과입니다.

개인의 속도와 기관의 책임 사이에 다리를 놓는 일

공공 AX는 지금 제작 민주화의 단계로 들어가고 있습니다. 모델과 공통기반이 공급되고, 현장의 사람은 자기 문제를 직접 해결할 수 있게 됐습니다. 이것은 큰 변화입니다. 그러나 제작비용이 내려갈수록 운영책임은 저절로 생기지 않습니다. 오히려 유지보수해야 할 작은 도구가 더 빠르게 늘어납니다.

개인의 프로토타입에는 속도가 있습니다. 기관의 서비스에는 책임이 있어야 합니다. 둘 가운데 하나를 선택할 필요는 없습니다. 필요한 것은 속도를 죽이지 않으면서 책임을 옮기는 다리입니다.

공공 AX의 성과를 POC 수나 배포 파일 수로만 세면 그 다리는 보이지 않습니다. 대신 이렇게 물어야 합니다.

누가 만든 도구인가보다 지금 누가 책임지는가. 몇 명이 내려받았는가보다 어떤 버전이 지원되는가. 얼마나 빨리 만들었는가보다 만든 사람이 떠난 뒤에도 안전하게 남는가. 계속할 이유만큼 멈출 조건도 있는가.

범정부 AI와 한 공무원이 만든 도구 사이에 빠진 한 층은 거대한 새 플랫폼이 아닐 수 있습니다.

발견하고, 시험하고, 권한을 정하고, 소유자를 세우고, 지원하고, 필요하면 끝내는 짧고 명확한 절차일 수 있습니다.

공공 AX가 개인의 영웅담을 넘어 조직의 능력이 되는 순간은 도구가 처음 만들어진 날이 아닙니다.

그 도구를 기관이 책임지기로 결정한 날입니다.

참고한 공식자료

※ 이 글은 2026년 8월 10일 확인한 공개·공식자료를 바탕으로 한 개인적 제안입니다. 국내 기관의 실제 승격 절차와 유지보수 성과에 관한 공개자료가 충분하지 않아, 제안한 단계와 30일 파일럿은 공식 지침이 아니라 검증할 운영 가설입니다.