실전 패턴과 사례 연구

이제 이론을 잠시 책장에 꽂아두고, 현장으로 내려가 보자. Agent Skill은 설명할 때보다 써볼 때 훨씬 빨리 이해된다. 왜냐하면 Skill의 진짜 가치는 멋진 정의가 아니라, 반복되는 일을 더 안정적으로 처리하게 만드는 데 있기 때문이다.

Agent Skill은 지시문, 스크립트, 참고 자료, 템플릿을 한 묶음으로 패키징해 에이전트가 필요할 때만 꺼내 쓰게 만드는 방식이다. 시작할 때는 이름과 설명만 보이고, 관련 있다고 판단되면 SKILL.md를 읽고, 더 필요하면 참고 파일이나 스크립트를 추가로 읽는 식이다. 이 점진적 공개 방식 덕분에 컨텍스트를 낭비하지 않으면서도 깊은 업무 지식을 실을 수 있다.¹

다만 모든 문제를 Skill로 풀 필요는 없다. 단순한 일은 단순하게 푸는 편이 낫고, 고정된 절차는 워크플로로, 유연한 판단이 필요한 부분은 에이전트와 Skill로 맡기는 편이 보통 더 안정적이다.²⁷ 이 장에서는 바로 그 경계선을 실제 사례로 익혀 보겠다.

사례를 보기 전에: 어떤 일이 Skill에 잘 맞을까

Skill이 특히 잘 먹히는 업무에는 몇 가지 공통점이 있다.

• 같은 종류의 요청이 자주 반복된다.

• 절차는 분명하지만, 사람이 매번 기억하기엔 자잘한 규칙과 예외가 많다.

• 정책 문서, 템플릿, 체크리스트처럼 필요할 때만 불러오면 되는 자료가 있다.

• 결과를 검토할 기준이 비교적 분명하다.

반대로 한 번 하고 끝나는 일, 성공 기준이 모호한 일, 또는 그냥 팀의 상시 기본 규칙이면 Skill보다 다른 수단이 더 낫다. 예를 들어 저장소 전체에 늘 적용되어야 하는 코딩 스타일은 상시 규칙이나 저장소 기본 지침이 더 어울리고, 특정 상황에서만 필요한 절차는 Skill이 더 어울린다.²⁴

이제 대표적인 활용 장면으로 들어가 보자.

문서 처리: 파일을 읽는 것이 아니라 절차를 가르치는 일

문서 처리는 Skill이 가장 빛나는 분야 중 하나다. 이유는 간단하다. 모델은 대체로 문서를 읽고 요약하는 일은 꽤 잘하지만, 실제 업무에서는 읽기만으로 끝나지 않기 때문이다. PDF에서 필드를 찾아야 하고, 계약서에서 특정 조항만 점검해야 하고, 사내 양식에 맞춰 결과를 다시 써야 한다. 이때 필요한 것은 일반 지식이 아니라 절차적 지식이다.³

예를 들어 청구서 처리 Skill을 만든다고 해보자. 이 Skill은 먼저 문서 종류를 판별하고, 필요한 필드를 추출하고, 회사 정책과 대조하고, 누락 항목을 표시하고, 마지막으로 회계 시스템에 넣기 쉬운 형식으로 정리한다. 여기서 중요한 것은 SKILL.md에 모든 정책을 우겨넣지 않는 것이다. 핵심 절차만 본문에 두고, 상세 정책은 references 폴더로, 반복 계산이나 필드 추출은 scripts 폴더로 분리하는 편이 훨씬 낫다.¹⁵

이 패턴이 좋은 이유는 세 가지다. 첫째, 문서마다 필요한 정보가 다르기 때문에 점진적 공개가 잘 맞는다. 둘째, 필드 추출이나 변환 같은 작업은 스크립트로 돌릴 때 더 결정적이다. 셋째, 결과 형식이 정해져 있어 평가가 쉽다.¹³

실제로 문서 편집과 PDF, 스프레드시트, 프레젠테이션 처리는 여러 공식 Skill 모음에서 대표 예시로 다뤄질 만큼 재사용 가치가 높은 영역이다.⁶

