앱을 내는 일은 코드를 짜는 일보다 콘솔을 누르는 일이 더 길었다

심심해서 앱을 하나 만들어 iOS와 Android에 출시했습니다. 개발과 빌드는 Claude Code와 터미널 안에서 거의 다 끝났습니다. 테스트를 돌리고, EAS로 빌드를 만들고, 업로드까지 명령어로 처리했습니다.

하지만 꼭 제 손이 거쳐야 하는 부분이 있었습니다. App Store Connect와 Google Play Console입니다. 변경 사항 문구를 채우고, 빌드를 골라 붙이고, 심사에 제출하는 일은 생각보다 굉장히 귀찮은 작업이었습니다. 공식 API가 열려 있는 영역도 있지만, 키를 발급하고 권한을 나누고 연결하는 수고가 다시 필요합니다.

또한 개발자 프로그램 사용권 계약 동의, Play Console의 앱 콘텐츠 설문(데이터 보안, 광고 ID, 콘텐츠 등급), 스토어 등록정보와 테스트 트랙 같은 초기 설정은 용어도 낯설고 하나하나 AI한테 물어보며 진행해야 했습니다.

이 글은 그 귀찮음을 해결해준 Aside 브라우저 이야기입니다. 사용법, 제가 실제로 어떻게 썼는지, 좋았던 점과 조심해야 할 점, 그리고 앞으로 어떻게 활용하면 좋을지까지 정리해보았습니다.

Aside 브라우저는 무엇인가

Aside는 AI 에이전트가 들어 있는 브라우저입니다. 핵심은 제가 이미 로그인해 둔 사이트의 세션과 쿠키를 그대로 이용해서 일을 해 준다는 점입니다.

제어하는 방식은 크게 두 가지입니다.

• aside exec: 작업을 통째로 에이전트에게 위임합니다. 서브에이전트를 하나 띄우는 감각에 가깝고, 대부분의 일은 이 방식으로 충분합니다.
• aside repl: Playwright와 호환되는 JS REPL입니다. 스크린샷과 DOM을 직접 보면서 제어해야 할 때 씁니다. 심부름을 맡기는 exec이 대리인이라면, repl은 제가 운전대를 직접 잡는 수동 모드입니다.

그 밖에도 사용자의 맥락을 정리해 두는 메모리(aside memory)와, 다른 기기에서 돌아가는 Aside를 원격으로 제어하는 기능이 있습니다.

Aside는 어떻게 움직이나

페이지를 읽고 조작하는 방식

핵심은 화면을 두 가지 형태로 본다는 점입니다. 건물의 층별 안내도와 실제 사진을 같이 들고 다니는 것과 비슷합니다. 안내도(접근성 트리)로 호실 번호를 찾고, 헷갈리면 사진(스크린샷)으로 눈으로 확인합니다.

• 접근성 트리 스냅샷: 페이지를 요소마다 가상의 번호표(e12 같은 ref)가 붙은 텍스트 트리로 읽습니다. 번호표는 실제 DOM 속성이 아니라 스냅샷마다 새로 부여되는 가상 식별자라서, 화면이 바뀌면 이전 번호표는 무효가 됩니다. 은행 대기번호표가 그 순번에서만 유효한 것과 같습니다. 화면 밖에 있는 요소와 iframe 안의 내용도 한 번에 담기고, 동작 뒤에는 바뀐 부분만 diff로 돌려줍니다.
• 스크린샷: 구조만으로 판단이 어려울 때는 번호표와 상자를 겹쳐 그린 스크린샷(annotatedScreenshot)으로 눈으로 확인합니다.

이 둘을 Playwright와 호환되는 API로 조작합니다. aside repl은 샌드박스된 JavaScript 환경에서 page, snapshot() 같은 전역으로 탭을 열고 클릭하고 입력하는 구조입니다. Slack, Gmail, Notion처럼 자주 쓰는 사이트는 전용 스킬이 내장되어 있어서 REPL에서 바로 쓸 수 있습니다. 실행한 코드와 판단 과정이 로그로 그대로 남기 때문에, 결과가 이상할 때 어디서 그렇게 판단했는지 되짚어볼 수 있다는 점도 좋았습니다.

그리고 aside mcp로 Aside 자체를 MCP 서버로 쓸 수도 있습니다. MCP가 없는 사이트를 Aside로 조작하고, 그 Aside를 다시 MCP로 노출하는 셈입니다.

Chrome 확장 방식은 어떤 구조인가

Chrome 확장으로 브라우저를 제어하는 방식(ex. Claude in Chrome)도 같은 목적의 도구라서 자주 비교됩니다.

