브라우저를 직접 조작하는 AI 에이전트를 써서 서버 관리 화면의 반복 작업을 맡겨 봤다. 스택 재배포, 인증 설정 추가, DNS 레코드 등록 같은 일이다. 화면을 보고 클릭하는 방식은 데모에서는 근사하지만 실제 관리 콘솔에서는 자주 미끄러졌다. 결국 자리 잡은 방식과 그 한계를 정리한다.
화면 클릭이 깨지는 곳
- 예고 없는 팝업. 유료 기능 안내, 새 버전 소개, 설문 같은 것이 버튼 위를 덮는다. 에이전트는 방금 본 화면의 좌표를 누르는데 그 자리에 다른 것이 와 있다.
- 여러 단계 마법사. 단계마다 입력 요소가 동적으로 바뀌는 설정 마법사에서 자동 입력이 값을 놓치거나 검증 오류를 냈다.
- 레이아웃 이동. 값을 입력하자 안내 문구가 두 줄이 되면서 저장 버튼이 20픽셀 내려간다. 이전 화면 기준으로 누른 클릭은 빗나간다.
- 맞춤 드롭다운. 표준 입력 요소가 아니라 직접 그린 목록은 키보드 조작이 한 번은 되고 한 번은 안 됐다.
더 나았던 방식: 로그인된 세션으로 API 호출
대부분의 관리 콘솔은 화면이 자기 REST API 를 부르는 구조다. 사람이 이미 로그인해 둔 브라우저 탭 안에서 그 API 를 직접 부르면, 화면 배치와 무관하게 같은 일을 할 수 있다.
const res = await fetch('/api/stacks/42/redeploy', {
method: 'PUT',
credentials: 'include', // 로그인 쿠키 사용
headers: { 'Content-Type': 'application/json', 'X-CSRF-Token': csrf },
body: JSON.stringify({ pullImage: false }),
});붙이면서 알게 된 것들:
- CSRF 토큰이 필요한 경우가 많다. 어떤 콘솔은 상태 조회 응답의 헤더에 토큰을 실어 주고, 어떤 것은 쿠키 값을 그대로 헤더에 넣으라고 한다. 브라우저 개발자 도구의 네트워크 탭에서 화면이 보내는 요청을 한 번 보면 알 수 있다.
- 인증 방식은 버전에 따라 바뀐다. 저장소에 토큰을 두던 콘솔이 업데이트 뒤 쿠키 세션으로 바뀌어, 잘 돌던 스크립트가 어느 날 인증 오류를 냈다.
- API 로 만든 객체는 화면으로 만든 것과 다를 수 있다. 화면은 기본값을 채워 주지만 API 는 보낸 것만 저장한다. 필수처럼 보이지 않던 필드가 비어 있어 기능이 동작하지 않은 적이 있다. 화면으로 만든 정상 객체를 조회해서 비교하는 것이 가장 빨랐다.
이 방식이 막히는 곳
모든 서비스에서 통하지는 않는다. 어떤 대형 서비스의 대시보드는 세션으로 조회 요청은 받아 주지만 변경 요청은 보안 계층이 차단했다. 헤더를 맞춰도 마찬가지였다. 이런 곳은 화면 클릭으로 돌아가되, 한 동작마다 화면을 다시 확인하며 천천히 진행하는 수밖에 없다. 공식 API 토큰을 발급받을 수 있다면 그것이 정석이다.
사람이 해야 하는 일
- 로그인. 비밀번호와 인증 코드는 사람이 직접 넣는다. 에이전트는 이미 열린 세션만 쓴다. 세션이 만료되면 사람에게 다시 로그인해 달라고 요청하게 한다.
- 약관 동의와 결제. 버튼 하나로 계약이 성립하는 단계는 에이전트가 화면을 준비해 두고 사람이 누른다.
- 되돌릴 수 없는 삭제. 실행 전에 대상과 영향을 사람이 확인한다.
- 비밀 값 발급. 생성 직후 한 번만 보여 주는 키는 사람이 내려받아 정해진 위치에 둔다. 대화 내용에 값이 남지 않게 한다.
기록해 두면 다음이 빨라진다
어느 콘솔에서 어떤 방식이 통했는지를 프로젝트 메모에 남긴다. "이 콘솔은 화면 자동화가 팝업 때문에 깨지니 세션 API 로", "여기는 변경 요청이 막히니 화면으로". 이 한 줄이 없으면 다음 대화의 에이전트는 같은 시행착오를 처음부터 다시 한다.
정리
브라우저 에이전트의 강점은 "사람의 로그인 상태를 빌려 쓸 수 있다"는 것이지 "사람처럼 클릭한다"가 아니었다. 클릭은 최후의 수단으로 두고, 가능하면 화면 뒤의 API 를 부르게 하는 편이 빠르고 정확했다.
댓글 없음:
댓글 쓰기