조직의 AI 전환(AX)을 위해서는 구성원이 AI로 업무에 필요한 정보를 찾고, 그 과정에서 만든 도구와 지식을 다른 구성원도 활용할 수 있어야 합니다. 또한 조직은 누가 얼마나 썼는지 알아야 하고, 사내 시스템과 안전하게 연결되어야 하고, 한 팀이 만든 것을 다른 팀이 다시 만들지 않아야 합니다. 이 문제가 해결되지 않으면 에이전트는 개인 PC 안에 머물고, 조직의 AX는 시작되지 […] ||
조직의 AI 전환(AX)을 위해서는 구성원이 AI로 업무에 필요한 정보를 찾고, 그 과정에서 만든 도구와 지식을 다른 구성원도 활용할 수 있어야 합니다. 또한 조직은 누가 얼마나 썼는지 알아야 하고, 사내 시스템과 안전하게 연결되어야 하고, 한 팀이 만든 것을 다른 팀이 다시 만들지 않아야 합니다. 이 문제가 해결되지 않으면 에이전트는 개인 PC 안에 머물고, 조직의 AX는 시작되지 않습니다.
이 설계 목표는 새로운 업무가 추가될 때 기존 시스템과의 연결과 운영 체계를 재사용하는 데 있습니다. 데이터를 연결하는 방식, 에이전트를 실행하는 환경, 조직 안에서 공유하는 절차를 공통 기반으로 만들고, 각 업무에 필요한 지식과 도구를 그 위에 더할 수 있도록 했습니다. 이 글에서는 그 기반을 어떻게 구성했는지, 각 설계가 조직의 AI 활용에 어떤 의미를 갖는지 살펴봅니다.
1. 조직의 AX 도입이 요구하는 세 가지
개인이 AI를 쓰는 것과 조직이 AI를 쓰는 것은 다른 문제입니다. 개인은 브라우저에서 챗봇을 열고 질문하면 됩니다. 하지만 조직에서는 질문에 답할 데이터가 사내 시스템 안에 있고, 그 데이터에 접근할 권한이 사람마다 다릅니다. 그리고 개인이 만든 도구가 다른 사람에게 공유되지 않으면, 유사한 에이전트나 MCP를 중복해서 만드는 일이 반복됩니다. 조직에서 사용하는 에이전트가 수십 개가 되었을 때, 조직의 AX 관점에서 에이전트를 운영하고 공유하기 위한 플랫폼 기반이 필요합니다. 이를 위해 경신홀딩스가 AI 플랫폼을 설계하며 정리한 요구사항은 다음 세 가지였습니다.
1.1 사내 데이터를 안전하게 연결하는 방식
업무에 필요한 답은 대부분 사내 시스템 안에 있습니다. 경신홀딩스의 경우 생산과 품질 데이터는 MS-SQL 서버에, 구매와 회계 데이터는 SAP에 있었습니다. 에이전트가 자연어 질문을 받아 이 시스템들을 대신 조회하려면, 각 시스템으로 연결되는 구성이 먼저 만들어져야 합니다.
문제는 이 연결이 부서와 업무마다 따로 만들어지기 쉽다는 점입니다. 품질팀 에이전트가 MS-SQL에 연결하는 코드를 만들고, 생산팀 에이전트가 같은 서버에 다른 방식으로 연결하면, 접속 정보는 여러 곳에 흩어지고 보안 정책을 바꿀 때마다 모든 곳을 고쳐야 합니다. 조직에 필요한 것은 데이터 소스마다 한 번 연결하고, 그 연결을 여러 에이전트가 공통으로 사용하는 구조입니다. 인증 정보는 에이전트 코드가 아니라 플랫폼이 관리하고, 어떤 사용자가 어떤 데이터에 접근할 수 있는지도 연결 지점에서 중앙 관리되어야 합니다.
1.2 에이전트를 실행하고 운영하는 환경
에이전트를 만드는 것과 운영하는 것은 별개의 일입니다. 개인 PC에서 동작하던 에이전트를 조직 단위로 운영하려면 사용자별 세션 격리, 로그인과 역할, 대화 기억, 도구 연결, 사용량과 비용 집계, 유해 입력 차단 등을 공통으로 처리하고 운영을 위한 확장을 고려해야 합니다.
실행과 운영 환경은 하나로 표준화하고, 각 팀은 그 위에 자신의 에이전트 로직만 올리는 방식이어야, 모니터링과 비용 관리가 한 곳에서 이루어지고, 새로운 에이전트를 추가할 때 인프라를 다시 고민하지 않게 됩니다.
1.3 공통 애셋을 조직 안에서 공유하는 절차
AX가 확산되는 조직에서는 구성원 스스로 에이전트를 만들기 시작합니다. 개인이 만든 MCP 서버나 스킬 문서를 다른 팀이 찾아 쓰려면 카탈로그가 있어야 하고, 사내 데이터에 연결된 도구를 누가 승인해서 공개하는지 정해야 합니다. 승인 절차 없이 공유하면 검증하지 않은 도구가 사내 데이터에 연결될 수 있습니다. 그래서 에이전트를 등록하고, 검색하고, 다