챗 위젯을 위한 에이전트 레이어: 에이전트 웹에서 유용성을 유지하는 방법

에이전트 기반 브라우징은 단순한 가정을 바꿉니다. 즉, 귀하의 사이트가 더 이상 오직 인간에 의해서만 탐색되지 않는다는 것입니다. 더 많은 세션이 이미 브라우저 안에 있는 어시스턴트에 의해 시작되며, 이 어시스턴트는 페이지를 읽고, 요약하고, 사용자를 대신하여 작업을 완료하려고 시도합니다.

이는 챗 위젯에 중요합니다. 왜냐하면 챗 위젯은 에이전트가 필요로 하는 세 가지 것, 즉 컨텍스트(context), 의도(intent), 그리고 실행(execution)의 교차점에 위치하기 때문입니다. 위젯은 질문에 답할 수 있을 뿐만 아니라 라이브 시스템으로 라우팅하고, 워크플로우를 트리거하며, 정책을 강제할 수도 있습니다. 에이전트 웹에서는 이것이 위젯을 단순한 지원 버블(support bubble)이라기보다는 사이트의 가장 안전한 제어 표면(control surface)처럼 만듭니다.

저희는 이미 에이전트 웹의 도래에 대해 작성했습니다. 이것은 실질적인 후속 조치입니다. 즉, 챗봇 위젯을 무엇으로 변경해야 에이전트와 경쟁하는 대신 함께 작동할 수 있게 하고, 취약한 UI 스크래핑 없이 고급 작업을 완료할 수 있게 할 것인가 하는 문제입니다.

일반적인 위젯이 에이전트에게 어려움을 겪는 이유

대부분의 챗 위젯은 답변을 읽고 클릭하는 인간을 위해 만들어졌습니다. 하지만 에이전트는 다르게 행동합니다. 그들은 '재고 확인', '플랜 비교', '데모 예약', '반품 시작', '티켓 열기'와 같은 목표를 가지고 도착합니다. 만약 사이트가 명확한 경로를 제공하지 않는다면, 에이전트는 사용자가 하듯이 HTML을 읽고, 버튼을 클릭하고, 폼 플로우를 시도하며 추측하게 됩니다.

이러한 접근 방식은 취약합니다(brittle). 웹사이트는 변경됩니다. A/B 테스트가 버튼을 이동시킵니다. 제품 세부 정보는 탭, 툴팁, PDF 및 동적 구성 요소에 걸쳐 분할되어 있습니다. 심지어 에이전트가 올바르더라도, 왜 그 결정을 내렸는지 또는 어떤 데이터를 사용했는지 쉽게 감사(audit)할 수 없습니다.

또한 안전성 문제도 있습니다. 에이전트 웹에서 에이전트는 끊임없이 신뢰할 수 없는 콘텐츠에 노출됩니다. 만약 귀하의 유일한 인터페이스가

에이전트 레이어는 위젯을 위한 작고 실용적인 업그레이드입니다. 새로운 표준이나 공개해야 할 비밀 정보가 필요하지 않습니다. 단지 세 가지를 명시적으로 만듭니다.

첫째, 위젯은 자신이 무엇을 할 수 있고 어떤 규칙을 따르는지 선언해야 합니다. 에이전트는 시행착오로 능력을 추론할 필요가 없어야 합니다. 위젯이 티켓 생성이나 데모 예약 같은 작업을 지원하는지, 어떤 언어를 지원하는지, 그리고 어떤 작업에 확인이 필요한지를 빠르게 발견할 수 있어야 합니다.

둘째, 위젯은 산문(prose)뿐만 아니라 구조화된 형태로 응답해야 합니다. 인간은 단락을 원합니다. 에이전트는 설명과 분리된 사실들, 즉 발견된 주요 엔티티, 신뢰도 신호, 제안되는 다음 단계, 그리고 민감한 작업에 사용자 확인이 필요한지 여부를 필요로 합니다.

