0. 전제 지식: 애초에 AI에서의 Skill이란 무엇인가?

AI 업계에서 「Skill」이라는 용어는 과거 몇 차례 의미가 변해왔다.

우선 이곳의 인식을 맞추기 위해, 본 기사에서는 다음과 같이 세대별로 의미를 정의한다.

제1세대: Alexa 등에 대표되는, 개발자가 코드로 꼼꼼하게 작성한 외부 API 호출 규칙.

제2세대: ChatGPT 등장 이후. 인간이 자연어로 고민하며 작성한 프롬프트 모음이나 정형 문구. 이른바 프롬프트 엔지니어링 (Prompt Engineering).

제3세대: AI가 자율적으로 움직이기 위한 「목적·제약·도구의 패키지」.

1. 업계 상황

1-1. 모델의 진화

Claude Falbe나 OpenAI Sol 등 새로운 추론 모델의 대두로 인해, LLM의 능력은 극적으로 진화했다.

그에 따라 프롬프트 엔지니어링 (Prompt Engineering)의 이론도 완전히 뒤집히고 있다.

조금 전까지만 해도 「어쨌든 컨텍스트 (Context)를 길고 상세하게 쓰는 것」이 정의였으나, 지금의 똑똑한 모델에 그렇게 하면 오히려 추론이 흔들리거나, 과적합 (Overfitting)과 같은 상태가 되어 지시를 무시하기도 한다.

Anthropic 공식에서도 프롬프트에 에지 케이스 (Edge Case)를 채워 넣지 말라고 경고하고 있다 (Effective context engineering for AI agents - Anthropic).

이처럼 모델이 바뀌면 최적의 지시 「형태」도 바뀌기 때문에, 프롬프트에는 항상 유지보수가 요구된다.

1-2. Agent라는 상위 개념으로의 통합

「Skills」라는 말이 유행하던 시기에는, LLM에게 어떻게 특정 계산이나 검색 (=Skill)을 가르칠 것인가라는 단일 기능 추가에 초점이 맞춰져 있었다.

그 후 현재는 기술이 성숙하여, LLM 스스로가 태스크를 계획 (Plan)하고, 필요한 도구를 자율적으로 선택·실행 (Execute)하는 AI Agent 아키텍처가 주류가 되었다.

그 결과, 개별 부품인 Skill에 관한 화제보다, 그것들을 묶어서 어떻게 자율적으로 움직이게 할 것인가라는 상위 워크플로우 (Agentic Workflow)나 Router 구현으로 업계의 관심이 이동하고 있다.

그렇다고는 해도, 특정 정형 동작이나 역할을 Markdown으로 정의하는 행위 자체는 지금도 시스템 개발에서 매우 중요하다.

하지만 현재 그것은 단일 태스크로서의 Skills를 정의하는 작업이 아니라, 「Agent의 시스템 프롬프트 (System Prompt)를 설계하는 것」 혹은 「특정 역할을 가진 Micro-Agent를 세우는 것」과 같은 작업으로 옮겨가고 있다.

Appendix: LLM에 특정 역할을 부여하는 기술의 변천

LLM에 특정 역할을 부여하는 기술은 다음과 같은 4가지 페이즈를 거쳐 진화해 왔다.

프롬프트 엔지니어링 (Prompt Engineering)의 시대 (2022년~2023년 전반기)

ChatGPT 등장 직후, 「LLM을 특정 전문가처럼 행동하게 만들기」 위한 복잡한 프롬프트를 고안해 냈다.

「당신은 시니어 엔지니어입니다」, 「다음 Markdown 규칙에 따라 응답해 주세요」와 같은 지시 템플릿이 공유되었고, Semantic Kernel 등의 초기 프레임워크는 이를 「Semantic Skills (의미적 스킬)」로서 시스템에 편입시키는 접근 방식을 취했다.
이것이 일반적으로 상상되는 「Skills」의 전성기.

Chains (고정 워크플로우)의 시대 (2023년 중반)

