스킬을 압축해야 하는 이유 — SkillZip의 구조적 압축 실측 31.2%

자가진화 에이전트의 스킬 비대화 문제를 해결하는 SkillZip. 평가 없이 구조적으로 압축해 압축률 31.2%, 성능은 오히려 상승, 3.5배 빠르고 rollout 0회. 자가진화 시리즈 후속작.

스킬을 압축해야 하는 이유 — SkillZip의 구조적 압축 실측 31.2% 대표 이미지

핵심 요약

  • 자가진화 에이전트가 축적한 스킬이 무한정 늘어나는 문제를 해결하는 arXiv 논문 (2608.11079, 2026-08-11)
  • SkillZip: 평가 없이(evaluation-free) 스킬을 압축하는 방법 — "한 번 설명하고 여러 번 참조" 원리
  • 실측: 압축률 27.1%–36.9% (평균 31.2%), 성능은 오히려 소폭 상승 (매크로 평균 0.577)
  • 압축 시간 286초 (3.5배 속도 향상), 평가 기반 방식(SkillReducer) 대비 40–80회 rollout 불필요
  • 기존 스킬 시리즈(SkillProx → Ouroboros → LinkedIn)의 "스킬이 비대해지는 문제" 를 정확히 짚음

서론: 스킬이 끝없이 자란다

지난 글 "자가진화의 두 방식"에서 봤듯이, 자가진화 에이전트는 성공한 절차와 실패 수정을 계속 스킬로 축적합니다.

그런데 이 축적이 문제를 만듭니다:

"the same requirement is often restated in several branches, examples, and warnings, while common action sequences are copied rather than reused"

즉:

  • 같은 요구사항이 여러 분기·예시·경고에 중복
  • 공통 액션 시퀀스가 재사용되지 않고 복사됨
  • 결과적으로 스킬이 비대해져 주입 비용이 커지고 유지보수가 어려워짐

이건 우리가 실제로 경험한 문제입니다. SkillProx에서 스킬 압축(25.6k→12.6k 토큰)이 중요했던 이유이기도 하죠.

왜 기존 압축이 부적합한가

일반적인 프롬프트 압축은 스킬을 평평한 텍스트(flat passage) 로 봅니다. 그런데 스킬은 구조를 가집니다:

스킬 구성 요소 역할
이름·설명 언제 적용되는지 정의
워크플로우 실행 순서 제어
도구·출력 계약 유효성 제약
희귀 예외 샘플 태스크가 안 걸려도 핵심일 수 있음

평범한 텍스트 압축은 이런 구조적 제약을 파괴할 수 있습니다. 희귀 예외는 샘플에 안 나타나서 잘려나갈 수 있는데, 그게 정작 중요한 규칙일 수 있죠.

평가 기반 압축(evaluation-guided)은 이걸 검증하지만:

  • rollout(실행)이 필요 → 비용 발생
  • 압축 시점의 평가 데이터에 의존
  • 과적합 위험

SkillZip: "한 번 설명하고, 여러 번 참조"

SkillZip의 핵심 아이디어:

"Explain once, reference many" — 반복되는 규칙을 적용 범위에서 한 번만 설명하고, 반복 액션 시퀀스는 공유 프로시저로, 차이만 명시적 예외로 남긴다.

이걸 타입화된 최소 설명 길이 목적함수(typed minimum-description-length)로 공식화합니다:

스킬 = 스킬 계약(contract) + 잔여물(residual)
목적: 설명 길이 최소화
제약: 추출된 트리거·워크플로우 엣지·도구 요구·의무·출력 필드 모두 커버

핵심 특징:

  • 공유 임계값: 반복 구조를 공유 프로시저로 승격
  • 희귀 예외 보존: 고유한 규칙은 구조적으로 살아남음 (샘플 비의존)
  • 효율적 로컬 업데이트: 전체를 다시 분석 안 함

구체적 예시: 압축이 실제로 어떻게 일어나는가

논문이 제시한 구체적 압축 메커니즘입니다. 같은 규칙이 여러 곳에 반복되는 상황을 가정합니다.

① 스코프 리프팅 (Scope Lifting)

규칙 c가 자식 스코프 s₁, …, sᵣ에 반복해서 나온다면, 이를 가장 가까운 공통 조상 스코프로 끌어올립니다:

압축 전:
  ├─ branch A: "소스 파일을 덮어쓰지 마라"
  ├─ branch B: "소스 파일을 덮어쓰지 마라"
  └─ branch C: "소스 파일을 덮어쓰지 마라"

압축 후:
  공통 조상: "소스 파일을 덮어쓰지 마라"  ← 한 번만
  └─ (예외가 있으면 로컬에 명시)

단, 리프팅은 조상에서 모든 경로가 그 규칙을 요구할 때만 가능합니다. 지역적 충돌이 있으면 예외로 인코딩됩니다.

② 워크플로우 재사용 (Workflow Reuse)

같은 액션 시퀀스가 반복되면 공유 프로시저로 추출합니다:

압축 전: "검증 → 수리 → 재검증" 이 3개 분기에 각각 복사됨

압축 후: shared_procedure("검증-수리-재검증")  ← 한 번만 정의
  └─ 분기마다 "shared_procedure 호출 + 차이점만"

③ 공유 선택 조건 (수식으로 명확히)

두 조항 x₁과 x₂가 공통 타입 단위 z로 표현될 수 있을 때, 설명 길이가 줄어들 때만 공유합니다:

L(z) + L(x₁|z) + L(x₂|z) < L(x₁) + L(x₂)
  • 진짜 의역(paraphrase)이면 잔여물(residual)이 거의 비어 공유가 유리
  • 극성 변화·가드 차이·도구 인자 차이·출력 필드 차이는 잔여물에 인코딩 → 공유가 손해면 안 함

