프롬프트를 skill로 바꿔 블록처럼 쌓기

Read this post in English.

같은 프롬프트를 세 번째쯤 복사해서 붙여넣다 보면, 이걸 아예 skill로 만들어 둘까 하는 생각이 든다. 지난 글에서 세션이 끝나면 실패, 결정, 지식, skill을 골라 남겨야 한다고 했는데, 그중 skill은 다음에도 반복할 절차와 그 검증 방법이다. 그런데 반복해서 쓰는 프롬프트를 전부 skill로 만들어야 할까?

꼭 그렇지는 않다. 아직 문제가 정확히 무엇인지도 모르는 탐색 단계에서는 일회성 프롬프트가 더 빠르고 부담도 적다. 이때 인터페이스와 평가부터 고정하면 잘못된 추상화를 오래 유지하게 된다. 지난 글에서 한 번 성공한 방법을 바로 memory에 올리면 안 된다고 한 것과 같은 이야기다.

이야기가 달라지는 건 같은 작업이 실제로 반복되고, 성공과 실패를 구분할 수 있게 된 다음이다. 그럼 언제 프롬프트를 skill로 바꾸고, skill 안에는 무엇을 넣고, 그 skill이 제대로 작동하는지는 어떻게 알 수 있을까?

언제 skill로 만들까

이런 조건이 여러 개 맞으면 만들 만한 가치가 생긴다.

• 같은 종류의 작업이 실제로 반복된다.
• 입력과 기대 출력의 형태가 비교적 안정적이다.
• 성공과 실패를 확인 가능한 기준으로 나눌 수 있다.
• 사용할 도구와 권한의 경계를 정할 수 있다.
• 매번 손으로 고치는 비용이나 실패 비용이 크다.

결국 따져볼 것은 이 부등식이다.

skill을 만들고 유지하는 비용 < 프롬프트를 반복하고, 고치고, 실패하는 데 드는 누적 비용

“세 번 쓰면 만든다”는 출발점으로는 괜찮지만 기준이 횟수 하나일 수는 없다. 열 번을 반복했더라도 사람의 취향이 핵심인 작업이나 성공 기준이 계속 바뀌는 작업은 skill로 고정하기 어렵다.

프롬프트 한 줄과 skill의 차이

기술 블로그를 검토하는 skill을 만든다고 해 보자. 가장 단순한 프롬프트는 이렇다.

이 글을 검토하고 개선점을 알려줘.

한 번 쓰기에는 충분하다. 하지만 이걸 재사용하려면 적어도 다음이 정해져 있어야 한다.

• Goal: 핵심 주장을 보존하면서 사실 오류와 독자 오해를 줄인다.
• Input/Output: 글 초안, 출처 목록, 그리고 이 글을 누가 읽을지를 받는다. 같은 문장도 읽는 사람에 따라 오해가 생기는 곳이 다르기 때문이다. 결과로는 문제가 되는 구절, 그 이유, 수정안을 돌려준다.
• Tools/Permissions: 허용된 원문만 읽고, 글을 직접 고치지 않고 수정안만 낸다.
• Invariant: 확인되지 않은 사실이나 저자의 경험을 지어내 넣지 않는다.
• Stop/Escalation: 중요한 문제가 없으면 끝내고, 출처끼리 충돌하면 사람에게 묻는다.
• Eval/Version: 인용이 실제로 뒷받침되는지, 핵심 주장이 유지되는지, 비전문가가 이해하는지를 기준으로 평가하고, 그 기준에 버전을 붙여 둔다.

이 목록은 문서를 그럴듯하게 꾸미려는 게 아니다. 입력 형식이 바뀌었는데 계속 실행할지, 출처가 충돌할 때 한쪽을 알아서 고를지, 평가 기준이 바뀐 뒤에도 이전 결과와 비교할 수 있는지가 여기서 정해진다. 프롬프트만 복사해 가면 이런 경계는 사람의 기억 속에만 남는다. skill로 옮긴다는 건 프롬프트 문장이 아니라 인터페이스와 검증 방법을 함께 옮긴다는 뜻이다.

출력 형식도 마찬가지다. 보기 좋게 만드는 규칙이 아니라 단계 사이에서 의미가 사라지지 않게 하는 약속이다.

skill 안에는 무엇을 넣을까

skill이 모든 일을 글로 쓴 설명만으로 처리할 필요는 없다. 따로 만들어 둔 스크립트를 실행하라고 시킬 수 있고, 특정 단계는 subagent에게 맡기라고 적어 둘 수도 있고, 여러 단계를 정해진 순서로 도는 workflow를 통째로 넣을 수도 있다.

