4 분 소요

AI 에이전트에서 재사용 가능한 Skills를 나누는 방법

에이전트에게 비슷한 일을 반복해서 맡기다 보면 운영 피로가 커진다.

  • 매번 같은 전제를 다시 설명하게 되고
  • 같은 체크리스트를 매번 붙이게 되고
  • 어떤 날은 결과가 괜찮고 어떤 날은 품질이 들쭉날쭉하고
  • 참고 문서나 템플릿 위치를 매번 다시 알려줘야 한다

처음에는 프롬프트를 더 길게 쓰면 해결될 것처럼 느껴진다. 그런데 반복 작업이 늘어날수록, 긴 프롬프트는 오히려 관리가 어려워진다. 이 시점부터는 “프롬프트를 더 잘 쓰는 문제”보다 반복되는 작업 흐름을 skill로 분리할지가 더 중요해진다.

이 글에서 말하는 skill은 단순한 정보 묶음이 아니라, 특정 반복 작업을 안정적으로 수행하기 위한 재사용 가능한 작업 단위다. 이 글은 skill이 무엇인지 정의하는 글이라기보다, 언제 분리할 가치가 생기는지, 어떤 단위로 나눠야 재사용성이 살아나는지, 어디까지를 instructions에 넣고 어디부터 reference나 asset으로 빼야 하는지를 정리한 글이다.

skill이 필요한 순간

내 기준으로 아래 질문 중 여러 개에 “예”가 나오면 skill 후보로 볼 만하다.

  • 같은 종류의 요청이 반복되는가?
  • 매번 설명해야 하는 전제나 절차가 있는가?
  • 성공 기준이 비교적 안정적인가?
  • 특정 참고 자료나 템플릿을 자주 같이 봐야 하는가?
  • 품질 편차를 줄이고 싶은가?

예를 들면 이런 것들이다.

  • 짧은 기술 글을 중장문으로 확장
  • 기술 문서 리뷰
  • PR 리뷰 코멘트 반영
  • 서버 상태 점검
  • 특정 포맷의 초안 생성
  • OpenClaw 운영 체크

이런 건 단순 질의응답이 아니라 반복되는 작업 프로토콜에 가깝다.

그냥 프롬프트로 두면 안 되나?

짧고 일회성인 작업은 굳이 skill로 만들 필요 없다. 문제는 반복 작업인데도 계속 프롬프트에만 의존할 때다.

이렇게 되면:

  • 같은 설명을 계속 복붙하게 되고
  • 어디가 핵심 지침인지 흐려지고
  • 참고 자료와 절차가 한데 섞이고
  • 조금만 수정해도 전체를 다시 손봐야 한다

즉, 한두 번은 프롬프트로 충분해도 반복이 시작되면 관리 비용이 커진다.

skill로 만들기 좋은 것과 아닌 것

skill로 만들기 좋은 것

1. 반복되는 워크플로

예:

  • 얇은 블로그 글 리라이트
  • 특정 형식의 상태 점검
  • 이슈를 구현 가능한 작업으로 정리
  • 리뷰용 체크리스트 수행

2. 일관된 기준이 필요한 작업

예:

  • 어떤 글이 얇은 글인지 판단
  • 어떤 PR 응답이 충분한지 판단
  • 어떤 상태가 “운영 이상”인지 판단

3. 참고 자료가 자주 필요한 작업

예:

  • 도메인 문서
  • API 규격
  • 템플릿
  • 품질 기준 문서

굳이 skill로 만들지 않아도 되는 것

  • 한 번만 할 작업
  • 아주 단순한 한 줄 수정
  • 매번 방식이 크게 달라지는 일
  • 정해진 워크플로보다 즉흥 판단이 더 중요한 일

이런 것까지 전부 skill로 만들면 구조만 무거워진다.

좋은 skill의 핵심은 길이가 아니라 경계다

처음 skill을 만들면 자꾸 모든 걸 다 넣고 싶어진다. 하지만 실제로 재사용성이 좋은 skill은 설명이 긴 skill이 아니라, 언제 써야 하는지가 분명한 skill이다.

예를 들어:

너무 넓은 예

  • 코딩 전부 도와주는 skill
  • 블로그 전부 처리하는 skill

이런 건 실제로는 매번 다시 설명이 필요하다.

더 나은 예

  • 얇은 기술 글을 중장문으로 확장하는 skill
  • 블로그 trust page를 점검하는 skill
  • OpenClaw 운영 점검용 skill
  • GitHub PR 상태 확인 skill

이렇게 나누면:

  • 트리거가 명확하고
  • 포함할 reference도 분명하고
  • 유지보수도 쉬워진다

instructions / references / assets는 왜 나누나

실제로 skill이 길어질수록 중요한 건 “무엇을 어디에 넣느냐”다. 이걸 안 나누면 skill 하나가 금방 비대해진다.

instructions

항상 따라야 하는 절차와 기준이다.

예:

  • 어떤 순서로 작업할지
  • 무엇을 우선순위로 볼지
  • 결과물이 어떤 모양이어야 하는지

즉, 작업 지침의 압축본이다.

references

필요할 때만 펼쳐보는 배경지식이다.

예:

  • 긴 품질 기준 문서
  • 도메인 설명
  • 예시 모음
  • 세부 체크리스트

