스킬은 반복하는 일의 절차를 문서로 적어 에이전트에게 가르치는 방법이다.
5장에서 메모리로 업무 맥락을 남겼다면, 이번 장에서는 일하는 순서 자체를 남긴다. 매주 같은 사이트에서 같은 형식으로 자료를 정리할 때마다 “제목과 날짜만 모아 줘, 날짜가 없으면 추측하지 마, 로그인 화면이 나오면 멈춰”라고 다시 말하고 있다면 스킬을 만들 때가 된 것이다. 스킬은 프로그램 코드가 아니라 평범한 문장으로 쓴 작업 지침서다. 이 장에서는 첫 스킬로 고를 일, 요청하는 방법, 완성된 예제 파일, 그리고 제대로 작동하는지 시험하는 방법까지 차례로 다룬다.
6.1 한 번의 요청, 메모리, 스킬, 루틴은 무엇이 다를까?
네 가지는 모두 AI에게 무언가를 전달하지만 맡는 역할이 다르다. 한 번의 요청은 지금 이 작업의 범위를 정한다. 오늘 볼 기간, 이번에만 적용할 예외가 여기에 들어간다. 메모리는 여러 작업에서 이어 쓸 맥락이다. 공식 도움말은 메모리를 다시 쓸 수 있는 맥락으로 설명한다. 이 책에서는 여기서 한 걸음 나아가 맥락은 메모리에, 반복 작업의 절차는 스킬에 나누어 담는 방식으로 정리한다. 무엇을 먼저 확인하고, 어떤 형식으로 결과를 내며, 어디서 멈추는지를 적은 작업 지침이다. 루틴은 정해진 시각이나 조건에 작업을 시작하게 하는 실행 장치다. 스킬이 일하는 방법이라면 루틴은 일을 시작하는 시점이다. 이 구분을 잡아 두면 무엇을 어디에 적을지 고민이 크게 줄어든다.
| 구분 | 담는 것 | 예시 | 이런 때 쓴다 |
|---|---|---|---|
| 한 번의 요청 | 이번 작업의 범위와 예외 | 이번 주 공지만, 5개까지 | 매번 달라지는 조건 |
| 메모리 | 여러 작업에 이어 쓸 맥락 | 보고서에는 확인일을 넣는 선호 | 업무 배경과 판단 기준 |
| 스킬 | 반복 작업의 절차와 결과 형식 | 수집, 제외, 검증 순서를 적은 지침 | 같은 순서를 여러 번 설명할 때 |
| 루틴 | 작업을 시작하는 시점 | 매주 월요일 오전에 실행 | 사람이 부르지 않아도 시작해야 할 때 |
어사이드 공식 블로그의 개발자용 글도 스킬을 같은 방향으로 소개한다. 팀마다 다른 브라우저 작업을 매번 프롬프트로 반복하는 대신 절차로 기록해 두면 점검 목록, 어떤 대시보드를 볼지, 무엇을 유효한 근거로 인정할지를 일정하게 유지할 수 있다는 설명이다. 요청할 때 특정 스킬을 쓰라고 명시할 수도 있다. 동시에 결과를 사람이 검토한다는 전제도 그대로다. 그 글의 예시는 개발 업무지만, 원리는 1인 사업자의 자료 정리에도 똑같이 적용된다.
6.2 어떤 일을 첫 스킬로 만들면 좋을까?
첫 스킬은 좁고, 자주 반복되며, 읽기만 하는 일에서 고른다. 좁다는 것은 입력과 결과가 분명하다는 뜻이다. “거래처 사이트 공지 목록에서 제목, 날짜, 주소를 표로 만든다”는 좁은 일이고, “업무 전반을 알아서 챙긴다”는 넓은 일이다. 자주 반복된다는 것은 같은 설명을 이미 두세 번 해 봤다는 뜻이다. 한 번도 직접 시켜 보지 않은 일은 절차를 적기 어렵다. 읽기만 한다는 것은 게시, 발송, 결제, 신청처럼 되돌리기 어려운 동작이 없다는 뜻이다. 절차가 조금 틀려도 결과를 다시 받으면 그만이므로, 스킬을 고쳐 가며 익히기에 부담이 적다. 공개 공지 목록 요약은 이 세 조건을 모두 갖춘 좋은 첫 연습 대상이다.
반대로 처음부터 피하는 편이 좋은 주제도 있다. 회사의 모든 업무 규정을 한 파일에 담은 만능 스킬, 로그인과 결제가 섞인 절차, 매번 판단이 크게 달라지는 창작 작업이다. 이런 일은 스킬이 길어질수록 어느 문장이 지금 적용되는지 흐려진다. 작은 스킬 하나가 확실히 작동하는 것을 확인한 뒤, 필요하면 비슷한 크기의 스킬을 하나씩 늘리는 편이 결과가 안정적이다.
6.3 스킬 파일은 어떤 구조로 되어 있을까?
스킬 하나는 폴더 하나이고, 그 안의 SKILL.md 파일이 중심이다. 파일 맨 위에는 머리말(frontmatter)이라 부르는 짧은 영역이 있고 여기에 name과 description 두 가지를 적는다. name은 소문자와 하이픈으로 된 짧은 이름이다. description은 이 스킬을 언제 써야 하는지 알려 주는 문장으로, 에이전트가 스킬을 고를 때 먼저 보는 부분이다. 그래서 적용 대상과 적용하지 않는 경우를 여기에 함께 적는다. 머리말 아래 본문에는 절차, 멈추는 조건, 결과 형식, 검증 방법을 쓴다. 본문은 스킬이 선택된 뒤에 읽히므로 “언제 쓰는가”를 본문에 다시 쓸 필요는 없다. 긴 기준표나 양식이 필요하면 references나 assets 폴더에 따로 두고 본문에서 가리킨다.
이 구조는 글쓰기 순서로 이해하면 쉽다. description은 표지의 요약, 본문은 작업 설명서, references는 부록이다. description만 보고도 이 일에 맞는 스킬인지 알 수 있게 쓰고, 본문에는 실제 작업 순서를 적고, 긴 기준표나 양식은 부록으로 빼 둔다. 그러면 에이전트가 먼저 설명을 보고 판단한 뒤 본문을 따르고, 필요한 경우 본문이 가리키는 보조 자료를 찾아볼 수 있다. 이렇게 층을 나누어 써 두면 본문이 짧고 분명해진다. 다만 이것은 작성과 읽기를 돕는 정리 방식이지, 실행할 때마다 정확히 이 순서와 분량으로만 읽힌다는 보장은 아니다. 스킬 작성자가 할 일은 설명을 층별로 나누어 적는 것이다.
public-notice-digest/ ├── SKILL.md 필수. 머리말과 절차 ├── references/ 선택. 긴 기준표, 용어 정리 ├── assets/ 선택. 결과 양식, 표 틀 └── scripts/ 선택. 꼭 필요할 때만
하위 폴더는 모두 선택이다. 이 장의 예제처럼 SKILL.md 한 파일로 충분한 경우가 많고, scripts는 스킬을 만드는 데 전제 조건이 아니다. 설치 안내서, 변경 기록, 별도 README 파일도 만들지 않는다. 스킬 폴더에는 다음 작업에 필요한 지침만 둔다.
스킬을 볼 때는 두 축을 따로 생각한다. 첫째는 소유와 위치다. 어사이드가 기본으로 제공하는 스킬과 사용자가 자기 계정에 만든 스킬이 있다. 집필에 사용한 macOS 환경에서는 계정 폴더 아래 skills 폴더에 builtin과 user가 나뉘어 있었고, 사용자 스킬은 ~/.aside/u/<계정번호>/skills/user/<스킬이름>/SKILL.md 형태였다. 이는 해당 환경의 관찰이며 모든 기기의 경로를 보장하지 않는다. 둘째는 적용 범위다. 특정 사이트 하나를 위한 스킬도 있고 여러 사이트에 두루 쓰는 스킬도 있다. 범위는 위치와 별개의 성질이다. 폴더 이름을 사이트 주소로 지었다고 그 사이트에서 저절로 켜지는 것도 아니고, 계정에 저장했다고 모든 작업에 항상 적용되는 것도 아니다. 어떤 작업에 쓰일지는 description과 그때의 요청에 달려 있다.
6.4 공지 목록 요약 스킬 예제
아래는 공개된 공지나 새소식 목록에서 제목, 게시일, 주소만 모아 표로 만드는 설명용 기본 예제다. 아래 내용을 복사해 SKILL.md라는 이름의 파일로 저장해 쓸 수 있다. 실제 계정의 스킬 폴더에 설치하거나 실행해 본 것은 아니다. 자기 업무에 맞게 고쳐 쓴 뒤 6.5의 요청으로 등록하면 된다.
--- name: "public-notice-digest" description: "공개 웹페이지의 공지·새소식 목록에서 제목, 게시일, URL만 모아 표로 정리할 때 사용한다. 사용자가 목록 주소와 조회 기간 또는 최대 개수를 알려 준 읽기 전용 조회에 한한다. 로그인이 필요한 페이지, 게시·댓글·신청·결제, 첨부파일 분석, 작성자나 연락처 같은 개인정보 수집 요청에는 사용하지 않는다." --- # 공개 공지 목록 요약 ## 입력 확인 1. 목록 페이지 URL, 조회 기간, 최대 항목 수를 확인한다. 2. 기간과 개수가 모두 없으면 먼저 묻는다. 사용자가 그대로 진행하라고 하면 첫 페이지의 최대 20개로 제한하고 그 사실을 결과 첫 줄에 적는다. 3. 목록 URL이 여러 개면 URL마다 따로 수집한 뒤 하나의 표로 합친다. ## 수집 절차 1. 목록 페이지를 열어 현재 화면에 보이는 항목을 읽는다. 2. 항목마다 제목, 게시일, 상세 페이지 URL 세 가지만 적는다. 본문, 작성자 이름, 연락처, 첨부파일 내용은 옮기지 않는다. 3. 목록에 게시일이 없으면 해당 상세 페이지를 한 번만 열어 확인한다. 그래도 날짜가 없으면 '미확인'으로 적고 추정하지 않는다. 4. 요청 기간 밖의 항목은 제외한다. 게시일이 '미확인'인 항목은 제외하지 말고 표 맨 아래에 둔다. 5. 다음 페이지는 요청한 기간이나 개수를 채울 때까지만 넘기며, 최대 3페이지를 넘지 않는다. 6. URL이 완전히 같은 항목은 하나만 남긴다. ## 멈추는 조건 - 로그인, 본인 인증, CAPTCHA, 결제, 게시, 댓글, 신청 단계가 나타나면 더 진행하지 않는다. - 페이지가 열리지 않거나 목록의 제목과 링크를 구분할 수 없으면 멈춘다. - 요청이 이 스킬의 범위를 벗어나면 범위 밖이라고 알리고 이 절차를 적용하지 않는다. - 멈출 때는 어디까지 확인했는지와 멈춘 이유를 적는다. ## 결과 형식 1. 첫 줄: 조회한 목록 URL, 적용한 기간 또는 개수 한도, 확인 시각. 2. 표: 번호 | 제목 | 게시일(YYYY-MM-DD 또는 미확인) | URL. 게시일 최신순으로 정렬하고 미확인 항목은 맨 아래에 둔다. 3. 표 아래: 확인한 항목 가운데 제외한 수와 이유(기간 밖, 중복), 미확인 항목 수, 멈춘 지점이 있으면 그 내용. 4. 3페이지 한도, 날짜 미확인, 남은 페이지 때문에 기간 전체를 다 봤는지 알 수 없으면 확인한 페이지와 항목 범위를 적고 기간 전체를 확인했다고 쓰지 않는다. 5. 목록에 없는 내용을 요약하거나 해석하지 않는다. ## 마무리 검증 - 표의 URL 가운데 최소 2개(전체가 2개 이하이면 전부)를 다시 열어 제목과 게시일이 맞는지 확인한다. - 표에 중복 URL이 없는지, 기간 밖 날짜가 섞이지 않았는지 확인한다. - 다시 열어 보지 못한 항목을 확인했다고 쓰지 않는다. 검증한 항목 수를 결과 끝에 적는다. - 결과 끝에 기간 전체를 확인했는지, 확인한 페이지와 항목 범위까지만 봤는지 한 줄로 적는다.
예제에서 눈여겨볼 곳은 세 군데다. description에는 할 일과 함께 하지 않을 일이 들어 있다. 로그인 페이지, 게시와 결제, 개인정보 수집을 제외해 두면 비슷해 보이는 요청이 들어와도 이 스킬이 엉뚱하게 쓰일 여지가 줄어든다. 본문의 멈추는 조건과 결과 형식은 판단이 갈릴 만한 지점을 미리 정해 둔 것이다. 날짜가 없을 때, 같은 주소가 두 번 나올 때, 기간을 말하지 않았을 때 어떻게 할지가 적혀 있으므로 결과를 같은 기준으로 정리하기 쉬워진다. 마지막 검증 항목은 에이전트가 스스로 결과를 한 번 더 대조하게 만든다. 머리말의 값은 모두 큰따옴표로 감쌌다. 어사이드 변경 기록에는 잘못된 머리말과 따옴표 없는 콜론 문제를 고친 내용이 있고, 기본 제공 스킬 작성 안내도 값을 큰따옴표로 감싸도록 권한다. 문장 안에 콜론이 들어가도 구조가 깨지지 않게 하는 습관이다.
6.5 스킬을 만들어 달라고 어떻게 요청할까?
파일을 직접 만들지 않아도 된다. 어사이드 변경 기록을 보면 6월 업데이트에서 사용자가 소유하는 스킬을 관리하고 대화에서 만드는 기능이 추가됐고, 7월에는 스킬 작성 도구가 기본 제공 스킬로 바뀌어 스킬 파일을 직접 쓸 수 있게 됐다. 그러니 대화창에서 무엇을 만들지 분명히 말하면 된다. 9월 변경 기록에 보이는 터미널 설치 명령은 외부 코딩 에이전트에 어사이드 브라우저 기능을 붙이는 용도라서, 계정 안에서 스킬을 만드는 데는 필요하지 않다. 메뉴 위치는 버전에 따라 달라질 수 있으므로 이 장에서는 화면 경로 대신 요청문을 기준으로 설명한다.
공개 공지 목록을 요약하는 스킬을 새로 만들어 줘. 이름은 public-notice-digest로 하고 내 계정의 사용자 스킬로 저장해 줘. 내용은 첨부한 예제 파일을 기준으로 하되, 다른 스킬은 수정하지 마. 만든 뒤 저장한 파일 위치와 전체 내용을 보여 주고, 머리말 형식 검사를 통과했는지 알려 줘.
요청에는 네 가지가 들어 있다. 새로 만든다는 사실, 이름과 저장 위치, 기준이 되는 내용, 그리고 결과를 보여 달라는 확인 요청이다. 예제 파일 없이 말로 설명할 때도 같은 틀을 쓴다. 어떤 일을, 어떤 입력으로, 어떤 결과 형식으로 하는지와 하지 않을 일을 순서대로 말한다. 답을 받으면 “만들었다”는 문장보다 보여 준 경로와 파일 내용을 본다. 머리말에 name과 description이 모두 있는지, 제외 조건이 빠지지 않았는지 확인한다. 이미 있는 스킬이라면 “새로 만들어 줘” 대신 “보여 줘”로 시작해 현재 내용부터 확인한다.
6.6 잘 만들었는지는 어떻게 시험할까?
시험은 세 단계로 나눈다. 첫째는 문법 검토다. 머리말이 규칙에 맞는지, 이름이 소문자와 하이픈으로 되어 있는지를 본다. 스킬 작성 도구에는 머리말 형식을 검사하는 과정이 들어 있으므로 결과를 알려 달라고 하면 된다. 둘째는 종이 위의 시험이다. 가상의 입력을 놓고 이 스킬대로라면 어떤 결과가 나와야 하는지 미리 적는다. 셋째는 실제 작동 시험이다. 새 작업에서 공개 목록 하나로 요청해 보고, 에이전트가 스킬을 읽었는지와 결과가 약속한 형식을 지켰는지 확인한다. 문법이 맞다고 작동이 보장되지는 않고, 예상 출력을 적었다고 실제로 그렇게 나온다는 뜻도 아니다. 세 단계를 섞지 않는 것이 핵심이다.
| 시험 | 요청 예 | 기대하는 동작 |
|---|---|---|
| 정상 목록 | 이 공지 목록에서 이번 달 공지를 정리해 줘 | 스킬 사용, 기간 확인 항목과 날짜 미확인 항목을 구분한 4열 표, 첫 줄에 조건과 확인 시각, 끝에 검증 수 |
| 날짜 누락 | 게시일이 표시되지 않는 목록 | 상세 페이지를 한 번 확인, 없으면 미확인 표기, 표 맨 아래 배치 |
| 중복 주소 | 같은 공지가 상단 고정과 목록에 두 번 나옴 | URL이 같으면 하나만 남기고 제외 수에 중복으로 기록 |
| 범위 밖 | 이 공지에 댓글을 달아 줘 / 작성자 연락처를 모아 줘 | 이 스킬 절차를 적용하지 않고 범위 밖임을 알림, 게시나 수집을 하지 않음 |
종이 위의 시험은 아래처럼 적어 둘 수 있다. 가상의 주소와 제목으로 만든 예상 출력이며 실제로 실행해 얻은 결과가 아니다.
[예상 출력 예시, 가상 데이터] 조회 목록: https://example.com/notice | 기간: 2026-09-01~2026-09-30 | 확인 시각: (실행 시각) | 번호 | 제목 | 게시일 | URL | | 1 | 추석 연휴 휴무 안내 | 2026-09-22 | https://example.com/notice/103 | | 2 | 서비스 점검 안내 | 2026-09-10 | https://example.com/notice/102 | | 3 | 이용약관 개정 안내 | 미확인 | https://example.com/notice/099 | 제외(확인한 항목 기준): 기간 밖 2건, 중복 1건 / 미확인 1건 / 검증: 2건 재확인 확인 범위: 1~2페이지, 6개 항목. 날짜 미확인 항목이 있어 기간 전체 확인 여부는 미확정
실제 작동 시험에서는 요청문에 “public-notice-digest 스킬을 사용해”라고 명시하는 방법과, 스킬 이름 없이 평소처럼 부탁하는 방법을 모두 해 본다. 명시하지 않았을 때 쓰이지 않는다면 먼저 그 작업에서 스킬이 실제로 인식되고 읽혔는지 확인한다. 어떤 스킬을 참고했는지 물어보면 된다. 인식은 되는데 선택되지 않는다면 description이 먼저 점검할 후보다. 적용 대상을 더 분명한 말로 고친다. 반대로 관계없는 요청에 스킬이 끼어든다면 제외 조건을 보강한다. 이 책에서는 예제 파일의 구조와 머리말 규칙만 확인했고, 실제 계정에 등록해 작동을 시험한 결과는 싣지 않았다. 독자의 환경에서 위 표를 기준으로 직접 확인하기를 권한다.
6.7 스킬에 적으면 그대로 허락되는 것일까?
스킬은 절차이지 허가가 아니다. 어사이드 보안 도움말은 실제 권한을 텍스트 지시와 분리해 다룬다. 도구와 접근은 Allow, Ask, Deny로 정하고, 둘이 겹치면 Deny가 우선한다. 그러니 스킬에 “이 사이트에 게시해도 된다”고 적어도 권한 설정에서 막혀 있으면 게시되지 않는다. 반대로 스킬에 없는 도구나 로그인, 예약 실행 기능이 스킬 덕분에 생기지도 않는다. 현재 요청은 이번 작업의 범위를 정하고, 스킬은 그 범위 안에서 일하는 순서를 정한다고 이해하면 된다. 그래서 예제 스킬은 멈추는 조건을 따로 두어, 권한이 허용하더라도 로그인이나 결제 단계에서 멈추도록 스스로 범위를 좁혔다.
스킬 파일은 로컬에 저장되지만, 개인정보처리방침은 작업에 필요한 문맥이 호스팅된 모델 제공자에게 전달될 수 있다고 밝힌다. 로컬에 저장된다는 사실이 외부로 전달되지 않는다는 뜻은 아니다. 스킬에는 비밀번호, 고객 정보, 내부 문서 원문을 넣지 않고 절차와 기준만 적는다.
6.8 스킬은 언제 고치고 언제 새로 만들까?
같은 일의 결과가 조금 어긋날 때는 기존 스킬을 고치고, 다른 일이 생겼을 때는 새 스킬을 만든다. 공지 목록에 분류 열 하나를 더하는 것은 수정이다. 같은 사이트라도 가격표 숫자를 모으는 일은 입력, 결과, 검증 방법이 다르므로 새 스킬이 맞다. 고칠 때는 한 번에 조건 하나만 바꾼다. 날짜 형식과 제외 규칙과 결과 순서를 한꺼번에 바꾸면 다음 결과가 달라졌을 때 어느 변경 때문인지 알 수 없다. 조건 하나를 바꾸고 6.6의 시험을 다시 해 본 뒤 다음으로 넘어간다. 스킬이 모든 업무를 담는 회사 규정집처럼 커지면 description이 흐려지고 엉뚱한 요청에 끌려 들어가기 쉽다. 커졌다 싶으면 일의 단위로 나눈다.
public-notice-digest 스킬을 보여 주고 한 가지만 수정해 줘. 결과 표에 '분류' 열을 추가하고, 목록에 분류가 없으면 '미확인'으로 적게 해 줘. 다른 규칙은 바꾸지 마. 수정 전후로 달라진 줄만 보여 줘.
수정 이력은 스킬 안에 쌓지 않는다. “9월에 날짜 규칙을 바꿨다” 같은 기록은 다음 작업의 지침이 아니라 과거의 사실이다. 스킬에는 지금 따라야 할 규칙만 남기고, 언제 무엇을 왜 바꿨는지는 별도 메모나 작업 기록에 둔다. 5장의 메모리가 이런 경과를 담기에 알맞다.
6.9 다음 장: 절차를 정해진 때에 실행하기
스킬로 일하는 방법을 정했다면 남은 것은 언제 할지다. 공지 목록처럼 텍스트를 모으는 일은 필요할 때 부르면 되지만, 매주 같은 날 가격이나 판매량 같은 숫자를 모아 지난주와 비교하는 일은 시작 시점까지 정해 두어야 편하다. 7장에서는 이런 반복 숫자 수집을 루틴으로 맡기는 방법을 다룬다. 이번 장에서 만든 스킬처럼 좁은 범위와 멈추는 조건을 먼저 정해 두면 다음 장의 루틴도 훨씬 안심하고 맡길 수 있다.
확인한 공식 자료와 관찰 범위
2026년 9월 26일 확인. Aside 개발자용 블로그(팀별 브라우저 작업을 위한 스킬) · Aside 변경 기록(스킬 관리·작성 도구·머리말 수정) · 보안과 권한 안내 · 메모리 안내 · 개인정보처리방침. 동봉된 스킬 작성 안내와 예제 구조를 확인했으며, 실제 계정에 예제를 등록하거나 자동 실행을 시험하지는 않았다. 폴더 경로는 집필 환경의 관찰이며 보편적인 경로를 뜻하지 않는다. 메뉴 위치와 화면 경로는 이 장에서 확인하지 않았다.
다음 글: 7장 · 매일 같은 숫자를 긁어 시트에 쌓기
이전 글: 5장 · 메모리: 맥락을 가르치는 법
『Aside 브라우저 사용설명서』 연재 목록
공식 자료와 기본 제공 스킬 작성 안내를 확인하고 AI의 도움을 받아 작성·편집했습니다. 예제 스킬과 예상 출력, 구조도는 설명용이며 실제 계정에 설치하거나 실행한 결과가 아닙니다. 초판 선공개 원고 v1.0.