셋째, 위젯은 UI 자동화를 장려하기보다는 통제된 액션(controlled actions)을 제공해야 합니다. 무언가를 해야 할 때(티켓 생성, 예약 스케줄링, 재고 조회 실행 등)는 서버에서 권한, 개인 정보 보호 및 감사 기능을 강제하는 승인된 액션 경로를 통해 이루어져야 합니다.

이것이 한 문장으로 정의되는 에이전트 레이어입니다: 발견 가능한 기능(discoverable capabilities), 구조화된 답변(structured answers), 통제된 액션(controlled actions).

실제 챗봇 사용 사례에서 이것이 가능하게 하는 것들

위젯이 에이전트 준비 상태가 되면, 페이지 텍스트만으로는 안정적으로 수행하기 어려운 워크플로우를 활성화할 수 있습니다.

흔한 예시로 **제품 지원(product support)**이 있습니다. 사용자가 보증의 특수한 경우(warranty edge case), 호환성 규칙, 또는 정책 세부 사항에 대해 질문합니다. 페이지에는 전체 답변이 거의 포함되어 있지 않습니다. RAG 기반 위젯은 문서에서 답변할 수 있지만, 에이전트는 다음에 무엇을 해야 하는지도 알아야 합니다. 구조화된 응답은 안전한 다음 단계를 제안할 수 있습니다: 티켓 개설을 제안하거나, 확인을 요청하거나, 최소한의 세부 정보만 수집하는 것입니다.

또 다른 예시는 재고 및 가격 책정입니다. UI를 스크래핑하는 에이전트는 재고 여부 라벨을 잘못 읽거나 “현재 사이트에서 재고 있음”과 “3일 후 배송 예정”의 차이를 놓칠 수 있습니다. 제어된 재고 액션을 가진 위젯은 테넌트와 사이트에 정확하게 범위가 지정된 실시간 결과를 반환하며, 사용자에게 명확한 설명을 제공할 수 있습니다.

세 번째 예시는 리드 확보 및 일정 예약입니다. 에이전트는 양식을 작성할 수 있지만 오류가 발생하기 쉽고 종종 작동이 멈춥니다. 제어된 예약 액션은 안정적인 흐름, 일관된 검증, 그리고 분석에서 깔끔한 기여도를 제공합니다.

각 경우에 에이전트는 신뢰할 수 있는 인터페이스를 얻게 됩니다. 비즈니스는 깨진 플로우가 줄고 추적 가능성이 높아집니다.

이것이 HoverBot의 기존 기능과 어떻게 연결되는가

HoverBot은 이미 에이전트 레이어를 가치 있게 만드는 내부 구성 요소들을 갖추고 있습니다.

• 파일, 텍스트 및 URL에서 구축된 RAG 지식 기반을 사용하여 답변할 수 있습니다.
• 분류를 통해 허용되지 않거나 범위를 벗어난 요청을 차단하는 가드레일(guardrails)을 적용할 수 있습니다.
• 모델 호출 주변의 PII(개인 식별 정보)를 감지하고 마스킹할 수 있습니다.
• 감사 로그, 세션 모니터링 및 분석을 유지할 수 있습니다.
• 그리고 리드 생성 및 제품 지원과 같은 모듈식 스킬로 멀티테넌트 구성을 지원합니다.

에이전트 레이어는 이러한 구성 요소들을 대체하는 것이 아닙니다. 에이전트가 안전하게 사용할 수 있는 방식으로 접근 가능하게 만듭니다.

용어를 제거하고 실질적인 변화를 말하자면 이렇습니다: 위젯은 단순히 UI가 아니라, “내가 책임지는 것은 이것이고, 내가 할 수 있는 것은 이것이며, 그리고 이것을 하는 안전한 방법이 여기 있다”고 말하는 작은 계약서가 됩니다.

팀들이 과소평가하는 부분: 봇 간 조정(bot to bot coordination)

많은 사이트에서 사용자는 곧 두 개의 어시스턴트를 보게 될 것입니다. 브라우저의 에이전트 패널과 사이트의 채팅 위젯입니다. 만약 둘 다 주된 코파일럿처럼 작동한다면, 경험은 산만해집니다. 사용자는 중복된 답변, 상충되는 제안, 그리고 주의를 끌기 위해 싸우는 공격적인 팝업을 받게 됩니다.

