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

직답 요약

AX Foundry는 사내에서 만들어진 AI 에이전트를 한곳에 등록하고, 정책·승인·감사 기록을 기준으로 운영하도록 돕는 AI 거버넌스 플랫폼입니다. Dify, n8n, 자체 개발 등 제작 방식과 관계없이 등록되는 순간부터 관리 대상이 되며, 폐쇄망·클라우드·하이브리드 환경에서도 같은 운영 체계를 적용할 수 있습니다. 직원과 부서가 각자 만들어 사용하던 AI를 회사가 파악하고 책임질 수 있는 자산으로 전환하는 것이 핵심 목적입니다.

AI 에이전트, 제대로 관제되고 있나요?

혹시 지금 회사 안에서 몇 개의 AI 에이전트가 운영되고 있는지 바로 답할 수 있으신가요? 노코드 빌더가 보급되면서 개발 인력을 거치지 않고도 부서 담당자가 직접 챗봇을 만들고 사내 문서 검색 기능을 연결할 수 있게 됐습니다.

제작 속도가 빨라진 만큼 에이전트 수도 늘었는데요. 재무팀의 실적 분석 에이전트, 인사팀의 규정 안내 챗봇, 마케팅팀의 데이터 분석 에이전트가 서로 다른 환경에서 각기 다른 기준으로 운영되는 상황입니다.

이처럼 회사가 존재를 파악하지 못한 채 운영되는 에이전트를 ‘섀도우 에이전트’라고 부릅니다. 누군가 악의를 가지고 숨긴 것이 아니라, 등록하고 관리할 체계가 없어 방치된 경우가 대부분입니다.

마이크로소프트 역시 클라우드 도입 프레임워크에서 조직 전반의 에이전트 거버넌스를 네 영역으로 나누고, 첫 번째 영역인 통제 계층에 ‘에이전트 레지스트리 유지’를 포함하고 있습니다. 추적되지 않은 배포와 섀도우 배포는 보안과 비용 위험을 만들기 때문에, 모든 AI 에이전트를 하나의 조직 인벤토리에 기록하고 소유자·목적·플랫폼·접근 범위를 추적해야 한다는 권고입니다. 결국 존재를 모르는 에이전트는 통제할 수도 없습니다.

사내에서 몇 개의 AI 에이전트가 운영되고 있는지 한 번도 세어 본 적이 없다면, 아직 본격적인 관제가 시작되지 않은 상태라고 볼 수 있습니다.

관제되지 않으면 어떤 문제가 생기나요?

챗봇이 잘못 안내한 요금, 항공사가 물어줬습니다

고객을 상대하는 AI 에이전트의 답변이 회사 책임으로 인정된 사례가 있습니다. 관제되지 않는다는 것은 회사가 책임져야 할 범위조차 정확히 파악하지 못하고 있다는 뜻입니다.

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

에어캐나다는 재판에서 챗봇이 제공한 정보까지 회사가 책임질 수는 없다고 주장했습니다. 그러나 재판부는 이를 챗봇을 스스로의 행위에 책임지는 별개의 법적 주체로 보는 것과 같은 “놀라운 주장(a remarkable submission)”이라고 평가했습니다. 챗봇 역시 웹사이트의 일부이며, 정보가 정적인 페이지에서 제공됐든 챗봇을 통해 제공됐든 회사의 책임에는 차이가 없다는 판단이었습니다. 재판부는 에어캐나다가 챗봇의 정확성을 확보하기 위해 합리적인 주의를 기울이지 않았다고 보고, 2024년 2월 과실에 의한 부실표시를 인정했습니다(Moffatt v. Air Canada, 2024 BCCRT 149).

이 사건이 보여주는 핵심은 에이전트가 한 답변의 책임도 결국 회사가 진다는 점입니다. 고객을 상대하는 에이전트 한 개만으로도 회사는 분쟁 절차에서 책임을 다퉈야 했습니다. 여러 부서에서 다수의 에이전트가 운영되고 있는데 답변의 정합성과 운영 상태를 관리하지 못한다면, 회사가 책임져야 할 범위도 그만큼 넓어집니다.

