Dataiku Agent Management 발표 — 흩어진 AI 에이전트의 비용과 성과를 함께 봅니다

SVIL - Singularity Visual Intelligence Lab 2026. 09. 25 14 min read

팀마다 AI 에이전트를 만들기 시작하면 회사 전체에 무엇이 돌아가는지 묻는 일이 어려워집니다. Dataiku가 9월 24일 발표한 Agent Management는 여러 제작 플랫폼에 흩어진 에이전트를 한곳에서 관리하려는 제품입니다.

발표와 즉시 이용 가능은 다릅니다. 공식 안내의 일반 제공 예정은 2026년 10월이며, 이 글은 제품을 직접 사용한 평가가 아니라 공개 발표와 제품 문서를 확인한 정리입니다. 적용 사례는 별도로 가상 예시라고 표시했습니다.

에이전트가 늘면 먼저 사라지는 것

자동화가 늘면 코드보다 소유권이 먼저 흐려질 수 있습니다. 누가 만들었는지는 알아도 지금 누가 운영하고 있으며 어떤 자료에 접근하는지는 다른 질문입니다.

Dataiku는 이런 흩어진 에이전트의 목록·성과·위험을 관리 대상으로 삼습니다. 관리 제품의 가치는 항목을 많이 보여주는 데서 끝나지 않고, 각 항목에 책임과 판단 근거를 연결하는 데 있습니다.

이번 발표와 실제 출시 일정

9월 24일 공식 발표는 Succeed 행사에서 소개한 독립 제품과 10월 일반 제공 계획을 설명합니다. 앞서 예고된 관리 방향과 이번 상용화 발표를 구분해야 합니다.

따라서 오늘 모든 계정에 이미 제공된다고 표현할 근거는 없습니다. 구체적인 이용 범위는 실제 출시 안내와 계약 조건으로 다시 확인할 부분입니다.

에이전트 목록에 필요한 정보

제품 문서는 에이전트를 목록으로 모으고 담당자와 목적을 연결한다고 설명합니다. 단순한 실행 프로세스 목록보다 업무 단위의 장부에 가깝습니다.

운영 관점에서 목적이 없으면 성과도 정의하기 어렵습니다. 고객 문의에 답하는 에이전트와 내부 초안을 만드는 에이전트는 같은 정확도 숫자만으로 비교할 수 없습니다.

여러 플랫폼을 연결하는 방식

공식 제품 FAQ는 외부 플랫폼의 API와 로그를 통해 연결한다고 설명합니다. 자동 탐색을 하더라도 먼저 연결과 인증이 필요합니다.

제품의 플랫폼 독립성은 모든 내부 동작을 마법처럼 알아낸다는 뜻이 아닙니다. 연결 가능한 인터페이스와 권한이 관측의 출발점이라는 점이 중요합니다.

연결 범위와 관측 사각지대

FAQ는 통합 깊이가 외부 플랫폼이 제공하는 정보에 달린다고 명시합니다. 같은 목록에 올라와도 어떤 에이전트는 상세 기록이 있고 어떤 것은 일부 상태만 보일 수 있습니다.

가상의 도입 검증에서는 플랫폼별로 수집 가능한 항목을 표로 나누는 방법이 합리적입니다. 빈칸을 정상으로 표시하지 않고 관측 불가 상태로 드러내야 합니다.

서버 가동률과 업무 성과

서버가 응답했다는 사실과 업무가 올바르게 끝났다는 사실은 다릅니다. Dataiku의 기존 관측성 설명도 이 차이를 강조합니다.

예를 들어 잘못된 문서를 근거로 매번 빠르게 답하는 에이전트는 시스템 가동률이 높아도 업무 품질은 낮습니다. 완료 결과를 따로 측정할 필요가 생기는 이유입니다.

사용량이 적을 때 확인할 것

사용량은 수요를 보여주지만 곧바로 효용을 뜻하지는 않습니다. 쓰는 사람이 적다면 기능을 몰라서인지, 결과를 신뢰하지 못해서인지, 실제 업무가 드문지 확인할 부분이 다릅니다.

이는 이 글의 운영상 해석입니다. 사용량 하나로 유지·중단을 정하면 드물지만 꼭 필요한 업무를 놓치거나 자주 쓰이지만 부정확한 도구를 과대평가할 수 있습니다.

비용을 성공한 업무에 연결합니다

