AI Skill은 md 파일 하나가 아니라, 반복 업무를 시스템화하는 출발점이다

안녕하세요, Seigniter의 유민수 개발자입니다.

AI를 잘 쓰는 사람과 그렇지 않은 사람의 차이는 더 긴 프롬프트를 쓰느냐에서 갈리지 않습니다. 반복되는 작업을 얼마나 안정적인 구조로 재사용하느냐가 더 큰 차이를 만듭니다.

다만 한 가지를 먼저 구분하겠습니다. 우리가 흔히 말하는 Skills(AI가 특정 작업을 수행하는 데 필요한 지시·파일·예시·도구·절차를 묶어 재사용하는 작업 단위)는 md 파일 몇 개로만 완성되는 개념이 아닙니다. 플랫폼이나 구현체에 따라 Skills는 지시문과 보조 파일, 예시 데이터, 스크립트, 도구 호출, 권한, 실행 환경, 평가 루프까지 품습니다.

그래서 이 글에서 다루는 건 Skills 전체가 아닙니다. 정확히는 Skills를 이루는 여러 계층 가운데 마크다운 기반의 지시 계층(instruction layer, AI가 작업을 어떻게 수행해야 하는지 설명하는 문서화된 규칙 영역)을 중심으로 봅니다. skill.md, examples, evals.md, memory.md 같은 파일로 반복 업무의 기준을 문서화하고 재사용 가능하게 만드는 방식이죠. Skills의 전부는 아니지만, 대부분의 팀과 개인이 Skill 설계를 시작할 때 가장 먼저 손대야 하는 핵심 계층입니다.

AI에게 "이 글 좀 다듬어줘"라고 던지는 것과, "이 유형의 글은 어떤 기준으로 판단하고, 어떤 예시를 참고하며, 어떤 체크리스트를 통과해야 하고, 이전 작업에서 무엇을 기억해야 하는가"를 구조화하는 것은 전혀 다른 접근입니다. 전자는 일회성 채팅이고, 후자는 반복 가능한 작업 시스템의 출발점입니다.

개발자 눈으로 보면 md 기반 Skill은 단일 프롬프트라기보다 Context Package(특정 업무에 필요한 지시·예시·평가 기준·보조 정보를 묶은 실행 단위)에 가깝습니다.

"긴 글 편집"이라는 업무를 예로 들어 보겠습니다. 좋은 편집은 문장을 매끄럽게 바꾸는 것만으로는 부족합니다. 글의 목적을 파악하고, 독자가 누구인지 이해하고, 도입부가 충분히 강한지 판단해야 합니다. 불필요한 AI식 표현을 걷어내고 문단의 리듬도 다듬어야 하며, 마지막엔 실제 사람이 읽었을 때 자연스러운지 검수해야 합니다. 이 기준을 매번 채팅창에 다시 쓰는 대신 파일 단위로 분리해 둘 수 있습니다. skill.md에는 작업의 실행 규칙을, examples에는 좋은 결과물 예시와 문체 샘플을, evals.md에는 반드시 통과해야 할 평가 기준을, memory.md에는 시간이 지나며 쌓이는 사용자 취향과 개선점을 둡니다.

이 구조가 중요한 이유는 AI 사용을 "프롬프트 재사용"에서 "업무 절차의 제품화"로 끌어올리기 때문입니다.

일반적인 AI 사용은 요청 단위로 끝납니다. 사용자가 초안을 붙여넣고 "전문적으로 다듬어줘"라고 하면, AI는 그 순간의 대화 맥락과 일반적인 언어 능력에 기대어 결과를 냅니다. Skill 기반 접근은 다릅니다. AI가 먼저 작업 유형을 감지해 이 글이 개인 에세이인지 제품 분석 글인지 튜토리얼인지 판단하고, 관련 예시를 참조해 초안에서 부족한 지점을 찾아 다시 쓴 뒤, 평가 기준에 따라 검수합니다. 한 번 답하고 끝나는 게 아니라 입력부터 산출물까지 처리 흐름을 갖는, 워크플로우에 가까운 동작입니다.

