같은 양식의 폼은 첫 1건을 사람이 확인한 뒤 나머지를 맡기면 된다.
7장의 일은 읽기만 하고 쓰는 곳은 내 시트 하나였다. 이번 장은 한 걸음 더 나아가 남의 사이트에 있는 양식을 여러 번 채워 제출하는 일을 다룬다. 예제로 삼는 일은 여러 유통 채널의 판매자 관리 화면에 상품 정보를 같은 양식으로 등록하는 작업이다. 집필 환경에서는 2026년 9월에 세 곳의 판매 채널에서 상품 등록 작업을 실제로 진행했고, 그 과정에서 어디까지 맡기고 어디서 멈춰야 하는지가 분명해졌다. 이 장은 그 기록을 일반화해 정리한 것이다. 사이트 이름과 상품, 실제 값은 밝히지 않는다.
8.1 어떤 폼 제출을 에이전트에게 맡기면 좋을까?
맡기기 좋은 폼은 칸의 구성이 같고 들어갈 값만 건마다 다른 폼이다. 상품 등록, 재고 수정, 기관 신청 양식, 회원 정보 일괄 변경처럼 한 건을 채우는 데 5분에서 10분이 걸리고, 그런 건이 여러 개 쌓여 있는 일이 대표적이다. 사람이 직접 하면 세 번째 건쯤부터 칸을 헷갈리고, 복사해 붙인 값이 앞 건의 값인지 확인하느라 시간이 더 든다. 에이전트는 지루해하지 않고 같은 순서를 반복하지만, 제출은 7장의 시트 기록과 달리 되돌리기 어렵다. 그래서 처음에는 제출 뒤에도 수정이나 취소가 되는 폼, 또는 임시 저장 기능이 있는 폼부터 시작하는 편이 좋다. 임시 저장까지만 맡기고 최종 제출은 사람이 누르는 방식으로 시작하면, 틀려도 제출 전에 고칠 기회가 남는다. 결제가 끼어드는 폼, 메시지나 메일을 바깥으로 보내는 폼은 이 장의 대상이 아니다. 그런 일은 11장과 14장에서 따로 다룬다.
8.2 처음 한 건은 왜 사람이 직접 확인해야 할까?
새 사이트, 새 양식에서의 첫 제출은 사람도 에이전트도 그 사이트가 어떻게 반응하는지 모르는 상태에서 이루어지기 때문이다. 성공하면 어떤 화면이 나오는지, 어느 칸이 저절로 바뀌는지, 어느 버튼이 정말 되돌릴 수 없는 버튼인지를 첫 건에서 배운다. 아래 표는 세 채널에서의 실제 진행 방식을 일반화한 것이다.
| 채널 | 처음 방식 | 확인한 것 | 이후 위임 범위 |
|---|---|---|---|
| 채널 A (처음 쓰는 판매자 사이트) | 에이전트가 모든 값을 입력하고 임시 저장까지만 진행 | 사람이 각 건의 최종 제출 버튼을 직접 눌러 결과 확인 | 이 채널은 끝까지 최종 제출을 사람이 누름 |
| 채널 B (다른 판매자 사이트, 6건) | 에이전트가 1번 건만 채우고 멈춤. 사람이 값을 확인하고 1번을 제출 | 목록에 1번 건이 등록된 상태로 나타나는 것 | “나머지 5건 제출해”로 2~6번의 입력, 제출, 확인을 위임 |
| 채널 C (제출 뒤 수정이 어려운 유통 사이트) | 첫 저장 전에 전체 값 표, 입력된 폼의 위아래 화면 캡처, 원본 문서와의 대조 결과를 먼저 보여 줌 | 표와 캡처가 원본과 일치하는 것 | 사람이 확인한 뒤 저장 클릭 자체를 위임 |
채널 B의 경험이 이 장의 핵심이다. 필요한 안전장치는 “모든 건마다 사람이 확인”이 아니라 “새 사이트, 새 양식의 첫 제출은 사람이 확인”이었다. 1번 건이 목록에 제대로 올라간 것을 본 뒤에는 같은 양식의 나머지 5건을 맡겨도 불안하지 않았고, 실제로 2번부터 6번까지 에이전트가 채우고 제출하고 확인까지 마쳤다. 건마다 승인을 요구하면 사람은 내용을 보지 않고 승인만 누르기 쉽다. 채널 C에서는 제출 뒤 고치기 어렵다는 사정 때문에 첫 저장 전에 값 표와 캡처, 원본 대조를 한꺼번에 보여 주었고, 그것을 본 사람이 클릭까지 맡겼다. 이 방식은 한 번 관찰한 사례일 뿐 규칙은 아니지만, 무엇을 보여 주면 맡기기 편해지는지 알려 주는 좋은 예다. 사람은 칸마다 승인하기보다 검증된 값을 표 하나로 한 번에 보고 한 번 승인하는 방식을 선호했다.
8.3 입력 원장은 어떻게 준비할까?
입력 원장은 폼에 넣을 값을 건별로 한 줄씩 적은 표다. 에이전트가 원본 문서를 그때그때 읽어 값을 고르게 하지 말고, 먼저 원장을 만들어 사람이 한 번 확인한 뒤 그 원장만 보고 입력하게 한다. 원장에는 입력할 값뿐 아니라 상태와 확인 근거 칸을 둔다. 상태는 8.8의 표에 나오는 다섯 단계로 적고, 확인 근거에는 제출 뒤 목록이나 상태표에서 무엇을 보고 성공으로 판단했는지를 적는다. 이 두 칸이 있으면 작업이 중간에 멈춰도 어디서부터 이어야 하는지 바로 알 수 있고, 같은 건을 두 번 제출하는 일도 막을 수 있다.
[입력 원장 예시, 가상 데이터] 번호 | 상품명 | 코드 | 날짜 | 가격 | 상태 | 확인 근거 1 | 샘플 상품 A | SMP-0001 | 2026-09-01 | 9,900 | 확인됨 | 목록 12→13건, 새 행 코드·분류·상태 일치 2 | 샘플 상품 B | SMP-0002 | 2026-09-01 | 7,700 | 확인됨 | 목록 13→14건, 새 행 일치 3 | 샘플 상품 C | SMP-0003 | 2026-09-05 | 8,800 | 제출됨 | 목록 반영 대기 중 4 | 샘플 상품 D | SMP-0004 | 2026-09-05 | 6,600 | 대조됨 | 5 | 샘플 상품 E | SMP-0005 | 2026-09-10 | 9,900 | 입력 전 | 6 | 샘플 상품 F | SMP-0006 | 2026-09-10 | 5,500 | 입력 전 |
8.4 전체 작업은 어떤 순서로 흘러갈까?
흐름은 일곱 단계다. 먼저 입력 원장을 준비한다. 다음으로 에이전트가 1번 건만 입력하고 멈춘 뒤 값 표와 화면 캡처를 보여 준다. 사람은 그것을 확인하고 첫 제출을 한다. 네 번째 단계에서 목록이나 상태표에서 성공 신호를 확인하고, 그 신호가 무엇이었는지 원장에 적는다. 다섯 번째부터는 나머지 건을 한 건씩 입력하고, 화면에 표시된 값을 원장과 대조하고, 제출하고, 확인한다. 여섯 번째로 실패한 건은 따로 떼어 이유를 적고 재시도한다. 마지막으로 원장 전체와 사이트 목록을 다시 대조해 보고한다. 한 건이 완전히 끝나야 다음 건으로 넘어간다.
8.5 빠르게 채우면 왜 값이 틀어질까?
빠른 입력 방식은 사이트가 스스로 하는 정리와 검사를 건너뛰기 때문이다. 채널 B의 날짜 칸이 그런 경우였다. 1번 건에서는 에이전트가 일반 입력 방식으로 20260901을 넣었고, 사이트가 이를 2026-09-01로 자동으로 바꿔 주었다. 2번 건부터는 속도를 높이려고 스크립트로 칸의 값을 직접 넣었는데, 이 방식에서는 사이트의 날짜 정리 기능이 동작하지 않아 날짜가 8자리 숫자 그대로 남았다. 겉으로는 값이 들어간 것처럼 보였기 때문에 그대로 제출했다면 잘못된 날짜로 등록될 수 있었다. 제출 전에 모든 칸의 표시값을 다시 읽어 원장과 대조하는 단계에서 이 차이가 드러났고, 6건 모두 날짜를 일반 입력 방식으로 다시 넣은 뒤 제출했다. 1건에서 N건으로 늘린 뒤에도 건마다 사이트가 정리한 뒤의 표시값을 원장과 대조해야 한다. 지름길은 사이트 자체의 검증을 건너뛴다.
분류 선택 팝업에서도 비슷한 일이 있었다. 버튼을 눌러 여는 분류 선택 창을 여는 동작과 창 안에서 고르는 동작을 한 단계로 묶었더니, 창이 아직 준비되지 않은 상태에서 고르려다 실패하는 일이 가끔 생겼다. 팝업을 여는 단계와 다루는 단계를 나누자 문제가 사라졌다. 화면이 바뀌는 동작 뒤에는 새 화면을 한 번 읽고 나서 다음 동작을 하게 하면 된다.
8.6 제출이 성공했는지는 어떻게 알 수 있을까?
성공 메시지가 아니라 목록과 상태표로 확인한다. 채널 B에서는 제출 뒤 성공 메시지가 나오지 않았다. 믿을 수 있는 신호는 상품 목록의 전체 건수가 1 늘어나는 것이었고, 반영까지 12초에서 15초쯤 기다려야 했다. 건수가 늘어나면 새 행의 상품 번호, 이름, 코드, 분류, 상태가 원장과 같은지 확인했다. 채널 C는 더 헷갈렸다. 저장을 눌러도 메시지가 없고, 폼에는 입력한 값이 그대로 남아 있고, 진행 중인 항목을 보여 주는 상자에는 여전히 없음이라고 적혀 있었다. 실패처럼 보이는 화면이었지만 실제 확인은 다음 단계 화면의 상태표에서 이루어졌고 저장은 정상이었다. 여기서 나온 규칙이 “화면이 그대로라는 이유로 다시 누르지 않는다”이다. 다시 누르면 중복 등록될 수 있다. 성공 여부가 불분명하면 기다렸다가 목록이나 상태표를 다시 읽고, 그래도 판단이 안 서면 멈추고 사람에게 묻는다.
8.7 되돌릴 수 없는 지점은 어디일까?
사이트마다 다르므로 시작 전에 정확히 어느 클릭인지 찾아 둔다. 채널 C에서 마지막 단계 버튼은 이름만 보면 최종 제출 같았지만, 누르면 확인 창이 열릴 뿐이었다. 진짜로 되돌릴 수 없는 지점은 그 확인 창의 확인 버튼이었고, 그 전까지는 첨부 파일도 바꿀 수 있었다. 이 경계를 알고 나니 확인 창이 열리기 직전까지는 편하게 맡기고, 확인 버튼 하나에만 주의를 모을 수 있었다. 지시문에는 “확인 창의 확인 버튼 전에서 멈춰”처럼 경계를 구체적으로 적는다.
폼이 받아 준다고 승인된 것은 아니라는 점도 기억해 둔다. 기관 신청 양식 하나는 제출 자체는 막힘 없이 되었고 사유 칸에 사정도 설명했지만, 심사 단계에서 반려되었다. 이유는 사이트 안내문에 분명한 문장으로 적혀 있던 규칙이었다. 조건부나 재량을 암시하는 표현이 아니라 단정적으로 적힌 규칙은 폼이 입력을 막지 않더라도 심사에서 그대로 적용된다고 보는 편이 맞다. 그래서 신청 양식을 맡길 때는 안내문을 먼저 읽고 해당 규칙에 걸리는지 점검하게 한다. 같은 곳에 서로 의존하는 요청이 여러 개라면 한 메시지에 묶지 않고, 앞의 요청이 해결된 뒤에 다음 요청을 보내는 순서를 택했다. 앞의 결과에 따라 다음 요청의 내용이 달라질 수 있기 때문이다.
8.8 한 건이 실패하면 나머지는 어떻게 해야 할까?
실패의 성격을 먼저 나눈다. 한 건에만 해당하는 실패, 예를 들어 그 상품의 값 하나가 형식에 맞지 않는 경우라면 그 건을 실패로 표시하고 이유를 적은 뒤 다음 건으로 넘어가도 된다. 반대로 모든 건에 똑같이 일어날 실패, 예를 들어 날짜 칸이 정리되지 않는 문제나 로그인이 풀린 상황이라면 계속 진행해 봐야 같은 실패만 쌓인다. 그래서 연속 두 건이 실패하거나, 첫 건에서 보지 못한 화면이 나타나면 전체를 멈추고 보고하게 한다. 각 건은 아래 다섯 상태 중 하나로 원장에 기록한다.
| 상태 | 뜻 | 다음 단계로 가는 조건 | 하지 말 것 |
|---|---|---|---|
| 입력됨 | 폼에 원장 값을 일반 입력 방식으로 넣음 | 모든 칸의 표시값을 다시 읽음 | 스크립트로 값을 직접 넣기 |
| 대조됨 | 표시값이 원장과 전부 일치함 | 한 칸이라도 다르면 고친 뒤 다시 대조 | 불일치를 둔 채 제출 |
| 제출됨 | 제출 버튼을 한 번 누름 | 목록이나 상태표 반영을 기다림 | 화면이 그대로라고 다시 누르기 |
| 확인됨 | 목록 건수 증가, 새 행 값 일치 | 확인 근거를 원장에 적고 다음 건으로 | 메시지만 보고 확인 처리 |
| 실패 재시도 | 이유를 적고 따로 떼어 둠 | 원인을 고친 뒤 목록에 없는지 확인하고 한 번만 재시도 | 목록 확인 없이 재제출, 연속 2건 실패 뒤 계속 진행 |
8.9 요청 지시문 예제
아래는 지금까지의 규칙을 모은 설명용 지시문이다. 사이트 이름과 원장 파일은 가상으로 두었으니 자기 작업에 맞게 고쳐 쓴다. 자주 한다면 6장처럼 스킬로 저장해 둔다.
[반복 폼 제출 지시문 예시, 가상 설정] 목적: '상품원장.csv'의 6건을 판매자 관리 화면의 상품 등록 양식으로 1건씩 등록한다. 시작 전 1. 원장을 읽고 건수와 각 칸의 형식을 확인한다. 이상하면 시작하지 말고 보고한다. 2. 되돌릴 수 없는 클릭이 어디인지 찾아 알려 준다. 확인 창이 따로 뜨는지도 확인한다. 3. 사이트 안내문에 제출 조건이나 금지 규칙이 있으면 요약해 보여 준다. 첫 건 4. 1번 건만 입력하고 제출 전에 멈춘다. 5. 입력된 모든 칸의 표시값과 원장 값을 나란히 적은 표, 폼의 위쪽과 아래쪽 화면 캡처를 보여 준다. 6. 내가 확인하고 제출하면, 목록이나 상태표에서 무엇이 성공 신호인지 확인해 원장에 적는다. 7. 내가 "나머지 진행"이라고 말하기 전에는 2번 건을 시작하지 않는다. 나머지 건 (1건씩, 한 건이 끝나야 다음 건) 8. 키보드로 입력하는 일반 방식으로 채운다. 스크립트로 값을 직접 넣지 않는다. 9. 팝업을 여는 단계와 팝업 안에서 고르는 단계를 나눈다. 10. 모든 칸의 표시값을 다시 읽어 원장과 비교한다. 전부 같을 때만 제출한다. 11. 제출은 한 번만 누른다. 화면이 그대로여도 다시 누르지 않는다. 12. 15초쯤 기다린 뒤 목록 건수가 1 늘었는지, 새 행의 코드·이름·분류·상태가 원장과 같은지 확인한다. 13. 원장의 상태 칸을 입력됨 / 대조됨 / 제출됨 / 확인됨 / 실패 재시도 중 하나로 갱신하고 확인 근거를 적는다. 실패 처리 14. 한 건에만 해당하는 실패는 이유를 적고 그 건을 건너뛴 뒤 다음 건으로 간다. 15. 재시도 전에는 그 건이 이미 목록에 있는지 먼저 확인한다. 재시도는 한 번만. 16. 연속 2건 실패, 첫 건에서 못 본 화면, 로그인·본인 인증·CAPTCHA 화면이 나오면 전체를 멈추고 보고한다. 금지 - 결제, 메시지 발송, 계정 설정 변경은 하지 않는다. - 원장에 없는 값을 추측해 넣지 않는다. 최종 보고 - 처리 / 확인됨 / 실패 건수 - 건별 상태와 확인 근거 표 - 실패 건의 이유와 필요한 조치 - 마지막에 목록 전체를 다시 읽어 원장과 대조한 결과
보고는 이런 모양으로 받는다. 아래는 형식을 보여 주기 위한 가상 예시이며 실제 작업 결과가 아니다.
[가상 예시] 상품 등록 최종 보고 처리 6 / 확인됨 5 / 실패 1 1 샘플 상품 A 확인됨 목록 12→13건, 새 행 일치 (첫 건, 사람 제출) 2 샘플 상품 B 확인됨 목록 13→14건, 새 행 일치 3 샘플 상품 C 확인됨 목록 14→15건, 새 행 일치 4 샘플 상품 D 실패 분류 선택 창에 원장의 분류가 없음. 제출하지 않음 5 샘플 상품 E 확인됨 목록 15→16건, 새 행 일치 6 샘플 상품 F 확인됨 목록 16→17건, 새 행 일치 필요한 조치: 4번 분류를 원장에서 정해 주면 1건만 재진행 최종 대조: 목록 17건 중 이번 등록 5건, 원장과 불일치 0, 중복 등록 0
8.10 승인과 중간 개입은 어디서 할까?
공식 문제 해결 도움말에 따르면 작업은 승인이나 답변을 기다리며 멈출 수 있다. 이때 작업을 열어 요청된 동작을 검토하고 승인, 거절, 답변을 한 뒤 재개하면 된다. 승인 팝오버는 브라우저 화면에서 바로 승인하거나 거부할 수 있고, 질문과 초안 검토는 작업 상세 화면에서 열린다. 작업이 엉뚱한 방향으로 가면 후속 메시지를 보낸다. Steer는 지금 실행 중인 작업을 바로잡고, Queue는 현재 실행이 끝난 뒤에 이어 할 일을 넣는다. “4번은 건너뛰어” 같은 지시는 Steer로 보낸다. 사이트가 다중 인증, 패스키, CAPTCHA, 본인 확인을 요구하면 사람이 그 단계를 마친 뒤 작업을 재개한다.
권한도 함께 정해 둔다. 공식 보안 도움말에 따르면 도구와 접근은 Allow, Ask, Deny로 정하고 겹치면 Deny가 이긴다. 권한 모드는 Read only, Guard, Full access 세 가지이며 기본값은 Guard다. 집필 환경에서 관찰한 설정으로는 결제 사용 기능이 꺼져 있고 결제 전에 묻도록 되어 있었으며, 메시지나 메일 발송도 꺼져 있고 보내기 전에 묻도록 되어 있었다. 이는 이 환경의 관찰이며 모든 사용자의 기본값을 보장하지 않는다. 승인을 어디에 두면 좋은지는 11장에서, 아예 맡기지 않을 일은 14장에서 자세히 다룬다.
8.11 다음 장: 내 사이트를 점검하고 고치기
이 장에서는 남의 사이트에 같은 양식을 반복해 제출하면서 첫 건 확인, 건별 대조, 목록으로 확인하기라는 세 가지 습관을 익혔다. 다음 9장에서는 방향을 바꿔 내가 운영하는 사이트를 에이전트와 함께 점검하고 고치는 일을 다룬다.
확인한 공식 자료와 관찰 범위
2026년 9월 26일 확인. 문제 해결 안내 · 보안과 권한 안내. 등록 기록은 집필 환경에서 실제로 진행한 등록 작업을 일반화한 것이며, 사이트와 상품, 입력값은 공개하지 않았다. 결제와 발송 관련 설정값은 이 환경에서 관찰한 것이며 기본값을 보장하지 않는다. 입력 원장, 지시문, 보고 예시는 설명용 가상 예시다.
다음 글: 9장 · 내 사이트를 점검하고 고치기
이전 글: 7장 · 매일 같은 숫자를 긁어 시트에 쌓기
『Aside 브라우저 사용설명서』 연재 목록
공식 자료와 집필 환경의 작업 기록을 바탕으로 AI의 도움을 받아 작성·편집했습니다. 흐름도와 예시는 설명용이며 실제 앱 화면이나 실제 값이 아닙니다. 초판 선공개 원고 v1.0.