소프트웨어 기술자 구분 (등급제 → IT직무제)
1. 개요
가. 정의
기술자 등급제는 경력·학력·자격을 점수화해 초급·중급·고급·특급으로 나누던 인력 분류 체계이고, IT직무제는 수행하는 직무(job)와 실제 역량 수준(competency) 을 기준으로 인력을 분류하는 역량 중심 체계다.
두 제도의 본질적 차이는 "무엇으로 사람을 평가하는가"에 있다. 등급제는 투입 인력의 이력(input) — 몇 년 일했고, 어느 학교를 나왔으며, 어떤 자격증이 있는가 — 을 점수화한다. 반면 IT직무제는 수행하는 직무와 그 직무에서 요구되는 역량의 도달 수준(competency) 을 본다. 관점이 "얼마나 오래"에서 "어떤 일을, 얼마나 잘"로 이동한 것이 핵심이다.
이 주제를 이해할 때 유의할 점은, "등급제 vs 직무제"가 단순한 인사 분류의 문제가 아니라 SW 산업의 대가(비용) 산정 체계 전체와 맞물린 구조적 사안이라는 것이다. 기술자를 어떻게 구분하느냐가 곧 발주 금액을 어떻게 계산하느냐를 결정하기 때문에, 분류 체계의 전환은 산업의 돈 흐름과 인재 유인 구조를 동시에 바꾸는 일이다. 기술사 관점에서 이 주제를 다룰 때 "분류 방식"과 "대가 산정"과 "인력 처우"를 하나로 엮어 보아야 하는 이유가 여기에 있다.
나. 등장 배경
과거 SW 산업은 기술자 등급제에 기반해 인건비(노임단가)를 산정했다. 발주 대가를 계산할 때 "특급 몇 명, 고급 몇 명"으로 투입 인력의 등급을 세고 등급별 단가를 곱하는 방식이었다. 등급이 곧 단가였기에 계산은 단순하고 다툼의 여지가 적었지만, "몇 년 일했는가"가 "무엇을 얼마나 잘하는가"를 대신하는 연공서열형 평가라는 근본 문제를 안고 있었다.
이 문제는 SW 직종의 특성과 정면으로 충돌한다. 물리적 노동은 경력이 쌓일수록 숙련도가 대체로 비례하지만, 소프트웨어 개발은 같은 10년 차라도 생산성과 산출물 품질의 편차가 수 배에 이를 만큼 크다. 뛰어난 신진 개발자가 경력만 앞선 인력보다 낮은 단가로 평가받는 왜곡이 상시적으로 발생한 것이다. 이에 정부는 2012년 SW기술자 신고제(등급제) 관련 규정을 폐지하고, 직무와 역량 중심의 IT직무제로의 전환을 추진했다.
등급제가 오래 유지될 수 있었던 이유도 함께 이해할 필요가 있다. 공공 SW 사업의 대가 산정은 예산 편성·감사와 직결되므로, 발주 기관은 "누가 봐도 이견이 없는" 객관적 기준을 선호했다. 경력·학력·자격은 서류로 검증 가능한 명확한 수치였기에 등급제는 행정 편의성 측면에서 강력했다. 문제는 그 편의성이 "실력을 보상하지 못한다"는 근본 결함을 가리고 있었다는 점이며, SW가 국가 핵심 산업으로 커지면서 이 결함의 비용이 더는 감당할 수 없을 만큼 커진 것이 전환의 배경이다.
다. 필요성
IT직무제의 필요성은 전문성에 대한 정당한 보상에서 나온다. 역량이 뛰어난 개발자가 경력만 앞선 인력보다 낮게 평가받으면 우수 인재는 산업을 떠나고, 발주 대가도 실제 창출 가치와 어긋난다. 이는 개인의 불만을 넘어 SW 산업 전체의 경쟁력 저하로 이어지는 구조적 문제다.
직무·역량 기반 분류는 이런 왜곡을 바로잡는 출발점이다. 발주자는 "특급 1명" 대신 "클라우드 아키텍처 설계가 가능한 시니어 아키텍트"처럼 필요한 역량을 명확히 요구할 수 있고, 그에 맞는 대가를 합리적으로 산정할 수 있다. 나아가 개인에게는 "주니어 개발자 → 시니어 개발자 → 아키텍트/기술리더"와 같은 경력개발 경로(Career Path) 를 제시해, 연공이 아닌 역량으로 성장하는 동기를 부여한다. 이것이 산업 전체의 전문성을 끌어올리는 기반이 된다.
또한 IT직무제는 급변하는 기술 지형에 대한 대응력을 높인다. 클라우드·AI·보안처럼 새로 부상하는 직무는 경력 연수만으로 평가할 수 없고, 실제 역량으로 판별해야 한다. 등급제는 "새로운 직무"를 담을 그릇이 없어 신기술 인력을 제대로 보상하지 못하지만, 직무·역량 체계는 새 직무를 정의하고 그 수준을 매기는 방식으로 기술 변화를 흡수할 수 있다. 산업의 변화 속도가 빠를수록 역량 중심 분류의 이점이 커지는 것이다.
2. 등급제와 IT직무제의 개념·특징
가. 전환의 개념
flowchart LR
G["등급제<br/>경력·학력·자격 → 초/중/고/특급"] -->|"역량 중심 전환"| J["IT직무제<br/>직무·역량 수준 기반"]
G -.->|"단순·객관 산정"| GA["등급별 노임단가"]
J -.->|"전문성 반영"| JA["직무·역량 기반 대가"]
위 그림은 두 제도가 서로 다른 대가 산정 방식으로 이어짐을 나타낸다. 등급제는 "등급 → 등급별 노임단가"라는 직선적 경로로 대가를 뽑아내는 반면, 직무제는 "직무·역량 수준 → 그에 상응하는 대가"라는 경로를 취한다. 화살표가 상징하듯 전환의 방향은 명확하지만, 점선으로 표시한 대가 산정 경로가 아직 충분히 다져지지 않은 것이 현실이다.
등급제는 계산의 편의성이라는 뚜렷한 장점을 가졌다. 경력·학력·자격증이라는 객관적 자료로 등급을 매기므로 산정이 쉽고, 발주자와 수주자 사이의 다툼도 적었다. 공공 발주처럼 투명성과 감사 대응이 중요한 환경에서는 이런 명확성이 오래 선호되었다. 그러나 이 명확성은 "실제 산출물의 질과 무관하게 등급이 고정된다"는 대가를 치른다.
반면 IT직무제는 수행 직무와 그 직무에서 요구되는 역량 수준을 본다. 예컨대 국제 역량체계인 SFIA(Skills Framework for the Information Age) 는 직무를 여러 범주로 나누고 각 직무마다 요구 역량과 숙련 단계(레벨)를 정의한다. 국내에서는 NCS(국가직무능력표준) 가 IT 직무별 능력단위와 수준을 규정해 유사한 역할을 한다. 이런 체계는 "이 사람이 어떤 직무를, 어느 수준으로 수행할 수 있는가"를 기준으로 삼는다.
관점의 이동이 곧 제도 전환의 본질이다. 등급제가 "투입(input) 중심"이라면 IT직무제는 "역량·성과(competency) 중심"이며, 이는 SW를 노동시간의 합이 아니라 전문 역량의 발현으로 보는 시각의 전환을 의미한다.
IT직무제에서 말하는 "직무"는 단일한 것이 아니라 여러 갈래로 세분된다. 통상 IT 직무는 기획·컨설팅, 소프트웨어 개발(응용·시스템), 데이터베이스, 네트워크, 정보보안, IT 아키텍처, 프로젝트 관리 등으로 나뉘고, 각 직무 안에서 다시 수행 수준(예: 주니어/시니어/리드)이 구분된다. 등급제가 모든 개발자를 하나의 등급 사다리에 세웠다면, 직무제는 "무슨 일을 하는 사람인가"를 먼저 구분한 뒤 그 안에서 숙련도를 보는 2차원 구조인 셈이다. 이 구조가 더 정교한 대신, 직무별로 기준을 마련해야 하는 부담이 뒤따른다.
나. 비교
| 구분 | 기술자 등급제 | IT직무제 |
|---|---|---|
| 기준 | 경력·학력·자격 → 등급(초·중·고·특급) | 직무·역량 수준 분류 |
| 관점 | 투입 인력의 등급(연공) | 수행 직무·전문성 |
| 대가 산정 | 등급별 노임단가 | 직무·역량 기반 단가 |
| 장점 | 단순·객관적 산정, 감사 용이 | 전문성 반영·경력개발 유도 |
| 단점 | 연공서열·역량 미반영 | 현장 정착 미흡·기준 부재 |
표에서 주목할 대목은 두 제도의 장단점이 정확히 상충(trade-off) 한다는 점이다. 등급제의 최대 장점인 "단순·객관"이 곧 IT직무제의 약점(기준 부재·평가 곤란)이고, IT직무제의 장점인 "전문성 반영"이 곧 등급제의 약점(연공서열)이다. 이 상충 구조 때문에 전환이 단번에 이뤄지지 못하고, 뒤에서 볼 "제도와 현장의 간극"이 발생한다.
다. 구체적 상황 예시
차이가 실무에서 어떻게 드러나는지 두 가지 상황으로 살펴보자. 첫째, 뛰어난 5년 차 개발자가 있다고 하자. 등급제에서는 경력 연수에 따라 "중급"으로 고정되어, 실제로는 특급 수준의 아키텍처 설계를 해도 중급 단가만 받는다. 반대로 평범한 15년 차는 경력만으로 "특급" 단가를 받는다. 이 역전이 우수 인재의 이탈을 부르는 전형적 왜곡이다. 둘째, 발주 관점에서 "특급 2명, 고급 3명"이라는 등급 기반 요구는 어떤 역량이 왜 필요한지를 말해 주지 못한다. 반면 "클라우드 마이그레이션 설계 가능한 아키텍트 1명, MSA 개발 경험 시니어 2명"처럼 직무·역량으로 요구하면 사업 목적에 맞는 인력을 정확히 조달할 수 있다. 이처럼 두 제도의 차이는 단가표의 형식 차이가 아니라 인력의 가치를 얼마나 정확히 반영하느냐의 차이다.
3. 현행 IT직무제의 문제점
가. 문제의 구조
flowchart TD
P["제도 전환(등급제 폐지)"] --> GAP["제도와 현장의 간극"]
GAP --> P1["대가 기준 공백"]
GAP --> P2["역량 평가 곤란"]
GAP --> P3["인식·수용 부족"]
P1 --> R["현장은 여전히 등급 관행 유지"]
P2 --> R
P3 --> R
위 그림이 보여 주듯, 문제들은 개별적으로 존재하는 것이 아니라 "제도와 현장의 간극"이라는 하나의 뿌리에서 갈라져 나온다. 제도(등급제 폐지)는 앞서갔지만 이를 받쳐 줄 실행 기반(대가 기준·역량 평가·인식)이 뒤따르지 못하면서 현장은 옛 관행에 머무는 것이다. 세부 원인을 하나씩 짚어 본다.
제도는 바뀌었지만 현장은 여전히 등급제 관행에 머물러 있다는 것이 핵심 문제다. 가장 큰 원인은 대가 산정 기준의 공백이다. 등급제는 "특급 얼마, 고급 얼마"라는 명확한 숫자(등급별 노임단가)가 있었지만, 직무제는 이를 대체할 표준 단가·기준이 충분히 정비되지 않았다. 그 결과 발주자는 계약서에 여전히 "중급 이상" 같은 등급 표현을 쓰게 되고, 제도상 폐지된 등급이 실무 관행으로 살아남는 역설이 벌어진다.
두 번째 원인은 역량 평가의 곤란함이다. IT직무제가 작동하려면 "이 사람이 해당 직무 역량을 갖췄다"를 객관적으로 증명할 수 있어야 하는데, 이를 뒷받침할 표준 인증 체계가 미비하다. 자격증은 특정 지식의 보유는 증명하지만 실제 직무 수행 역량과는 괴리가 있고, 경력기술서는 주관적이다. 측정할 잣대가 불명확하니 발주자는 검증하기 쉬운 옛 기준(등급)으로 되돌아가게 된다.
세 번째 원인은 발주자·기업의 인식과 수용도 부족이다. 오랜 등급제 관행에 익숙한 발주 담당자에게 직무·역량 기반 발주는 낯설고, 잘못 적용하면 감사 지적을 받을 위험도 있다고 느낀다. 제도가 바뀌어도 그것을 실행할 사람들의 이해와 유인이 갖춰지지 않으면 현장은 관성대로 움직인다.
이 세 원인은 서로 맞물려 악순환을 이룬다. 대가 기준이 없으니 발주자가 등급을 쓰고, 등급을 쓰니 역량 인증 수요가 생기지 않으며, 역량 평가가 정착되지 않으니 대가 기준을 만들 근거 데이터도 쌓이지 않는다. 어느 한 고리만 끊어서는 전환이 완성되지 않고, 대가 기준·역량 인증·인식 개선을 동시에 추진해야 순환의 고리를 풀 수 있다는 점이 이 문제의 어려움이자 개선의 방향을 규정한다.
덧붙여, 이 문제는 SW 산업의 고질적 이슈인 저가 수주·다단계 하도급 구조와도 얽혀 있다. 대가 기준이 모호하면 발주 금액이 낮게 책정되기 쉽고, 그 부담이 하도급 단계로 내려가며 결국 현장 기술자의 처우 악화로 귀결된다. 즉 기술자 구분 제도의 미정착은 단순한 분류의 문제가 아니라 산업 전반의 대가·처우 왜곡과 연결된 구조적 사안임을 보여 준다.
나. 문제점 정리
| 문제점 | 내용 |
|---|---|
| 현장 미정착 | 발주·계약서에 여전히 등급 요구 |
| 대가 기준 혼선 | 직무제 기반 노임단가·산정 기준 부재/모호 |
| 역량 평가 곤란 | 객관적 역량 측정·검증 체계 미비 |
| 인식 부족 | 발주자·기업의 이해·수용 저조 |
4. 개선 방향
문제의 뿌리가 "제도와 현장의 간극"이므로, 개선도 간극을 메우는 실질 대책이어야 한다. 선언적 제도 변경만으로는 관행이 바뀌지 않으며, 발주자가 실제로 등급 대신 직무로 계약할 수 있게 만드는 구체적 수단이 필요하다. 아래 네 방향은 앞서 진단한 세 원인(대가 기준 공백·역량 평가 곤란·인식 부족)을 각각 겨냥하면서, 급격한 충격 없이 전환을 이끄는 데 초점을 둔다.
첫째, 직무제 기반 대가·노임 기준을 명확히 세운다. 발주자가 등급 대신 직무로 요구하려면 "이 직무의 시장 임금은 얼마"라는 근거가 있어야 한다. 이를 위해 SW사업 대가산정 가이드가 직무별 임금 실태조사에 기반한 기준을 제시하고, 사업 유형·난이도를 반영한 산정 방식을 정교화해야 한다.
이 대목에서 유의할 점은, 대가 산정 방식 자체도 "투입 인력 기반(맨먼스)"에서 "기능·가치 기반(기능점수 등)"으로 함께 진화해야 한다는 것이다. 인력을 어떻게 구분하든 대가를 여전히 "몇 명 × 며칠"로만 계산하면 역량의 차이가 대가에 반영되기 어렵다. 따라서 기술자 구분의 직무제 전환은 대가 산정 패러다임의 전환과 맞물려야 온전한 효과를 낸다. 두 개혁은 동전의 양면이다.
둘째, 표준 역량체계와 인증을 마련한다. SFIA·NCS 같은 표준 역량체계를 국내 실정에 맞게 정착시키고, 경력관리시스템과 연계해 "이 사람이 어떤 직무를 어느 수준으로 수행할 수 있는지"를 증명 가능하게 한다. 역량이 객관적으로 인증되어야 발주자가 안심하고 직무 기준으로 계약한다. 이때 인증은 자격증처럼 지식 보유만 확인하는 데 그치지 않고, 실제 프로젝트 수행 이력·성과와 연계된 형태여야 실효성이 있다. 경력관리시스템에 축적된 수행 이력을 직무·수준으로 구조화하는 것이 그 출발점이다.
셋째, 인식 제고와 공공부문 선도다. 발주 가이드·교육으로 담당자의 이해를 높이되, 민간이 먼저 움직이길 기다리기보다 공공 발주가 먼저 직무제를 적용해 시장을 선도하는 것이 효과적이다. 공공이 표준 계약서와 성공 사례를 만들면 민간이 뒤따르기 쉬워진다.
넷째, 단계적 전환(연착륙) 이다. 급격한 전환은 현장 혼란을 부르므로, 등급과 직무를 매핑해 한동안 병행 운영한 뒤 점진적으로 직무제로 이행한다. 예컨대 "특급 ≈ 시니어 아키텍트" 식의 대응표를 두면 기존 관행과의 충돌을 줄이면서 새 기준에 적응할 시간을 벌 수 있다.
네 가지 방향은 앞서 본 악순환의 세 고리(대가 기준·역량 인증·인식)에 정확히 대응하며, 단계적 전환이 이들을 시간축에서 이어 준다. 즉 개선은 개별 대책의 나열이 아니라 "무엇을 먼저, 무엇과 함께, 얼마의 속도로" 추진할지의 로드맵 설계 문제다. 특히 공공부문이 먼저 표준 계약서와 성공 사례를 만들어 시장에 신호를 주는 것이 전체 전환의 마중물 역할을 한다는 점이 실무적으로 가장 중요하다.
| 개선 방향 | 내용 |
|---|---|
| 제도 정비 | 직무제 기반 대가·노임 기준 명확화(임금 실태조사 연계) |
| 역량 인증 | 표준 역량체계(SFIA·NCS)·인증, 경력관리시스템 연계 |
| 인식 제고 | 발주 가이드·교육, 공공부문 선도 적용 |
| 단계적 전환 | 등급-직무 매핑 → 병행 운영 → 이행 |
네 방향은 독립적으로 작동하지 않고 상호 보강한다. 대가 기준이 서면 발주자가 직무로 요구할 유인이 생기고, 역량 인증이 갖춰지면 그 요구를 검증할 수 있으며, 인식 제고와 공공 선도가 이를 뒷받침하고, 단계적 전환이 충격을 완화한다. 따라서 개선은 "무엇부터"가 아니라 "함께, 순서 있게"의 관점에서 설계되어야 실효를 거둔다.
5. 심화: 국내외 동향과 유사 개념 연계
등급제에서 직무제로의 전환은 어느 한 시점에 완결되는 사건이 아니라, 제도·시장·문화가 함께 이동하는 장기적 과정이다. 아래에서는 이 전환을 둘러싼 국내외 동향과, 시험·실무에서 자주 함께 다뤄지는 유사·연계 주제를 정리한다.
IT직무제로의 전환은 한국만의 과제가 아니라, 글로벌 IT 인력 관리의 보편적 흐름과 맞닿아 있다. 영국에서 시작해 국제적으로 널리 쓰이는 SFIA는 이미 수많은 기업·정부의 인력 역량 관리 표준으로 자리 잡았고, 국내의 NCS와 이를 활용한 NCS 기반 채용·능력중심 채용 정책도 같은 방향을 가리킨다. 즉 "학력·연공이 아니라 실제 능력으로 사람을 평가한다"는 원칙은 이미 시대적 대세이며, SW 기술자 구분 문제도 이 큰 흐름의 한 갈래다.
유사·연계 주제로는 첫째, SW사업 대가산정 제도가 있다. 기술자 구분 방식이 곧 대가 산정의 기초 단위이므로, 등급제→직무제 전환은 대가산정 가이드의 개편과 함께 움직인다. 둘째, 소프트웨어 진흥법(2020년 전부개정)은 SW 산업 생태계와 기술자 처우 개선의 법적 기반을 제공하며, 원격지 개발·상용SW 우선구매 등과 함께 인력 제도 개선을 뒷받침한다. 셋째, SW 개발자 처우·주 52시간·상용SW 중심 전환 등 산업 구조 변화도 역량 중심 평가 정착의 배경을 이룬다.
SFIA를 조금 더 들여다보면 IT직무제의 지향점이 분명해진다. SFIA는 IT 관련 역량을 여러 범주(전략·설계·개발·운영·관리 등)로 나누고, 각 역량마다 자율성·영향력·복잡성·비즈니스 기여도 등의 관점에서 숙련 수준을 여러 단계로 정의한다. 즉 "몇 년 차"가 아니라 "얼마나 독립적으로, 얼마나 복잡한 문제를, 얼마나 넓은 영향 범위에서 다루는가"로 사람을 자리매김한다. IT직무제가 궁극적으로 추구하는 평가의 정교함이 바로 이런 다차원 역량 모델이며, 국내 제도도 이 방향으로 성숙해 가는 것이 과제다.
한편 민간 IT 기업들이 이미 자체적으로 직무·레벨 체계(예: 개발자 L1~L5, 직군별 트랙)를 운영하며 역량 기반 평가·보상을 실천하고 있다는 점도 주목할 만하다. 시장은 이미 역량 중심으로 움직이는데 공공 발주 제도만 등급제 관행에 머물러 있다면 그 괴리가 곧 제도 개선의 압력으로 작용한다. 민간의 앞선 실천을 공공 발주 기준으로 수렴시키는 것도 현실적인 정착 경로가 될 수 있다.
기술사 시험 관점에서 이 주제는 "SW사업 대가산정", "SW 진흥법", "인력 양성·처우 개선"과 엮여 출제되는 경향이 있다. 따라서 답안에서는 등급제/직무제의 정의 비교에 그치지 말고, 왜 전환이 필요한가(연공서열의 왜곡) → 무엇이 걸림돌인가(대가 기준 공백·평가 곤란) → 어떻게 정착시키는가(대가 기준 정비·역량 인증·단계적 전환) 의 논리 흐름으로 전개하면 완성도가 높다.
답안 구성 전략으로는, 개요에서 두 제도를 대비하는 표를 제시해 차이를 한눈에 보여 준 뒤, 본론에서 "현행 문제 → 개선 방향"을 원인-대책이 짝을 이루도록 구성하는 것이 효과적이다. 예컨대 "대가 기준 공백"이라는 문제에는 "직무별 임금 실태조사 기반 대가 기준"이라는 대책을, "역량 평가 곤란"에는 "표준 역량체계·인증"을 대응시키면 논리적 완결성이 높아진다. 마지막으로 시사점에서 "제도만 바꿔서는 안 되고 발주 문화·감사 제도가 함께 바뀌어야 한다"는 통합적 관점을 제시하면 기술사 수준의 깊이를 확보할 수 있다.
6. 고려사항 및 시사점
- 제도와 현장의 간극 해소가 최우선: 아무리 좋은 분류체계도 대가 산정·발주 관행이 뒷받침되지 않으면 사문화된다. 직무제 기반 대가 기준의 명확화가 다른 무엇보다 시급한 과제다.
- 역량 중심 문화로의 전환: 연공이 아닌 실력으로 평가받는 문화가 정착되어야 우수 인재가 산업에 남는다. 제도(하드웨어)와 함께 조직·발주 문화(소프트웨어)를 바꾸는 병행 접근이 필요하다.
- 법·제도 정합성: 소프트웨어 진흥법, SW사업 대가산정 가이드, 공공 SW 발주 제도와 정합적으로 연계되어야 실효성이 확보된다. 개별 제도가 따로 놀면 현장은 혼란만 겪는다.
- 국제 정합성 확보: SFIA 등 국제 역량체계와 호환되는 기준을 두면 글로벌 인력 이동·협업·평가에도 대응할 수 있어, 국내 인력의 해외 진출과 해외 인력 활용 양면에서 유리하다. 원격 협업이 일상화된 환경에서 국제 통용 역량 기준의 중요성은 더욱 커진다.
- 점진적·데이터 기반 이행: 등급-직무 매핑으로 연착륙하되, 직무별 임금·수요 실태조사 등 데이터에 기반해 기준을 지속 갱신함으로써 시장 현실과 괴리되지 않게 관리해야 한다.
- 발주·감사 제도와의 동반 개혁: 직무제가 정착하려면 발주 담당자가 "등급 대신 직무로 계약해도 감사에서 문제되지 않는다"는 확신을 가질 수 있어야 한다. 표준 발주서·평가 지침을 정비해 담당자의 위험 부담을 낮추는 것이 제도 정착의 실질적 열쇠다.
참고자료
- 소프트웨어 진흥법(국가법령정보센터): https://www.law.go.kr/
- 한국소프트웨어산업협회(KOSA) SW기술자 경력관리·SW사업 대가산정: https://www.sw.or.kr/
- SFIA(Skills Framework for the Information Age): https://sfia-online.org/
- 국가직무능력표준(NCS): https://www.ncs.go.kr/
한 줄 요약: SW 기술자 구분은 경력 기반 등급제 에서 직무·역량 기반 IT직무제 로 전환됐으나, 대가 기준 공백·역량 평가 곤란·인식 부족으로 현장에 정착하지 못한 것이 문제이며, 직무제 대가 기준 명확화·표준 역량 인증·공공 선도·단계적 전환이 핵심 개선 방향이다.