모든 사람이 Skill 작성자가 되는 시대

어떤 시대에는 엑셀을 잘 다루는 사람이 팀의 해결사였습니다. 또 어떤 시대에는 검색을 잘하는 사람이 정보의 문지기였습니다. 이제는 그 자리에 조금 다른 사람이 올라오고 있습니다. AI에게 말을 잘 거는 사람도 물론 눈에 띕니다. 하지만 더 오래 강한 사람은 따로 있습니다. 반복되는 일을 발견하고, 그것을 재사용 가능한 Skill로 바꿀 줄 아는 사람입니다.

이 변화는 생각보다 큽니다. 왜냐하면 Skill 작성은 더 이상 개발자만의 작업으로 남아 있지 않기 때문입니다. 오히려 많은 경우 Skill은 코드를 먼저 짜는 일이 아니라, 사람이 하던 일을 입력, 판단, 출력, 예외로 분해해 문서화하는 일에 더 가깝습니다. 실제로 비개발자를 위한 Agent Skills 안내들은 마케터, 작가, PM, 운영 담당자도 블로그 초안 작성, 회의록 정리, 이메일 초안 작성, 경쟁사 분석 같은 작업을 SKILL.md 중심의 절차 문서로 시작할 수 있다고 설명합니다.¹

이 장에서 보고 싶은 것은 단순한 낙관론이 아닙니다. "이제 누구나 AI를 쓸 수 있다"는 말은 너무 익숙합니다. 더 중요한 질문은 이것입니다. 누가 앞으로 Skill 작성자가 될 것인가. 그리고 그 사람에게 필요한 능력은 무엇인가.

비개발자도 Skill 작성자가 될 수 있다

많은 사람이 Skill이라는 말을 들으면 곧바로 개발 환경부터 떠올립니다. 터미널을 열고, 파일을 만들고, 스크립트를 붙이고, 복잡한 자동화를 연결하는 장면 말입니다. 물론 그런 Skill도 있습니다. 하지만 실무에서 처음 효과를 내는 Skill은 의외로 훨씬 소박합니다.

예를 들어 마케팅 담당자는 매주 비슷한 구조의 캠페인 회고를 씁니다. 편집자는 원고 초안을 받으면 같은 순서로 다듬습니다. 채용 담당자는 면접 메모를 읽고 같은 기준으로 강점, 리스크, 보류 사유를 정리합니다. PM은 회의가 끝나면 언제나 결정사항, 미해결 이슈, 다음 액션을 분리합니다. 이런 일은 대단한 프로그래밍보다 좋은 업무 매뉴얼에 더 가깝습니다.

그래서 비개발자가 Skill을 시작할 때 가장 좋은 질문은 "무슨 언어를 배워야 하지?"가 아닙니다. "내가 반복해서 하는 판단은 무엇이지?"입니다. 그 판단이 보이면 Skill의 절반은 이미 보인 셈입니다. 비개발자용 가이드들이 slash command 기반 사용 예시와 간단한 SKILL.md 예시를 통해 강조하는 것도 바로 이 지점입니다. Skill은 프로그램이라기보다 AI를 위한 작업 설명서에 가깝고, 처음에는 회의록 정리나 블로그 서론 작성처럼 작고 반복적인 절차부터 시작하는 편이 훨씬 현실적입니다.¹

이 말은 Skill 작성의 문턱이 낮아졌다는 뜻이기도 합니다. 이제 현업 실무자는 "내가 매일 하는 이 일을 AI가 같은 방식으로 따라 하게 만들 수 있을까?"라는 관점으로 자기 일을 다시 보게 됩니다. 이 질문을 던질 수 있는 사람은 이미 Skill 작성자의 입구에 서 있습니다.

Skill 작성의 핵심은 글쓰기보다 절차 설계다

