Dataiku Agent Management 정식 공개 전, 기업은 AI Agent를 어떻게 점검할까? 2026 체크리스트

Dataiku는 2026년 9월 24일 Agent Management를 발표하고 2026년 10월 정식 공개 계획을 밝혔습니다. 공식 발표를 확인한 지금의 우선순위는 제품 공개를 기다리는 일이 아닙니다. 먼저 여러 플랫폼에 흩어진 Agent의 목록과 담당자, 위험 근거를 정리하세요. 모니터링 기록은 실행 권한이나 격리 통제를 대신하지 않습니다.

이 글은 여러 실행 환경을 관리하는 플랫폼 엔지니어, 민감 데이터와 고객 영향도를 검토하는 AI 거버넌스 책임자, Agent의 계속 운영 여부를 결정해야 하는 연구개발 및 업무 책임자를 위한 안내입니다.

마지막 업데이트: 2026년 9월 26일. Dataiku의 공식 발표와 제품 설명을 대조했습니다. 정식 공개 시점과 지원 범위는 이후 공식 안내에 따라 달라질 수 있습니다.

Dataiku Agent Management 공개 준비는 사내 자산 목록부터 시작합니다

제품이 여러 플랫폼의 Agent를 발견하고 상태를 관리하도록 설계됐다는 설명은 공급업체의 발표입니다. 그것만으로 회사 안의 모든 자체 개발 환경과 도구 연결까지 자동으로 찾아낸다고 판단해서는 안 됩니다. Dataiku는 OpenTelemetry를 이용한 자체 환경 지원도 설명합니다. 다만 실제 적용 범위와 필요한 계측 작업은 환경별로 확인해야 합니다.

특히 세 가지를 서로 다른 증거로 관리하세요. 자산 발견은 무엇이 존재하는지 확인하는 일이고, 실행 모니터링은 실행 중 무슨 변화가 있는지 관찰하는 일입니다. 실행 통제는 Agent가 어디에 접근하고 어떤 작업을 수행할 수 있는지 제한하는 일입니다. 하나의 대시보드에 Agent가 보인다는 사실은 나머지 두 가지가 갖춰졌다는 증거가 아닙니다.

목록에 넣을 항목	확인할 증거와 정보 출처	누락됐을 때의 조치
Agent 식별자와 버전 또는 구성	배포 목록, 저장소, 플랫폼 기록	중복 및 미등록 여부를 담당 팀에 확인합니다
실행 플랫폼과 환경	배포 설정, 계측 상태, 운영 기록	자체 환경인지 확인하고 수동 등록 대상으로 둡니다
모델, 도구, 데이터 연결	설정 파일, 비밀 정보 참조, 연결 권한	연결 대상을 확인할 때까지 민감 데이터 접근을 제한합니다
업무 목적, 이용 대상, 책임자	업무 승인 기록, 운영 팀 확인	소유자나 목적이 불명확하면 확인 대기 상태로 둡니다
정보 출처와 마지막 검증 상태	확인한 시스템과 검토 담당자	최신 여부가 확인될 때까지 승인된 자산으로 간주하지 않습니다

Dataiku가 공개한 플랫폼 연결 범위에 사내 환경이 포함되는지 확인하고, 확인할 수 없는 항목은 수동 목록에 남기세요. OpenTelemetry는 서비스를 계측해 텔레메트리를 수집하는 방식과 관련 기준을 설명합니다. 계측 개념 안내를 참고하되, 계측이 없는 환경을 자동으로 관찰 가능하다고 취급하지 마세요.

플랫폼 엔지니어는 발견 범위와 갱신 책임을 정합니다

AI Agent 자산 점검은 한 번 만든 스프레드시트로 끝나지 않습니다. 새 배포와 구성 변경 때 누가 목록을 갱신할지 정해야 합니다. 플랫폼 엔지니어는 각 실행 플랫폼과 저장소, 배포 파이프라인을 대조하고 자동 발견 결과와 수동 신고 결과를 구분해 보관하세요.

• [ ] 플랫폼별 배포 목록과 사내 Agent 등록 목록을 대조합니다.
• [ ] 각 Agent의 모델, 도구, 데이터 연결이 어느 설정과 기록에서 확인됐는지 적습니다.
• [ ] OpenTelemetry 계측 여부와 수집되는 신호를 환경별로 확인합니다.
• [ ] 자동 발견이 되지 않는 자체 환경을 담당자에게 배정해 수동 등록합니다.
• [ ] 배포 또는 구성 변경 때 목록을 갱신하는 담당 팀과 확인 절차를 정합니다.

OpenTelemetry 문서는 신호로 트레이스, 메트릭, 로그를 설명합니다. 신호 유형 안내에 있는 각 신호는 관찰에 쓰이는 서로 다른 정보입니다. 수집 신호가 있다는 사실만으로 작업 결과의 정확성이나 배포 승인을 입증할 수는 없습니다. 신호가 누락될 때 운영자가 어떤 기록을 확인하고 누구에게 에스컬레이션할지도 정해 두세요.