단일 Skill만으로는 복잡한 업무를 수행할 수 없기 때문에, 여러 Skill을 사슬처럼 잇는 접근 방식 (LangChain 등)이 유행했다.

「요약 Skill」 → 「번역 Skill」 → 「포맷 정렬 Skill」과 같은 식으로, 코드상에서 정적인 파이프라인을 정의하는 수법이지만, 도중에 예외가 발생하면 후속 작업이 모두 실패한다는 취약점이 있다.

ReAct와 단일 Agent의 대두 (2023년 후반~2024년)

여기서 「Agent」라는 개념이 폭발적으로 보급되었다.

「ReAct (Reasoning and Acting)」라는 수법을 통해, LLM이 사고(Reasoning) → 행동(Acting) → 관찰(Observation)의 루프를 돌리게 하는 기술이 확립되었다.

이를 통해 고정 워크플로우를 사전에 준비하지 않더라도, 사전에 정의된 Markdown 규칙 (Skills)을 LLM 스스로가 필요한 타이밍에 읽어 들여 실행하게 되었다.

이 시기에 OpenAI가 Custom GPTs를 발표하면서, 특정 프롬프트와 규칙을 가진 AI를 쉽게 만들 수 있게 되었고, 굳이 스스로 Skills라는 용어를 사용하여 정의할 기회가 줄어들었다. -
Agentic Workflow와 멀티 에이전트(Multi-Agent)의 시대 (2024년~현재)

현재는 단일 AI에 여러 개의 Skill을 집어넣으면 지시를 다 따르지 못하게 되는 것(프롬프트 비대화에 따른 성능 저하)이 알려져 있다.

그렇기 때문에 현재의 시스템 아키텍처는 하나의 구체적인 Skill(Markdown의 역할 정의)을 가진 작은 에이전트(Agent)를 대량으로 만들고, 이들을 연계시키는(Multi-Agent System) 형태로 진화하고 있다.

과거의 구현: 하나의 거대한 LLM에게 「설계 Skill」, 「구현 Skill」, 「테스트 Skill」을 선택하게 함.

현재의 구현: 「설계 Agent」, 「구현 Agent」, 「테스트 Agent」라는 독립된 마이크로서비스(Microservice)와 같은 AI를 준비하여, 에이전트 간에 토론이나 태스크 전달을 수행함 (CrewAI나 LangGraph 등의 프레임워크가 대두).

1-3. 이런 상황에서 이제 와서 생각 없이 Skill이나 프롬프트 기술에만 집중할 것인가?

프롬프트나 Skill의 작성법 및 사용법에 관한 사례집이나 공유회를 (여전히) 자주 접하게 되지만, 지금의 상황을 고려하면 엔지니어가 정말로 집중해야 할 곳은 그곳이 아닌 것처럼 보인다.

특히, Skill을 자주 사용하는 작업용으로 긴 프롬프트를 복사해서 저장해 두는 식의 제2세대적 운용을 하고 있다면, 완전히 시대에 뒤떨어진 것이다.

두꺼운 프롬프트 모음집은 자율적으로 움직이는 멀티 에이전트 시스템에서는 그저 병목 현상(Bottleneck)으로 전락하고 만다.

이 글에서는 부채가 되는 프롬프트 관리를 버리고, 새로운 Skill 운용과 엔지니어가 정말로 집중해야 할 것에 대해 쓰고자 한다.

2. Skill은 「자산」이 아니라 「일회용 설정 파일」

먼저 조금 추상적으로, 새로운 Skill 운용과 엔지니어가 정말로 집중해야 할 것을 정리한다.

2-1. 새로운 Skill 운용: 필요할 때 AI에게 만들게 하고 버리기

과거의 프롬프트는 인간이 시행착오를 거치며 미세 조정하는 자산이었다.

팀에서 공유하고 소중히 보관해 왔다.

