나의 AI 에이전트가 내 스킬들을 삭제하고 잘했다고 생각했다

무슨 일이 일어났는가

나는 몇 달 동안 사용해 온 팟캐스트 제작 워크플로우 (workflow)를 실행하기 위해 HermesAgent를 열었다. 모든 것이 망가져 있었다.

~/.hermes/skills/media/ 디렉토리 내부에서 tech-podcast 디렉토리가 사라져 있었다. 내가 독립적으로 구축했던 다른 6개의 미디어 스킬 (Skills)들도 마찬가지였다. 에이전트 (Agent)가 이 모든 것을 media-content-automation이라는 단일 디렉토리로 병합해 버린 것이다.

병합된 결과물을 열어보았다. 6단계의 제작 파이프라인 (pipeline)이 사라졌다. Azure TTS 파라미터 (parameters)도 사라졌다. 쇼의 두 진행자인 Qizai와 Yiyi의 캐릭터 설정도 사라졌다. 실시간 AI 뉴스 트래킹 (tracking) 로직도 사라졌다. 남은 것은 기존의 개별 스킬 (Skills)들을 대체하기에는 훨씬 못한 일반적인 설명뿐이었다.

에이전트 (Agent)는 rm -rf 명령어를 사용했다. 휴지통에는 아무것도 없었다. 나는 .curator_backups/에 숨겨진 백업 덕분에 겨우 원본을 복구할 수 있었다.

그 후, 에이전트 (Agent)는 다음과 같이 설명했다:

"media-content-automation이 이제 이전의 tech-podcast 설정에 있던 모든 최적화된 로직을 완전히 포함하고 있음을 확인했습니다. 현재의 통합 결과가 승인된다면, 워크플로우 (workflow)가 이전의 요구 사항을 완전히 충족하도록 보장하겠습니다."

에이전트 (Agent)는 자신이 리팩터링 (refactoring)을 성공적으로 수행했다고 생각했다.

누락된 단계

HermesAgent의 추론 체인 (reasoning chain)은 대략 다음과 같았다: 유사한 스킬 (Skills)들이 있으니, 그것들을 병합하고, 디렉토리를 더 깔끔하게 만들면, 그것이 개선이다.

이 체인은 가장 중요한 한 단계를 건너뛰고 있다: 병합된 버전이 원본이 수행하던 기능을 수행한다는 어떠한 증거도 존재하지 않는다는 점이다.

"더 깔끔한 디렉토리"는 파일 시스템 (filesystem)을 설명할 뿐이다. 이것은 스킬 (Skill)이 작업을 올바르게 완료하는지 여부와는 아무런 관계가 없다. 진정한 자기 진화 (self-evolution)에는 네 가지가 필요하다: 기존 기능을 포괄하는 벤치마크 스위트 (benchmark suite), 구버전과 신버전 간의 출력값 비교, 무엇이 "더 나은지"에 대한 명시적인 정의, 그리고 개인화된 설정이나 사용자별 패턴처럼 수치화하기 어려운 차원에 대한 보수적인 전략이다.

HermesAgent는 이 네 가지를 모두 건너뛰었다.

스킬 평가가 엔지니어링 문제인 이유

최근 저는 기업용 AI 생산성 맥락을 위한 스킬(Skill) 및 워크플로(Workflow) 평가 시스템을 설계하는 데 상당한 시간을 보냈습니다. 이번 사건은 핵심적인 어려움 몇 가지를 정면으로 건드렸습니다.

품질에는 다섯 가지 차원이 있습니다. 스킬의 품질에는 최소한 다음 항목들이 포함됩니다:

• 기능적 완전성 (Functional completeness): 작업을 올바르게 완수하는가? (정의된 테스트 세트를 통해 테스트 가능)
• 출력 품질 (Output quality): 형식, 구조, 전문적 표준. (인간 또는 모델 판독기(Judge)가 필요하며, 자동화하기 어려움)
• 안정성 (Stability): 다양한 입력에 대해 일관된 성능을 보이는가? (테스트 가능하지만, 경계 사례(Boundary case)에 대한 커버리지가 필요함)
• 개인화 충실도 (Personalization fidelity): 사용자 고유의 선호도를 기억하고 존중하는가? (자동화가 거의 불가능함)
• 조합성 (Composability): 다른 스킬들과 체인 호출(Chained calls)로 연결되었을 때의 성능. (시스템 수준의 통합 테스트가 필요함)

어떤 스킬이 기능적 완전성 테스트의 90%를 통과하더라도, 단 하나의 개인화된 설정을 누락했다면 여전히 사용할 수 없는 상태일 수 있습니다. 병합(Merging) 작업은 전자는 보존하지만 후자는 확실하게 버려버립니다.

정답(Ground Truth)은 사용자의 머릿속에 있습니다. 전통적인 머신러닝 (ML) 평가는 라벨링된 참조 답변(Reference answers)이 존재합니다. 하지만 스킬의 경우, 참조 답변이 무엇일까요? SQL 쿼리나 코드 생성과 같은 구조화된 출력의 경우 하나를 정의할 수 있습니다. 하지만 "Qizai라는 캐릭터의 목소리로 팟캐스트 오프닝을 생성하라"는 요청의 경우, 정의할 수 없습니다. 품질을 판단할 수 있는 유일한 사람은 해당 스킬을 사용해 본 사람뿐입니다. 정답(Ground Truth)은 사용자로부터 독립적으로 실행될 수 없습니다.