다시 강조하면, 이 md 파일 구조는 Skills의 전체 실행 환경이 아니라 제어 표면(control surface, 사람이 시스템의 동작을 정의하고 조정하는 인터페이스 영역)입니다. 실제 Skill이 강력해지는 지점은 이 문서화된 규칙이 도구·파일·코드·외부 시스템과 연결될 때입니다.

글 편집 Skill이라면 md 파일만으로도 어느 정도 굴러갑니다. 더 확장하면 초안을 읽고, 브랜드 톤 가이드를 검색하고, 기존 게시물 예시를 참조하고, 금지어 목록을 검사하고, 문단 길이를 측정하고, 제목 후보를 생성하고, 평가 기준에 따라 실패 항목을 찾아 수정본을 다시 만든 뒤, 최종 검수 결과를 남기는 구조까지 갑니다. 여기서 md 파일은 "무엇을 해야 하는가"와 "어떤 기준으로 판단하는가"를 정의하고, 도구와 스크립트는 "실제로 어떻게 실행하는가"를 맡습니다.

이 구분이 중요합니다. skill.md는 Skill 자체가 아니라 Skill의 실행 명세(execution specification, 작업이 수행되어야 하는 방식과 조건을 적은 규칙 문서)입니다. examples는 학습 참고 자료, evals.md는 산출물이 다음 단계로 넘어가기 전 통과해야 하는 품질 게이트, memory.md는 과거 작업에서 얻은 선호와 개선점을 보존하는 상태 저장소 역할을 합니다. 그리고 실제 Skill은 이 요소들이 실행 환경·도구·권한·데이터와 결합될 때 비로소 더 완성된 작업 단위가 됩니다.

설계 원칙 1 — skill.md와 예시 파일을 분리한다

많은 사람이 AI 작업 시스템을 만들 때 모든 정보를 하나의 긴 지시문에 밀어 넣으려 합니다. 좋은 설계가 아닙니다. skill.md에는 일반화된 실행 규칙만 두고, 개인적인 예시나 문체 샘플은 별도 파일로 빼는 편이 낫습니다.

이유는 셋입니다. 먼저 Context Window(AI가 한 번에 읽고 참고할 수 있는 입력 범위)를 아낄 수 있습니다. 모든 작업에서 모든 예시를 읽을 필요는 없고, 지금 작업과 관련 있는 예시만 골라 참조하면 됩니다. 보안과 공유 측면에서도 유리합니다. skill.md에 개인적인 글과 민감한 맥락, 내부 문서 스타일이 다 들어가 있으면 남과 공유하기 어렵지만, 실행 규칙과 개인 예시를 분리하면 재사용성과 안전성이 함께 좋아집니다. 유지보수도 쉬워집니다. 새 예시가 생기면 examples 폴더에 더하고, 평가 기준이 바뀌면 evals.md만 고치면 됩니다. 거대한 프롬프트 하나를 계속 손보는 것보다 훨씬 구조적이죠.

이 접근은 Retrieval(필요한 정보만 골라 불러오는 방식)에 닿아 있습니다. AI가 모든 맥락을 늘 읽는 게 아니라, 지금 작업에 필요한 문체·예시·기준만 골라 참조하는 겁니다. 일반적인 RAG(Retrieval-Augmented Generation, 외부 문서나 지식을 검색해 생성 과정에 결합하는 방식)가 외부 지식 검색에 무게를 둔다면, md 기반 Skill 구조는 사용자의 업무 기준과 취향을 검색 가능한 로컬 지식으로 바꿔 놓습니다.

설계 원칙 2 — 트리거 설명을 명확히 쓴다

스킬은 존재한다고 늘 실행되지 않습니다. AI는 먼저 스킬의 이름과 설명을 보고 "이 요청에 이 스킬을 써야 하나"를 판단합니다. 그래서 description은 단순 소개문이 아니라 라우팅 규칙(routing rule, 요청을 어떤 처리 흐름으로 보낼지 결정하는 조건문)입니다.