하지만 앞서 언급했듯이 모델의 진화 속도가 너무 빠르기 때문에, 과거의 비전(秘傳) 프롬프트는 순식간에 예기치 않은 동작을 일으키는 기술적 부채(Technical Debt)가 되어버린다.

이것은 이제 누구나 알고 있는 사실일 것이다.

하지만 매번 유지보수하는 것은 번거롭다.

그렇다면 어떻게 해야 하는가?

필요에 따라 Skills나 프롬프트를 AI 스스로 작성하게 하고, 필요 없어지면 버리는 상태로 두는 것이 정답이다.

2-2. 엔지니어가 집중해야 할 것: 상세 설계서가 아닌 config를 전달하기

Skills나 프롬프트를 AI에게 작성하게 하기 위한 프롬프트에 상세한 절차를 구구절절 적고 있다면, 결국 자신이 프롬프트를 작성하는 것과 다를 바 없다.

우리가 던지는 프롬프트는 특정 작업을 모두 정의한 설계서나 지시서가 아니라, 비유하자면 에이전트를 자율 주행시키기 위한 config 파일로 파악해야 한다.

작업을 일일이 가르치는 것이 아니라, 필요한 config 요소만을 전달한다.

그렇다면 구체적인 config 요소란 무엇인가?

다음의 3요소라고 생각한다.

Input / Output의 명확화

• 예: 「입력은 요구사항 정의 Markdown. 출력은 FastAPI의 라우팅 코드」

Eval (성공 조건의 정의)

• 예: 「Pydantic 모델을 이용한 유효성 검사(Validation)가 포함될 것」, 「HTTP 404 에러 핸들링이 구현되어 있을 것」

Guardrail (금지 사항·제약)

• 예: 「사내 라이브러리 이외의 외부 패키지는 임포트하지 말 것」, 「출력은 JSON 형식으로만 하며, 불필요한 인사말이나 해설을 포함하지 말 것」

요컨대, AI의 채팅창에 「당신은 우수한 엔지니어입니다. ~~라는 형식으로, 단계별로(Step-by-step)……」라고 길게 늘어놓는 것은 그만두고, 「입력, 출력, 성공 조건, 금지 사항」만을 불렛 포인트로 던져라는 뜻이다.

그러면 AI가 알아서 파싱(Parse)하여 최적의 구조를 가진 Skill로 만들어 줄 것이다.

2-3. 버리고 싶지 않다면 평가할 수 있는 메커니즘을 만들기

2-1에서 Skills의 운용에 대해, "필요에 따라 Skills나 프롬프트를 AI 스스로 작성하게 하고, 필요 없어지면 버리는 상태로 두는 것이 정답"이라고 언급했다.

다만 이는 개인 개발이나 소규모 팀이라면 괜찮겠지만, 대규모 팀에서는 그렇게 하기 어렵다.

대규모 팀에서는 Skill도 공수를 들여 만든 소중한 성과물로 간주하고, 많은 인원이 이를 재사용함으로써 팀 전체의 생산성을 높이는 것이 필요하다.

그 경우에는, 정기적으로 Skill/프롬프트(Prompt)의 평가·개선을 반복하는 운영 체계가 필수적이다.

구체적으로는, 2-2에서 설정한 config 3요소를 테스트 케이스(Test Case)로 하여, 정기적으로 평가·개선·변경 A/B 테스트를 수행하는 메커니즘을 자동화해야 한다.

Skill이라는 소중한 성과물은 한여름에 방치된 아이스크림처럼, 엄청난 속도로 자산으로서의 형태를 잃고, 심지어 초파리를 불러모으는 것과 같다.

유지하는 체계는 필수적이지만, 그것을 한 명의 인간이 공수를 들여 어떻게든 해결하려 하기보다는 자동화하고 싶다.

이러한 접근 방식은 각 사의 공식 가이드에서도 권장하고 있다.

OpenAI (Prompt Engineering Guide): 프롬프트의 미세 조정(Fine-tuning)보다는, "예시를 제공하는 것"이나 "변경 사항을 체계적으로 테스트하는 것"을 전략으로 권장하고 있다 (OpenAI Prompt Engineering Guide).