위의 검토 skill로 보면 이렇다.

• 링크가 살아 있는지, 인용한 문장이 원문에 실제로 있는지는 따로 만들어 둔 스크립트를 실행해서 확인한다. 매번 같은 답이 나와야 하는 일을 모델에게 시키면 비싸고 결과도 들쑥날쑥하다.
• 비전문가 리뷰는 subagent에게 맡긴다. 앞 단계에서 저자의 의도를 다 들은 모델은 글이 어디서 어려운지 잘 느끼지 못한다. 아무 맥락 없이 글만 받은 쪽이 막히는 곳을 더 잘 찾는다.
• 근거 확인 → 비전문가 리뷰 → 수정안 정리처럼 순서가 정해진 부분은 workflow로 적어 두고, 모델이 매번 순서를 새로 정하지 않게 한다.

이렇게 나눠 두면 평가도 쉬워진다. 스크립트로 뺀 부분은 일반 테스트로 확인하면 되고, LLM 채점은 정말 판단이 필요한 부분에만 쓰면 된다.

skill이 많아지면 고르는 것도 일이다

skill을 하나둘 만들다 보면 금방 수십, 수백 개가 된다. 그러면 어떤 skill을 언제 쓸지 고르는 것 자체가 문제가 된다. Anthropic이 설명한 Agent Skills 방식에서는 에이전트가 처음에 설치된 모든 skill의 이름과 짧은 설명만 읽어 두고, 지금 작업에 맞는다고 판단한 skill만 본문을 열어 읽는다¹. skill이 몇 개일 때는 이걸로 충분하다. 하지만 수백 개가 되면 설명만 읽는 데도 context가 꽤 들고, 설명이 비슷한 skill끼리 헷갈려서 엉뚱한 skill을 고르거나 필요한 skill을 놓치기 쉽다.

헷갈리지 않게 하는 첫 번째 방법은 설명을 잘 쓰는 것이다. 개인적으로 만들어 쓰는 지식 관리 도구가 있는데, 뇌 같은 느낌으로 cortex라고 이름을 붙였다. cortex의 skill 설명에는 언제 쓰는지뿐 아니라 언제 쓰지 않는지도 적어 둔다. 지난 작업 세션을 찾는 skill에는 지식 베이스 검색이 아니라고 적고, 여러 모델에게 토론을 시키는 skill에는 테스트로 확인할 수 있는 질문에는 쓰지 말라고 적는 식이다. 그래도 skill이 많아지면 설명만으로는 부족하고, 모델이 고르기 전에 후보를 먼저 줄이는 단계가 필요할 것 같다.

1. 하드 필터: activation keyword, 파일 종류, 저장소, 작업 단계처럼 확실한 조건으로 먼저 거른다. 요청에 “리뷰”나 “PR”이라는 말이 없으면 리뷰 skill은 후보에 올리지 않는 식이다. 싸고 결과가 늘 같지만, 표현이 조금만 달라도 놓친다.
2. 싼 모델이나 검색: 남은 후보 중에서 지금 요청과 가까운 skill 몇 개만 고른다. 표현이 달라도 잡을 수 있지만, 이 단계도 틀릴 수 있다.
3. 본 모델: 좁혀진 후보의 설명을 읽고 실제로 쓸 skill을 고른다.

좋은 블록을 이어도 좋은 시스템이 되지는 않는다

skill 하나를 블록 하나라고 생각해 보자. 레고 블록을 쌓듯이 여러 skill을 이어 workflow를 만들고, 앞에서 말한 것처럼 그 workflow를 다시 하나의 skill 안에 넣을 수도 있다. 예를 들어 글 하나를 쓰는 과정은 자료 수집, 근거 검증, 논지 구성, 초안 작성, 전문가 리뷰, 비전문가 리뷰, 한 페이지 요약이라는 블록 7개로 나눌 수 있고, 이걸 순서대로 엮으면 “글쓰기”라는 더 큰 skill 하나가 된다. 블록마다 따로 고치고 다른 작업에 다시 쓸 수 있으니 편하다.

문제는 블록이 많아질수록 실패할 수 있는 곳도 많아진다는 점이다. 각 블록이 서로 독립적으로 95% 확률로 성공하고 모두 성공해야 끝난다고 단순하게 가정하면, 위의 7개 블록이면 전체 성공률이 약 70%로 떨어진다. 실제 실패는 독립적이지 않으니 예측값은 아니지만, 블록이 늘수록 실패가 쌓인다는 방향은 보여준다.

