매일 같은 숫자를 긁어 시트에 쌓기 | Aside 브라우저 사용설명서 7장

실행 전 점검, 수집, 이상값 검사, 시트 기록, 전체 대조, 요약 보고로 이어지는 숫자 추적 루틴 흐름도

매일 같은 숫자를 모아 시트에 쌓는 일은 크론 루틴에 맡기면 된다.

6장에서 일하는 순서를 스킬로 적었다면, 이번 장에서는 그 순서를 정해진 시각에 저절로 시작하게 만든다. 예제로 삼는 일은 공개 페이지에 표시되는 숫자 항목 100여 개를 매일 새벽 읽어 Google Sheets에 하루 한 열씩 쌓는 작업이다. 집필 환경에서 이 일을 40일 동안 실제로 돌렸고, 추적 항목은 처음 약 100개에서 지금 130여 개로 늘었다. 그 사이 여러 번 어긋났고, 어긋날 때마다 규칙을 하나씩 더해 지금은 매일 불일치 0으로 끝나는 절차가 됐다. 이 장은 그 과정을 일반화해 정리한 것이다. 특정 사이트나 항목, 실제 수치는 밝히지 않는다.

7.1 어떤 일을 루틴에 맡기면 좋을까?

루틴에 맡기기 좋은 일은 매번 같은 곳을 같은 방식으로 읽고, 결과를 같은 자리에 적는 일이다. 가격표, 재고 표시, 조회수, 순위, 후기 개수처럼 공개 페이지에 숫자로 드러나는 값이 대표적이다. 하루에 한 번 사람이 직접 열어 옮겨 적으면 10개까지는 버틸 만하지만 100개가 넘어가면 시간도 들고 실수도 생긴다. 더 중요한 이유는 기록의 연속성이다. 숫자는 하루치만 보면 의미가 없고, 날짜별로 빠짐없이 쌓였을 때 비로소 추세가 보인다. 사람은 바쁜 날 하루를 건너뛰지만 루틴은 정해진 시각에 시작한다. 다만 루틴이 시작을 대신해 줄 뿐, 결과가 맞는지는 절차 안에 검사를 넣어 확인해야 한다. 이 장의 대부분은 바로 그 검사에 관한 이야기다. 로그인, 결제, 게시가 끼어드는 일은 처음 루틴으로 삼기에 알맞지 않다. 읽기만 하는 공개 페이지에서 시작한다.

7.2 크론 루틴과 하트비트는 어떻게 다를까?

공식 자동화 도움말은 루틴을 두 가지로 나눈다. 크론(Cron) 루틴은 정해진 일정에 새 작업을 시작한다. 하트비트(Heartbeat)는 이미 있는 대화를 깨워 그 흐름을 이어 간다. 도움말은 혼자서 완결되는 반복 작업에는 크론을 쓰라고 안내한다. 매일 숫자를 모으는 일은 전날 대화의 맥락이 필요 없고 시트만 있으면 되므로 크론이 맞다. 도움말에 따르면 어사이드는 루틴 실행이 겹치면 겹친 실행을 건너뛰고, 대상 대화를 쓸 수 없으면 루틴을 일시 중지한다. 설정의 루틴 화면에서는 루틴을 만들고, 지시문과 일정을 고치고, 일시 중지와 재개, 삭제, 지금 실행(Run now)을 할 수 있다. 추천 루틴을 찾아 활성화하거나 거절하는 기능도 있다. 무료 요금제는 활성 루틴이 3개까지이고 Pro는 제한이 없다.

집필 환경에서 관찰한 점도 하나 적어 둔다. 이 환경의 루틴은 사용자의 로컬 브라우저로 실행됐다. 화면만 꺼진 상태에서는 정상적으로 돌았지만 컴퓨터가 잠자기에 들어가면 그 시각의 실행은 건너뛰어졌다. 이는 사양이 아니라 관찰이며, 자세한 내용은 12장에서 다룬다. 40일 운영 동안 실행 시각은 사용자의 생활 리듬에 맞춰 두 번 앞당겼고, 새벽에 한 번 도는 크론 하나로 충분했다.

