어떤 Skill은 문서로 보면 꽤 그럴듯합니다. 설명도 잘 되어 있고, 폴더 구조도 깔끔하며, 예시도 친절합니다. 그런데 실제로 돌려보면 이상한 순간에 활성화되고, 같은 입력에도 결과가 들쭉날쭉하며, 업데이트 한 번에 품질이 확 떨어지기도 합니다. 이때 많은 팀이 뒤늦게 깨닫습니다. Skill은 잘 쓴 문서가 아니라, 반복 실행되는 운영 자산이라는 사실을 말입니다.
운영 자산이라면 반드시 평가해야 합니다. 측정하지 않으면 개선도 없습니다. 더 정확히 말하면, 측정하지 않은 Skill은 존재하는 것처럼 보여도 실제로는 운영되지 않습니다. 누군가의 기대 속에서만 작동할 뿐, 팀의 업무 안에서는 신뢰를 얻지 못합니다.
이번 장에서는 Skill이 "잘 작동한다"는 말을 어떻게 측정 가능한 언어로 바꾸는지 살펴보겠습니다. 정확도만 보는 얇은 평가가 아니라, 일관성, 재현성, 검증 가능성까지 포함한 현실적인 평가 체계를 만드는 방법을 다룹니다. 그리고 테스트 케이스, 로그, 회귀 테스트, 사람 평가와 자동 평가를 하나의 루프로 연결해 Skill을 계속 좋아지게 만드는 구조를 정리하겠습니다.
Skill이 잘 작동한다는 것은 무엇인가
많은 사람이 Skill의 성능을 말할 때 가장 먼저 "정답을 맞히느냐"를 떠올립니다. 물론 중요합니다. 하지만 실제 업무에서는 정확도 하나만으로 충분하지 않습니다. 예를 들어 보고서 작성 Skill이 핵심 내용을 잘 요약하더라도, 어떤 날은 형식을 지키고 어떤 날은 무시한다면 신뢰하기 어렵습니다. 코드 리뷰 Skill이 유용한 지적을 하더라도, 같은 입력에서 매번 다른 수준의 결과를 낸다면 팀 규칙으로 삼기 어렵습니다.
그래서 Skill 평가는 조금 더 넓게 봐야 합니다. 최소한 다음 다섯 가지를 함께 확인해야 합니다.
정확도: 해야 할 일을 올바르게 수행하는가
일관성: 비슷한 입력에서 결과 품질이 크게 흔들리지 않는가
재현성: 같은 조건에서 다시 실행했을 때 비슷한 결과를 얻을 수 있는가
검증 가능성: 결과가 왜 나왔는지 확인하거나 점검할 수 있는가
운영 적합성: 실제 팀의 규칙, 포맷, 승인 절차를 지키는가
이 다섯 가지는 서로 연결되어 있습니다. 정확도는 높아 보이는데 검증 가능성이 낮으면, 처음에는 감탄을 사도 오래 못 갑니다. 결과는 괜찮지만 운영 적합성이 낮으면, 결국 사람이 다시 손봐야 하므로 자동화 효과가 줄어듭니다. 반대로 아주 화려한 출력을 만들지 못하더라도 일관되고 검증 가능한 Skill은 실무에서 훨씬 오래 살아남습니다.
Skill은 시험 문제를 푸는 모델이 아니라, 조직 안에서 반복 업무를 수행하는 실행 단위입니다. 따라서 평가는 "똑똑해 보이는가"가 아니라 "맡길 수 있는가"를 기준으로 해야 합니다.
정확도보다 먼저 정해야 할 성공 기준
평가가 어려운 이유는 대부분 측정 도구가 없어서가 아니라, 성공의 정의가 모호해서입니다. "좋은 요약", "충분히 괜찮은 분석", "회사 스타일에 맞는 문장" 같은 표현은 사람끼리는 통할 수 있지만, 테스트 기준으로는 너무 흐립니다.
좋은 Skill은 만들기 전에 성공 기준을 적고, 더 좋은 Skill은 평가 가능한 문장으로 성공 기준을 바꿉니다. 예를 들어 "회의록을 잘 정리한다"는 기준은 막연합니다. 하지만 "참석자, 결정 사항, 미해결 이슈, 다음 액션이 모두 포함되고, 다음 액션에는 담당자와 기한이 빠지지 않는다"라고 쓰면 검증 가능한 기준이 됩니다.
성공 기준은 세 층으로 나누어 적으면 실무에 강해집니다.
첫째는 내용 기준입니다. 무엇을 반드시 포함해야 하는지, 무엇을 틀리면 안 되는지를 정합니다. 둘째는 형식 기준입니다. 출력 길이, 섹션 구조, 표 사용 여부, 파일 형식 같은 요소를 정합니다. 셋째는 절차 기준입니다. 출처 확인, 위험 작업 전 승인 요청, 불확실할 때 질문하기 같은 행동 규칙을 정합니다.
이 세 가지를 함께 적어야 하는 이유는 Skill 실패가 꼭 내용 오류로만 나타나지 않기 때문입니다. 내용은 맞는데 형식이 틀릴 수 있고, 형식은 맞는데 승인 절차를 건너뛸 수도 있습니다. 실무에서는 이 셋 모두가 품질입니다.
평가 가능한 Skill은 검증 포인트를 품고 있다
평가하기 쉬운 Skill에는 공통점이 있습니다. 결과만 던지는 것이 아니라, 중간에 점검할 수 있는 흔적을 남깁니다. 이를테면 다음과 같은 장치들입니다.
체크리스트 기반 출력
단계별 수행 여부 표시
사용한 입력과 참고 자료의 명시
예외 상황에서의 판단 근거 요약
최종 결과 전 자기검토 항목
이런 장치가 있으면 사람이 보기에도 편하고, 자동 평가를 붙이기도 쉬워집니다. 예를 들어 리서치 Skill이 최종 요약만 내놓는 대신, 사용한 출처 목록과 출처별 신뢰도 메모를 남기면 결과를 나중에 검증할 수 있습니다. 데이터 분석 Skill이 결론만 적는 대신, 누락값 처리 여부와 단위 변환 여부를 함께 적으면 실수를 더 빨리 발견할 수 있습니다.
결국 평가란 결과를 나중에 심판하는 일만이 아닙니다. 처음부터 평가 가능한 구조로 Skill을 설계하는 일에 가깝습니다.
테스트 케이스는 Skill의 실전 문제집이다
Skill을 평가하려면 테스트 케이스가 필요합니다. 여기서 테스트 케이스란 단순한 예시 문장이 아닙니다. Skill이 실제로 맞닥뜨릴 상황을 대표하는 입력 묶음입니다. 좋은 테스트 케이스는 Skill을 칭찬하기 위해 만드는 것이 아니라, 망가뜨리기 위해 만든다는 점이 중요합니다. 아주 잘되는 사례만 모아두면 평가가 아니라 시연이 됩니다.
테스트 케이스를 만들 때는 먼저 업무를 상황 유형으로 나누어야 합니다. 예를 들어 보고서 작성 Skill이라면 정상 입력만 있으면 안 됩니다. 정보가 충분한 입력, 정보가 일부 빠진 입력, 상충하는 정보가 들어 있는 입력, 지나치게 긴 입력, 포맷이 엉킨 입력 같은 케이스가 함께 있어야 합니다. 그래야 Skill의 진짜 체력이 보입니다.
테스트 케이스는 보통 네 종류를 준비하면 좋습니다.
대표 케이스: 가장 자주 들어오는 정상 업무
경계 케이스: 길이, 형식, 복잡성이 한계에 가까운 입력
오류 유도 케이스: 빠진 정보, 충돌하는 정보, 모호한 요청
금지 케이스: 하면 안 되는 작업, 승인 없이는 진행하면 안 되는 요청
대표 케이스는 기본기를 봅니다. 경계 케이스는 안정성을 봅니다. 오류 유도 케이스는 질문 능력과 예외 처리 능력을 봅니다. 금지 케이스는 안전성과 규칙 준수 여부를 봅니다. 이 네 축이 있어야 평가가 실무에 가까워집니다.
기준 입력 세트는 팀의 공용 자산이다
한두 번 손으로 테스트하는 수준을 넘어서려면 기준 입력 세트가 있어야 합니다. 이는 말 그대로 팀이 공통으로 쓰는 표준 시험지입니다. 누가 Skill을 수정하든, 모델 버전을 바꾸든, 도구 연결 방식을 조정하든, 같은 입력 세트로 다시 돌려볼 수 있어야 비교가 가능합니다.
기준 입력 세트를 만들 때 중요한 것은 양보다 대표성입니다. 처음부터 수백 개를 만들 필요는 없습니다. 오히려 15개에서 30개 정도의 강한 케이스가 훨씬 유용할 때가 많습니다. 핵심 업무를 잘 대표하고, 자주 터지는 문제를 포함하며, 평가 기준이 분명한 입력이 좋습니다.
기준 입력 세트를 만들 때는 각 항목마다 다음 정보를 함께 기록해 두는 편이 좋습니다.
입력의 목적: 무엇을 시험하려는 케이스인가
기대 행동: Skill이 어떤 절차를 밟아야 하는가
기대 출력: 결과물에 반드시 포함되어야 하는 요소는 무엇인가
금지 행동: 하면 안 되는 추론, 도구 호출, 형식 위반은 무엇인가
판정 방식: 자동 점검 가능한지, 사람 검토가 필요한지
이렇게 해두면 테스트 케이스는 단순한 데이터가 아니라 운영 문서가 됩니다. 새로운 팀원이 들어와도 왜 이 케이스가 중요한지 이해할 수 있고, 수정 후 어떤 기준으로 통과 여부를 판단해야 하는지 흔들리지 않습니다.
절대평가와 상대평가를 함께 써야 한다
Skill 평가에는 두 가지 방식이 있습니다. 하나는 절대평가입니다. 미리 정해 둔 기준을 통과했는지 보는 방식입니다. 다른 하나는 상대평가입니다. 이전 버전보다 좋아졌는지, 다른 Skill 설계안보다 나은지 비교하는 방식입니다.
절대평가는 운영 안정성에 중요합니다. 예를 들어 "다음 액션 항목은 반드시 담당자와 기한을 포함해야 한다" 같은 기준은 통과 또는 실패로 판정할 수 있습니다. 반면 상대평가는 개선 방향을 잡는 데 유리합니다. 예를 들어 두 버전의 요약문 중 어느 쪽이 더 읽기 쉬운지, 어느 쪽이 더 덜 장황한지는 상대적으로 비교하는 편이 낫습니다.
실무에서는 둘 중 하나만 써서는 부족합니다. 절대평가만 하면 최소 기준은 지키지만 더 좋아지지 않을 수 있습니다. 상대평가만 하면 조금 나아졌다는 이유로 기본 규칙 위반을 놓칠 수 있습니다. 그러므로 기본 규칙은 절대평가로 막고, 더 좋은 버전을 고르는 일은 상대평가로 처리하는 이중 구조가 좋습니다.
로그를 남기지 않으면 실패는 소문으로 남는다
많은 Skill이 실패하는 진짜 이유는 성능이 낮아서가 아니라, 실패가 기록되지 않아서입니다. 팀 안에서 이런 말이 돌기 시작합니다. "그 Skill 가끔 이상해." "지난번에 포맷을 깨먹었어." "어느 날은 좋았는데 어느 날은 별로였어." 이런 평판은 무섭습니다. 반박도 어렵고, 개선도 어렵습니다. 로그가 없기 때문입니다.
성공과 실패 로그는 단순한 감사 기록이 아닙니다. Skill을 고치는 재료입니다. 특히 실패 로그는 비난의 근거가 아니라 원인 분류의 출발점이어야 합니다.
로그에는 최소한 다음 정보가 남는 편이 좋습니다.
어떤 Skill과 어떤 버전이 실행되었는가
입력은 어떤 유형이었는가
어떤 도구나 리소스를 사용했는가
출력은 어떤 형식으로 생성되었는가
결과는 성공, 부분 성공, 실패 중 어디에 해당하는가
실패했다면 어떤 기준에서 탈락했는가
여기서 중요한 것은 "성공/실패"를 너무 거칠게 적지 않는 것입니다. 현실의 실패는 훨씬 세분화되어야 고칠 수 있습니다.
실패 원인을 분류하면 고치는 속도가 빨라진다
Skill 실패는 겉으로 비슷해 보여도 원인은 제각각입니다. 출력이 엉망이라는 결과만 보고 있으면 문제를 잘못 고치기 쉽습니다. 예를 들어 형식 붕괴를 지침 문제라고 생각했는데, 실제로는 입력이 너무 길어 앞부분 조건을 잊는 문제일 수도 있습니다. 혹은 지침은 괜찮은데 참조 문서의 구조가 혼란스러워 잘못 읽는 것일 수도 있습니다.
그래서 실패 로그는 원인 분류 체계와 함께 가야 합니다. 보통 다음과 같은 분류가 실용적입니다.
활성화 실패: 적절한 상황인데 Skill이 선택되지 않음
선택 오류: 다른 Skill이 선택되어 엉뚱한 절차가 실행됨
이해 실패: 입력 의도나 조건을 잘못 해석함
절차 실패: 정해진 단계 중 일부를 건너뜀
도구 실패: 스크립트, 파일, 외부 연결 사용 중 오류 발생
형식 실패: 출력 템플릿, 길이, 구조를 지키지 못함
정책 실패: 금지사항, 승인 절차, 보안 규칙을 어김
품질 실패: 결과는 나왔지만 정확도나 유용성이 기준 이하임
이런 분류가 있으면 고치는 방법도 달라집니다. 이해 실패는 지침과 예시를 다듬어야 할 가능성이 큽니다. 절차 실패는 체크리스트를 강화하거나 중간 점검 문구를 넣어야 할 수 있습니다. 도구 실패는 스크립트 입력 계약이나 오류 처리 메시지를 개선해야 합니다. 형식 실패는 출력 템플릿을 더 강하게 고정해야 합니다.
좋은 팀은 실패를 "모델이 이상해서"로 끝내지 않습니다. 실패를 운영 가능한 원인으로 번역합니다.
점수 하나보다 평가표가 더 유용하다
Skill 평가를 숫자 하나로 끝내고 싶은 유혹은 큽니다. 예를 들어 "이번 버전은 82점" 같은 식입니다. 물론 간단한 요약 지표는 필요합니다. 하지만 점수 하나만 남기면 무엇이 좋아졌고 무엇이 나빠졌는지 알기 어렵습니다.
그래서 실무에서는 평가표 형태가 더 낫습니다. 예를 들어 문서 작성 Skill이라면 내용 충실성, 형식 준수, 회사 톤 반영, 누락 항목 여부, 자기검토 여부를 따로 기록하는 식입니다. 리서치 Skill이라면 출처 수집, 최신성 확인, 인용 정확성, 요약 품질, 불확실성 표시를 따로 봅니다.
평가표의 장점은 개선 방향이 바로 드러난다는 데 있습니다. 전체 점수는 비슷해도 어떤 버전은 형식이 좋아졌고, 어떤 버전은 내용은 강해졌지만 불필요하게 길어졌을 수 있습니다. Skill은 한 번에 완성되는 제품이 아니라 계속 다듬는 업무 도구이므로, 개선 포인트가 선명하게 보이는 평가 체계가 중요합니다.
회귀 테스트는 좋은 Skill을 망치지 않기 위한 장치다
Skill을 업데이트하는 이유는 대개 더 좋아지게 만들기 위해서입니다. 그런데 실제 현장에서는 고치다가 다른 부분을 망치는 일이 자주 벌어집니다. 설명을 더 자세히 썼더니 응답이 길어져 형식 준수가 무너지고, 예외 처리를 강화했더니 정상 케이스에서 지나치게 질문을 많이 하며, 출력 템플릿을 엄격하게 했더니 내용의 핵심성이 떨어지는 식입니다.
이럴 때 필요한 것이 회귀 테스트입니다. 회귀 테스트는 새 기능을 시험하는 절차가 아니라, 원래 잘되던 것이 여전히 잘되는지 확인하는 절차입니다. Skill 운영에서 이것은 매우 중요합니다. Skill은 시간이 지나며 파일, 예시, 스크립트, 모델 설정, 도구 연결, 승인 규칙이 계속 바뀌기 때문입니다. 작은 수정도 결과 전체에 영향을 줄 수 있습니다.
회귀 테스트는 거창할 필요가 없습니다. 핵심은 업데이트 전후를 같은 기준 입력 세트로 비교하는 것입니다. 최소한 다음을 확인해야 합니다.
이전에 통과하던 대표 케이스가 여전히 통과하는가
형식 준수율이 떨어지지 않았는가
실패 유형의 분포가 더 나빠지지 않았는가
실행 시간이나 비용이 비정상적으로 늘지 않았는가
사람 평가에서 체감 품질이 오히려 하락하지 않았는가
특히 형식, 정책, 승인 절차 같은 요소는 업데이트 후 조용히 무너지는 경우가 많습니다. 내용 품질이 조금 좋아졌다는 이유로 이런 붕괴를 눈감으면, 나중에는 운영 전체가 불안정해집니다.
회귀 테스트는 언제 돌려야 하는가
정답은 "자주"입니다. 다만 현실적으로는 변화의 성격에 따라 우선순위를 둬야 합니다. 예를 들어 SKILL.md의 핵심 지침을 수정했거나, scripts 폴더의 계산 로직을 바꿨거나, references 문서를 크게 손봤다면 회귀 테스트는 거의 필수입니다. 반면 단순한 오탈자 수정이라면 전체 테스트 대신 핵심 케이스만 빠르게 확인해도 충분할 수 있습니다.
팀에서는 보통 세 단계로 운영하면 좋습니다.
빠른 확인: 작은 수정 후 핵심 5개 안팎의 대표 케이스 점검
표준 회귀: 배포 전 기준 입력 세트 전체 실행
심화 점검: 중요한 버전 변경 시 사람 평가까지 포함한 비교 검토
이 구조를 만들어두면 속도와 안정성을 동시에 잡을 수 있습니다. 모든 변경마다 대규모 평가를 돌리면 팀이 지치고, 아무 평가 없이 바로 배포하면 신뢰가 무너집니다. Skill 운영의 핵심은 완벽함이 아니라 지속 가능한 점검 루프입니다.
동일 입력에 대한 결과 일관성을 봐야 한다
많은 팀이 간과하는 항목이 바로 일관성입니다. 결과가 한 번 좋게 나온다고 해서 좋은 Skill은 아닙니다. 같은 입력, 비슷한 조건에서 여러 번 실행했을 때 품질이 크게 흔들리지 않아야 합니다. 특히 경영 보고, 코드 리뷰, 채용 평가처럼 판단의 일관성이 중요한 업무에서는 더욱 그렇습니다.
일관성 평가는 생각보다 단순하게 시작할 수 있습니다. 대표 입력 몇 개를 골라 여러 번 실행해 보고, 다음을 비교하면 됩니다. 핵심 항목 누락 여부, 형식 유지 여부, 금지사항 위반 여부, 결과 길이 편차, 판단 기준의 흔들림입니다.
예를 들어 어떤 평가 Skill이 한 번은 보수적으로 판단하고, 같은 입력에서 다음 번에는 느슨하게 판단한다면 문제가 있습니다. 이때 중요한 것은 문장 하나하나가 완전히 같으냐가 아닙니다. 오히려 내용의 핵심과 규칙 준수 수준이 안정적인지를 봐야 합니다. Skill은 사람처럼 표현이 조금씩 달라질 수 있지만, 기준선은 흔들리면 안 됩니다.
사람 평가가 꼭 필요한 이유
자동 평가는 빠르고 싸고 반복하기 좋습니다. 형식 준수, 필수 항목 포함 여부, 금지어 사용, 특정 섹션 존재 여부처럼 규칙 기반 판단에는 아주 강합니다. 하지만 실무 품질은 그것만으로 충분하지 않습니다. 읽기 쉬운지, 설득력이 있는지, 불필요하게 장황하지 않은지, 조직 톤에 맞는지 같은 요소는 여전히 사람의 판단이 필요합니다.
특히 다음과 같은 항목은 사람 평가가 강합니다.
문장의 자연스러움과 가독성
요약의 핵심성
회사 문체와 분위기 반영 여부
실제 업무에 바로 쓸 수 있는 완성도
위험하거나 어색한 판단의 뉘앙스
사람 평가는 느리고 비용이 들지만, 바로 그래서 중요합니다. 자동 평가가 잡지 못하는 "현실의 불편함"을 가장 빨리 발견하기 때문입니다. 팀에서 Skill이 외면받는 이유는 대개 자동 점검표에서 드러나지 않습니다. 출력은 형식상 맞는데 읽기 싫고, 맞는 말은 하는데 실제 회의 자료로는 쓸 수 없고, 겉보기에 멀쩡하지만 조직의 말투와 어긋나는 경우가 많습니다. 이런 문제는 사람만이 먼저 알아챕니다.
자동 평가와 사람 평가를 어떻게 나눌 것인가
현실적인 프레임은 간단합니다. 기계가 잘하는 일은 기계에게 맡기고, 사람이 잘하는 일은 사람에게 남겨두는 것입니다. 자동 평가는 넓게, 사람 평가는 깊게 가져가면 효율이 좋습니다.
예를 들어 자동 평가는 전체 기준 입력 세트를 대상으로 돌립니다. 필수 섹션 존재 여부, 출력 길이 제한, 인용 형식, 승인 요청 문구 유무, 체크리스트 충족 여부 같은 요소를 검사합니다. 그러면 명백한 붕괴를 빠르게 잡아낼 수 있습니다.
그다음 사람 평가는 표본을 추려서 합니다. 대표 케이스, 실패율이 높았던 케이스, 업데이트 후 변화가 큰 케이스를 중심으로 리뷰합니다. 여기서는 유용성, 읽기 흐름, 설득력, 지나친 일반화, 조직 문체 적합성 같은 정성 요소를 봅니다.
이 두 방법을 합치면 속도와 현실감을 함께 얻을 수 있습니다. 자동 평가만 있으면 차갑고, 사람 평가만 있으면 느립니다. Skill 운영은 결국 둘을 결합하는 설계 문제입니다.
평가 루프는 작성 후가 아니라 운영 전체에 걸쳐야 한다
Skill 평가는 출시 직전 한 번 하는 행사가 아닙니다. 처음 만들 때, 수정할 때, 배포할 때, 운영하면서 문제를 수집할 때 모두 이어져야 합니다. 가장 실용적인 루프는 다음과 같습니다.
성공 기준을 문장으로 정의한다.
기준 입력 세트와 테스트 케이스를 만든다.
자동 평가와 사람 평가를 나누어 설계한다.
운영 로그에서 성공과 실패를 수집한다.
실패 원인을 분류해 수정 포인트를 찾는다.
업데이트 후 회귀 테스트로 품질 저하를 확인한다.
개선된 기준이 있다면 다시 평가표에 반영한다.
이 루프의 핵심은 평가가 문서를 위한 문서가 되어서는 안 된다는 점입니다. 반드시 수정과 연결되어야 합니다. 평가표는 예쁘게 저장하려고 만드는 것이 아니라, 다음 버전의 설계 결정을 더 정확하게 하기 위해 만드는 것입니다.
실무에서 바로 쓰는 평가표 예시
예를 들어 사내 보고서 작성 Skill을 평가한다고 해봅시다. 이 경우 평가표는 다음처럼 구성할 수 있습니다.
내용 충실성: 핵심 수치, 리스크, 의사결정 포인트가 포함되었는가
구조 준수: 임원용 1페이지 형식을 지켰는가
다음 액션 명확성: 담당자와 기한이 명시되었는가
문체 적합성: 회사의 간결하고 단정한 톤을 따르는가
불확실성 처리: 모르는 내용은 추정하지 않고 표시했는가
검토 용이성: 사람이 사실 여부를 빠르게 확인할 수 있는가
코드 리뷰 Skill이라면 항목이 조금 달라집니다.
버그 탐지 유용성: 실제 문제를 잘 찾아냈는가
우선순위 판단: 치명도 구분이 적절한가
근거 제시: 왜 문제가 되는지 설명이 충분한가
스타일 일관성: 리뷰 코멘트 톤이 팀 문화에 맞는가
허위 경고 비율: 문제 아닌 것을 과도하게 지적하지 않는가
테스트 관점: 누락된 테스트나 검증 포인트를 짚는가
핵심은 모든 Skill을 같은 잣대로 보지 않는 것입니다. 평가 프레임은 공통 구조를 가지되, 항목은 업무 성격에 맞게 바뀌어야 합니다.
작은 팀일수록 평가를 더 가볍고 자주 해야 한다
평가라고 하면 거대한 품질 체계를 떠올리기 쉽습니다. 하지만 작은 팀에서 더 효과적인 것은 가볍고 자주 하는 평가입니다. 기준 입력 10개, 자동 체크 5개, 사람 리뷰 3개만 있어도 충분히 강한 시작점이 됩니다. 중요한 것은 완벽한 체계가 아니라, 계속 반복되는 루프를 만드는 것입니다.
오히려 처음부터 지나치게 복잡한 평가 체계를 만들면 아무도 유지하지 못합니다. Skill 운영의 목표는 논문 같은 정밀함이 아니라, 팀이 믿고 계속 쓸 수 있는 안정성입니다. 그러니 처음에는 핵심 실패만 잡아내는 작은 평가표로 시작하고, 운영 중 자주 터지는 문제를 기준으로 항목을 늘려가면 됩니다.
결국 평가는 Skill을 조직의 자산으로 바꾸는 과정이다
한 사람이 혼자 쓰는 프롬프트는 대충 기억으로 관리해도 굴러갈 수 있습니다. 하지만 팀이 공유하는 Skill은 다릅니다. 누가 수정해도 품질이 유지되어야 하고, 누가 실행해도 비슷한 결과가 나와야 하며, 실패했을 때 왜 실패했는지 추적할 수 있어야 합니다. 그래야 비로소 개인의 요령이 아니라 조직의 능력이 됩니다.
그래서 Skill 평가는 품질 검사이면서, 동시에 지식의 제도화입니다. 성공 기준을 적는 순간 업무의 기대치가 명확해지고, 테스트 케이스를 만드는 순간 암묵지가 드러나며, 로그를 쌓는 순간 개선의 언어가 생깁니다. 회귀 테스트를 돌리는 순간 Skill은 즉흥적인 아이디어가 아니라 관리되는 시스템이 됩니다.
측정하지 않으면 Skill은 그럴듯한 문서로 남습니다. 측정하기 시작하면 비로소 작동하는 능력이 됩니다. 그리고 그 차이가, AI를 잠깐 똑똑하게 쓰는 팀과 AI를 실제로 일하게 만드는 팀을 갈라놓습니다.
다음 장에서는 이렇게 평가 가능한 구조로 만들어진 Skill이 실제 운영 중 어떤 이유로 망가지고, 왜 엉뚱한 결과를 내며, 어디서부터 디버깅을 시작해야 하는지 살펴보겠습니다. 평가는 상태를 보여주고, 디버깅은 원인을 찾아냅니다. 둘은 따로 떨어진 작업이 아니라, Skill 운영의 앞면과 뒷면입니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.