오늘 사용되는 모든 소프트웨어는 단 하나의 가정 아래 구축되었습니다. 화면 앞에 손가락을 가진 누군가가 앉아 있다는 가정입니다. 버튼은 의도를 암시합니다. 위저드(Wizards)는 복잡성을 관리합니다. 양식(Forms)은 인간의 사고를 구조화합니다. 최근까지 클릭하는 주체는 인간뿐이었기에, 이러한 아키텍처는 수십 년간 제품 디자인을 지배해 왔습니다.
이제 그 가정은 깨졌습니다. AI 에이전트는 인터페이스를 읽지 않습니다. 유용한 툴팁이나 확인 대화 상자로부터 이득을 얻지도 않습니다. 자율 시스템이 사용자를 대신해 행동해야 할 때, UI 요소(chrome)는 오히려 방해가 됩니다. 그 결과, 제품이 구축되는 방식과 현대의 호출자(callers)가 실제로 행동하는 방식 사이에 점점 더 큰 불일치가 발생하고 있습니다.
클릭 패러다임
전통적인 소프트웨어는 시각적 계약에 의존합니다. 인간은 버튼을 보고, 레이블을 이해하며, 그것을 누를지 결정합니다. 워크플로우에는 의도적으로 마찰(friction)이 가미됩니다. 사람들이 실수를 저지르고 가드레일이 필요하기 때문에 다단계 위저드가 존재합니다. 드롭다운과 라디오 버튼은 자유 형식의 텍스트가 혼란을 초래할 수 있기 때문에 입력을 제한합니다.
운영자가 사람일 때는 이 방식이 잘 작동합니다. 하지만 운영자가 에이전트라면 이 방식은 무너집니다. 기계는 구독을 취소하거나 레코드를 수정하기 위해 5단계 위저드를 필요로 하지 않습니다. 기계에게 필요한 것은 어떤 작업이 존재하는지에 대한 명확한 명세와, 해당 작업을 수행할 권한이 있는지에 대한 확정적인 답변입니다. 팀들이 이를 간과할 때, 보통 두 가지 지름길을 선택합니다.
첫째, 에이전트에게 API 키를 넘겨줍니다. 둘째, 기존 사용자 인터페이스를 챗봇으로 감싸고 통합이 완료되었다고 간주합니다. 두 방식 모두 근본적인 문제를 해결하지 못합니다.
API 키는 "이 요청이 신뢰할 수 있는 소스에서 왔는가?"라는 질문에는 답할 수 있습니다. 하지만 정작 중요한 질문인 "이 특정 호출자가 이 특정 레코드를 읽을 수 있는가?"에는 답하지 못합니다. 키는 마스터 키(skeleton key)와 같습니다. 한 번 발급되면 일반적으로 리소스와 컨텍스트 전반에 걸쳐 광범위한 접근 권한을 부여합니다. 시스템 내부의 개별 동작을 규정하는 정책에 대해서는 전혀 알지 못합니다.
GUI를 챗봇으로 감싸는 것은 훨씬 더 취약합니다. 에이전트는 인터페이스에 내장된 모든 인간 중심적인 가정을 그대로 물려받습니다. 자율적인 로직이 아니라 사람의 눈을 위해 설계된 모달과 양식을 통해 클릭을 시뮬레이션합니다. 챗봇이 UI 요소를 성공적으로 탐색할 수는 있겠지만, 이는 이해를 바탕으로 한 것이 아닙니다. 이는 '자동화 연극(automation theater)'에 불과합니다. 그 이면에는 무엇이 허용되는지에 대한 기계 판독 가능한 계약이 여전히 존재하지 않습니다.
에이전트에게 필요한 것은 현관문으로 통하는 또 다른 열쇠가 아닙니다. 그들에게 필요한 것은 게이트(gates)입니다.
게이트의 실제 역할
게이트는 통제된 실행 계층입니다. 자격 증명을 신뢰하고 호출자가 잘 행동하기를 바라는 대신, 게이트가 있는 시스템은 선언된 규칙에 따라 모든 요청을 평가합니다. 이러한 규칙은 인간이든 아니든 어떤 인터페이스와도 독립적으로 존재합니다.
적절한 게이트는 네 가지를 정의합니다. 제품 내에 어떤 작업이 존재하는지 선언합니다. 누가 어떤 조건에서 해당 작업을 호출할 수 있는지 명시합니다. 호출자가 사이드 이펙트(side effects)를 발생시키기 전에 언제 멈추고 명시적인 동의를 요청해야 하는지 지정합니다. 그리고 시스템이 모든 결정을 구조화되고 쿼리가 가능한 추적 로그(trail)로 기록하도록 보장합니다.
이는 전통적인 액세스 제어와 근본적으로 다릅니다. 역할 기반(Role-based) 시스템은 종종 입구에서 "관리자입니까?"라고 묻고 건물 안을 돌아다니게 허용합니다. 반면 게이트는 모든 교차로에서 "지금 이 특정 스위치를 조작할 권한이 있습니까?"라고 묻습니다. 정체성(Identity)보다 행동(behavior)이 우선시됩니다. 정책이 동작과 함께 움직입니다.
이를 구체화하기 위해, 고객에게 환불을 해야 하는 에이전트를 상상해 보십시오. 키 기반 방식은 엔드포인트에 접근할 수만 있다면 키를 가진 누구든 환불을 처리할 수 있게 할 수 있습니다. 게이트 기반 방식은 사용 가능한 작업의 매니페스트(manifest)를 확인하고, 특정 고객 레코드에 대한 에이전트의 권한을 검증하며, 금융 관련 사이드 이펙트에 대해 명시적인 사용자 승인을 요구하고, 전체 시퀀스를 감사 로그(audit log)에 기록합니다. 게이트는 단순한 정체성이 아니라 정책을 집행합니다.
Whistler에서의 테스트
우리는 이 모델을 Whistler에 적용했습니다. 인간과 기계를 위한 별도의 파이프라인을 구축하는 대신, 단일 정책 계층을 작성하고 두 가지 서로 다른 호출자를 대상으로 테스트를 진행했습니다.
한 호출자는 내장된 Shell을 사용하는 인간이었고, 다른 하나는 우리 팀 외부에서 개발된 제3자 에이전트였습니다. 둘 다 동일한 매니페스트에 연결되었습니다. 둘 다 모든 단계에서 동일한 권한 확인을 거쳤습니다. 데이터를 수정하거나 외부 이벤트를 트리거하는 것과 같이 사이드 이펙트가 있는 작업을 시도할 때, 시스템은 명시적인 승인을 요구했습니다. 모든 요청, 승인 및 거부는 동일한 구조화된 감사 추적(audit trail)을 생성했습니다.
두 호출자 모두 마스터 API 키를 사용하지 않았습니다. 정책을 우회하는 백도어도, 상향된 권한의 자격 증명도 없었습니다. 사람은 비밀번호와 브라우저를 가졌다고 해서 더 완화된 제한을 받지 않았습니다. 에이전트는 인간의 지문(fingerprint)이 없다고 해서 임의적인 차단을 당하지도 않았습니다. 게이트는 동작, 컨텍스트, 그리고 규칙을 평가했습니다. 그것이 트랜잭션의 전부였습니다.
그 결과, 사람이나 기계 등 새로운 호출자를 추가할 때 액세스 로직을 리팩터링할 필요가 없는 시스템이 구축되었습니다. 정책을 업데이트하면, 게이트가 이를 적용했습니다.
제품에 대한 질문을 다시 생각하기
만약 여러분의 팀이 현재 사람이 만든 제품에 AI 에이전트를 어떻게 추가할지 고민하고 있다면, 아마 잘못된 질문부터 시작하고 있을 가능성이 높습니다. 팀들은 본능적으로 API를 노출해야 하는지를 묻습니다. 대신, 모든 호출자에 대해 통제된 실행 계층(governed execution layer)을 갖추고 있는지를 물어야 합니다.
게이트가 없는 API는 그저 더 넓은 문일 뿐입니다. 내부 정책이 위저드 로직, 폼 검증, 사람이 읽을 수 있는 도움말 텍스트 안에만 존재한다면, 여러분이 공개하는 어떤 엔드포인트도 자율적인 호출자에게 안전할 수 없습니다. 에이전트는 키를 통해 너무 많은 신뢰를 상속받거나, 챗봇 래퍼를 통해 취약한 꼭두각시 놀음(brittle puppetry)을 수행하게 될 것입니다.
게이트를 먼저 구축한다는 것은 제품 내의 모든 의미 있는 동작을 선언된 작업(declared operation)으로 나열하는 것을 의미합니다. 이는 권한 확인을 사용자 인터페이스와 분리하여, 셸 사용자(Shell user)와 외부 에이전트 모두 동일한 런타임 강제 적용을 받게 함을 의미합니다. 또한, 에이전트가 잘못된 데이터셋을 삭제한 후가 아니라, 파괴적인 작업이 필요하기 전에 미리 동의 훅(consent hooks)을 삽입하는 것을 의미합니다. 그리고 호출자가 탄소 기반(사람)인지 실리콘 기반(기계)인지에 상관없이 보안 및 컴플라이언스 팀이 검사할 수 있는 감사 추적(audit trails)을 생성하는 것을 의미합니다.
이를 위해서는 진정한 아키텍처의 전환이 필요합니다. 인간 중심 설계는 로직을 공감과 마찰로 감쌉니다. 에이전트 대응 설계는 로직을 명시적이고 기계가 읽을 수 있는 컨트랙트(contract)를 통해 노출합니다. 인터페이스가 곧 정책이 되는 시대는 끝났습니다. 이제 매니페스트(manifest)가 정책이 됩니다.
이러한 전환은 인간을 대체하는 것이 아닙니다. 여러분의 소프트웨어에 이제 한 종류 이상의 호출자가 존재한다는 사실을 인식하는 것입니다. 각각의 호출자는 동일한 엄격함을 적용받을 자격이 있습니다.
핵심 요약
클릭을 위한 설계는 멈추십시오. 규칙을 위한 설계를 시작하십시오. 만약 여러분의 시스템이 선언된 작업, 컨텍스트 기반 권한, 동의 확인, 그리고 공유된 감사 추적을 통해 모든 호출자를 통제할 수 있다면, 반대편에 누가 혹은 무엇이 있든 상관없습니다. 사람이든 에이전트든, 모두 동일한 게이트를 통과하게 됩니다. 게이트를 먼저 구축하십시오. API는 그저 문일 뿐입니다. 방을 온전하게 유지하는 것은 바로 정책입니다.