비용은 호출 수만으로 읽기보다 성공한 업무 단위와 연결해 볼 수 있습니다. 재시도와 사람의 수정 시간이 많으면 낮은 호출 단가가 전체 비용 절감으로 이어지지 않을 수 있습니다.

가상 지표로는 승인된 결과 한 건당 비용, 수정에 든 시간, 재작업 비율을 함께 보는 구성을 생각할 수 있습니다. 이 수치는 제품이 보장한 절감률이 아닙니다.

품질 평가의 기준을 정합니다

에이전트마다 기대 결과가 다르므로 품질 평가도 목적에 맞게 정해야 합니다. 정해진 서식을 채우는 업무와 질문에 근거를 붙여 답하는 업무는 실패 조건이 다릅니다.

제품 설명은 목적에 맞춘 사용량·비용·품질 추적을 제시합니다. 실제 평가 문항과 합격 기준까지 조직 대신 자동으로 결정해 준다고 해석할 근거는 없습니다.

행동 변화와 드리프트

드리프트는 처음의 기대에서 행동이 달라지는 문제입니다. 모델이 바뀌거나, 검색 자료가 늘거나, 도구의 응답 형식이 바뀌는 등 여러 변화가 결과에 영향을 줄 수 있습니다.

단순히 지난주보다 점수가 낮다는 알림보다 어떤 구성 변화와 겹쳤는지를 함께 보는 편이 유용합니다. 원인 분석을 위해 버전 정보를 남길 이유가 생깁니다.

도구와 모델의 의존 관계

공식 발표는 에이전트가 의존하는 도구와 모델을 파악하는 기능을 설명합니다. 목록 속 에이전트 하나도 실제로는 여러 시스템을 묶은 실행 단위입니다.

가령 공유 검색 도구가 바뀌면 여러 팀의 결과가 동시에 달라질 수 있습니다. 이런 경우 에이전트 하나씩 고치는 것보다 공통 의존 관계를 보는 편이 원인을 찾기 쉽습니다.

위험에 따라 관리 깊이를 나눕니다

모든 에이전트에 같은 수준의 검토를 적용하면 비용이 커지고 중요한 위험이 묻힐 수 있습니다. 고객에게 직접 응답하는지, 민감한 자료를 보는지, 실제 거래를 바꾸는지가 구분점이 됩니다.

발표문은 높은 위험의 에이전트에 인증 상태와 위험·테스트 기록을 연결하는 방향을 제시합니다. 구체적인 등급은 각 조직이 업무와 권한에 맞게 정할 부분입니다.

인증 상태와 테스트 기록

제품 안내에는 운영 허용 상태와 위험 완화 조치, 재실행한 테스트의 기록을 관리하는 기능이 나옵니다. 여기서 인증은 곧 모든 외부 법규를 자동 충족한다는 뜻이 아닙니다.

기록은 판단을 뒷받침하는 자료입니다. 누가 어떤 조건을 보고 승인했는지가 있어야, 이후 조건이 바뀌었을 때 다시 검토할 이유도 분명해집니다.

정기 재평가가 필요한 이유

처음 한 번 통과한 에이전트도 운영 중에 바뀔 수 있습니다. OWASP 에이전트 보안 안내는 프롬프트·도구·모델 등의 중요한 변경 뒤 검증을 다룹니다.

일정에 따른 재평가와 변경에 따른 재평가를 함께 두는 구성을 생각할 수 있습니다. 지난달 결과를 그대로 보여주는 것과 현재 상태를 시험한 결과는 다릅니다.

AI 게이트웨이와의 역할 차이

공식 FAQ는 Agent Management가 AI 게이트웨이가 아니라고 구분합니다. 도구로 가는 요청을 중간에서 제어하는 계층과 에이전트를 위에서 관찰·관리하는 계층은 역할이 다릅니다.

따라서 목록에 등록됐다는 이유만으로 위험한 요청이 실행 단계에서 차단된다고 단정할 수 없습니다. 모니터링과 실행 권한 정책을 따로 확인할 부분입니다.

기존 제작 플랫폼을 옮겨야 할까

여러 플랫폼 위에 관리 계층을 두는 방향이므로 모든 에이전트를 Dataiku에서 다시 만드는 제품으로 설명되지는 않습니다. 다만 실제 통합 작업이 전혀 없다는 뜻도 아닙니다.

