당신의 소프트웨어에 두 번째 사용자가 생겼습니다. 그리고 그 사용자는 인간이 아닙니다.

우리는 수년 동안 사람들을 위해 웹사이트를 설계해 왔습니다. 이제 AI 에이전트들까지 그것을 사용하기 시작했습니다.

최근 저는 한 AI 에이전트가 웹사이트를 탐색하는 것을 지켜봤는데, 마치 컴퓨터를 처음 사용하는 사람 같아 의심스러울 정도였습니다.

잘못된 메뉴를 클릭하고, 뒤로 가기를 누르고, 다른 버튼을 시도하며, 무언가 로딩되기를 기다렸고, 때로는 자신이 완전히 오해한 것에 대해 극도로 자신감 있는 모습을 보이기도 했습니다.

차이점은 무엇일까요? 이 특정 사용자는 또한 Python 코드를 작성하고, 문서를 읽고, 자신의 실수가 사실 합리적이었다는 매우 설득력 있는 설명을 생성할 수 있다는 것입니다.

우리는 오랫동안 소프트웨어를 인간이 사용하기 더 쉽게 만드는 데 시간을 쏟아왔습니다. 이제 우리는 완전히 다른 종류의 사용자를 방정식에 도입하고 있습니다.

그리고 저는 우리의 애플리케이션들이 그것을 받아들일 준비가 되었다고 확신하지 못합니다.

우리는 인간의 가정에 맞춰 웹을 구축했습니다

꽤 평범한 결제 페이지를 생각해 보세요.

오른쪽 상단 모서리에는 쇼핑 카트 아이콘이 있고, 확장 가능한 섹션 뒤에 숨겨진 할인 입력란과 “계속하기”라고 적힌 밝은 버튼이 있습니다.

인간에게는 익숙합니다. 우리는 수백 개의 웹사이트에서 거의 동일한 인터페이스를 봤기 때문에, 별다른 생각 없이 무엇을 해야 할지 알고 있습니다.

하지만 AI 에이전트는 페이지를 반드시 같은 방식으로 경험하지 못합니다.

애플리케이션과 상호작용하는 방식에 따라, 그것은 스크린샷, 접근성 트리(accessibility tree), DOM(Document Object Model) 또는 사용 가능한 컨트롤의 구조화된 표현을 볼 수 있습니다.

아름답게 디자인된 버튼이라도 에이전트가 그것이 무엇을 하는지 신뢰할 수 있게 식별하지 못한다면 별로 유용하지 않습니다.

그리고 인간에게는 명백해 보이는 인터페이스라도, 사용하는 주체가 인간의 직관을 가지고 있지 않다면 놀라울 정도로 혼란스러워질 수 있습니다.

이것은 흥미로운 가능성을 만듭니다. 즉, 웹사이트가 사람들에게는 훌륭한 UX를 가졌지만 에이전트에게는 형편없는 UX를 가질 수 있다는 것입니다.

같은 결제 페이지. 두 가지 매우 다른 이해 방식.

에이전트가 우리처럼 좌절하지 않는다는 점이 이상합니다

인간은 결제 버튼을 찾지 못하면 몇 가지 시도를 하다가 떠날 수 있습니다.

하지만 에이전트는 계속 나아갈 수 있습니다.

행동을 재시도하거나, 이전 페이지로 이동하거나, 다른 페이지를 열거나, 대체 경로를 시도할 수 있습니다. 이는 첫 번째 시도가 실패했을 때 유용하지만, 새로운 문제들을 야기합니다.

에이전트가 주문을 제출하려고 하는 상황을 상상해 보세요.

'제출(Submit)' 버튼을 클릭합니다. 페이지가 응답하는 데 몇 초가 걸립니다. 에이전트는 행동이 성공했는지 확신할 수 없으므로 다시 클릭합니다.

만약 첫 번째 클릭이 실제로 작동했다는 것을 상상해 보세요.

축하드립니다. 매우 끈기 있는 새로운 고객이 냉장고 두 대를 구매했습니다.

이는 단순히 UI 디자인 문제가 아닙니다. 신뢰성(reliability) 문제입니다.