하트비트가 더 어울리는 경우도 있다. 어제 나눈 대화의 결론을 이어받아 오늘 후속 작업을 해야 하거나, 하나의 프로젝트 대화에서 진행 상황을 계속 쌓아 가고 싶을 때다. 반면 숫자 수집처럼 매일 똑같이 끝나는 일을 하트비트로 만들면 한 대화에 날마다 기록이 쌓여 길어지고, 그 대화를 쓸 수 없는 날에는 루틴이 멈춘다. 크론은 매번 깨끗한 새 작업으로 시작하므로 전날의 실수가 다음 날 대화에 섞여 들지 않는다. 필요한 기억은 대화가 아니라 시트와 스킬에 둔다. 어제 값은 시트의 지난 날짜 열에 있고, 일하는 방법은 스킬에 있으니 새 작업은 둘만 읽으면 된다. 이 구분은 나중에 루틴을 여러 개 운영할 때도 그대로 쓸 수 있다.

7.3 시트는 어떤 모양으로 만들어 둘까?

시트는 고정 영역과 날짜 영역으로 나눈다. 왼쪽 고정 열에는 번호, 이름, 페이지 주소, 추적 상태, 최신값, 전일 대비, 최종 업데이트를 둔다. 그 오른쪽에는 날짜 열이 하루에 하나씩 추가되고, 맨 끝에 상태 열이 있다. 새 날짜 열은 매일 상태 열 바로 앞에 끼워 넣으므로 날짜가 왼쪽에서 오른쪽으로 쌓인다. 날짜 열의 첫 행에는 그날 합계에서 전날 합계를 뺀 수식을 넣어, 하루 동안 전체가 얼마나 움직였는지 한눈에 보이게 한다. 가장 중요한 원칙은 지난 날짜 열을 절대 덮어쓰지 않는 것이다. 과거 열은 이미 확정된 기록이고, 루틴이 손대는 곳은 오늘 열과 고정 열의 최신값 칸뿐이다. 이렇게 경계를 정해 두면 나중에 무엇이 바뀌었는지 대조하기도 쉬워진다.

[시트 구성 예시, 가상 데이터]
                                                                     +74    +81    +68    (첫 행: 그날 합계 - 전날 합계)
번호 | 이름     | 페이지 주소                  | 추적 상태 | 최신값 | 전일 대비 | 최종 업데이트 | 09-24 | 09-25 | 09-26 | 상태
1    | 항목 001 | https://example.com/item/1   | 추적      | 152    | +2        | 2026-09-26    | 148   | 150   | 152   | 정상
2    | 항목 002 | https://example.com/item/2   | 추적      | 37     | 0         | 2026-09-26    | 37    | 37    | 37    | 정상
3    | 항목 003 | https://example.com/item/3   | 중단      | 12     |           | 2026-08-30    |       |       |       | 추적 안 함
4    | 항목 004 | https://example.com/item/4   | 추적      | 0      | 0         | 2026-09-26    |       | 0     | 0     | 신규

추적할 행은 추적 상태 열의 값으로 고른다. 그래서 사용자가 시트 아래에 새 행을 직접 추가하고 추적 상태만 채우면 다음 날부터 자동으로 수집 대상에 들어간다. 실제로 항목은 이 방식으로 약 100개에서 130여 개까지 늘었다. 한 가지 놓친 곳은 첫 행의 합계 수식이었다. 수식 범위를 처음 행 수에 맞춰 고정해 두었기 때문에 행이 늘자 새 항목이 합계에서 빠졌고, 범위를 넓혀 바로잡았다. 행을 늘리는 방식이라면 합계 범위를 넉넉하게 잡거나 열 전체를 대상으로 하는 편이 안전하다.

