공공부문 AI 서비스 성숙도 · 평가 기준일 2026-08-08
사례 70건 평가 모형 요약

네 개의 관문.

"AI 기능이 있다"
──▶
"업무가 실제로 완결된다"

등급은 AI를 얼마나 많이 쓰는지로 정해지지 않습니다. 일이 어디까지 스스로 끝나는가로 정해집니다. 위 단계로 갈수록 요구되는 것은 더 좋은 모델보다 더 촘촘한 운영 설계입니다.

관문은 합산되지 않습니다 총점이 높아도 필수 항목 하나가 비면 그 단계는 성립하지 않습니다.
근거가 없으면 "미확인"입니다 없다고 단정하지 않고 상위 단계 판정을 보류합니다.
단계와 운영 여부는 별개입니다 운영 중인 Ready도, 시제품인 Enabled도 모두 가능합니다.
01 성숙도 사다리 — 각 단계의 통과 조건 ■ 표시 개수 = 그 단계에서 반드시 통과해야 하는 관문 수
STAGE 01
AI-Ready
준비 · 쓸 수 있게 만든 상태

AI를 실제 업무에 붙여 시험해볼 수 있도록 데이터·권한·책임·기준선을 갖춘 단계입니다.

필수 관문
  • 데이터·권한·책임·기준선 중 하나 이상 확보
  • 지금 붙여서 돌려볼 수 있는 상태
  • API·MCP·RAG·플랫폼·교육·실험환경 형태로 제공
  • 산출물이 준비 요소에 실질적으로 기여
미달 판정 "AI로 코딩했다"는 사실만으로는 등급에 반영되지 않습니다.
AI를 끄면 달라지는 것이 없습니다.
S1–S2C0E0–E1
STAGE 02
AI-Enabled
활용 · 결과물이 나오는 상태

기존 업무 흐름은 그대로 두고, 한 구간에서 AI가 확인 가능한 결과물을 만들어 사람이 검토하는 단계입니다.

필수 관문
  • 실제 업무 산출물이 존재 — 검색·요약·분류·번역·초안·추천·분석
  • 맞고 틀림을 확인할 수 있는 결과
  • 사람이 확인해야 다음으로 넘어가는 절차
미달 판정 화면에 AI 기능이 붙어 있는 것만으로는 부족합니다.
AI를 끄면 손이 조금 더 갈 뿐 업무는 돌아갑니다.
S2–S3C1–C2E1–E2
STAGE 03
AI-First
재설계 · 흐름을 다시 짠 상태

AI를 전제로 업무의 시작점·처리경로·역할을 다시 설계하고, 그 설계가 실제로 돌아간 기록이 있는 단계입니다.

필수 관문
  • 시작점·처리경로·역할의 재설계
  • 저위험 건의 자동 처리
  • 고위험 건의 숙련자 이관
  • 예외 처리 — 승인·거부·롤백
  • 운영 결과의 지표화
  • 반복 예외의 제도·기준 반영
미달 판정 설계 문서만으로는 통과하지 못합니다. 모든 관문에 운영 증거가 필요합니다.
AI를 끄면 처리량이 급감하고 적체가 시작됩니다.
S3–S4C3–C4E3+
STAGE 04
AI-Native
내재화 · 없으면 성립하지 않는 상태

AI가 서비스의 핵심 가치를 만들고, 사용 결과가 서비스를 고치며, 장애와 품질 변동에도 서비스가 유지되는 단계입니다.

필수 관문
  • 핵심 가치 결합 — AI를 빼면 서비스가 성립하지 않음
  • 학습 구조 — 사용 결과가 평가·개선으로 되돌아옴
  • 복원력 — 장애·가격·품질 변동에도 핵심 기능 유지
  • 적용 범위 기록 — 도구/업무/흐름/서비스/조직/생태계
가장 자주 걸리는 곳 성능은 충분한데 환류 회로와 강등 경로가 없어 여기서 멈춥니다.
AI를 끄면 서비스가 성립하지 않습니다. 그래서 강등 경로가 필수입니다.
S4–S5C5M4–M5E4+
완결성 눈금 — 어디까지 스스로 끝나는가 각 단계가 실제로 놓이는 구간
C0
C1
C2
C3
C4
C5
Ready
Enabled
First
Native

