AI 브라우저 다 써봤는데 결국 여기로 갈아탑니다 | Aside Browser 개발자라면 꼭 쓰세요

URL: https://www.youtube.com/watch?v=OXg-0BXf_Yk
날짜: 2026-08-15
채널: 개발동생
영상 길이: 14분 27초
구분: YouTube 심층 다이제스트

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==개발자에게 좋은 AI 브라우저는 페이지를 요약하는 브라우저가 아니라, 로그인 세션과 브라우저 상태를 활용해 실제 업무를 수행하고 코딩 에이전트의 시각적 검증까지 연결하는 브라우저 에이전트다.==

• 개발동생은 Arc, Zen, Dia 등 여러 브라우저를 사용하다가 Aside를 메인 브라우저로 선택했다.
• Aside는 Chromium 기반 브라우저 안에 페이지 질문·요약, 장기 작업, 메모리, 루틴, 브라우저 에이전트를 통합한다.
• 쿠팡 상품 검색과 주문처럼 로그인·확장 프로그램·세션이 필요한 작업을 브라우저의 실제 상태 위에서 수행할 수 있다.
• Aside CLI를 Claude Code나 Codex에 연결하면 Playwright MCP 없이도 로그인된 브라우저를 이용한 시각적 테스트를 수행할 수 있다.
• Playwright MCP와 비교한 실험에서 도구 정의와 고정 컨텍스트가 작아 평균 2.3배, 특정 페이지에서는 4.2배 적은 토큰을 사용했다.
• 다만 로그인 세션과 쿠키를 에이전트에게 넘기는 구조는 프롬프트 인젝션에 노출될 수 있으므로, 권한 모드와 프로필을 분리해 사용해야 한다.

Aside의 핵심 가치는 AI를 브라우저 옆에 붙인 데 있지 않다. 브라우저가 가진 로그인 상태·쿠키·확장 프로그램·히스토리와 에이전트의 실행 능력을 하나의 작업 환경으로 결합한 데 있다. 그래서 일반 사용자는 반복적인 웹 업무를 맡길 수 있고, 개발자는 코딩 에이전트에게 실제 로그인 화면을 보여주며 검증을 자동화할 수 있다. 동시에 이 강력한 연결은 보안 위험도 키우므로, ‘무엇을 할 수 있는가’와 ‘무엇을 허용할 것인가’를 함께 설계해야 한다.

1. 여러 AI 브라우저를 거쳐 Aside로 이동한 이유

여러 AI 브라우저가 등장했지만, 발표자가 Aside를 선택한 이유는 대화형 보조 기능보다 브라우저 상태를 실제 작업에 사용할 수 있다는 점에 있다.

1.1. Arc·Zen·Dia에서 Aside로

1. 브라우저를 계속 갈아탄 사용 경험

   1. 발표자는 과거에 Arc를 사용하다가 Firefox 기반의 Zen으로 옮겼다.
   2. Arc를 만든 회사가 Dia를 출시한 뒤에는 Dia를 주로 AI 브라우저로 사용했다.
   3. 그러나 이번에는 기존 브라우저를 모두 버리고 Aside로 옮겼다고 말한다.

2. AI 브라우저 시장의 경쟁

   1. OpenAI의 Atlas, Perplexity의 Comet, Dia 등 AI 브라우저가 이미 많이 등장했다.
   2. 발표자는 Aside가 기존 AI 브라우저와는 차원이 다르다고 평가한다.
   3. Aside는 Y Combinator 배치 스타트업이며, 창립자 세 명이 모두 한국인이라는 점도 소개된다.

1.2. Chromium 기반의 브라우저 에이전트

1. 브라우저 안에 에이전트가 들어 있다

   1. Aside는 Chromium 기반 브라우저다.
   2. 단순히 현재 페이지를 읽어주는 AI 사이드바가 아니라, 브라우저를 직접 조작하는 에이전트 브라우저로 설명된다.
   3. 브라우저에서 사람이 할 수 있는 작업을 에이전트가 대신 수행하는 것이 기본 방향이다.