겉으로 보면 SKILL.md는 글입니다. 그래서 많은 사람이 Skill 작성 능력을 문장력으로 오해합니다. 하지만 실제로 좋은 Skill을 만드는 능력은 문학적 글쓰기보다 절차 설계 능력에 가깝습니다.

좋은 Skill 작성자는 멋진 문장을 쓰는 사람이 아니라, 에이전트가 헷갈리지 않게 길을 깔아 주는 사람입니다. 이때 중요한 것은 화려한 표현이 아니라 구조입니다. 언제 이 Skill을 써야 하는지, 어떤 입력을 받는지, 어떤 단계를 거치는지, 어디서 사람 확인이 필요한지, 어떤 경우에는 멈춰야 하는지가 선명해야 합니다.

Agent Skills 개요 문서는 Skill이 이름과 설명으로 먼저 발견되고, 관련성이 있을 때 전체 지침이 로드되며, 필요할 때만 참고자료와 스크립트가 추가로 불러와지는 progressive disclosure 구조로 동작한다고 설명합니다.² 이 구조는 비개발자에게 특히 유리합니다. 처음부터 모든 것을 한 파일에 우겨 넣지 않아도 되기 때문입니다. 핵심 절차는 SKILL.md에 적고, 긴 기준표나 예시는 참고자료로 분리하면 됩니다. 즉, 복잡한 지식도 "필요한 순간에만 펼쳐지는 매뉴얼"처럼 설계할 수 있습니다.²

예를 들어 회의 후속조치 Skill을 만든다고 해봅시다. 좋은 작성자는 이렇게 생각합니다. 먼저 회의 메모에서 결정을 추출한다. 그다음 미결 항목을 따로 모은다. 이후 담당자와 기한이 없는 액션은 임시 액션으로 분류한다. 대외 공유용 문서에는 민감한 내부 표현을 제거한다. 이 절차는 글솜씨보다 설계 감각의 산물입니다.

그래서 앞으로 Skill 작성 훈련은 "프롬프트를 더 그럴듯하게 쓰는 법"에서 끝나지 않을 가능성이 큽니다. 오히려 description 작성, 활성화 조건 정의, 단계별 지침 분리, 의사결정표 작성, 예시 배치, 참고자료 분해 같은 능력이 더 중요해집니다. 한마디로, Skill 작성자는 말을 잘하는 사람이 아니라 일을 잘 구조화하는 사람입니다.

업무 매뉴얼을 Skill로 바꾸는 순간, 역할이 다시 나뉜다

Skill이 보편화될수록 더 중요해지는 것은 협업 구조입니다. 여기서 가장 먼저 분명히 해야 할 것이 있습니다. 에이전트와 Skill은 같은 역할을 하지 않습니다. Agentic Scrum Team 관련 Skill 문서는 이 차이를 아주 간단하게 정리합니다. 에이전트는 언제, 왜 이 절차를 쓸지 오케스트레이션하고, Skill은 어떻게 수행할지에 대한 실행 지식을 담는다는 것입니다.³

이 구분은 실무에서 매우 유용합니다. 현업 담당자는 대개 "어떤 기준으로 판단해야 하는가"를 가장 잘 압니다. 반면 개발자나 AI 빌더는 "어떤 도구를 연결하고 어떤 실행 환경을 붙여야 안정적으로 돌아가는가"를 잘 압니다. 둘이 각자 잘하는 것을 나누는 편이 훨씬 효율적입니다.

예를 들어 채용 후보자 평가 Skill을 만든다고 해보겠습니다. 인사 담당자는 면접 메모에서 무엇을 근거로 강점과 우려를 구분하는지, 어떤 표현은 금지해야 하는지, 어떤 판단은 반드시 사람 승인 후에만 확정해야 하는지를 적어 줍니다. 개발자나 AI 빌더는 지원자 관리 시스템 연결, 점수 계산 보조 스크립트, 출력 포맷 검증 같은 부분을 붙입니다. 그러면 Skill은 단순한 텍스트가 아니라, 현업 판단과 기술 실행이 만나는 접점이 됩니다.

