AI 전환 · 공공 부문

AI로 바뀌는 공공기관, 성공의 조건

인공지능(AI, Artificial Intelligence)을 조직에 들여야 한다는 말은 이제 흔하다. 정작 어려운 것은 무엇을, 어떻게 바꿀 것인가이다. 한 공공기관 인사 부서가 연말마다 몇 주씩 매달리던 인건비 계산 업무를 자동화한 사례는, 이 질문에 비교적 구체적인 답을 제시한다. 이 글은 그 사례를 실마리로 삼아 도입의 동기와 기술의 진화, 그리고 성공을 가르는 조건을 정리한다.

1.공공기관이 AI에 주목하는 이유

공공기관의 인사·관리 부서는 정부와 입법부의 통제를 강하게 받는다. 정해진 양식에 맞춰 자료를 작성하고, 지침에 따라 제도를 운용하는 단순·반복 업무가 많다는 뜻이다. 이런 업무를 효율화할 수 있다면, 그만큼 전략적이거나 창의적인 일에 시간을 더 쓸 수 있다. 자동화의 동기는 거창한 데 있지 않다. 매일 반복되는 병목 지점을 하나씩 찾아 덜어 내는 데 있다.

제도적 흐름도 같은 방향을 가리킨다. 정부가 AI 관련 정책을 확대하면서 공공기관 경영평가에도 AI·디지털 관련 지표가 들어오기 시작했다. 앞으로 공공 부문 전반에서 AI 도입 시도가 늘어날 수밖에 없는 환경이다.

2.디지털 전환이 먼저, AI 전환은 그다음

흔히 AI 전환(AX, AI Transformation)을 기술 도입으로만 이해한다. 그러나 AI 전환이 제대로 이뤄지려면 먼저 디지털 전환(DX, Digital Transformation)이 선행돼야 하고, 디지털 전환은 해당 업무 영역(도메인)에 대한 깊은 지식이 있어야 가능하다. 위에서 지시가 내려온다고 해서 곧바로 전환이 일어나지는 않는다. 무엇이 비효율인지, 데이터가 어디서 어떻게 흐르는지는 그 업무를 직접 하는 사람만 안다.

그래서 변화는 두 방향이 함께 가야 한다. 경영평가나 제도처럼 위에서 아래로 내려오는 탑다운(top-down)과, 각 업무 영역에서 현장이 스스로 움직이는 바텀업(bottom-up)이다. 공공 부문은 상대적으로 탑다운이 강하지만, 도메인에 뿌리내린 바텀업이 받쳐 주지 않으면 시스템과 프로그램만 들어오고 일하는 방식은 그대로 남는다.

3.시간을 아끼는 것과 혁신은 다르다

자동화로 시간을 아끼면 그만큼 생산성이 오르리라 기대하기 쉽다. 그러나 아낀 시간이 곧바로 더 가치 있는 일로 전환되지는 않는다. 오히려 대부분은 그렇지 않다는 연구가 많다. 전환의 열쇠는 기술이 아니라 동기에 있다.

조직이 혁신하려면 약간의 여유 공간(슬랙, slack)이 필요하다. 그런데 공공 인사 부서를 들여다보면, 요구 자료 작성이나 감사 대응 같은 부수 업무에 치여 정작 핵심 업무를 못 보는 경우가 많다. 업무량을 낮춰 여유 공간을 만들어야, 비로소 제도 개선이나 혁신을 고민할 시간이 생긴다. 기술로 빈 공간을 만들고, 조직문화로 그 공간을 채우는 일이 함께 가야 하는 이유다.

그 동기를 공공 부문에서 어떻게 만들 것인가. 고전적인 변화관리 이론은 변화의 첫 단추로 위기의식 조성을 꼽는다. 그러나 공공 부문은 민간에 비해 위기의식을 만들기 어려운 구조다. 대안으로 주목할 만한 것이 공공봉사동기(PSM, Public Service Motivation)다. 직접적인 이익으로 연결되지 않더라도, 작은 업무 개선 하나가 궁극적으로 국민의 삶을 나아지게 하는 출발점이 될 수 있다는 동기다. 이타심과는 결이 다르다. 내가 조금 더 노력하면 공익에 기여할 수 있다는, 공공 영역 특유의 동기부여다.