Chrome 확장은 이미 실행 중인 Chrome 안에서 도는 프로그램입니다. 보통 백그라운드에서 도는 서비스 워커와 각 페이지에 주입되는 콘텐츠 스크립트가, Chrome이 확장에 열어 준 API(탭, 스크립팅, 디버깅 등)로 페이지를 읽고 조작합니다. 바깥의 에이전트와는 네이티브 메시징 같은 연결 통로로 통신하고, 에이전트에게는 탐색, 페이지 읽기, 입력, 스크린샷, 콘솔 로그와 네트워크 요청 읽기 같은 도구 호출의 형태로 기능이 노출됩니다.

여기서 구조상의 특징이 생깁니다.

• 확장은 Chrome이 허락한 범위 안에서만 움직입니다. 사이트별 권한을 사용자가 확장에서 승인해야 하고, 브라우저 자체의 UI는 제어할 수 없습니다. 실제로 도구 안내에도 브라우저 대화상자(alert 등)가 뜨면 이후 명령을 받을 수 없으니 피하라고 적혀 있습니다.
• 대신 사용자가 평소 쓰는 Chrome 프로필을 그대로 쓰니 로그인 상태와 다른 확장이 모두 그대로입니다.
• 판단은 도구를 호출하는 쪽(Claude 등)이 합니다. 한 번 호출하고, 결과를 받고, 다음 호출을 정하는 반복입니다.

기술적으로 무엇이 다른가

핵심 차이는 에이전트가 브라우저를 제어하는 층위입니다. Chrome 확장자는 결국 AI에게 눈을 붙여준 것과 같다면, Aside는 친구를 한 명 더 붙여준 것과 같다고 생각합니다.

그래서 언제 무엇을 쓰나

• 시키고 기다려도 되는 긴 작업, 여러 작업의 동시 진행, 호출하는 쪽의 컨텍스트 절약이 중요하면 Aside가 맞았습니다.
• 평소 쓰는 Chrome 상태에서 바로 이어서 보고 싶을 때, 페이지의 콘솔과 네트워크까지 들여다보며 디버깅할 때, 새 브라우저에 로그인하기 번거로울 때는 Chrome 확장 방식이 자연스럽습니다.

제가 실제로 쓴 방식

1. 읽기 전용 상태 점검

출시 후 가장 먼저 시킨 일은 상태 확인이었습니다. Play Console에서 비공개 테스트가 어떤 상태인지, 참여를 선택한 테스터는 몇 명인지, 국가는 어디로 설정되어 있는지를 한 번에 정리해 달라고 했습니다. 제가 직접 열면 메뉴를 몇 번 오가야 알 수 있는 정보들입니다. 결과는 "막혀 있는 문제 없음, 테스터 12명, 국가 1개"처럼 요약된 보고로 돌아왔습니다.

2. 두 콘솔을 동시에

App Store Connect 작업과 Play Console 작업을 별도 세션으로 동시에 돌렸습니다. Play Console에서는 앱 번들을 올리고, 출시 노트를 한국어와 영어로 입력하고, 검토를 위해 전송하는 일까지 진행했습니다. 사람이 하나씩 순서대로 하면 한참 걸릴 일을 병렬로 맡길 수 있다는 점이 가장 와닿았습니다.

3. 복잡하고 낯선 설정도 한결 쉬워졌다

처음 한 번만 하는 복잡한 일들도 이 조합으로 훨씬 수월해졌습니다. Play Console의 앱 콘텐츠 설문과 초기 설정과 개발자 프로그램 사용권 계약 동의를 Aside가 직접 처리했습니다. 이어지는 클릭 위주의 작업, 항목을 클릭하면 새로 생기는 세부 항목들을 그때마다 AI에게 물어봐야 하는 귀찮음이 줄어들었습니다.

좋았던 점

MCP나 API가 없어도 된다

가장 큰 장점입니다. 사람이 쓰는 화면이 곧 인터페이스가 됩니다. 연동을 위해 키를 발급하고 권한 범위를 설계하고 서버를 붙이는 수고 없이, 이미 열려 있는 콘솔을 그대로 일터로 쓸 수 있었습니다.

로그인된 세션을 그대로 쓴다

인증 정보를 에이전트나 설정 파일에 넘길 필요가 없었습니다. 제가 이미 로그인한 브라우저의 세션을 쓰기 때문입니다. 비밀번호를 적은 쪽지를 건네는 대신, 이미 출입증을 찍고 들어간 건물 안에서 일을 시키는 셈입니다. 다만 이것은 장점이면서 동시에 책임이기도 합니다. 아래에서 다시 이야기하겠습니다.

화면이 바뀌어도 버틴다

정해진 선택자를 따라가는 자동화 스크립트와 달리, 에이전트는 화면을 보고 이해하면서 움직입니다. 지도 좌표만 외운 사람은 가게가 옮기면 헤매지만, 간판을 읽는 사람은 길이 바뀌어도 찾아갑니다. 콘솔 UI는 메뉴 이름과 배치가 자주 바뀌는 편인데, 제가 겪은 범위에서는 흐름이 끊기지 않고 이어졌습니다.

결과만 받아 본다

