AX Foundry란? 사내 AI 에이전트를 등록하고 통제하는 운영 플랫폼

직답 요약

AX Foundry는 사내에서 만들어진 AI 에이전트를 한곳에 등록해 정책과 승인, 감사 기록을 제공하는 AI 에이전트 관리 플랫폼입니다. 모든 에이전트는 등록되는 시점부터 관리 대상이 되며, 폐쇄망을 포함한 모든 환경에서 같은 운영 체계를 유지합니다. 오픈네트웍시스템이 컨설팅과 구축, 관제까지 한 번에 제공합니다.

부서마다 AI 에이전트를 만들어 쓰는데, 관리는 누가 하나요?

노코드 빌더가 보급되면서 개발 인력을 거치지 않고도 부서 담당자가 직접 챗봇을 올리고 사내 문서 검색 기능을 붙일 수 있게 됐습니다. 관리는 만든 부서가 각자 하고 있고, 전사 차원에서 관리하는 주체는 따로 정해지지 않은 채 남기 쉽습니다. 만드는 속도가 빨라진 만큼 에이전트 수도 늘었습니다. 재무팀이 만든 실적 분석 에이전트, 인사팀이 만든 규정 안내 챗봇, 마케팅 부서가 만든 데이터 분석 에이전트가 서로 다른 환경에서 각각의 기준으로 운영됩니다.

이 상태를 위험으로 보는 것은 우리만이 아닙니다. 마이크로소프트는 클라우드 도입 프레임워크에서 조직 전반의 에이전트 거버넌스를 네 갈래로 나누고, 그중 첫 갈래인 통제 계층을 여섯 항목으로 정리합니다. 두 번째 항목이 에이전트 레지스트리 유지입니다. 원문은 추적되지 않은 배포와 섀도우 배포가 보안과 비용 위험을 만든다고 적고, 존재를 모르는 에이전트는 통제할 수 없다고 못 박습니다. 권고 내용은 모든 AI 에이전트를 하나의 조직 인벤토리에 기록하고 소유자와 목적, 플랫폼, 접근 범위를 추적하며 에이전트를 관리 대상 자산으로 취급하라는 것입니다.

관리가 안 되면 구체적으로 어떤 일이 생기나요?

에이전트가 한 말의 책임은 회사에 있다는 판정이 이미 나와 있습니다. 관리되지 않는다는 말은, 그 책임의 범위를 회사가 모른다는 뜻입니다.

2022년 11월 한 승객이 에어캐나다 웹사이트의 챗봇에 유족 할인 운임을 문의했습니다. 챗봇은 정상 운임으로 결제한 뒤 나중에 소급 신청할 수 있다고 답했지만, 실제 회사 규정은 소급 신청을 허용하지 않았습니다. 승객은 캐나다 브리티시컬럼비아주 민사분쟁해결재판소(Civil Resolution Tribunal)에 분쟁을 제기했습니다.

재판에서 에어캐나다는 챗봇이 제공한 정보까지 회사가 책임질 수는 없다고 주장했습니다. 재판부는 이 주장이 결국 챗봇을 스스로의 행위에 책임지는 별개의 법적 주체로 보는 것과 같다고 정리하고, 놀라운 주장("a remarkable submission")이라고 적었습니다. 챗봇에 상호작용하는 부분이 있더라도 그것은 여전히 웹사이트의 일부이고, 회사가 웹사이트의 모든 정보에 책임이 있다는 것은 에어캐나다에게도 자명했어야 하며, 정보가 정적인 페이지에서 나왔든 챗봇에서 나왔든 차이가 없다는 것이 재판부의 판단이었습니다.

에어캐나다가 챗봇의 정확성을 확보할 합리적 주의를 기울이지 않았다는 결론으로, 과실에 의한 부실표시가 인정돼 2024년 2월 배상 판정이 나왔습니다(Moffatt v. Air Canada, 2024 BCCRT 149). 배상액은 650.88캐나다달러, 이자와 비용까지 812.02캐나다달러였습니다. 1캐나다달러를 1,000원으로 잡으면 약 81만원입니다.

이 사건이 보여주는 교훈은, 챗봇이 한 답의 책임은 챗봇이 아니라 회사에 있다는 것입니다. 고객 대면 챗봇 한 개를 두고도 회사는 분쟁 절차에서 그 책임을 다투어야 했습니다. 부서마다 여러 개가 돌고 있고 답변 정합성에 대해 관리가 안되고 있는 상태라면, 회사가 책임져야 할 범위는 그만큼 넓어집니다.