4.리더십은 분위기를 바꾸지만, 지속은 별개다

리더가 강하게 추진하면 조직의 분위기는 분명히 달라진다. 같은 공공 조직이라도, 리더가 AI에 관심을 갖고 주기적으로 강조하는 곳은 구성원의 의지와 역량에서 뚜렷한 차이를 보인다. 리더의 강조와 추진이 공공 영역에서도 확실히 영향을 미친다는 뜻이다.

다만 그것이 자발성으로 이어지려면 또 다른 무언가가 필요하다. 리더가 추진하면 분위기는 바뀌지만, 리더가 바뀐 뒤에도 조직이 같은 방식으로 돌아가야 변화가 정착된다. 분위기를 자발성으로, 다시 일하는 방식과 조직문화로 굳히는 단계가 빠지면, 사람이 떠나는 순간 변화도 함께 사라진다.

5.AI에게 일을 맡기는 방식의 진화

생성형 AI 활용 초기에는 명확한 지시만으로도 충분했다. 이른바 프롬프트 엔지니어링이다. 그러나 여러 자료가 서로 연결된 복잡한 작업에서는, 한 곳을 수정하도록 요청하면 엉뚱한 다른 곳이 함께 바뀌어 결과를 통제하기 어려웠다. 작업이 복잡해지면서 AI에게 일을 맡기는 방식도 함께 진화했다. 지시 위주의 프롬프트 엔지니어링에서, 필요한 정보를 함께 제공하는 컨텍스트 엔지니어링으로, 다시 위험 행동을 막는 울타리를 치는 하네스 엔지니어링으로 옮겨 갔다.

세 단계는 운전에 빗대어 설명할 수 있다. 프롬프트 엔지니어링은 운전자에게 “이렇게 운전해 줘”라고 지시하는 것이다. 컨텍스트 엔지니어링은 지도와 교통 상황 같은 정보를 함께 준 뒤 그것을 고려해 운전하라고 맡기는 것이다. 하네스 엔지니어링은 한발 더 나아간다. 차선 이탈 방지나 사고 직전의 급제동처럼, AI가 위험 영역을 넘어서려 할 때 스스로 멈추도록 울타리를 쳐 두는 방식이다. 여기서 하네스(harness)는 본래 마구나 안전벨트처럼 무언가를 붙들어 통제하는 장치를 뜻한다.

6.지침 파일과 서브에이전트: 울타리는 어떻게 세우나

하네스 엔지니어링은 추상적인 개념이 아니라 구체적인 파일과 규칙으로 구현된다. 프로젝트 폴더에는 AGENTS.md라는 지침 파일을 둔다. 컴퓨터가 읽기 쉬운 마크다운 형식으로, AI 에이전트가 따라야 할 규칙이 담긴다. 핵심은 세 가지다.

• 우선순위 부여 – 규정 준수와 데이터 연계의 정확성을 최우선으로 두고, 화면 모양새(UI, User Interface)는 후순위로 명시한다. 데이터가 정확히 맞물리는 것이 먼저라는 원칙을 못박는 것이다.
• 작업 위험도 분류 – 들어온 요청이 단순히 화면 표시만 바뀌는 일인지, 한 템플릿 안의 값을 바꾸는 일인지, 아니면 템플릿끼리 연결된 계산 로직 자체를 건드리는 일인지 위험도에 따라 나눈다. AI가 작업의 성격을 스스로 판단하도록 만든다.
• 금지 행위 명시 – 해서는 안 되는 동작을 한국어로 적어 둔다. 예컨대 기관에 필요 없는 특정 템플릿은 비활성화하라고 지정해 두는 식이다.

지침은 한 장에 다 적지 않는다. 처음 마주하는 지침 파일은 일종의 목차다. AI는 목차를 타고 들어가 전체 지침을 읽고, 다시 요청의 성격을 구분해 더 구체적인 지침으로 내려간다. 들어가고, 또 들어가는 계층 구조다. 그리고 정말 위험한 행동은 별도의 검증 장치로 막는다. 작업을 마치고 코드를 저장하거나 공유하는 시점에 자동으로 검사가 돌고, 위험 부분이 있으면 아예 진행을 중단시킨다.