눈금이 오른쪽으로 갈수록 사람이 손대야 하는 일이 줄어듭니다. C5는 AI-Native의 필수 조건이며, 평가·학습·재검증·대체경로·장애복원이 모두 들어가야 도달합니다.

02 세 개의 눈금자 — 등급 하나로 뭉뚱그리지 않기 한 사례는 언제나 단계 + S + C + M 으로 함께 기록
S — 업무 범위

얼마나 넓은 일을 감당하는가

S1
단일 기능조회·변환·생성·검사 하나
S2
기능 묶음관련 도구·데이터의 세트
S3
업무 흐름목표 하나를 위한 순차·조건 처리
S4
종단 서비스접수·처리·승인·통지·종료 확인까지 연결
S5
생태계여러 기관·서비스·에이전트의 공동 수행
C — 업무 완결성

어디까지 스스로 끝내는가

C0
기능 제공도구가 있고 호출됨
C1
결과 제공답만 주고 후속은 사람이
C2
연속 처리단계는 이어지나 판단·완료는 사람이
C3
운영 폐쇄루프입력→처리→검증→완료, 종료 상태 확인
C4
예외 포함 완결오류·승인·이의제기·이관·롤백까지
C5
적응형 완결평가·학습·재검증·대체경로·장애복원까지
M — 실행계층 파급력

얼마나 공적으로 쓰이는가 · MCP 사례에 적용

M1
제한적만든 사람과 소수만 사용
M2
재사용형공개되어 다른 사용자·모델이 재사용
M3
업무통합형실제 업무 시스템·API와 연결
M4
생태계형기관이 공식 제공, 다기관 공동 이용
M5
핵심인프라형공식 실행계층, SLA·책임·감사·복원력 보유
03 무엇이 언제부터 필수인가 위 단계는 아래 단계의 요건을 모두 포함
설계 요소 Ready Enabled First Native
준비 자산 — 데이터·권한·책임·기준선
검증 가능한 업무 산출물
사람의 확인 절차
위험도에 따른 자동·이관 분기
종료 상태 확인
승인·거부·롤백 경로
처리 건별 지표 적재
반복 예외의 제도 반영
핵심 가치 결합
평가 → 개선 환류 회로
대체 경로·장애 복원
적용 범위 명시 기록
필수 — 없으면 그 단계 판정 불가 권장 — 다음 단계로 가는 발판 해당 단계에서는 묻지 않음
04 우리 서비스는 지금 어디인가 위에서부터 순서대로, 처음 "아니오"가 나온 곳이 현재 위치
Q1 데이터·권한·책임·기준선 중 하나라도 실제로 붙여 쓸 수 있게 정리되어 있습니까? 아니오미착수
Q2 AI가 만든 업무 산출물이 있고, 맞고 틀림을 확인할 수 있습니까? 아니오AI-Ready
Q3 그 결과 때문에 일의 시작점과 담당 역할이 실제로 바뀌었습니까? 아니오AI-Enabled
Q4 자동 처리·숙련자 이관·롤백이 실제로 작동한 운영 기록이 있습니까? 아니오AI-Enabled · First 후보
Q5 쌓인 지표가 판정 기준이나 자동화 범위를 실제로 바꾸고 있습니까? 아니오AI-First
Q6 모델이 멈추거나 품질이 떨어져도 핵심 기능이 유지됩니까? 아니오AI-First
AI-Native · 적용 범위를 함께 기록하십시오
05 같은 업무, 네 가지 버전 예시 — 지자체 보조금 신청 접수부터 지급 종결까지

AI-Ready

  • 최근 3년 심사 결과를 항목별로 라벨링해 정리
  • 지원 요건·감액 기준을 조문 단위로 쪼개 검색 인덱스 구축
  • 담당 부서에 실험 환경과 조회 권한 부여
  • 현재 평균 처리일수·반려율을 기준선으로 기록
산출물은 아직 없습니다.

AI-Enabled

  • 신청서를 올리면 누락 서류와 요건 불일치 항목을 표시
  • 과거 유사 심사 사례와 적용 조문을 근거로 제시
  • 담당자가 화면에서 확인 후 승인·반려를 직접 결정
일하는 순서는 그대로입니다.