그리고 블록 자체만이 아니라 블록 사이의 연결 부분도 실패 지점이 된다. 이 연결 부분을 이 글에서는 연결부(seam)라고 부른다. 예를 들어 자료 수집 블록이 URL과 요약만 넘기고 원문의 어느 부분인지를 버리면, 다음 근거 검증 블록은 인용을 확인할 수 없다. 두 블록이 각자의 테스트는 통과했는데 연결된 시스템은 이미 실패한 것이다.

그래서 평가도 세 층으로 나눠 보는 게 좋다.

1. 블록 평가(Block eval): skill 하나가 약속한 일을 하는가. 출력 형식, 정확도, 비용, 경계 사례에서의 실패를 본다.
2. 연결부 평가(Seam eval): 다음 단계로 넘어갈 때 출처, 불확실성, 전제가 그대로 전달되는가. 형식만 맞는지가 아니라 다음 단계가 기대하는 전제를 앞 단계가 실제로 보장했는지 본다. 실패했을 때 다시 시도할지, 다른 경로로 갈지, 사람에게 넘길지도 정해져 있어야 한다.
3. 시스템 평가(System eval): 전체가 실제 목적을 달성했는가. 최종 성공률, 비용, 사람이 개입한 횟수, 되돌릴 수 있는지, 운영 환경까지 넘어간 실패를 본다.

앞에서 말한 skill 고르기도 여기에 들어간다. 요청과 skill 사이도 하나의 연결부이기 때문이다. 엉뚱한 skill이 불리면 그 skill이 자기 일을 아무리 잘해도 최종 목적은 실패한다. 이런 실패는 블록 평가로는 안 보이고 연결부나 시스템 평가에서 보인다. 그래서 실제 요청 수십 개에 “이 요청에는 이 skill이 맞다”는 정답을 달아 두고, 불렸어야 할 skill이 안 불린 경우와 안 불려야 할 skill이 불린 경우를 따로 센다. 그러면 필터나 skill 설명을 고칠 때마다 다시 돌려 볼 수 있다.

skill을 블록으로 만들고 workflow로 이어 붙이고 평가까지 돌리는 걸 실제로 해 본 사례가 있다. 우리 팀과 가깝게 일하는 동료 중에 거의 완전히 AI-native로 일하는 사람이 있다. 우리 팀이 만든 AI 취약점 탐지·수정 시스템인 MDASH²를 개발할 때 그 동료가 일하는 걸 옆에서 봤고, 이 글과 지난 글의 생각도 그 동료와 이야기하면서 많이 정리됐다. 이런 방식을 실제로 보고 싶다면 그 동료가 공개해 둔 amplihack-rs가 참고하기 좋다. 코딩 에이전트용 workflow 프레임워크인데, 2026년 10월 기준 저장소에는 SKILL.md 파일만 200개가 넘고 평가 관련 파일도 많다³.

다른 모델에게 채점을 맡기면 될까

지난 글에서 검증은 모델 밖에서 해야 한다고 했다. 그런데 채점을 다른 모델에게 맡기면 어떨까? 정답이 하나가 아닌 글쓰기나 설계 같은 문제에서는 모델 여러 개의 리뷰가 실제로 쓸모 있다. 하지만 모델 수를 늘리는 것과 독립적인 검증을 늘리는 것은 다르다.

Apple의 Correlated LLM Evaluation Panels 연구는 7개 모델 계열에서 채점 모델 9개를 골라 자연어 추론 과제와 두 답 중 나은 쪽을 고르는 선호 비교 과제를 채점하게 했다. 그런데 9개가 낸 정보는 서로 독립적인 판정 2.0~2.5개 정도에 해당했다⁴. 여러 모델이 같은 항목에서 같이 틀리는 경향이 있었다는 뜻이다. 시험한 과제에 한정된 결과이고, 공유된 학습 데이터 때문인지까지 밝힌 것은 아니다.

그래서 모델과 다른 방식으로 실패하는 수단을 먼저 둔다. unit test와 property test, parser와 type checker, 실제 실행, 명시적인 invariant, 사람이 따로 만들어 둔 holdout 같은 것들이다. 모델 리뷰를 쓸 때도 “여러 모델이 동의했다”가 아니라 각 지적이 원문과 논리로 성립하는지를 확인한다.