문서 처리 Skill이 실패하는 흔한 이유도 있다. SKILL.md가 너무 길어서 핵심 절차가 묻히거나, 정책 문서를 복붙해 넣어서 라우팅은 되지만 실행은 흐려지는 경우다. 또 추출은 했는데 검증 단계가 없어서, 보기에는 그럴듯한 잘못된 결과를 내놓기도 쉽다. 문서 처리 Skill은 똑똑한 독서가보다 꼼꼼한 사무 담당자처럼 설계해야 한다.

코드 리뷰: 좋은 리뷰를 우연이 아니라 구조로 만들기

코드 리뷰 역시 Skill로 풀기 좋은 업무다. 많은 팀에서 리뷰 품질은 리뷰어의 경험과 컨디션에 크게 좌우된다. 어떤 날은 보안 이슈를 잘 잡고, 어떤 날은 네이밍만 보다가 끝난다. Skill의 역할은 바로 이 흔들림을 줄이는 것이다.

좋은 코드 리뷰 Skill은 보통 하나의 거대한 체크리스트가 아니다. 오히려 리뷰 관점을 나누는 편이 낫다. 예를 들어 보안, 안정성, 성능, 유지보수성, 테스트 관점으로 나눠서 보게 만들면 에이전트가 한 번에 너무 많은 걸 놓치지 않는다. 복잡한 작업은 하나의 큰 호출보다 나눠서 처리한 뒤 합치는 방식이 더 낫다는 실무 패턴과도 잘 맞는다.²

여기서 특히 중요한 원칙은 단일 책임이다. 백엔드 보안 리뷰 Skill, 프론트엔드 접근성 리뷰 Skill, 데이터 마이그레이션 리뷰 Skill을 따로 두는 편이, 모든 걸 다 보는 만능 리뷰 Skill 하나보다 보통 더 잘 작동한다.⁵

코드 리뷰 Skill 안에는 이런 요소가 들어가면 좋다.

• 어떤 상황에서 이 Skill을 써야 하는지에 대한 분명한 설명

• 위험도 기준과 코멘트 우선순위

• 팀이 반복해서 지적하는 안티패턴

• 좋은 리뷰 코멘트 예시와 나쁜 리뷰 코멘트 예시

• 변경 후 반드시 확인할 테스트나 로그 포인트

이 구조를 쓰면 리뷰가 덜 감정적이고 더 재현 가능해진다. 에이전트는 단순히 코드에 대해 의견을 말하는 것이 아니라, 팀이 중요하게 보는 렌즈를 순서대로 적용하게 된다.

물론 함정도 있다. 기준이 너무 많으면 리뷰가 소설처럼 길어지고, 너무 추상적이면 결국 뻔한 칭찬과 모호한 경고만 남는다. 코드 리뷰 Skill은 똑똑한 평론가보다 정확한 검사표에 가까워야 한다.

웹 테스트: 버그 리포트를 재현 가능한 테스트로 바꾸기

웹 테스트는 Skill의 실용성이 아주 또렷하게 드러나는 장면이다. 사용자는 보통 이렇게 말한다. 로그인 버튼이 가끔 안 눌려요. 장바구니가 모바일에서 이상해요. 결제 후 화면이 멈춰요. 이 문장을 그대로 두면 추상적이지만, 테스트 Skill이 개입하면 재현 시나리오, 테스트 코드, 실행 결과, 다음 액션으로 바뀐다.

이 분야에서 좋은 Skill은 설명부터 다르다. 그냥 테스트를 돕는다고 쓰지 않고, 사용자가 UI 버그를 제보하거나 사용자 플로우 검증을 요청할 때 Playwright 테스트를 만들고 실행하며 실패를 요약한다고 적는 식이다. 이런 라우팅급 설명이 있어야 에이전트가 언제 Skill을 불러야 할지 잘 판단한다.⁴

