Agent Skills란 무엇인가
AI 에이전트를 처음 접할 때 많은 사람은 이렇게 생각한다. 모델이 똑똑해졌으니, 이제는 더 길고 정교한 프롬프트만 쓰면 복잡한 일도 꽤 잘 처리하겠지. 실제로 초반에는 어느 정도 맞는 말이다. 하지만 일을 반복해 보면 금세 다른 문제가 드러난다. 어떤 날은 그럴듯한 결과가 나오고, 어떤 날은 순서를 빼먹는다. 도구는 쓸 줄 아는데 언제 써야 하는지 애매해하고, 형식은 맞췄는데 회사 규칙은 놓친다. 똑똑한데도 믿고 맡기기 어렵다.
바로 이 지점에서 Agent Skills라는 개념이 필요해진다. Skill은 모델을 더 많이 아는 존재로 만드는 장치가 아니라, 더 안정적으로 일하는 존재로 만드는 장치다. 이 장에서는 그 경계를 먼저 분명히 잡아보려 한다. Skill이 정확히 무엇인지, 무엇이 아닌지, 어디까지를 Skill로 설계해야 하는지를 여기서 정해 두어야 이후의 설계가 흔들리지 않는다.
Agent Skills를 한 문장으로 정의하면
Agent Skills는 범용 LLM이나 에이전트에게 특정 업무를 안정적으로 수행하도록 가르치는 경량의 개방형 확장 단위다. 더 쉽게 말하면, "이 일을 이런 순서와 기준으로 하라"는 업무 매뉴얼을 에이전트가 실제로 읽고 재사용할 수 있는 형태로 묶어 둔 패키지라고 보면 된다.1
중요한 것은 Skill이 단순한 한 줄 지시문이 아니라는 점이다. 보통 하나의 Skill은 이름과 설명만 담고 끝나지 않는다. 최소한의 메타데이터와 핵심 지침이 들어 있는 SKILL.md를 중심으로, 필요하다면 스크립트, 참고 문서, 템플릿, 샘플, 브랜드 자산까지 함께 묶을 수 있다.12 그래서 Skill은 "좋은 프롬프트의 저장본"이 아니라, 재사용 가능한 워크플로 패키지에 가깝다.
예를 들어 "회의록을 정리해 줘"라는 요청이 있다고 해보자. 프롬프트만으로 처리하면 모델은 매번 다른 구조를 떠올릴 수 있다. 어떤 날은 잘 요약하고, 어떤 날은 액션 아이템을 빠뜨릴 수 있다. 반면 회의록 정리 Skill이 있다면 이야기가 달라진다. 발언을 요약하는 순서, 결정 사항을 분리하는 규칙, 미정 이슈를 표시하는 방식, 최종 출력 형식, 민감한 표현을 다듬는 기준까지 한 덩어리로 제공할 수 있다. 에이전트는 더 이상 즉흥적으로 회의록을 "창작"하지 않고, 정해진 절차를 "수행"하게 된다.
Skill의 핵심은 답변이 아니라 일하는 방식이다
많은 사람이 Skill을 "도구를 더 잘 쓰게 하는 기능" 정도로 이해한다. 절반만 맞는 말이다. Skill은 도구를 포함할 수 있지만, 본질은 도구 그 자체가 아니다. Skill의 핵심 역할은 무엇을 답할지를 알려주는 것이 아니라, 어떻게 일할지를 가르치는 데 있다.3
이 차이는 생각보다 크다. 사실 지식만 많다고 실무를 잘하는 것은 아니다. 실무에서는 대개 다음과 같은 요소가 함께 필요하다.
어떤 순서로 작업할지
어느 시점에 어떤 도구를 쓸지
애매한 경우 무엇을 우선할지
예외 상황에서 어디서 멈출지
마지막에 무엇을 검토할지
바로 이런 것이 절차적 지식이다. Skill은 이 절차적 지식을 에이전트가 쓸 수 있는 형태로 옮겨 놓는다. 그래서 같은 모델을 써도 Skill이 없는 에이전트는 똑똑한 인턴처럼 보이고, Skill이 잘 설계된 에이전트는 숙련된 실무자처럼 보일 수 있다.34
예를 들어 리서치 업무를 생각해 보자. Skill이 없는 에이전트는 검색 몇 번 하고 요약문을 멋지게 써 줄 수는 있다. 하지만 최신성 검증을 빼먹거나, 출처 신뢰도 기준이 없거나, 서로 충돌하는 자료를 정리하지 못할 수 있다. 반면 리서치 Skill이 있다면 질문 분해, 검색 키워드 확장, 출처 등급 평가, 날짜 확인, 중복 제거, 인용 기준, 최종 보고서 형식까지 한 흐름으로 실행할 수 있다. 이때 Skill은 "똑똑해 보이는 글"이 아니라 "검토 가능한 결과물"을 만들게 한다.
프롬프트와 Skill은 왜 다른가
프롬프트는 여전히 중요하다. 하지만 프롬프트와 Skill은 같은 층위의 도구가 아니다. 프롬프트가 한 번의 상호작용에서 모델의 응답 방향을 정하는 지시라면, Skill은 특정 업무를 반복 수행하기 위한 운영 규칙을 묶은 구조다.3
프롬프트는 대개 지금 이 대화에서 무엇을 하라고 말한다. 반면 Skill은 같은 유형의 일이 다시 들어왔을 때도 흔들리지 않게 만드는 재사용 단위다. 프롬프트는 대화에 붙여 넣는 요청이고, Skill은 에이전트가 필요할 때 불러오는 업무 패키지다.1
차이를 가장 쉽게 이해하는 방법은 이런 질문을 던져보는 것이다.
"이 지시를 다음 주에도, 다른 사람도, 다른 프로젝트에서도 그대로 반복해서 쓰고 싶은가?"
그렇다면 그것은 프롬프트가 아니라 Skill 후보일 가능성이 높다.
물론 프롬프트와 Skill은 경쟁 관계가 아니다. 실전에서는 둘이 함께 움직인다. 사용자는 프롬프트로 현재 요청을 전달하고, 에이전트는 그 요청이 특정 Skill과 맞는다고 판단하면 그 Skill을 활성화해 절차를 따른다. 즉 프롬프트는 현재의 의도이고, Skill은 재사용 가능한 업무 방식이다.
Custom GPT, GPT Actions, MCP와는 어떻게 구분할까
여기서 가장 많이 헷갈리는 것이 Skill과 다른 확장 방식의 관계다. 이름이 비슷해서 한 묶음처럼 보이지만, 실제로는 담당하는 역할이 다르다.
먼저 Custom GPT는 특정 페르소나, 기본 지침, 대화 성격을 미리 설정해 두는 방식에 가깝다. 쉽게 말해 "어떤 캐릭터와 기본 습관을 가진 AI인가"를 정하는 층이다. 반면 Skill은 그 위에서 "특정 업무를 어떤 절차로 처리할 것인가"를 정한다. Custom GPT가 기본 복장이라면, Skill은 특정 임무를 위한 작업 매뉴얼에 가깝다.
GPT Actions는 OpenAI 생태계에서 외부 API를 연결하는 방식이다. 보통 OpenAPI 스펙을 기반으로 HTTP API를 호출하게 만든다.5 이때 Actions가 제공하는 것은 주로 실행 경로다. 다시 말해 "이 API를 이렇게 부를 수 있다"는 능력이다. 하지만 그 API를 언제 호출해야 하는지, 어떤 순서로 다른 단계와 엮어야 하는지, 호출 실패 시 어떻게 우회할지는 별도의 설계가 필요하다. 그 설계를 담는 쪽이 Skill이다.
MCP는 더 넓은 범위의 오픈 프로토콜이다. 에이전트가 외부 도구와 데이터 소스에 연결되는 표준 인터페이스를 제공한다. JSON-RPC 기반으로 도구를 발견하고 호출하며, 특정 벤더에 묶이지 않는다는 점이 특징이다.56 쉽게 말해 MCP는 에이전트의 손을 바깥세계와 연결해 주는 표준 포트다.
이제 관계가 조금 선명해진다.
프롬프트는 지금 무엇을 요청하는가를 정한다.
Custom GPT는 기본 성격과 기본 설정을 정한다.
GPT Actions와 MCP는 외부 세계와 연결되는 실행 통로를 제공한다.
Skill은 그 위에서 어떤 절차와 판단 기준으로 일할지를 정의한다.
그래서 실전에서는 "절차는 Skill, 실행은 Action 또는 MCP"라는 조합이 자주 등장한다. 예를 들어 사내 보고서를 만드는 업무를 생각해 보자. 보고서에 어떤 항목을 넣고, 어떤 순서로 원자료를 정리하고, 어떤 표현을 금지하고, 어떤 품질 검사를 거칠지는 Skill이 담당한다. 반면 최신 매출 데이터를 CRM이나 데이터베이스에서 불러오는 연결은 MCP나 API Action이 담당한다.
핵심은 이것이다. Skill은 연결 기술이 아니라 업무 설계다. 반대로 MCP나 Actions는 업무 설계가 아니라 연결 기술이다. 둘은 비슷한 것이 아니라, 서로를 보완하는 다른 레이어다.
왜 Skill은 파일 시스템 기반 패키지로 설계되는가
Skill을 그냥 긴 텍스트 한 덩어리로 두지 않고 파일 시스템 기반 패키지로 만드는 이유는 운영성 때문이다. 실제 업무는 생각보다 많은 재료를 필요로 한다. 핵심 지침만으로 충분한 경우도 있지만, 대개는 긴 기준 문서, 샘플 출력, 계산 스크립트, 템플릿, 체크리스트가 함께 필요해진다. 이 모든 것을 하나의 프롬프트에 욱여넣으면 읽기 어렵고, 고치기도 어렵고, 재사용도 어렵다.
파일 시스템 기반 Skill은 이 문제를 정리해 준다. 중심에는 SKILL.md가 있고, 긴 참고 문서는 references/, 반복 계산이나 검증 코드는 scripts/, 템플릿과 브랜드 자산은 assets/에 분리할 수 있다.12 이렇게 하면 세 가지 이점이 생긴다.
첫째, 버전관리가 쉬워진다. 팀이 같은 Skill을 함께 개선할 수 있고, 무엇이 언제 바뀌었는지 추적할 수 있다. 둘째, 이식성이 높다. 같은 Skill을 여러 에이전트 제품이나 여러 프로젝트에 옮겨 붙이기 쉽다. 셋째, 확장이 자연스럽다. 처음에는 SKILL.md 하나로 시작했다가, 업무가 복잡해지면 참고자료와 스크립트를 추가하는 식으로 점진적으로 키울 수 있다.
또 하나 중요한 이유는 컨텍스트 효율이다. Agent Skills는 보통 점진적 공개, 즉 progressive disclosure 방식으로 동작한다. 에이전트는 처음부터 모든 Skill의 전체 내용을 읽지 않는다. 먼저 이름과 설명 같은 가벼운 메타데이터만 보고 어떤 Skill이 관련 있는지 판단하고, 필요할 때만 전체 지침을 읽고, 정말 필요할 때만 참고자료나 스크립트까지 불러온다.12 덕분에 스킬 라이브러리가 커져도 컨텍스트 창을 무작정 잡아먹지 않는다.
이 구조는 마치 공구함과 비슷하다. 서랍 겉면에 라벨이 붙어 있어 어떤 공구가 있는지 알 수 있고, 작업이 생기면 그 서랍만 열고, 더 세부 부품이 필요하면 안쪽 칸을 꺼내 보는 식이다. 모든 공구를 책상 위에 늘어놓고 시작하는 방식보다 훨씬 실용적이다.
어떤 업무가 Skill에 적합한가
이제 가장 중요한 질문으로 들어가 보자. 모든 업무를 Skill로 만들 필요는 없다. Skill은 강력하지만, 만능 해법은 아니다. 무엇을 Skill로 만들지 판단하는 기준이 있어야 한다.
가장 실용적인 기준은 세 가지다. 반복성, 절차성, 검증 가능성이다.
반복성: 같은 종류의 일이 자주 들어오는가
먼저 반복성이 있어야 한다. 한 번 하고 끝나는 일이라면 굳이 Skill로 포장할 이유가 적다. 하지만 주간 보고서 작성, 회의록 정리, PR 리뷰, 채용 후보자 평가, 시장 리서치 요약처럼 비슷한 유형의 요청이 계속 들어온다면 이야기가 달라진다. 이때는 매번 프롬프트를 새로 쓰는 것보다 업무 방식을 패키지로 고정하는 편이 훨씬 낫다.
반복성은 단순히 "자주 한다"는 뜻만은 아니다. 입력은 조금씩 달라도 작업의 뼈대가 비슷해야 한다. 예를 들어 고객 문의 답변은 매번 내용이 달라도, 문의 분류 → 정책 확인 → 답변 초안 작성 → 금지 표현 검토 → 에스컬레이션 여부 판단이라는 흐름은 반복된다. 이런 일이 Skill에 잘 맞는다.
절차성: 순서와 판단 기준을 문서화할 수 있는가
둘째는 절차성이다. 어떤 일을 잘 수행하기 위해 명확한 순서가 있거나, 중간중간 판단 기준이 있다면 Skill로 만들 가치가 커진다. 반대로 매번 완전히 다른 사고 실험이 필요한 일은 Skill화하기 어렵다.
좋은 Skill 후보는 보통 이런 질문에 답할 수 있다.
시작 전에 무엇을 확인해야 하는가?
어떤 순서로 단계를 진행해야 하는가?
중간에 무엇을 기준으로 갈라지는가?
실패 위험이 큰 지점은 어디인가?
언제 사람에게 확인을 요청해야 하는가?
이 질문에 답할 수 있다면, 이미 절차의 윤곽이 잡혀 있다는 뜻이다. Skill은 바로 그 윤곽을 에이전트가 실행 가능한 지침으로 바꾸는 장치다.
검증 가능성: 결과가 맞는지 확인할 수 있는가
셋째는 검증 가능성이다. 이 기준이 빠지면 Skill은 금세 "긴 지시문"으로 전락한다. 좋은 Skill은 결과물이 잘 되었는지 확인할 방법이 있어야 한다. 형식 체크리스트일 수도 있고, 테스트 케이스일 수도 있고, 필수 항목 누락 검토일 수도 있다.
예를 들어 문서 작성 Skill이라면 제목 구조, 요약 길이, 액션 아이템 존재 여부 같은 점검 기준을 둘 수 있다. 데이터 분석 Skill이라면 단위 변환 확인, 누락값 처리 여부, 이상치 검토 여부를 점검할 수 있다. 코딩 Skill이라면 테스트 통과, 린트 통과, 보안 체크 항목 적용 여부로 검증할 수 있다.
검증 가능성이 중요한 이유는 Skill의 목표가 '한 번 멋지게 해내는 것'이 아니라 '계속 비슷한 품질로 해내는 것'이기 때문이다.
Skill로 만들지 말아야 할 일도 있다
Skill이라는 개념을 이해하면 오히려 모든 것을 Skill로 만들고 싶어진다. 하지만 그 유혹을 조심해야 한다. Skill이 맞지 않는 작업도 분명히 있다.
대표적으로 단발성 질의는 Skill 우선 대상이 아니다. "이 개념이 뭐야?", "이 기사 핵심만 알려줘"처럼 한 번 답하고 끝나는 요청은 굳이 별도 Skill 없이 일반 대화로 충분할 수 있다.
탐색적 브레인스토밍도 마찬가지다. 아이디어를 넓게 퍼뜨리고, 예상 밖의 방향으로 튀어야 하는 작업은 지나치게 강한 절차가 오히려 창의성을 꺾는다. 이런 경우에는 느슨한 가이드만 두고 자유 대화로 푸는 편이 더 낫다.
맥락이 계속 바뀌는 작업도 Skill화가 어렵다. 예를 들어 이해관계자가 시시각각 바뀌고, 목표 정의 자체가 계속 흔들리는 초기 전략 회의는 안정된 절차보다 즉흥적 조율이 중요하다. 이런 일은 Skill보다 사람의 상호작용과 판단이 더 중요하다.
또 어떤 작업은 Skill보다 도구 연결이 먼저다. 예를 들어 "캘린더에 일정을 등록해 줘"는 절차보다 실제 캘린더 접근 권한과 API 연결이 핵심이다. 이런 경우 Skill이 없어도 도구만 잘 연결돼 있으면 충분할 수 있다. 물론 등록 전 확인 질문, 시간대 검증, 중복 일정 점검까지 포함해 업무를 표준화하고 싶다면 그때는 Skill을 얹을 수 있다.
정리하면, Skill은 절차를 가르치는 데 강하지만, 자유 탐색이나 단순 도구 호출 자체를 대신하지는 않는다.
실무에서 바로 쓰는 판단 질문
현장에서 "이걸 Skill로 만들까?"를 고민할 때는 복잡한 이론보다 짧은 체크가 더 유용하다. 다음 질문에 예가 많을수록 Skill로 설계할 가능성이 높다.
이 작업은 다음 달에도 반복될까?
잘하는 사람은 대체로 비슷한 순서로 이 일을 수행하는가?
초보자가 자주 빠뜨리는 단계가 분명한가?
결과물의 품질을 체크리스트로 점검할 수 있는가?
회사나 팀만의 규칙이 개입되는가?
도구를 아무 때나 쓰면 안 되고, 쓰는 순서나 조건이 중요한가?
예를 들어 "블로그 글 제목 20개 브레인스토밍"은 Skill보다 자유 대화에 가깝다. 하지만 "기술 블로그 초안 작성 후, 사내 문체 적용, 코드 예제 검토, SEO 제목 개선, 최종 템플릿으로 출력"은 Skill 후보에 가깝다. 전자는 아이디어 발산이고, 후자는 반복 가능한 업무 절차이기 때문이다.
이 차이를 이해하면 Skill을 과도하게 만들지도 않고, 반대로 필요한 곳을 놓치지도 않게 된다.
Skill은 업무를 '설치'하는 방식이다
이 장의 마지막에서 다시 핵심만 붙잡아 보자. Skill은 모델에게 더 많은 정보를 주는 수단이 아니다. 모델이 특정 업무를 더 일관되고 재사용 가능하게 수행하도록 업무 절차를 설치하는 방법이다. 그래서 Skill은 단순 프롬프트보다 오래가고, 단순 도구 연결보다 넓고, 단순 페르소나 설정보다 구체적이다.
좋은 Skill은 다음을 함께 담는다. 언제 써야 하는지, 어떤 순서로 해야 하는지, 어떤 도구를 어떤 기준으로 써야 하는지, 어디서 멈추고 확인해야 하는지, 결과가 잘 되었는지 어떻게 검토해야 하는지. 이 다섯 가지가 모이면 에이전트는 단순한 응답 기계에서 실행 시스템으로 바뀌기 시작한다.
다음 장에서는 한 걸음 더 들어가 보자. Skill이 단지 파일로 존재하는 것만으로는 충분하지 않다. 에이전트가 그 Skill을 어떻게 발견하고, 언제 활성화하고, 어떤 부분만 읽는지가 실제 성능을 크게 좌우한다. 다시 말해, 이제부터는 "Skill이 무엇인가"에서 "에이전트는 그 Skill을 어떻게 읽는가"로 넘어갈 차례다.
참고
1Agent Skills Overview - Agent Skills
2Agent Skills | Microsoft Learn
3What Are Agent Skills? The Complete Guide to AI Agent Skills (2026)
4What Are AI Agent Skills? The Complete Guide to Teaching Agents How to Work
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.