브라우저 에이전트 도입 가이드: 클릭 자동화 전에 설계할 7가지 안전장치

브라우저 에이전트는 웹 페이지를 읽고, 버튼을 누르고, 입력창에 값을 넣고, 화면을 캡처한다. API가 없는 오래된 사내 사이트나 거래처 포털에도 접근할 수 있다는 점이 매력이다. 동시에 문제가 생기는 방식도 기존 자동화와 다르다. 버튼의 위치가 바뀌거나, 팝업이 끼어들거나, 로그인 세션이 만료되면 에이전트는 그럴듯한 다음 행동을 선택할 수 있다.

그래서 브라우저 에이전트의 첫 질문은 "무엇을 클릭할 수 있나?"가 아니다. 어떤 화면을 읽을 수 있고, 어떤 행동 앞에서 멈추며, 잘못된 행동을 어떻게 되돌릴 것인가가 먼저다.

브라우저 자동화와 브라우저 에이전트는 어떻게 다른가?

정해진 페이지에서 같은 버튼을 누르는 일은 일반 브라우저 자동화로 충분하다. 에이전트는 화면의 상태와 목표를 보고 다음 행동을 선택한다. 입력 구조가 매번 달라지거나, 어디에 정보가 있는지 사람이 먼저 탐색해야 하는 업무에서 유연성이 생긴다.

구분	작동 방식	잘 맞는 업무	주의할 점
스크립트 자동화	정해진 선택자와 순서대로 실행한다.	매일 같은 형식의 다운로드·업로드	화면이 조금만 바뀌어도 실패할 수 있다.
워크플로우	이벤트와 규칙을 연결한다.	폼 접수 후 알림·분류·티켓 생성	예외가 늘면 분기 관리가 복잡해진다.
브라우저 에이전트	화면을 관찰하고 목표에 맞는 다음 행동을 선택한다.	사이트마다 다른 자료를 찾고 초안을 만드는 일	잘못된 화면 이해가 잘못된 클릭으로 이어질 수 있다.
AX 운영체계	업무 범위·사람 승인·기록·복구·지표를 함께 관리한다.	반복 웹 업무를 팀 프로세스로 편입하는 일	기술 데모만으로는 운영 가능성을 증명할 수 없다.

브라우저 에이전트가 필요한지부터 확인하자. 공식 API가 있고 데이터 구조가 안정적이면 API 연동이 더 빠르고 감사하기 쉽다. 브라우저 에이전트는 API가 없거나, 여러 사이트의 화면을 사람이 실제로 확인해야 하거나, 기존 시스템을 당장 교체하기 어려운 경우에 선택한다.

첫 파일럿에 적합한 업무는 무엇인가?

첫 업무는 고객에게 바로 노출되는 일이 아니어야 한다. 실패해도 원본 데이터와 운영 자금에 영향을 주지 않고, 사람이 결과를 1~2분 안에 확인할 수 있어야 한다.

• 여러 공급사 포털에서 공개된 배송 상태를 모아 내부 표에 업데이트한다.
• 채용·영업 사이트에서 공개된 공고를 모아 내부 리서치 초안을 만든다.
• 파트너 포털에서 주간 리포트를 내려받고 파일명 규칙을 적용한다.
• 내부 테스트 계정에서 문의 내용을 읽고 답변 초안과 담당자 큐를 만든다.

반대로 결제, 환불 확정, 계약 동의, 고객에게 보내는 법적 약속, 대량 삭제는 첫 파일럿에서 제외한다. 기술적으로 클릭할 수 있다는 것과 조직이 안전하게 맡길 수 있다는 것은 다른 판단이다.

브라우저 에이전트에 붙여야 할 7가지 안전장치

1. 별도 브라우저 프로필과 테스트 계정

개인 브라우저 세션을 그대로 넘기지 않는다. 업무용 테스트 계정, 별도 쿠키 저장소, 최소한의 시드 데이터로 시작한다. 세션이 섞이면 에이전트가 어느 계정으로 행동했는지 추적하기 어렵다.

2. 허용 도메인과 페이지 목록

에이전트가 방문할 수 있는 도메인을 먼저 정한다. 업무에 필요하지 않은 검색 결과나 광고 링크를 따라가게 하지 않는다. 허용 도메인 밖으로 이동하려 하면 멈추고 사람에게 이유를 보여준다.

3. 읽기와 쓰기 권한 분리

첫 단계에서는 화면 읽기와 파일 다운로드만 허용한다. 내부 초안 작성은 두 번째 단계다. 외부 발송·결제·삭제는 별도 권한으로 분리하고 기본값을 차단한다.

4. 민감 필드 마스킹

주민등록번호, 카드번호, 비밀번호, API 키, 고객의 전체 상담 이력은 화면에 보여야 하는지부터 다시 묻는다. 입력이 필요하다면 마스킹된 테스트 값으로 시나리오를 만들고, 실제 값은 사람이 직접 입력하는 게 안전할 수 있다.

5. 되돌릴 수 없는 행동 앞의 사람 승인