7.4 한 번의 실행은 어떤 순서로 흘러갈까?

실행 전 점검에서 작은 묶음 수집, 이상값 검사, 새 날짜 열 기록, 전체 대조, 요약 보고로 이어지는 일일 숫자 수집 루틴의 여섯 단계 흐름도
그림 7-1. 매일 숫자를 모아 시트에 쌓는 루틴의 여섯 단계를 정리한 설명용 흐름도, 실제 앱 화면 아님. 2026년 9월 26일 기준.

실행은 여섯 단계로 흐른다. 먼저 실행 전 점검에서 작업할 브라우저 창을 쓸 수 있는지 확인하고, 시트 전체를 CSV로 내려받아 백업한다. 다음은 수집이다. 한 번에 여섯 개 정도의 작은 묶음으로 페이지를 열어 숫자를 읽고 닫으며, 읽은 결과는 행 번호를 기준으로 파일에 저장해 둔다. 세 번째는 이상값 검사로, 0과 빈칸과 급격한 변화를 걸러 다시 확인한다. 네 번째가 시트 기록이다. 모든 행을 모은 뒤에야 새 날짜 열을 만들고 값을 적는다. 다섯 번째는 전체 대조로, 시트를 다시 내려받아 적은 칸과 보존해야 할 칸을 모두 비교한다. 마지막으로 처리 건수와 변동을 요약해 보고한다. 이 순서는 처음부터 설계된 것이 아니라, 7.5의 사건들을 하나씩 겪으며 자리 잡은 결과다.

7.5 40일 운영에서 무엇이 어긋났고 어떻게 고쳤을까?

2026년 8월 17일부터 40일 동안의 운영 기록을 정리하면 아래 표와 같다. 사건마다 무엇이 일어났는지, 어떻게 알아챘는지, 그 뒤로 어떤 규칙을 더했는지를 적었다. 사건을 겪을 때마다 규칙을 절차에 반영했고, 마지막 7일은 모두 실패 0, 불일치 0으로 끝났다.

날짜일어난 일잡아낸 방법고친 규칙
9월 5일20여 개 행 묶음을 조용히 건너뛰어 그날 칸이 빈칸으로 남음. 실패 표시도 없었음다음 날 전체 변동이 평소 80 안팎 대신 550가량으로 튀어 합계 검사에 걸림수식을 믿기 전에 전날 열의 빈칸부터 확인. 빈칸은 마지막 확인값으로 채우고 표시를 남김
9월 10~13일작업 창이 전체 화면 상태로 다른 데스크톱 공간에 있어 새벽 실행이 시트조차 열지 못함실행 보고에 시트 접근 실패가 남음창 초점을 되찾은 뒤 재실행해 완료. 밤새 작업 창을 전체 화면으로 두지 않음
9월 13일127개 중 70여 개를 읽은 시점에 창 초점을 잃음묶음 사이 점검에서 발견묶음 전후로 초점 확인, 성공한 결과는 행 기준으로 보관, 전부 모은 뒤에만 기록, 실패 행만 재개
9월 14일시트 탭이 뒤에 있는 상태에서 일괄 붙여넣기가 맨 왼쪽 위 칸에 들어가 앞쪽 세 열을 덮어씀기록 뒤 전체 대조실행 전 CSV 백업에서 정확히 복원. 탭을 앞에 두고 칸을 지정해 적는 방식으로 전환
9월 17일한 번의 호출에 묶음을 너무 많이 이어 붙여 호출당 120초 제한에 걸림호출 시간 초과 오류한 호출에 한 묶음만 처리
9월 19일실행 중 백그라운드 서비스가 재시작되어 작업 상태가 사라짐. 한 탭을 재사용해 여러 페이지를 넘길 때 사이트 오류도 발생진행 파일과 탭별 결과 비교진행 파일에서 이어서 재개. 약 6개씩 열고 읽고 닫는 작은 묶음으로 복귀
9월 20일너무 빨리 읽은 초반 묶음에서 연속 76개가 0으로 찍힘. 숫자가 뜨기 전 자리표시 값이었음어제 양수였던 항목이 0, 0의 긴 연속을 기록 전 검사가 잡음해당 행만 더 작은 묶음으로 새로 읽어 전부 회복
표 7-1. 40일 운영 기록을 일반화한 사건과 규칙. 사이트와 항목, 실제 수치 대신 규모만 적었다.