exec로 위임하면 중간 과정을 일일이 보지 않고 최종 보고만 받아 볼 수 있어서 제 컨텍스트가 덜 소모됩니다. 필요하면 세션을 이어서 질문하거나 방향을 바꿀 수 있습니다.

조심해야 할 점

보고서를 그대로 믿지 않기

한 번은 에이전트가 새 버전에 iPad 13형과 Apple Watch 스크린샷 탭이 생겼고 필수일 수 있다고 보고했습니다. 그런데 제 빌드는 iPhone 전용이라 실제로는 필수가 아닐 가능성이 컸고, 실제 제출 단계에서도 막지 않았습니다. 에이전트의 보고는 "확인해 볼 단서"로 받아들이고, 중요한 내용은 한 번 더 검증하는 습관이 필요합니다.

2단계 인증은 사람의 몫

Apple 계정의 세션이 만료되어 로그인 화면에서 막힌 적이 있습니다. 이때 에이전트가 로그인을 반복 시도하면 계정이 잠길 수 있어서 작업을 바로 중단시켰습니다. 2단계 인증은 끌 수 없고, 비밀번호와 인증 코드를 에이전트에 넘기는 것도 좋은 생각이 아닙니다. 대신 브라우저를 신뢰 기기로 등록하거나 패스키를 쓰면 번거로움을 줄일 수 있습니다. 로그인은 사람이 한 번 해 주고, 그 뒤부터를 맡기는 구조가 맞다고 느꼈습니다.

권한은 말로 못 박아야 한다

에이전트는 제가 쓰는 계정의 권한을 그대로 갖습니다. 집 열쇠를 맡긴 가사도우미에게 "안방 서랍은 열지 마세요"라고 미리 말해 두는 것과 같습니다. 그래서 "읽기 전용", "제출 직전에서 정지", "이 항목은 건드리지 마" 같은 제약을 프롬프트에 명시하는 일이 곧 안전장치였습니다. 결제나 법적 동의, 되돌리기 어려운 제출은 어디까지 허락할지 제가 먼저 정해 주어야 합니다.

사소한 제약들

브라우저의 파일 접근 제약 때문에 작업 공간 밖의 파일은 바로 올릴 수 없어서, 앱 번들을 임시 폴더에 복사해서 올리는 식의 우회가 필요했습니다. 또 클릭 몇 번이면 끝나는 단순한 일은 직접 하는 쪽이 더 빠를 수 있습니다.

이렇게 활용하면 좋을 것 같습니다

• 릴리스 체크리스트: 배포 직후 심사 상태, 테스트 인원, 경고 항목을 읽기 전용으로 점검하는 루틴
• 번역과 문구 입력: 같은 변경 사항 문구를 여러 언어 칸에 채워 넣는 반복 작업
• MCP가 없는 SaaS 관리 화면: 도메인과 DNS, 클라우드 콘솔, 광고나 분석 대시보드 같은 곳의 상태 확인과 설정 변경
• 증빙 수집: 작업을 마친 화면을 스크린샷으로 남기게 해서 기록으로 쓰기
• 처음 한 번뿐인 복잡한 설정: 계약 동의나 스토어 초기 설정처럼 자주 하지 않아서 익숙해질 일이 없는 작업
• 승인 지점을 끼운 자동화: 준비는 에이전트가, 최종 제출은 사람이 하는 구조

마치며

이번 출시에서 가장 와닿았던 것은 속도보다 역할 분담이었습니다. 코드와 빌드는 Claude Code가, 사람 손이 필요했던 콘솔 작업은 Aside가, 그리고 어디까지 해도 되는지를 정하는 일과 마지막 판단은 제가 맡았습니다.

MCP가 모든 서비스에 열려 있지 않은 이상, 화면을 보고 움직이는 에이전트는 꽤 오래 필요한 도구일 것 같습니다.

그리고 개발자로서 한 가지 더 느낀 게 있습니다. 이제 웹의 손님은 사람뿐만이 아니라 AI 에이전트도 된다는 점입니다. 이 글에서 보듯 에이전트는 페이지를 접근성 트리로 읽고 움직입니다.

가게로 치면 간판과 안내판을 읽으며 찾아오는 손님이 생긴 것이라서, 간판이 없거나 문이 숨겨져 있으면 들어오기 어렵습니다. 버튼에 의미 있는 이름을 붙이고, 시맨틱 HTML과 접근성 속성을 제대로 쓰고, 화면의 상태와 결과를 텍스트로 분명히 보여 주는 것.

원래 스크린 리더를 쓰는 사람을 위한 접근성 작업이었는데, 이제는 그것이 AI가 쉽게 접근하고, 이해하고, 제어할 수 있는 웹을 만드는 일과 거의 같아졌습니다. 사람에게 친절한 웹이 AI에게도 친절한 웹이라는 것이 이번에 여러 콘솔을 오가며 느낀 점입니다.