에이전트가 장바구니를 만들거나 초안 메일을 작성하는 것은 자동화 후보가 될 수 있다. 결제 버튼, 전송 버튼, 삭제 버튼은 승인 게이트로 만든다. 승인 화면에는 대상·금액·수신자·변경 전후 값을 함께 보여줘야 한다.

6. 화면·행동·결과 로그

최종 결과만 저장하면 원인을 찾기 어렵다. 작업 시작 시각, 방문 도메인, 화면 캡처 또는 주요 DOM 상태, 실행한 행동, 실패 이유, 사람의 승인 여부를 연결한다. 개인정보가 포함된 캡처는 보관 기간과 접근 권한도 정한다.

7. 타임아웃과 복구 경로

팝업이 사라지지 않거나 동일 행동을 반복하면 일정 횟수 뒤 멈춘다. 세션 만료·네트워크 지연·페이지 변경을 서로 다른 실패 유형으로 기록한다. 실패한 작업을 처음부터 다시 실행하지 말고 마지막 확인된 상태부터 사람이 재개할 수 있어야 한다.

예시: 파트너 포털 주간 리포트 수집

업무 목표를 "파트너 포털 5곳에서 지난주 배송 상태를 확인해 내부 리포트 초안을 만든다"로 고정해 보자. 에이전트가 알아서 모든 사이트를 돌아다니게 하지 말고, 다음 계약을 쓴다.

항목	운영 계약
허용 사이트	사전에 등록한 5개 파트너 도메인만
허용 행동	로그인, 리포트 조회, CSV 다운로드, 내부 초안 작성
금지 행동	파트너에게 메시지 발송, 설정 변경, 파일 삭제, 결제
완료 조건	사이트별 기준일·건수·오류·원본 파일 링크가 모두 존재
중단 조건	도메인 변경, 로그인 재인증, 2회 연속 선택자 실패, 민감 필드 노출
사람 승인	내부 보고서 발송과 상태 변경은 담당자 확인 뒤 수행

이렇게 하면 에이전트의 유연성은 살리고, 실수의 범위는 줄일 수 있다. 사이트가 바뀌어도 어떤 조건에서 멈췄는지 알 수 있다.

2주 브라우저 에이전트 AX 파일럿

1. 1~2일차: 사람이 처리한 최근 20건을 기준 데이터로 고정하고 처리시간·오류·재작업을 측정한다.
2. 3~4일차: 테스트 계정에서 화면 읽기와 초안 작성만 실행한다. 외부 쓰기 행동은 차단한다.
3. 5~7일차: 실패한 화면, 팝업, 세션 만료, 빈 데이터 사례를 모아 중단 조건을 추가한다.
4. 8~10일차: 내부 업무 하나에 연결한다. 모든 실행에 로그 ID와 원본 링크를 남긴다.
5. 11~14일차: 사람이 수정하는 시간과 실패 복구시간을 비교해 계속·축소·중단을 결정한다.

성공을 어떻게 측정할까?

지표	측정 방법	좋은 신호
작업 성공률	완료 조건을 모두 충족한 실행 / 전체 실행	단순 완료가 아니라 필수 필드와 원본 링크가 함께 있다.
사람 수정시간	초안 수신부터 승인까지 걸린 시간	처리 건수와 함께 줄어든다.
중단 정확도	실제로 멈춰야 하는 상황을 놓치지 않은 비율	위험 행동을 시도하기 전에 멈춘다.
복구시간	실패부터 수동 재개까지 걸린 시간	로그만 보고 다음 행동을 결정할 수 있다.
단위 비용	성공한 업무 한 건에 사용한 모델·브라우저·사람 비용	수동 처리보다 낮거나, 더 빠른 처리로 가치가 설명된다.

브라우저 에이전트 보안 체크리스트

• 개인 계정과 업무 계정을 분리했는가?
• 허용 도메인과 이동 가능한 페이지를 목록으로 만들었는가?
• 비밀번호·카드·개인정보를 에이전트 화면에 노출하지 않는가?
• 외부 발송·결제·삭제 전에 사람 승인이 필요한가?
• 스크린샷과 행동 로그의 보관 기간·접근자를 정했는가?
• 실패한 세션을 자동으로 반복하지 않고 멈추는가?
• 실제 운영 전에 테스트 계정과 롤백 방법을 확인했는가?

Anthropic과 OpenAI의 컴퓨터 사용 문서도 브라우저 제어 자체보다 실행 환경, 안전한 사용, 사람의 감독을 함께 다룬다. 문서의 기능 목록만 보고 도입하지 말고, 조직의 데이터 경계와 승인선을 먼저 설계해야 한다.

LeanX는 브라우저 에이전트를 바로 구축하기보다 실제 업무 하나를 고르고, 위험 경계와 승인선을 함께 설계한 뒤 2주 파일럿으로 검증합니다. AX 컨설팅에서 업무 후보와 파일럿 범위를 확인해보세요.

공식 참고자료

• Anthropic Computer use tool 문서
• OpenAI Computer use 문서
• Playwright 공식 문서
• NIST AI Risk Management Framework