전형적인 흐름은 이렇다. 먼저 테스트 환경과 실행 명령을 확인하고, 그다음 사용자 시나리오에서 최소 재현 경로를 뽑고, Playwright나 Cypress 테스트를 생성하거나 수정하고, 테스트를 돌리고, 실패를 요약하고, 필요하면 다시 실행한다.⁴

이 패턴이 Skill과 잘 맞는 이유는 테스트 업무가 생각보다 절차적이기 때문이다. 기다림 전략, 셀렉터 우선순위, 더미 계정 사용법, 캡처 저장 위치, 실패 시 로그 수집 규칙 같은 로컬 지식이 많다. 이런 내용은 모델의 일반 상식이 아니라 팀의 작업 방식에 가깝다. Skill은 바로 그 부분을 담당한다.

또한 웹 테스트는 스크립트와의 궁합이 좋다. 테스트 러너 실행, 실패 스크린샷 수집, 리포트 변환처럼 결과가 명확한 일은 코드가 맡고, 에이전트는 시나리오 해석과 다음 단계 판단을 맡으면 된다.⁵

반대로 실패하기 쉬운 경우는 테스트 환경이 불안정한데도 Skill이 그 사실을 모를 때다. 환경 문제와 제품 버그를 구분하지 못하면, 에이전트는 열심히 엉뚱한 고장을 고치기 시작한다. 그래서 웹 테스트 Skill에는 환경 확인 단계와 재시도 정책이 꼭 들어가야 한다.

디자인 가이드: 취향을 매번 설명하지 않게 만들기

디자인 가이드도 Skill로 만들면 의외로 효율이 좋다. 여기서 말하는 디자인은 단지 예쁜 화면이 아니라, 브랜드 톤, 카피 스타일, 컴포넌트 규칙, 금지 표현, 예시 화면, 리뷰 기준까지 포함한 넓은 의미의 디자인이다.

많은 팀이 이 정보를 늘 켜진 규칙으로 밀어 넣고 싶어 하지만, 꼭 그렇지는 않다. 어떤 지침은 항상 필요하지만, 어떤 지침은 랜딩 페이지를 만들 때만 필요하고, 어떤 지침은 배너 카피를 쓸 때만 필요하다. 이런 자료를 모두 상시 컨텍스트에 넣으면 무겁고 산만해진다. 그래서 디자인 관련 지식은 Skill로 분리해 필요할 때만 불러오는 편이 더 낫다.¹⁴

예를 들어 브랜드 카피 Skill에는 이런 구성이 들어갈 수 있다. SKILL.md에는 톤의 핵심 원칙, 금지 문구, 산출물 절차를 적는다. references 폴더에는 긴 브랜드 가이드와 캠페인 예시를 둔다. assets 폴더에는 랜딩 페이지 헤드라인 템플릿, CTA 문안 템플릿, 제품 소개 구조를 둔다. 그러면 에이전트는 단순히 문장을 생성하는 것이 아니라, 브랜드가 이미 합의한 스타일 안에서 작업하게 된다.

이때 특히 중요한 것은 설명의 구체성이다. 디자인을 도와준다고 쓰면 거의 아무 일도 안정적으로 일어나지 않는다. 대신 SaaS 랜딩 페이지, 기능 소개 섹션, 제품 비교표, CTA 카피를 만들 때 사용한다고 구체적으로 적어야 한다. Skill의 설명은 광고 문구가 아니라 라우팅 신호라는 점을 잊지 말자.⁴

디자인 가이드는 재미있는 분야다. 사람은 자꾸 취향이라고 말하지만, 팀이 반복해서 수정하는 부분을 모아보면 의외로 규칙이 많다. Skill은 그 취향을 문서화된 습관으로 바꿔 준다.

사내 업무 자동화: 정책과 예외가 많은 곳에서 진가가 난다

사내 업무 자동화는 Agent Skill이 가장 현실적인 가치를 내는 영역이다. 비용 처리, 구매 요청, 온보딩 체크리스트, 헬프데스크 분류, 인보이스 검증 같은 업무를 떠올려 보자. 겉보기에는 단순 반복 같지만, 실제로는 정책, 예외, 승인, 증빙, 시스템 입력 규칙이 뒤엉켜 있다.