2. 개발자를 주요 사용자로 보는 이유

   1. 개발자는 대시보드, 스테이징 서버, 관리자 페이지처럼 로그인해야 접근할 수 있는 화면을 자주 검증한다.
   2. 기존 자동화 도구는 새 브라우저 프로필에서 실행되는 경우가 많아 로그인 세션을 유지하기 어렵다.
   3. Aside는 실제 브라우저 프로필과 세션을 유지하면서 이 문제를 줄인다.

2. 일반 사용자가 활용하는 Aside의 기능

Aside는 우측 탭 관리, 페이지 문답, 좌측 장기 작업, 메모리와 루틴을 하나의 브라우저 경험으로 묶는다.

2.1. 페이지를 읽고 질문하는 사이드바

1. 현재 탭을 대상으로 한 작업

   1. 우측 사이드바에는 현재 열려 있는 브라우저 탭이 표시된다.
   2. 해당 페이지에 대해 질문하거나 요약을 요청할 수 있다.
   3. 유튜브 영상처럼 긴 콘텐츠도 페이지 안에서 요약을 요청하는 흐름이 가능하다.

2. 연결한 모델을 활용하는 구조

   1. Aside 안에는 LLM 모델을 연결해 사용할 수 있다.
   2. 우측의 현재 페이지 분석과 좌측의 장기 작업·채팅이 서로 다른 용도로 사용된다.
   3. 브라우저 안에서 읽기·질문·행동을 자연스럽게 이어갈 수 있다는 점이 기존 AI 검색 사이드바와 다르다.

2.2. 쿠팡 주문으로 보여준 브라우저 에이전트

1. 자연어로 장기 작업을 시작한다

   1. 발표자는 Aside에게 쿠팡에서 클렌징 워터를 하나 주문해 보자고 요청했다.
   2. Aside는 쿠팡 사이트를 열고 ‘클렌징 워터’를 검색했다.
   3. 검색 결과에서 랭킹 1위로 표시된 라운드랩 독 클렌징 워터를 선택해 주문 흐름으로 들어갔다.

2. 로그인과 확장 프로그램을 작업 과정에 포함한다

   1. 로그인 단계에서 발표자는 아직 로그인하지 않은 상태였다.
   2. Aside는 발표자가 사용하는 Bitwarden 확장 프로그램을 열어 계정 정보를 찾았다.
   3. 아이디와 비밀번호를 입력해 로그인하는 과정까지 진행했다.

3. 주문 완료 직전까지 이어지는 자동화

   1. 배송지 정보를 입력하고 결제 비밀번호 입력창까지 띄웠다.
   2. 결제 비밀번호까지 패스워드 매니저에 저장해 두었다면 결제도 진행할 수 있는 흐름이라고 설명한다.
   3. 발표자는 실제로 다음 날 상품을 배송받았다고 말하며, 단순 데모가 아니라 실제 웹 업무에 가까운 자동화임을 강조한다.

2.3. 메모리와 루틴

1. 이전 작업을 기억하는 메모리

   1. 브라우저 에이전트와 진행한 채팅 내용이나 작업 히스토리를 기록할 수 있다.
   2. 다음 작업에서 과거의 실수를 반복하지 않도록 기록을 활용해 개선할 수 있다.
   3. 이 기능은 일회성 페이지 요약보다 반복 업무 자동화에 더 가깝다.

2. 정해진 시간에 반복하는 루틴

   1. 특정 루틴을 미리 추가해 둘 수 있다.
   2. 지정된 시간에 작업이 자동으로 실행되도록 만들 수 있다.
   3. 메모리와 루틴을 합치면 브라우저가 개인 업무 운영 환경으로 확장된다.

3. 개발자에게 중요한 브라우저 에이전트 기능

