AI 브라우저한테 제 앱을 쓰게 했습니다

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Aside로 자신의 앱 오토클릭을 직접 조작하게 한 사례는 AI 브라우저의 실용성과 함께, 에이전트가 읽기 쉬운 앱 설계와 권한 관리의 중요성을 보여준다.

📌 핵심 요점

1. Aside는 페이지 조작, 작업 메모리, 비밀번호 관리를 결합한 에이전트 브라우저로 소개된다. 기존 로그인 상태를 활용하지만, 실제 시연에서는 별도 계정과 추가 로그인이 필요한 구간도 나타난다.
2. 발표자는 자신이 구독하는 Claude를 연결해 브라우저 작업을 실행한다. 설명에 따르면 에이전트 작업은 연결한 구독의 한도를 사용하고, 이미지 생성에는 별도의 Aside 토큰이 쓰인다.
3. 오토클릭 썸네일 제작에서는 이전 조사와 메모리를 활용해 입력과 생성을 맡긴다. 쇼핑 장바구니 구성, 여러 서비스의 구독 정보 취합, 유튜브 스튜디오 분석도 시연한다.
4. 에이전트의 앱 개선 제안은 코드와 대조해야 한다. 초기 보고서의 API 관련 판단을 재검토한 뒤, 기존 API 활용과 선택 상태를 읽기 쉬운 UI 개선을 우선순위로 정한다.
5. CLI와 스킬로 개발 에이전트에 브라우저 조작을 연결하고, 브랜치로 작업 맥락을 나눈다. 실제 운영에는 최종 행동 승인과 개인·업무·테스트 프로필 분리가 중요하다.

🧩 배경과 문제 정의

발표자는 에이전트 시대의 브라우저가 실제 업무를 얼마나 끝까지 수행할 수 있는지 묻는다. 기존 브라우저 자동화의 장애물로 로그인, 모달·로딩·레이아웃 변화, 여러 단계의 연결을 꼽고, Aside가 이를 어떻게 다루는지 자신의 업무로 살펴본다.

핵심 실습 대상은 발표자의 썸네일 제작 서비스 오토클릭이다. 단순히 AI에게 앱 사용을 맡기는 데서 나아가, 사용 중 발견한 불편을 개선 보고서로 만들고 개발 에이전트의 코드 검토와 구현으로 연결한다. 쇼핑, 구독 관리, 유튜브 분석은 활용 범위를 보여주는 추가 사례다.

🕒 시간순 섹션별 상세정리

1. 에이전트에게 자신의 앱을 맡기는 실험

• 발표자는 Aside로 오토클릭을 자동화하고 있다고 소개하며, 에이전트 시대의 브라우저가 실제 일을 얼마나 수행할 수 있는지 질문한다. [00:53]
• 다른 에이전트 브라우저와 비교한 개인적 선호를 밝히고, 오토클릭도 에이전트가 잘 사용할 수 있도록 고쳐보겠다고 예고한다. [01:39]

2. 브라우저 자동화가 막히는 세 가지 이유

• 영수증 처리 사례를 들어 로그인, 계속 변하는 화면 상태, 다운로드와 결과 확인까지 이어지는 다단계 작업을 난점으로 보여준다. [02:45]
• Aside는 기존 로그인 상태를 사용하고 작업 맥락을 기억하며, 페이지 읽기·조작 도구를 브라우저와 함께 설계했다고 보여준다. [03:28]

3. 페이지 조작·메모리·비밀번호 관리

• 핵심 구성으로 사람처럼 페이지를 읽고 행동하는 에이전트, 다음 작업에 맥락을 활용하는 메모리, 내장·외부 비밀번호 관리 기능을 꼽는다. [04:14]
• 공식 문서의 설명을 인용해 자동 입력에 쓰는 저장 비밀번호를 AI가 직접 볼 수 없도록 설계했다고 드러낸다. [04:30]

4. 브라우저 이전과 구독·모델 설정

• Windows 베타를 언급하면서 정확한 상태는 모른다고 덧붙이고, Chrome의 북마크·캐시·쿠키를 가져와 사용했다고 보여준다. [05:20]
• 무료 플랜에서 기존 Claude 구독을 연결한 설정을 보여주며, 에이전트 실행이 해당 구독의 사용 한도를 소비한다고 보여준다. [06:00]
• 작업별 모델 설정과 이미지 생성 설정을 소개하고, 이미지 생성에는 Aside 토큰이 차감된다고 드러낸다. [06:34]

5. 메모리로 누적되는 작업 맥락

• 날짜별 작업 기록과 조사 내용을 보여주며 오토클릭 썸네일 생성도 자동화해 사용한다고 보여준다. [07:16]
• 회사·프로젝트·사이트별 정보와 사용자 메모리가 개인화된 에이전트의 맥락으로 쌓이는 과정을 보여준다. [07:51]
• 메모리 활성화를 권하고, 내장 비밀번호 관리자 외에 외부 관리자를 연결하는 설정도 보여준다. [08:13]

6. CLI와 스킬로 개발 도구 연결