관리 체계를 구축하는 것은 이 책임의 범위를 회사가 인지하고 관리할 수 있게 설계하는 일입니다. 이를 위해서는 각 에이전트에 대해 다음 다섯 가지 질문에 답할 수 있어야 합니다.

금융권에서는 이 다섯 가지를 회사의 자율적인 판단만이 아니라 규제 요건에 따라 관리해야 합니다. 금융위원회가 2026년 6월 22일 시행한 「금융분야 인공지능 가이드라인」 개정안이 금융분야 AI 7대 원칙을 제시하고 있습니다. 다만 금융산업에 특화된 별도 규율에 해당하므로, 금융회사 또는 금융 관련 업무를 수행하지 않는 조직이라면 우선 해당 내용을 적용 대상에서 제외하고 검토해도 무방합니다. 업종과 업무에 관계없이 AI를 활용하는 모든 금융회사가 대상이며, 적용 수준은 회사가 보유한 자원과 활용 범위, 서비스의 위험 수준을 고려해 자율적으로 정할 수 있습니다. 다만 인공지능 기본법과 시행령이 규율하는 고영향 인공지능에 해당한다면 별도의 법적 의무가 발생합니다.

AI 거버넌스, 전담 조직부터 만들면 되지 않을까요?

전담 조직을 만드는 일과 관리 대상인 에이전트의 목록을 만드는 일은 서로 다릅니다. 에이전트 목록이 없다면 조직을 구성해도 구체적인 판단을 내리기 어렵습니다.

거버넌스라는 말을 들으면 먼저 전담 조직이나 위원회를 만드는 방식을 떠올리기 쉽습니다. 실제로 이 7대 원칙 가운데 첫 번째인 거버넌스 원칙도 경영진이 역할과 책임을 분담하고, 의사결정기구와 전담 조직을 구성하며, 관련 내규를 마련하도록 안내합니다.

하지만 전담 조직이 판단을 내리려면 먼저 관리 대상의 목록이 있어야 합니다. 지난달 마케팅팀이 만든 에이전트가 어떤 사내 데이터를 읽고 있는지는 전사 내규만으로 확인할 수 없습니다. 해당 정보는 에이전트별 기록에 남아 있어야 하며, 앞서 제시한 다섯 가지 질문 역시 조직도가 아니라 개별 에이전트의 등록 정보에서 답을 찾아야 합니다.

마이크로소프트의 권고 순서도 같은 방향입니다. 에이전트 거버넌스의 책임을 기존 클라우드 거버넌스·보안·컴플라이언스 책임자에게 배정하고, 별도의 병렬 거버넌스 모델을 새로 만들지 말라고 안내합니다. 그다음 단계가 에이전트 레지스트리를 유지하는 일입니다. 새로운 조직부터 만드는 것이 아니라, 기존 책임 체계에 AI 에이전트 관리를 연결하고 전체 목록을 확보하는 순서입니다.

따라서 AI 거버넌스는 전담 조직을 만들고 내부 규정을 마련하는 데서 끝나지 않습니다. 각 에이전트가 어떤 목적으로 만들어졌고, 누가 책임지며, 실제로 어떻게 운영되는지 회사가 명확하게 설명할 수 있는 관리 체계를 갖추는 것이 핵심입니다.

이를 위해 에이전트의 제작 주체와 도입 목적은 등록 단계에서 기록합니다. 어떤 데이터에 접근할 수 있고 어떤 작업까지 수행할 수 있는지는 정책 단계에서 정합니다. 운영을 승인한 사람과 책임 소재는 승인 과정에서 명확히 남깁니다. 마지막으로 실제 실행 과정과 적용된 정책은 감사 로그에 차곡차곡 기록됩니다. 문제가 발생했을 때 무엇이 언제 어떻게 처리됐는지 확인하고, 필요한 경우 책임을 추적할 수 있도록 하기 위해서입니다.

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