에이전트가 준비된 위젯은 에이전트가 존재할 때 동작을 전환할 수 있어야 합니다. 실제로 이는 UI에서 대화하는 느낌(chatty)이 줄어들고 인터페이스에서 더 협력적으로 작동한다는 것을 의미합니다. 여전히 인간 사용자에게 서비스를 제공할 수는 있지만, 에이전트가 호출할 수 있는 안정적인 엔드포인트로도 기능해야 합니다.

이는 브라우저에 관계를 넘겨주는 것이 아닙니다. 충돌을 방지하고 실행 제어권을 자신 측에 유지하는 것에 관한 것입니다.

에이전트가 읽기 쉬운 힌트, 숨겨진 메타데이터는 아님

많은 팀들이 에이전트에게 추가 컨텍스트를 전달할 방법을 원하기 때문에 숨겨진 메타데이터에 대해 이야기합니다. 더 안전한 접근 방식은 다음과 같습니다. 노출해도 안전한, 에이전트가 읽을 수 있는 힌트를 게시하고, 모든 것은 인증 및 정책 검사 뒤에서 권한(privileged)으로 유지하는 것입니다.

기능 설명에는 절대 비밀 정보가 포함되어서는 안 됩니다. 어떤 동작이 존재하는지, 그리고 어떤 확인 규칙이 적용되는지만 말할 수 있습니다. 내부 API 키, 비공개 URL 또는 크롤러가 보고 싶어 하지 않을 모든 것이 포함되어서는 안 됩니다.

진정한 힘은 발견 이후에 발생하는 것에서 나옵니다. 즉, 짧게 살아있는 토큰과 테넌트 수준의 권한 하에 서버에서 동작이 실행되는 것입니다. 바로 그곳에서 개인 정보 보호와 보안이 강제됩니다.

작고 유지 가능한 실질적인 배포 전략

가장 빠른 경로는 하나의 테넌트(tenant)와 좁은 범위로 시작하여 점차 확장하는 것입니다.

읽기 워크플로우(read workflow) 하나와 수행 워크플로우(do workflow) 하나를 선택하세요. 읽기 워크플로우는 인용문이 포함된 정책 답변과 같은 것입니다. 수행 워크플로우는 티켓 생성이나 콜백 예약처럼 확인(confirmation)이 필요한 것이 예입니다. 이 두 가지가 안정화되면, 사용자의 시간을 절약해 줄 수 있는 추가 동작(예: 이용 가능 여부 확인 또는 주문 상태 조회)을 제품에 따라 하나 더 추가하세요.

핵심은 자제력입니다. 에이전트 레이어는 작고, 명시적이며, API 계약처럼 유지될 때 가장 잘 작동합니다. 만약 40개의 동작을 게시한다면, 40개의 동작을 유지해야 합니다. 다섯 개를 게시한다면, 실제로 작동하는 다섯 개를 배포할 가능성이 높습니다.

요점 정리

에이전트 기반 브라우저는 웹을 더욱 작업 중심적으로 느끼게 만들 것입니다. 이러한 변화는 에이전트에게 신뢰할 수 있는 인터페이스를 제공하는 사이트를 보상하고, 에이전트가 DOM에서 추측하도록 강요하는 사이트는 처벌할 것입니다.

챗 위젯의 경우, 해결책은 재설계가 아닙니다. 그것은 얇은 에이전트 레이어입니다: 기능을 발견 가능하게 만들고(discoverable), 구조화된 출력을 반환하며, 가드레일(guardrails), PII 보호 및 감사(auditing)를 거친 통제된 경로를 통해 액션을 실행해야 합니다.

다시 말해, 여러분의 위젯을 사이트가 제공할 수 있는 가장 안전한 에이전트 API로 취급하십시오.

출처 (Sources)

• OWASP AI Agent Security Cheat Sheet
• OWASP Prompt Injection Prevention Cheat Sheet
• OpenAPI Specification