Aside 여섯 가지 활용법과 에이전트 친화적 웹을 둘러싼 한마디

16일 밤 11시 32분, 한 참가자가 브라우저 에이전트 Aside의 용도를 두고 질문을 올렸다.

aside가 저는 playwright?였나 이놈 대신 실제 개발 바이브코딩할때 참고하는 브라우저 용도로 쓰는데 ai한테 aside이용해서 프론트 개발하라하는데 이렇게 쓰는거맞나요?

Playwright(웹 자동화 테스트 프레임워크)를 대신해 프런트엔드 개발 참고용으로 Aside를 쓰고 있는데, 이 방식이 맞는지 확인하는 질문이었다.

프레임워크와 브라우저, 여섯 가지 활용법

2분 뒤 다른 참가자가 두 도구의 근본적인 차이부터 짚었다.

플레이라이트는 브라우저를 제어하는 프에임워크고 aside는 브라우저 그 잡채 에요

Playwright는 브라우저를 제어하는 프레임워크일 뿐이고, Aside는 그 자체로 브라우저라는 설명이었다. 이 참가자는 곧이어 Aside를 실제로 잘 쓰는 여섯 가지 방식을 한 번에 정리해줬다.

어사이드 잘쓰는 방식 1. 사이트에 바로가는게 아니라 챗으로 대상 사이트에서 할일을 말하는 것으로 시작 2. 로그인 훅 저장으로 모든 내 사이트 스스로 입출 가능 3. 자동화 루틴 적용 가능 4. CLI MCP써서 코덱스 클코로 호출가능 5. 웹에사 돌아가는 영상분석 6. 로컬파일 로컬MCP CLI와 연동 가능

사이트 주소를 직접 입력하는 대신 채팅으로 할 일을 지시하는 것부터, 로그인 정보를 저장해 여러 사이트를 자동으로 드나들게 하는 것, 자동화 루틴 적용, CLI·MCP를 통한 코덱스·클로드 코드 연동, 화면에서 돌아가는 영상 분석, 로컬 파일·로컬 MCP·CLI 연동까지 — 브라우저 하나를 여섯 갈래로 활용하는 방법이 한 번에 정리된 셈이다.

결국은 SEO로 충분하다는 반론

다음 날 오후 1시 9분, 다른 참가자는 반대 방향에서 문제를 제기했다.

웹페이지를 Agent가 잘 읽을 수 있도록 readable 하게 만들어야겠다는 생각이 드네용.

에이전트가 브라우저를 더 잘 쓰게 만드는 것뿐 아니라, 웹페이지 쪽에서도 에이전트가 읽기 쉽게 구조를 갖춰야 한다는 제안이었다. 1분 뒤 다른 참가자가 답했다.

요즘은 그냥 seo 적합하게 구성하라고 하면 되실겁니다

에이전트 친화적인 웹 설계를 별도로 고민할 필요 없이, 기존의 검색 엔진 최적화(SEO) 기준을 잘 지키면 그것으로 충분하다는 반응이었다.

도구 쪽 활용법에서 웹 쪽 구조로

이 화두는 Aside라는 도구를 브라우저 자동화 관점에서 어떻게 활용할지 정리하는 데서 시작해, 그 반대편에 있는 웹페이지 자체를 에이전트가 읽기 쉽게 만들어야 하는지로 자연스럽게 옮겨갔다. 에이전트가 브라우저를 다루는 기술이 여섯 가지나 정리될 만큼 다양해진 지금, 그 에이전트를 맞이하는 웹 쪽의 설계도 함께 논의 대상에 오른 것으로 보인다. SEO 기준으로 충분하다는 반론은, 에이전트 친화적 웹이라는 새로운 개념을 굳이 새로 만들지 않아도 기존 웹 표준 안에서 상당 부분 해결될 수 있다는 시각을 보여준다.

이 화두에는 13명이 참여해 91건의 메시지를 남겼다.