관리 체계를 세운다는 것은 그 범위를 회사가 알고 있게 만든다는 뜻입니다. 그러려면 에이전트마다 무엇을 확인할 수 있어야 하는지부터 정해져 있어야 합니다. 이 글에서 거버넌스라 칭하는 영역은 그 확인 항목을 등록과 정책, 승인, 감사로 관리하는 체계를 의미합니다. 확인해야 하는 다섯 가지를 정리하면 아래와 같습니다.

이 다섯 가지는 문서로는 채워지지 않습니다. 지난달에 마케팅팀이 올린 에이전트가 어떤 사내 데이터를 읽고 있는지는 에이전트 하나하나에 붙어 있을 때만 알 수 있습니다.

이런 상황에서 먼저 떠오르는 대응은 전담 조직을 만드는 것입니다. 마이크로소프트 권고는 거버넌스 체계를 따로 세우지 말라는 쪽입니다. 에이전트 거버넌스의 책임을 기존 클라우드 거버넌스와 보안, 컴플라이언스 책임자에게 그대로 붙이라는 것이 첫 항목이고, 그 바로 다음 항목이 앞에서 본 에이전트 레지스트리 유지입니다.

AX Foundry는 어떤 솔루션인가요?

AX Foundry는 사내에서 만들어진 AI 에이전트를 한곳에 등록해 정책과 승인, 감사로 운영하는 플랫폼입니다.

등록, 정책, 승인, 감사 네 가지로 운영합니다

등록은 에이전트마다 신원 정보를 남기는 단계입니다. 사람이 주민등록 없이 사회생활을 하기 어려운 것과 같습니다. 태어난 기록이 있어야 그 뒤의 모든 절차가 그 기록에 걸리고, 에이전트도 등록된 기록이 있어야 정책을 적용하고 승인을 받을 수 있고 감사에 남습니다. AX Foundry는 이 기록을 Agent Manifest라고 부릅니다. 이름과 버전, 접속 주소, 제작 조직, 책임 부서, 무슨 업무를 위해 만들었는지, 어떤 정책과 템플릿을 따르는지, 어떤 도구를 쓸 수 있는지가 필수 항목입니다. 출처와 책임, 목적이 비어 있으면 등록 요청 자체가 거부됩니다.

정책은 등록된 에이전트가 무엇까지 할 수 있는지를 정하는 단계입니다. 접근 가능한 데이터의 범위와 사용할 수 있는 도구, 호출할 수 있는 모델과 호출 한도를 지정합니다. 정책에서 특정 데이터에 대한 접근 권한을 지정하고, 실행할 때 어떤 정책이 적용됐는지는 감사 기록에 함께 남습니다. 접근 범위와 호출 한도는 미리 설정하기 때문에 담당자가 지침을 기억하고 있는지와 무관하게 적용됩니다.

승인은 사람이 검토하는 단계로 두 종류로 나뉩니다. 하나는 새 에이전트가 운영에 들어갈 때 받는 등록 승인이고, 다른 하나는 이미 운영 중인 에이전트가 주어진 승인 한계를 넘어서는 일을 하려 할 때 실행 직전에 걸리는 승인입니다. 뒤쪽은 검토 대기열에 올라가며, 무엇이 왜 걸렸는지와 어떤 정책 버전이 적용됐는지가 함께 표시됩니다. 누가 언제 승인했는지도 기록으로 남습니다.

감사는 실행 기록이 전수로 남는 단계입니다. 호출 한 건을 골라 상세를 보면 요청 수신에서 정책 판정, 도구 호출, 응답 반환까지 거친 경로가 순서대로 펼쳐지고, 그 실행에 동반된 식별 정보가 함께 남습니다. 감사 로그 화면에서는 1) 누가 만들었는지 2) 왜 만들었는지 3) 누가 승인했는지 4) 어떤 정책을 따랐는지 5) 책임자가 누구인지를 확인할 수 있습니다. 사고가 났을 때 경로를 되짚는 근거이자 규제 대응에 제출할 근거가 됩니다.

AX Console에서는 무엇을 다루나요

AX Console의 관제 대시보드에서는 관제 대상 에이전트 수와 호출 건수, 정책에 걸려 차단된 건수, 승인 대기 건수를 한 화면에서 볼 수 있습니다. Agent 현황에서는 여기에 더해 책임 부서가 지정되지 않은 에이전트를 구분해서 확인이 가능합니다. 관리 책임에서 벗어나 방치된 에이전트가 있는지를 이 화면에서 확인할 수 있고, 보이지 않던 대상을 관리 범위 안으로 들일 수 있습니다.