Aside의 가장 큰 차별점은 브라우저 UI에 AI를 붙이는 데서 끝나지 않고, 코딩 에이전트가 브라우저를 조작할 수 있도록 연결한다는 점이다.

3.1. Playwright MCP 대신 Aside를 사용하게 된 이유

1. 기존 브라우저 검증 패턴

   1. 시각적 브라우저 테스트를 에이전트에게 맡기려면 Playwright MCP나 브라우저 자동화 CLI를 사용하는 경우가 많다.
   2. 이런 도구는 페이지를 열고 클릭·입력·스크린샷을 수행하는 기능을 제공한다.
   3. 하지만 별도의 깨끗한 브라우저 프로필을 사용하면 로그인 세션과 쿠키가 유지되지 않는 문제가 생긴다.

2. Aside의 Developer 기능

   1. Aside에는 개발자용 기능이 포함되어 있다.
   2. Aside CLI를 PC에 설치하고, Claude Code나 Codex에서 Aside 브라우저를 조작할 수 있다.
   3. 코딩 에이전트가 Aside 브라우저를 사용하면 실제 로그인 상태가 필요한 화면의 시각적 테스트도 수행할 수 있다.

3.2. Aside Exec과 Aside REPL

1. Aside Exec

   1. Aside Exec은 Aside 브라우저 에이전트를 호출하는 기능이다.
   2. 에이전트가 로그인 계정, 확장 프로그램, 방문 기록 등 브라우저의 상태를 활용해 실제 작업을 수행한다.
   3. 자연어로 브라우저 작업을 맡기거나, 코딩 에이전트가 브라우저 검증 작업을 요청할 때 사용하는 층이다.

2. Aside REPL

   1. Aside REPL은 JavaScript 코드를 실행하는 방식이다.
   2. 화면을 검증하고, 스크린샷을 찍고, 결과물을 다운로드하는 절차를 코드로 표현할 수 있다.
   3. 자유로운 에이전트 작업이 필요한 경우에는 Exec을, 반복적이고 명시적인 절차가 필요한 경우에는 REPL을 사용하는 구분으로 이해할 수 있다.

3. 코딩 에이전트와의 연결

   1. Aside CLI를 먼저 설치한다.
   2. Claude Code나 Codex 등 사용하는 코딩 에이전트에 Aside 스킬 또는 MCP를 설치한다.
   3. 이후 코딩 에이전트가 구현한 결과를 Aside 브라우저에서 열고, 로그인된 상태의 실제 화면을 확인하게 만들 수 있다.

4. 토큰 효율 비교: 도구를 많이 노출하지 않는 설계

발표자는 Playwright MCP와 Aside를 같은 사이트에 적용해 페이지 읽기 작업을 비교했다. 수치는 공식 벤치마크라기보다 영상에서 소개한 개인 실험 결과로 이해해야 한다.

4.1. Playwright MCP의 고정 비용

1. 많은 도구 정의

   1. Playwright MCP는 도구만 약 24개가 노출된다.
   2. 이 도구들의 사용법과 파라미터를 설명하는 컨텍스트가 약 18,000자 이상 들어간다.
   3. 실제 페이지를 읽기 전에 이미 상당한 고정 컨텍스트 비용이 발생한다.

2. 에이전트가 선택해야 할 표면적

   1. 도구가 많으면 모델이 선택할 수 있는 행동의 표면적도 커진다.
   2. 단순히 페이지를 읽는 작업에도 클릭·입력·탭·스크린샷 등 여러 도구 정의가 함께 전달될 수 있다.
   3. 도구를 전부 노출하는 구조는 범용적이지만 토큰과 선택 비용을 늘린다.

4.2. Aside의 단일 스킬 구조와 실험 결과

1. 작은 진입점

   1. Aside는 스킬 하나를 통해 브라우저 작업을 수행한다.
   2. 스킬 안의 도구 정의는 5,000자 미만으로 구성되어 있다고 소개된다.
   3. 실제 세부 브라우저 조작은 에이전트 내부에서 처리하고, 상위 코딩 에이전트에는 작은 인터페이스만 노출하는 구조다.