AX Foundry는 사내에서 만들어진 AI 에이전트를 한곳에 등록하고 정책·승인·감사를 기준으로 운영하는 AI 거버넌스 플랫폼입니다. 각 에이전트에 대해 다섯 가지 질문에 답할 수 있는 상태를 만드는 것이 AX Foundry의 역할이며, 등록된 에이전트를 관리하는 화면을 AX Console이라고 부릅니다. 정책과 승인은 모두 에이전트가 무엇까지 할 수 있는지를 정하는 과정이므로 함께 설명하겠습니다.

사내 AI 에이전트 현황을 한눈에 파악할 수 있습니다

등록은 에이전트마다 신원과 책임 정보를 남기는 단계입니다. 사람에게 공식적인 신원 기록이 필요하듯, 에이전트도 등록 기록이 있어야 정책을 적용하고 승인을 받으며 실행 내역을 감사 기록에 남길 수 있습니다.

AX Foundry는 이 기록을 ‘Agent Manifest’라고 부릅니다. 이름과 버전, 접속 주소, 생성 조직, 책임 부서, 생성 목적, 적용되는 정책과 템플릿, 사용할 수 있는 도구 등이 필수 항목입니다. 출처와 책임자, 생성 목적이 비어 있으면 등록 요청 자체가 거부됩니다.

등록된 에이전트는 하나의 카탈로그 화면에 모입니다. 전 부서에서 어떤 에이전트가 몇 개 운영되고 있고 각각 책임자가 누구인지 여기에서 확인할 수 있습니다. 등록 범위 밖에서 운영되는 섀도우 에이전트는 탐지 대상이 되어 알림으로 올라오기 때문에, 기존 목록에서 빠져 있던 에이전트도 관리 범위 안으로 편입할 수 있습니다.

등록은 일회성 절차가 아닙니다. 에이전트는 생성·승인·운영·폐기로 이어지는 상태를 가지며, 등록 정보와 실제 운영 상태가 어긋나면 주기적으로 자동 탐지됩니다. 오랫동안 사용되지 않은 에이전트는 알림 대상으로 분류되고, 담당자가 바뀌면 책임자를 이관할 수 있습니다. 등록 이후 책임자가 공석이 된 에이전트도 별도로 구분해 확인할 수 있어, 방치된 에이전트를 회사가 다시 관리하는 절차를 마련할 수 있습니다.

에이전트의 책임자와 권한 범위를 확인할 수 있습니다

승인은 사람이 직접 검토하는 절차로, 두 가지 경우에 적용됩니다.

첫째, 새로 만든 에이전트를 실제 운영에 배포하려는 경우입니다. 둘째, 운영 중인 에이전트가 기존 승인 범위를 넘어서는 작업을 요청하는 경우입니다. 승인 검토 대기열에는 무엇이 어떤 이유로 차단됐는지와 적용된 정책 버전이 함께 표시됩니다. 요청자와 승인자는 분리되고, 누가 언제 승인했는지도 기록으로 남습니다. 승인된 버전만 배포할 수 있으며 승인 범위를 벗어난 변경은 차단됩니다.

정책은 등록된 에이전트의 접근 범위와 실행 권한을 정하는 단계입니다.

접근할 수 있는 데이터와 호출 한도는 정책으로 미리 정해집니다. 따라서 담당자가 별도의 지침을 기억하거나 매번 확인하지 않아도 동일한 기준이 일관되게 적용됩니다. 새로 등록되는 에이전트에도 기존 정책을 자동으로 적용할 수 있어, 운영 기준을 안정적으로 유지할 수 있습니다.

검토가 끝난 정책 설정은 템플릿으로 저장해 다른 에이전트에도 그대로 적용할 수 있습니다. 정책 템플릿은 처음에는 초안으로 관리하고, 검토와 사용을 거쳐 회사의 표준으로 발전시킬 수 있습니다.

에이전트의 실행 내역과 비용을 확인할 수 있습니다

