2-Tier Context Skill은 토큰을 줄일까? 로딩 구조와 보존율 검증

2-Tier 구조는 모든 지침을 상시 넣지 않아 토큰을 줄일 수 있지만, 필요한 스킬을 제때 고르고 요약에서 핵심 조건을 보존할 때만 효과가 있습니다. Agent-Skills-for-Context-Engineering은 이 점진적 로딩 방식을 시험할 수 있는 참고 스킬 모음입니다. 도입 전에는 초기 토큰 절감만 계산하지 말고 잘못된 스킬 선택과 복구 대화까지 포함한 전체 작업 비용을 비교해야 합니다.

2-Tier 구조가 줄이는 것은 무엇인가

원문은 처음에는 스킬의 이름과 짧은 설명만 제공하고, 요청에 맞는 스킬이 선택된 뒤 전체 Markdown 지침을 읽는 점진적 공개 구조를 설명합니다. 모든 방법론을 시스템 프롬프트에 넣을 때보다 초기 문맥을 작게 유지하려는 방식입니다.

이 구조가 자동으로 lost-in-the-middle 문제를 해결하는 것은 아닙니다. 설명이 모호하면 잘못된 스킬을 고를 수 있고, 필요한 정보를 지침과 함께 불러오지 못하면 결과는 여전히 틀립니다. 초기 토큰 수뿐 아니라 선택 정확도와 로딩 뒤의 총 토큰도 측정해야 합니다.

라우팅이 맞았는지는 어떻게 측정할까

먼저 반복되는 실제 요청을 모아 각 요청에 필요한 스킬과 필요하지 않은 스킬을 사람이 표시합니다. 이후 이름과 짧은 설명만 본 라우터가 어떤 스킬을 골랐는지 비교합니다. 필요한 스킬을 놓치는 경우와 불필요한 스킬을 부르는 경우를 따로 세야 합니다. 전자는 작업 실패나 재질문으로 이어지고, 후자는 줄이려던 문맥을 다시 키웁니다.

겉보기 단어만으로 선택되는지도 시험합니다. 예를 들어 “메모리”가 대화 기억을 뜻할 때와 GPU 메모리를 뜻할 때 같은 스킬이 호출된다면 설명이 지나치게 넓은 것입니다. 반대로 표현이 조금 달라졌다고 필요한 스킬을 놓친다면 설명에 실제 사용자가 쓰는 문제 표현이 부족합니다. 스킬 본문을 바꾸기 전에 이 짧은 설명의 경계를 다듬는 것이 2-Tier 구조의 첫 개선점입니다.

라우팅 결과는 정답 여부만 기록하지 말고 수정 비용을 남깁니다. 잘못 고른 뒤 몇 번의 대화와 도구 호출을 거쳐 회복했는지, 사람이 개입해야 했는지 기록하면 작은 오선택이 전체 비용에 미치는 영향을 볼 수 있습니다.

어떤 스킬부터 읽을까

context-fundamentals는 시스템 지침, 도구 정의, 검색 문서, 대화 기록, 도구 출력처럼 문맥을 구성하는 요소를 분해합니다. context-degradation은 긴 대화의 중간 유실과 오염을 진단하고, context-compression은 오래된 세션을 요약하는 전략을 다룹니다. memory-systems는 벡터 검색과 시간 정보가 있는 지식 구조를 설계하는 관점을 제공합니다.

multiagent-patterns와 evaluation 같은 추가 주제도 원문에 소개되지만, 모두 설치한다고 에이전트가 스스로 올바른 순간에 발동하는 것은 아닙니다. 현재 문제가 검색 누락인지, 불필요한 도구 출력인지, 잘못된 요약인지 먼저 분류한 뒤 하나씩 적용해야 합니다.

서로 비슷한 스킬을 한꺼번에 넣으면 선택 경계가 흐려집니다. 압축과 메모리처럼 함께 쓰일 수 있는 주제라도 어느 단계에서 무엇을 책임지는지 설명해야 합니다. 하나는 오래된 문맥을 줄이고 다른 하나는 세션 밖에 정보를 저장한다는 식으로 입출력과 종료 조건이 구분돼야 합니다. 같은 지시를 서로 다른 말로 반복하는 스킬은 로딩 비용뿐 아니라 우선순위 충돌도 만듭니다.