등록과 정책, 승인, 감사가 무엇을 하는지라면, 그 통제가 어디까지 미치는지는 다섯 계층으로 나뉩니다. 1) 콘솔에 로그인하는 사람의 신원, 2) 에이전트의 신원과 권한, 3) 에이전트에 연결하는 도구, 4) 접근할 수 있는 데이터, 5) 실행할 수 있는 행위와 한도입니다. 사람의 권한과 에이전트의 권한을 처음부터 분리해 두는 것이 이 구조의 출발점입니다.

검증이 끝난 정책 구성은 템플릿으로 쌓여 다음 에이전트에 그대로 적용되고, 초안에서 검증본, 조직 표준으로 단계를 올려 관리합니다.

통제와 별개로 실행을 들여다보는 관찰 화면이 따로 있습니다. 어떤 업무가 돌아가고 있는지, 개별 실행이 어떤 경로로 지나갔는지, 부서별로 얼마나 쓰고 있고 모델 비용이 어디에 몰리는지를 봅니다. 이 화면들은 조회 전용이라 실행을 중단시키는 조작은 들어 있지 않습니다.

화면 구성과 정책 항목은 AX Console 운영 매뉴얼 v1.0 기준이며, 실제 메뉴와 항목은 고객 환경에 맞춰 상세 설계 단계에서 확정됩니다.

지금 쓰는 에이전트 제작 솔루션을 바꿔야 할까요?

바꾸지 않아도 됩니다. AX Foundry는 에이전트를 제작하는 솔루션이 아니라, 제작 솔루션 위에 얹혀 만들어진 에이전트를 운영하는 관리 솔루션입니다. 제작 단계와 운영 단계는 서로 보완됩니다.

모든 에이전트는 등록되는 순간부터 관리됩니다

AX Foundry는 특정 빌더 전용 제품이 아닙니다. 관제 콘솔의 메뉴 구성에서도 에이전트를 만드는 빌더는 콘솔 바깥에 따로 놓여 있습니다. 노코드 빌더로 만들었든 자동화 솔루션으로 엮었든 개발팀이 직접 코드로 구현했든 등록되는 시점부터 같은 정책과 감사 아래로 들어옵니다. 이미 만들어 둔 에이전트를 폐기하고 처음부터 다시 만들 필요가 없다는 뜻이고, 지금까지 부서가 쌓아 온 결과물도 그대로 살아 있습니다.

에이전트 개발 솔루션 없이 AX Foundry만 도입해도 됩니다

이미 사내에 만들어 둔 에이전트가 있다면 그 상태 그대로 AX Foundry만 도입해 등록과 관제부터 시작할 수 있습니다.

만드는 제품과 운영하는 제품이 어떻게 나뉘는지, 기업용 AI 솔루션을 유형별로 비교한 내용은 기업용 AI 솔루션 정리 편에 따로 정리해 두었습니다.

폐쇄망에서도 사용할 수 있을까요?

사용할 수 있습니다. AX Foundry는 폐쇄망과 프라이빗 클라우드, 퍼블릭 클라우드와 혼합 구성 가운데 어디에 놓여도 같은 운영 체계를 유지하도록 설계되어 있습니다.

어떤 환경에서도 같은 운영 체계를 유지합니다

AX Foundry가 놓일 수 있는 환경은 네 가지입니다.

어느 쪽을 골라도 등록과 정책, 승인, 감사라는 운영 체계는 그대로 사용 가능합니다. 폐쇄망과 망분리 환경에서 AI를 운영하는 조건에 대해서는 온프레미스 AI란 무엇일까 편에 정리해 두었습니다.

도입하면 무엇부터, 얼마나 걸리고 비용은 어떻게 잡나요?

처음부터 전사를 대상으로 시작하지 않습니다. 미리 구성해 둔 에이전트로 한 부서에서 시작해 범위를 넓히는 순서로 진행합니다.

미리 구성된 에이전트로 시작합니다

AX Foundry는 업무별로 미리 구성해 둔 Ready Agent를 제공합니다. 무엇을 만들지부터 정해야 하는 부담을 줄이려는 구성입니다.