복잡한 작업에서는 서브에이전트를 활용한다. 구조와 연동 경로를 추적하는 에이전트, 화면 동작을 다루는 에이전트처럼 역할을 나눠 둔 보조 에이전트들이다. 메인 에이전트는 작업의 범위를 분석한 뒤 적절한 서브에이전트에 일을 넘기고, 각 에이전트가 맡은 부분을 처리한다. 이 울타리 자체도 사람이 처음부터 끝까지 작성한 것은 아니다. 공개된 기술 문서를 AI에 입력해 구조를 파악하게 한 뒤 초안을 만들고, 사람이 그 위에 보완을 더하는 방식으로 구성됐다.

7.멈추는 AI

이 울타리가 작동하는 방식은 다음과 같다. 지침에 비활성화 상태로 지정해 둔 템플릿이 있다. 여기에 그 지침과 충돌하는 명령, 곧 해당 템플릿을 활성화하라는 지시가 들어오는 경우를 가정한다. 일반적인 작업이라면 에이전트는 스스로 해결책을 찾아 진행한다. 그러나 이 경우에는 진행을 멈추고, 그대로 실행해도 되는지를 사람에게 되묻는다.

그 변경이 목차와 메뉴, 계산 로직이 서로 연결된 구조를 끊을 수 있는 위험 작업이기 때문이다. 사용자가 무심코 명령을 넣었더라도, 기술적으로 연결이 끊어진다고 판단되면 아예 멈추거나 다시 확인하도록 설계돼 있다. 숫자가 촘촘히 연결된 작업일수록, 알아서 잘 처리하는 것보다 위험할 때 멈출 줄 아는 것이 더 중요하다.

8.사례: 총인건비 인상률 산정 시스템

이 모든 원칙이 적용된 실제 사례가 인건비 계산 업무다. 공공기관은 예산 한도 안에서 인건비를 자유롭게 쓰는 것이 아니라, 정부가 정한 지침에 따라 어떤 항목이 인건비성인지 아닌지를 분류해 집계해야 한다. 1년 동안의 인사 발령, 곧 승진이나 전보 같은 사안과 급여를 모두 반영해 총인건비 인상률을 계산하는데, 이 작업이 연말에 몰린다. 계산하는 동안에는 다른 업무를 보기 어려울 정도로 부담이 크다.

문제는 방식이었다. 조직 규모와 무관하게 대부분 엑셀로 작업한다. 인사 발령과 급여 데이터를 파일과 시트 20여 개에 따로 정리한 뒤, 그것들을 다시 수작업으로 연동한다. 연결 고리 하나만 끊겨도 계산 오류가 나고, 사람이 손으로 옮기다 실수(휴먼 에러)할 가능성도 늘 따라다닌다. 담당자가 부담을 크게 느낄 수밖에 없는 구조다.

새로 만든 시스템은 웹에서 돌아가는 프로그램이다. 전사적 자원관리(ERP, Enterprise Resource Planning) 시스템에서 받은 원시 데이터를 올리기만 하면, 정해진 로직에 맞게 값이 자동으로 채워진다. 정규직과 무기계약직을 구분해 계산하고, 성과급과 각종 수당도 데이터를 올리면 자동으로 연동된다. 매월 정기로 나가지 않는 비정기 급여는 최근 5년치를 학습해 텍스트로 분류하도록 로직을 짰다. 기본 연봉 인상률과도 연동돼, 예컨대 인상률 한도가 3퍼센트라면 몇 퍼센트까지 올렸을 때 총인건비 인상률이 얼마가 되는지를 한 화면에서 확인할 수 있다. AI가 값만 던져 주는 것이 아니라, 의심스러우면 교차 확인할 수 있도록 관련 명단까지 함께 보여 준다.

9.효과: 시간 절감, 그리고 암묵지의 시스템화

가장 뚜렷한 변화는 시간이다. 기존 수작업 방식에서는 같은 계산에 3-4주가 걸렸다. 로직이 복잡한 데다, 원 단위까지 정확히 맞아야 해 거듭 교차 확인을 해야 했기 때문이다. 데이터만 제대로 올리면 결과가 한눈에 도출되는 시스템에서는, 이 시간을 절반 이상 줄일 수 있다.

