AX 전환, 실무 프레임으로의 전환 — 7단계 이행절차
사고실험에서 실무로
지난 글에서 "대한민국 행정부 전체의 업무를 AI로 전환한다면" 이라는 극단적인 사고실험을 통해 7단계 이행절차를 도출했습니다. 그 사고실험은 AX 전환이 기존 ISP/ISMP와 본질적으로 어떻게 다른지를 드러내는 데 유효했다고 생각합니다. 숲 속에서 헤메고 있다가 숲에서 나와 드론을 띄워서 숲의 전체 형태를 이해하기 위한 작업이라 말할 수 있습니다.
하지만 사고실험은 어디까지나 사고실험일 뿐입니다. 실제 AX 컨설팅 프로젝트는 국가 행정부 전체가 아니라 특정 기관의 특정 업무 영역을 대상으로 이행됩니다. 그래서 사고실험의 7단계를 실무에 적용할 수 있도록 하려면 두 가지를 방향 전환이 필요합니다.
첫째, 대상의 범위를 확정하는 것 자체가 프로젝트의 핵심 과업이 됩니다. 사고실험에서는 "행정부 전체"라고 전제했지만, 실무에서는 "이 기관의 어떤 업무를, 어느 수준까지 전환할 것인가"를 판단하는 과정이 방법론 안에 들어와야만 합니다.
둘째, 컨설턴트가 직접 수행할 수 없는 영역의 성격이 변경됩니다. 대표적으로 사고실험의 4단계는 "법적 기반의 선행 정비"였지만, 실무에서 컨설턴트의 산출물은 법 개정이 아니라 "이 전환을 위해 이런 법적 정비가 선행되어야 한다"는 진단과 권고로 역할이 변경되어야 합니다.
전제 조건
이 글에서 다루는 AX 전환 이행절차는 다음의 두가지 전제를 기반으로 합니다.
대상 기관은 자체 전산센터를 운영하는 기관입니다.
GPU 서버 도입을 위해 전력 증설, 냉방 설비 확충, 시스템 하중 보강 등 시설 공사까지 고려해야 하는 환경을 갖춘 기관 입니다.
자체 전산센터를 전제로 삼은 이유는, 이것이 가장 복잡한 사례이기 때문입니다. 클라우드 기반이나 외부 데이터센터를 이용하는 기관이라면 인프라 관련 단계를 축소하거나 생략하면 됩니다. 가장 복잡한 케이스에서 AX 이행절차를 설계해야 가벼운 케이스에도 적용할 때 무리가 없을 것으라 생각했습니다.
7단계 이행절차
1단계: 기관의 법적 목적과 업무 체계 정의
AX 전환의 출발점은 "지금 무엇을 하고 있는가"가 아니라 "이 기관이 무엇을 해야 하는가"입니다. 기관의 설립 근거 법령, 직제령, 시행규칙, 개별 법률의 위임 조항까지 내려가면서 해당 기관이 수행해야 하는 업무의 전체 목록을 법적 근거와 함께 확정해야 합니다. 이 과정에서 관행적으로 수행하고 있지만 법적 근거가 불분명한 업무, 반대로 법에는 있지만 실제로는 수행하지 않는 업무도 드러나게 됩니다.
그리고 각 단계별로 발주기관과 사업수행사의 역할을 포함했습니다. 이 글이 전체를 포괄하지는 못하더라도 AX 전환사업의 시작점에서 참고 정도는 될 것이라 생각합니다.
발주기관·사업담당자의 역할
기관의 설립 근거 법령, 직제령, 시행규칙 등 법적 문서 제공
현행 업무분장표 및 조직도 제공
법령에 없지만 관행적으로 수행 중인 업무, 법령에 있지만 실제 수행하지 않는 업무에 대한 식별
사업수행사의 역할
법령 및 하위 규정 분석을 통한 업무 체계 구조화
법적 근거 기반 업무 목록 작성
법령 근거 기반 목적 계층과 구조 계층 분리
관행적 업무와 법령 간 괴리 식별
산출물: 법적 근거 기반 업무 체계도
2단계: 업무의 본질 분류와 전환 대상 선별
정의된 업무를 성격별로 분류하고, 전환 대상과 범위를 확정하는 단계입니다. 분류의 축은 세 가지로 구성됩니다.
판단의 성격 — 재량행위인지 기속행위인지. "~할 수 있다"로 규정된 재량행위와 "~하여야 한다"로 규정된 기속행위는 AI 전환의 난이도와 법적 쟁점이 완전히 다릅니다.
책임의 귀속 — 해당 업무 결과에 대해 누가 법적 책임을 지는가. 행정처분 불복, 국가배상 등이 걸려 있는 업무는 기술적으로 가능하더라도 책임 귀속 구조를 먼저 정리해야 합니다.
대국민 영향도 — 개인의 권리·의무에 직접 영향을 미치는 침익적 행정행위인지, 내부 행정인지, 서비스 제공인지에 따라 요구되는 안전장치 수준이 달라집니다.
분류 후 각 업무에 대해 세 가지를 판별합니다. 첫번째, 기술적으로 가능한가(Can), 두번째, 법적으로 허용되는가(May), 세번째, 사회적으로 바람직한가(Should). 이 세 가지가 충족되는 영역부터 AI 전환 대상이 되어야 합니다.
이 과정에서 중요한 것은 정확하고 객관적 정보를 분석하고 추출하는 것입니다. 지난 글에서 다뤘듯이, AX 전환에서 설계의 출발점은 담당자의 개선에 대한 요구사항이 아니라 다음 세 가지 객관적 정보가 되어야만 합니다.
첫째, 기관의 법적 목적 — 이 기관이 법령에 의해 달성해야 하는 것.
둘째, 이해관계자의 요구 — 서비스를 받는 관계기관과 국민이 실제로 필요로 하는 것.
셋째, 누적된 업무 데이터 — 처리 건수, 소요 시간, 오류율 등 업무 수행이 남긴 객관적 흔적.
이 세 가지는 모두 "이 기관이 무엇을 달성해야 하는가"에 대한 법적 요구사항이 기반이 됩니다. 이 기반 위에서 설계해야 AX 전환이 "담당자를 위한 업무 개선"이 아니라 "기관 목적의 신속하고 정확한 달성"이 될 수 있습니다.
발주기관·사업담당자의 역할
각 업무의 실제 수행 방식에 대한 현업 부서 업무 분석 지원
재량/기속, 대국민 영향도 등에 대한 현업 부서의 확인·검증 지원
기관 차원의 AX 전환 전략적 우선순위 및 방향성 제시
사업수행사의 역할
업무의 본질 분류 수행 (재량/기속, 책임 귀속, 대국민 영향도)
기술적 가능성(Can) / 법적 권한식별(May) / 공익 추구(Should) 여부 분석
기관의 전략 방향과 분석 결과를 종합한 AX 전환 대상·범위 도출
담당자 인터뷰 시 도메인 지식과 요구사항의 분리
산출물: 업무 분류 매트릭스, 전환 대상 업무 목록 및 우선순위 분석
3단계: 현행 체계 진단
전환 대상으로 선별된 업무에 대해 현행 체계를 다섯 가지 영역(BA, AA, DA, TA, 인프라)에서 진단합니다. 이는 기존 ISP/ISMP에서도 수행하는 현행(As-Is) 분석과 동일하지만 상세 내용은 조금 다릅니다.
첫번째는 업무 프로세스입니다. 현재 업무가 실제로 어떻게 수행되고 있는지, 법령이나 매뉴얼에 드러나지 않는 예외 상황, 맥락적 판단, 현장의 암묵지가 무엇인지를 파악합니다. 이것이 담당자로부터 얻어야 하는 도메인 지식입니다.
둘째는 데이터 입니다. AI 학습과 운영에 활용할 수 있는 데이터가 어디에, 어떤 형태로, 얼마나 있는지, 품질은 어떤지를 파악해야 합니다.
세번째는 어플리케이션 입니다. 현재 운영 중인 어플리케이션의 목록, 기능 범위, 기술 스택, 운영 상태를 파악합니다. AI 전환 시 대체·통합·연계 대상이 되는 어플리케이션을 식별하는 기초 자료가 됩니다.
네번째는 시스템 구성현황입니다. 현재 업무가 어떤 시스템 위에서 수행되고 있는지, 시스템 간 연계 구조는 어떻게 되어 있는지, 레거시 시스템의 아키텍처는 어떤 상태인지를 파악합니다. 이 분석이 없으면 To-Be 설계가 현행 시스템과의 접점 없어져 곤란함을 겪게 됩니다.
마지막으로 인프라 현황 입니다. 자체 전산센터를 운영하는 기관의 경우, 이 진단이 특히 중요합니다. 전력 공급 용량과 현재 사용량, 냉방 설비 용량과 여유분, 전산실 바닥 하중 설계치, 네트워크 구성 등을 파악해야 합니다. 이 진단 결과가 5단계 설계의 물리적 제약 조건과 연결됩니다.
발주기관·사업담당자의 역할
업무 프로세스 관련 자료 제공 (업무 매뉴얼, 처리 절차서 등)
데이터 현황 자료 제공 (보유 데이터 목록, 시스템 간 데이터 흐름, 데이터 품질 현황)
시스템 구성 및 어플리케이션 현황 자료 제공 (시스템 구성도, 연계 현황, 어플리케이션 목록, 기술 스택 등)
인프라 현황 자료 제공 (전력 공급 용량, 냉방 설비 용량, 바닥 하중 설계치, 네트워크 구성도)
현업 부서 및 전산센터 관리 부서와의 협조 채널 확보
사업수행사의 역할
업무 프로세스 분석 — 담당자 인터뷰에서 도메인 지식을 추출하되, 요구사항과의 분리를 수행
데이터 현황 분석 — AI 학습·운영 활용 가능 데이터의 품질·양 평가
시스템 구성 분석 — 시스템 간 연계 구조, 레거시 아키텍처 상태 진단
어플리케이션 분석 — 운영 중 어플리케이션의 기능 범위·기술 스택 파악 및 AI 전환 시 대체·통합·연계 대상 식별
인프라 격차 분석 — GPU 서버 도입 시 필요한 전력, 냉방, 하중 요구량 산정 및 현재 여유분과의 격차 도출
산출물: 현행 체계 진단서 (업무 프로세스, 데이터, 시스템, 어플리케이션, 인프라 현황 및 격차 분석)
4단계: 법적·제도적 제약 식별
전환 대상 업무에 대해 현행 법령 상 AI 수행이 가능한지, 제약이 있다면 구체적으로 어떤 조항이 문제인지를 식별하는 단계입니다.
이 단계에서 컨설턴트의 역할은 법을 정비하는 것은 아닙니다. "이 업무를 AI로 전환하려면 어떤 법령의 어떤 조항이 장애가 되며, 어떤 방향으로 정비가 필요한가"를 진단하고 권고하는 것이 컨설턴트의 역할 입니다.
발주기관·사업담당자의 역할
해당 업무에 적용되는 개별 법령, 내부 규정, 행정규칙 제공
기존 법적 검토 사례 공유
기관 법무 담당 부서와의 협의 채널 확보
사업수행사의 역할
전환 대상 업무별 현행법상 AI 수행 가능 여부 분석
인공지능 기본법, 행정절차법, 전자정부법, 개인정보보호법 등 관련 법령과의 충돌 분석
정비 필요 법령·규정의 목록 및 정비 방향 도출
산출물: 법적 제약 분석서 및 정비 권고안 수립
5단계: To-Be 업무 구조 및 인프라 설계
ISP/ISMP에서 목표모델 설계는 보통 BA, AA, DA, TA, 인프라 다섯 개 영역으로 나뉩니다. AX에서도 이 프레임 자체는 유효합니다. 설계해야 할 영역의 분류가 바뀌는 것이 아니라, 각 영역 안에서 설계의 전제와 주요 목표모델이 변경되는 구조입니다.
BA(Business Architecture) — 업무 아키텍처
기존 ISP/ISMP에서는 기존 조직 구조와 업무분장을 상수로 두고, 그 위에서 프로세스를 개선하는 방식이었습니다. "지금 이 부서에서 이 업무를 하고 있으니, 이 프로세스를 어떻게 효율화할 것인가"가 질문이자 과제였습니다.
AX에서는 이 전제가 깨집니다. 수행 주체가 바뀌기 때문에 업무 프로세스만 개선하는 것이 아니라 업무 자체를 재설계해야 합니다. 조직의 인지적·물리적 한계를 전제로 분리되어 있던 업무가 통합될 수 있고, 계층적 결재 구조가 실시간 판단 체계로 대체될 수 있습니다. 1단계에서 분리한 목적 계층은 유지하되, 구조 계층은 변수로 놓고 재설계하는 것이 BA의 핵심입니다. 이 영역이 ISP/ISMP와 가장 크게 달라지는 지점입니다.
발주기관·사업담당자의 역할
기관의 전략적 방향과 우선순위 제시
To-Be 업무 구조 재설계안에 대한 내부 검토 및 수용 가능성 판단
업무 통합이나 결재 구조 변경에 대한 부서 간 합의 주도
사업수행사의 역할
목적 계층 기반의 업무 재설계 수행
AI 수행 전제의 프로세스·의사결정 구조·부서 간 업무 흐름 설계
기존 구조 계층의 어떤 부분이 해소되고 어떤 부분이 유지되는지 판별
AA(Application Architecture) — 어플리케이션 아키텍처
기존 ISP/ISMP에서는 업무 기능을 지원하는 어플리케이션을 설계했습니다. "이 업무를 지원하기 위해 어떤 시스템이 필요하고, 시스템 간 연계는 어떻게 할 것인가"가 설계의 내용이었습니다.
AX에서는 어플리케이션의 성격 자체가 달라집니다. AI 모델이 업무를 수행하는 구조이므로, 기존의 "사용자가 조작하는 업무 시스템" 외에 AI 모델 서빙, AI 에이전트 구조, 사람-AI 인터페이스 (감독·검증·예외처리 화면) 같은 새로운 어플리케이션 유형이 들어옵니다. 기존 어플리케이션 중 어떤 것은 대체되고, 어떤 것은 AI와 연계되며, 어떤 것은 그대로 유지되는지를 판별하고, 이를 통합된 어플리케이션 구조로 설계해야 합니다.
발주기관·사업담당자의 역할
현행 어플리케이션의 운영 현황 및 사용자 피드백 제공
대체·유지·연계에 대한 내부 의사결정
AI 감독·검증·예외처리 화면에 대한 실무적 요구사항 확인
사업수행사의 역할
기존 어플리케이션의 대체·통합·연계·유지 판별
AI 모델 서빙 구조 및 에이전트 아키텍처 설계
담당자-AI 인터페이스(감독·검증·예외처리 화면) 설계, 통합된 어플리케이션 구조도 작성
DA(Data Architecture) — 데이터 아키텍처
기존 ISP/ISMP에서도 데이터 아키텍처는 핵심 영역이었습니다. 데이터 모델, 데이터 흐름, 마스터 데이터 관리 같은 설계는 AX에서도 동일하게 필요합니다.
달라지는 부분은 AI 특화 데이터 흐름이 추가된다는 점입니다. AI 학습을 위한 훈련 데이터 파이프라인, 추론 시 입출력 데이터 흐름, AI 판단 결과에 대한 피드백 데이터 수집과 재학습 순환 구조 등이 그것입니다. 전통적 데이터 아키텍처가 "저장과 조회"에 초점이 있었다면, AX의 데이터 아키텍처는 "학습-추론-피드백-재학습"이라는 순환 구조까지 설계해야 합니다.
발주기관·사업담당자의 역할
보유 데이터에 대한 접근 권한 및 활용 범위 결정
개인정보·민감정보 포함 데이터의 AI 학습 활용 가능 여부에 대한 기관 차원의 판단
데이터 거버넌스 체계 수립에 대한 의사결정
사업수행사의 역할
전통적 데이터 모델·데이터 흐름·마스터 데이터 관리 설계
AI 훈련 데이터 파이프라인 설계
추론 시 입출력 데이터 흐름 설계
피드백 수집 및 재학습 순환 구조 설계
데이터 품질 관리 방안 수립
TA(Technical Architecture) — 기술 아키텍처
기존 ISP/ISMP에서는 웹-WAS-DB 3계층 구조, 미들웨어, 개발 프레임워크 같은 전통적 기술 스택을 설계했습니다.
AX에서는 여기에 AI 고유의 기술 계층이 추가됩니다. AI 프레임워크, MLOps 파이프라인(모델 학습-배포-모니터링-재학습의 자동화), 모델 서빙 인프라가 그것입니다. 그리고 앞서 언급하신 클라우드 네이티브 전환 여부가 바로 이 TA 영역의 핵심 의사결정입니다. 컨테이너 기반 운영, 마이크로서비스 구조로의 전환 여부에 따라 TA 전체의 설계 방향이 달라집니다. 기존 ISP/ISMP의 기술 스택 설계 위에 AI 기술 계층과 클라우드 네이티브 아키텍처를 중첩해서 설계하는 구조가 됩니다.
발주기관·사업담당자의 역할
클라우드 네이티브 전환 여부에 대한 기관 차원의 의사결정
보안 정책과의 정합성 검토(컨테이너 운영, 외부 클라우드 연계 등에 대한 기관 보안 기준 제시)
기술 스택 변경에 따른 운영 인력 확보 계획
사업수행사의 역할
AI 프레임워크 선정 및 기술 스택 설계
MLOps 파이프라인(모델 학습-배포-모니터링-재학습 자동화) 설계
클라우드 네이티브 전환 시 컨테이너·마이크로서비스 아키텍처 설계
기존 기술 스택과 AI 기술 계층의 통합 구조 설계
인프라(Infrastructure)
ISP/ISMP에서는 x86 서버, SAN/NAS 스토리지, 네트워크 장비 같은 전통적 인프라를 산정했습니다. 전력과 냉방은 기존 설비 범위 안에서 해결되는 경우가 대부분이었습니다.
AX에서는 GPU 서버가 들어오면서 인프라의 성격이 근본적으로 바뀝니다. GPU 서버는 전력 소모가 기존 서버의 수배에서 수십 배이고, 그에 비례해서 냉방 부하가 증가하며, 물리적 무게도 상당합니다. 그래서 인프라 설계가 IT 장비 사양 산정에서 시설 공사 설계로 확장됩니다. 전력 증설, 냉방 설비 확충, 바닥 하중 보강, 경우에 따라서는 고속 인터커넥트를 위한 네트워크 배선까지. 이것이 자체 전산센터를 전제로 놓은 이유이기도 합니다.
정리하면, 다섯 개 영역의 프레임 자체는 ISP/ISMP와 동일합니다. 하지만 BA는 "개선"에서 "재설계"로, AA는 AI 모델 서빙과 인간-AI 인터페이스라는 새로운 유형이 추가되고, DA는 학습-추론-피드백 순환 구조가 추가되며, TA는 MLOps와 클라우드 네이티브가 핵심 의사결정으로 들어오고, 인프라는 IT 장비에서 시설 공사까지 범위가 확장됩니다.
발주기관·사업담당자의 역할
전력 증설, 냉방 설비 확충, 하중 보강 등 시설 공사에 대한 예산 확보
시설 관리 부서와의 조율 및 공사 일정 협의
네트워크 보안 정책 및 물리적 보안 기준 제시
사업수행사의 역할
GPU 서버 규모·스토리지·네트워크 사양 산정
전력·냉방·하중 보강 범위 및 사양 도출
고속 인터커넥트 등 네트워크 배선 설계
시설 보강 사양서 작성
6단계: 담당자 역할 재정의와 조직 변화 설계
AI가 업무를 수행하더라도, 담당자가 반드시 수행해야 하는 역할이 있습니다. 최종적인 책임과 판단의 귀속, AI 시스템에 대한 감독과 통제, 예외 상황에서의 판단, 국민과의 직접적 소통이 그것입니다.
이 단계에서는 전환 후 담당자의 역할이 어떻게 바뀌는지를 구체적으로 정의하고, 그에 따른 조직 구조 변화와 역량 전환 계획을 수립합니다.
발주기관·사업담당자의 역할
인사 부서, 현업 부서장 등과의 조율
역할 재정의에 대한 조직 내부 합의 주도
인사 부서, 현업 부서장 등과의 조율
재교육·역량 전환에 대한 기관 차원의 자원 배분 결정
사업수행사의 역할
전환 후 담당자 역할 정의 — AI 감독, 예외 처리, 산출물 검증 등
새로운 역할에 필요한 역량 요건 도출
역량 전환 교육 계획 수립
조직 구조 변화안 도출
산출물: 역할 재정의서, 역량 전환 계획서, 조직 변화안
7단계: 전환 로드맵 수립과 단계적 이행 계획
한꺼번에 전환하는 것은 현실적으로 불가능 합니다. 위험도가 낮고 효과가 큰 영역부터 전환하면서 검증하고, 점진적으로 확대하는 로드맵 수립과 이행방안이 필요합니다.
이 단계에서는 세 가지 시간축을 종합해서 고려해야 합니다. 인프라 구축의 리드타임(전력 증설, 하중 보강 등 시설 공사는 설계-발주-시공까지 상당한 기간이 소요된다), 법적 정비의 소요 시간, 조직 변화의 수용 속도. 이 세 가지 중 가장 긴 것이 전체 로드맵의 병목이 될 수 있기에 적절한 계획수립과 조율이 필요합니다.
발주기관·사업담당자의 역할
연도별 예산 확보 계획 제시
조직 변화의 수용 가능 속도 판단
대외 일정(감사, 국정과제 보고 등) 등 현실적 제약 조건 제시
이행 로드맵에 대한 기관장 보고 및 승인
사업수행사의 역할
인프라 구축 리드타임, 법적 정비 소요 시간, 조직 변화 수용 속도를 종합한 이행 로드맵 수립
단계별 이행 순서 및 일정 확정
각 단계의 착수 조건과 검증 기준 정의
산출물: 전환 로드맵, 단계별 이행 계획서
마무리 하면서
발주기관 역할의 본질적 변화
7단계를 관통하는 특징이 하나 있습니다. 전통적 ISP/ISMP에 비해 발주기관의 역할이 근본적으로 무거워진다는 것입니다. 그리고 수행사가 분석하고 설계해야 할 일도 많이 증가하게 됩니다.
전통적으로 ISP/ISMP에서 발주기관은 주로 자료 제공, 인터뷰 응대, 검토·승인 역할이었습니다. 사업수행사가 분석하고 설계한 것을 확인하고 승인하는 구조였던 거죠.
그런데 AX에서는 달라집니다. 기관의 전략적 방향 제시, 조직 내부의 합의 형성, 시설 공사 조율, 인사·조직 변화 관리, 예산 확보까지 — 발주기관이 능동적으로 의사결정하고 주도해야 하는 영역이 대폭 증가하게 됩니다.
이것은 AX 사업의 발주기관 담당자에게 요구되는 역할의 본질적 변화이기도 합니다. 그리고 이 변화를 사업 착수 전에 발주기관이 인식하고 준비하는 것이, AX 전환의 성패를 가르는 첫 번째 조건이 될 수 있습니다.
사업수행사 역할의 본질적 변화
발주기관만 무거워지는 것이 아닙니다. 사업수행사 역시 근본적으로 달라져야 합니다.
전통적 ISP/ISMP에서 수행사의 핵심 역량은 업무분석과 정보시스템 설계였습니다. 현업을 인터뷰하고, 요구사항을 수집하고, 이를 시스템 설계로 전환하는 것. 투입 인력도 IT 컨설턴트와 시스템 아키텍트 중심으로 구성하면 충분했습니다.
AX에서는 수행사에게 요구되는 역량의 폭이 전혀 다른 수준으로 넓어집니다. 법령 분석에서 출발해서 업무의 본질 분류, AI 기술 판별, 데이터 파이프라인 설계, MLOps 아키텍처, 클라우드 네이티브 설계, GPU 인프라 사양 산정, 전력·냉방·하중 같은 시설 영역까지. 한 프로젝트 안에서 법률 해석, 업무 재설계, AI 엔지니어링, 인프라 설계가 동시에 요구됩니다. 이것은 기존 ISP/ISMP 수행 조직의 구성으로는 감당할 수 없는 범위입니다.
인력의 양만 늘어나는 것이 아닙니다. 인력의 구성 자체가 달라져야 합니다. AI 모델링과 MLOps를 아는 엔지니어, 법령 분석이 가능한 컨설턴트, 데이터 아키텍트, 클라우드 네이티브 설계가 가능한 기술 아키텍트, 그리고 GPU 인프라의 물리적 조건까지 설계할 수 있는 인프라 전문가가 한 팀에 있어야 합니다. 기존에는 한 명의 시니어 컨설턴트가 BA부터 인프라까지 총괄하는 것이 가능했지만, AX에서는 각 영역의 전문성이 깊어져서 한 사람이 전 영역을 관통하기 어렵습니다.
이것은 수행사의 사업 수행 체계에도 영향을 줍니다. 단일 수행사가 모든 역량을 보유하기 어렵다면, 컨소시엄 구성이나 전문 영역별 협력 구조가 필수적이 됩니다. 그리고 발주기관의 제안요청서(RFP) 역시 이러한 역량 구성을 반영해서 작성되어야 합니다. 기존 ISP/ISMP의 RFP 구조로 AX 사업을 발주하면, 수행사가 적절한 인력을 투입할 수 있는 근거 자체가 만들어지지 않습니다.
결국 AX 전환은 발주기관과 수행사 양쪽 모두에게 역할의 전환을 요구합니다. 발주기관은 자료 제공자에서 능동적 의사결정자로, 수행사는 시스템 설계자에서 기관 변혁의 설계자로. 이 양쪽의 변화가 함께 이루어지지 않으면 AX 전환은 이름만 바뀐 ISP/ISMP로 귀결될 수밖에 없습니다.