AI 활용기: 브라우저 자동화가 사람의 탭을 건드릴 뻔했다

먼저 답하면

오늘 AI 자동화 운영 규칙을 고치며 가장 먼저 잠근 것은 어느 창이 이 작업의 것인가였다. 여러 작업과 사람이 같은 Chrome을 쓰는 환경에서, 위치로 창을 가리키는 명령은 사람이 열어둔 메일 작성 탭을 건드릴 뻔했다. 새 창을 만들고 식별자를 기록한 뒤 그 창에만 URL 변경과 탭 닫기 명령을 보내도록 계약을 바꿨다.

실제 겪은 일

브라우저를 쓰는 공장 작업이 늘어나면서 사람의 Chrome과 자동화가 같은 시간에 열려 있었다. 9월 30일 운영 규칙 수정 기록에는 자동화가 사람의 메일 작성 탭 URL을 덮어쓸 뻔한 사례가 남아 있다. 실제 메일 내용이 사라졌다고 확인된 사건은 아니다. 주소를 바꾸기 전에 위험을 발견했고, 작업 지시를 수정했다.

바뀐 절차는 간단하다. 작업이 시작할 때 전용 Chrome 창을 새로 만들고 그 창의 식별자를 적어둔다. 페이지 이동, 탭 열기·닫기, 종료 시 창 닫기는 모두 그 식별자를 대상으로 한다. 화면 좌표를 눌러야 할 때는 Chrome을 앞으로 가져온 뒤 화면을 캡처해 대상이 맞는지 확인한다. 다른 작업이 위에 창을 띄운 순간에는 같은 좌표가 전혀 다른 버튼을 가리킬 수 있기 때문이다.

온라인에도 있는 같은 원리

AppleScript 언어 가이드는 객체의 순서가 추가·삭제 과정에서 바뀔 수 있으므로 ID로 대상을 참조하는 방식을 설명한다. 이번 사고 위험을 일반화하면, ‘첫 번째 창’ 같은 순서 대신 작업이 확보한 창의 식별자를 쓰는 문제다.

Selenium의 창·탭 문서도 창 핸들을 저장하고 새 창으로 전환한 뒤, 작업이 끝나면 원래 핸들로 돌아가는 흐름을 보여준다. 같은 브라우저의 여러 창을 다룰 때 현재 보이는 창과 실제 명령 대상이 일치하는지 명시적으로 관리한다는 점에서 비슷하다.

Playwright의 브라우저 컨텍스트 문서는 더 강한 격리를 제공한다. 테스트마다 쿠키·저장소가 분리된 컨텍스트를 만들 수 있다. 로그인 세션을 공유해야 하는 운영 작업에 이 방식을 그대로 옮길 수 있다는 뜻은 아니다. 다만 작업마다 소유한 페이지와 상태를 분리해야 한다는 원칙은 같다.

적용할 때 남는 조건

창 식별자를 저장해도 좌표 클릭은 포커스가 바뀌면 빗나갈 수 있다. 그래서 클릭 직전 화면 확인이 별도 조건이다. 반대로 화면을 확인하더라도 URL 변경 명령이 다른 창을 가리키면 사고가 난다. 두 확인은 서로 대신할 수 없다.

이번 기록은 운영 지시를 바꾼 사실과 사고 직전의 위험을 보여준다. 실제로 모든 브라우저 작업이 이 규칙을 장기간 지켰는지, 사고율이 얼마나 줄었는지는 아직 측정하지 않았다. 자동화가 사람과 같은 브라우저를 쓴다면 우선 작업별 창 소유권을 기록하고, 실행 로그에 조작 대상과 직전 화면 확인 결과를 남기는 것부터 시작할 수 있다.