2. 다섯 페이지 비교

   1. GitHub, Hacker News, MDN, Wikipedia, Tailwind의 다섯 페이지를 같은 방식으로 읽게 했다.
   2. 전체 평균에서 Aside가 Playwright보다 약 2.3배 적은 토큰을 사용했다.
   3. 특정 페이지에서는 약 4.2배 적은 토큰을 사용하는 경우도 있었다.
   4. 발표자는 토큰 절약뿐 아니라 실행 속도도 Aside가 빨랐다고 평가한다.

3. 설계상의 시사점

   1. MCP 도구를 무조건 많이 노출하는 것보다, 상위 에이전트가 사용하는 인터페이스를 작게 만드는 편이 효율적일 수 있다.
   2. 브라우저 내부의 복잡한 조작을 브라우저 에이전트에 맡기면 코딩 에이전트의 컨텍스트가 가벼워진다.
   3. 따라서 Aside의 장점은 단순한 브라우저 성능이 아니라 에이전트 간 역할 분리와 컨텍스트 설계에도 있다.

5. 가장 결정적인 이유: 로그인 세션과 브라우저 프로필

발표자가 Aside로 옮긴 결정적인 이유는 토큰 효율보다 로그인 세션을 유지할 수 있다는 점이었다.

5.1. 깨끗한 자동화 브라우저의 한계

1. 초기화된 프로필 문제

   1. Playwright MCP나 일부 코딩 에이전트의 Chrome 확장은 완전히 초기화된 브라우저 프로필을 사용하는 경우가 많다.
   2. 이런 환경에서는 기존 로그인 상태나 쿠키가 존재하지 않는다.
   3. 따라서 대시보드·스테이징 서버·관리자 페이지처럼 로그인한 사용자만 볼 수 있는 화면을 검증하기 어렵다.

2. 개발 업무와 로그인 상태

   1. 실제 개발자가 확인해야 하는 화면은 대부분 로그인이 필요하다.
   2. 쿠팡 주문처럼 계정·배송지·결제 정보가 필요한 업무도 마찬가지다.
   3. 로그인 상태를 매번 새로 설정하는 것은 자동화의 편의성을 크게 떨어뜨린다.

5.2. 프로필과 기존 브라우저 데이터의 이전

1. 여러 용도의 프로필 분리

   1. Aside에서는 여러 브라우저 프로필을 만들 수 있다.
   2. 발표자는 개인 용도, 회사 업무, Aside에 풀 액세스를 줄 때의 용도로 세 가지 프로필을 만들었다.
   3. 세 번째 프로필은 게스트 모드처럼 구성해 중요한 로그인 세션을 넣지 않고 사용한다.

2. 브라우저 상태의 격리

   1. 프로필마다 서로 다른 로그인 세션 정보를 넣어둘 수 있다.
   2. 브라우저 히스토리와 쿠키도 프로필 단위로 격리된다.
   3. 특정 작업에 특정 프로필을 지정하면 업무별 권한 경계를 유지할 수 있다.

3. 가져오기 기능

   1. Chrome, Safari, Firefox 등 기존 브라우저에서 북마크와 브라우저 데이터를 가져올 수 있다.
   2. 기존 브라우저의 히스토리와 쿠키를 옮기면 로그인 상태도 유지되는 경우가 있다.
   3. 이주 비용을 낮추는 기능이므로, 브라우저를 바꿀 때 가장 귀찮은 초기 설정을 줄여 준다.

6. 보안과 프라이버시: 강력한 브라우저 에이전트의 대가

로그인된 브라우저를 에이전트가 사용할 수 있다는 장점은 동시에 가장 큰 위험이다. 영상은 Aside를 추천하면서도 보안 문제를 별도 주제로 강조한다.

6.1. 기본 보안 설정