감사는 에이전트가 실제로 무엇을 했는지 기록하고 확인하는 단계입니다. 에이전트가 실행될 때마다 요청을 받은 시점부터 정책을 확인하고, 도구를 호출하고, 응답을 반환하기까지의 전체 과정이 기록됩니다. 각 실행에는 에이전트와 사용자, 요청, 적용된 정책을 식별할 수 있는 정보도 함께 남습니다.

감사 로그를 통해 다음과 같은 내용을 확인할 수 있습니다.

• 에이전트를 누가 만들었는가

• 어떤 업무를 목적으로 만들었는가

• 누가 운영을 승인했는가

• 실행 당시 어떤 정책이 적용됐는가

• 현재 책임자는 누구인가

기록은 기존 내용을 수정하는 대신 새로운 내용을 덧붙이는 방식으로 저장됩니다. 따라서 사후에 기록이 변경됐는지 확인할 수 있으며, 장애 조사나 보안 점검, 규제 대응에 필요한 증빙 자료로도 활용할 수 있습니다.

사용량과 비용은 별도의 대시보드에서 관리합니다. 부서·에이전트·모델별 사용량과 비용을 매일 집계하고, 예산 경보선을 설정하면 한도에 도달하기 전에 담당자에게 알림을 보냅니다. 사용자별 API 키를 발급하면 개인별 사용량도 추적할 수 있습니다. 여러 AI 서비스와 벤더에 분산된 비용을 한 화면에서 확인할 수 있다는 점도 장점입니다.

AX Console의 관제 대시보드에서는 다음과 같은 운영 현황을 한눈에 확인할 수 있습니다.

• 관리 중인 에이전트 수

• 전체 호출 건수

• 정책에 따라 차단된 호출 건수

• 승인 대기 중인 요청 수

별도의 실행 조회 화면에서는 에이전트가 어떤 업무에 사용되고 있는지, 개별 실행이 어떤 과정을 거쳤는지, 부서별 사용량과 모델 비용이 어디에 집중되는지를 확인할 수 있습니다. 이 화면은 운영 현황을 확인하기 위한 조회 전용 화면이며, 실행을 직접 중단하는 기능은 제공하지 않습니다.

화면 구성과 정책 항목은 AX Console 운영 매뉴얼 v1.0을 기준으로 작성했습니다. 실제 메뉴와 세부 항목은 고객사의 업무 환경과 보안 요건을 반영해 상세 설계 단계에서 커스터마이징을 거쳐 확정합니다.

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

기존 제작 솔루션을 바꾸지 않아도 됩니다. AX Foundry는 에이전트를 직접 제작하는 솔루션이 아니라, 여러 제작 솔루션에서 만들어진 에이전트를 등록하고 운영하는 관리 솔루션입니다. 제작 단계와 운영 단계는 서로 보완하는 관계입니다.

에이전트 개발 솔루션 없이 AX Foundry만 도입할 수 있습니다

AX Foundry는 특정 빌더에 종속되지 않으며, 에이전트 제작 도구와 운영·관리 기능을 분리해 사용할 수 있습니다. 이미 사내에서 운영 중인 에이전트가 있다면, 별도의 제작 솔루션을 추가하지 않고 AX Foundry만 도입해 등록과 관제부터 시작할 수 있습니다.

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

사용할 수 있습니다. AX Foundry는 기존 인프라와 보안 기준을 바꾸지 않고, 현재 환경 위에 설치할 수 있도록 설계되어 있습니다.

어떤 환경을 선택하더라도 등록·정책·승인·감사로 이어지는 운영 체계는 동일하게 적용할 수 있습니다. 특정 모델 공급사에 종속되지 않기 때문에 나중에 언어 모델 엔진을 교체해도 기존 운영 체계를 유지할 수 있습니다.

폐쇄망과 망분리 환경에서 AI를 운영하기 위한 조건은 온프레미스 AI란 무엇일까에서 자세히 설명하고 있습니다.

도입하면 무엇부터 시작하고, 얼마나 걸리나요?

처음부터 전사에 모든 기능을 한 번에 적용할 필요는 없습니다. 먼저 사내 에이전트 현황을 등록하고, 이후 필요한 통제 수준에 따라 관리 기능을 단계적으로 확장할 수 있습니다.