Agent Hub처럼 제작·운영 연결을 다루는 기능과 관리 제품의 범위를 비교하면, 어떤 시스템이 무엇을 맡는지 구분하기 쉽습니다.

요금 구조에서 확인되는 것

공식 발표에서 확인되는 요금 구조는 인스턴스별 연간 이용료와 관리 대상 에이전트 단위의 계량입니다. 구체적인 금액은 해당 발표문에서 공개되지 않았습니다.

그러므로 지금 비용이 저렴하다거나 몇 개부터 손익분기점이라는 결론을 낼 수는 없습니다. 평가할 때는 시험용·중단된 에이전트가 어떻게 집계되는지도 확인할 부분입니다.

고객 응대 업무의 가상 사례

가상 사례로 고객 응대 에이전트가 빠르게 답하지만 환불 규정을 자주 잘못 설명하는 상황을 생각해 볼 수 있습니다. 가동 시간과 응답 시간만 보면 문제가 숨을 수 있습니다.

이 업무에는 정책에 맞는 답변 비율, 상담원 이관 결과, 사람이 수정한 비율을 함께 볼 수 있습니다. Dataiku 고객의 실제 성과 사례를 인용한 것이 아니라 평가 설계 예시입니다.

내부 보고 업무의 가상 사례

또 다른 가상 사례는 내부 주간 보고서를 만드는 에이전트입니다. 보고서 생성 성공만 세면 잘못된 숫자가 들어간 초안도 완료로 집계될 수 있습니다.

원본 수치와 일치했는지, 근거 링크가 유효한지, 승인된 최종본이 만들어졌는지를 구분하는 편이 합리적입니다. 완료 기준이 성과 측정의 일부가 됩니다.

중복 에이전트를 찾은 다음

비슷한 목적의 에이전트가 여러 개 보인다고 무조건 합칠 필요는 없습니다. 접근 권한이나 언어, 실제 이용자가 달라 따로 운영하는 이유가 있을 수 있습니다.

중복 발견 뒤에는 목적과 결과, 운영 소유자를 비교하는 단계가 필요합니다. 관리 목록은 결정을 돕는 근거이지 자동 삭제를 정당화하는 명령이 아닙니다.

관리 시스템 자체의 접근 권한

중앙 관리 도구에는 여러 팀의 로그와 실행 정보가 모일 수 있습니다. 따라서 관리 도구를 보는 사람의 권한과 내보내기 범위도 설계 대상입니다.

Dataiku의 거버넌스 안내는 책임과 정책 연결을 설명합니다. 실제 연결에 필요한 최소 권한과 수집하는 민감정보 범위는 도입 시 검증할 부분입니다.

도입 검증에서 남길 근거

도입 검증에서는 기존 에이전트 하나를 연결하고, 목록에 보이는 항목과 실제 플랫폼 상태를 대조하는 방법이 유용합니다. 일부 로그가 빠지는 상황도 함께 확인할 수 있습니다.

이 글이 제안하는 판정 기준은 연결 성공 문구가 아니라 최신 실행, 비용, 담당자, 평가 결과가 정확히 되돌아오는지입니다. 관측 지연과 누락을 알 수 있어야 운영에 쓸 수 있습니다.

핵심 정리

Dataiku Agent Management의 이번 발표는 에이전트 관리의 단위를 서버에서 업무와 책임으로 넓히려는 시도입니다. 공식 일반 제공 예정은 10월이며, 실제 제품 성능을 이번 글에서 검증한 것은 아닙니다.

플랫폼 연결 범위, 성과 기준, 실행 통제와의 역할 분리, 과금 집계 방식이 실제 도입에서 살펴볼 핵심입니다. 에이전트 개수보다 관리 가능한 상태가 중요합니다.

공식 자료에서 확인할 부분

공식 제품 FAQ의 게이트웨이 구분과 통합 깊이에 대한 문답을 먼저 읽으면 기대 범위를 잡기 쉽습니다. 발표문은 출시 일정과 요금 구조를 확인하는 기준 자료입니다.

여러 자동화를 운영하고 계시다면 이름·담당자·목적·최종 검증 시각만 모아 보아도 관리의 빈칸이 드러날 수 있습니다. 실제로 겪은 관리 문제는 블로그에서 함께 나눠도 좋겠습니다.

출처

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://svil.dev/