AI가 거래처 관리자 페이지에 로그인해 주문 정보를 입력하고 저장을 눌렀습니다. 그런데 완료 화면이 뜨기 전에 연결이 끊겼습니다. 자동화 기록에는 실패로 남았지만, 거래처 시스템에는 주문이 이미 생성됐을 수 있습니다.

AI가 처음부터 다시 실행하면 같은 주문이 두 건 들어갑니다. 반대로 재시도하지 않으면 주문이 누락될 수 있습니다. 이때 가장 위험한 상태는 성공이나 실패가 아니라, 실제 결과를 알 수 없는 미확인입니다.

브라우저를 조작할 수 있다는 사실만으로 운영 자동화가 완성되지는 않습니다. 어떤 연결 방식을 쓰든 실행할 대상과 값, 중복 방지, 결과 확인과 사람에게 넘길 조건이 먼저 있어야 합니다.

API가 있으면 화면보다 API를 먼저 봅니다

API는 주문번호, 상품코드, 수량과 같은 값을 구조화해 주고받습니다. 요청이 거절된 이유와 생성된 레코드 ID도 응답으로 받을 수 있습니다. 권한을 조회와 변경으로 나누고, 같은 업무 요청이 다시 들어왔을 때 중복을 막는 키를 설계하기도 쉽습니다.

관리자 화면은 사람에게 상태를 보여주기 위한 인터페이스입니다. 버튼 문구와 위치가 바뀌거나 팝업이 추가돼도 사람은 맥락을 보고 대응하지만, 자동화는 다른 버튼을 누르거나 멈출 수 있습니다. AI가 화면을 다시 해석해 통과하더라도 그것이 원래 의도한 주문인지 확인하는 절차는 별개입니다.

저라면 다음 업무는 API를 우선합니다.

  • 주문·예약·계약 생성과 취소
  • 가격·재고·정산 금액 변경
  • 고객에게 메일·메시지 발송
  • 고객정보와 권한 수정
  • 반복량이 많고 완료 시각을 보장해야 하는 처리

API가 있다고 자동으로 안전해지는 것은 아닙니다. 잘못된 값을 보내면 브라우저보다 더 빠르게 사고가 커질 수 있습니다. 실행 전 규칙 검사와 승인, 중복 방지, 변경 기록은 그대로 필요합니다.

화면이 유일한 연결점이면 브라우저를 씁니다

오래된 ERP나 거래처 포털에는 공식 API가 없을 수 있습니다. 시스템을 수정할 권한도 없다면 브라우저 자동화가 현실적인 연결 방법입니다.

조회, 파일 다운로드, 낮은 빈도의 반복 입력과 한시적인 데이터 이전은 브라우저로 시작할 수 있습니다. 다만 모든 클릭을 AI가 판단하게 두기 전에 고정 규칙으로 처리할 수 있는 구간을 먼저 나눕니다.

  • 화면과 입력 위치가 고정됨: 선택자와 명시적인 순서로 실행
  • 문구나 배치가 달라 맥락 판단이 필요함: AI가 후보 화면과 다음 행동을 제안
  • 주문·가격처럼 영향이 큼: 규칙 검사와 사람 승인 후 실행
  • 추가 인증이나 CAPTCHA가 나타남: 우회하지 않고 사람에게 전환

AI는 비정형 화면을 읽고 예외를 분류하는 데 유용합니다. 위험한 변경의 대상과 값을 최종 확정하는 역할까지 맡길 필요는 없습니다.

로그인 세션은 비밀번호처럼 다룹니다

브라우저 자동화는 로그인 상태를 유지하기 위해 쿠키와 세션 파일을 저장할 수 있습니다. 이 파일을 가진 사람이나 프로그램은 비밀번호를 다시 입력하지 않고도 계정 권한을 행사할 수 있습니다. 인증된 세션 토큰은 로그인에 사용한 인증 수단과 사실상 같은 권한을 가지므로 비밀정보로 보호해야 합니다.[1]

개인 계정의 브라우저 프로필을 복사해 서버에 올리는 방식은 피합니다. 자동화 전용 계정을 만들고 조회·입력·승인 권한을 가능한 범위에서 나눕니다. 세션은 암호화된 비밀 저장소에 두고, 담당자 변경이나 계약 종료 시 즉시 회수할 수 있어야 합니다.

화면 녹화와 스크린샷도 확인해야 합니다. 오류 분석을 위해 남긴 이미지에 고객 이름, 주문 금액과 주소가 그대로 보일 수 있습니다. 보관 기간과 접근자를 정하고 필요한 영역만 가리거나 잘라 저장합니다.

저장 버튼 뒤에는 세 가지 상태가 있습니다

자동화 기록을 성공/실패 두 값으로만 두면 연결이 끊긴 요청을 잘못 처리하게 됩니다.