AX Foundry의 기능은 크게 네 개 모듈로 나뉩니다. 이 모듈은 등록·정책·승인·감사라는 관리 기능을 단순히 순서대로 나눈 것이 아닌, 실제 도입 범위와 운영 수준을 기준으로 구성한 단계입니다. 따라서 조직의 에이전트 운영 현황과 위험도 등 필요한 관리 수준에 따라 일부 모듈만 먼저 도입하거나 여러 모듈을 함께 구축할 수 있습니다.

필요한 단계부터, 모듈 네 개

기존 에이전트를 등록 모듈에 추가하려면 에이전트마다 식별자를 부여하고 등록부에 올려야 합니다. 새로운 제작 솔루션을 연결할 때는 어댑터를 추가해야 하며, 솔루션 하나당 약 1~2주가 더 걸릴 수 있습니다.

관측 모듈은 게이트웨이 없이도 도입할 수 있습니다. 다만 통제 모듈에서 결재선이나 그룹웨어를 연동하려면 고객사의 업무 방식과 시스템 환경을 확인한 뒤 별도로 협의해야 합니다.

모든 에이전트에 가장 높은 수준의 통제를 적용할 필요는 없습니다. 중요도와 위험도가 높은 에이전트에는 통제 모듈을 적용하고, 위험도가 낮은 에이전트에는 등록이나 관측 중심으로 운영할 수 있습니다.

네 모듈을 모두 순서대로 구축하면 단순 합산 기준으로 약 13~17주가 걸립니다. 다만 실제 기간은 고객사의 요구사항과 시스템 환경에 따라 달라집니다. 특히 통제 모듈의 구축 기간은 별도 협의가 필요합니다. 실행 기록을 남기는 감사 기능을 어느 모듈에 포함할지도 요구사항을 확정하는 단계에서 결정합니다.

현재 상황에 맞춰 선택하는 세 가지 패키지

패키지에 따라 관리 체계를 구축하는 동시에 초기 운영에 사용할 에이전트를 준비할 수 있습니다.

AX Foundry는 에이전트를 직접 제작하는 솔루션이 아니지만, 첫 도입 단계에서 특정 업무처리에 적합한 에이전트를 정의하고 준비하는 과정을 지원합니다. 이를 통해 고객사는 처음부터 모든 에이전트를 준비해야 하는 부담을 줄이고 우선순위가 높은 업무부터 운영을 시작할 수 있습니다.

사용할수록 회사의 자산으로 남습니다

단계별 경험과 운영 기준이 쌓일수록 고객사가 직접 담당할 수 있는 범위가 넓어지고 외부 지원에 대한 의존도는 줄어듭니다.

지금 사내에서 운영 중인 AI 에이전트가 몇 개인지, 누가 관리하고 있는지, 어떤 데이터에 접근하는지 바로 답하기 어렵다면 AX Foundry 도입을 검토해 보시기 바랍니다. 모든 에이전트를 한 번에 바꾸거나 전사 시스템을 즉시 재구축할 필요는 없습니다. 먼저 한 부서나 몇 개의 핵심 에이전트부터 등록하고, 운영 현황과 비용, 책임 범위를 확인하는 것부터 시작할 수 있습니다.

오픈네트웍시스템은 현재 사용 중인 에이전트와 제작 환경, 보안 요건을 함께 확인한 뒤 적절한 도입 범위와 순서를 제안합니다. 사내 AI 에이전트를 회사가 책임질 수 있는 자산으로 전환하고 싶다면, 지금 AX Foundry 도입 상담을 신청해 보세요.

자주 묻는 질문

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

아닙니다. AX Foundry는 이미 만들어진 에이전트를 등록하고 운영하는 관리 솔루션입니다. 에이전트 제작은 기존에 사용하던 빌더나 개발 방식을 그대로 유지하고, AX Foundry는 그 상위에서 등록·정책·승인·감사를 담당합니다.

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

