Toss 기술블로그의 **「Skill 품질 관리를 위한 Rubric 설계와 시스템 구현」**은 CLAB Agent Harness를 만들 때 가장 직접적으로 연결되는 자료였다. 하네스를 만들다 보면 skill, prompt, convention, checklist가 계속 늘어난다. 문제는 양이 아니다. 좋은 skill과 나쁜 skill을 가르는 기준이 없으면 하네스는 금방 무거워진다.
CLAB repo에도 같은 위험이 있다. AGENTS.md, CLAUDE.md, .agent/prompts, .agent/templates, convention 문서가 늘어날수록 AI가 읽을 자료는 많아진다. 그런데 각 자료의 품질 기준이 없으면 모델은 중요한 규칙과 임시 메모를 구분하지 못한다.
Toss 글에서 유용했던 관점은 skill을 단순 문서로 보지 않는다는 점이다. Skill은 사람이 읽는 설명서에 가깝지만, 실제 목표는 AI가 일관되게 실행하도록 돕는 것이다. 그러려면 문서가 친절하기만 해서는 부족하다.
CLAB 하네스에서 skill은 이런 조건을 가져야 한다.
- 언제 써야 하는지 trigger가 분명하다.
- 입력과 출력이 정해져 있다.
- 해야 할 일과 하지 말아야 할 일이 같이 적혀 있다.
- 검증 방법이 있다.
- 실패했을 때 멈출 기준이 있다.
- 팀 규칙인지 개인 학습인지 범위가 분리되어 있다.
이 조건이 없으면 skill은 “좋은 말이 많은 문서”가 된다. 그런 문서는 처음에는 도움 되는 것처럼 보이지만, 시간이 지나면 AI가 매번 다른 방식으로 해석한다.
하네스가 커질수록 “이 skill을 넣을까?”보다 중요한 질문은 “이 skill을 어떤 기준으로 유지할까?”다.
예를 들어 CLAB에서 다음과 같은 항목을 skill로 만들 수 있다.
- 작업 요청을 task card로 바꾸는 skill
- member/land/design-system 책임 영역을 판별하는 skill
- PR draft를 쓰는 skill
- UI 변경 후 screenshot evidence를 요구하는 skill
- 팀 메모리로 승격할 후보를 제안하는 skill
전부 필요해 보인다. 하지만 평가 기준이 없으면 skill 목록은 곧 잡동사니가 된다. 어떤 skill은 너무 넓고, 어떤 skill은 실제 repo와 맞지 않고, 어떤 skill은 검증 없이 “잘하자”만 반복한다.
Rubric은 이때 하네스의 품질 관리 장치가 된다. CLAB에 필요한 rubric은 대략 이런 모양이어야 한다.
명확성: 언제 실행해야 하는지 알 수 있는가?
경계: 하지 말아야 할 일이 적혀 있는가?
재현성: 같은 입력에 비슷한 결과가 나오는가?
검증성: 결과를 확인할 방법이 있는가?
팀 적합성: CLAB repo 구조와 실제 작업 방식에 맞는가?
유지보수성: 오래된 규칙을 제거하거나 수정하기 쉬운가?
CLAB 하네스에서 특히 조심해야 할 부분은 개인 학습과 팀 규칙의 경계다. AI가 사용자의 요청 습관이나 반복 실수를 기록하는 것은 도움이 된다. 하지만 그것을 바로 repo에 넣으면 팀 하네스가 감시 장부처럼 보일 수 있다.
그래서 skill 품질 기준에는 출처와 범위가 들어가야 한다.
개인 코칭 메모
- .agent-local/ 아래에 둔다.
- 사용자의 요청 습관, 반복 실수, 개인 선호를 다룬다.
- git에 올리지 않는다.
팀 skill / convention
- repo 안의 .agent/ 또는 docs/에 둔다.
- 여러 사람이 반복해서 겪는 문제만 올린다.
- 근거와 검증 기준이 있어야 한다.
이 분리가 없으면 하네스는 빠르게 불편해진다. 팀에 필요한 것은 개인을 평가하는 기록이 아니라, 반복되는 작업 실패를 줄이는 공유 구조다.
이 Toss 글을 보고 CLAB 하네스에 필요한 것은 skill을 많이 만드는 능력이 아니라 skill을 평가하고 승격시키는 기준이라고 봤다.
처음부터 완벽한 skill set을 만들 필요는 없다. 오히려 처음에는 얇게 시작하는 편이 맞다. 자연어 요청을 task card로 좁히고, repo convention을 찾고, 검증 evidence를 남기는 최소 흐름만 둔다. 이후 반복되는 실패가 확인되면 그때 skill로 승격한다.
다만 승격할 때는 기준이 있어야 한다. “좋아 보인다”가 아니라 trigger, boundary, verification, maintenance가 있는지 봐야 한다. 이 기준이 있어야 CLAB 하네스가 시간이 지날수록 좋아지고, 그냥 문서 더미가 되지 않는다.
Post Q&A
CLAB 인사이트 분석: Skill은 많을수록 좋은 게 아니라 평가 기준이 있어야 한다 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!