Anthropic (Context Engineering): 복잡한 지시는 XML 태그로 구조화하는 것을 권장하지만, 인간이 작성하는 것이 아니라 최소한의 정보로 남겨두고, Eval(평가)용 테스트 케이스를 사용하여 실패 모드(Failure Mode)를 기반으로 개선해 나가는 것을 베스트 프랙티스(Best Practice)로 삼고 있다 (Anthropic Platform Docs).

skill-creator

의 충격: Eval(평가) 주도와 자율 수복

3. Claude Code 이 Skill을 일회용으로 취급하고 평가에 철저히 집중하는 사상을 강렬하게 체현하고 있는 것이, Anthropic이 공개한 skill-creator (anthropics/skills GitHub 리포지토리)다.

대화로 프롬프트를 만들어 주는 기능 자체는 타사에도 있지만, skill-creator는 근본적으로 다르다. CI/CD 사상이 밑바탕에 깔려 있다.

이것이 구체적으로 어떻게 유용한지, React 컴포넌트를 자동 생성하는 Skill을 만드는 상황에서 비교해 보겠다.

Before: 기존의 수동 유지보수 (두더지 잡기)

• 인간이 Skill을 만듦: "React 전문가로서 코드를 작성해줘. Tailwind를 사용할 것"
• 실행해 봄 → AI가 센수를 발휘해 CSS Modules로 출력해 버림.
• 인간이 Skill을 수정: "절대로 CSS Modules는 사용하지 말 것. Tailwind 한정" - 재실행 → Tailwind는 되었지만, 컴포넌트의 export를 잊어버림.
• 인간이 Skill을 수정: "파일 마지막에 반드시 export default를 할 것"

...이 두더지 잡기에 무한한 시간을 낭비하고 있었다.

skill-creator의 Eval(평가) 주도 개발

After:

• 인간은 요건(Requirement)만 skill-creator에 전달한다.
  • "React와 Tailwind로 컴포넌트를 만드는 Skill이 필요해"

【테스트의 자동 정의】

• 사전에 테스트 코드를 준비할 필요는 없다. skill-creator 스스로 요건을 읽고, "그렇다면 '버튼 컴포넌트를 만드는' 테스트(Eval)를 진행하겠습니다. 합격 조건은 'Tailwind 클래스가 있는가'와 'export default가 되어 있는가'입니다"라고 테스트 케이스를 자동으로 정의하여 제안한다.

【병렬 실행과 스코어화】

• skill-creator는 내부적으로 "작성 중인 Skill을 가진 에이전트"와 "Skill이 없는 순수 에이전트(Baseline)\

앞 장에서 소개한 skill-creator의 사상은 옳다. 하지만 개인 개발 단계에서 CI와 같은 자동 평가 기반까지 구축하는 것은 과하다. 그 사상을 일상적인 작업에 적용하면 다음과 같다.

• 요구사항만 불렛 포인트로 전달한다 —— 「입력(Input)」「출력(Output)」「지켜야 할 것」「해서는 안 될 것」의 4줄만 작성.
• AI에게 Skill의 초안을 쓰게 한다 —— 구조화(Structuring)는 AI에게 통째로 맡긴다.
• 실제 태스크에서 2~3회 사용한다 —— 이것이 skill-creator가 말하는 Eval(평가)의 대용이다. 즉, 수동 결합 테스트(Integration Test)다.
• 어긋난 부분만 수정하게 한다 —— 전문을 다시 쓰지 않는다. 실패한 테스트에 대응하는 차분(Diff)만 적용한다.

「처음부터 완벽한 프롬프트를 작성하는 것」을 그만두고, **「사용하면서 키워 나가는 것」**으로 바꾸기만 하면 된다. 거창한 기반이 없더라도, Eval 주도(Eval-driven)의 본질 —— 테스트로 문제를 찾아내고, 차분으로 수정한다 —— 는 개인의 작업 환경에서도 재현할 수 있다.