• 발표자는 웹 서비스 테스트에서 Aside의 속도와 토큰 효율에 만족한다고 말하지만, 정량 비교 결과는 제시하지 않는다. [08:42]
• Aside CLI를 Claude나 Codex의 도구로 연결하고 스킬을 사용 설명서처럼 제공해, 개발 에이전트가 브라우저를 조작하는 방식을 보여준다. [09:23]

7. 화면 질문과 쇼핑 작업 시연

• 새 탭의 채팅·탭 구성을 소개하고 Ask Aside에 현재 화면 설명을 요청해 페이지 내용을 읽는 모습을 보여준다. [10:22]
• 아마존에서 프로틴 셰이크를 추천해 장바구니에 담고 보고하도록 요청하자, 에이전트가 페이지를 이동하며 상품을 비교한다. [10:57]

8. 오토클릭에서 썸네일 생성

• 로그인한 오토클릭에서 메타 뮤즈 관련 썸네일 제작을 요청한다. 에이전트는 페이지와 메모리, 이전 조사 자료를 확인하며 수동 입력 과정을 대신한다. [12:03]
• 쇼핑 작업의 장바구니 담기 보고를 확인하고, 결제는 승인을 받도록 해야 한다고 강조한다. 이어 오토클릭의 썸네일 제작 결과를 확인한다. [12:44]

9. 여러 서비스의 구독 정보 취합

• 구독료·갱신일·남은 API 크레딧을 모아 보고하도록 요청한다. 여러 사이트를 방문하는 업무는 특정 탭보다 채팅에서 맡기기 편하다고 보여준다. [13:42]
• 일부 서비스는 병렬로 확인하며, 로그인되지 않은 계정은 자신이 별도로 인증해야 할 수 있다고 드러낸다. [14:18]

10. 유튜브 스튜디오 분석과 인증 장벽

• 시청자 이탈 그래프처럼 API로 제공되지 않는다고 알고 있는 정보를 브라우저로 분석하도록 요청하고, 스튜디오를 여는 과정을 관찰한다. [15:21]
• 채팅과 브라우저 화면을 오가며 작업을 확인하는 UI를 보여준다. 구독 취합에서는 ElevenLabs 로그인, 다른 Google 계정, 별도 Anthropic API 계정 확인이 필요해진다. [16:28]

11. 조사부터 썸네일까지 연결한 추가 사례

• Aside 소개 영상의 자료 조사와 이미지 제작을 함께 요청한다. 조사 결과에는 한국인 공동 창업자 세 명과 Chromium 기반 독립 앱이라는 설명이 포함된다. [17:04]
• 오토클릭으로 만든 썸네일 프로젝트를 확인하고, 서비스에 직접 내용을 입력하지 않고 Aside로 작업했다고 보여준다. [17:34]

12. 비용 점검과 채널 분석 결과

• 구독·API 분석 보고서에 사용량 급증과 크레딧 소진 관련 내용이 나타나며, 발표자는 최근 오토클릭 개발 과정의 API 호출 증가와 연결해 해석한다. [18:04]
• 롱폼 영상 약 일곱 개를 살펴본 유튜브 분석은 시간이 오래 걸렸다. 결과에는 첫 60초에 시청자 절반가량이 이탈한다는 진단과 개선 제안이 담겼다. [18:38]
• 여러 화면에서 데이터를 수집하는 업무의 활용 가능성을 강조하고, 에이전트가 쉽게 탐색할 수 있는 웹사이트 설계 문제로 논의를 옮긴다. [19:48]

13. 에이전트의 개선 제안을 코드로 검토

• 오토클릭을 더 효율적으로 사용하려면 스킬·API·CLI가 도움이 되는지 묻고 보고서를 받는다. 초기 보고서는 활용할 API가 없다는 판단 등을 담는다. [20:28]
• 보고서를 개발 환경으로 가져가 코드와 대조하자, 개선 가치가 있는 제안과 그렇지 않은 제안이 나뉜다. 기존 API 활용과 선택 상태를 읽기 쉬운 제품 수정이 우선순위에 오른다. [21:11]
• Codex에 구현과 PR 생성을, Claude에 리뷰를 맡기고 Aside 스킬로 브라우저 테스트를 진행한다. 병합 후의 토큰 효율 개선은 기대 효과로 보여준다. [21:40]

14. 브랜치로 작업 맥락 나누기

• 진행 중인 세션의 맥락을 복사해 별도 작업으로 이어가는 브랜치 기능을 보여준다. [22:17]
• 유튜브 분석 세션을 나눠 한쪽은 숏폼 분석을 요청하고 다른 쪽은 기존 분석을 바탕으로 후속 작업을 이어가는 예를 든다. [22:51]

15. 권한과 최종 행동 승인

• 읽기 전용, 가드, 전체 접근 수준을 보여준다. 읽기 전용에서는 캘린더 일정 추가처럼 쓰기가 필요한 행동을 수행할 수 없다고 예시를 든다. [23:22]
• 자동화에 넓은 권한을 줄 때는 검증이 중요하다고 강조하고, 결제·전송·삭제·제출 같은 최종 행동 전에 확인을 받는 설정을 보여준다. [24:12]