이 구조가 중요한 이유는 책임이 선명해지기 때문입니다. 현업은 도메인 기준을 제공하고, 빌더는 도구와 환경을 보강합니다. 둘 중 하나만 있으면 Skill은 자주 삐끗합니다. 현업만 있으면 실행이 약해지고, 기술만 있으면 기준이 비게 됩니다.

결국 Skill 작성의 민주화는 "모두가 혼자 다 한다"는 뜻이 아닙니다. 더 정확히 말하면, 더 많은 사람이 Skill 설계에 참여하고, 역할은 더 또렷하게 나뉜다는 뜻입니다.

이미 도구는 Skill 작성의 대중화를 전제로 움직이고 있다

이 흐름이 단지 가능성에 그치지 않는 이유는, 주요 도구들이 이미 Skill 작성을 별도의 전문 의식이 아니라 일반 작업으로 다루기 시작했기 때문입니다. OpenAI 도움말에 따르면 ChatGPT에서는 사용자가 Skill을 만들거나 수정해 달라고 요청할 때, 시스템이 자동으로 skill-creator Skill을 사용해 생성, 업데이트, 트러블슈팅을 돕습니다.⁴

이 변화는 상징적입니다. 예전에는 Skill 작성이 숙련자만 다루는 제작 행위처럼 느껴졌다면, 이제는 "AI에게 Skill을 만들게 하는 작업" 자체가 일반 사용 흐름 안으로 들어오고 있습니다. 다시 말해 Skill 작성은 점점 코드 편집기의 구석 기능이 아니라, 에이전트를 다루는 기본 상호작용으로 들어오는 중입니다.⁴

물론 이것이 곧바로 고품질 Skill을 보장한다는 뜻은 아닙니다. 자동 생성은 초안을 빨리 만드는 데 강하지만, 좋은 기준을 대신 정해 주지는 못합니다. 그래서 오히려 인간의 역할이 더 선명해집니다. 앞으로 중요한 사람은 빈 화면에서 처음부터 모든 문장을 쓰는 사람이 아니라, AI가 만든 초안을 보고 "이 절차는 빠졌고, 이 조건은 너무 넓고, 이 단계는 승인 없이는 위험하다"라고 말해 줄 수 있는 사람입니다.

Skill 작성이 쉬워질수록 Skill 설계자의 판단력은 더 중요해집니다. 자동문이 생겼다고 해서 어디로 들어갈지의 문제가 사라지는 것은 아니기 때문입니다.

지식노동에서는 개인 노하우를 Skill 자산으로 바꾸는 사람이 유리해진다

교육, 컨설팅, 출판, 마케팅, 운영, 리서치 같은 지식노동은 겉보기보다 반복이 많습니다. 매번 새로 하는 것 같지만, 자세히 보면 같은 판단을 계속 반복합니다. 어떤 자료를 먼저 읽는지, 어떤 기준으로 요약하는지, 어떤 톤으로 쓰는지, 무엇을 위험 표현으로 보는지, 어떤 체크리스트를 통과해야 제출 가능한지. 이 반복을 Skill로 옮겨 담기 시작하면 생산성의 성격이 바뀝니다.

예전에는 개인의 숙련도가 성과를 만들었습니다. "저 사람은 원고를 빨리 정리해", "저 팀장은 보고서 톤을 잘 잡아", "저 운영자는 고객 문의 분류가 정확해" 같은 식입니다. 하지만 Skill이 자리 잡으면 개인의 감각 일부가 자산으로 고정됩니다. 그러면 같은 사람만 빨라지는 것이 아니라, 팀 전체가 같은 기준으로 빨라질 수 있습니다.