AI-First

  • 요건 충족이 명확한 건은 심사 대기열을 건너뛰고 승인 초안으로 직행
  • 감액 사유·신규 유형·확신도 미달 건은 숙련 담당자에게 자동 이관
  • 이의신청 인용 시 지급 결정을 되돌리는 롤백 절차 상시 운영
  • 건별 처리시간·수정률·이관률·이의 인용률을 적재
  • 반복되는 이의 사유는 심사 기준 개정 안건으로 상신
접수부터 종결까지 닫힙니다.

AI-Native

  • 자동 심사를 전제로 인력 배치와 접수 물량 자체가 재편
  • 이의 인용률이 오른 유형은 자동 처리 기준이 스스로 엄격해짐
  • 분기마다 심사 모델을 재검증하고 성능 저하 시 사람 검토 비중 확대
  • 모델 장애 시 대체 모델 → 규칙 기반 → 수동 순으로 강등, 접수는 계속
  • 심사 기능을 다른 기관이 호출 가능한 공식 실행계층으로 제공
멈추면 서비스가 성립하지 않습니다.
06 Native를 가르는 한 장면 — 강등 경로 평가 사례 대부분이 여기서 미확인 처리됨

모델이 멈추거나, 단가가 뛰거나, 품질이 떨어질 때 무엇이 일어나는지 미리 정해두었는가. 이것이 문서로만 존재하면 관문을 통과하지 못합니다.

EVENT
모델·API 중단 응답 지연, 오류율 급증, 단가 인상
FALLBACK 1
대체 모델 전환 동급 성능의 다른 모델로 자동 절체
FALLBACK 2
규칙 기반 강등 판정 범위를 좁히고 확정 규칙으로 처리
FALLBACK 3
수동 전환 전건 사람 처리, 접수·통지는 그대로 유지
어느 경로에서도 접수·처리·통지는 끊기지 않고, 전환 이력은 감사 기록에 남습니다.
07 그래서 무엇을 만들 것인가 — 설계 여섯 가지 각 항목은 하나의 관문에 직접 대응
AIM 01

결과가 아니라 종료를 설계하십시오

무엇을 출력할지보다 무엇을 완료로 볼지를 먼저 정의합니다. 종료 상태가 정의되지 않으면 아무리 정확해도 완결성은 C2에 머뭅니다.

확인 질문이 건이 끝났다는 것을 시스템이 어떻게 압니까?
AIM 02

예외 경로를 먼저 그리십시오

되돌리는 방법이 없는 자동화는 자동화가 아닙니다. 승인·거부·롤백을 설계 초기에 넣어야 나중에 붙일 수 있습니다.

확인 질문잘못 처리된 건을 누가 어떤 절차로 되돌립니까?
AIM 03

위험도로 분기하십시오

전부 자동도, 전부 사람도 설계 실패입니다. 쉬운 건은 통과시키고 어려운 건은 숙련자에게 보내는 기준선이 핵심입니다.

확인 질문자동으로 넘길 건과 사람에게 보낼 건의 경계는 무엇입니까?
AIM 04

처리마다 흔적을 남기십시오

처리시간·오류율·수정률·이관률·사용량·비용이 건별로 쌓여야 다음 단계로 갈 연료가 생깁니다. 쌓이지 않으면 개선도 증명도 불가능합니다.

확인 질문지난달 수정률을 지금 숫자로 말할 수 있습니까?
AIM 05

모델 하나에 묶지 마십시오

특정 모델·특정 공급자에 하드코딩된 서비스는 아무리 잘 작동해도 Native가 되지 못합니다. 강등 경로가 곧 자격 요건입니다.

확인 질문오늘 그 모델이 멈추면 무슨 일이 일어납니까?
AIM 06

결과가 기준을 고치게 하십시오

지표가 쌓이기만 하고 자동화 범위나 판정 기준을 바꾸지 않으면 회로가 닫히지 않습니다. 환류가 Native의 마지막 관문입니다.

확인 질문지난 분기 지표 때문에 바뀐 규칙이 하나라도 있습니까?
자주 나오는 미달 사례
  • 화면에 AI 버튼만 추가하고 흐름은 그대로 둔 경우
  • 시연 영상은 있으나 운영 지표가 하나도 없는 경우
  • 자동 처리는 되는데 되돌리는 절차가 없는 경우
  • 도구 개수는 늘었으나 업무 결과로 이어지지 않은 경우
  • 지표는 쌓이지만 아무 규칙도 바뀌지 않는 경우
  • 모델 한 곳에 묶여 대체 경로가 없는 경우