유지보수의 이점도 있다. 외부 용역으로 만든 프로그램은 한번 만들면 고치기가 쉽지 않다. 반면 이 시스템은 ERP의 데이터 구성이나 평가 기준이 바뀌어도 시스템만 수정하면 되도록 설계돼, 변화에 비교적 쉽게 대응한다.

비용으로 환산하기 어렵지만 더 큰 효과는 따로 있다. 담당자 개인의 노하우, 곧 암묵지(暗默知)를 시스템으로 끌어올린 것이다. 오래 그 일을 해 온 사람은 빠르게 처리하고 오류도 금세 잡아낸다. 그러나 그 노하우가 문서로 남아 있지 않으면, 담당자가 갑자기 빠질 때 조직은 큰 곤란을 겪는다. 시스템화는 새 담당자가 곧바로 하기 어려운 일을 떠받쳐 주고, 그만큼 조직의 위험을 낮춘다.

10.어디까지 표준화할 수 있나

이 시스템을 다른 기관이 그대로 가져다 쓸 수 있을까. 부분적으로만 그렇다. 정부 지침을 기반으로 한 상위 템플릿은 기관마다 동일하다. 그러나 ERP가 어떻게 구축돼 있느냐에 따라 뽑아낼 수 있는 데이터가 다르고, 중간에 사람이 손으로 해 오던 암묵지도 기관마다 제각각이다. 결국 도출하려는 결과값은 같지만, 그에 이르는 경로가 달라 그대로 복제하기는 어렵고 기관에 맞춘 수정이 필요하다. 다만 로직의 절반 이상은 비슷해, 표준화의 여지는 분명히 있다.

규모를 생각하면 이 여지는 작지 않다. 중앙정부가 지정한 공공기관만도 300여 개에 이르고, 지방 공공기관까지 포함하면 그 수는 훨씬 많다. 사기업의 자동화 도구는 그 기업을 벗어나면 효용이 급격히 떨어지지만, 공공 부문은 상위 조직이 요구하는 사항이 서로 비슷하다. 잘 만든 산정 도구를 표준화해 공유하면 효용이 상대적으로 크다는 뜻이다.

11.혼자 만든 도구는 의미가 없다

기술적으로 잘 만드는 것만으로는 충분하지 않다. 혼자 프로그램을 만들어 혼자 쓰는 것은 의미가 없다. 구성원과 공유하고, 함께 역량을 키우는 학습 조직으로 가야 변화가 조직 전체로 번진다. 좋은 템플릿과 프로그램을 공유하면 모두의 시간을 아낄 수 있다. AI 전환이든 자동화든, 그 핵심은 결국 공유와 상호 학습에 있다.

경영평가에 AI 지표가 들어오면 각 기관은 관련 시스템과 프로그램을 도입하려 할 것이다. 그러나 시스템 도입이 곧 자발적 변화를 뜻하지는 않는다. 일하는 방식과 조직문화가 바뀌어야 하고, 그러려면 구성원이 스스로 움직여야 한다. 도구의 도입과 사람의 변화 사이에는 여전히 메워야 할 거리가 있다.

12.기술이 아니라 문제를 먼저 보라

기술 트렌드는 변화가 빨라 일일이 따라잡기 어렵다. 그리고 더 중요한 것은 기술 자체가 아니다. 새 기술이 들어왔을 때 조직에 자리 잡고 사람이 일하는 방식을 본질적으로 바꾸려면, 결국 조직문화와 리더십, 조직 관리가 받쳐 줘야 한다. 기술에만 빠지면 정작 더 중요한 것을 놓치기 쉽다.

그래서 순서를 뒤집지 않는 것이 중요하다. 유행하는 기술을 먼저 좇기보다, 지금 내가 선 자리의 문제가 무엇인지를 먼저 본다. 그 문제를 풀기 위한 수단으로 학습과 기술이 따라올 때, 공부도 더 효과적이 된다. 주객이 전도되면 도구는 늘어나는데 문제는 그대로 남는다. 빠르게 변하는 시대일수록, 기술 목록이 아니라 문제 의식이 먼저다.

결국 관건은 기술을 도입하느냐가 아니라, 그것이 만들어 낸 여유를 어떤 가치로 전환하느냐에 있다.