본문으로 건너뛰기

01. AI 에이전트 플랫폼 검증 가이드

이름과 데모보다 먼저 확인할 것은 출처, 데이터 경계, 실패 경로, 운영 증거다.

이 페이지의 이전 버전은 출처를 제시하지 않은 채 Arrow 1.0이라는 제품의 기능, 연동 대상, 가격과 운영 준비 상태를 사실처럼 설명했다. 공개 문서, 저장소, 릴리스 노트처럼 독자가 다시 검증할 수 있는 근거가 없었으므로 해당 주장은 유지하지 않는다. 대신 같은 종류의 AI 에이전트 플랫폼을 실제로 평가할 때 재사용할 수 있는 검증 절차를 남긴다.

이 가이드는 특정 제품을 추천하거나 존재를 보증하지 않는다. 공급자가 제시한 주장은 검증 전 상태로 취급하고, 도입 결정은 아래 증거가 확보된 범위에서만 내린다.

1. 평가할 시스템의 경계를 먼저 그린다​

"에이전트 플랫폼"은 모델 하나가 아니다. 일반적으로 사용자 요청, 모델 호출, 도구 실행, 외부 데이터 접근, 상태 저장, 관측과 승인 절차를 연결하는 실행 계층이다. 따라서 제품 이름보다 먼저 다음 데이터 흐름을 한 장으로 그린다.

  1. 어떤 입력이 시스템에 들어오는가
  2. 입력과 중간 결과가 어디에 저장되는가
  3. 어느 모델과 외부 서비스로 데이터가 전송되는가
  4. 도구가 어떤 자격증명과 권한으로 실행되는가
  5. 사람이 어느 단계에서 승인하거나 중단할 수 있는가
  6. 실패·재시도·부분 성공이 어떤 상태를 남기는가

이 흐름을 공급자 문서만으로 그릴 수 없다면 평가를 멈춘다. "지원한다"는 기능 목록은 데이터가 어디로 이동하고 누가 책임지는지를 설명하지 못한다.

2. 주장마다 증거 등급을 매긴다​

모든 제품 주장을 같은 무게로 읽지 않는다. 아래 순서에서 위쪽일수록 재현 가능성이 높다.

등급증거확인할 내용
A공개 저장소, 버전이 고정된 문서, 재현 가능한 테스트실제 API, 권한, 실패 동작, 릴리스 이력
B공식 보안 문서, 아키텍처 문서, 감사 보고서데이터 보존, 암호화, 격리, 사고 대응 범위
C직접 실행한 제한된 파일럿지연, 비용, 품질, 재시도, 운영자의 개입량
D공급자 데모·마케팅·구두 설명검증할 가설로만 기록

"운영 준비 완료", "안전한 실행", "모든 모델 지원" 같은 넓은 문구는 그 자체로 증거가 아니다. 지원 버전, 제한 조건, 측정 기간과 실패 사례가 없으면 D 등급으로 둔다.

3. 보안과 권한 경계를 검증한다​

에이전트는 단순한 채팅 UI보다 큰 권한을 갖기 쉽다. SaaS 토큰, 저장소 쓰기 권한, 고객 데이터, 사내 검색 시스템을 한 실행 그래프에 연결하면 모델의 잘못된 판단이 실제 부수 효과로 이어진다. 최소한 다음 항목을 파일럿 전에 확인한다.

  • 자격증명은 모델 문맥과 로그에서 분리되는가
  • 도구별 최소 권한과 실행별 임시 자격증명을 지원하는가
  • 외부 입력이 도구 지시로 승격되는 prompt injection 경계를 검사하는가
  • 쓰기·삭제·발송 같은 고위험 작업에 명시적 사람 승인이 있는가
  • tenant, 프로젝트, 환경 사이의 데이터와 실행이 격리되는가
  • 감사 로그에 요청자, 승인자, 사용한 모델·도구·정책 버전이 남는가
  • 보존 기간과 삭제 절차를 사용자가 통제할 수 있는가

"self-hosted"라는 배포 형태만으로 이 문제가 해결되지는 않는다. 운영 책임, 업데이트, 키 관리, 로그 접근 권한이 사용자 조직으로 이동할 뿐이다.

4. 작은 파일럿으로 운영 주장을 반증한다​

데모를 재현하는 것보다 실패 조건을 만드는 편이 더 많은 정보를 준다. 읽기 전용의 낮은 위험 업무 하나를 선택하고, 고정된 입력 집합과 기대 결과를 준비한다. 정상 입력뿐 아니라 빈 응답, 느린 API, rate limit, 중복 이벤트, 잘못된 도구 결과, 모델 거부와 중간 단계 재시작을 포함한다.

파일럿에서는 다음을 함께 측정한다.

  • 업무 성공률과 사람이 수정한 비율
  • 요청당 모델·도구 비용과 최악 지연
  • 재시도가 중복 쓰기나 중복 발송을 만드는지
  • 실행 중단 후 이어서 처리할 수 있는지
  • 로그만으로 실패 원인과 영향 범위를 찾을 수 있는지
  • 모델·프롬프트·도구 버전을 바꿨을 때 회귀를 탐지할 수 있는지

평균값만으로 도입을 결정하지 않는다. 고비용 요청과 긴 지연의 상위 구간, 실패가 몰리는 입력 유형, 사람이 개입해야 하는 경계를 별도로 기록한다.

5. 도입 결정을 문서로 남긴다​

최종 결정에는 제품 소개가 아니라 검증 결과가 들어가야 한다.

  • 허용 범위: 어떤 데이터와 작업까지 맡기는가
  • 금지 범위: 자동화하지 않을 고위험 작업은 무엇인가
  • 근거: 각 핵심 주장에 대응하는 문서, 테스트, 측정치는 무엇인가
  • 통제: 권한, 승인, 비용 상한, 중단 스위치는 어디에 있는가
  • 탈출 계획: 워크플로·로그·데이터를 내보낼 수 있는가
  • 재평가 조건: 모델, 가격, 정책, 공급자 또는 데이터 흐름이 바뀌면 무엇을 다시 검증하는가

증거가 부족하면 "도입 보류"도 완전한 결론이다. 이름이 알려지지 않은 제품을 그럴듯한 기능 목록으로 채우는 것보다, 확인할 수 없음을 명시하는 편이 독자와 운영 환경에 더 안전하다.

관련 문서​

참고 자료​