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

핵심 요약
- 자가진화 에이전트가 축적한 스킬이 무한정 늘어나는 문제를 해결하는 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
저장소는 파싱·최적화·렌더링·평가를 분리해, "평가 없이 압축한다"는 주장을 파일 접근과 로그로 검증할 수 있게 설계했습니다.
두 가지 모드
- One-shot: 한 번의 구조적 추출 호출 + 결정적 최적화로 압축
- 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회 (비용 효율)
- ✅ 스킬은 쌓기만 하면 부채 — 압축이 필수