에이전트를 사기 전에 먼저 정해야 할 ‘인터페이스 계약’

월요일 아침 운영회의에서 재무팀은 결제 예외 정리를, 영업팀은 다음 주 영업노트, CS팀은 고객응대 초안을 AI 에이전트에 의뢰했습니다. 분명 빠릅니다. 20분 안에 문서가 정리되었고, 리더는 안도의 한숨을 쉬었습니다. 하지만 실제로 확인해야 할 건 그 뒤였습니다. 어떤 데이터에서 출발했고, 누가 승인했고, 잘못된 작업은 누가 중단해 누가 복구할지 화면에는 남아 있지 않았습니다.

Anthropic의 Building Effective AI Agents은 워크플로(정해진 절차)와 에이전트(상황 기반 탐색)를 구분해야 한다고 말합니다. 즉, 모든 자동화가 에이전트가 할 일은 아니라는 뜻입니다. OpenAI의 Agents SDK는 애플리케이션이 상태와 오케스트레이션을 소유하고, Human-in-the-loop를 실제 운영 구조에 넣을 때 강점이 생긴다는 접근입니다. Google ADK는 build·interact·evaluate·deploy 순환을 강조하고, 멀티에이전트 협업과 정책 위반 감지를 전제로 합니다. MCP는 AI가 데이터·도구·워크플로우를 접속하는 USB-C 같은 개념이라, 연결점이 늘수록 인터페이스 계약이 더 중요해집니다. NIST AI RMF 1.0도 설계, 개발, 사용, 평가 전 구간에서 신뢰성 지표를 세우고 근거를 남기라고 경고합니다.

[IMAGE:opening]

> ALTOS LAB 판단: 성능 비교표가 아니라, 입력 규칙, 승인 포인트, 롤백 경로를 먼저 문서화한 조직만이 AI 에이전트를 안정적으로 확장합니다.

첫 번째, 입력 계약을 정량화

에이전트가 사용할 컨텍스트는 가장 먼저 계약합니다. 최근 현장에서 가장 흔한 오류는 ‘좋은 프롬프트 = 좋은 결과’라고 믿고 데이터 출처를 자유화하는 것입니다. 그러면 오류가 생겨도 추적이 불가능해집니다.

실무적으로는 최소 네 가지 메타를 고정합니다. (1) 허용된 데이터셋, (2) 접근 기간, (3) 수정 불가 필드, (4) 참고 로그 보존 주기입니다. 이 기준이 정해지면, 어느 에이전트 작업이 특정 규칙을 위반했는지도 즉시 추적됩니다.

두 번째, 승인·실행 분리

OpenAI가 말하는 ‘에이전트’는 도구와의 호출 체계를 가진다는 점에서 유연합니다. 반대로, 엔터프라이즈 운영에서 중요한 것은 실행 주체가 사람인지 에이전트인지의 구분입니다. 자금·법무·고객 약속 변경은 사람이 최종 승인한 뒤만 자동화 단계로 넘어가야 합니다.

Google ADK의 평가 단계는 단지 점수 출력이 아니라, 리스크 시나리오에서 실패 로그와 복구 메시지를 함께 남겨야 한다는 점을 강조합니다. 이 원칙이 있으면 주말 교대조 운영에서도 누가 무엇을 복구할지 즉시 정해집니다.

[IMAGE:mechanism]

운영팀이 바로 적용할 체크리스트

지금 주간 회의에서 바로 쓰는 6개 항목 1. 에이전트 입력은 승인된 데이터셋 3개 항목으로 제한했는가? 2. 각 작업은 저위험/중위험/고위험으로 분류되었는가? 3. 고위험 작업에서 사람 승인 지점이 실제로 존재하는가? 4. 에이전트가 호출한 툴과 API는 로그에 남는가? 5. 실패 시 복구 담당자와 회수 기준이 SLA에 적힌 상태인가? 6. 회의용 요약본과 실제 실행본을 비교하는 재검증 절차가 있는가?

이 6개를 채우지 않으면, 모델은 빠르게 작동해도 조직은 천천히 망가집니다. AI 에이전트의 본질은 속도보다 지속성입니다. 계속 쓰는 구조를 만들려면 계약을 먼저 씁니다.