이게 "의미 중복 제거(semantic deduplication)와 다르다"는 논문의 주장입니다. 단순히 비슷한 문장을 합치는 게 아니라, 계약(contract) 단위로 공유 가능한지를 수식으로 판단합니다.

압축 알고리즘 (One-shot 모드)

1. 모델 쓰기 전에 SKILL.md 스캔
2. 타입화된 계약을 한 번 복구
3. 타입 호환 재사용만 제안
4. 가장 짧은 커버 설명 선택
5. 고정 템플릿으로 렌더 + 구조적 감사

논문에는 이 판단이 구체적인 알고리즘으로 구현되어 있습니다:

Algorithm 1: One-Shot SkillZip

1:  B    ← Scan(S)              # 스킬 스캔 (블록 분해)
2:  (A,R) ← ExtractContract(B)  # 타입화된 계약 추출 (A=계약, R=잔여물)
3:  H    ← ProposeReuse(A)      # 타입 호환 재사용 후보 제안
4:  K    ← MinCostCover(A,R,H)  # 최소 비용 커버 선택 ← 핵심 판단
5:  S'   ← Render(K)            # 고정 템플릿으로 렌더
6:  if v:                       # 감사 모드
7:    K̂    ← Parse(S')           # 압축본을 독립 재파싱
8:    M    ← ContractDiff(K,K̂)   # 계약 누락 diff
9:    S'   ← RestoreMissingSpans(S',M)  # 누락 복구
10: return S'

핵심은 4번 MinCostCover 입니다 — 앞서 본 공유 선택 수식(L(z)+L(x₁|z)+L(x₂|z) < L(x₁)+L(x₂))을 바탕으로 설명 길이(비용)가 최소가 되는 커버를 찾는 최적화 문제를 풉니다. 7-9번의 감사 모드가 압축 과정에서 계약이 빠지지 않도록 보장합니다.

CLI로도 구현되어 있음

# 압축
skillzip update skillzip.json PATCH.md --output SKILL.md

# 평가 없는 구조 검사
skillzip audit SKILL.compact.md skillzip.json

# 각 승인/거부된 추상화 설명
skillzip inspect skillzip.json --show-savings

저장소는 파싱·최적화·렌더링·평가를 분리해, "평가 없이 압축한다"는 주장을 파일 접근과 로그로 검증할 수 있게 설계했습니다.

두 가지 모드

  1. One-shot: 한 번의 구조적 추출 호출 + 결정적 최적화로 압축
  2. Zip-on-Write (지속형): 각 자가진화 패치를 태스크 재실행이나 전체 이력 재파싱 없이 즉시 흡수

Zip-on-Write가 중요한 이유 — 자가진화가 진행될수록 패치가 계속 생기는데, 매번 전체를 다시 압축하면 비용이 커집니다. 이 모드는 새 패치만 국소적으로 통합합니다.

실측 결과

압축 성능

메트릭 SkillZip
압축률 27.1%–36.9% (평균 31.2%)
성능(매크로 평균) 0.577 (오히려 소폭 상승)

압축했는데도 성능이 떨어지지 않고 소폭 상승 — 비대한 스킬이 오히려 노이즈를 만들었음을 시사합니다.

지속 압축 (continual)

메트릭 결과
스킬 길이 감소 1.6×–1.9× (무압축 대비 38–50% 감소)
이유 매 쓰기(write)가 즉시 흡수되어 누적 방지

비용 효율성

메트릭 SkillZip SkillReducer(기존)
압축 시간 286초 더 오래 걸림
rollout 필요 0회 40–80회
압축 모델 호출 적음 많음

SkillZip은 3.5배 빠르고, 평가용 rollout이 전혀 필요 없습니다.

이론과 실전의 연결

SkillProx Ouroboros SkillZip
문제 스킬이 오히려 성능 저하 에이전트 진화 스킬이 비대해지는 것
해결 검증 루프 + 압축 리뷰된 커밋 구조적 압축 (평가 없이)
핵심 수치 압축 29.4% 절감 Terminal-Bench 86.97% 압축 31.2%, 3.5× 빠름
스킬 압축 관점 25.6k→12.6k 토큰 — 27.1–36.9%

SkillZip은 SkillProx가 "압축이 중요하다"고 말한 것에 대해 "압축을 어떻게 해야 하는가" 를 실용적으로 답합니다. 특히 자가진화의 지속형 패치에 대응하는 Zip-on-Write가 실무적 강점입니다.

결론: 스킬은 무한정 쌓아서는 안 된다

이 논문의 핵심 교훈:

"스킬 축적은 자산이 아니라, 구조화되지 않으면 부채가 된다."

  • 자가진화 에이전트가 스킬을 계속 쌓으면 → 중복·비대화 → 주입 비용 증가 + 유지보수 어려움
  • SkillZip은 평가 없이 구조적으로 압축해, 성능은 유지하면서 크기를 1/3로 줄임
  • 특히 Zip-on-Write로 자가진화의 지속 패치를 국소적으로 흡수

우리가 만든 agent-skills 자가개선 프레임워크에도 이 원리를 적용할 수 있습니다 — SKILL.md가 커질 때마다 SkillZip처럼 구조적 압축을 하면 됩니다.

핵심 요약:

  • ✅ 자가진화 스킬의 비대화 문제 해결
  • ✅ 평가 없는 구조적 압축 (압축률 31.2%, 성능 소폭 상승)
  • ✅ Zip-on-Write로 지속 패치 국소 통합 (1.6×–1.9× 감소)
  • ✅ 3.5배 빠르고 rollout 0회 (비용 효율)
  • ✅ 스킬은 쌓기만 하면 부채 — 압축이 필수