상태의미다음 행동
성공목적 시스템에서 생성된 결과를 확인함결과 ID와 시각 기록
실패요청이 적용되지 않았음을 확인함원인 수정 후 재시도 가능
미확인요청은 보냈지만 적용 여부를 확인하지 못함실제 상태 조회 또는 사람 대조

응답을 읽기 전에 연결이 끊긴 요청을 자동으로 다시 보내려면, 반복해도 같은 의도된 결과가 나오는 작업이거나 원래 요청이 적용되지 않았음을 확인할 수 있어야 합니다.[2]

화면의 로딩 표시가 사라지지 않았다는 이유만으로 실패라고 판단하지 않습니다. 주문 목록에서 업무 키를 검색하거나, 외부 시스템이 돌려준 주문번호와 처리 시각을 확인합니다. 확인할 방법이 없다면 자동 재시도를 멈추고 미확인 대기함으로 보냅니다.

자동화 실행번호보다 업무 키를 남깁니다

워크플로 8217번은 자동화 도구 안에서만 의미가 있습니다. 실제 중복을 막으려면 같은 주문 의도를 알아볼 수 있는 업무 키가 필요합니다.

예를 들어 고객사, 발주번호와 주문 유형을 조합해 ACME-PO240816-신규 같은 키를 만들 수 있습니다. 다시 실행돼도 같은 키를 사용하고, 저장 전에 목적 시스템에서 이 키가 이미 처리됐는지 확인합니다.

실행 기록에는 다음 내용을 함께 남깁니다.

  • 업무 키와 자동화 실행번호
  • 승인된 대상·값과 승인자
  • 실행한 계정과 시각
  • API 요청 ID 또는 저장 전후 화면 근거
  • 목적 시스템에서 확인한 결과 ID
  • 성공·실패·미확인 판정과 다음 담당자

외부 관리자 페이지에 업무 키를 저장할 칸이 없다면 메모 필드나 주문 참조번호를 사용할 수 있는지 확인합니다. 그것도 불가능하면 사내 작업 원장에 입력값과 결과를 연결하고, 재시도 전에 목적 시스템의 실제 상태를 대조합니다.

브라우저와 API를 한 흐름에서 섞습니다

실무에서는 한 방식만 고집할 이유가 없습니다. 각 구간의 연결 가능성과 위험에 따라 나눕니다.

업무 구간권장 방식
사내 제품·재고 조회API
거래처 포털의 파일·상태 조회브라우저
문서와 화면의 예외 분류제한된 AI 판단
주문 대상·가격·수량 확인업무 규칙과 담당자 승인
주문 변경 실행API 우선, 필요한 구간만 브라우저
실행 결과 확인업무 키와 목적 시스템 상태 대조

이 구조에서는 AI가 관리자 페이지 전체를 자유롭게 돌아다니지 않습니다. 허용된 화면과 행동 안에서 필요한 정보를 찾고, 위험한 실행은 검증된 입력을 받아 한 번만 수행합니다.

브라우저가 실패해도 이미 API로 완료한 단계를 다시 실행하지 않도록 구간별 상태를 남깁니다. 반대로 API 성공 뒤 브라우저 화면이 늦게 갱신됐다고 전체 작업을 실패로 돌리지 않습니다.

선택 기준은 첫 데모보다 복구 비용입니다

브라우저 자동화는 API가 없는 현실을 빠르게 건널 수 있습니다. 그러나 화면 변경, 세션 만료와 응답 지연을 항상 안고 갑니다. API 연동은 처음 협의와 개발이 더 필요할 수 있지만 구조화된 결과와 중복 방지, 권한 분리에 유리합니다.

대표 업무 한 건으로 다음 상황을 먼저 시험합니다.

  • 저장 직후 연결이 끊겼을 때 결과를 찾을 수 있는가
  • 같은 업무 키로 다시 실행해도 중복이 생기지 않는가
  • 화면과 버튼 문구가 바뀌면 안전하게 멈추는가
  • 세션이 만료되면 다른 계정이나 우회 경로로 넘어가지 않는가
  • 잘못된 주문을 취소하고 원래 상태로 복구할 수 있는가

사람과 AI의 역할과 실패 시 안전한 동작은 문서로 남겨야 합니다.[3] 성공률만 비교하기보다 실패를 발견해 정상 상태로 돌리는 시간과 사람이 대조해야 할 건수를 함께 봅니다.

저는 브라우저 자동화를 회사의 핵심 거래가 모두 지나는 중앙 통로로 만들지 않습니다. API가 없는 구간을 연결하는 다리로 사용하고, 반복량과 책임이 커지는 지점부터 구조화된 API와 명시적인 업무 규칙으로 옮깁니다.

관리자 페이지를 클릭하는 장면은 데모의 시작일 뿐입니다. 운영 가능한 자동화는 클릭 뒤의 결과를 확인하고, 모르면 멈추며, 다시 실행해도 같은 업무를 두 번 만들지 않아야 합니다.

출처