가령 이런 식이어야 합니다. "긴 글 초안, 뉴스레터, 블로그 포스트, LinkedIn 아티클을 편집할 때 사용한다." "사용자가 문장을 더 선명하게 만들거나, 제목을 추천하거나, 도입부를 강화해 달라고 할 때 사용한다." "초안의 구조·문체·훅·불필요한 AI식 표현을 점검해야 할 때 사용한다." 이 설명이 모호하면 아무리 좋은 스킬을 만들어도 호출되지 않습니다. 엔지니어링에 빗대면 API Gateway(들어온 요청을 적절한 서비스로 분배하는 진입점)의 라우팅 조건이 잘못된 것과 같습니다. 기능은 있는데 요청이 거기까지 닿지 못하는 거죠.

설계 원칙 3 — evals.md를 둔다

Evals(Evaluations, AI 출력물이 요구 조건을 만족하는지 검사하는 규칙)은 결과물의 품질을 안정시키는 핵심입니다. 특히 점수형 평가보다 통과·실패로 가르는 이진 평가가 실무에서 더 쓸모 있습니다.

가령 도입부에 독자가 계속 읽을 이유가 있는지, 첫 두세 문장이 간결한지, 불필요한 AI식 표현이 빠졌는지, 문단 길이가 LinkedIn에서 읽기 적절한지, 마지막에 독자가 가져갈 실행 포인트가 있는지, 기술 용어가 독자 수준에 맞게 설명됐는지를 묻는 식입니다. LLM은 "이 글을 5점 만점으로 평가해줘" 같은 요청에는 그럴듯하게 답하지만, 3점과 4점, 4점과 5점을 안정적으로 가르는 데는 약합니다. 반대로 "도입부에 구체적 문제 제기가 있는가", "마지막 문단에 적용 방법이 있는가"처럼 판정 가능한 기준은 훨씬 운영하기 좋습니다. 소프트웨어 테스트와 비슷합니다. 모호한 감상평보다 단위 테스트가 강하듯, 글·제안서·강의안·고객 응답 같은 비정형 산출물에도 품질 게이트를 걸 수 있습니다.

설계 원칙 4 — 생성 에이전트와 평가 에이전트를 나눈다

AI가 직접 만든 결과물을 같은 맥락에서 곧바로 평가하면 자기합리화가 끼어듭니다. 왜 그렇게 썼는지 이미 알고 있으니까요. 그래서 가능하면 초안을 개선하고 다시 쓰는 Editor Agent와 결과물을 기준에 따라 검수하는 Grader Agent를 분리하는 게 좋습니다.

흐름은 간단합니다. Editor Agent가 초안을 편집하면 Grader Agent가 evals.md 기준으로 검수하고, 실패 항목이 있으면 Editor Agent가 다시 고칩니다. 모든 항목이 통과할 때까지 이 과정을 반복합니다. CI와 닮았습니다. 테스트가 실패하면 코드를 고쳐 다시 돌리듯, Skill 기반 작업에서는 코드 대신 글·문체·구조·설득력·실용성 같은 비정형 결과물에 같은 사고방식을 적용합니다.

설계 원칙 5 — memory.md로 스킬 자체를 키운다

memory.md는 이번 결과물이 통과했는지 검사하는 파일이 아닙니다. 그건 evals.md의 몫입니다. memory.md는 시간이 지나며 쌓이는 회고 로그(retrospective log, 과거 작업에서 배운 개선점과 선호를 축적하는 기록)에 가깝습니다.

