시골에서 텔레그램으로 사이트 관리자 로그인을 맡긴 적이 있다.
프롤로그에 적은 그 장면이다. 내 컴퓨터에서 Aside는 브라우저에 이미 로그인되어 있던 구글 계정 세션으로 호스팅 서비스에 들어갔다. 인증 단계가 나오자 연결된 메일함을 열어 인증 메일을 찾았고, 로그인을 끝냈다. 나는 휴대폰으로 결과만 받았다. 편리했다. 그리고 섬뜩했다. 나를 확인하려고 보낸 인증 단계를 에이전트가 내 메일함을 읽고 대신 통과한 것이다. 이 장은 그 두 감정을 함께 들고 시작한다. 권한과 승인을 처음부터 끝까지 설명하는 곳은 이 책에서 여기 한 곳이다.
11.1 편리함과 섬뜩함을 같이 기억하기
4장에서 나는 추가 인증은 사람이 하는 단계라고 썼다. 그런데 프롤로그의 장면에서는 Aside가 그 단계를 넘었다. 둘은 어긋나 보이지만 사정은 단순하다. 그날 인증을 넘긴 것은 그 순간 내가 그렇게 두기로 한 선택이었다. 문제는 그 선택을 미리 설계하지 않았다는 데 있다. 메일함과 인증 단계는 온라인에서 내가 나라는 것을 증명하는 자리다. 비밀번호 재설정도, 새 기기 로그인 확인도, 거래처와 주고받는 약속도 메일함을 거친다. 그곳을 열 수 있는 에이전트는 사실상 나로 행동할 수 있다. 그래서 이 장은 편리함을 버리자고 말하지 않는다. 어디에 문을 달고, 그 문을 누가 여는지 미리 정해 두자고 말한다. 그 문을 이 책에서는 승인 게이트라고 부른다.
게이트를 설계하려면 먼저 Aside가 권한을 어떻게 나누는지 알아야 한다. 앞 장들에서 “권한은 11장에서”라고 미뤄 둔 이야기, 메모리와 스킬에 적은 규칙이 권한이 되는가 하는 물음, 작업 중 무엇이 밖으로 나가는가 하는 물음을 이 장에서 한 번에 정리한다.
11.2 권한을 정하는 세 개의 축
Aside의 권한은 세 개의 축으로 나뉜다. 첫째는 도구 규칙이다. Settings > Agents의 Tool permissions에서 Allow, Ask, Deny 세 칸에 규칙을 넣는다. Allow는 묻지 않고 쓰고, Ask는 진행하기 전에 묻고, Deny는 막는다. 규칙이 서로 부딪히면 Deny가 Ask와 Allow보다 우선한다. 둘째는 파일 권한이다. 에이전트가 볼 수 있는 폴더와 고칠 수 있는 폴더의 목록이고, 여기에 샌드박스가 붙는다. 샌드박스를 켜면 명령이 운영체제 수준에서 격리된 채 실행된다. 목록이 짧을수록 실수가 닿을 수 있는 범위도 짧아진다.
셋째는 작업 모드다. 작업마다 Read only, Guard, Full access 가운데 하나를 고른다. Read only는 파일을 바꾸지 않고 브라우저와 파일 맥락만 살핀다. Guard는 승인된 폴더 안에서 일하고 다른 폴더에 가려면 먼저 묻는다. Full access는 컴퓨터 어디든 읽고 쓴다. 새 작업의 기본은 Guard다. 페이지를 살피고 보고만 받을 일이라면 Read only로 시작하고, Full access는 꼭 필요한 작업에서만 잠깐 켜는 편이 좋다.
세 축은 층으로 쌓인다. Settings > Agents에서 정한 값이 에이전트의 기본이 되고, 각 작업에서 고른 설정이 그 위에 얹힌다. 도구 규칙은 무엇을 할 수 있는지를, 파일 권한은 어디를 만질 수 있는지를, 작업 모드는 이번 일에서 그 범위를 얼마나 넓힐지를 정한다. 한 가지 오해는 미리 풀어 둔다. Full access를 켜도 넓어지는 것은 파일 접근이다. 저장된 비밀번호 값은 여전히 에이전트에게 보이지 않는다. Aside는 자동 입력 내용을 만들기 전에 접근 정책과 대상 주소를 먼저 확인한다. 로그인 칸을 채워 주는 일과 비밀번호를 읽어 주는 일은 다르게 다뤄진다.
| 축 | 어디서 | 무엇을 막나 | 내 설정 |
|---|---|---|---|
| 도구 규칙 | Settings > Agents의 Tool permissions | 특정 도구 사용을 묻게 하거나 막는다 | Allow, Ask, Deny 모두 No rules |
| 파일 권한과 샌드박스 | Settings > Agents의 Sandbox, File permissions | 허용 목록 밖 폴더의 읽기와 쓰기 | 샌드박스 켜짐, 목록은 기본값인 프로젝트 루트 |
| 작업 모드 | 각 작업의 설정, 기본값은 Agents 화면 | 이번 작업에서 파일 접근을 넓힐 범위 | 기본 권한 Guard |
11.3 내 Agents 화면에서 보이는 것
화면 위쪽 Chat 영역에는 Access permission 항목이 있고, 설명은 Read and write permission for agents다. 내 설정에서 기본 권한(Default permission)은 Guard, 작업 중에 들어온 메시지를 처리하는 방식(Follow-up behavior)은 Queue다. 아래로 내리면 세 축이 차례로 나온다.
Sandbox에는 Enable sandbox 스위치가 켜져 있고, 작업을 내가 허용한 파일과 폴더 안으로 제한한다는 설명이 붙어 있다. File permissions는 Can view와 Can edit 두 목록으로 나뉜다. 기본으로 프로젝트 폴더가 들어 있고, 화면은 이 목록을 작게 유지하라고 권한다. Tool permissions에는 Allow(확인 없이 실행), Ask(실행 전에 묻기), Deny(실행 전에 거부) 세 칸이 있다. 내 설정에서는 세 칸 모두 No rules로 비어 있다.
내 환경의 설정 파일도 들여다보았다. 이 부분은 도움말에 나온 설명이 아니라 내 컴퓨터에서 관찰한 값이다. 도구 규칙의 기본값은 허용이었다. 허용 폴더 밖의 파일은 읽기와 쓰기 모두 묻기로 되어 있었다. 샌드박스는 켜져 있었다. 결제 기능은 꺼져 있었고, 켜면 결제 전에 묻도록 되어 있었으며, 자동 승인 한도를 적는 칸에 50달러가 들어 있었다. 기능이 꺼져 있으니 이 한도는 쓰이지 않는다. 메시지 발송 같은 소통 기능도 꺼져 있었고, 발송 전에 묻는 설정이었다. 화면 맥락 인식은 꺼져 있었다. 정리하면 내 환경은 도구는 넓게 열어 두고, 파일은 좁게 묶고, 돈과 발송은 아예 닫아 둔 모양이다.
윈도우용 Aside에서도 같은 설정 화면을 쓴다. 나는 윈도우판도 쓰는데 이 화면에서 눈에 띄는 차이는 없었다.
11.4 행동을 위험도 사다리에 올려 보기
설정 화면의 칸을 채우기 전에, 맡기려는 행동을 위험도 순으로 늘어놓아 보면 게이트 자리가 보인다. 가장 아래는 읽기다. 페이지를 확인하고 파일을 읽는 일은 틀려도 잃을 것이 없다. 그 위가 초안 작성이다. 초안은 아직 아무에게도 보이지 않는다. 다음은 내 공간에 저장하기다. 허용 폴더에 파일을 만들거나 비공개 초안을 올리는 일이다. 그 위가 되돌릴 수 있는 변경이다. 사이트 설정을 고치거나 비공개 글을 수정하는 일은 틀리면 되돌리면 된다. 여기서 한 칸 올라가면 성격이 바뀐다. 외부에 보이는 게시와 발송은 누군가 이미 읽었을 수 있어서 되돌려도 흔적이 남는다. 가장 위는 돈, 계약, 신청이다. 결제와 계약과 관공서 신청은 취소에도 비용과 절차가 든다. 게이트는 사다리가 성격을 바꾸는 곳, 곧 외부에 보이기 시작하는 칸 바로 앞에 세우면 좋다.
| 행동 | 예 | 기본 처리 | 사람 확인 시점 |
|---|---|---|---|
| 읽기 | 페이지 확인, 파일 읽기, 검색 | 맡긴다 | 결과를 받을 때 |
| 초안 작성 | 원고, 답글, 메일 초안 | 맡긴다 | 초안을 읽을 때 |
| 내 공간에 저장 | 허용 폴더에 파일 저장, 비공개 초안 | Guard 안에서 맡긴다 | 허용 폴더 밖이면 그때 묻는다 |
| 되돌릴 수 있는 변경 | 사이트 설정 수정, 비공개 글 수정 | 맡기고 결과를 확인한다 | 끝난 뒤 |
| 외부에 보이는 게시·발송 | 메일 발송, SNS 게시, 공개 발행 | 멈추고 묻는다 | 누르기 직전 |
| 돈·계약·신청 | 결제, 계약, 관공서 신청 | 멈추고 묻는다, 새 종류의 첫 회는 사람이 직접 | 단계마다 |
사다리는 세 축과 이렇게 맞물린다. 아래 세 칸은 작업 모드와 파일 권한만으로 충분히 지킬 수 있다. Guard에서 허용 폴더를 좁게 두면 에이전트는 읽고, 쓰고, 내 공간에 저장하는 데서 멈춘다. 위 세 칸은 대부분 브라우저 안에서 일어나는 일이라 폴더 목록으로는 막을 수 없다. 그래서 여기는 도구 규칙의 Ask와 Deny, 그리고 요청 속 멈춤 지점이 맡는다. 사다리의 칸마다 어느 축이 지키는지 한 번 짝지어 두면 빈틈이 어디인지 보인다.
11.5 요청 속 한 줄과 설정은 무엇이 다를까?
요청에 “누르기 전에 물어봐”라고 적는 것과 Ask 규칙을 두는 것은 무게가 다르다. 요청 속 문장은 에이전트가 지키려고 애쓰는 약속이다. 대부분 지켜지지만, 긴 작업 중에 앞부분이 요약되거나 지시가 여러 겹으로 쌓이면 흐려질 수 있다. 설정은 실행 단계에서 강제된다. Ask에 걸린 도구는 에이전트가 잊어도 멈추고, Deny에 걸린 도구는 에이전트가 원해도 실행되지 않는다. 그래서 두 가지를 함께 쓰는 편이 좋다. 요청 속 문장은 이번 일의 맥락에 맞는 멈춤 지점을 알려 주고, 설정은 어떤 일이 있어도 넘지 말아야 할 선을 지킨다. 5장과 6장에서 다룬 메모리와 스킬도 같은 자리에 선다. 메모리에 “메일은 보내기 전에 묻는다”라고 적어 두면 에이전트는 그 선호를 읽고 따르려 한다. 그래도 그 글은 권한 설정이 되지 못한다. 반드시 막아야 하는 일은 설정 화면에 둔다.
11.6 내가 게이트를 세운 순간들
내 게이트는 설계도에서 나오지 않았다. 일이 생길 때마다 하나씩 세웠다. 첫 번째는 메일이었다. 거래처 담당자에게 보낼 메일을 맡겼는데, 내가 잠깐 보류하라고 말하기 직전에 메일이 나가 버렸다. 내용에는 문제가 없었다. 그래도 다음부터는 확인을 받으라고 했고, 그 뒤로 바깥으로 나가는 메일은 보내는 순간에 내 명시적인 허락을 받는다. 더 큰 일을 통째로 맡긴 경우에도 발송 버튼 앞에서는 멈춘다. 두 번째는 소셜 계정이었다. 내 계정에 답글을 한꺼번에 올렸더니 한 독자가 AI냐고 묻는 댓글을 달았다. 그 뒤로 게시물과 답글은 초안으로 먼저 받아 내가 승인한 것만 올라간다. 두 경우 모두 사다리의 같은 칸, 외부에 보이는 칸에서 일어났다.
세 번째는 처음 하는 종류의 되돌릴 수 없는 행동이다. 8장에서 쓴 것처럼, 새 판매 사이트에서 처음 누르는 제출 버튼은 내가 직접 눌렀다. 그것이 제대로 처리된 것을 확인한 뒤에는 같은 종류의 반복 제출을 Aside에게 맡겼다. 첫 회에 게이트를 두고, 검증이 끝나면 게이트를 연다. 네 번째는 승인의 단위다. 나는 칸 하나하나를 승인하기보다 확인을 마친 값들을 표 하나로 받아 한 번에 승인하는 편을 좋아한다. 다섯 번째는 위험의 크기에 따른 속도 조절이다. 되돌릴 수 있고 다시 해도 비용이 적은 사이트 작업은 일단 시도하게 둔다. 돈, 계약, 관공서 신청은 조건을 하나씩 순서대로 맞춰 가며 조심스럽게 진행한다.
11.7 멈출 지점을 적은 요청 예시
게이트를 요청 안에 쓸 때는 멈출 곳을 동사로 적는다. “조심해서”보다 “발행 버튼을 누르기 전에 멈춰”가 분명하다. 아래 예시는 모두 가상 설정이다.
[멈춤 지점을 적은 작업 요청 예시, 가상 설정] 판매 사이트에 새 책 정보를 등록해 줘. 1. 원고 폴더의 정보 파일에서 제목, 가격, 소개를 읽어 표로 정리 2. 표를 보여 주고 내 답을 기다려 <- 멈춤 1 3. 승인하면 등록 화면에 입력만 하고 저장 전 화면을 캡처해서 보여 줘 <- 멈춤 2 4. 내가 "제출"이라고 답하기 전에는 제출 버튼을 누르지 마 5. 로그인 중 인증 메일이나 문자 확인이 필요하면 그 자리에서 멈추고 알려 줘
[초안만 받는 게시 요청 예시, 가상 설정] 이번 주 새 글을 소개하는 게시물 초안을 세 가지 써 줘. - 게시는 하지 마. 초안만 보여 줘 - 각 초안은 300자 이내, 링크는 https://example.com/sample-post/ - 내가 고른 번호만 게시하고, 게시 뒤 공개 주소를 알려 줘
설정 쪽 규칙은 개발자가 아니어도 말로 먼저 정리해 둘 수 있다. 아래는 규칙의 정확한 문법이 아니라, Allow, Ask, Deny 칸에 무엇을 둘지 생각해 보는 목록이다.
[Ask와 Deny에 둘 만한 것, 말로 정리한 목록] Ask(실행 전에 묻기) - 메일이나 메시지를 보내는 도구 - 허용 폴더 밖의 파일을 읽거나 고치는 일 - 파일이나 폴더를 지우는 명령 - 인터넷에서 받은 프로그램을 설치하거나 실행하는 명령 Deny(실행 전에 거부) - 결제와 송금 - 개인 문서 폴더처럼 에이전트가 볼 일이 없는 곳의 수정 Allow(확인 없이 실행) - 페이지 읽기, 검색, 허용 폴더 안의 초안 저장
11.8 메일과 인증은 어떻게 다룰까?
프롤로그의 장면으로 돌아가 보자. 그날 Aside가 메일함에서 한 일만 떼어 보면 사다리의 가장 아래 칸, 읽기였다. 메일 하나를 찾아 읽은 것이다. 그런데 그 메일이 인증 메일이었기 때문에, 읽기 하나가 나를 증명하는 절차 전체를 대신한 셈이 되었다. 메일함은 사다리의 칸으로 재기 어려운 곳이다. 그래서 메일과 인증은 따로 떼어 설계하는 편이 좋다. 허용한다면 내가 연락이 닿는 때로 한정하고, 할 수 있으면 그 자리에서 먼저 묻게 한다. 위 예시의 5번 줄이 그 설계를 요청으로 옮긴 것이다. 인증 코드를 누가 입력하든, 그 순간을 내가 알고 있어야 한다.
11.9 작업 중에 무엇이 밖으로 나가나
권한과 함께 알아 둘 것이 하나 더 있다. Aside의 개인정보 처리방침에 따르면, 작업을 실행하는 데 쓰이는 외부 모델 제공자는 작업에 필요한 만큼의 맥락을 받는다. 내가 쓴 요청, 도구 실행 결과, 선택된 스냅숏이나 스크린숏, 파일이 여기에 들어간다. 제3의 웹사이트는 내가 직접 조작했을 때 받았을 정보를 받는다. 앞 장들에서 이 이야기를 이곳으로 미뤘다. 그러니 메일함이나 개인 문서를 작업에 열어 주는 일은 권한의 문제이면서 동시에 무엇을 모델에게 보여 줄지의 문제다. 볼 필요가 없는 폴더를 파일 권한 목록에서 빼 두면 두 가지가 함께 좁아진다.
11.10 멀리서 승인하기
게이트가 멈추면 작업은 내 승인이나 답을 기다린다. 컴퓨터 앞이라면 브라우저 화면에 뜨는 팝오버에서 승인하거나 거부하고, 초안 검토는 작업 상세 화면에서 연다. 기다리는 동안 메시지를 더 보내면 설정에 따라 줄을 서거나(Queue) 진행 중인 작업의 방향을 바로 조정한다(Steer). 나는 밖에 있을 때 텔레그램으로 승인한다. 9월 19일 업데이트 뒤로는 Guard 승인 카드가 대화창에 바로 뜨고, 카드가 내 답을 기다리는 동안에도 /stop이 먹힌다. 루틴에도 선이 있다. 루틴은 그것을 만드는 작업보다 높은 권한 모드를 받을 수 없다. 내 환경에서도 더 높은 모드로 루틴을 만들려는 시도가 거부되는 것을 확인했다. 게이트를 세워 두면 멀리 있어도 맡길 수 있고, 멈춰야 할 때 확실히 멈춘다.
남은 물음은 컴퓨터 쪽이다. 게이트가 아무리 잘 서 있어도, 노트북 뚜껑을 닫는 순간 그 앞에서 기다리던 작업도 함께 잠든다. 그럼 노트북을 닫으면 누가 일하나. 12장은 거기서 시작한다.
이 장의 확인 범위
기능 설명은 2026년 9월 26일에 확인한 Aside 도움말, 개인정보 처리방침, 변경 기록을 기준으로 했다. 이후 화면 이름이나 동작은 바뀔 수 있다.
- 설정 파일에서 본 값(도구 규칙 기본 허용, 허용 폴더 밖 읽기·쓰기 묻기, 결제 기능 꺼짐과 50달러 한도 칸, 소통 기능 꺼짐, 화면 맥락 인식 꺼짐)은 내 환경의 관찰이며 모든 사용자의 기본값이라고 확인한 것은 아니다.
- 루틴 권한 모드 제한은 내가 겪은 거부를 바탕으로 적었다.
- 도구 규칙의 정확한 작성 문법은 확인하지 않았다. 11.7의 목록은 말로 정리한 예시이며 그대로 입력하는 규칙이 아니다.
- 요청 속 지시가 흐려질 수 있다는 설명은 일반적인 주의다. 확실히 막아야 하는 일은 설정으로 두는 것을 전제로 했다.
- 윈도우에서 차이가 없었다는 것은 내 사용 경험이며, 모든 항목을 나란히 비교한 것은 아니다.
- 그림 11-1과 11-2는 실제 화면이며 경로의 사용자 이름을 가렸다. 그림 11-3은 설명용 도식이다. 요청 예시의 문구와 주소는 가상이다.
참고한 자료
2026년 9월 26일 확인. 보안과 권한 도움말 · 문제 해결 도움말 · 개인정보 처리방침 · Aside 변경 기록
다음 글: 12장 · 노트북을 닫으면 누가 일하나
이전 글: 10장 · 텔레그램으로 지시하고 결과 받기
『Aside 브라우저 사용설명서』 연재 목록
저자의 실제 사용 경험과 Aside 도움말을 바탕으로 AI의 도움을 받아 작성·편집했습니다. 초판 선공개 원고 v1.0.