에이전트가 애플리케이션 내부에서 실제 행동을 수행하려면, 해당 애플리케이션은 결과를 모호하지 않게 만들어야 합니다. 버튼에는 의미 있는 레이블이 필요하고, 작업에는 명확한 성공 상태가 필요합니다. 두 번 발생해서는 안 되는 행동은 중복 실행에 대한 보호 장치가 필요합니다.

에이전트에게 좋은 인터페이스란 반드시 더 매력적인 것을 의미하지 않습니다.

그것은 더 이해하기 쉽고 예측 가능한 것을 의미합니다.

모니터링 대시보드에 절반의 이야기가 빠져 있을 수 있습니다

여기서 엔지니어링 관점에서 흥미로운 부분이 발생합니다.

만약 에이전트가 결제를 세 번 시도한다고 가정해 봅시다. 첫 번째 요청은 성공했지만, 인터페이스는 이를 명확하게 확인해주지 않았습니다. 에이전트는 두 번 재시도하고 결국 포기합니다.

이제 모니터링 대시보드를 살펴보는 것을 상상해 보세요.

서버는 200 OK를 반환했습니다.

결제 엔드포인트는 성공적으로 응답했습니다.

명백한 예외(exception)는 발생하지 않았습니다.

모든 것이 정상으로 보입니다.

하지만 에이전트는 냉장고를 구매했는지 전혀 알지 못합니다.

그리고 요청을 한 사람 역시 그렇지 않습니다.

이것이 제가 실제 사용자 세션에 흥미를 느끼는 이유 중 하나입니다. 성공적인 API 응답은 요청이 성공했음을 알려줍니다. 하지만 사용자가 인간이든 아니든, 무엇이 일어났는지 이해했는지 여부는 반드시 알려주지 않습니다.

HeronSignal에서는 기술적 신호와 실제로 발생한 세션을 연결하는 데 중점을 둡니다. 오류(error), 요청(request), 또는 성능 문제(performance issue)를 고립된 사건으로 취급하는 대신, 주변의 사용자 여정(user journey)을 검사할 수 있습니다.

이것은 문제가 화려한 백엔드 실패가 아니라 혼란스러운 상호작용 순서일 때 특히 유용해집니다.

요청은 이야기의 일부일 뿐입니다. 주변 세션이 맥락(context)을 제공합니다.

HeronSignal은 현재 AI 에이전트 탐지 도구로 제시되고 있지는 않습니다. 그것은 별개의 과제입니다. 그러나 애플리케이션을 탐색하는 주체가 인간이 아닐 수도 있을 때, 세션 동안 무슨 일이 일어났는지 검사할 수 있는 능력은 점점 더 흥미로워집니다.

우리는 '세션'의 의미를 재고해야 할지도 모릅니다

웹사이트 분석을 살펴볼 때, 우리는 상호작용 뒤에 사람이 있다고 가정하는 경향이 있습니다.

누군가가 가격 책정 페이지(pricing page)를 방문하고, 플랜을 선택하며, 결제(checkout) 페이지를 열고, 결제 정보를 입력한 다음, 구매를 완료합니다.

하지만 만약 AI 에이전트가 누군가를 대신하여 그러한 행동을 수행했다면 어떨까요?

세션은 처음에는 완벽하게 평범해 보일 수 있습니다. 단지 그 에이전트가 인터페이스를 다르게 이동하거나, 더 공격적으로 행동을 재시도하거나, 인간이라면 다르게 해석할 정보를 기반으로 결정을 내릴 수 있다는 점만 제외하고요.

그리고 갑자기, 익숙했던 몇 가지 분석 질문들이 더 어려워집니다.

그것이 제품을 탐색하는 고객의 행동이었는지, 아니면 플랜을 비교하는 에이전트의 행동이었을까요? 사용자가 결제를 포기한 것일까요, 아니면 그들의 에이전트가 모호한 상태를 만나 멈춘 것일까요? 저 특이한 탐색 패턴은 의심스러운 것일까요, 아니면 자동화된 어시스턴트가 합법적인 작업을 완료하려 노력하는 것일까요?