표에서 가장 교훈이 컸던 것은 전체 화면 사건이다. macOS에서 창을 전체 화면으로 두면 그 창은 별도의 데스크톱 공간을 차지하고, 사용자가 다른 공간에 있는 동안에는 초점을 잃은 상태가 된다. 이 환경의 루틴은 그런 창을 제대로 다루지 못해 시트를 열지 못했다. 해결은 간단했다. 사용자가 창을 다시 눌러 초점을 돌려주자 같은 날 재실행이 모두 끝났다. 예방도 어렵지 않다. 작업 창은 밤사이 전체 화면으로 두지 않는다. 창 왼쪽 위의 초록 버튼을 누르거나 Ctrl+Cmd+F로 전체 화면을 빠져나오고, 크게 쓰고 싶다면 Option 키를 누른 채 초록 버튼을 눌러 새 공간을 만들지 않고 창만 키운다. 여기에 더해 묶음 사이마다 초점을 확인하고, 성공한 결과는 행 번호로 보관하며, 모든 행이 모였을 때만 시트에 적도록 바꿨다. 그 뒤로는 중간에 멈춰도 실패한 행만 다시 읽으면 된다.

9월 14일의 덮어쓰기는 백업 덕분에 피해 없이 끝난 사건이다. 빠르게 처리하려고 여러 칸을 한 번에 붙여넣었는데, 시트 탭이 뒤에 가려진 상태라 붙여넣기가 의도한 열이 아니라 시트 맨 위 왼쪽 첫 칸부터 들어갔다. 그 결과 번호, 이름, 페이지 주소 열이 덮였다. 다행히 실행 전에 시트 전체를 CSV로 받아 두었기 때문에 그 파일에서 세 열을 한 칸도 틀리지 않게 되살렸다. 이후에는 탭을 앞에 둔 상태에서 칸을 명시적으로 지정해 이동한 뒤 적는다. 빠른 일괄 붙여넣기보다 칸이나 열 단위로 적고 확인할 수 있는 방식이 조금 느려도 결과를 믿을 수 있다. 쓰기 전 전체 백업은 이 장에서 가장 먼저 권하는 습관이다.

7.6 빈칸과 0은 왜 따로 다뤄야 할까?

시트 수식에서 빈칸은 0으로 계산되기 때문이다. 9월 5일에 20여 개 행이 빈칸으로 남자, 다음 날 합계 수식은 그 행들의 전날 값을 0으로 보고 전체 값을 하루 증가분으로 셌다. 평소 80 안팎이던 변동이 550가량으로 튄 이유다. 숫자 자체는 틀리지 않았지만 빈칸이 끼어든 비교는 의미가 없었다. 그래서 규칙을 두 개 더했다. 첫째, 합계 수식을 믿기 전에 전날 열에 빈칸이 있는지 먼저 본다. 둘째, 빈칸이 있으면 마지막으로 확인된 값을 이어 채우고 그렇게 채웠다는 표시를 남긴다. 이 항목들의 하루 변화는 대개 한 자리 수라서 마지막 값을 잇는 것이 가장 덜 틀리는 선택이었다. 반대로 0은 빈칸과 다르다. 새로 추가한 항목은 정말로 0일 수 있다. 그래서 0이나 -1이 한 번 나오면 바로 받아들이지 않고 두 번 더 읽어 같은 값일 때만 기록한다.