처음에는 자주 반복되고 실패 비용이 분명한 한두 문제만 골라 적용하는 편이 좋습니다. 짧은 질문이나 한 파일 수정처럼 원래 문맥이 작은 작업은 스킬 선택과 지침 읽기가 본 작업보다 길어질 수 있습니다. 스킬 수가 많다는 사실 자체를 성숙도로 보지 말고, 실제 요청에서 재사용되는지 확인해야 합니다.

효과는 요약 전후의 보존율로 확인한다

컨텍스트 압축을 시험한다면 원본 대화에서 절대 잃으면 안 되는 결정, 미해결 질문, 파일 경로, 수치를 골라 정답표를 만듭니다. 스킬 적용 뒤 이 항목이 보존됐는지, 이미 폐기한 정보가 다시 살아나지 않았는지 확인합니다. 단순 스크립트처럼 문맥이 짧은 작업에서는 추가 라우팅이 오히려 비용일 수 있습니다.

보존율 정답표는 모호한 “내용 대부분”이 아니라 검증 가능한 항목으로 만듭니다. 예를 들면 사용자가 승인한 결정, 금지한 행동, 변경할 파일, 유지할 URL, 아직 답하지 못한 질문입니다. 요약 후 각 항목이 그대로 남았으면 보존, 의미가 바뀌었으면 손실로 표시합니다. 이미 취소한 요구가 다시 나타나는 것도 오류이므로 단순 누락과 별도로 셉니다.

숫자만 남고 맥락이 사라지는 문제도 주의해야 합니다. “최소 3,200자”라는 값이 남아도 무엇의 길이인지 빠지면 실행 지침으로 쓸 수 없습니다. 파일 경로 역시 이름만 보존하고 대상 저장소를 잃으면 잘못된 위치를 수정할 수 있습니다. 중요한 항목은 값, 대상, 조건을 한 묶음으로 검사합니다.

압축 전후를 같은 최종 과제로 평가합니다. 원문 문맥을 그대로 준 실행과 스킬로 압축한 실행이 같은 결정과 산출물을 내는지 비교하고, 입력 토큰, 추가 검색, 재질문, 수정 횟수를 모두 합산합니다. 처음 프롬프트가 짧아졌어도 누락을 복구하느라 원문을 다시 읽었다면 순절감은 작거나 음수가 될 수 있습니다.

토큰 비용은 어디까지 합산해야 하나

초기 메타데이터, 선택된 스킬 본문, 스킬이 요구한 참고 자료, 도구 출력, 실패 후 복구 대화까지 한 작업의 비용입니다. 최초 입력 토큰만 비교하면 점진 로딩이 언제나 유리해 보일 수 있습니다. 반대로 한 번 읽은 지침을 같은 세션의 여러 작업에서 재사용할 수 있다면 작업당 비용은 낮아질 수 있으므로 단발 작업과 연속 작업을 나눠 측정합니다.

품질과 비용은 함께 표로 둡니다. 토큰이 줄어도 필수 결정을 잃거나 위험한 명령을 실행하면 성공이라고 할 수 없습니다. 동일 품질에서 더 적은 비용인지, 동일 비용에서 더 높은 성공률인지 기준을 먼저 선택해야 합니다. 어느 쪽도 개선되지 않는다면 2-Tier 구조를 유지할 이유가 약합니다.

원문의 사용 예시는 특정 편집기에 파일을 복사해 호출하는 개념적 절차이며 현재 Claude Code나 Cursor의 공통 설치법으로 보증되지 않습니다. 모델 크기만으로 스킬 선택 성공을 단정할 근거도 이 글에는 없습니다.

저장소는 지침 코드처럼 검토한다

스킬은 모델 행동을 바꾸는 실행 지침이므로 일반 문서보다 엄격하게 봐야 합니다. 외부 전송, 파일 수정, 명령 실행을 요구하는 부분이 있는지 읽고 제한된 프로젝트에서 시험합니다. 결과가 좋아도 핵심 결정을 사람이 원문과 대조할 수 있어야 합니다.

