Aside 사용법,
AI 브라우저에 업무를 맡기기 전 정할 5가지

Aside는 대화창이 아니라 일을 처리하는 브라우저입니다

Aside는 웹사이트를 열어 답을 보여주는 일반 챗봇과 달리, 브라우저 안에서 여러 탭과 로그인된 서비스를 오가며 주어진 업무를 처리하도록 설계된 AI 브라우저입니다. 예를 들어 메일함에서 특정 조건의 메시지를 찾고, 대시보드의 숫자를 비교하고, 파일을 읽어 표로 정리하는 일을 한 요청 안에서 이어갈 수 있습니다. 결과를 글로 답하는 데서 끝나지 않고 브라우저의 실제 화면과 자료를 근거로 작업한다는 점이 핵심입니다.

공식 제품 페이지는 Aside가 로그인된 웹사이트에서 작동하고, 웹 탐색 기록을 작업 맥락으로 활용하며, 민감한 행동은 사용자 확인을 기다리도록 설계됐다고 설명합니다. 다만 로그인돼 있어도 권한이 자동으로 넓어지는 것은 아닙니다. 어떤 자료를 읽고 어디까지 행동해도 되는지는 요청마다 분명히 정해야 합니다. 이 글은 그 경계를 정한 뒤 첫 작업을 안전하게 시작하는 방법을 다룹니다.

1. 요청보다 ‘끝난 상태’를 먼저 씁니다

AI 브라우저는 검색 결과를 요약하는 도구이면서, 로그인된 웹사이트와 탭을 오가며 실제 작업을 수행할 수 있는 에이전트이기도 합니다. 그래서 “경쟁사 좀 조사해줘”처럼 넓은 요청은 검색 범위도, 끝나는 시점도 불분명합니다. 첫 문장에는 대상 사이트와 결과물을 함께 넣는 편이 좋습니다.

공식 도움말도 Ask AI 요청에는 사이트, 원하는 결과, 지켜야 할 제한을 이름으로 적으라고 안내합니다. 질문을 길게 만드는 것보다 “무엇을 하지 말아야 하는가”를 같이 쓰는 편이 중요합니다. 예를 들어 이메일 초안을 만들라는 요청과 이메일을 실제 발송하라는 요청은 전혀 다른 권한을 요구합니다.

2. 필요한 맥락은 명시적으로 붙입니다

브라우저 안에 탭이 열려 있다고 해서 그것이 항상 현재 작업의 근거가 되지는 않습니다. 사이트를 여럿 쓰는 업무라면 어떤 탭, 파일, 기간을 읽을지 요청에 적습니다. Aside 도움말의 @ 맥락 첨부 기능도 이 용도로 쓰입니다. 작업을 시작하기 전에 “이 탭의 표만 기준으로”, “첨부한 CSV의 7월 행만 사용해”처럼 범위를 좁히면 엉뚱한 페이지를 근거로 답할 가능성이 줄어듭니다.

예를 들어 채용 후보를 정리할 때에는 채용 공고, 지원자 목록, 평가 기준을 각각 가리킵니다. 지원자 개인정보가 든 탭과 공개 포트폴리오 탭을 섞어 두고 단순히 “추천해줘”라고 하면 어떤 정보를 사용했는지 나중에 검토하기 어렵습니다. 필요한 정보만 붙이는 일은 답의 정확도뿐 아니라 접근 범위를 줄이는 방법이기도 합니다.

3. 첫 작업은 읽기 전용으로 끝냅니다

처음부터 게시물 발행, 결제, 메시지 전송까지 맡기면 결과가 맞는지와 행동이 적절했는지를 한 번에 검토해야 합니다. 첫 버전은 자료 조회, 비교표 작성, 초안 생성처럼 외부 상태를 바꾸지 않는 일로 제한합니다. 결과 형식이 마음에 들고, 어떤 근거를 읽었는지 확인한 뒤에만 다음 단계를 넓힙니다.