한 번 잘 설계된 Skill은 초안 작성 속도만 높이지 않습니다. 톤 적용, 포맷 정렬, 검토 기준 반영, 누락 방지, 온보딩까지 함께 개선합니다. 새로 들어온 팀원은 선배의 머릿속 감각을 추측하는 대신, 이미 구조화된 Skill을 통해 일의 기준을 배웁니다. 이것은 단순한 자동화가 아니라 팀 학습 속도의 향상입니다.

2026년 기준의 AI 리터러시 로드맵들이 지식노동자에게 AI 이해와 활용 능력을 기본 역량으로 보며, 단순 사용을 넘어 실제 워크플로에 통합하고 평가하는 능력을 중요하게 다루는 것도 같은 맥락입니다.⁵ 이제 "가끔 ChatGPT를 써 본 사람"과 "자기 업무를 AI가 재현할 수 있게 구조화한 사람" 사이의 차이는 점점 커질 가능성이 큽니다.⁵

그래서 앞으로의 경쟁력은 AI를 써 봤느냐가 아니라, 내 노하우를 재사용 가능한 형식으로 남길 줄 아느냐에서 갈릴 가능성이 큽니다. 이 차이는 처음엔 작아 보여도, 시간이 갈수록 복리처럼 벌어집니다.

'Skill 디자이너'는 새 직함이라기보다 새 책임 묶음이다

이쯤 되면 이런 질문이 생깁니다. 그럼 회사마다 Skill 디자이너라는 새 직무가 생길까요? 일부 조직에서는 정말 그렇게 부를 수도 있습니다. 하지만 더 현실적인 변화는 직함보다 책임의 재배치에서 먼저 일어날 가능성이 큽니다.

Skill 디자이너는 한 명의 특별한 전문가라기보다, 여러 역할 사이에서 새롭게 떠오르는 책임 묶음에 가깝습니다. 이 책임은 대체로 다섯 가지로 정리할 수 있습니다.

• 어떤 업무가 Skill 후보인지 식별한다.

• 절차를 입력, 판단, 출력, 예외로 구조화한다.

• 자연어 지침만으로 충분한지, 스크립트나 도구 연결이 필요한지 구분한다.

• 테스트와 리뷰를 통해 오해 지점을 줄인다.

• 실제 사용 로그를 보고 개정 루프를 돌린다.

이 다섯 가지를 모두 한 사람이 맡을 필요는 없습니다. 현업 전문가가 1번과 2번을 강하게 담당할 수 있고, AI 빌더가 3번을 맡을 수 있으며, 팀 리드나 운영 담당자가 4번과 5번을 챙길 수 있습니다. 중요한 것은 "누가 이 일을 하느냐"보다 "이 책임이 어디에도 비어 있지 않느냐"입니다.

이 관점이 필요한 이유는 Skill이 점점 많아질수록, 잘 쓰는 사람보다 잘 다듬는 사람이 중요해지기 때문입니다. 초안은 AI가 빠르게 만들 수 있습니다. 하지만 경계 조건을 세우고, 위험 지점을 줄이고, 다른 사람이 써도 오해가 적은 구조로 바꾸는 일은 여전히 사람이 맡아야 합니다.

그래서 Skill 디자이너는 미래의 화려한 신직업이라기보다, 이미 조직 안에 있는 실무자, 편집자, 운영자, 개발자가 함께 떠안게 될 새로운 책임 이름에 가깝습니다.

생산성 격차는 질문력이 아니라 축적력에서 벌어진다

한동안 AI 활용 능력은 "질문을 잘하는 능력"으로 설명됐습니다. 실제로 그 말은 큰 도움이 됐습니다. 좋은 프롬프트는 분명 성과를 바꿨습니다. 하지만 앞으로 더 큰 차이를 만드는 것은 질문력 하나만은 아닐 가능성이 큽니다.

왜냐하면 질문은 그 순간의 성과를 만들지만, Skill은 다음번의 출발점을 바꾸기 때문입니다. 프롬프트 중심의 개인은 매번 조금 더 잘 묻기 위해 애씁니다. Skill 중심의 팀은 이미 검증된 절차를 다시 불러와 같은 실수를 줄입니다. 전자는 순간의 숙련을 쌓고, 후자는 조직의 실행 지식을 쌓습니다.

