행정부 업무 전체를
AI로 전환한다면
누구의 요구사항으로 AI를 설계할 것인가
극단적 질문을 하나 던져서 사고 실험을 해봤습니다.
이 사고 실험을 통해서 AX 전환 컨설팅이 기존 ISP/ISMP와 어떻게 다른지 감을 잡아보고자 했습니다.
대한민국 행정부 업무 전체를 AI로 전환하려고 한다.
이러한 전제에 따라 IT 컨설턴트가 던질 수 있는 질문은
대한민국 행정부의 모든 업무를 AI로 전환한다면, 어떤 절차를 거쳐야 할까?
행정부는 국민들의 합의와 법에 따라 대통령을 정점으로 총리, 각 부처 장관들이 업무를 위임받아 수행하는 트리 구조 입니다. 만약 행정부 전체의 업무를 AI 전환(AX)하려 한다면 어떤 절차를 거쳐야 하는지 생각해 봤습니다.
1단계: 법적 근거에 기반한 업무의 완전한 정의
2단계: 업무의 본질 분류 (재량/기속, 책임 귀속, 대국민 영향도)
3단계: 전환 가능성과 조건의 판별 (기술적으로 가능한가, 법적으로 허용되는가, 사회적으로 바람직한가) 4단계: 법적 기반의 선행 정비
5단계: To-Be 업무 구조 재설계
6단계: 담당자 역할 재정의
7단계: 단계적 전환과 검증
현실적으로 행정부 전체를 AI로 전환하는 일은 일어나지 않을 것입니다. 그럼에도 이 사고실험을 통해 알 수 있는 것 중 하나는 1단계부터 5단계까지 기존 ISP/ISMP의 수행 범위를 완전히 벗어나며 현재 시점을 기준으로 법령과 규정으로 정의되어 있지 않은 프로세스라는 것입니다.
ISP/ISMP가 전제하는 숨겨진 두 가지
1단계 부터 5단계까지 기존 ISP/ISMP의 수행 범위를 벗어난다는 것을 설명하기 위해서는, ISP/ISMP에는 명시적이든 암묵적이든 두 가지 전제가 깔려 있다는 사실을 먼저 알아야만 합니다.
첫째, 기존 틀은 유지한다.
조직 구조, 업무 프로세스, 법적 체계는 주어진 상수다.
ISP/ISMP는 이 상수 위에 정보시스템을 얹는 작업이다.
둘째, 업무의 수행 주체는 담당자이다.
정보시스템은 인간이 업무를 더 잘 수행하도록 돕는 도구이지, 담당자를 대체하는 주체가 아니다.
AX 전환은 이 두 전제를 동시에 깨뜨려야 제대로 된 AX 전환의 결과물을 얻을 수 있습니다. 업무 수행의 주체가 변경되고, 조직의 인지적·물리적 한계를 전제로 만들어진 기존의 트리 구조, 결재 체계, 부처 분류 같은 틀 자체가 유효하지 않게 됩니다. 틀을 재설계해야 하는 이유가 "더 큰 변화라서"가 아니라, 수행 주체의 본질이 바뀌면서 기존 틀의 존재 근거 자체가 해소되기 때문입니다.
물론 수행 주체가 바뀐다는 것은 많은 사람들의 일자리와 직결되는 문제입니다. 그래서 이것은 사회적 합의와 법·제도 그리고 복지제도의 보강이 선행적으로 토론되고 합의가 되어야 하는 영역입니다.
이러한 일자리 문제 등은 여기서 다루기에는 너무 거대한 문제이고 다루고자 하는 주제의 본질에도 맞지 않기 때문에 AX 컨설팅 방법론의 관점에서만 계속 이야기를 이어가려 합니다.
누구의 요구사항으로 설계하는가
ISP/ISMP에서는 현업 담당자 인터뷰가 요구사항 수집의 주요 방안 중 하나 입니다. "지금 업무에서 어떤 점이 불편하세요?", "어떤 시스템이 필요하세요?" — 이런 질문을 통해 기존 업무를 개선하기 위해 지원 시스템을 구축하는 것을 목적으로 하다보니, 업무를 가장 잘 아는 담당자에게 묻고 의견을 반영하는 것이 당연한 것이었습니다.
AX 전환사업에서 같은 방식으로 담당자에게 물으면 두 가지 문제가 발생합니다.
첫번째는 현상 유지 편향 입니다.
담당자의 요구사항은 "지금 내가 하는 일을 더 편하게 해달라"는 방향으로 수렴하게 마련 입니다.
비유를 하자면 마차를 더 좋은 마차로 개선하는 요구사항이지, 자동차를 설계하는 데 필요한 정보를 제공하진 못합니다.
두번째는 구조적 이해충돌 입니다.
자신의 업무가 재설계 대상인 업무 담당자에게 재설계의 방향을 묻는 것은, 객관적인 답을 기대하기 어려운 구조입니다. 이것은 담당자 개인의 문제가 아니라 분석 구조 자체의 문제입니다.
그래서 AX에서 요구사항의 진짜 원천은 담당자가 아니라 다른 곳에 있어야 한다.
조직의 법적 목적 — 이 조직이 법령에 의해 달성해야 하는 것
관계기관과 국민의 요구 — 서비스를 받는 쪽에서 실제로 필요로 하는 것
누적된 결과 데이터 — 지금까지의 업무 수행이 남긴 객관적 흔적
이 세 가지는 모두 "이 조직이 무엇을 달성해야 하는가"에 대한 객관적 정보가 됩니다. AX 전환의 설계는 이 세가지를 분석하는 것에서 출발해야 합니다.
그러면 담당자는 필요 없는가
결코 그렇지 않습니다. 담당자의 의견과 지식은 AX 전환사업에서 꼭 필요합니다. 다만 담당자에게서 얻어야 하는 정보가 바뀌는 것입니다.
AX에서 담당자는 "요구사항의 원천"이 아니라 "도메인 지식의 원천" 역할을 해야 합니다.
“도메인 지식의 원천”이라는 표현을 설명하자면 법령에 드러나지 않는 예외 상황, 데이터에 기록되지 않는 맥락적 판단, 현장에서 체득한 암묵지 등을 의미합니다. 이런 것들은 담당자만 가지고 있는 고유하고 귀중한 정보입니다.
다시 한번 요구사항과 도메인 지식의 차이를 정확히 이해할 필요가 있습니다.
요구사항은 "나는 이것이 필요하다"는 형태 입니다.
미래에 대한 주장이고, 화자의 이해관계가 반영되어 있습니다.
예를 들어 민원 처리 담당자가 "민원 접수 화면에 자동 분류 기능이 있으면 좋겠다"고 말하면, 이것은 요구사항 입니다.
도메인 지식은 "실제로는 이렇게 작동한다"는 형태다.
현실에 대한 사실 진술이고, 화자의 희망과는 무관하게 존재하는 정보입니다.
같은 담당자가 "법령상으로는 유형 A와 B로 구분되지만, 실제로는 경계가 모호한 경우가 30% 정도 되고, 그때는 민원인의 진술 맥락을 보고 판단한다"고 말하면, 이것은 도메인 지식입니다.
요구사항에는 "이렇게 해주면 내 업무가 편해진다"는 이해관계가 내포되어 있고, 도메인 지식에는 "이런 경우에는 이런 일이 발생한다"는 인과관계가 내포되어 있습니다. 요구사항은 더 나은 대안이 있을 수 있지만, 도메인 지식은 대안의 문제가 아니라 그 자체가 분석과 설계의 제약 조건이 됩니다.
분리의 책임은 누구에게 있는가
현장에서 담당자가 이 둘을 구분해서 말해줄 수 있을까요?
솔직하게 말하면, 기대하기 어렵습니다. 그리고 기대해서도 안 된다 생각합니다.
담당자와의 인터뷰 시 요구사항과 도메인 지식은 섞여 있을 가능성이 높습니다. "이 민원은 유형이 모호한 경우가 많아서(도메인 지식), 자동 분류 기능이 있으면 좋겠다(요구사항)" — 이런 식으로. 업무를 잘 아는 사람일수록 사실 진술과 개선 의견이 자연스럽게 뒤섞이게 됩니다.
그렇기 때문에 요구사항과 도메인 지식의 분리 책임은 담당자가 아니라 컨설턴트에게 있습니다.
담당자는 자기가 아는 것을 자기 방식대로 이야기하면 됩니다. 그 이야기 속에서 도메인 지식과 요구사항을 분류하고, 도메인 지식은 설계의 제약 조건으로 수용하고, 요구사항은 조직 목적과 데이터에 비추어 별도로 검증하는 것 — 이것이 AX 컨설턴트의 고유한 역할입니다.
이것을 방법론에 반영하면 인터뷰 설계 자체가 달라져야 합니다. 전통적 ISP에서는 "어떤 기능이 필요하십니까?"라고 묻지만, AX에서는 다르게 질문을 해야 합니다.
"이 업무에서 판단이 필요한 순간은 언제입니까?"
"그 판단의 근거는 무엇입니까?"
"예외적인 상황은 어떤 것들이 있습니까?"
담당자에게 구분을 요구하는 것이 아니라, 질문의 구조가 자연스럽게 도메인 지식을 끌어내도록 설계하는 것이 중요합니다.
정리
AX 전환에서 설계의 입력이 바뀝니다. 전통 ISP/ISMP에서는 담당자의 요구사항이 설계의 출발점이었지만, AX에서는 조직의 목적, 이해관계자의 요구, 누적 데이터가 출발점이 되어야 합니다.
담당자의 역할은 요구사항의 원천에서 도메인 지식의 원천으로 전환되어야 합니다. 그리고 이 둘을 분리하는 것은 담당자의 몫이 아니라, AX 컨설턴트의 역량이자 방법론이 설계해야 하는 영역입니다.