한 줄 요약
작은 스킬을 하나의 팁이나 프롬프트 조각으로만 두지 않고, 작업 분류·라우팅·검증 기준까지 담아두면 에이전트가 그 스킬을 기준으로 움직이기 시작합니다. 그 순간 스킬은 단순한 도구가 아니라 작은 하네스처럼 작동합니다.
이런 분들께 도움돼요
코덱스, 클로드 코드, 오픈클로, 헤르메스에서 스킬을 만들어본 분
에이전트에게 매번 같은 작업 기준을 다시 설명하는 게 귀찮았던 분
스킬이 많아졌는데 어떻게 묶고 운영해야 할지 고민하는 분
LLM Wiki를 스킬이나 하네스와 연결해보고 싶은 분
시작점: 작은 스킬 하나가 생각보다 유용했습니다
여러분은 혹시 코덱스나 클로드 코드, 오픈클로, 헤르메스에서 스킬을 만들어 보신 적 있으신가요?
저는 최근에 에이전트를 쓰면서 “스킬 하나를 잘 만드는 것”이 생각보다 큰 차이를 만든다는 걸 느꼈습니다. 처음에는 그냥 특정 작업을 더 잘하게 만드는 작은 설명서 정도로 생각했는데, 계속 쓰다 보니 이게 단순한 프롬프트 조각이 아니더라고요.
예를 들면 이런 식입니다.
리서치할 때 어떤 자료를 먼저 볼지
작업이 커지면 어디서 멈추고 확인할지
결과물을 만들고 나서 어떤 기준으로 검증할지
비슷한 일이 반복될 때 어떤 순서로 처리할지
이런 기준을 매번 대화에서 다시 설명하지 않고, 하나의 스킬 안에 넣어둘 수 있습니다. 그러면 에이전트는 그 작업을 만났을 때 “이번에도 이 기준으로 움직이면 되겠구나” 하고 시작할 수 있습니다.
만든 것: 스킬을 작업 방식의 단 위로 보기
이번에 정리한 핵심은 이겁니다.
> 스킬은 단순히 “이 일을 잘해줘”라는 도움말이 아니라, 작업 방식 자체를 재사용 가능한 운영 단위로 만들 수 있다.
작은 스킬 하나는 보통 특정 작업을 잘하게 만듭니다.
그런데 그 작은 스킬들이 쌓이면, 그다음부터는 다른 문제가 생깁니다.
“이 요청에는 어떤 스킬을 써야 하지?”
“이건 바로 답하면 되는 일인가, 아니면 먼저 분해해야 하는 일인가?”
“작업이 끝났다고 말하기 전에 뭘 확인해야 하지?”
이 질문을 다루기 시작하면, 스킬은 단순한 개별 기능을 넘어서기 시작합니다. 여러 스킬을 묶고, 어떤 상황에서 무엇을 불러올지 정하고, 마지막에 어떤 기준으로 확인할지 잡아주는 상위 흐름이 필요해집니다.
저는 이 지점이 “작은 스킬이 하네스가 되는 순간”이라고 느꼈습니다.
진행 방법
1. 먼저 작은 스킬을 만든다
처음부터 거대한 하네스를 만들려고 하면 오히려 복잡해집니다.
저는 작은 단위부터 보는 게 더 좋다고 생각합니다.
예를 들면:
글쓰기 피드백을 자연스럽게 만드는 스킬
리서치 자료를 정리하는 스킬
스킬을 합치기 전에 영향 범위를 확인하는 스킬
작업이 끝났는지 검증하는 스킬
이런 것들은 각각 작게 시작할 수 있습니다. 중요한 건 스킬 안에 “어떤 상황에서 쓰는지”와 “끝났다고 판단하는 기준”이 들어가야 한다는 점입니다.
2. 작은 스킬들을 묶어 상위 흐름을 만든다
스킬이 몇 개 생기면, 이제 개별 스킬보다 “흐름”이 중요해집니다.
예를 들어 어떤 요청이 들어왔을 때 상위 스킬은 이렇게 판단할 수 있습니다.
이건 단순 질문인가?
아니면 파일을 읽고, 수정하고, 검증까지 해야 하는 작업인가?
리서치 스킬이 필요한가?
글쓰기 스킬이 필요한가?
검증 스킬을 마지막에 붙여야 하는가?
이렇게 되면 상위 스킬은 직접 모든 일을 하는 기능이 아니라, 작업을 분류하고 필요한 스킬을 연결하는 제어층처럼 움직입니다.
저는 이 부분이 하네스에 가깝다고 봤습니다.
하네스는 결과물을 대신 만드는 것보다, 작업이 굴러가는 경로를 잡아주는 쪽에 가깝습니다. 어디서 시작하고, 어떤 순서로 지나가고, 어디서 사람이 확인하고, 어떤 기준을 통과해야 끝났다고 볼지 정해주는 역할입니다.
3. 바뀐 기준은 작은 스킬에 반영한다
좋았던 점은 유지보수 방식입니다.
상위 하네스 안에 모든 규칙을 다 박아두면, 나중에 고치기가 어렵습니다. 그런데 작은 스킬들이 분리되어 있으면 문제가 생겼을 때 해당 스킬만 고치면 됩니다.
예를 들어 글쓰기 결과가 너무 템플릿처럼 나온다면 글쓰기 스킬을 고치면 됩니다. 스킬 병합 전에 영향 범위 확인이 약하다면 영향 범위 점검 스킬을 고치면 됩니다.
그렇게 작은 스킬이 좋아지면, 그 스킬을 부르는 상위 하네스도 같이 좋아집니다.
이게 꽤 재미있었습니다. 작은 부품을 고쳤는데 전체 작업 흐름의 품질이 같이 올라가는 느낌이었습니다.
LLM Wiki와 연결했을 때의 가능성
확장과제 마지막에 LLM Wiki를 활용하는 하네스 스킬 만들어보기가 있었습니다.
저는 여기에 가능성이 꽤 많다고 느꼈습니다.
LLM Wiki는 지식을 쌓아두는 쪽에 가깝고, 스킬은 에이전트가 어떻게 행동할지 정하는 쪽에 가깝습니다. 둘을 연결하면 단순히 자료를 검색하는 것을 넘어서, “내가 쌓아둔 지식을 기준으로 에이전트가 일관되게 행동하게 만드는” 방향으로 갈 수 있습니다.
예를 들면:
LLM Wiki에는 프로젝트 배경, 용어, 실패 기록, 결정 이유를 쌓아둡니다.
스킬에는 그 정보를 어떤 순서로 참고하고, 어떤 기준으로 판단할지 적어둡니다.
하네스는 요청이 들어왔을 때 필요한 wiki 맥락과 스킬을 연결합니다.
그러면 에이전트가 매번 빈 상태에서 추측하는 게 아니라, 제가 쌓아둔 맥락과 작업 규칙을 같이 참고하면서 움직일 수 있습니다.
아직 LLM Wiki를 완전히 연결하지 못했더라도, 먼저 작은 스킬을 하나 만들어보는 것만으로도 시작할 수 있다고 생각합니다.
Before vs After
Before
예전에는 에이전트에게 작업을 시킬 때마다 비슷한 설명을 반복해야 했습니다.
“이건 바로 실행하지 말고 먼저 확인해줘”
“결과만 말하지 말고 검증도 해줘”
“비슷한 스킬이 있으면 중복인지 먼저 봐줘”
“글은 너무 정돈된 템플릿처럼 쓰지 말아줘”
이런 말들이 계속 반복됐습니다. 에이전트가 똑똑해도, 기준이 대화 안에만 있으면 다음 작업에서 다시 흔들릴 수 있습니다.
After
기준을 스킬로 분리하니 흐름이 조금 달라졌습니다.
단순한 일은 가볍게 처리합니다.
복잡한 일은 먼저 작업을 나눕니다.
필요한 전문 스킬을 붙입니다.
마지막에 완료 기준을 확인합니다.
문제가 생기면 어느 스킬의 판단이 약했는지 나눠서 볼 수 있습니다.
즉, 에이전트가 “그때그때 잘 답하는 도구”에서 “정해진 작업 방식 안에서 움직이는 파트너”에 가까워집니다.
결과와 배운 점
이번 정리를 하면서 제일 크게 느낀 건, 스킬은 작게 시작해도 된다는 점이었습니다.
처음부터 완성된 하네스를 만들 필요는 없습니다. 오히려 작은 스킬 하나를 잘 만들고, 실제로 써보고, 이상한 부분을 고치고, 비슷한 스킬과 연결하는 과정에서 하네스가 생기는 것 같습니다.
제가 정리한 장점은 이렇습니다.
판단 기준이 일관됩니다.
간단한 일과 복잡한 일을 구분할 수 있습니다.
전문 기능과 진행 관리를 분리할 수 있습니다.
결과 검증이 쉬워집니다.
문제가 생겼을 때 원인 분석이 쉬워집니다.
작은 스킬을 개선하면 상위 흐름도 같이 좋아집니다.
모든 규칙을 매번 대화에 넣지 않아도 돼서 컨텍스트 비용도 줄어듭니다.
결국 스킬 기반 하네스는 “에이전트에게 더 많은 일을 시키는 방법”이라기보다, “에이전트가 같은 기준으로 일하게 만드는 방법”에 가깝다고 느꼈습니다.
다음에 해볼 것
다음에는 LLM Wiki와 연결해서 조금 더 실험해보고 싶습니다.
예를 들면 이런 방향입니다.
작업 기록을 LLM Wiki에 남기고, 다음 스킬 실행 때 참고하게 하기
실패한 케이스를 wiki에 쌓고, 하네스가 같은 실수를 피하게 하기
특정 창작물이나 리서치 주제에 맞춘 전용 스킬 만들기
작은 스킬들을 묶어서 “리서치용 하네스”, “글쓰기용 하네스”, “스킬 관리용 하네스”처럼 나누기
아직 거창하게 완성된 건 아니지만, 방향은 꽤 분명해진 것 같습니다.
작은 스킬 하나를 만드는 것부터 시작해도 됩니다. 그 스킬이 쌓이고, 연결되고, 검증 기준을 갖기 시작하면 어느 순간 작업 방식 자체를 잡아주는 하네스가 될 수 있습니다.
행복한 하루 되세요, 지피터스 여러분!