다시 만들지 않아도 됩니다. Dify 같은 워크플로형 빌더로 만든 에이전트, n8n으로 구성한 자동화, 사내 개발팀이 직접 구현한 에이전트 모두 AX Foundry에 등록되는 시점부터 정책과 감사 대상이 됩니다. 새롭게 도입하는 솔루션은 어댑터를 추가해 편입할 수 있습니다.

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

인터넷이 차단된 내부망에 온프레미스로 설치할 수 있습니다. 프라이빗·퍼블릭 클라우드를 함께 사용하는 하이브리드 구성과 기존 쿠버네티스 클러스터 위에 이미지를 배포하는 방식도 지원합니다. 어느 환경에 설치하더라도 등록·정책·승인·감사로 이어지는 운영 체계는 동일하게 사용할 수 있습니다.

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

등록 모듈은 약 2주가 예상되며, 기준 모듈 2~3주와 관측 모듈 3~4주가 추가됩니다. 통제 모듈의 예상 기간은 약 6~8주이지만 구체적인 기간은 협의가 필요합니다. 네 모듈을 단순 합산하면 약 13~17주이며, 고객사의 요건이 확정된 이후 산정되는 예상치입니다. 모든 모듈을 한 번에 도입할 필요는 없습니다.

비용은 어떻게 잡나요?

도입 범위와 고객사 환경에 따라 달라집니다. 필요한 모듈만 선택하는 방식, 특정 부서부터 시작하는 방식, 네 개 모듈을 모두 구축하는 방식 중에서 선택할 수 있어 첫 도입 규모를 작게 설정할 수도 있습니다. 구체적인 비용은 진단 상담에서 범위를 정한 뒤 안내합니다.

운영은 누가 맡게 되나요?

구축 단계에서는 오픈네트웍시스템이 등록·정책·승인·감사 체계를 구성합니다. 이후 교육과 운영 기준을 고객사에 이관해 내부에서 직접 운영하고 확장할 수 있도록 지원합니다. 필요한 인력 규모는 도입 범위와 시스템 환경에 따라 달라지므로 도입 상담에서 별도로 안내합니다.

도입을 검토하고 계신다면

사내에 몇 개의 AI 에이전트가 운영되고 있는지 지금 답할 수 없다면, 먼저 전체 목록을 만드는 것부터 시작해야 합니다.

오픈네트웍시스템의 진단 상담에서는 현재 사내에서 운영 중인 에이전트가 몇 개인지, 각 에이전트를 누가 관리하고 어떤 데이터와 시스템에 연결되어 있는지 함께 확인합니다. 아직 정확한 목록이 없더라도 괜찮습니다. 부서별 사용 현황과 제작 환경을 바탕으로 관리 대상과 우선순위를 정리해 드립니다.

상담 후에는 현재 업무의 병목과 에이전트 도입이 효과적인 업무, 적절한 시작 범위, 예상 구축 기간, 구매 조건까지 함께 안내해 드립니다. 전사 도입이 필요한지, 특정 부서나 핵심 에이전트부터 시작하면 되는지도 현재 상황에 맞춰 제안합니다.

등록 모듈은 약 2주 범위에서 시작할 수 있습니다. AX Console의 관제 대시보드와 실제 운영 방식을 직접 확인하고 싶으시다면 데모도 요청해 주시기 바랍니다.

출처

출처

• Microsoft, Cloud Adoption Framework 「Govern and secure AI agents across the organization」 (2026.4.9)

• 금융위원회, 「금융분야 인공지능 가이드라인」 개정안 (2026.6.18 발표, 2026.6.22 시행)

• Moffatt v. Air Canada, 2024 BCCRT 149 (캐나다 브리티시컬럼비아주 민사분쟁해결재판소, 2024.2)

• McCarthy Tétrault, 「Moffatt v. Air Canada: A Misrepresentation by an AI Chatbot」

• Dentons Data, 「Airline ordered to compensate a B.C. man because its chatbot provided inaccurate information」

• 오픈네트웍시스템, 「AX Foundry 서비스 소개서」 (2026.8.26 전달본)

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