1. 서드파티 쿠키와 제품 개선 데이터

   1. Aside의 보안·프라이버시 설정에서 서드파티 쿠키를 허용할지 차단할지 선택할 수 있다.
   2. 브라우저 사용 데이터를 제품 개선에 활용하는 것을 원하지 않는다면 관련 옵션을 비활성화하라고 권한다.
   3. 로그인 세션을 유지할수록 쿠키와 브라우저 데이터의 범위도 커지므로, 초기 설정을 확인해야 한다.

2. 권한 모델

   1. 읽기 전용(Read-only) 모드는 브라우저 에이전트가 읽기 작업만 하게 한다.
   2. 가드(Guard) 모드는 승인된 폴더나 허용된 범위에서 실행하고, 나머지 작업은 사용자에게 묻는다.
   3. 풀 액세스(Full Access) 모드는 모든 접근을 허용한다.
   4. 발표자는 기본적으로 가드 모드를 두고 사용할 것을 권장한다.

6.2. 프롬프트 인젝션은 해결되지 않은 문제다

1. 웹페이지 안에 숨은 지시문

   1. 프롬프트 인젝션은 웹페이지의 HTML 안에 보이지 않는 악의적 지시문을 넣는 공격이다.
   2. 브라우저 에이전트가 페이지를 읽고 작업하는 과정에서 이 지시문을 자신의 지시처럼 따를 수 있다.
   3. 그 결과 에이전트가 사용자 쪽의 정보나 세션을 공격자에게 넘길 가능성이 생긴다.

2. 로그인 세션을 쓸 수 있다는 것의 위험

   1. Aside 에이전트는 사용자가 로그인해 둔 세션 정보를 활용할 수 있다.
   2. 이 능력은 로그인 필요한 업무를 가능하게 하지만, 공격이 성공했을 때 피해 범위도 키운다.
   3. 발표자는 OpenAI Atlas 같은 AI 브라우저에서도 프롬프트 인젝션이 여전히 연구 중인 문제이며, 수년간 해결 노력이 필요할 것으로 본다.

3. 완전한 안전을 전제하지 않는다

   1. Aside에 권한 모드·패스워드 매니저·프로필 분리 같은 장치는 있다.
   2. 그러나 발표자도 패스워드 원문이 에이전트에 노출되지 않는다는 설명을 실제로 공격해 검증한 것은 아니며, 문서에 그렇게 적혀 있다는 수준으로 소개한다.
   3. 따라서 보안 장치가 있다는 사실과 안전성이 입증됐다는 사실을 혼동해서는 안 된다.

6.3. 패스워드 매니저와 프로필을 조합하는 방법

1. 패스워드 매니저 연동

   1. Aside 자체 패스워드 매니저를 사용하거나 기존 패스워드 매니저를 연결할 수 있다.
   2. 발표자는 Bitwarden을 연결해 사용한다.
   3. 영상에서 소개된 문서 설명에 따르면 패스워드를 로그인 폼에 채우더라도 패스워드 원문은 에이전트에게 보이지 않도록 처리된다.

2. 세 가지 프로필 전략

   1. 개인 프로필에는 개인 로그인 세션을 둔다.
   2. 회사 프로필에는 업무에 필요한 회사 계정만 둔다.
   3. 완전 자율 검증용 프로필은 게스트 또는 빈 프로필로 만들어 중요한 세션과 히스토리를 넣지 않는다.

3. 코딩 에이전트의 규칙 파일에 기본값 기록

   1. 코딩 에이전트의 규칙 파일에 어떤 Aside 프로필을 기본으로 사용할지 적어 둔다.
   2. 로그인 세션이 없는 검증 전용 프로필을 기본값으로 지정하면 실수로 개인 계정에 접근할 가능성을 줄일 수 있다.
   3. 필요할 때만 명시적으로 로그인된 프로필을 선택하는 방식이 더 안전한 운영 패턴이다.

주요 발언 모음

“기존에 AI 브라우저랑 완전히 차원이 다르다라고 생각이 들었습니다.”