이런 업무에서 Skill은 플레이북 역할을 한다. 예를 들어 비용 처리 Skill은 어떤 영수증이 유효한지, 어떤 항목은 승인 대상인지, 어떤 경우에는 추가 증빙을 요청해야 하는지, 결과를 어떤 형식으로 남겨야 하는지를 설명한다. 여기에 고정된 승인 흐름, 사람 검토 단계, 상태 저장, 재시작 같은 요소는 워크플로가 맡는다. 즉, Skill은 어떻게 판단할지를 맡고, 워크플로는 어떤 순서로 흘릴지를 맡는 셈이다.⁷

이 구분은 중요하다. 워크플로는 미리 정의된 흐름에 강하고, 체크포인팅이나 사람 개입 같은 운영 기능도 잘 제공한다. 반면 Skill은 정책과 절차를 문맥에 맞게 불러오는 데 강하다.⁷ 둘을 섞어 쓰면, 고정된 기업 프로세스 안에서 에이전트의 유연함을 안전하게 끼워 넣을 수 있다.

실무 감각으로 말하면 이렇다. 사내 업무 자동화에서 Skill이 잘 먹히는 업무는 규칙이 많은데 매번 사람이 설명하는 일이다. 그리고 잘 안 맞는 업무는 규칙이 자주 바뀌는데 아무도 Skill을 관리하지 않는 일이다. 낡은 정책을 가진 Skill은 부지런한 신입사원보다 더 위험하다.

평가 파이프라인: 답을 만드는 Skill보다 기준을 만드는 Skill

초보자가 가장 늦게 떠올리지만, 실제로는 매우 중요한 활용처가 평가 파이프라인이다. 많은 팀이 생성 Skill은 열심히 만들면서, 그것이 정말 도움이 되는지 검증하는 Skill은 뒤로 미룬다. 하지만 운영 단계로 가면 오히려 후자가 더 중요해진다.

평가 Skill은 모델의 답변이나 작업 결과를 정해진 기준으로 검토하게 만든다. 예를 들어 사실성, 형식 준수, 안전성, 브랜드 일관성, 테스트 통과 여부 같은 축을 따로 점검할 수 있다. 이런 다면 평가는 병렬화와 잘 맞고, 생성자와 평가자를 분리하는 구조도 잘 맞는다.²

또한 반복 개선이 필요한 작업에서는 생성자와 평가자가 루프를 도는 evaluator-optimizer 패턴이 유용하다. 초안이 나오면 평가 Skill이 부족한 점을 짚고, 생성 Skill이 고치고, 다시 평가하는 식이다. 다만 이 루프는 끝이 없으면 안 되므로, 반복 횟수 제한과 종료 조건이 꼭 필요하다.²⁵

좋은 평가 Skill에는 다음이 들어간다.

• 점수 기준이나 패스 조건

• 실패 유형 분류표

• 예시 입력과 기대 결과

• 구조화된 리포트 형식

• 재시도 여부와 에스컬레이션 조건

이런 Skill이 있으면 모델을 바꾸거나 프롬프트를 바꿔도 비교가 쉬워진다. 즉, 평가 Skill은 단순한 감상문이 아니라 팀의 측정 도구가 된다. 체중계를 사지 않고 다이어트 일기를 쓰는 식으로는 오래 버티기 어렵다.

큰 작업의 사례: 코드 마이그레이션은 왜 Skill 하나로 끝나지 않을까

조금 더 큰 사례로 코드 마이그레이션을 보자. 예를 들어 자바 서비스를 타입스크립트로 옮기는 작업은 한 파일 변환으로 끝나지 않는다. 의존성을 읽어야 하고, 변경 순서를 정해야 하고, 변환 규칙을 일관되게 적용해야 하고, 마지막에는 테스트와 린트로 검증해야 한다.