9월 20일의 76개 연속 0은 이 규칙이 제 역할을 한 경우다. 페이지를 연 직후 숫자가 채워지기 전의 자리표시 값을 그대로 읽은 것인데, 어제 양수였던 항목이 갑자기 0이 되고 0이 길게 이어지는 모습이 기록 전 검사에 걸렸다. 시트에는 아무것도 적히지 않았고, 해당 행만 더 작은 묶음으로 새로 열어 읽자 모두 정상값으로 돌아왔다. 검사를 기록 앞에 두면 틀린 값이 시트에 남을 틈이 없다.

7.7 기록 전후로 무엇을 점검해야 할까?

점검은 기록 전과 기록 후로 나눈다. 기록 전에는 쓸 준비가 되었는지, 기록 후에는 쓴 것이 맞는지를 본다. 기록 후 대조가 특히 중요하다. 시트를 CSV로 다시 내려받아, 오늘 적은 칸뿐 아니라 고정 열, 지난 날짜 열 전부, 상태 열처럼 바뀌면 안 되는 영역까지 백업본과 비교한다. CSV 내보내기는 편집 직후 곧바로 반영되지 않을 때가 있어 몇 초 기다렸다가 받는다. 결과는 “불일치 몇 개”라는 숫자 하나로 보고하게 한다. 마지막 7일(9월 20일~26일)은 매일 127~131개 항목을 전부 처리했고, 실패 0, 약 320행 CSV 전체에서 불일치 0이었다. 하루 순변동은 대체로 +60~+100 사이였다.

보고는 짧을수록 좋다. 매일 아침 사람이 확인할 것은 처리, 성공, 실패 건수와 불일치 개수, 그리고 전체 변동이 평소 범위 안에 있는지 정도다. 실패가 0이고 불일치가 0이며 변동이 평소와 비슷하면 시트를 열어 볼 필요도 없다. 세 값 중 하나라도 튀면 그때 시트를 열고 해당 행을 본다. 9월 5일의 빈칸 사건도 바로 이 변동 값이 평소의 일곱 배 가까이 튀면서 드러났다. 평소 범위를 알려면 처음 몇 주는 보고를 눈여겨 보며 감을 잡아야 한다. 범위가 잡히면 그 숫자를 지시문에 적어, 범위를 크게 벗어나면 보고 첫 줄에 경고를 달게 할 수도 있다. 사람의 감을 규칙으로 옮겨 두는 것이다.

시점점검 항목통과 기준
기록 전작업 창 초점과 전체 화면 여부창이 앞에 있고 전체 화면이 아님
기록 전시트 전체 CSV 백업파일이 저장되고 행 수가 시트와 같음
기록 전전날 열의 빈칸빈칸 없음, 있으면 마지막 값으로 채우고 표시
기록 전수집 결과의 이상값0·-1은 2회 재확인, 어제 양수→0과 0 연속은 재수집
기록 전수집 완료 여부추적 대상 전 행의 값이 모였을 때만 진행
기록 후오늘 열의 모든 칸수집값과 CSV 값이 전부 일치
기록 후보존 영역(고정 열, 지난 날짜 열, 상태 열)백업본과 비교해 변경 0
기록 후첫 행 합계 수식 범위새로 추가된 행까지 포함
표 7-2. 시트 기록 전후 점검표. 기록 후 결과는 불일치 개수 하나로 보고한다.

7.8 루틴 지시문 예제

아래는 지금까지의 규칙을 모아 만든 설명용 지시문이다. 주소와 시트 이름은 가상으로 바꿨으니 자기 환경에 맞게 고쳐 쓴다. 이 예제를 그대로 루틴 지시문에 넣어도 되지만, 6장처럼 절차는 스킬로 저장하고 루틴에는 “daily-number-log 스킬로 오늘 수집을 실행해” 한 줄만 두는 편이 관리하기 쉽다. 스킬은 일하는 방법을, 루틴은 시작하는 시각을 맡는다. 새 규칙이 생기면 스킬만 고치면 되고, 실행 시각을 바꿀 때는 루틴 일정만 바꾼다. 이 장의 40일 동안에도 규칙은 여러 번 늘었지만 실행 시각 변경은 두 번뿐이었다. 둘을 나눠 두면 어느 쪽을 고쳐도 다른 쪽이 흔들리지 않는다.