16. 개인·업무·테스트 프로필 분리

• 프로필마다 비밀번호 관리와 브라우저 맥락을 나눌 수 있으며, 개인용·업무용·테스트용으로 구성하는 방법을 보여준다. [24:59]
• 테스트 계정에는 해당 서비스의 비밀번호만 제공하고 작업에 맞는 프로필을 지정하면 더 안전하게 테스트할 수 있다고 드러낸다. 자신은 현재 메인 프로필을 주로 쓴다고 덧붙인다. [25:39]

17. 활용 경험 정리와 후속 주제 예고

• 발표자는 오토클릭 썸네일 제작이 자신의 주된 활용처라고 정리하고, 가입 후 연락하면 무료 크레딧을 제공한다는 안내를 덧붙인다. [26:04]
• 공동 창업자 인터뷰를 본 소감을 전하며, 많은 업무가 이루어지는 브라우저에서 AI가 수행할 역할에 기대를 표한다. 시청자에게 맡긴 일과 성공·실패 경험을 요청한다. [27:11]
• 후속 주제로 메타 뮤즈 활용과 트렌딩 스킬 리뷰를 제안하고, 시청자의 의견을 요청하며 영상을 마친다. [27:58]

🧾 결론

• 영상에서 가장 구체적인 활용 사례는 발표자의 오토클릭 썸네일 제작이다. 주제 전달부터 기존 자료 확인, 폼 입력, 생성까지 이어지는 흐름을 보여준다.
• 브라우저 자동화의 가치는 개별 클릭보다 로그인과 작업 맥락을 유지하면서 여러 단계를 끝내는 데 있다. 다만 인증 장벽과 분석 대기 시간은 남는다.
• 앱을 에이전트가 잘 쓰게 만들려면 실제 사용 과정에서 막히는 지점을 찾고, 제안을 코드와 대조한 뒤 구현·리뷰·브라우저 테스트로 검증해야 한다.
• 발표자의 높은 만족도와 제품 간 객관적 우열은 구분해야 한다. 이 영상은 개인 활용 시연이며, 비교 벤치마크나 개선 전후 정량 측정은 제시하지 않는다.

📈 투자·시사 포인트

• 제품 관점에서는 에이전트가 상태와 다음 행동을 이해하기 쉬운 웹 UI가 새로운 사용성 평가 기준이 될 수 있다. 오토클릭의 선택 상태 개선 논의가 이를 보여준다.
• API로 접근하기 어렵다고 소개된 화면과 여러 사이트에 흩어진 업무는 브라우저 에이전트의 활용 영역이다. 유튜브 스튜디오 분석 사례에서는 가능성과 긴 처리 시간이 함께 드러난다.
• 비용은 브라우저 요금만으로 판단하기 어렵다. 연결한 AI 구독 한도와 이미지 생성 토큰을 함께 살펴야 실제 업무당 비용을 평가할 수 있다.
• 메모리와 인증 정보 활용은 편의성을 높이지만, 권한 범위와 승인 설정도 제품 평가 요소가 된다. 영상은 특정 기업의 매출이나 투자 수익성을 판단할 재무 근거를 제공하지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• Windows 베타 제공 여부는 발표자도 정확히 모른다고 언급한다. 요금제, 구독 연결 조건, 모델명과 제공 범위도 영상 시점의 설명이며, 전사된 모델명에는 오류 가능성이 있다.
• 저장된 비밀번호를 AI가 볼 수 없다는 설명은 발표자가 공식 문서를 인용한 주장이다. 영상 자체에서 보안 구조나 실제 정보 노출 여부를 검증하지는 않는다.
• 속도·토큰 효율·경쟁 제품 대비 우수성은 발표자의 경험에 근거한다. 동일 과제 비교, 반복 성공률, 소요 시간과 비용 수치는 제시되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복하는 브라우저 업무 하나를 골라 입력, 완료 조건, 결과 확인 항목을 정하고 Aside로 시도한다.
• 연결할 AI 구독의 사용 한도와 이미지 생성 토큰 차감 조건을 확인해 작업 비용을 기록한다.
• 결제·전송·삭제·제출 전에 확인을 받도록 최종 승인 설정을 점검한다.
• 개인·업무·테스트 프로필을 분리하고 테스트 프로필에는 해당 서비스의 계정 정보만 제공한다.

❓ 열린 질문

• 같은 업무를 반복했을 때 Aside의 성공률, 처리 시간, 토큰 사용량은 다른 브라우저 자동화 도구와 얼마나 차이가 나는가?
• 선택 상태를 명확하게 표시하고 기존 API를 활용한 뒤, 오토클릭 자동화 효율은 실제로 얼마나 개선되는가?
• 장기 메모리가 잘못된 정보를 저장하거나 오래된 맥락을 적용할 때 사용자는 어떻게 확인하고 수정할 수 있는가?