LLM으로 채점할 때는 먼저 무엇을 묻는지가 중요한 것 같다. “이 글이 좋은가?”처럼 점수 하나를 물으면 왜 그 점수가 나왔는지 확인하기 어렵다. 앞에서 정한 평가 기준을 쪼개서 “이 인용이 주장을 실제로 뒷받침하는가”, “핵심 주장이 바뀌었는가”처럼 근거를 가리키며 답할 수 있게 물어야 사람이 결과를 다시 확인할 수 있다.

채점하는 모델에도 버릇이 있다. LLM-as-a-Judge 연구는 LLM 채점자가 답이 놓인 순서, 답의 길이, 자기 답인지 여부에 따라 판단이 흔들린다고 보고했고⁵, 다른 연구는 LLM이 자기가 쓴 글을 알아보고 더 높게 채점하는 경향을 보였다⁶. 글을 쓴 모델에게 그대로 채점을 맡기면 안 되는 이유다.

채점은 어떤 모델로 할까

채점은 skill을 고칠 때마다 다시 돌려야 해서 비용이 금방 쌓인다. 그럼 싼 모델로 많이 돌리는 게 나을까, 비싼 모델로 적게 돌리는 게 나을까? 앞에서 말한 MDASH는 단계마다 모델을 나눠 쓴다. 어려운 추론에는 최신 모델을, 양이 많은 토론 단계에는 싼 증류(distilled) 모델을 쓰고, 또 다른 최신 모델을 독립적인 견제 역할로 둔다².

나도 비슷한 고민을 했다. 앞에서 말한 cortex에는 모델이 글에서 뽑은 주장이 원문 근거와 맞는지 다른 모델이 확인하는 단계가 있다. 일종의 채점이라, 여기에 쓸 모델을 몇 가지 비교해 봤다.

가장 비싼 최신 모델은 너무 많이 걸렀다. 주장을 뽑은 모델과는 다른 회사의 중간급 모델보다 약 두 배 많이 탈락시켰는데, 그중에는 근거가 제대로 있는 주장도 있었다. 반대로 주장을 뽑은 모델과 같은 회사의 모델은 주장의 14%만 걸러서 사실상 도장만 찍었다. 더 정확하고 더 싼 건 그 중간급 모델이었다. 채점 프롬프트를 다듬고 다시 비교하자 최신 모델도 과하게 거르지 않았다. 최신 모델과 중간급 모델의 결과가 같아졌으니 싼 중간급 모델을 그대로 두었다. 다만 비교한 표본이 작아서 더 어려운 문제에서는 결과가 달라질 수 있다.

그래서 채점 모델은 정답을 알고 있는 작은 셋에서 먼저 비교해 보고 고르는 게 맞는 것 같다. 충분히 맞으면 싼 모델로 넓게 돌리고, 애매한 것만 비싼 모델이나 사람에게 올리면 된다.

마치며

skill의 가치는 프롬프트를 길게 저장하는 데 있지 않은 것 같다. 반복할 수 있는 부분과 매번 다시 판단해야 하는 부분을 나누고, 실패가 어느 블록과 어느 연결부에서 생겼는지 추적할 수 있게 해 주는 데 있다. 평가할 수 없고 유지할 수 없는 skill은 재사용 가능한 능력이라기보다 나중에 문제가 될 추상화에 가깝다.

3줄요약

• skill은 입력과 출력이 안정되고 성공을 잴 수 있을 때 만들고, 프롬프트와 함께 권한, 멈출 조건, 평가 기준까지 옮긴다.
• skill이 많아지면 후보를 먼저 줄여서 고르고, 이어 붙인 skill은 블록, 연결부, 시스템 세 층으로 나눠 평가한다.
• 모델 여러 개가 채점해도 독립적인 검증이 그만큼 늘지는 않으니, 테스트를 먼저 두고 채점 모델은 정답을 아는 작은 셋에서 비교해 보고 고른다.

참고 자료

1. Anthropic, Equipping agents for the real world with Agent Skills (2025-10-16) ↩︎

2. Microsoft, Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark (2026-05-12) ↩︎ ↩︎²

3. rysweet, amplihack-rs ↩︎

4. Apple, Nine Judges, Two Effective Votes: Correlated Errors Undermine LLM Evaluation Panels (2026-06-23) ↩︎

5. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv, 2023-06) ↩︎

6. Panickssery et al., LLM Evaluators Recognize and Favor Their Own Generations (arXiv, 2024-04) ↩︎