4. 그렇다면, 내일부터 무엇을 Skill로 만들어야 하는가

지금까지 「Skill은 일회용이다」, 「AI에게 쓰게 해라」와 같은 운용 방침을 서술해 왔지만, 정작 중요한 **「애초에 자신의 무엇을 Skill로 만들어야 하는가」**가 빠져 있다면 이는 탁상공론에 불과하다.

이 의사결정은 매우 단순하다.

같은 설명을 AI에게 3번 이상 했다는 느낌이 드는가?

이 질문의 답이 Yes라면, 그것은 Skill화의 후보로서 적합하다.

3번인지 5번인지는 팀에 따라 미세한 조정이 있을 수 있겠지만, 체감상 우선 3번을 하나의 척도(Barometer)로 삼으면 좋다고 생각한다.

그 외에는 만들 필요가 없다. 「만들지 않는다」는 판단이야말로 최대의 효율화다.

일회용이 될지 여부는 결과론적인 문제이지, 목적이 아니다.

4-1. Skill로 만들어야 할 3가지 유형

유효한 Skill은 파고들면 결국 이 3가지로 집약된다.

• 워크플로우형 (Workflow-type, 절차가 정해져 있는 작업)
  매번 같은 순서로 수행하는 작업. 「PR 리뷰 관점 체크」, 「릴리스 노트 생성」, 「회의록으로부터 태스크 추출」 등. 절차가 머릿속에 고정되어 있을수록 Skill로 만들 가치가 높다.

• 컨텍스트형 (Context-type, 자신·팀 고유의 규칙)
  AI가 절대 알 수 없는 당신만의 전제 조건. 명명 규칙(Naming Convention), 사용 가능한 라이브러리, 문체, 금지 사항 등. 앞 장에서 언급한 「Input/Output · Eval · Guardrail」이 가장 효과를 발휘하는 영역이다.

• 템플릿형 (Template-type, 출력 포맷이 고정된 것)
  주간 보고서, 장애 보고서, 설계 문서. 내용은 매번 다르지만 틀(Container)은 동일한 것.

반대로, 단 한 번뿐인 조사, 그 자리에서의 상담, 매번 내용이 바뀌는 사고 작업은 Skill로 만들어서는 안 된다. Skill을 만드는 불필요한 공수와 'Skill'이라는 부채가 발생하기 때문이다.

4-2. 첫 번째 Skill을 만드는 법

이것저것 고민하기 전에, 가장 자주 사용하는 도구를 소재로 첫 번째 하나를 만들어라.

GitHub를 자주 사용한다면, 주제는 「PR 리뷰」나 「커밋 메시지 형식」 정도가 적당하다.

전달해야 할 것은 단 4줄이다.

• 입력(Input): 리뷰 대상의 diff
• 출력(Output): 관점별로 정리된 리뷰 코멘트
• 지킬 것: 지적 사항에는 반드시 수정 제안을 첨부할 것
• 금지 사항: 취향 수준의 사소한 지적으로 채우지 말 것

이것을 AI에게 던져주고 초안을 만들게 한다.

그 후 다음 PR에서 사용하고, 어긋나면 수정한다.

5. 마치며

지금의 Skill은 써서 저장해 두는 것이 아니라, AI가 생성하게 하고, 테스트로 평가하며, 자동으로 수선하게 만드는 것이다.

만약 구세대(2세대) 프롬프트 모음을 소중하게 간직하고 있다면, 지금 당장 버리는 것이 좋다.

잔기술(Trick)에 집착하는 것은 그만두고, 우리는 시스템의 본질적인 가치와 아키텍처 설계에 에너지를 쏟자.

AI 에이전트의 오케스트레이션(Orchestration)을 전제로 하고, 메타적으로 도구를 최대한 활용한다면, 개발은 훨씬 더 본질적이고 압도적으로 편해질 것이다.

Discussion