금융과 제조, 공공 업종별로 묶은 Industry Pack도 제공됩니다. 필요한 것만 골라 먼저 시작하고 뒤에 Pack 단위로 범위를 넓히는 구성이라 첫 도입 규모를 작게 잡을 수 있습니다.

진단부터 내재화까지 다섯 단계

도입은 다섯 단계로 나뉘고, 그중 검증 단계는 한 부서 범위에서 진행합니다.

AX Foundry는 세 갈래로 구성됩니다. 과제 발굴과 로드맵, 규제 진단은 AX Consulting이 맡고 폐쇄망 설치와 GPU 추론 환경 구성은 Secure Delivery가 담당하며 등록과 관제는 AX Console이 제공합니다.

비용은 무엇을 기준으로 매겨지나요

구축 기간과 비용은 도입 범위와 고객사 환경에 따라 별도로 산정됩니다.

저희는 예산 항목을 먼저 세워야 한다면 진단 단계에서 범위를 좁힌 뒤 산정하는 순서를 권합니다. 전사를 전제로 잡은 금액은 결재선에서 걸리기 쉽습니다. 한 부서 검증분이면 성과가 나온 뒤에 범위를 넓히는 근거가 생깁니다.

자주 묻는 질문

AX Foundry는 AI 에이전트를 만드는 솔루션인가요?

아닙니다. AX Foundry는 만들어진 에이전트를 등록하고 운영하는 관리 솔루션입니다. 만드는 일은 기존에 쓰던 빌더나 개발 방식을 그대로 두고 AX Foundry는 그 위에 얹힙니다.

이미 다른 솔루션으로 만들어 둔 에이전트가 있는데 다시 만들어야 하나요?

다시 만들지 않아도 됩니다. 노코드 빌더로 만든 것이든 개발팀이 짠 것이든 AX Foundry에 등록되는 시점부터 정책과 감사 대상이 됩니다.

폐쇄망 환경에서도 쓸 수 있나요?

폐쇄망을 포함한 온프레미스 환경에서 동작하도록 구축됩니다. 폐쇄망과 프라이빗 클라우드, 퍼블릭 클라우드 어디에 놓여도 등록과 정책, 승인, 감사라는 운영 체계는 그대로 사용할 수 있습니다.

도입까지 얼마나 걸리나요?

검증 단계인 PoC가 4주 기준이며 전체 기간은 도입 범위와 환경에 따라 달라집니다. 도입 범위가 정해지면 그에 맞춰 산정합니다.

운영은 누가 맡게 되나요?

운영관제 단계에서는 오픈네트웍시스템이 등록과 정책, 승인, 감사 체계를 세웁니다. 이후 내재화 단계에서 운영 패키지와 교육을 이관해 고객사가 직접 확장할 수 있도록 넘겨 드립니다. 필요한 인력 규모는 도입 범위와 환경에 따라 달라지므로 도입 상담에서 별도로 안내해 드립니다.

도입을 검토하고 계신다면

사내에 몇 개의 에이전트가 돌고 있는지 지금 답할 수 없다면 그 목록을 만드는 일부터가 시작입니다. 오픈네트웍시스템은 진단 단계에서 AI 전환 과제를 발굴하고 투자 대비 효과와 로드맵을 함께 정리한 뒤, 그중 한 부서를 골라 4주 범위의 검증까지 설계해 드립니다. 관제 대시보드 구성을 직접 보고 싶으시면 데모를 요청해 주시기를 추천합니다.

출처

출처

• Microsoft, Cloud Adoption Framework 「Govern and secure AI agents across the organization」 (2026.4.9) https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization

• Moffatt v. Air Canada, 2024 BCCRT 149 (캐나다 브리티시컬럼비아주 민사분쟁해결재판소, 2024.2) https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html

• McCarthy Tétrault, 「Moffatt v. Air Canada: A Misrepresentation by an AI Chatbot」 https://www.mccarthy.ca/en/insights/blogs/techlex/moffatt-v-air-canada-misrepresentation-ai-chatbot

• Dentons Data, 「Airline ordered to compensate a B.C. man because its chatbot provided inaccurate information」 https://www.dentonsdata.com/airline-ordered-to-compensate-a-b-c-man-because-its-chatbot-provided-inaccurate-information/

• 오픈네트웍시스템, 「ONS AX Foundry 서비스 소개서 v1.0」 (2026.7.30)

• 오픈네트웍시스템, 「ONS AX Console 운영 매뉴얼 v1.0」 (2026.6.30, 비공개 제품 자료)