안전한 순서는 간단합니다. 먼저 “이 페이지의 내용을 표로 정리하되 수정하지 마”라고 요청합니다. 다음에는 “이 표를 바탕으로 답장 초안을 작성하되 전송하지 마”라고 시킵니다. 마지막으로 사람이 수신자, 숫자, 첨부 파일을 확인한 뒤 전송 여부를 결정합니다. 이 흐름은 AI가 틀릴 수 있기 때문만이 아니라, 원래 업무의 책임자가 누구인지 흐리지 않기 위해서도 필요합니다.

반복 규칙이 명확한 단계는 n8n 같은 결정적 자동화에 두고, 문맥을 읽고 비교하는 좁은 판단만 Aside에 맡기는 편이 관리하기 쉽습니다. AI 에이전트를 만들기 전 끝난 상태를 정하는 글에서 설명한 입력·출력·금지 행동·중단 조건을 그대로 적용하면 됩니다.

4. 로그인과 승인은 ‘할 수 있음’이 아니라 ‘해도 됨’의 문제입니다

Aside는 로그인된 서비스에서 일할 수 있도록 설계돼 있습니다. 공식 제품 페이지는 비밀번호가 에이전트에 노출되지 않는 자동 완성과 민감 행동의 승인 절차를 설명합니다. 그렇더라도 로그인돼 있다는 사실이 해당 작업의 전권을 뜻하지는 않습니다. 고객 메일을 읽을 수 있다고 고객에게 답장을 보내도 되는 것은 아닙니다.

승인이 필요한 경계는 미리 적어둡니다. 외부로 나가는 메시지, 공개 게시, 결제, 삭제, 접근 권한 변경은 기본적으로 사람 확인 뒤에 실행합니다. 임시 파일을 만들거나 다운로드하는 일도 저장 위치와 보존 기간을 정합니다. “문제가 생기면 멈춰”보다 “수신자가 두 명 이상이면 멈춰”, “금액이 보이면 초안까지만 작성해”처럼 관찰 가능한 조건이 더 안전합니다.

5. 결과만 보지 말고 근거와 다음 행동을 검토합니다

작업이 끝났다는 메시지만 보고 끝내면 안 됩니다. 숫자라면 원본 화면의 기간과 통화를 다시 보고, 글이라면 링크와 인용이 실제 페이지를 가리키는지 확인합니다. 웹 입력 작업이라면 제출 전 화면과 제출 뒤 완료 화면을 구분해 봅니다. 제출 버튼을 눌렀다는 사실만으로 서버가 저장했다는 뜻은 아닐 수 있기 때문입니다.

검토가 끝난 업무만 반복 실행 후보로 남깁니다. 매주 같은 대시보드를 확인해 이상값만 보고하는 일처럼 입력과 결과 형식이 안정된 작업은 루틴으로 만들 만합니다. 반대로 기준이 자주 바뀌거나 사람 판단이 핵심인 업무는 매번 새 요청으로 범위를 확인하는 편이 낫습니다. 반복 여부를 정할 때는 “얼마나 자주 하는가”보다 “실패했을 때 바로 알아챌 수 있는가”를 먼저 봅니다.

권한이나 검토 흐름이 아직 낯설다면 일단 읽기 전용 작업만 수행하고, 변경 전에는 명시적으로 중단시키세요. Claude Code의 Ask·Allow·Deny 권한을 구분한 글도 같은 원칙을 다룹니다. 편의를 위해 확인 단계를 없애기보다, 내가 검토하기 쉬운 크기로 업무를 나누는 것이 장기적으로 더 빠릅니다.

첫 주에는 작업 하나를 끝까지 관찰합니다

Aside를 처음 쓸 때 가장 좋은 연습은 큰 자동화가 아닙니다. 한 사이트에서 한 가지 정보를 읽고, 지정한 형식의 결과를 받고, 근거를 다시 확인하는 짧은 작업입니다. 그 과정을 몇 번 반복해 보면 어떤 요청에 맥락을 더 줘야 하는지, 어느 행동에서 승인을 멈춰야 하는지가 드러납니다. 그다음에야 여러 탭을 넘나드는 조사나 반복 점검으로 범위를 넓힐 수 있습니다.