실무 사례를 보면 이런 작업은 보통 읽기 담당, 계획 담당, 변환 담당처럼 역할을 나눈 뒤, CI 검증까지 묶어 운영한다. 파일을 구조화해 읽고, 의존 관계를 바탕으로 작업 순서를 만들고, 실제 변환을 수행하고, 마지막으로 GitHub Actions, ESLint, Prettier, 테스트로 결과를 검증하는 식이다.⁸

여기서 중요한 교훈은 하나다. 큰 작업일수록 Skill은 규칙을 담고, 오케스트레이션은 흐름을 관리해야 한다. 예를 들어 자바의 특정 애너테이션을 타입스크립트에서 어떻게 바꿀지, 비동기 처리로 바꾸면서 무엇을 조심해야 할지는 Skill에 적는다. 하지만 어떤 파일부터 바꾸고, 실패하면 어디서 멈추고, 어떤 검증을 통과해야 다음 단계로 갈지는 워크플로와 검증 파이프라인이 맡는 편이 안전하다.⁷⁸

즉, Skill은 공구함이고, 오케스트레이션은 작업 감독이다. 큰 공사를 망치는 가장 쉬운 방법은 감독 없이 공구만 좋은 팀을 꾸리는 것이다.

어떤 업무에 어떤 패턴을 붙일까

아래 표는 지금까지 본 사례를 한눈에 정리한 것이다.

표를 보면 감이 온다. Skill은 대부분 지식 묶음이지만, 그 지식이 어떤 흐름 안에서 쓰이는지에 따라 어울리는 운영 패턴이 달라진다. 그래서 실전에서는 Skill만 보지 말고, 그 Skill이 들어갈 업무 흐름까지 같이 봐야 한다.

Skill로 만들지 말아야 할 일도 있다

실전에서는 무엇을 만들지보다 무엇을 만들지 않을지가 더 중요할 때가 많다. 다음 경우에는 Skill이 과한 해법일 수 있다.

• 단발성 요청이라 재사용 이득이 거의 없다.

• 성공 기준이 너무 모호해 평가가 어렵다.

• 항상 적용되는 상시 규칙이라 별도 Skill보다 기본 지침이 낫다.

• 절차보다 탐색이 핵심이라 오히려 고정된 안내가 방해된다.

이럴 때는 짧은 프롬프트, 상시 규칙, 또는 일반 워크플로가 더 낫다.²⁷

마무리: 실전 사례가 알려주는 가장 중요한 감각

이 장의 핵심은 단순하다. 좋은 Skill은 에이전트를 추상적으로 더 똑똑하게 만들지 않는다. 대신 특정 업무를 더 좁고, 더 선명하고, 더 반복 가능하게 만든다.

문서 처리에서는 절차를, 코드 리뷰에서는 관점을, 웹 테스트에서는 재현성을, 디자인 가이드에서는 팀 취향의 구조를, 사내 업무 자동화에서는 정책과 예외를, 평가 파이프라인에서는 측정 기준을 Skill로 묶는다. 그러면 비로소 어떤 업무가 Skill로 잘 풀리는지 감이 생긴다.

처음 Skill 후보를 고를 때는 세 가지만 물어보면 된다.

• 우리 팀이 AI에게 자꾸 반복해서 설명하는 절차가 무엇인가

• 그 절차에서 사람이 꼭 확인해야 하는 마지막 판단은 무엇인가

• 참고 자료, 템플릿, 체크리스트 중 분리해서 불러오면 좋은 것은 무엇인가

이 세 질문에 또렷하게 답할 수 있다면, 그 업무는 이미 절반쯤 Skill이 될 준비를 마친 셈이다.

참고

¹Agent Skills  Microsoft Learn

²Building Effective AI Agents

³Equipping agents for the real world with Agent Skills

⁴Agent Skills Part 2: Patterns, Architecture & Tooling

⁵Skills Patterns  Agent Skills

⁶Awesome Agent Skills

⁷Microsoft Agent Framework Workflows  Microsoft Learn

⁸LLM Agents for Code Migration: A Real-World Case Study