스킬 업데이트와 충돌은 어떻게 관리할까

지침 파일도 코드처럼 버전을 고정하고 변경 내역을 검토해야 합니다. 짧은 설명이 바뀌면 라우팅 대상이 달라지고, 본문 한 문장이 추가되면 파일 수정이나 외부 통신 범위가 넓어질 수 있습니다. 업데이트 전후에 같은 요청 세트를 실행해 선택률과 결과 차이를 비교하고, 문제가 생기면 이전 버전으로 되돌릴 수 있어야 합니다.

두 스킬이 상반된 순서나 도구를 요구할 때 어느 지침이 우선하는지도 정합니다. 자동으로 합치면 둘 다 일부만 지키는 모호한 행동이 나올 수 있습니다. 충돌을 발견하면 더 구체적인 스킬 하나만 선택하거나, 상위 운영 규칙에서 금지 행동과 권한 한계를 명시해야 합니다.

외부 저장소의 지침은 출처만 믿고 실행하지 않습니다. 어떤 파일을 읽고 쓰는지, 셸 명령이나 네트워크 전송을 요구하는지, 비밀값을 참조하는지 확인합니다. 제한된 테스트 프로젝트와 최소 권한으로 실행한 뒤 예상 밖 변경이 없는지 diff와 로그를 검사합니다. 이는 악의적 지침뿐 아니라 오래된 설치법이나 잘못된 경로로 인한 사고도 줄입니다.

결국 2-Tier 스킬이 맞는 환경은 긴 작업이 반복되고, 문제 유형을 비교적 안정적으로 분류할 수 있으며, 지침 로딩과 결과를 관찰할 수 있는 곳입니다. 짧고 매번 다른 작업에서는 단순한 체크리스트가 더 싸고 명확할 수 있습니다. 저장소의 스킬 수보다 자신의 요청에서 정확히 선택되고 핵심 정보를 보존하는지가 도입 판단의 중심입니다.

회귀 테스트에는 스킬을 불러야 하는 요청, 불러서는 안 되는 비슷한 요청, 두 스킬이 경합하는 요청을 함께 넣습니다. 설명이나 본문을 수정할 때마다 이 세 묶음의 선택 결과와 최종 산출물을 비교하면 토큰 절감 때문에 정확도가 조용히 낮아지는 일을 찾을 수 있습니다. 테스트에 통과하지 못한 업데이트는 전체 환경에 배포하지 않고 제한된 세션에서 다시 다듬습니다.

운영 중에는 “어떤 스킬이 호출됐는가”뿐 아니라 “왜 호출됐는가”를 남길 수 있어야 합니다. 잘못된 선택이 모델 문제인지 짧은 설명의 문제인지 구분해야 다음 수정이 가능합니다. 관찰할 수 없는 점진 로딩은 문맥을 줄여도 실패 원인을 더 찾기 어렵게 만들 수 있습니다.

구성과 예시는 GitHub 저장소에서, 원문이 인용한 소개 맥락은 관련 글에서 확인할 수 있습니다. 이 글은 외부 상태를 확인하지 않았으므로 스타 수나 현재 지원 제품을 평가 근거로 사용하지 않습니다.

함께 읽으면 이해가 이어지는 글

• everything-claude-code를 팀에 도입할까: 역할 분리, 스킬, 훅의 비용 — everything-claude-code의 역할별 에이전트, 필요할 때 불러오는 스킬, 훅 기반 기록 구조를 살펴보고 컨텍스트, 권한, 비용, 팀 설정의 도입 기준을 정리합니다.
• Claude-HUD는 무엇을 보여 주나? Statusline, Transcript 구조와 도입 기준 — Claude Code의 공식 statusline 입력과 transcript를 이용해 컨텍스트, 도구, 에이전트 상태를 표시하는 Claude-HUD의 구조, 보안 경계와 성능, 운영 검증법을 설명합니다.
• 유출 코드 기반 AI 에이전트를 써도 될까? Claw Code의 출처, 법적 리스크 — Claude Code 유출, 클린룸 재작성 주장이 얽힌 Claw Code에서 검증된 사실과 서사를 구분하고, 유용한 설계 패턴만 안전하게 읽는 기준을 제시합니다.