세션 리플레이(session replay)로는 이러한 질문들에 자동으로 답할 수 없습니다. 하지만 세션에 대한 가시성이 없다면, 이를 조사하는 것이 훨씬 어려워집니다.

HeronSignal을 작업하면서 저는 개별적인 기술적 이벤트들 사이에 얼마나 많은 정보가 존재하는지 깨닫게 되었습니다. 느린 요청, 반복되는 클릭, 그리고 사용자가 떠나는 것을 볼 수 있습니다. 각 이벤트는 무언가를 말해줍니다. 이들이 함께 모이면 훨씬 더 유용한 이야기를 들려줍니다.

그리고 AI 에이전트(AI agents)가 등장하면서, 그 이야기들은 상당히 기묘해질 수도 있습니다.

다음 접근성 문제는 기계 가독성일 수 있다

여기 흥미로운 연결고리가 있습니다.

인터페이스를 보조 기술(assistive technologies)에 더 쉽게 만드는 많은 것들이 브라우저 에이전트가 이해하기에도 더 쉽게 만듭니다.

시맨틱 HTML(Semantic HTML), 적절하게 레이블링된 입력 필드, 설명적인 버튼, 예측 가능한 탐색, 그리고 명확한 상태 메시지 모두 소프트웨어가 시각적 외관을 넘어 그 의미를 전달하는 데 도움을 줍니다.
학습하기: Medium의 가치

이 두 개의 버튼을 고려해 보세요:

여기를 클릭(Click here)

그리고

구매 확정(Confirm purchase)

인간은 주변 디자인을 통해 '여기를 클릭'이 무엇을 의미하는지 종종 추론할 수 있습니다.

하지만 에이전트는 훨씬 더 많은 맥락이 필요할 수 있습니다.

이는 접근성(accessibility)과 에이전트 사용성(agent usability)이 동일하다는 것을 의미하지는 않습니다. 그렇지 않습니다. 하지만 우리가 선택적인 다듬기 작업으로 여겼던 일부 엔지니어링 관행들이 훨씬 더 중요해질 수도 있다는 것을 의미합니다.

그리고 여기에는 약간 재미있는 점이 있습니다.

우리는 수년 동안 개발자들에게 시맨틱 HTML을 사용하라고 말했습니다.

이제는 로봇들까지 모두를 설득해야 하는 것 같습니다.
문제는 항상 실패한 요청만은 아닙니다.

여기서 저는 프로덕션 모니터링(production monitoring)이 사용자 행동과 더 연결되어야 한다고 생각합니다.

두 개의 결제 세션을 상상해 보세요.

첫 번째 경우, 누군가 '제출(Submit)'을 클릭하고 확인 메시지를 받은 뒤 떠납니다.

두 번째 경우, 에이전트(agent)가 '제출(Submit)'을 클릭하고 기다리거나, 재시도하거나, 이전 페이지로 이동한 다음 다시 제출합니다.

두 세션 모두 성공적인 HTTP 응답을 포함할 수 있습니다.

하지만 이 둘은 전혀 다른 경험입니다.

전통적인 오류 대시보드는 두 세션 중 어느 것도 특별히 흥미롭다고 여기지 않을 수 있습니다. 하지만 특히 애플리케이션이 중복 주문을 생성했거나 사용자에게 결과에 대해 불확실함을 남긴 경우, 두 번째 세션은 조사가 필요합니다.

HeronSignal은 이미 세션(sessions), 요청(requests), 오류(errors), 성능 신호(performance signals), 그리고 사용자 여정(user journeys)을 통합하여 제공합니다. 이를 통해 개발자는 단절된 로그에서 재구성하려고 노력하는 대신 이러한 종류의 순서들을 조사할 수 있습니다.

그리고 실제 프로덕션 문제와 관련된 경우, HeronAgent는 기술적 원인을 조사하고 인간 검토를 위한 제안 코드 수정(proposed code fix)을 준비하는 데 도움을 줄 수 있습니다.

이는 사용자가 사람인지 자동화된 어시스턴트인지에 관계없이 오늘날 유용합니다.