[일일 숫자 수집 지시문 예시, 가상 설정]

목적: 공개 페이지에 표시되는 숫자를 읽어 Google Sheets의 '일일기록' 탭 하나에 오늘 날짜 열로 기록한다.

범위
- 로그인 없이 볼 수 있는 공개 페이지만 읽는다. 페이지에서 클릭, 입력, 게시, 구매를 하지 않는다.
- 시트는 '일일기록' 탭만 수정한다. 다른 탭은 열어 보기만 하고 절대 편집하지 않는다.
- 지난 날짜 열, 번호·이름·페이지 주소·추적 상태 열, 상태 열은 덮어쓰지 않는다.

실행 전
1. 작업 창이 앞에 있고 전체 화면이 아닌지 확인한다. 아니면 멈추고 보고한다.
2. 시트 전체를 CSV로 내려받아 백업으로 저장한다.
3. 추적 상태가 '추적'인 행만 대상으로 삼는다.
4. 전날 날짜 열에 빈칸이 있으면 마지막으로 확인된 값으로 채우고 '보정' 표시를 남긴다.

수집
5. 한 번에 약 6개씩 새 탭으로 열어 숫자를 읽고 탭을 닫는다. 한 호출에 한 묶음만 처리한다.
6. 페이지의 숫자가 다 뜬 뒤에 읽는다.
7. 결과는 행 번호를 기준으로 진행 파일에 저장한다. 중단되면 진행 파일에서 이어서, 실패한 행만 다시 읽는다.
8. 묶음 사이마다 창 초점을 확인한다.

이상값
9. 0이나 -1은 두 번 더 읽어 같은 값일 때만 받아들인다. 새 항목은 0일 수 있다.
10. 어제 양수였던 항목이 0이거나 0이 여러 개 연속되면 해당 행만 더 작은 묶음으로 다시 읽는다.
11. 빈칸과 0을 섞지 않는다. 읽지 못한 값은 0으로 적지 않고 실패로 표시해 다시 읽는다.

멈추는 조건
- 로그인, 본인 인증, CAPTCHA 화면이 나오면 더 진행하지 않는다.
- 시트를 열 수 없거나 백업에 실패하면 기록하지 않는다.
- 멈출 때는 처리한 행 범위와 멈춘 이유를 보고한다.

기록
12. 모든 대상 행의 값이 모였을 때만 쓴다.
13. 상태 열 바로 앞에 오늘 날짜 열을 새로 만들고(이미 있으면 새로 만들지 않고 그 열만 갱신), 탭이 앞에 있는 상태에서 칸을 지정해 적는다. 일괄 붙여넣기는 쓰지 않는다.
14. 최신값, 전일 대비, 최종 업데이트 칸을 갱신한다.
15. 첫 행 합계 수식이 새 행까지 포함하는지 확인한다.

검증
16. 몇 초 기다린 뒤 시트 전체를 CSV로 다시 받는다.
17. 오늘 적은 모든 칸과 보존 영역을 백업본과 비교해 불일치 개수를 센다.

보고 형식
- 처리 / 성공 / 실패 건수
- 전일 대비 합계, 변동 항목 수와 유지 항목 수
- 많이 오른 항목 상위 3개, 소폭 감소 항목
- 보정한 칸, 재확인한 칸
- 검증 결과: 불일치 개수

보고는 이런 모양으로 받는다. 아래는 형식을 보여 주기 위한 가상 예시이며 실제 실행 결과가 아니다.

