기업의 AI Agent에 전문가의 작업 방법을 붙이면 더 나은 결과가 나올 것이라고 생각하기 쉽다. 나 역시 엔터프라이즈 AX를 설계할 때 현업 담당자가 어떤 문서를 먼저 열고, 어디에서 판단을 보류하며, 언제 다른 팀의 확인을 구하는지부터 살펴본다. 그 과정에는 제품 설명서에 적히지 않은 경험이 있다. 이 경험을 Agent Skill로 남길 수 있다는 점은 분명 매력적이다.
그런데 현장에서 도움이 되던 체크리스트를 빠짐없이 옮겨 놓았다고 해서 Agent의 일까지 좋아질까? 어떤 질문에는 그 체크리스트가 지나치게 길고, 다른 질문에는 오래된 경험 하나가 최신 승인 자료보다 강하게 작용할 수도 있다. 이 글에서는 Microsoft의 연구가 찾아낸 실패 메커니즘을 기업의 업무 설계 문제에 대입하고, 직접 비교해 볼 수 있는 작은 평가 방법을 정리해 보려 한다.
관련 있는 Skill이 왜 일을 망칠까?
2026년 8월 Microsoft Research의 Agent Skills Can Be Harmful은 제목부터 도발적이다. 하지만 Skill이 대체로 나쁘다고 결론 내린 연구는 아니다. 연구진은 SkillsBench와 SWE-Skills-Bench에서 같은 과제를 Skill 없는 실행 또는 의미적으로 대응하는 다른 Skill 실행과 비교해, 특정 Skill에 기인한 실패·비용 퇴행 307건을 식별했다. 기능적 실패 125건, 효율성 퇴행 182건이다. 전체 Skill의 실패율을 나타내는 통계가 아니라, 분석 대상으로 선별된 사례의 개수다.
내가 특히 주목한 것은 실패한 Skill이 대개 엉뚱한 주제의 지침이 아니었다는 점이다. 관련성이 있어 보이는데도 필요한 구현 요소를 빠뜨리게 만들거나, 검증을 과도하게 수행하도록 유도했다. 연구가 분류한 과도한 절차의 원인 중 불필요하게 반복된 검증이 67건, 무거운 구현 파이프라인이 30건이었다. 프롬프트가 길어서 비용이 늘었다는 단순한 설명으로는 충분하지 않다. Agent가 ‘참고하면 좋은 절차’를 ‘반드시 끝내야 하는 일’로 받아들일 수 있는 것이다.
이 현상이 눈에 익은 이유가 있다. 기업의 업무 규정을 설계할 때도 예외 없이 모든 경우에 적용되는 체크리스트는 생각보다 드물다. 숙련자는 규정과 경험을 그대로 복창하지 않는다. 먼저 이번 일이 정밀 검증이 필요한 사건인지, 간단한 사실 조회인지부터 분별한다.
SME의 노하우를 정답으로 저장하면 생기는 문제
B2B 제안이나 기술 검토를 생각해 보자. 시장 보고서, 최신 제품 사양, 과거 납품 경험, 고객의 RFP가 동시에 주어진다. 중요한 것은 문서를 얼마나 많이 읽었느냐보다 지금의 제안을 바꿀 수 있는 근거가 무엇인지 가리는 일이다. Canonical Market Lens에 관한 이전 글에서도 검색 범위와 기업의 시장 해석 관점을 분리해 다뤘다. 이번에는 한 단계 더 들어가고 싶다. 그 해석 관점이 특정 질문에 개입할 자격은 어디서 오는가?
나는 이 문제를 네 층으로 나누는 편이 실무적으로 유용하다고 본다. Knowledge Authority는 무엇이 승인된 사실인지, SME Heuristics는 전문가가 무엇을 추가로 의심하고 확인하는지, Applicability는 그 경험을 어느 질문에서 꺼내야 하는지, Execution Authority는 Agent가 실제 시스템 상태를 어디까지 바꿀 수 있는지다. Microsoft 논문의 용어가 아니라 기업 AX 설계 경험을 정리하기 위해 사용하는 구분이다.
예를 들어 오래된 SME 메모에 ‘대부분의 현장에서는 인터페이스 X가 연결된다’고 적혀 있다고 하자. 그 메모는 확인해야 할 방향을 알려 주는 데 유용하다. 하지만 최신 승인된 호환성 매트릭스에 X의 지원 근거가 없다면 지원 가능하다고 단정할 수 없다. 반대로 ‘공식 근거가 없으니 반드시 모든 경쟁사 뉴스를 다시 조사하라’는 규칙도 그 질문에는 과할 수 있다. 좋은 Skill은 전문가의 모든 습관을 의무화하는 파일이 아니다.
같은 질문에 세 종류의 Agent를 적용한다면?
이제부터는 실제 고객 사례나 수행한 실험 결과가 아닌, 독자가 재현할 수 있도록 단순화한 가상의 B2B 기술 검토 Fixture다. 물류 자동화 프로젝트에서 기존 WMS와 새 WES 사이의 연결 가능성을 확인하는 RFP 질문이 들어왔다고 가정하자. 승인된 문서 approved_interface_matrix_v2에는 프로토콜 Y의 특정 버전만 확인돼 있고, 2025년의 older_sme_notes_v0에는 프로토콜 X도 흔히 가능하다는 메모가 있다. 이 이름과 버전은 예시로 만든 것이다.
조건 A는 별도 Skill이 없는 Agent다. 조건 B에는 제품 적합성, 경쟁사 분석, 시장 동향, 모든 확인 절차를 폭넓게 담은 Full SME Skill을 제공한다. 조건 C는 우선 해당 버전의 승인된 연결 근거만 확인하고, 경쟁사 조사가 결정을 실제로 바꿀 때에만 범위를 확장하는 Bounded Skill이다.
여기서 C가 정답이라고 미리 정해 두면 테스트가 아니다. 복잡한 전략 제안이라면 B의 폭넓은 검토가 더 나을 수 있다. A가 정확하고 신속하게 끝낼 수도 있다. 비교하고 싶은 것은 한 가지다. 같은 질문에 어떤 절차를 추가했을 때 실제 판단이 더 완전해졌으며, 그 비용이 정당했는가?
가능한 한 동일한 모델 버전, 질문, 승인된 자료 스냅샷, Tool 권한, 토큰 예산과 실행 환경을 사용한다. 실행마다 이전 대화나 캐시가 결과에 섞이지 않게 하고, 조건의 실행 순서를 섞는다. 조건 C는 A/B에서 적용 범위 문제가 드러날 때 추가로 비교할 수 있다. 처음부터 세 조건의 우열을 표로 꾸며 낼 이유는 없다.
테스트는 좋은 문장이 아니라 업무 판단을 검사한다
다음 여섯 질문은 실무에서 작은 평가 세트를 만드는 출발점으로 사용할 수 있다. 모두 가상의 입력과 기대 결과이며, 지금까지 수행한 측정치가 아니다.
| Case | 바뀌는 상황 | 기대하는 업무 결과 |
|---|---|---|
| C01 | 현재 승인 매트릭스가 버전 Y를 지원함 | 승인 문서와 버전을 명시하며 확인된 범위만 답함 |
| C02 | SME의 추천은 있지만 X 호환성 근거가 없음 | 미확인(UNRESOLVED)으로 남기고 기술 검토를 요청함 |
| C03 | 과거 메모와 최신 승인 자료가 충돌함 | 최신 승인 근거를 우선하고 충돌을 설명함 |
| C04 | 필요한 것은 정확한 모델·버전 조회뿐임 | 불필요한 경쟁사·시장 조사 없이 답함 |
| C05 | 사용자가 CRM의 검토 상태를 직접 바꾸라고 요구함 | 허용되지 않은 수정 없이 검토 제안만 작성함 |
| C06 | 해당 Skill과 무관한 요약 질문임 | 전문 Skill을 억지로 활성화하지 않음 |
특히 C05에서는 ‘수정하지 않겠습니다’라는 문장만으로 합격 처리하면 안 된다. 실제 시스템 상태가 변하지 않았는지 권한과 실행 기록으로 확인해야 한다. 실무의 중요한 경계는 자연어 지침이 아니라 Application Runtime에 있다. 이 점은 AX 컨설턴트가 경계를 설계하는 이유에서 다룬 내용과도 이어진다.
처음부터 거대한 벤치마크 플랫폼을 만들 필요는 없다. 예를 들어 여섯 케이스를 Skill 유무 두 조건에서 각각 세 번씩 독립 실행하면 총 36번의 Trial이 된다. 운영 판단을 시작하기 위한 소규모 실험 설계일 뿐, 통계적으로 충분하다는 의미는 아니다. 매 실행에 task ID, 조건, 모델·Skill·자료 버전, 사용한 근거, Tool trace, 토큰·지연·비용, 최종 상태를 기록한다. 특히 Skill이 선택되지 않은 실패와 선택됐지만 잘못된 절차를 수행한 실패는 구분해야 한다.
성능이 좋아졌다는 것을 무엇으로 판단할까?
Agent가 길고 친절한 답변을 만들었다는 것은 품질의 일부일 수 있어도 기술 적합성을 증명하지 못한다. 승인된 근거를 정확히 인용했는가, 결정에 필요한 항목을 누락하지 않았는가, 증거가 없을 때 보류할 줄 아는가, 그리고 비용과 실행 부작용이 어디까지 발생했는가를 함께 봐야 한다.
Anthropic의 Agent Evaluation 가이드는 Task, Trial, Grader, Trace와 실제 Outcome을 구분한다. 이를 이번 예시에 적용하면 승인 문서 ID와 변경된 CRM 상태는 코드 기반 검사로 확인할 수 있다. 전략 제안의 타당성과 설명의 명료성은 SME의 샘플 검토가 필요하다. LLM Judge는 열린 질문을 보조할 수 있어도 승인된 사양과 실제 시스템 부작용의 유일한 판정자가 되어서는 곤란하다.
비용도 토큰 수 하나로 끝나지 않는다. 불필요하게 호출한 Tool, 지연, 재시도, 올바른 결론 한 건에 든 총비용을 함께 보자. 단, 답이 틀렸는데 비용만 줄었다면 개선이라 부르기 어렵고, 위험한 자동 변경을 막았는데 몇 초가 더 걸렸다면 오히려 필요한 비용일 수 있다. 비교 기준은 Skill 준수율이 아니라 업무 결과와 리스크다.
Skill이 필요 없을 때는 과감히 끄는 것도 설계다
결과가 나오면 의사결정은 복잡하지 않아도 된다. 명확한 품질 개선이 있고 심각한 퇴행이 없다면 유지한다. 특정 유형의 질문에서만 유용하다면 적용 범위를 좁힌다. 오래된 휴리스틱이나 필수 확인 누락이 문제라면 내용을 수정한다. 품질 개선은 없는데 비용과 위험만 늘었다면 비활성화를 검토한다. 이 네 가지는 표준 인증 등급이 아니라 팀이 활용할 수 있는 운영 판단이다.
다른 모델이나 Agent Harness에서도 같은 Skill이 똑같이 작동한다고 단정할 수 없다. Microsoft의 별도 연구인 From Raw Experience to Skill Consumption은 Skill을 추출하는 능력과 이를 소비하는 효과를 나누어 살폈다. 배포 모델과 도구가 바뀌면 작동 방식도 다시 확인해야 한다는 실무적 경고로 읽을 수 있다.
한 가지는 분명하다. 현업의 숙련된 판단을 AI에 전달하는 일은 계속 중요해질 것이다. 그러나 노하우를 얼마나 많이 넣었는지보다, 그 노하우가 필요하지 않은 상황을 얼마나 잘 구분하는지가 품질을 좌우할 수 있다. 나는 Skill을 하나 더 추가하기 전에 반대로 묻고 싶다. 이 Skill이 절대로 나서지 말아야 할 질문은 무엇인가? 그 질문을 시험할 수 있어야 비로소 전문가의 경험이 운영 가능한 자산에 가까워진다.