이 차이는 시간이 갈수록 커집니다. 같은 AI 도구를 써도 어떤 팀은 매번 빈 대화창에서 시작하고, 어떤 팀은 축적된 Skill 저장소에서 시작합니다. 같은 보고서를 작성해도 어떤 사람은 "이번엔 어떻게 시키지?"를 고민하고, 어떤 사람은 "기존 Skill v1.8에 이번 규정만 반영하면 되겠다"라고 생각합니다. 둘 다 AI를 사용하지만, 생산성의 기반이 다릅니다.

앞으로의 생산성 격차는 아마 이런 곳에서 벌어질 것입니다.

• AI를 가끔 잘 쓰는 개인과, 반복 가능한 Skill을 남기는 개인

• 프롬프트를 공유하는 팀과, Skill 저장소를 운영하는 팀

• 결과물을 한 번 생산하는 조직과, 실행 지식을 계속 개선하는 조직

이 변화는 결국 AI 활용의 중심을 옮깁니다. "잘 써보는 사람"에서 "반복 가능한 능력을 설계하고 운영하는 사람"으로, 그리고 "AI 잘 쓰는 개인"에서 "Skill을 축적하는 팀"으로 말입니다.

이제 중요한 것은 AI를 쓰는 사람이 아니라, AI의 일하는 방식을 설계하는 사람이다

모든 사람이 Skill 작성자가 되는 시대는, 모두가 스크립트를 짜는 시대가 아닙니다. 오히려 더 많은 사람이 자기 일의 구조를 언어로 꺼내고, 기준을 분명히 적고, 예외를 정의하고, AI가 따라 할 수 있는 절차로 바꾸는 시대에 가깝습니다.

그래서 비개발자도 충분히 중요한 작성자가 됩니다. 마케터는 캠페인 회고의 판단 기준을, 편집자는 원고 수정의 체크리스트를, 운영 담당자는 고객 응대의 금지 표현과 승인 조건을, PM은 회의 후속조치의 정리 규칙을 Skill로 남길 수 있습니다. 개발자는 그 위에 필요한 도구와 실행 환경을 더합니다. 그리고 팀은 그 결과를 테스트하고 개정하며 자산으로 축적합니다.

바로 이때 Skill은 개인의 편의 기능을 넘어 조직의 능력이 됩니다. 그리고 사람 사이의 생산성 차이도, 팀 사이의 실행력 차이도 점점 여기서 벌어질 가능성이 큽니다. AI에게 질문을 잘하는 것만으로는 충분하지 않습니다. 이제는 그 AI가 늘 같은 방식으로 일을 잘하게 만드는 구조를 설계할 수 있어야 합니다.

결국 앞으로 더 강한 사람은 AI를 자주 쓰는 사람이 아니라, AI가 반복해서 쓸 수 있는 능력을 남기는 사람일 것입니다. 더 강한 조직도 마찬가지입니다. 최신 모델을 가장 먼저 도입한 곳이 아니라, 자기 조직의 일을 Skill로 축적하고 개선하는 곳이 오래 앞서 갈 가능성이 큽니다.

이제 AI 활용의 무대는 대화창 안의 재치에서, 실행 지식의 설계로 옮겨가고 있습니다. 그리고 그 무대에는 개발자만 서지 않습니다. 일을 아는 사람, 기준을 설명할 수 있는 사람, 절차를 구조화할 수 있는 사람이라면 누구나 올라설 수 있습니다.

참고

¹Agent Skills for Non-Developers [No Programming Required]

²Agent Skills Overview - Agent Skills

³agent-skill-authoring.md at main - GitHub

⁴Skills in ChatGPT - OpenAI Help Center

⁵AI Literacy Roadmap: From Beginner to Proficient