업무와 연구개발 책임자는 이름이 아니라 책임을 지정합니다

계정 소유자는 기술적으로 Agent를 만든 사람일 수 있지만, 실제 업무 운영과 중단 결정을 책임지는 사람과 다를 수 있습니다. 두 역할을 한 칸에 합치면 문제가 생겼을 때 사용 목적과 정지 권한을 확인하기 어렵습니다.

업무 책임자는 기대하는 결과와 이용 대상을 기록하고, 연구개발 책임자는 실제 구성과 승인된 목적이 일치하는지 확인하세요. 담당자를 찾지 못하거나 용도가 달라진 Agent는 정상 운영 목록에 넣지 말고 확인 대기 상태로 분리해야 합니다. 책임이 정해지기 전에는 고객 응답이나 데이터 변경 같은 영향이 큰 작업을 제한하는 기준을 마련하세요.

보안팀은 위험 수준을 실제 권한과 부작용으로 판단합니다

기업 Agent 거버넌스에서 우선 검토할 대상은 고객과 직접 상호작용하는 Agent, 민감한 데이터에 접근하는 Agent, 거래나 외부 시스템 변경을 수행하는 Agent입니다. 이름이나 공급업체의 위험 라벨 대신 데이터 접근, 외부 도구 호출, 실행 가능한 작업, 사람의 승인 지점을 조사하세요.

검토 기준	우선 검토 대상	필요한 증거	증거가 부족할 때
데이터 접근	민감하거나 범위가 넓은 데이터에 연결됨	접근 권한과 데이터 범위	데이터 접근을 축소합니다
외부 도구	외부 시스템에 쓰기 작업을 수행함	도구 권한과 호출 기록	읽기 전용 또는 제한된 범위로 전환합니다
부작용	거래, 사용자 응답, 구성 변경을 일으킴	승인 절차와 되돌리기 방법	사람의 승인을 요구하거나 작업을 멈춥니다
운영 책임	담당자나 업무 목적이 불분명함	소유자 확인과 업무 승인 근거	확인 대기 상태로 둡니다

위 기준은 회사가 정할 내부 분류의 출발점이지, 공급업체의 분류를 보안 인증으로 바꾸는 방법이 아닙니다. 생성형 AI 위험 관리에 관한 NIST 프레임워크와 위험 관리 플레이북을 참고해 위험 식별, 평가, 대응을 조직의 절차와 연결하세요. Agent별 권한과 도구 위험을 확인할 때는 OWASP Agent 보안 점검표도 활용할 수 있습니다.

자주 묻는 질문

정식 공개 전에 어떤 Agent 정보를 모아야 하나요?

식별자와 실행 환경뿐 아니라 모델과 도구, 데이터 연결, 업무 목적, 운영 책임자를 한 목록에 담으세요. 각 정보가 어디에서 확인됐는지, 언제 확인했는지도 기록해야 나중에 오래된 정보와 미확인 정보를 구별할 수 있습니다. 공식 연결 범위가 명확하지 않은 자체 환경은 자동으로 발견된다고 가정하지 말고 수동 확인 항목으로 유지하세요.

여러 플랫폼의 Agent 담당자와 목적은 어떻게 통일하나요?

만든 팀과 현재 운영하는 팀을 별도로 확인하고, 업무 목적과 이용 대상, 중단을 결정할 책임자를 같은 등록 절차에서 확인하세요. 계정 이름만으로 업무 책임을 추정하면 담당자가 바뀐 뒤에도 목록이 잘못된 상태로 남을 수 있습니다. 소유자나 목적이 확정되지 않은 항목은 확인 대기로 분리하고, 고영향 작업은 확인 전까지 제한하세요.

어떤 Agent를 먼저 위험 분류하고 인증해야 하나요?

민감 데이터에 접근하거나 고객에게 직접 응답하고, 거래나 외부 시스템 변경을 수행하는 항목을 우선 검토하세요. 위험 판단에는 실제 접근 권한, 외부 도구, 부작용과 사람의 승인 경계가 필요합니다. 내부 인증 기록에는 판단 근거와 검토 책임자를 남기세요. 공급업체의 기능 설명이나 위험 표시는 사내 검토와 테스트를 대신하는 인증서가 아닙니다.

모니터링 기록으로 실행 권한과 격리를 확인할 수 있나요?

아니요. 모니터링 기록은 상태와 사용량, 행동 변화를 관찰하는 데 도움을 줄 수 있지만, 권한 범위나 네트워크 격리 상태를 그 자체로 증명하지는 않습니다. 접근 제어 설정과 실행 환경, 비밀 정보 관리, 사람의 승인 절차를 각각 확인해야 합니다. 안전한 전달에 필요한 증거가 없으면 영향 범위를 줄이거나 작업을 보류하세요.

