로그인이 걸려 있는 화면을 AI에게 맡기려면, 매번 로그인부터 다시 시켜야 할까요?
이 글은 Aside 브라우저를 macOS에 설치해서 제 개인 블로그 화면을 실제로 열고 눌러 본 기록입니다. 공식 문서에 적힌 설명과 제가 화면에서 확인한 것을 나눠서 적었고, 중간에 막혔던 지점도 그대로 남겼습니다.
한 줄 요약 Aside 브라우저는 Chromium 기반의 macOS 전용 데스크톱 브라우저입니다. 평소 쓰던 로그인 세션을 그대로 물고 뜨기 때문에 로그인 뒤 화면을 바로 다룰 수 있고, 화면 요소마다 번호가 붙어서 CSS 선택자 없이도 “몇 번을 눌러”라고 지시할 수 있습니다. 조작 자체는 내장 AI 모델을 쓰지 않아 무료로 시작할 수 있습니다.
- 설치는 명령 한 줄이고 관리자 권한이 필요 없습니다
- 브라우저 앱과 CLI는 별개라서 둘 다 받아야 합니다
- macOS 전용이고 자료가 적어서, 막히면 공식 문서 말고는 참고할 데가 거의 없습니다
측정 환경은 macOS이고, CLI 버전 1.26.810.1915, 데몬 버전 1.26.826.1414 기준입니다. 확인한 날짜는 2026년 8월 27일입니다.
1. Aside 브라우저는 어떤 도구일까요
Aside 브라우저는 Chromium을 바탕으로 만든 독립 데스크톱 브라우저입니다. 크롬에 끼워 넣는 확장 프로그램이 아니라 별도로 설치하는 앱이고, 지금은 macOS만 지원합니다.
만든 곳은 Aside Computer Inc.이고, 공식 사이트에 Y Combinator 지원을 받았다는 배지가 붙어 있습니다. 사이트 첫 화면에 걸린 문장은 “The most intelligent AI assistant, but it’s a browser.”입니다. AI 비서를 브라우저 안에 넣은 것이 아니라, 브라우저 자체가 비서라는 쪽에 방점이 찍혀 있습니다.
여기서 처음 헷갈리는 지점이 하나 있습니다. 브라우저 본체와 명령줄 도구(CLI)가 서로 다른 설치물이라는 점입니다. 사이트에서 받는 것은 브라우저 앱이고, 터미널에서 쓰는 aside 명령은 따로 설치해야 합니다. 저는 CLI만 깔아 놓고 브라우저가 안 뜬다고 한참을 헤맸습니다.
자체 패스워드 매니저도 들어 있습니다. 공식 문서 설명으로는 저장된 자격증명이 자동입력 경로로만 들어가고 AI 쪽에는 노출되지 않는다고 합니다. 다만 이 부분은 문서를 읽은 것일 뿐, 제가 직접 검증하지는 못했습니다.
2. Aside 브라우저로 무엇을 할 수 있나요
공식 개발자 문서를 보면 쓰는 방법이 세 갈래로 나뉩니다. 목적이 다르니 골라 쓰면 됩니다.
| 방식 | 명령 | 어떤 때 쓰나 |
|---|---|---|
| CLI | aside "자연어 지시" |
할 일을 통째로 말로 맡길 때 |
| MCP | aside mcp |
코딩 도구가 브라우저를 직접 쓰게 할 때 |
| REPL | aside repl "코드" |
정확한 조작이 필요할 때 |
CLI는 가장 편한 대신 결과를 예측하기 어렵고, REPL은 손이 더 가는 대신 무엇이 실행될지가 분명합니다. REPL의 API는 Playwright와 생김새가 비슷해서, 그쪽을 만져 본 적이 있다면 눈에 익습니다. 다만 비슷하다는 말과 같다는 말은 다릅니다. 이 차이가 나중에 저를 한 번 붙잡았습니다.
MCP 방식은 코딩 도구 쪽에서 브라우저를 도구로 등록해 쓰는 경로입니다. 코드를 쓰다가 화면 확인이 필요할 때 도구를 갈아타지 않아도 된다는 것이 장점입니다. 도구 사이를 잇는 규약 자체가 궁금하다면 MCP 로드맵의 장기 실행 작업 정리를 같이 보셔도 좋습니다.
셋 중 무엇을 고를지는 결과를 얼마나 정확히 통제하고 싶은지로 갈립니다. 무엇을 눌러야 할지까지 이미 정해져 있다면 REPL이 맞고, 화면을 보고 판단하는 단계까지 맡기고 싶다면 CLI가 맞습니다. 저는 화면이 어떻게 생겼는지부터 확인하고 싶었기 때문에 REPL로 시작했습니다.
이 글에서 제가 쓴 것은 REPL 하나뿐입니다. 내장 AI 모델이 얼마나 똑똑한지는 다루지 않았습니다. 모델 성능은 따로 확인해 봐야 할 주제라서, 여기서는 “브라우저를 코드로 조작하는 도구”로만 놓고 봤습니다.
3. 설치부터 첫 명령까지 시작하는 법
CLI 설치는 명령 한 줄입니다.
curl -fsSL https://releases.aside.com/install.sh | bash설치가 끝나면 ~/.local/bin/aside 에 심링크가 생깁니다. 관리자 권한을 묻지 않으니 권한 문제로 막힐 일이 적습니다. 이 경로가 PATH 에 없다면 그 부분만 잡아 주면 됩니다.
브라우저 앱은 공식 사이트에서 따로 받습니다. 앞서 적었듯 CLI만 깔면 명령이 붙을 대상이 없습니다.
둘 다 준비됐으면 첫 명령을 넣어 봅니다. 페이지 하나를 여는 것으로 시작하면 충분합니다.
aside repl "const p = await openTab('https://내블로그주소/')"여기까지가 시작 지점입니다. 그다음부터는 연 페이지를 어떻게 읽고 어떻게 누를지의 문제인데, 이 부분이 Aside 브라우저에서 가장 다르게 느껴진 대목이었습니다.
코딩 도구 쪽에서 붙여 쓰고 싶다면 아래 명령이 진입점입니다.
aside mcp이 경로로 붙이면 코딩 도구가 브라우저를 자기 도구 목록에 놓고 씁니다. 다만 이 글에서 제가 확인한 것은 REPL 쪽이라, MCP 연결이 실제로 어떤 느낌인지는 따로 적지 않겠습니다.
4. 직접 확인 1: 로그인 상태가 그대로 유지됐습니다
첫 명령으로 제 블로그를 열었더니, 화면 위쪽에 검은 관리자 도구 표시줄이 그대로 떠 있었습니다. 로그인 절차를 한 번도 거치지 않았는데 관리자 메뉴가 보이고, 오른쪽에는 로그인된 계정 표시까지 있었습니다.
별것 아닌 화면 같지만, 자동화 브라우저를 만져 본 적이 있다면 이게 왜 눈에 띄는지 바로 아실 겁니다. 자동화용 브라우저는 보통 아무것도 없는 빈 프로필로 뜹니다. 그래서 로그인 뒤에 있는 화면을 다루려면 매번 로그인부터 다시 해야 하고, 2단계 인증이라도 걸려 있으면 그 지점에서 작업이 통째로 멈춥니다.
제가 자동화하고 싶은 화면은 대부분 로그인 뒤에 있습니다. 글 목록, 통계 화면, 설정 화면이 전부 그렇습니다. 로그인을 어떻게 넘길지가 매번 첫 번째 숙제였는데, Aside 브라우저는 그 숙제를 아예 없앴습니다. 평소 쓰던 브라우저가 곧 자동화 대상이니 로그인 상태도 그대로입니다.
이 차이는 편의의 문제만은 아닙니다. 로그인을 자동화하려면 아이디와 암호를 어딘가에 적어 두게 되고, 그 파일을 어떻게 보관할지가 새로운 숙제로 따라붙습니다. 세션이 만료되면 스크립트가 조용히 실패하기도 합니다. 로그인 단계를 아예 건드리지 않으면 그 숙제들이 통째로 사라집니다. 제가 이 도구를 계속 써 보기로 한 이유의 절반은 여기에 있습니다.
뒤집어 말하면, 로그인된 계정으로 무엇이든 할 수 있는 상태라는 뜻이기도 합니다. 결제 화면이나 계정 설정처럼 되돌리기 어려운 화면에서는 지시를 좁게 주는 편이 낫습니다. AI에게 일을 맡길 때 어디까지 열어 줄지의 문제는 AI에게 일을 맡길 때 드는 비용에서 따로 정리한 적이 있습니다.
5. 직접 확인 2: 화면 요소마다 번호가 붙습니다
두 번째로 확인한 것은 페이지를 읽는 방식입니다. snapshot(page, { interactive: true }) 를 부르면 클릭할 수 있는 요소마다 e1, e2 같은 참조 번호가 붙은 목록이 돌아옵니다.
여기서 한 걸음 더 가면 재미있어집니다. annotatedScreenshot(page) 를 부르면 그 번호가 화면 위에 빨간 박스로 그려진 이미지가 나옵니다. 목록과 그림이 같은 번호를 공유하는 셈입니다.
메뉴와 제목은 물론이고 본문 링크와 광고 영역까지 번호가 매겨졌습니다. 이게 왜 편하냐면, CSS 선택자를 몰라도 조작을 지시할 수 있기 때문입니다. 클래스 이름이 뭔지 개발자 도구를 열어 볼 필요 없이 “23번을 눌러”라고 말하면 됩니다.
사람이 화면을 읽는 방식과 도구가 화면을 읽는 방식이 여기서 겹칩니다. 저는 지금까지 개발자 도구를 열어 요소를 찍고 클래스 이름을 복사해 오는 과정을 당연하게 여겼는데, 그 과정이 통째로 빠지니 작업 순서가 단순해졌습니다. 화면을 한 장 받고, 누를 번호를 고르고, 그 번호를 넘기면 끝입니다.
주의할 점이 하나 있습니다. 번호는 그 시점의 화면에만 유효합니다. 페이지가 바뀌면 번호가 새로 매겨지므로, 조작을 한 번 할 때마다 목록을 다시 받아야 합니다. 이걸 잊으면 엉뚱한 자리를 누르게 됩니다. 저는 이 규칙을 아래 함정 목록의 다섯째 항목과 묶어서 기억하고 있습니다. 화면도 세션도 매번 새로 시작한다고 놓고 쓰면 헷갈릴 일이 줄어듭니다.
번호로 눌러 페이지를 옮겼습니다
목록에서 “AI & LLM” 메뉴가 e23 이었습니다. 그 번호를 그대로 눌러 봤습니다.
await p.locator('e23').click();
console.log(p.url());주소가 https://blog.wonizz.com/ 에서 https://blog.wonizz.com/category/ai-llm/ 로 바뀌었고, 페이지 제목도 AI & LLM Archives - WONIZZ.LOG 로 따라 바뀌었습니다. 선택자를 한 글자도 쓰지 않고 화면을 옮긴 것입니다.
이동한 뒤에 snapshot() 을 다시 부르면 diff 로 무엇이 달라졌는지만 볼 수도 있습니다. 화면 전체를 다시 읽지 않아도 되니 그만큼 가볍습니다.
6. 요금은 얼마이고 무료로 어디까지 쓸 수 있나요
요금제는 네 단계입니다. 아래는 2026년 8월 27일 기준 가격 페이지 내용입니다.
| 플랜 | 가격 | 들어 있는 것 |
|---|---|---|
| Free | $0 forever | 본인 구독 연결(BYO), 크레딧 한 달 500, routine 최대 3개, 패스워드 매니저, 개인화 메모리 |
| Pro | 한 달 $20 | Free의 3배 사용량, Ultrabrowse 심층 리서치, routine 무제한, 원격 제어(Channels), Cloud handoff |
| Max | 한 달 $200 | Pro의 40배 사용량, 얼리 액세스 |
| Enterprise | 문의 | 팀 단위 |
연간 결제를 고르면 20% 할인이 붙는다고 표기돼 있습니다.
여기서 꼭 짚고 넘어갈 것이 있습니다. REPL로 브라우저를 조작하는 동작 자체는 내장 AI 모델을 쓰지 않습니다. 그래서 크레딧과 무관합니다. 이 글에서 제가 한 작업, 그러니까 페이지 열기와 요소 목록 받기, 스크린샷 찍기, 클릭까지는 전부 무료 구간에서 돌아갔습니다.
Free 플랜에 적힌 BYO는 본인이 이미 갖고 있는 AI 구독을 연결해서 쓰는 방식을 말합니다. 이미 쓰는 구독이 있다면 그쪽을 물려서 시작할 수 있다는 뜻입니다. routine은 최대 3개까지 만들 수 있고, 패스워드 매니저와 개인화 메모리는 무료 구간에도 들어 있습니다.
크레딧이 깎이는 쪽은 자연어 지시를 모델이 해석해 주는 CLI 방식이나 심층 리서치 같은 기능입니다. 즉 “브라우저를 코드로 조작하는 도구”로만 쓸 생각이라면 돈을 내지 않고 끝까지 써 볼 수 있습니다. 저는 이 점이 진입 장벽을 크게 낮춘다고 봤습니다.
7. Playwright와 무엇이 다를까요
가장 자연스러운 비교 대상은 Playwright입니다. REPL API가 비슷하게 생겼으니 더 그렇습니다. 다만 두 도구가 서 있는 자리는 꽤 다릅니다.
| 항목 | Aside 브라우저 | Playwright |
|---|---|---|
| 로그인 상태 | 평소 쓰던 브라우저 세션을 그대로 씁니다 | 보통 빈 프로필로 시작해 로그인이 필요합니다 |
| 요소 지정 | 화면에 붙은 번호로 지정합니다 | CSS 선택자나 텍스트로 지정합니다 |
| 플랫폼 | macOS 전용입니다 | 여러 운영체제를 지원합니다 |
| 성숙도 | 신생 제품이라 자료가 적습니다 | 오래돼 자료가 많습니다 |
속도나 안정성 같은 수치는 제가 나란히 재보지 않았으므로 여기에 적지 않았습니다. 표에 적은 네 가지는 문서와 화면에서 확인한 범위입니다. 어느 쪽이 빠른지 궁금하다면 같은 작업을 양쪽으로 짜서 재보는 수밖에 없는데, 그건 이 글의 범위를 넘습니다.
특히 성숙도 항목은 실제로 체감했습니다. 막혔을 때 검색으로 답을 찾은 적이 한 번도 없었고, 바로 다음 장에 적은 함정 여섯 가지는 전부 제가 직접 부딪혀서 알아낸 것입니다.
정리하면 Playwright는 테스트 자동화를 위해 만들어진 도구이고, Aside 브라우저는 사람이 쓰던 브라우저를 AI가 이어받는 쪽에 가깝습니다. 반복 실행되는 테스트를 짠다면 여전히 Playwright 쪽이 맞습니다. 반대로 로그인 뒤 화면을 한두 번 다루는 일이라면 Aside 브라우저가 준비 시간을 크게 줄여 줍니다.
8. 막혔던 지점 6가지, 이건 안 됩니다
여기부터는 제가 실제로 부딪힌 것들입니다. 전부 화면에 에러가 떠서 알게 된 내용이고, 나열한 순서도 제가 부딪힌 순서 그대로입니다. 문서를 먼저 꼼꼼히 읽었다면 몇 개는 피했을 텐데, 저는 그러지 않았습니다.
첫째, Playwright 코드가 그대로 돌지 않습니다. 습관대로 page.waitForTimeout() 을 불렀더니 TypeError: p.waitForTimeout is not a function 이 떴습니다. API가 비슷하게 생겼을 뿐 같지는 않습니다. 대기 동작은 직접 만들어 써야 했습니다. 비슷한 문법을 보면 나머지도 같겠거니 하고 넘어가게 되는데, 그 가정이 여기서 깨집니다.
둘째, 프로젝트 폴더 밖으로 파일을 못 씁니다. 스크린샷을 다른 경로에 저장하려니 Error: Path escapes Project and session roots 가 나왔습니다. 브라우저가 임의 경로에 파일을 쓰지 못하게 막아 둔 것이라 취지는 납득이 되지만, 처음에는 그냥 막힌 것처럼 보입니다. 저장 경로를 프로젝트 안쪽으로 옮겨서 넘어갔습니다.
셋째, /tmp 에 저장하면 조용히 다른 곳으로 갑니다. 경고가 한 줄 뜨면서 파일이 세션 폴더 안으로 옮겨져 저장됩니다. 저는 그 경고를 놓쳤고, 지정한 경로에 파일이 없어서 한참을 찾아다녔습니다. 실패로 끝났으면 차라리 빨리 알았을 텐데 저장은 성공했다고 나오니 더 헷갈렸습니다. 결국 세션 폴더 안에서 파일을 찾아내고 나서야 무슨 일이 벌어진 건지 알았습니다. 그 뒤로는 저장 경로를 아예 프로젝트 폴더 안으로 정해 두고 씁니다.
넷째, 폴더를 미리 만들어 두지 않으면 저장이 실패합니다. ./artifacts/ 같은 경로에 쓰려면 그 폴더가 먼저 있어야 합니다. 자동으로 만들어 주지 않습니다. 셋째 항목과 합쳐 놓고 보면 규칙은 하나입니다. 파일을 쓰기 전에 프로젝트 안쪽에 폴더를 만들어 두고, 저장 경로를 그 폴더로 고정해 두면 셋째와 넷째가 같이 해결됩니다. 저는 이 두 가지를 각각 다른 문제로 착각해서 두 번 헤맸습니다.
다섯째, 명령을 한 번 실행할 때마다 세션이 새로 시작됩니다. 앞 명령에서 열어 둔 탭이 다음 명령에는 남아 있지 않습니다. 그래서 여러 단계짜리 작업은 한 번의 호출 안에 몰아 넣거나 대화형 모드로 붙어서 해야 합니다. 저는 이걸 모르고 명령을 잘게 쪼갰다가 매번 빈 화면을 받았습니다.
여섯째, 호출 한 번에 4초에서 14초가 걸립니다. 가볍게 여러 번 부르는 방식과는 맞지 않습니다. 한 번 부를 때 할 일을 최대한 담아야 합니다. 다섯째 항목과 겹쳐서, 결국 “한 호출에 다 넣는다”가 기본 전략이 됩니다. 화면을 열고 요소 목록을 받고 하나를 누른 다음 결과 주소까지 찍는 흐름을 한 덩어리로 묶어 두면, 기다리는 시간이 한 번으로 끝납니다. 반대로 한 줄씩 나눠 실행하면 매번 처음부터 다시 시작하면서 기다리는 시간만 늘어납니다.
여섯 가지를 한 줄로 줄이면 이렇습니다. API는 비슷할 뿐 같지 않고, 파일은 프로젝트 안에만 쓸 수 있으며, 세션은 매번 새로 시작하고, 호출은 느립니다. 이 네 문장을 먼저 알고 시작했다면 제가 쓴 시간의 절반은 아꼈을 것입니다.
여기에 하나 덧붙이면, 도구가 알려 주는 실패 메시지를 끝까지 읽어야 한다는 점입니다. 셋째 항목은 경고가 분명히 떠 있었는데 제가 넘겼습니다. 자동화 도구의 완료 보고를 그대로 믿었다가 놓친 사례는 AI 완료 보고를 검증하는 법에도 적어 뒀습니다.
9. 누구에게 맞고 누구에게는 굳이일까요
먼저 맞지 않는 쪽부터 적겠습니다.
윈도우나 리눅스를 쓴다면 지금은 선택지가 아닙니다. macOS 전용입니다. 반복 실행되는 테스트 코드를 짜야 한다면 이미 검증된 도구가 있으니 굳이 갈아탈 이유가 약합니다. 자료가 많이 필요한 사람에게도 아직 이릅니다. 검색해도 후기가 거의 없어서, 제가 막혔을 때 참고할 데는 공식 문서뿐이었습니다.
반대로 잘 맞는 쪽은 이렇습니다. 로그인 뒤에 있는 화면을 다뤄야 하는 사람, 특히 개인 블로그나 각종 관리 화면처럼 매번 로그인이 걸림돌이 되던 작업을 자동화하려는 사람입니다. 준비 과정이 거의 없다시피 하니 시도해 보는 비용이 낮습니다. 코드 없이 자연어로 맡겨 보고 싶은 사람에게도 CLI 방식이 있습니다.
써 볼지 말지 정하는 가장 빠른 방법은 이렇습니다. CLI를 깔고 브라우저 앱을 받은 다음, 평소 로그인해 두고 쓰는 화면을 하나 열어 보면 됩니다. 로그인이 유지된 채로 뜨는지만 확인하면 이 도구가 나에게 무슨 값을 하는지 그 자리에서 판단이 섭니다. 여기까지는 돈이 들지 않고, 열어 보는 데 몇 분이면 됩니다. 유지가 안 되는 화면이라면 그 뒤 과정도 볼 것 없이 접으면 됩니다.
저는 당분간 Aside 브라우저를 블로그 화면 확인용으로 계속 써 볼 생각입니다. 발행한 글이 화면에서 제대로 보이는지 눈으로 확인하는 일은 지금까지 손으로 해 왔는데, 로그인이 유지된다는 점 하나만으로도 그 작업이 훨씬 간단해졌습니다. 도구를 하나 더 얹는 것이 늘 이득은 아니라는 이야기는 AI 자동화의 완료 조건에서 다룬 적이 있는데, 이번에는 얹을 만하다고 판단했습니다.
마지막으로 이 글의 한계를 분명히 해 두겠습니다. 저는 REPL 조작만 썼고 내장 AI 모델의 성능은 재보지 않았습니다. 패스워드 매니저의 안전성도 문서 설명을 읽었을 뿐 검증하지 못했습니다. 성능 비교 수치도 이 글에는 없습니다. 그 세 가지가 궁금하시다면 이 글로는 답이 되지 않습니다.