[가상 예시] 2026-09-26 새벽 일일 수집 보고
처리 130 / 성공 130 / 실패 0
전일 대비 합계 +74 (변동 41개, 유지 89개)
많이 오른 항목: 항목 017 +9, 항목 052 +7, 항목 088 +6
소폭 감소: 항목 031 -1 (2회 재확인 후 반영)
보정: 없음 / 재확인: 0 값 3건, 모두 신규 항목으로 확인
검증: CSV 재다운로드, 기록 칸과 보존 영역 대조 결과 불일치 0

지시문이 스스로 범위를 좁히는 것과 별개로 실제 권한도 정해 둔다. 공식 보안 도움말에 따르면 루틴과 작업에는 Read only, Guard, Full access 세 가지 권한 모드가 있고 기본값은 Guard다. 개별 도구와 접근은 Allow, Ask, Deny로 정하며 겹치면 Deny가 이긴다. 이 장의 실제 루틴은 기본값인 Guard로 돌렸고, 쓰는 곳은 시트 탭 하나로 지시문에서 못박았다. 권한은 할 수 있는 일의 바깥 경계를, 지시문은 그 안에서 실제로 할 일을 정한다고 이해하면 된다.

7.9 처음에는 어떻게 작게 시작할까?

처음부터 100개를 매일 돌리지 않는다. 항목 10개로 시트를 만들고, 루틴을 만든 뒤 설정의 루틴 화면에서 지금 실행(Run now)으로 두 번 돌려 본다. 첫 번째 실행에서는 새 날짜 열이 올바른 자리에 생기는지, 보고 형식이 지시문대로 나오는지를 본다. 두 번째 실행은 같은 날 한 번 더 돌렸을 때 날짜 열을 중복으로 만들지 않고 오늘 열만 갱신하는지, 백업과 대조가 매번 이루어지는지를 확인하는 시험이다. 두 번 모두 불일치 0으로 끝나면 그때 매일 일정으로 바꾼다. 며칠 지켜본 뒤 항목을 수십 개씩 늘린다. 항목을 늘릴 때마다 합계 수식 범위를 함께 확인한다. 이 장의 기록도 사건 대부분이 규모가 커지고 조건이 바뀐 시점에 나왔다. 작게 시작해 한 번에 하나씩 늘리면 문제가 생겨도 원인을 쉽게 찾을 수 있고, 고친 규칙을 스킬에 한 줄씩 더해 가면 된다.

7.10 다음 장: 반복되는 폼 제출

이 장의 일은 공개 페이지를 읽기만 하고 쓰는 곳은 내 시트 하나였다. 틀려도 백업에서 되돌릴 수 있었기에 규칙을 고쳐 가며 익힐 수 있었다. 다음 8장에서는 한 걸음 더 나아가 같은 양식을 여러 번 채워 제출하는 일을 다룬다. 제출은 되돌리기 어려운 동작이라, 이번 장에서 익힌 백업, 검사, 대조의 습관이 더 중요해진다.

확인한 공식 자료와 관찰 범위

2026년 9월 26일 확인. 자동화와 루틴 안내 · 보안과 권한 안내 · 작업 안내. 운영 기록은 집필 환경에서 2026년 8월 17일부터 40일 동안 실제로 돌린 루틴의 기록을 일반화한 것이며, 대상 사이트와 항목, 실제 수치는 공개하지 않았다. 잠자기와 전체 화면에 관한 내용은 집필 환경의 관찰이며 사양이 아니다. 시트 구성, 지시문, 보고 예시는 설명용 가상 예시다.

다음 글: 8장 · 같은 양식의 폼을 반복 제출하기
이전 글: 6장 · 스킬: 코드 없이 에이전트를 가르치기
『Aside 브라우저 사용설명서』 연재 목록

공식 자료와 집필 환경의 운영 기록을 바탕으로 AI의 도움을 받아 작성·편집했습니다. 흐름도와 예시는 설명용이며 실제 앱 화면이나 실제 수치가 아닙니다. 초판 선공개 원고 v1.0.