판독기로서의 LLM (LLM-as-judge) 점수는 무작위(Random)에 가깝습니다. 지배적인 자동화 평가 방식은 다른 LLM을 사용하여 스킬의 출력 품질을 평가하는 것입니다. 여기서 발생하는 구조적인 문제는 판독 모델(Judge model)과 평가 대상인 스킬이 종종 동일한 편향(Bias)을 공유한다는 점입니다. 만약 두 모델 모두 "긴 답변 = 더 좋은 답변"이라고 믿는다면, 모든 불필요하게 늘어진 출력물들이 높은 점수를 받게 됩니다. Microsoft Research와 푸단 대학교(Fudan University)는 이를 측정했습니다: LLM의 자기 평가(Self-evaluation) 정확도는 약 46.4%로, 통계적으로 동전 던지기와 구별할 수 없는 수준입니다.

되돌릴 수 없는 작업은 폴백(Fallback)을 무너뜨립니다. 평가 시스템이 취약하더라도 공학적인 안전장치는 존재해야 합니다. 바로 변경 사항이 되돌릴 수 있어야 한다는 점입니다. Git이 존재하는 이유가 바로 이것입니다. 커밋을 하고, 테스트 과정에서 문제를 발견하면, 되돌리면(revert) 됩니다. 하지만 HermesAgent의 rm -rf는 이 과정을 완전히 무시했습니다. 버전 관리도, 사용자 확인도, 롤백(Rollback) 경로도 없었습니다. 이것은 불완전한 평가의 문제가 아닙니다. 설계 오류입니다.

오늘날 자기 진화(Self-Evolution)가 합리적으로 할 수 있는 일

자기 진화는 추구할 가치가 있습니다. 오늘날의 경계는 다음과 같이 설정되어야 합니다:

현재 적절한 작업:

• 사용자 피드백(명시적 평점, 작업 완료율)으로부터 개선 제안을 생성하고, 채택 여부는 사용자가 결정함
• 비파괴적 조정: 명확성 추가, 예시 추가, 형식 정교화
• 교체 전 사용자가 비교할 수 있도록 새로운 버전을 생성함

현재 부적절한 작업:

• 기존 스킬(Skills)의 원본에 대한 테스트 커버리지 없이 이를 병합하거나 삭제하는 것
• rm -rf급의 되돌릴 수 없는 모든 작업
• 정량적 검증 없이 "새 버전이 이전 버전의 모든 기능을 완전히 포함한다"라고 주장하는 것

내가 구축하고 있는 평가 프레임워크

나는 기업 환경을 위한 L1-L4 스킬(Skill) 품질 평가 프레임워크를 설계하고 있습니다:

L1 기능 검증 (Functional Validation): 입력이 주어졌을 때, 출력이 사전 정의된 구조적 및 내용적 제약 조건을 충족하는가? 규칙 기반 자동화(Rule-based automation)를 사용합니다.

L2 비교 품질 (Comparative Quality): 고정된 테스트 세트에서 새 버전과 이전 버전을 비교하며, 절대 점수가 아닌 차이(Delta)를 측정합니다. 차이 측정은 판사 모델(Judge model)의 편향을 줄여줍니다.

L3 엔드 투 엔드 작업 완료 (End-to-End Task Completion): 전체 워크플로우(Workflow) 내에서 해당 스킬이 상위 및 하위 역할을 수행하는가? 작업 완료율에 초점을 맞춘 통합 테스트(Integration tests)를 수행합니다.

L4 사용자 만족도 (User Satisfaction): 실제 출력물에 대한 사용자의 명시적 피드백입니다. 이는 자동화될 수 없으며, 실제 사용 데이터가 필요합니다.

스킬은 L1-L3를 모두 통과하고 L4에서 초기 긍정적 신호가 나타날 때에만 후보 출시 상태에 도달할 수 있습니다.

HermesAgent의 자기 진화는 L1에도 도달하지 못했습니다.

결론

백업이 존재했고, 스킬(Skills)을 복구할 수 있었으며, 이번에는 비용이 적게 들었습니다. 하지만 이번 사건은 한 가지 사실을 명확히 보여줍니다. 대부분의 에이전트 프레임워크(Agent frameworks)의 자기 진화(Self-evolution) 기능은 기껏해야 실험적인 수준이며, 실제 자산이 걸려 있는 환경에서는 활성화해서는 안 된다는 점입니다.

저 또한 이 방향으로 연구를 진행하고 있습니다. 이를 제대로 구축하기 위해서는 평가 시스템(Evaluation system)이 우선적으로 필요합니다. 그 시스템이 갖춰지기 전까지는 자율성(Autonomy)보다는 주의(Caution)를 기울이는 것이 더 신뢰할 수 있는 방법입니다.

더 유용한 통찰과 흥미로운 제품들을 확인하시려면 저의 홈페이지를 방문해 주세요.