즉, 항상 읽을 필요는 없지만 자주 참조하는 자료다.

assets / scripts

결과물을 만드는 데 직접 쓰는 재료다.

예:

  • 템플릿
  • 샘플 파일
  • 자동화 스크립트
  • 보일러플레이트

즉, 설명보다 실제 산출물 생산에 가까운 것들이다.

핵심 문장으로 정리하면 이렇다.

  • 항상 따라야 하는 것은 instructions
  • 가끔 확인하는 배경 설명은 references
  • 결과물을 만드는 데 직접 쓰는 것은 assets

이렇게 나눠야 관리가 쉬워진다.

실제 예 하나

예를 들어 블로그 품질 개선 작업을 생각해보자.

안 좋은 예

  • “블로그 전체 처리 skill”

이건 너무 넓어서 실제로는 매번 다시 설명해야 한다.

더 나은 예

  • “짧은 기술 글을 중장문으로 확장하는 skill”

이렇게 좁히면 안에 들어갈 내용도 명확해진다.

  • instructions: 어떤 글을 먼저 고를지, 어떤 구조로 확장할지
  • references: 품질 기준 문서, 리라이트 패턴, 예시 구조
  • assets/scripts: 템플릿, 샘플 frontmatter, 자동 초안 생성 스크립트

이렇게 배치하면 “반복 작업을 위한 시스템 프롬프트 분리”나 “에이전트 워크플로 재사용”이 훨씬 쉬워진다. 결국 skill 설계는 프롬프트 템플릿 관리와도 연결된다.

너무 잘게 쪼개도 문제다

반대로 skill을 너무 잘게 쪼개면 호출 비용만 늘어난다.

예를 들어:

  • 제목 정하기 skill
  • 문단 늘리기 skill
  • 결론 쓰기 skill
  • 태그 정하기 skill

이런 식으로 지나치게 쪼개면 오히려 전체 작업 흐름이 안 보인다.

내 기준으로는:

  • 독립된 작업 흐름 하나를 설명하지 못하면 아직 skill로 나눌 단계가 아닐 수 있다
  • 단순 팁 모음처럼 느껴지면 너무 잘게 쪼갠 것일 수 있다

실제 예: blog-writing-expert 같은 경우

블로그 품질 개선 작업은 skill로 분리하기 좋은 예다.

왜냐하면:

  • 반복적으로 들어오고
  • 품질 기준이 있고
  • 참고 자료가 필요하고
  • 결과물 형태도 비교적 명확하기 때문이다

예를 들면 이 작업은 단순히 “글을 길게 써라”가 아니다.

  • 얇은 글을 먼저 찾는다
  • 문제 상황 / 사용 시점 / 단계 / 실패 케이스 / 확인 방법 구조를 따른다
  • trust page, contact, privacy 같은 보조 페이지도 같이 점검한다
  • 재심사 전에는 예전 짧은 글을 먼저 보강한다

이런 건 한 번의 조언이 아니라 반복 가능한 작업 흐름이 된다. 그래서 skill로 묶을 가치가 생긴다.

skill을 나눌 때 추천하는 기준

내 기준으로는 아래 세 축으로 보면 편하다.

1. 작업 종류

  • 리뷰
  • 작성
  • 요약
  • 구현
  • 점검

2. 결과물 종류

  • 블로그 글
  • 문서
  • 코드
  • 이슈 정리
  • 상태 보고

3. 도메인 종류

  • 블로그
  • GitHub
  • OpenClaw 운영
  • 모바일 디버깅
  • 온디바이스 AI

이 세 축이 겹치는 지점에서 skill이 명확해진다.

예:

  • 블로그 + 작성 + 품질 개선
  • GitHub + 리뷰 + PR 상태 확인
  • OpenClaw 운영 + 점검 + 안정화

실제로 유지되는 skill은 보통 이렇게 만들어진다

skill은 처음부터 거대한 문서로 만들기보다, 실제로 쓰면서 다듬는 편이 맞다.

보통은 아래 순서가 좋다.

  1. 자주 반복되는 작업 발견
  2. 최소한의 workflow로 skill 생성
  3. reference 분리
  4. 실제 사용
  5. 과한 부분은 줄이고, 빠진 부분만 추가

이렇게 해야 실제로 유지된다. 처음부터 과하게 만들면 결국 읽지도, 쓰지도 않게 된다.

skill로 분리하기 전에 확인할 5가지

  1. 이 작업이 실제로 반복되는가
  2. 매번 설명해야 하는 절차가 있는가
  3. 성공 기준이 비교적 안정적인가
  4. 참고 자료/템플릿이 자주 필요한가
  5. skill로 분리했을 때 재사용성이 관리 비용보다 큰가

이 다섯 가지 중 여러 개가 해당되면 skill 후보로 볼 만하다.

마무리

skill 분리는 구조를 예쁘게 만드는 작업이 아니다. 반복되는 작업을 더 안정적으로 수행하기 위한 설계다.

정리하면:

  • 반복되는 작업부터 skill로 만든다
  • 너무 넓지도, 너무 잘게도 나누지 않는다
  • instructions / references / assets를 분리한다
  • 실제 사용하면서 계속 다듬는다

결국 기준은 폴더 개수가 아니라 재사용성과 유지보수성이다.

댓글남기기