하지만 더 큰 질문은 이러한 비정상적인 상호작용 패턴이 더욱 흔해짐에 따라 무슨 일이 발생하는가 하는 것입니다.

요청 자체를 이해하는 것만큼 요청들 사이에서 무슨 일이 일어났는지 이해하는 것도 중요할 수 있습니다.

하나의 동작, 세 가지 매우 다른 결과

우리가 사용하던 냉장고로 다시 돌아가 봅시다.

에이전트가 '제출(Submit)'을 클릭하고, 세 가지 중 하나가 발생합니다.

애플리케이션이 성공을 확인합니다. 좋습니다. 에이전트는 멈출 수 있습니다.

애플리케이션이 실패를 확인합니다. 이것도 유용합니다. 에이전트는 재시도할지 아니면 도움을 요청할지 결정할 수 있습니다.

하지만 세 번째 가능성이 흥미로운 경우입니다: 애플리케이션이 명확한 결과를 제공하지 않습니다.

요청이 서버에서 처리되는 동안 시간 초과되었을 수도 있습니다. 확인 UI가 업데이트하는 데 실패했을 수도 있습니다. 주문은 성공했지만 에이전트가 성공 메시지를 인식하지 못했을 수도 있습니다.

이제 에이전트는 불완전한 정보로 결정을 내려야 합니다.

그리고 바로 그 지점에서, 겉보기에는 무해해 보이는 인터페이스 문제가 비용이 많이 들게 될 수 있습니다.

가장 위험한 결과는 항상 실패인 것은 아닙니다. 때로는 불확실성입니다.

개발자들에게 이것은 명확한 성공 상태(clear success states), 반복 가능한 작업(idempotent operations), 그리고 신뢰할 수 있는 피드백이 사소한 구현 세부 사항이 아님을 상기시켜 줍니다. 이들이 자동화된 워크플로우가 안전하게 완료될지 여부를 결정할 수 있습니다.

운영 환경용 도구(production tools)에게는, 단순히 격리된 오류 횟수만 보는 것을 넘어 문제 주변의 일련의 행동들을 이해해야 할 또 다른 이유를 제공합니다.

예상치 못한 사용자를 테스트해야 합니다

우리는 이미 브라우저, 화면 크기, 운영 체제 및 네트워크 조건 전반에 걸쳐 애플리케이션을 테스트합니다.

어쩌면 에이전트 기반 워크플로우(agent-driven workflows)도 그 논의에 자리를 차지해야 할지도 모릅니다.

모든 웹사이트가 특별한 AI 모드를 필요로 하기 때문이 아니라, 우리가 사용자 행동에 대해 내리는 가정이 변화하고 있기 때문입니다.

인간은 애니메이션이 끝날 때까지 기다릴 수 있습니다. 에이전트는 클릭 가능한 요소를 감지하는 즉시 작동할 수 있습니다. 인간은 확인 메시지가 주문 성공을 의미한다는 것을 인식할 수 있습니다. 하지만 에이전트는 그 메시지가 인터페이스에 명확하게 표현되지 않았기 때문에 이를 놓칠 수 있습니다.

이러한 차이점들은 이상한 운영 환경 동작(strange production behavior)으로 이어질 수 있습니다.

그리고 이것은 개발과 운영 사이의 관계가 점점 더 중요해지고 있다고 생각하는 이유 중 하나입니다.

우리는 의도했던 인터페이스를 테스트할 수 있습니다. 코드를 검사하고, 풀 리퀘스트(pull request)를 검토하며, 모든 것이 통과하는지 확인할 수 있습니다.

하지만 실제 사용자들이, 그리고 이제 잠재적인 AI 에이전트들이 애플리케이션과 상호작용하기 시작하면, 우리는 실제로 무슨 일이 일어나는지 발견합니다.

그것이 바로 HeronSignal에서 작업하는 소프트웨어의 측면입니다: 프로덕션 동작을 검사하고, 이해하며, 조사하기 쉽게 만드는 것입니다.

때로는 코드가 우리가 지시한 대로 정확히 작동할 때도 있습니다.

하지만 예상치 못한 행동을 하는 것은 사용자일 수 있습니다.