예를 들어 evals.md에는 "도입부에 구체적인 문제 제기가 있는가?" 같은 기준이 들어갑니다. 반면 memory.md에는 "사용자는 지나치게 마케팅스러운 문장을 선호하지 않는다", "실제 엔지니어링 비유가 들어간 설명을 좋아한다", "개념 설명보다 실무 적용 구조를 강조하는 글이 더 맞는다" 같은 내용이 어울립니다. evals.md가 지금 산출물의 품질을 검사한다면, memory.md는 다음 작업의 방향을 손봅니다. 단, memory도 길어지면 오히려 노이즈가 됩니다. 중요한 건 많이 기억하는 게 아니라, 다음 실행에 영향을 줄 만큼만 기억하는 겁니다.

다시, 전체 구조

Skills의 전체 개념은 md 파일만으로 설명되지 않습니다. 그래도 md 파일은 Skill을 설계하는 가장 기본적인 인터페이스입니다. 정리하면 description은 라우터, skill.md는 실행 명세, examples는 참조 데이터, evals.md는 테스트, memory.md는 상태 저장소입니다. 도구·스크립트·API·MCP(Model Context Protocol, AI 모델이 외부 도구와 데이터 소스에 연결되도록 돕는 프로토콜)·파일 입출력은 실제 작업을 수행하는 실행 계층이고요.

이렇게 보면 프롬프트 엔지니어링은 문장을 잘 쓰는 기술이 아닙니다. 반복 업무를 모듈로 나누고, 평가 가능하게 만들고, 시간이 갈수록 좋아지도록 설계하는 일에 가깝습니다.

물론 이 접근이 완전 자동화를 뜻하지는 않습니다. 좋은 AI 작업물에는 여전히 마지막 10~20%의 인간 판단이 필요합니다. AI는 초벌 작업과 반복 검수, 구조화, 변형, 비교에는 강하지만, 맥락의 미묘함과 조직 내부의 판단, 브랜드 톤의 작은 차이, 독자 반응에 대한 감각은 사람이 최종적으로 봐야 합니다. 그러니 AI Skill은 사람을 대체하는 장치라기보다, 반복 업무의 비용을 줄이고 품질 편차를 낮추는 운영 장치로 보는 편이 정확합니다.

실무 적용은 어렵지 않습니다. 지난 일주일을 돌아보세요. 가장 자주 반복했고 매번 비슷한 기준으로 판단했던 일을 찾으면 됩니다. 강의안 편집, 뉴스레터 작성, 제안서 검토, 코드 리뷰, 법령 요약, 고객 문의 답변, 랜딩페이지 카피 작성, 회의록 정리, 기술 문서 초안 작성 — 이런 작업이 있다면 Skill 후보입니다. 그다음 네 가지를 파일로 분리합니다. 좋은 결과물 예시, 나쁜 결과물 패턴, 반드시 통과해야 할 체크리스트, 장기적으로 기억할 취향과 기준. 여기까지가 md 기반 Skill 설계의 출발점입니다.

그다음은 이 구조를 실제 도구·데이터·자동화 스크립트·MCP·API와 연결하는 단계입니다. 그때부터 Skill은 단순 문서 묶음이 아니라 입력부터 산출물까지 이어지는 실제 업무 파이프라인에 가까워집니다.

결국 중요한 건 관점입니다. AI Skill을 "프롬프트 파일"로 보면 md 몇 개 잘 쓰는 문제로 끝납니다. 하지만 "반복 업무를 실행 가능한 시스템으로 바꾸는 단위"로 보면 이야기가 달라집니다. md는 그 시스템의 전부가 아닙니다. 그러나 좋은 Skill을 만드는 가장 중요한 시작점입니다.

AI 활용의 경쟁력은 앞으로 "누가 더 긴 프롬프트를 쓰는가"가 아니라 "누가 반복 업무를 더 잘 구조화하고, 평가하고, 실행 시스템으로 연결하는가"에서 갈릴 가능성이 큽니다. AI Skill은 프롬프트가 아니고, md 파일 하나도 아닙니다. 반복 가능한 작업 단위이자 평가 가능한 업무 절차이며, 도구와 연결될 때 실제 실행력을 갖는 AI 업무 시스템의 구성 요소입니다.