AX의 병목은 개발팀보다 현업 구조에 있다

공픈클로 AX 시리즈 3/4 · 중앙이 모든 도구를 대신 만드는 구조에서는 AI 전환이 느릴 수밖에 없고, 현업이 요청자에서 빌더로 바뀌는 순간 속도가 붙는다.

많은 조직이 AI 전환이 생각보다 느리다고 말한다. 예산도 넣었고, 모델도 도입했고, 사내 챗봇도 만들었는데 왜 일하는 방식은 크게 달라지지 않느냐는 것이다. 겉으로 보기에는 기술 문제가 원인처럼 보인다. 모델 성능이 부족하다거나, 보안이 까다롭다거나, 데이터가 정리되지 않았다는 설명이 뒤따른다. 물론 이런 요인들도 현실이다. 하지만 더 근본적인 병목은 다른 데 있을 수 있다.

나는 AX의 병목을 볼 때, 개발자 부족보다 현업이 여전히 요청자에 머물러 있다는 점이 더 크게 보인다고 생각한다.

전통적인 디지털 전환의 문법은 익숙하다. 현업이 문제를 발견하면 IT 부서나 외주 개발사에 요구사항을 전달한다. 그러면 몇 차례 회의와 문서 작업이 오가고, 우선순위를 정하고, 개발 일정이 잡히고, 몇 달 뒤 결과물이 나온다. 이 방식은 큰 시스템을 만들 때는 여전히 필요하다. 하지만 생성형 AI와 에이전트의 시대에도 이 문법만 고수하면, 작은 업무 개선조차 지나치게 느려진다.

왜냐하면 지금 필요한 것은 언제나 거대한 제품이 아니기 때문이다. 실제 업무 현장에서 필요한 것은 계약서 한 종류를 잘 읽는 AI 에이전트, 특정 법령 묶음을 비교해 주는 AI 에이전트, 민원 유형 몇 개를 빠르게 분류하는 AI 에이전트, 회의 메모를 정책 브리프로 바꿔 주는 작은 보조도구인 경우가 많다. 이런 문제까지 모두 개발 부서의 대기열로 보내면, AI 전환은 결국 병목을 벗어나지 못한다.

모더나가 흥미로운 이유는 이 병목을 우회하려고 했다는 데 있다. OpenAI 고객 사례를 보면, 그들은 기업용 AI 도입에 그치지 않고 교육, 오피스아워, 프롬프트 콘테스트, 내부 챔피언 네트워크를 만들었다. 이 말은 곧, AI를 중앙에서 만들어 배포하는 서비스로만 두지 않고 현업이 직접 실험하고 만드는 역량으로 조직에 심으려 했다는 뜻이다.

실제로 그 결과가 숫자로 드러난다. ChatGPT Enterprise 도입 두 달 만에 750개의 맞춤형 AI 에이전트가 생겼고, 주간 활성 사용자 중 40%가 직접 AI 에이전트를 만들었다. 만약 모든 AI 에이전트 제작을 중앙 IT가 담당했다면 이런 속도는 나올 수 없다. 핵심은 중앙 개발 조직의 생산성보다 현업이 빌더가 되기 시작했다는 점이다.

여기서 중요한 건 개발자의 역할이 사라지지 않는다는 점이다. 오히려 개발자의 역할은 더 중요해질 수 있다. 다만 역할의 중심이 바뀐다. 모든 도구를 직접 만드는 일에서, 현업이 안전하게 만들 수 있는 환경을 설계하는 일로 무게가 이동한다. 데이터 연결, 보안, 권한, 감사 로그, 공통 프롬프트 가이드, 템플릿, 검토 워크플로 같은 기반을 깔아 주는 역할이다.

이 구도가 되면 확산 속도가 완전히 달라진다. 중앙은 플랫폼과 거버넌스를 설계하고, 현업은 그 위에서 수많은 작은 에이전트를 만든다. 그리고 조직은 점점 분산형 혁신에 가까워진다. 작은 성공 사례가 곳곳에서 터지고, 그게 다시 다른 부서로 번진다. 이건 하나의 거대한 혁신 프로젝트보다 훨씬 빠르고, 현실적이며, 누적 효과도 크다.

공공부문은 특히 이 병목 문제를 심각하게 겪는다. 거의 모든 개선 요구가 정보화 사업이나 외주 개발 과제로 환원되기 쉽기 때문이다. 하지만 실제로는 많은 업무가 그 정도의 무게를 필요로 하지 않는다. 법령 해설 초안, 국회 대응자료 구조화, 언론 모니터링, 기관별 보고 템플릿, 질의응답 지식화 같은 일은 실무자가 스스로 자기 업무용 에이전트를 만들 수 있게 하면 훨씬 빨리 개선될 수 있다.

물론 공공은 민간과 달리 제약이 많다. 답변의 근거를 남겨야 하고, 잘못된 출력을 검토할 책임도 분명해야 하며, 개인정보와 보안도 중요하다. 그래서 더더욱 중앙이 직접 다 만드는 방식보다, 안전한 제작 환경과 검토 구조를 제공하는 방식이 유리하다. 현업이 만들되, 어디서 무엇을 근거로 만들었는지 추적 가능해야 한다.

결국 AX의 병목은 역할 분배에 있다. 모든 걸 중앙이 만들려는 구조에서는 AI 전환이 느릴 수밖에 없다. 현업이 문제를 정의하고, 작은 도구를 직접 만들고, 중앙이 이를 안전하게 뒷받침하면 속도가 붙는다.

이제 필요한 것은 개발자를 더 뽑아야 한다보다 현업을 어떻게 빌더로 만들 것인가에 대한 질문이다. 교육을 어떻게 할지, 챔피언을 어떻게 키울지, 어떤 도구를 표준화할지, 검토 책임은 어디에 둘지, 이런 질문이야말로 AX의 본론에 가깝다.

다음 글에서는 민간의 시민개발자 2.0 모델을 공공에 옮기면, 왜 시민개발자보다 실무자형 에이전트 빌더라는 개념이 더 잘 맞는지 살펴보겠다.