“단순히 토큰이 효율적인 이유도 물론 있지만, 그것보다 로그인 세션이 유지가 될 수 있다는 점이 굉장히 큰 매력으로 다가왔습니다.”

“프롬프트 인젝션은 여전히 에이전트 보안의 미해결 과제이며 앞으로도 수년간 지속적인 노력이 필요할 것으로 예상됩니다.”

“기본적으로는 가드 모드를 두고 활용하는 것을 권장드리고 있고요.”

“메인 브라우저를 어사이드로 옮기지는 않더라도 어사이드 브라우저 에이전트 기능을 코딩 에이전트에 스킬로 심어 두고 활용하는 것 정도는 꼭 해 주셨으면 좋을 것 같습니다.”

핵심 데이터 & 수치

• 영상 길이: 14분 27초.
• Aside의 배경: Y Combinator 배치 스타트업이며 창립자 세 명이 모두 한국인이라고 소개됨.
• 비교 대상: Playwright MCP, Claude Code의 브라우저 기능, Codex의 브라우저 기능.
• Playwright MCP 도구 수: 약 24개.
• Playwright 도구 정의 컨텍스트: 약 18,000자 이상.
• Aside 도구 정의: 스킬 하나, 약 5,000자 미만이라고 소개됨.
• 비교 페이지: GitHub, Hacker News, MDN, Wikipedia, Tailwind 등 5개.
• 토큰 절감: 실험 평균 약 2.3배, 특정 페이지 최대 약 4.2배.
• 프로필 운영 예시: 개인용·회사 업무용·풀 액세스/검증용의 3개 프로필.
• 권한 모드: 읽기 전용, 가드, 풀 액세스.

결론 및 시사점

1. AI 브라우저의 핵심은 요약이 아니라 실행이다: 페이지를 읽는 기능은 흔해졌고, 차별점은 로그인·쿠키·확장 프로그램을 포함한 실제 브라우저 상태에서 작업할 수 있는지에 있다.
2. 개발자는 Aside를 메인 브라우저로 옮기지 않아도 된다: Aside CLI와 스킬을 Claude Code·Codex에 연결해 로그인된 화면의 시각적 검증 도구로 먼저 활용할 수 있다.
3. 작은 에이전트 인터페이스가 토큰 비용을 줄인다: Playwright처럼 많은 도구를 상위 모델에 모두 노출하기보다, 브라우저 에이전트에 복잡성을 캡슐화하는 설계가 효율적일 수 있다.
4. 로그인 세션은 기능이면서 공격 표면이다: 세션 유지가 자동화를 강력하게 만들지만, 프롬프트 인젝션이 성공하면 개인·회사 계정까지 영향을 받을 수 있다.
5. 가드 모드를 기본값으로 사용한다: 읽기 전용 또는 가드 모드로 시작하고, 풀 액세스는 별도 프로필에서 제한된 작업에만 사용해야 한다.
6. 프로필을 권한 경계로 설계한다: 개인·회사·검증 전용 프로필을 분리하고, 코딩 에이전트의 규칙 파일에는 로그인 정보가 없는 검증 전용 프로필을 기본값으로 둔다.
7. 패스워드 보호 설명은 신뢰하되 검증 수준을 구분한다: 패스워드 원문 비노출은 영상에서 문서 설명으로 소개된 내용이므로, 중요한 계정에는 최소 권한·별도 계정·추가 승인을 적용하는 편이 안전하다.
8. 브라우저 이주는 데이터 이전부터 계획한다: 북마크뿐 아니라 쿠키·히스토리·로그인 세션을 어떤 프로필로 옮길지 결정한 뒤 마이그레이션해야 한다.
9. 최종 평가는 실제 업무로 해야 한다: 다섯 페이지의 토큰 비교는 참고 자료이며, 팀의 스테이징 검증·관리자 화면·반복 웹 업무에서 정확도·속도·보안 사고 가능성을 함께 측정해야 한다.