지금까지 프론트엔드 설계의 첫 번째 질문은 항상 "사람이 이 화면을 어떻게 읽는가"였다. 클릭 동선, 인지 부하, 폼 입력의 마찰—모두 인간 사용자를 중심에 놓은 판단이었다. 그런데 세 가지 사례가 거의 동시에 등장하면서 이 전제를 흔들고 있다. AI 에이전트가 브라우저를 열고, API를 호출하고, 폼을 채우는 주체가 된 지금, 설계의 첫 질문도 달라져야 한다.
두나무가 최근 출시한 '업비트 스킬(Upbit Skills)'은 이 변화를 가장 직접적으로 보여주는 사례다. Claude Code, Cursor, OpenAI Codex 같은 AI 코딩 에이전트 환경에서 업비트 API를 자연어로 다룰 수 있도록 구조화된 참조 지침 묶음이다. "KRW-BTC 현재가 조회해줘"라는 자연어 요청이 적절한 CLI 명령으로 변환되는 구조인데, 핵심은 이 지침이 일회성 프롬프트가 아니라는 점이다. 반복 업무를 수행할 때 에이전트가 참조하는 절차·규칙·예시의 묶음, 즉 에이전트용 업무 매뉴얼에 가깝다. 실제로 업비트의 API 활용 이용자는 2023년 대비 2025년 76% 증가했는데, 이 증가분의 상당 부분이 AI 에이전트를 끼운 '바이브 트레이딩' 수요와 맞닿아 있다.
한편 dev.to에 공개된 Agentyc는 조금 다른 층위의 문제를 건드린다. MCP(Model Context Protocol) 기반 브라우저 런타임인 이 도구는 AI 에이전트에게 실제 브라우저를 쥐여주되, 그 동작을 결정론적으로 만드는 데 초점을 맞춘다. 개발자 Jasss Kalkat이 "데모에서는 인상적이지만 실제 업무에서는 신뢰하기 어렵다"고 진단한 것처럼, 기존 브라우저 자동화 도구들은 실패했을 때 왜 실패했는지 알 수 없는 블랙박스였다. Agentyc는 browser_get_state로 페이지 상태를 안정적인 참조자(e123 같은 stable ref)로 노출하고, 테이블·링크·폼 필드 같은 일반적인 추출 작업에서는 퍼지 해석 대신 명확한 에러를 반환하는 방식을 택했다. "마법보다 신뢰 가능성"을 선택한 트레이드오프다.
그렇다면 이 에이전트들이 내 서비스에 접속할 때, 백엔드나 보안 레이어는 어떻게 반응해야 할까. Nyasa의 접근이 흥미로운 이유가 여기 있다. 이 브라우저 SDK는 세션을 Human, AuthorizedAgent, UnauthorizedBot 세 가지로 분류한다. 기존 CAPTCHA나 핑거프린팅이 "봇이냐 아니냐"를 묻는 이분법이었다면, Nyasa는 세 번째 행위자—사용자를 대신해 합법적으로 동작하는 AI 에이전트—를 명시적으로 식별하고 허용하는 구조를 제안한다. 쇼핑 어시스턴트나 핀테크 통합 에이전트가 CAPTCHA에 막히는 것은 정당한 비즈니스를 차단하는 것과 같다는 문제의식이다. window.__nyasaAgentSignature로 서명된 신원을 제출하면 봇 탐지 규칙을 우회하는 AuthorizedAgent로 분류되는 구조는, 에이전트 신원 확인이 프론트엔드 보안 설계의 새로운 레이어가 되고 있음을 시사한다.
세 사례를 함께 놓으면 하나의 구조가 보인다. 에이전트가 API를 자연어로 다루고(업비트 스킬), 브라우저를 결정론적으로 조작하며(Agentyc), 서비스는 그 에이전트를 신원으로 식별한다(Nyasa). 이것은 점진적인 자동화의 확장이 아니라, 인터페이스의 소비 주체가 추가되는 구조적 변화다. 프론트엔드 개발자 입장에서 이 변화는 세 가지 설계 질문으로 번역된다. 첫째, 내 API와 UI가 에이전트에게도 읽히는 구조인가—시맨틱 마크업과 안정적인 엘리먼트 식별자는 이제 접근성(a11y)만의 문제가 아니다. 둘째, 에이전트가 실패했을 때 왜 실패했는지 알 수 있는가—에러 응답의 구조화와 상태 노출 방식이 에이전트 디버깅의 핵심 인프라가 된다. 셋째, 내 서비스는 합법적인 에이전트를 봇으로 막고 있지 않은가—인증과 접근 제어 설계에 에이전트 신원 레이어를 포함할 때가 됐다.
"사람이 이 화면을 어떻게 읽는가"라는 질문이 틀린 것은 아니다. 다만 이제는 그 옆에 "에이전트가 이 인터페이스를 어떻게 다루는가"라는 질문이 나란히 서야 한다. 두 질문에 동시에 잘 답하는 설계가 앞으로의 인터페이스 품질 기준이 될 것이다.