안녕하세요? 정리하는 개발자 워니즈입니다.
브라우저 자동화 도구를 쓸 때, 화면을 보면서 시킬 때는 멀쩡했는데 스케줄러에 걸어두고 자리를 뜨면 이상하게 어긋난 적 있으신가요?
이 글은 Aside 브라우저 자동화를 한 달 가까이 사람 없이 돌리면서 실제로 걸린 지점 6가지를 정리한 것입니다. 사람이 앉아서 쓰는 사용기는 이미 여러 편이 있는데요, 사람이 없을 때만 드러나는 제약은 따로 있었습니다. 필자는 개인 블로그 운영을 하루 네 번 자동 실행으로 돌리면서 이 부분들을 하나씩 밟았습니다.
【한 줄 요약】 Aside 브라우저 자동화의 제약은 기능이 부족해서가 아니라 판정에 쓰는 신호가 사람 기준으로 맞춰져 있어서 생깁니다. 개발자 도구 포트가 닫혀 있고, 배경 탭이 스스로를 보이는 중이라고 답하며, 요소 번호가 명령 한 번을 넘기지 못하고, 상대 경로로 쓴 파일이 실행할 때마다 다른 폴더로 들어갑니다.
- 가장 위험한 것은 배경 탭이 화면에 보인다고 답하는 것입니다. 틀린 답을 오류 없이 자신 있게 줍니다.
- 가장 오래 헤맨 것은 파일 저장 위치입니다. 상대 경로의 기준이 실행 폴더가 아니라 매번 새로 생기는 세션 폴더였습니다.
- 가장 먼저 막히는 것은 개발자 도구 포트입니다. 기존 자동화 스크립트가 통째로 못 붙습니다.
판정에 쓸 수 있는 신호는 탭 목록이 알려주는 활성 여부 하나뿐입니다. 웹 표준이 주는 신호 세 개는 배경 탭에서 전부 거짓을 말했습니다.
측정 환경은 macOS이고 CLI 버전 1.26.916.1741, 브라우저 앱 버전 1.0.914.1 기준입니다. 확인한 날짜는 2026년 9월 23일입니다. 여섯 가지 모두 재현 명령과 결과를 아래에 그대로 적었습니다.
목차
- Aside 브라우저 자동화는 다른 도구와 무엇이 다른가요
- 무엇을 자동화해 두었나요
- 사람이 볼 때와 없을 때가 왜 갈리나요
- 제약 1. 개발자 도구 포트가 열려 있지 않습니다
- 제약 2. 배경 탭이 보이는 중이라고 답합니다
- 제약 3. 앞으로 끌어와도 앞으로 오지 않습니다
- 제약 4. 요소 번호는 명령이 끝나면 죽습니다
- 제약 5. 파일을 썼는데 어디에도 없습니다
- 제약 6. 탭은 늘어나기만 합니다
- 그래서 어떻게 짜야 할까요
- 누구에게 맞고 누구에게는 굳이일까요
1. Aside 브라우저 자동화는 다른 도구와 무엇이 다른가요
Aside는 Chromium을 바탕으로 만든 별도의 데스크톱 브라우저이고, 확장 프로그램이 아니라 앱 자체입니다. 자동화 관점에서 다른 도구와 갈리는 지점은 하나로 좁혀집니다. 로그인 세션이 앱 프로필에 그대로 남는다는 것인데요, 이게 왜 중요한지는 갈아타기 전에 겪은 일로 설명하는 편이 빠를 것 같습니다.
필자는 원래 크롬 프로필을 복제해서 원격 디버깅 포트로 붙이는 방식을 썼습니다. 그런데 이 방식은 프로필 복제본을 띄우는 구조라서 소셜 계정 세션이 오래 버티지 못했습니다. 실측으로는 오전에 게시가 성공한 뒤 같은 날 오전에 로그아웃됐고, 쿠키가 251개에서 12개로 줄어 있었습니다. 복구 수단이 2.4GB짜리 프로필 재복제뿐이었고 같은 날 다시 복제하는 것은 계정 쪽 위험이 있어서, 그날 예정된 작업이 통째로 막혔습니다.
Aside로 옮기고 나서는 이 실패 방식이 사라졌습니다. 세션이 앱 프로필에 유지되기 때문에 복제라는 단계 자체가 없습니다. 도구를 바꾼 이유가 기능 비교가 아니라 이 한 가지였다는 점을 먼저 적어둡니다. Aside 브라우저를 처음 써본 기록은 별도 글로 정리해 두었으니 설치와 요금이 궁금하시면 그쪽을 보시면 됩니다.
이 글은 그다음 이야기입니다. 도구를 골랐으니 이제 사람 없이 돌리는 단계인데요, 여기서부터 성격이 달라졌습니다.
2. 무엇을 자동화해 두었나요
제약 이야기를 하기 전에 무엇을 시키고 있는지부터 적는 편이 맞을 것 같습니다. 아래 네 가지가 지금 Aside 브라우저 자동화로 돌아가는 일들입니다. 전부 공개 API가 없거나, 있어도 로그인 세션이 있어야 쓸 수 있는 화면들입니다.
| 하는 일 | 왜 브라우저가 필요한가 | 빈도 |
|---|---|---|
| 소셜에 글 게시 | 공개 API가 사실상 없음 | 하루 2~3회 |
| 받은 답글에 회신 | 같음, 화면 조작이 유일한 경로 | 하루 최대 12건 |
| 게시 결과 실재 확인 | 게시 성공 응답과 실제 노출이 다를 수 있음 | 게시 직후 매번 |
| 긴 문서 본문 수집 | 화면에만 그려지고 내려받기가 없는 뷰어 | 필요할 때 |
세 번째를 따로 둔 이유가 있습니다. 자동화가 게시를 했다고 보고했는데 실제로는 안 올라간 적이 있었고, 반대로 실패했다고 보고했는데 올라가 있던 적도 있었습니다. 후자가 훨씬 위험한데요, 실패로 읽고 다시 누르면 같은 글이 두 번 올라가기 때문입니다. 지금은 스크립트가 뭐라고 보고하든 믿지 않고, 게시물 주소를 직접 열어 본문에서 그 문장이 몇 번 나오는지 세는 단계를 따로 두고 있습니다.
네 번째는 한 번 크게 데인 경우입니다. 화면에 글자를 그려주지만 내려받기가 없는 뷰어에서 수백 쪽을 읽어야 했는데요, 키를 눌러 넘기면서 화면의 글자를 모으는 방식으로 처리했습니다. 이때 걸린 것이 아래 제약 5입니다.
네 가지 모두 사람이 옆에서 보고 있으면 문제가 없습니다. 자리를 비우는 순간부터 성격이 달라집니다. 참고로 코딩 도구의 무료 한도를 확인하는 쪽은 브라우저가 필요 없어서, 커서 AI 무료 한도를 정리한 글처럼 문서와 계정 화면만으로 끝나는 주제도 있습니다.
3. 사람이 볼 때와 없을 때가 왜 갈리나요
브라우저 자동화 글이 대부분 사람이 앉아 있는 상황을 전제합니다. 화면이 떠 있고, 원하는 탭이 앞에 있고, 뭔가 어긋나면 눈으로 보고 바로잡습니다. 이 전제가 깔려 있으면 도구가 내주는 신호를 굳이 의심할 일이 없습니다.
무인 실행은 그 전제를 전부 뺍니다. 필자의 경우는 운영체제 스케줄러에 걸어 하루 네 번 자동 실행하는 구조인데요, 실행되는 시각에 필자가 컴퓨터를 보고 있을 수도 있고 아예 없을 수도 있습니다. 심지어 필자가 같은 브라우저로 다른 일을 하고 있을 수도 있습니다. 이 세 상황에서 같은 코드가 다르게 동작하면 자동화는 신뢰할 수 없게 됩니다.
아래 여섯 가지는 전부 그 차이에서 나왔습니다. Aside 브라우저 자동화가 기능이 안 되는 것이 아니라, 판정에 쓰는 신호가 사람이 보고 있다는 전제 위에 설계돼 있어서 사람이 없으면 엉뚱한 답을 주는 쪽에 가깝습니다.
| 구분 | 사람이 볼 때 | 사람이 없을 때 |
|---|---|---|
| 탭 상태 | 눈으로 확인 | 코드가 묻는데 답이 틀림 |
| 요소 지정 | 스냅샷 찍고 바로 클릭 | 명령이 나뉘며 번호가 죽음 |
| 파일 저장 | 저장 위치를 눈으로 확인 | 실행마다 폴더가 달라짐 |
| 오류 대응 | 보고 고침 | 그 회차가 통째로 사라짐 |
4. 제약 1. 개발자 도구 포트가 열려 있지 않습니다
가장 먼저 막힌 곳입니다. 기존에 쓰던 자동화 스크립트가 전부 원격 디버깅 포트에 붙는 방식이었는데요, Aside는 그 포트를 열어주지 않습니다.
직접 확인 1. 흔히 쓰는 포트 두 개를 확인했습니다.
nc -z 127.0.0.1 9222 ; nc -z 127.0.0.1 9333결과는 둘 다 닫힘이었습니다. 같은 시각에 브라우저 프로세스는 정상적으로 떠 있었고 아래에서 다룰 명령들도 전부 동작했습니다. 포트만 없는 것입니다.
Aside가 자체 데몬으로 움직이는 구조라서 그런데요, 남는 선택지는 기존 스크립트를 통째로 포기하거나 입력 전송 계층만 갈아끼우거나 둘로 갈렸는데요, 필자는 후자를 골라서 게시 성공 판정이나 중복 방지 같은 검증 로직은 그대로 두고 실제로 키를 누르고 클릭하는 부분만 Aside 명령으로 바꿨습니다.
같은 로직을 두 벌 만들면 이미 막아둔 사고를 다시 겪습니다. 필자는 예전에 그렇게 하다가 이미 고쳐둔 문제를 재발시킨 적이 있어서, 이번에는 층을 나누는 쪽을 택했습니다. 바꾼 것은 손끝이고 판단은 그대로 둔 셈입니다.
5. 제약 2. 배경 탭이 보이는 중이라고 답합니다
이게 여섯 개 중 가장 위험합니다. 틀린 답을 자신 있게 주기 때문인데요, 코드가 그 답을 믿고 다음 단계로 넘어갑니다.
웹 표준에는 지금 이 페이지가 화면에 보이는지 확인하는 신호가 있습니다. document.visibilityState와 document.hidden, 그리고 document.hasFocus()입니다. 보통은 배경 탭이면 숨김으로 나옵니다.
직접 확인 2. 명백히 배경에 있는 탭에 붙어서 세 신호를 한 번에 물었습니다. 대상 탭은 탭 목록에서 활성 여부가 거짓으로 나온 탭입니다.
| 신호 | 기대값 | 실측값 |
|---|---|---|
| 탭 목록의 활성 여부 | 거짓 | 거짓 |
document.visibilityState |
hidden | visible |
document.hidden |
참 | 거짓 |
document.hasFocus() |
거짓 | 참 |
셋 다 앞에 있다고 답했습니다. 눈으로는 전혀 다른 탭이 화면을 차지하고 있는데요, 코드가 물으면 자기가 보이는 중이라고 합니다.
결국 전면 여부를 판정할 때 쓸 수 있는 신호는 탭 목록이 알려주는 활성 여부 하나뿐이고, 웹 표준 쪽 신호 세 개는 Aside 브라우저 자동화에서 판정 근거로 쓰면 안 된다는 결론이 됩니다.
무인 실행에서 이게 왜 문제냐면, 되돌릴 수 없는 동작 앞에 두는 안전장치가 보통 이런 신호라서 그렇습니다. 지금 화면이 맞는지 확인하고 게시 버튼을 누르는 구조였다면, 확인은 통과하고 엉뚱한 탭에서 눌릴 수 있습니다.
6. 제약 3. 앞으로 끌어와도 앞으로 오지 않습니다
그럼 원하는 탭을 앞으로 끌어오면 되지 않을까 싶은데요, 그것도 안 됩니다.
직접 확인 3. 배경 탭에 붙어서 앞으로 가져오는 명령을 실행하고, 실행 전후로 탭 목록을 다시 읽었습니다.
| 항목 | 결과 |
|---|---|
| 명령 반환값 | 정상 종료, 반환값 없음 |
| 오류 발생 | 없음 |
| 대상 탭 활성 여부 (전) | 거짓 |
| 대상 탭 활성 여부 (후) | 거짓 |
| 화면의 활성 탭 목록 | 변화 없음 |
오류를 내지 않고 조용히 성공한 척합니다. 이게 제약 2와 겹치면 더 고약해집니다. 앞으로 끌어왔다고 믿고, 앞에 있냐고 물으니 그렇다고 답하니까, 코드 입장에서는 모든 조건이 충족된 상태가 됩니다.
필자가 정리한 결론은 이렇습니다. 전면을 확보할 수 있는 시점은 탭을 처음 만드는 순간 하나뿐이고, 그 뒤에 사용자가 다른 탭으로 옮기면 프로그램으로는 되돌릴 방법이 없다는 것인데요, 그 뒤로는 작업용 탭을 하나만 만들어 계속 재사용하고, 되돌릴 수 없는 동작 앞에서는 활성 여부를 바꾸려 하지 말고 기록만 남기고 진행하도록 바꿨습니다.
무인 실행일 때는 아예 전면 확보를 시도하지 않게 했습니다. 자동 실행이 사용자 화면을 가로채면 그게 더 큰 방해가 되기 때문입니다. 자동 실행 여부를 환경 변수로 넘겨두고, 그 값이 있으면 전면 확보 단계를 통째로 건너뜁니다.
7. 제약 4. 요소 번호는 명령이 끝나면 죽습니다
Aside의 편한 점 중 하나가 화면 요소마다 번호를 붙여준다는 것입니다. 복잡한 선택자를 쓰지 않고 번호로 지정할 수 있습니다. 그런데 이 번호에는 수명이 있습니다.
직접 확인 4. 같은 페이지를 열고 같은 번호를 두 번 썼습니다. 한 번은 번호를 딴 명령 안에서, 한 번은 명령을 새로 띄워서입니다.
| 상황 | 결과 |
|---|---|
| 같은 명령 안에서 사용 | 성공, 요소 글자를 정상으로 읽음 |
| 명령을 새로 띄워 사용 | 실패 |
실패했을 때 나온 문구를 그대로 옮기면, 요소가 제거됐거나 페이지가 바뀌었으니 스냅샷을 다시 찍으라는 안내가 나옵니다. 그런데 필자가 확인한 상황에서 페이지는 전혀 바뀌지 않았고 요소도 그 자리에 그대로 있었는데요, 달라진 것은 명령을 실행하는 프로세스 하나뿐이었습니다.
메시지를 그대로 믿으면 페이지 쪽을 붙잡고 시간을 씁니다. 필자도 처음에는 사이트가 화면을 다시 그리는 줄 알고 그쪽을 뒤졌습니다. 원인이 화면이 아니라 실행 단위에 있다는 것을 알기까지 한참이 걸렸습니다.
정리하면 이렇습니다. 여러 번에 걸쳐 진행되는 화면 조작은 번호로 잡으면 안 되고 선택자로 잡아야 합니다. 번호는 한 명령 안에서 스냅샷을 찍고 바로 쓰는 용도로만 씁니다.
여기에 하나 더 있습니다. 화면에 떠 있는 요소가 예상한 위치에 없을 수 있습니다. 어떤 화면은 대화상자를 열면 그 안이 아니라 문서 바깥쪽에 내용을 그립니다. 대화상자 안만 뒤지면 없다고 나오는데 실제로는 떠 있는 상태였습니다. 이 경우도 번호가 아니라 선택자로 문서 전체를 뒤져야 잡힙니다.
비슷한 계열로 화면 밖 내용이 아예 없는 경우도 있는데요, 목록을 조금씩 채워 넣는 화면은 화면 밖 항목을 문서에 두지 않기 때문에 한 번 읽고 없다고 판정하면 이미 올라가 있는 글도 없는 것으로 나옵니다. 판정 전에 스크롤을 넣는 동작을 따로 만든 이유가 이것입니다.
8. 제약 5. 파일을 썼는데 어디에도 없습니다
가장 오래 헤맨 것이 이겁니다. 결론부터 말하면 상대 경로의 기준점이 생각과 다릅니다.
직접 확인 5. 경로 세 개에 같은 내용을 쓰려고 했습니다.
| 경로 | 결과 |
|---|---|
/tmp 아래 절대 경로 |
거부, 프로젝트와 세션 범위를 벗어난다는 안내 |
./artifacts 아래 |
실패, 폴더가 없음 |
./ 바로 아래 |
성공 |
성공한 파일이 어디에 있는지가 핵심입니다. 명령을 실행한 폴더가 아니었습니다. 홈 아래 Aside 전용 폴더의 세션 폴더 안에 들어가 있었습니다. 그리고 그 세션 폴더는 명령을 실행할 때마다 새로 만들어집니다.
필자의 컴퓨터에서 오늘 하루치를 세어봤더니 세션 폴더가 342개 있었고, 그중 323개가 빈 폴더였습니다. 명령 한 번에 폴더 하나가 생기는 구조인 셈인데요, 상대 경로로 파일을 쓰면 그중 어느 하나에 들어가고 다음 명령은 다른 폴더를 봅니다. 방금 쓴 파일이 다음 단계에서 사라진 것처럼 보이는 이유가 여기에 있습니다.
필자는 이걸 모른 채 긴 작업을 한 번에 돌렸다가 결과물을 전부 잃은 적이 있습니다. 수십 쪽 분량을 모아 파일로 저장하는 코드였는데, 저장은 성공했다고 나오고 파일은 찾을 수 없었습니다. 다시 처음부터 넘기는 데 시간이 그대로 두 배로 들었습니다.
지금은 파일로 남기지 않고 표준 출력으로 찍어서 셸 쪽에서 받는 방식으로 바꿨는데요, 여러 명령에 걸쳐야 하는 데이터는 브라우저 안이 아니라 밖에서 들고 있는 편이 훨씬 안전하더군요.
9. 제약 6. 탭은 늘어나기만 합니다
주소를 지정해 브라우저를 여는 방식은 항상 새 탭을 만듭니다. 같은 주소여도 재사용하지 않습니다. 그리고 그렇게 만들어진 탭은 프로그램으로 닫히지 않았습니다.
직접 확인 6. 현재 열려 있는 탭을 세어봤습니다.
| 항목 | 값 |
|---|---|
| 전체 탭 수 | 25 |
| 활성으로 잡히는 탭 | 2 |
| 같은 주소가 중복으로 열린 건 | 1건, 탭 2개 |
하루 네 번 돌리는 자동화가 회차마다 탭을 하나씩 남기면 며칠 만에 눈에 띄게 쌓이는데요, 작업용 탭을 하나 만들어 식별자를 파일에 적어두고 다음 회차에서는 그 탭이 살아 있으면 새로 만들지 않고 그 안에서 주소만 바꾸도록 했습니다.
부수적으로 알게 된 것도 하나 있습니다. 사용자가 브라우저를 쓰는 중이면 활성 탭을 자동으로 잡는 방식이 엉뚱한 화면을 집는다는 것입니다. 자동화는 활성 탭을 잡지 말고 식별자로 특정 탭에 붙어야 하는데요, 다행히 화면 저장은 배경 탭에서도 정상으로 찍혔습니다.
10. 그래서 어떻게 짜야 할까요
여섯 가지를 겪고 나서 필자가 지키는 규칙은 네 줄로 줄었습니다. Aside 브라우저 자동화를 무인으로 돌릴 생각이라면 이 네 가지만 먼저 반영해도 대부분 막힙니다.
첫째, 전면 여부는 탭 목록의 활성 값만 믿습니다. 웹 표준 신호 세 개는 판정에서 뺍니다.
둘째, 여러 명령에 걸치는 조작은 번호가 아니라 선택자로 잡습니다. 번호는 한 명령 안에서만 씁니다.
셋째, 명령 사이로 넘겨야 하는 데이터는 브라우저 밖에서 들고 있습니다. 파일 저장에 의존하지 않습니다.
넷째, 탭은 하나만 만들어 재사용하고 식별자를 남깁니다. 활성 탭을 자동으로 잡지 않습니다.
여기에 운영 쪽 규칙을 하나 더 붙였습니다. 자동 실행과 사람이 쓰는 세션이 같은 브라우저를 동시에 건드리면 중복 실행 사고가 납니다. 필자는 사람이 작업 중일 때 잠금 파일을 두고, 그게 있으면 자동 실행이 스스로 멈추게 했습니다. 사람과 기계가 같은 창을 공유한다는 점이 이 도구의 장점이자 가장 조심할 부분인 것 같습니다.
11. 누구에게 맞고 누구에게는 굳이일까요
정리해 보면 대상이 꽤 분명하게 갈립니다.
| 상황 | 판단 |
|---|---|
| 로그인이 필요한 화면을 사람이 보며 조작 | 잘 맞습니다 |
| 공개 API가 없는 서비스를 다뤄야 함 | 잘 맞습니다 |
| 스케줄러로 무인 실행 | 가능하지만 이 글의 여섯 가지를 먼저 반영해야 합니다 |
| 로그인이 필요 없는 단순 페이지 수집 | 굳이 필요 없습니다 |
| 화면 없이 서버에서 돌려야 함 | 맞지 않습니다 |
마지막 줄이 중요한 것 같습니다. Aside 브라우저 자동화는 사람 컴퓨터에서 사람 계정으로 도는 것이 전제인데요, 무인으로 돌린다는 말이 서버에서 돌린다는 뜻은 아니고, 사람이 잠깐 자리를 비운 컴퓨터에서 돈다는 뜻에 가깝습니다. 이 차이를 헷갈리면 설계가 처음부터 어긋납니다.
필자는 개인 블로그 운영에 이걸 붙여서 쓰고 있는데요, 같은 계열로 명령줄 도구의 사용량을 확인하는 방법은 클로드 코드 사용량을 확인하는 세 가지 방법에 정리해 두었습니다. 설치와 요금은 공식 사이트에서 확인하시면 됩니다.
확인하지 못한 것도 적어둡니다. 이 글의 여섯 가지는 전부 macOS에서 잰 값이고, 다른 운영체제에서 같은지는 확인하지 못했습니다. 버전이 올라가면 달라질 수 있는 항목들이라 위에 적어둔 버전과 날짜를 같이 봐주시면 좋겠습니다. Aside 브라우저 자동화를 이미 쓰고 계신 분이라면 여섯 가지 중 몇 개나 겪으셨는지 궁금합니다.