나만의 Agent Skills 시스템 설계하기
책의 마지막 장에서는 이제 남의 예시를 구경하는 자리에서 내려와, 내 책상 위로 돌아온다. 앞 장들에서 우리는 Agent Skill이 무엇이고, 어떻게 만들고, 어떻게 평가하고, 어떻게 운영하는지 살펴봤다. 이제 남은 질문은 하나다. 그래서 내 일에는 무엇을 어떻게 붙일 것인가?
이 질문이 중요하다. Agent Skills의 진짜 가치는 멋진 데모를 복제하는 데 있지 않다. 내 업무의 반복, 내 팀의 판단 기준, 내 조직의 예외 규칙을 담아내는 데 있다. Agent Skills는 원래부터 범용 지식을 더하는 장치라기보다, 절차적 지식과 현장 맥락을 필요할 때만 불러오는 구조로 설계되었다.12 그래서 마지막 장의 목표는 단순하다. 독자가 "좋은 Skill이 뭔지 안다"에서 멈추지 않고, "내가 어떤 Skill 묶음부터 만들지 안다"까지 가는 것이다.
시스템으로 본다는 것은 Skill 몇 개를 모은다는 뜻이 아니다
초보자는 보통 Skill을 하나의 파일이나 하나의 기능으로 생각한다. 하지만 실제로 오래 쓰는 사람은 Skill을 시스템으로 본다. 시스템이라는 말이 거창하게 들릴 수 있지만, 뜻은 의외로 소박하다. 일이 들어오면 어떤 Skill이 불리고, 무엇을 읽고, 어떤 도구를 쓰고, 어디까지 자동으로 하고, 어디서 사람이 확인하는지를 미리 정해 두는 것이다.
예를 들어 "회의록 정리" Skill 하나만 있다고 해보자. 처음에는 꽤 유용하다. 그런데 조금 지나면 이런 요구가 붙는다. 중요한 액션 아이템만 뽑아 달라, 담당자별로 나눠 달라, 지난 회의 결정사항과 비교해 달라, 노션 형식으로 바꿔 달라. 이때마다 하나의 Skill에 계속 덧칠하면, 결국 만능 리모컨처럼 버튼은 많고 누를수록 헷갈리는 상태가 된다.
그래서 시스템 설계의 출발점은 "무엇을 더 만들까?"가 아니라 "어떤 경계로 나눌까?"다. Agent Skills는 폴더 단위의 패키지로 구성되고, 이름과 설명만 먼저 노출한 뒤 필요할 때만 자세한 내용을 읽는 점진적 공개 방식을 쓴다.23 이 구조는 곧 설계 원칙을 하나 알려 준다. 처음부터 모든 지식을 한 Skill에 밀어 넣지 말고, 작게 나눠 연결하라.
첫 번째 질문: 내 업무에서 반복되는 마찰은 어디에 있나
나만의 시스템은 멋진 기술 스택에서 시작하지 않는다. 짜증 나는 반복에서 시작한다. 하루나 일주일을 돌아보며 생각해 보자. 자꾸 다시 설명하는 일, 매번 같은 자료를 찾는 일, 산출물 형식을 맞추느라 시간을 쓰는 일, 검토 기준이 사람마다 달라지는 일이 있을 것이다.
이런 마찰은 Skill 후보가 되기 좋다. 특히 다음 성질을 가진 업무는 시작점으로 훌륭하다.
자주 반복된다.
절차는 있는데 머릿속에만 있다.
참고 자료나 템플릿이 있다.
결과가 어느 정도 좋고 나쁨으로 평가된다.
반대로 너무 드문 일, 성공 기준이 너무 모호한 일, 매번 완전히 새로 탐색해야 하는 일은 첫 Skill로는 좋지 않다. 실제 가이드들도 복잡한 시스템으로 바로 뛰어들기보다, 먼저 단일 에이전트나 작은 구조에서 시작하고 필요할 때만 확장하라고 권한다.45
쉽게 말해, 첫 Skill은 인생을 바꾸는 마법이어야 할 필요가 없다. 매주 나를 귀찮게 하는 일 하나면 충분하다.
두 번째 질문: 이 일에서 모델이 판단할 것과 판단하지 말아야 할 것은 무엇인가
좋은 시스템 설계는 능력을 더하는 일인 동시에, 자유를 줄이는 일이기도 하다. 이 점은 많은 초보자가 의외로 늦게 배운다. 모델이 똑똑하다고 해서 모든 결정을 맡기면, 처음엔 유연해 보이지만 나중에는 들쭉날쭉해진다.
좋은 Skill 설계 원칙 중 하나는 에이전트가 결정하면 안 되는 것을 먼저 정하는 것이다.6 점수 계산, 파일 형식, 체크리스트 항목, 명령 실행 순서처럼 일관성이 중요한 것은 스크립트, 템플릿, 고정 규칙으로 빼는 편이 낫다. 반대로 문맥 해석, 설명, 우선순위 제안, 초안 작성처럼 상황에 따라 달라져야 하는 것은 에이전트가 맡는 편이 좋다.6
이 구분은 나만의 시스템을 설계할 때 특히 중요하다. 예를 들어 영업 미팅 후속 메일 시스템을 만든다고 해보자. 고객 톤과 대화 맥락에 맞게 메일 초안을 쓰는 것은 모델이 잘할 수 있다. 하지만 CRM 필드명, 단계별 상태값, 메일 제목 형식, 누락 체크 항목은 모델이 매번 창의력을 발휘하면 오히려 사고가 난다. 그 부분은 고정해야 한다.
즉, 내 시스템을 설계할 때는 각 Skill마다 이렇게 물으면 된다. "여기서 똑똑해야 하는 부분은 어디고, 여기서 고정돼야 하는 부분은 어디인가?" 이 질문 하나가 Skill의 품질을 꽤 많이 바꾼다.
세 번째 질문: 업무를 Skill 하나로 끝낼 것인가, Skill 묶음으로 나눌 것인가
여기서 많은 사람이 갈림길에 선다. 작은 일을 작은 Skill 하나로 만들면 될 것 같은데, 또 실제 업무는 생각보다 연결되어 있다. 그렇다면 언제 묶고 언제 나눌까?
가장 쉬운 기준은 입력, 판단 기준, 산출물이다. 이 셋이 비슷하면 한 묶음으로 가져가고, 셋 중 둘 이상이 다르면 분리하는 편이 좋다.
예를 들어 콘텐츠 팀의 업무를 보자. 아이디어 발굴, 초안 작성, 브랜드 톤 교정, 발행 전 체크는 서로 이어져 있지만, 실제로는 서로 다른 능력을 요구한다. 아이디어 발굴은 발산이 중요하고, 초안 작성은 구조가 중요하고, 브랜드 톤 교정은 금지 표현과 스타일 규칙이 중요하고, 발행 전 체크는 결정적 검증이 중요하다. 이걸 하나의 거대 Skill로 만들면, 결국 설명도 길어지고 활성화 조건도 흐려진다.
반대로 "주간 회고 정리"처럼 입력도 늘 비슷하고 산출물도 정해져 있고 판단 기준도 거의 같다면, 하나의 Skill로 시작하는 편이 낫다.
중요한 것은 처음부터 완벽한 분해를 하려 하지 않는 것이다. 실제 현장 문서들도 하나의 범용 설계보다, 적절한 패턴을 선택하고 주기적으로 다시 검토하며 발전시키는 접근을 권한다.47 시스템 설계는 한 번에 끝나는 건축이 아니라, 살면서 벽을 옮기는 집수리에 가깝다.
가장 현실적인 출발점: 씨앗 번들부터 만든다
처음부터 "나만의 Agent OS"를 만들겠다고 달려들면 십중팔구 지친다. 대신 씨앗 번들을 만드는 편이 훨씬 낫다. 씨앗 번들이란, 내 업무에서 가장 자주 이어서 쓰는 3~5개의 Skill 묶음이다.
이 번들의 조건은 단순하다. 혼자 자주 쓰고, 서로 연결되고, 효과를 체감하기 쉬워야 한다. 예를 들어 직무별로 이런 식의 씨앗 번들을 상상해 볼 수 있다.
1인 마케터의 씨앗 번들
아이디어 정리 Skill
블로그 초안 작성 Skill
브랜드 톤 교정 Skill
게시 전 체크 Skill
PM의 씨앗 번들
회의 요약 Skill
요구사항 정리 Skill
이슈 우선순위화 Skill
주간 공유문 작성 Skill
개발자의 씨앗 번들
이슈 재현 정리 Skill
코드 수정 계획 Skill
PR 설명 작성 Skill
배포 전 점검 Skill
이런 묶음이 좋은 이유는 Skill 하나의 품질보다 흐름 전체의 마찰 감소를 느끼게 해주기 때문이다. Agent Skills는 원래 다양한 제품과 환경에서 재사용 가능한 포터블 패키지로 설계되었고, 여러 Skill을 조합해 복합 작업을 수행하는 데 강하다.12
처음 시스템을 설계할 때는 "가장 멋진 Skill"보다 "가장 자주 이어 붙는 Skill들"을 고르는 편이 낫다.
시스템의 뼈대는 보통 세 층으로 나누면 편하다
개인용이든 팀용이든 오래 가는 Agent Skills 시스템은 대체로 세 층으로 정리하면 관리가 쉽다.
첫 번째는 핵심 실행 Skill이다. 실제 업무 산출물을 직접 만드는 Skill이다. 예를 들어 초안 작성, 버그 재현, 회의 요약, 비용 검토 같은 것이 여기에 들어간다.
두 번째는 지원 Skill이다. 스타일 가이드, 정책 참조, 형식 변환, 분류 규칙처럼 여러 실행 Skill이 함께 참조하는 공통 지식이다. 이런 지식은 항상 켜두기보다 필요할 때 불러오는 편이 효율적이다. Agent Skills의 점진적 공개 구조가 바로 이 상황에 잘 맞는다.23
세 번째는 검증 Skill이다. 결과를 확인하고 수정 방향을 알려 주는 Skill이다. 생성만 있고 검증이 없으면, 시스템은 빠르게 뭔가를 많이 만들지만 점점 믿기 어려워진다. 그래서 마지막 장에서는 꼭 말하고 싶다. 생성 Skill만 모아도 시스템은 되지 않는다. 검증 Skill이 들어와야 비로소 운영 체계가 된다.
이 세 층은 아주 거창한 아키텍처가 아니다. 오히려 내 일을 작게 나눠 보는 가장 현실적인 방법이다. 가령 "제안서 작성" 시스템이라면, 실행 Skill은 제안서 초안 작성이고, 지원 Skill은 고객 정보 정리와 브랜드 메시지 참조이고, 검증 Skill은 누락 항목 점검과 톤 검토가 된다.
Skill 이름보다 더 중요한 것은 트리거 문장이다
Skill을 설계할 때 사람들은 폴더 구조나 파일명에 먼저 신경을 쓴다. 물론 중요하다. 하지만 실제로 시스템을 잘 굴리려면, 그보다 먼저 어떤 요청이 들어오면 이 Skill이 켜져야 하는가를 명확히 해야 한다.
여러 구현과 가이드에서 공통으로 강조하는 점도 설명의 구체성이다. Skill의 이름과 설명은 단순 홍보 문구가 아니라, 에이전트가 이 Skill을 선택할지 판단하는 라우팅 신호다.138 따라서 "문서 작업 도우미" 같은 이름은 너무 넓다. "회의록에서 결정사항과 담당자별 액션 아이템을 추출해 주간 보고 형식으로 정리" 정도는 되어야 실제 업무에서 잘 붙는다.
좋은 시스템 설계를 하려면 각 Skill에 대해 최소한 세 가지 트리거를 적어 보는 것이 좋다.
사용자가 실제로 할 법한 요청 문장
이 Skill이 특히 빛나는 상황
비슷해 보이지만 사실은 다른 Skill로 가야 하는 상황
이 작업은 사소해 보이지만, 나중에 Skill이 많아질수록 엄청난 차이를 만든다. 선택 기준이 흐리면 에이전트도 흐려지고, 결국 사용자는 "그냥 내가 직접 설명하는 게 낫네"라는 결론에 도달한다.
시스템의 규모는 단일 에이전트에서 시작하는 편이 대체로 낫다
이 책을 읽고 나면 멀티 에이전트가 꽤 멋져 보일 수 있다. 실제로 복잡한 업무에서는 라우팅, 병렬 처리, 평가 루프, 계층적 분해가 큰 힘을 발휘한다.45 하지만 내 시스템을 처음 설계할 때부터 거기까지 갈 필요는 없는 경우가 많다.
여러 실무 가이드는 공통적으로 "가능하면 단순하게 시작하라"고 말한다.45 이유는 간단하다. 작은 시스템일수록 무엇이 잘 되고 무엇이 안 되는지 보이기 때문이다. 반대로 처음부터 여러 에이전트와 복잡한 흐름을 얹으면, 실패 원인이 Skill인지 라우팅인지 메모리인지 도구인지 헷갈린다.
그래서 보통은 다음 순서가 좋다.
1단계: 단일 에이전트 + 3~5개 Skill
2단계: 공통 지원 Skill 분리
3단계: 검증 Skill 추가
4단계: 필요 시 라우팅 또는 병렬 구조 도입
이 순서가 좋은 이유는, 시스템의 복잡도를 사용량과 문제 크기에 맞춰 늘릴 수 있기 때문이다. 즉, 구조가 먼저가 아니라 문제가 구조를 부른다.
내 시스템의 설계도는 업무 지도에서 나온다
이제 조금 더 실제적으로 설계해 보자. 빈 종이에 "내 일"을 쓰고, 그 아래에 반복 업무를 쭉 적는다고 상상해 보자. 여기서 가장 중요한 것은 업무 목록이 아니라 업무 지도다.
업무 지도는 보통 네 구역으로 나눠 그리면 편하다.
입력이 들어오는 곳
판단이 일어나는 곳
산출물이 나가는 곳
검토와 수정이 일어나는 곳
예를 들어 채용 담당자의 일을 그리면, 입력은 이력서와 채용 공고, 판단은 적합성 평가와 인터뷰 질문 준비, 산출물은 후보자 요약과 면접 피드백, 검토는 편향 점검과 누락 확인이 된다. 이 지도를 그려 보면 Skill 후보가 자연스럽게 보인다. "이력서 요약 Skill", "인터뷰 질문 생성 Skill", "면접 피드백 정리 Skill", "평가 기준 일관성 점검 Skill" 같은 식이다.
이 방식의 장점은 Skill을 기능 중심이 아니라 업무 흐름 중심으로 설계하게 만든다는 점이다. 그러면 시스템이 기술 장난감이 아니라 실제 일의 보조 구조가 된다.
좋은 개인 시스템은 공용 규칙과 개인 취향을 분리한다
나만의 시스템을 설계할 때 흔히 생기는 문제는, 개인의 선호와 팀의 규칙이 뒤섞이는 것이다. 예를 들어 나는 짧은 문장을 좋아하지만, 팀은 공식 문서에서 더 정중한 톤을 원할 수 있다. 나는 체크리스트를 간단히 쓰고 싶지만, 조직은 필수 항목을 더 요구할 수 있다.
이럴 때는 Skill을 두 층으로 나누면 편하다. 하나는 팀 또는 조직의 공용 규칙이다. 다른 하나는 개인 작업 스타일이다. Microsoft의 Skills 문서도 여러 디렉터리에서 Skill을 함께 검색하고 조합하는 방식을 지원한다.3 이 구조를 개념적으로 차용하면, 내 시스템 안에서도 "회사 기본 Skill", "팀 Skill", "내 개인 Skill"을 나눠 생각할 수 있다.
예를 들어 문서 작성 시스템이라면, 회사 Skill은 브랜드 톤과 보안 규칙을 담고, 팀 Skill은 문서 템플릿과 검토 절차를 담고, 개인 Skill은 내가 좋아하는 초안 방식이나 정리 습관을 담는 식이다. 이 분리가 잘 되어 있으면, 팀이 바뀌거나 도구가 바뀌어도 내 시스템을 쉽게 재조합할 수 있다.
성장하는 시스템은 로드맵이 있다
Agent Skills 시스템은 한 번 만들어 두고 끝나는 정원 자동물주기가 아니다. 시간이 지나면 일이 바뀌고, 팀이 바뀌고, 정책이 바뀌고, 모델도 바뀐다. 그래서 마지막 장의 핵심은 "지금 무엇을 만들까"뿐 아니라 "어떻게 자라게 할까"다.
가장 쉬운 로드맵은 3단계로 생각하는 것이다.
1단계: 생존 단계
이 단계의 목표는 크지 않다. 나를 가장 자주 괴롭히는 반복 업무 몇 개를 안정화하는 것이다. Skill 수는 적고, 범위도 좁다. 대신 트리거가 분명하고, 결과 형식이 선명해야 한다. 여기서는 멋보다 재사용성이 중요하다.
2단계: 정리 단계
어느 정도 쓰다 보면 공통 규칙이 보인다. 여러 Skill이 같은 템플릿, 같은 정책, 같은 스타일 가이드를 참조하고 있다는 사실이 드러난다. 이때 공통 자산을 지원 Skill로 빼고, 검증 Skill을 붙인다. 구조가 조금씩 "개별 도우미"에서 "작은 체계"로 바뀌기 시작한다.
3단계: 확장 단계
이 단계에서는 라우팅, 병렬 평가, 메모리, 워크플로 연동, 사람 승인 지점 같은 요소가 들어올 수 있다. 다만 이 확장은 사용량과 위험도에 따라 가야 한다. 구조화된 설계 프레임워크를 강조하는 가이드들도, 처음부터 모든 것을 설계하라는 뜻이 아니라 운영과 확장이 필요해지는 시점에서 의도적으로 설계하라고 말한다.7
이 3단계 로드맵의 좋은 점은 욕심을 조절해 준다는 것이다. 처음부터 20개 Skill을 만들겠다고 하면, 만들기 전에 지친다. 하지만 "이번 달엔 씨앗 번들 4개", "다음 달엔 공통 검증 추가"처럼 나누면 훨씬 현실적이다.
작은 예시: 한 사람의 시스템은 이렇게 자란다
조금 더 감을 잡아 보자. 프리랜서 콘텐츠 기획자 민지를 상상해 보자. 민지는 매주 고객 인터뷰 녹취를 정리하고, 블로그 초안을 쓰고, SNS용 짧은 문구를 만들고, 마지막으로 고객 톤에 맞는지 점검한다.
처음에 민지는 "콘텐츠 작성 Skill" 하나로 시작했다. 하지만 곧 문제가 생겼다. 인터뷰 정리와 블로그 초안은 필요한 자료도 다르고 판단 기준도 달랐다. 그래서 시스템을 네 개로 나눴다. 인터뷰 핵심 추출 Skill, 블로그 구조 설계 Skill, SNS 재가공 Skill, 브랜드 톤 검토 Skill.
한 달 뒤에는 또 다른 문제가 보였다. 각 Skill이 같은 브랜드 가이드를 중복해서 설명하고 있었던 것이다. 그래서 브랜드 가이드를 지원 Skill로 분리했다. 이후에는 블로그와 SNS가 모두 이 지원 Skill을 참조하도록 바꿨다.
그다음에는 검증이 필요해졌다. 초안은 빨라졌지만, 빠르게 틀리는 경우도 생겼다. 그래서 "금지 표현 점검 Skill"과 "게시 전 누락 체크 Skill"을 붙였다. 이때부터 민지의 시스템은 단순히 글을 빨리 쓰는 도구가 아니라, 일관된 품질을 유지하는 작업 체계가 되었다.
이 예시에서 중요한 것은 대단한 기술이 아니다. 작은 묶음으로 시작했고, 중복을 발견해 지원 Skill로 분리했고, 마지막에 검증을 붙였다는 점이다. 대부분의 개인 시스템은 이런 식으로 자란다.
팀으로 커질 가능성이 있다면 처음부터 아주 조금만 준비해 두자
지금은 개인용으로 시작하더라도, 어떤 Skill은 생각보다 빨리 팀 자산이 된다. 그래서 처음부터 딱 세 가지만 준비해 두면 나중이 편하다.
이름과 설명을 구체적으로 쓴다.
입력과 출력 예시를 남긴다.
변경 이유를 짧게 기록한다.
이 세 가지는 사소해 보여도 재사용성과 유지보수성에 큰 차이를 만든다. Agent Skills는 원래 조직 지식을 버전 관리되는 패키지로 다루기 좋게 만드는 개념이기도 하다.16 처음엔 나 혼자 쓰더라도, 나중에 다른 사람이 읽을 수 있는 형태로 적어 두면 Skill이 갑자기 팀의 언어가 된다.
흔한 실패: 내 시스템을 만들었는데 결국 안 쓰게 되는 이유
마지막 장이니 솔직하게 말해 보자. 많은 Agent Skills 시스템은 기술적으로 실패하기보다, 생활 속에 못 들어와서 실패한다.
가장 흔한 이유는 너무 크게 시작하는 것이다. 둘째는 Skill 경계가 흐려서 뭐가 언제 켜져야 하는지 모르는 것이다. 셋째는 검증 없이 생성만 붙여 놓는 것이다. 넷째는 고정해야 할 규칙까지 모델의 즉흥성에 맡기는 것이다. 다섯째는 실제 내가 쓰는 문장과 맞지 않는 설명을 적어 두는 것이다.
이 문제를 피하려면 화려한 설계보다 습관에 가까운 설계가 필요하다. 아침마다 열어 보는 문서, 매주 반복되는 요청, 늘 복사해 오던 체크리스트, 항상 다시 쓰던 문장을 기준으로 Skill을 만들어야 한다. 시스템은 감탄을 부르는 구조보다, 손이 먼저 가는 구조여야 오래 산다.
지금 바로 그릴 수 있는 나만의 설계 질문
이 장을 덮기 전에, 아래 질문에 답해 보자. 이 질문에 답하면 당신의 첫 Agent Skills 시스템은 이미 반쯤 설계된 셈이다.
내가 반복해서 설명하는 업무는 무엇인가?
그 업무의 입력은 무엇이고, 원하는 출력은 무엇인가?
여기서 고정해야 하는 규칙은 무엇인가?
여기서 모델이 유연하게 판단해야 하는 부분은 무엇인가?
이 업무를 한 Skill로 둘지, 두세 개로 나눌지 기준은 무엇인가?
공통으로 참조할 정책, 템플릿, 예시는 무엇인가?
결과를 검사할 검증 Skill은 무엇인가?
한 달 안에 만들 씨앗 번들은 어떤 3~5개인가?
이 질문들은 거창한 프레임워크가 아니다. 하지만 실제로는 이 정도만 분명해도, 남의 Skill을 가져다 쓰는 단계를 넘어 내 일에 맞는 체계를 만들 수 있다.
마지막 마무리: 좋은 Agent Skills 시스템은 나를 복제하지 않고, 나를 확장한다
이 책의 끝에서 꼭 남기고 싶은 말이 있다. 나만의 Agent Skills 시스템을 만든다는 것은 나를 파일로 압축해 넣는 일이 아니다. 내 업무의 강점은 남기고, 피로한 반복은 덜고, 중요한 판단은 더 또렷하게 만드는 일이다.
좋은 시스템은 나를 대체하는 척하지 않는다. 대신 내가 잘하는 일에 더 오래 집중하게 해 준다. 매번 설명하느라 새는 시간을 줄여 주고, 중요한 기준이 흐려지지 않게 붙잡아 주고, 작은 작업들을 묶어 더 큰 흐름으로 연결해 준다.
결국 Agent Skills의 마지막 목적은 이거다. 범용 AI를 쓰는 사람이 되는 것이 아니라, 내 일에 맞는 작업 체계를 설계하는 사람이 되는 것.
그리고 그 시작은 늘 작다. 오늘 가장 자주 반복한 일 하나를 골라, 그것을 첫 Skill로 적어 보는 것. 거기서부터 당신의 시스템이 자라기 시작한다.
참고
2Agent Skills for Context Engineering
3Agent Skills Microsoft Learn
4Choose a design pattern for an agentic AI system
5Agent system design patterns Databricks on AWS
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.