마지막 단계: 인증 증거와 중단 조건을 목록에 연결합니다

운영 모니터링과 결과 검수는 별개입니다. 상태가 정상으로 보인다고 업무 결과가 정확한 것은 아니며, 관찰 기록만으로 코드 테스트 통과나 안전한 전달을 증명할 수도 없습니다. 모니터링이 비어 있는 경우의 수동 확인 경로와 담당자를 정하고, 확인 기록이 Agent의 버전 또는 구성 변경과 연결되도록 관리하세요.

• [ ] 고위험 Agent에 담당자, 목적, 데이터와 도구 권한을 연결합니다.
• [ ] 인증 상태와 판단 근거, 테스트 결과, 다음 검토 책임자를 기록합니다.
• [ ] 구성이나 버전 변경 뒤 기존 검토 증거를 다시 확인할 조건을 정합니다.
• [ ] 증거가 부족하면 작업 범위 제한, 사람 승인, 일시 중단 중 어떤 조치를 취할지 결정합니다.
• [ ] 사용량과 비용, 업무 가치, 위험을 함께 검토해 처리 순서를 정합니다.

비용을 설명할 수 없거나 책임자가 없고 검토 증거도 부족한 Agent를 먼저 정리하세요. 공급업체의 기능 설명만으로 사내 절감액이나 필요한 실행 용량을 계산하지 마세요. 실제 작업 기록과 검증 가능한 환경 정보를 모은 뒤 판단해야 합니다.

현재 환경이 범용 클라우드나 공용 개발 장비라면 macOS 전용 빌드와 서명, 운영체제 호환성 검증을 그대로 재현하지 못할 수 있습니다. 반대로 Agent 목록과 권한 관리만을 위해 Mac을 빌릴 필요는 없습니다. 실제 macOS 도구 체인으로 납품물을 확인해야 하는 프로젝트라면, 필요한 기간에 맞춰 vmzig의 Mac 환경을 검토해 실행 환경 증거를 보완할 수 있습니다. 이는 Agent 접근 제어나 격리를 대체하지 않으므로, 먼저 권한과 승인 경계를 정하고 그다음 환경 검증이 필요한 작업에만 사용하세요.

자주 묻는 질문

Dataiku Agent Management가 열리기 전에 어떤 정보를 모아야 하나요?

Agent 이름과 식별자, 실행 플랫폼과 배포 환경, 사용 모델 및 도구, 연결 데이터, 담당 팀과 업무 목적을 우선 정리하세요. 각 정보가 어디에서 확인됐는지와 마지막 검증 상태도 함께 기록해야 합니다. 공식 연결 범위에 포함되지 않거나 사내 자체 환경에서 실행되는 항목은 자동으로 등록될 것이라 가정하지 말고, 수동 확인 대상으로 남겨 두세요.

여러 플랫폼에 흩어진 AI Agent의 담당자와 용도는 어떻게 통일하나요?

계정 소유자만으로 책임자를 정하지 마세요. 만든 팀과 현재 운영하는 팀을 별도로 확인하고, 업무 목적과 실제 이용 대상, 중단 여부를 결정할 사람까지 기록해야 합니다. 담당자를 찾지 못했거나 처음 승인된 목적에서 벗어난 Agent는 확인 대기 상태로 두세요. 책임자가 지정되기 전에는 고영향 작업을 계속 허용하지 않는 기준도 함께 정하는 편이 안전합니다.

어떤 기업용 Agent부터 위험 분류와 인증을 진행해야 하나요?

고객에게 직접 응답하거나 민감한 데이터에 접근하고, 거래 또는 되돌리기 어려운 작업을 수행하는 Agent부터 검토하세요. 데이터 접근 범위, 외부 도구 호출, 작업이 일으키는 부작용, 사람의 승인 지점을 증거와 함께 남겨야 합니다. 위험 등급은 회사의 규칙과 실제 구성에 따라 정해야 합니다. 공급업체가 표시한 위험 정보만으로 내부 인증을 완료했다고 판단하면 안 됩니다.

Agent 모니터링 기록이 실행 권한이나 격리 환경 통제를 대신하나요?

대신하지 않습니다. 모니터링은 상태나 사용량, 동작 변화의 단서를 제공할 수 있지만, 어떤 파일과 데이터에 접근할 수 있는지 또는 실행 프로세스가 격리됐는지를 그 기록만으로 증명하지는 못합니다. 권한 설정과 네트워크 경계, 비밀 정보 관리, 사람의 승인 절차는 별도 증거로 확인하세요. 영향이 큰 작업에 증거가 부족하면 범위를 제한하거나 실행을 멈추고 보완 검증을 진행해야 합니다.