AI 에이전트의 기능을 삭제하지 않고, 자체 개선을 통해 '처음 읽어야 할 정보'를 42% 줄였습니다

AI 에이전트를 오랫동안 키우다 보면, 할 수 있는 것이 늘어나는 한편, 규칙(rule), 작업 절차(procedure), 기억(memory), 테스트(test) 등도 함께 늘어나게 됩니다.

모든 것을 매번 읽히면 안심할 수는 있지만, 관계없는 정보까지 포함하게 되어 무거워집니다. 그렇다고 해서 큰 것부터 덜어내면, 필요한 능력까지 사라질 수도 있습니다.

이번에는 이 두 가지 선택지를 피하기 위해, '기능을 삭제하는' 것이 아니라 '처음부터 읽어야 할 정보를 줄이는' 방향으로 구조를 정리했습니다.

결과는 다음과 같습니다.

• 기능 자체의 삭제:
  0 - 자체 개선을 시작할 때의 로딩량:
  406,524 bytes (바이트) → 234,865 bytes - 감소율:
  42.2% - 처음 읽는 전문 기능(Skill):
  10개 → 7개 - 나머지 3개:
  필요할 때가 되어 추가로 읽기

여기서 말하는 **자체 개선(self-improvement)**이란, AI 에이전트가 자신의 규칙이나 작업 절차, 기억 사용 방식을 재검토하는 작업을 의미합니다.

본문에서는 감소율 자체보다도, 능력을 떨어뜨리지 않으면서 가볍게 만들기 위해 무엇을 남기고, 무엇을 나중에 읽도록 했는지를 설명합니다.

먼저, 이 글에서 사용할 용어들

전문 용어를 몰라도 이해할 수 있도록, 먼저 의미만 정리하겠습니다.

감소율을 목표로 삼지 않았습니다

처음에 정한 것은 '30% 줄이기', '절반으로 만들기'와 같은 목표가 아니었습니다.

기준은 단 하나입니다.

없어져서 곤란할 가능성이 있다면, 삭제하지 않는다.

따라서 작업은 한 번에 압축하는 것이 아니라, 작은 변경마다 회귀 테스트(regression test)를 거쳤습니다.

구체적으로는 다음과 같은 순서였습니다.

• 동일한 책임을 중복으로 설명하는 부분을 통합하기
• 과거 이력처럼 매번 필요하지 않은 정보를 필요할 때 가져오도록 변경하기
• 매번 읽을 필요가 없는 전문 기능(Skill)만, 중간에 추가로 가져올 수 있는 형태로 바꾸기
• 가벼운 인덱스(index)를 사용할 경우에도, 최종적으로 올바른 것으로 취급하는 원본 데이터(Source of Truth)로 돌아갈 경로 남겨두기
• 가볍게 할 수 있을 것 같아도, 회귀 테스트로 안전을 확인할 수 없는 부분은 건드리지 않기

여기서 말하는 원본 데이터란, 최종적으로 올바른 것으로 취급하는 정보원(Source of Truth)을 의미합니다. 가벼운 인덱스나 캐시를 입구에 사용하더라도, 판단을 확정할 때는 원본 데이터로 돌아갈 수 있도록 합니다.

즉, 최적화 대상은 '정보량' 그 자체가 아닙니다.

무조건 읽어야 하는 정보의 양입니다.

10개를 7개로 줄였다. 하지만 3개는 삭제하지 않았다

자체 개선을 시작할 때, 이전에는 큰 전문 기능(Skill)을 포함한 10개의 항목을 초기에 읽도록 구성되어 있었습니다.

이 중 3개는 매번 필수적인 것은 아니었습니다.

예를 들어,

• 외부의 최신 연구가 판단 자료가 되었을 때만 필요한 조사 기능(Skill)
• 프롬프트나 컨텍스트 구조 자체를 변경할 때만 필요한 설계 기능(Skill)
• 새로운 능력을 앞으로도 표준으로 사용할지 판단할 때만 필요한 유지보수 기능(Skill)

이었습니다.

그래서 구성을,

10개를 상시 읽기
에서,

7개는 처음에 읽고. 3개는 필요해진 순간에 추가하기

로 바꿨습니다.

저는 이 형태를, '처음 반드시 읽어야 하는 것'과 '필요한 단계가 되어 추가하는 것'을 분리하는 설계라고 합니다. 내부적으로는 '단계별 로딩(phase-gated activation)'이라고 부릅니다.

중요한 것은 단순히 지연 로딩(lazy loading)으로 만들지 않았다는 점입니다.

첫 번째 요청문에 '조사', '컨텍스트 설계'라고 쓰여 있지 않아도, 작업 도중에 외부 근거 확인이나, AI를 구동하는 시스템 자체의 변경이 중요해지면, 그 시점에서 필요한 기능을 다시 선택합니다(재선택).

이번 정제 작업 자체에서도, 처음에는 불필요했던 전문 기능(Skill)이 비교용 테스트를 설계하는 단계에서 필요하게 되어 도중에 추가로 가져와졌습니다.

이를 회귀 테스트로도 진행했습니다.

처음 읽지 않는 것과, 필요해도 읽지 않는 것은 다릅니다.

중복을 제거한다. 능력은 제거하지 않는다

경량화로 처음 봐야 할 곳은, 큰 파일이 아니라 같은 의미를 여러 곳이 가지고 있지 않은가 하는 것이었습니다.

예를 들어, 어떤 조사 기능(Skill) 안에, 동일한 '이상하게 비판이 발견되지 않은 상태'를 평가하는 메커니즘이 중복으로 존재했습니다.

한쪽에만 존재하는 요소를 정규(正規) 측으로 흡수하여, 두 가지의 책무를 하나로 되돌렸습니다.

이 변경을 통해 본문은 약 5% 작아졌습니다.

감소량만 보면 적습니다.

하지만 진정한 이득은 다음에 그 판단 기준을 바꿀 때 단 한 곳만 수정하면 되었다는 것입니다.

한편, 크더라도 고유한 역할이 많은 기능(Skill)은 남겨두었습니다.

다른 큰 기능에는 '일반 처리'와 '이미지 생성 시에만 필요한 절'이 공존하고 있어, 크기만으로 분할할 수 있을 것 같았습니다.

다만 당시 테스트에서는, 분할 후에 필요한 절을 확실하게 재획득할 수 있다는 보장이 부족했습니다.

그래서 분할하지 않았습니다.

경량화 후보를 찾아도,

나눌 수 있는지

가 아니라,

분리한 후에도 필요할 때 다시 로드할 수 있는지 확인하는 것으로 판단하고 있습니다.

여기부터는 조금 기술적입니다: 가벼운 인덱스는 '후보가 발견되었을 때'만 봐서는 안 됩니다

구조의 생각 방식만 알고 싶다면, 이 절에서 '다른 AI 에이전트에게 응용한다면'까지 건너뛰어도 결론은 파악할 수 있습니다.

이전 기사에서는, 큰 기능 목록(Skill Registry)을 매번 읽는 대신, 작은 인덱스(Reasoning Index)로 후보를 좁히는 방법을 소개했습니다.

관련:

이번에는 그 가벼운 인덱스 자체를 평가했습니다.

현재의 '어떤 기능을 사용할지 선택하는 처리'에서는,

• 원래 기능 목록: 42,605자
• 가벼운 인덱스: 11,076자

입니다.

가벼운 인덱스만으로는 약 74% 작습니다.

하지만 이것만으로는 평가로서 불충분합니다.

후보가 발견되지 않은 경우, 가벼운 인덱스를 읽은 후에 원래 기능 목록 전체로 돌아갑니다.

그러면,

11,076 + 42,605 = 53,681자를 읽게 됩니다.

즉, 후보가 발견되지 않으면 처음부터 원래 목록만 읽는 경우보다 26% 무거워집니다.

대표적인 사례에서는, 후보가 발견되었을 때의 로드 양이 원래 기능 목록 전체보다 약 71~73% 적어졌습니다.

한편, 후보가 하나도 발견되지 않으면 26% 추가 로드가 발생합니다.

이 결과로부터, 가벼운 인덱스는 '작으니까 항상 사용해야 한다'가 아니라,

• 얼마나 많은 후보가 발견되는지
• 필요한 후보를 놓치고 있지는 않은지
• 무관한 후보를 늘리고 있지는 않은지
• 발견되지 않았을 때, 원래 목록으로 돌아가는 추가 비용이 얼마나 되는지

까지 측정할 필요가 있다는 것을 알게 되었습니다.

44개 사례에서 평균 47.7% 감소. 하지만 아직 실제 사용에는 적용하지 않았다

이미 가지고 있던 선택 처리를 확인하는 테스트 44건에, 같은 키워드 일치만 보는 간이 테스트를 적용했습니다.

결과는,

• 후보가 발견됨: 33 / 44 = 75%
• 후보가 발견되지 않음: 11 / 44 = 25%
• 원래 목록으로 돌아가는 경우를 포함한 평균 로드: 22,288자
• 원래 기능 목록 전체: 42,605자

였습니다.

글자 수 기준으로 평균 47.7% 적은 계산입니다.

그럼에도 저는 가벼운 인덱스를 '이미 안정적이다'라고 취급하지 않습니다.

이유는 이 44건이 **선택 처리를 확인하기 위해 준비한 테스트 케이스(fixture)**이기 때문입니다.

실제 이용 분포가 아닙니다.

게다가, 이 평가는 키워드 일치만으로 후보가 나오는지 보는 간이 확인일 뿐, 의미를 이해해서 최종적으로 필요한 기능을 선택하는 정확성 그 자체는 아닙니다.

따라서 현재의 다음 단계는, 평소 작업에서,

• 발견된 후보가 정말 필요했는지
• 불필요한 후보를 의미 판단으로 걸러낼 수 있었는지
• 후보가 발견되지 않을 때, 안전하게 원래 목록으로 돌아갈 수 있었는지
• 최종적으로 필요한 기능(Skill)의 조합을 빠뜨리지 않았는지

를 보는 것입니다.

테스트에서 빨랐다고 해서, 실제에서도 맞다고 할 수는 없다.

여기서 구분했습니다.

기억은 더욱 신중하게, 후보 비교만으로 시도했다

같은 구조를 기억(Memory)에도 만들 수 있습니다.

실측으로는,

• 원래 기억 목록: 31,715자
• 가벼운 인덱스: 6,369자

로, 가벼운 인덱스 자체는 79.9% 작아졌습니다.

후보가 발견된 대표적인 사례에서는, 약 73~78% 적은 로드로 후보를 좁힐 수 있었습니다.

하지만 후보가 하나도 발견되지 않으면, 원래 기억 목록으로 돌아가기 때문에 약 20.1%의 추가 로드가 발생합니다.

기능보다 기억을 신중하게 다루는 이유가 있습니다.

기능을 하나 잘못 읽으면, 주로 관련 없는 정보가 섞이거나 로드량이 문제가 됩니다.

기억을 잘못하면,

• 과거의 상태를 현재의 사실로 사용한다
• 이번과 관계없는 과거의 성공 사례를 가져온다
• 현재의 명시적 지시보다 옛날의 취향을 우선한다
• 다른 사건을 '기억하고 있다'고 오인한다

이러한 문제로 이어집니다.

따라서 기억의 선택은 아직 후보만 백그라운드에서 비교하는 시험 운영(shadow) 단계입니다.

경량화된 인덱스가 제시한 후보들을 백그라운드에서 비교하지만, 실제로 어떤 기억을 사용할지 판단하는 데는 아직 사용하고 있지 않습니다.

승격 조건에는 단순히 읽어들이는 양뿐만 아니라,

• 필요한 기억을 가져왔는지
• 관련 없는 기억을 섞지 않았는지
• 오래된 기억을 현재 상태로 취급하지 않았는지
• 현재의 지시를 덮어쓰지 않았는지

와 같은 것들이 포함되어 있습니다.

부분 읽기는 아직 하지 않음

여기까지 오면, 다음에 하고 싶은 최적화가 생깁니다.

기능 설명 본문도 필요한 헤딩만 읽으면 더 가벼워지지 않을까?

기술적으로는 가능합니다.

다만, 저는 아직 비활성화 상태로 두고 있습니다.

기능 설명 본문의 후반부에,

• 금지 사항(禁止事項)
• 안전 경계(安全境界)
• 완료 조건(完了条件)
• 검증 절차(検証手順)

가 놓여 있는 경우가 있기 때문입니다.

경량화된 인덱스로 '어떤 Skill을 읽을지'를 좁히는 것과, Skill 본문의 '어디까지 읽을지'를 줄이는 것은 별개의 문제입니다.

후자의 경우, 놓쳤을 때 능력 자체가 결함이 생기기 쉽습니다.
따라서 독립적인 회귀 테스트 결과가 충분해질 때까지는 선택된 Skill 본문은 전문(全文)을 읽는다는 경계를 유지하고 있습니다.

제가 이번에 '하지 않은 것'

이번 다듬기 과정에서는 다음 후보들을 의도적으로 보류했습니다.

다른 AI 에이전트에 응용한다면, 이 6단계로 생각할 수 있습니다

지금까지의 구현은 저에게 고유하지만, 사고방식은 다른 AI 에이전트의 메커니즘으로 옮길 수 있습니다.

필요한 것은 같은 파일 구성이나 같은 기능명을 복사하는 것이 아닙니다.

'무엇을 지키고(守り)、무엇을 지연시키며(遅延させ)、실패했을 때 어디로 돌아갈지(どこへ戻るか)'를 같은 순서로 설계하는 것입니다.

최소 구성으로 하면 다음 6단계가 있습니다.

• 보호할 능력을 먼저 고정한다
  필수 능력, 안전 경계, 최종 판단으로 돌아갈 원데이터를 결정합니다. -
• 중복된 책무만 통합한다
  '크기라서 줄인다'가 아니라, 같은 판단 기준이 여러 곳에 있는 상태를 먼저 해소합니다. -
• 처음에 읽는 것과 필요할 때 읽는 것을 분리한다
  필요 시 획득(必要時取得)으로 옮기는 것은, 작업 도중에 필요하다는 것을 감지하고 다시 선택할 수 있다고 검증된 경우에만 합니다. -
• 경량화된 인덱스에는 반드시 돌아갈 길을 남긴다
  오래되거나, 고장 났거나, 모호하거나, 후보가 없을 때는 원래 목록으로 돌아갑니다. -
• 후보 있음/없음을 모두 측정한다
  줄인 양뿐만 아니라, 필요한 후보 누락, 불필요한 후보, 원래 목록으로 돌아갈 때의 추가 비용을 측정합니다. -
• 준비된 테스트뿐만 아니라 평소 작업에서도 확인한다
  테스트에서 성공했다고 해서 그것만을 이유로 실제 사용에 전환하지 않습니다.

설계를 유사 코드로 옮기면 사고방식은 이 정도입니다.

요청을 받는다
처음부터 필요한 기능을 읽는다
작업 중에 새로운 필수 조건이 나오면:
...

구현할 사람에게: 변경 기록 형식

여기서부터의 YAML 예시는 구현자를 위한 것입니다. 건너뛰어도 기사의 결론에는 영향을 주지 않습니다.

각 변경 사항을 다음 형태로 기록해 두면, 다른 AI 에이전트에서도 비교하기 쉽습니다. 영어 이름은 기계 처리가 용이하도록 남겨두었지만, 의미는 '지킬 조건(守る条件)・측정할 것(測るもの)・채택 조건(採用条件)・원래로 돌아갈 조건(元に戻す条件)'의 네 가지입니다.

change:
invariant:
- required_capability_recall >= baseline
...

이 형태라면, Claude Code 계열, Codex 계열, 자체 제작 AI 에이전트 등에서도 구체적인 파일 형식은 바꾸면서도 같은 판단 순서를 응용할 수 있습니다.

중요한 것은 '42% 줄이는 것'을 복사하는 것이 아닙니다.

능력 보존을 먼저 고정하고, 축소는 그 제약 범위 내에서 진행한다는 것을 복사하는 것입니다.

다듬기는 '줄이는 것'이 아니었다

이번에 자기 개선 시 초기 읽기 양은 42.2% 줄었습니다.

하지만 작업 중에 가장 신경 쓰였던 숫자는 42%가 아닙니다.

삭제된 기능(Skill)이 0이라는 것입니다.

AI 에이전트를 구동하는 메커니즘이 성장하면, 언젠가 '늘리는' 것보다 '정돈하는' 작업이 필요하게 됩니다.

그때는, 저는 큰 것부터 줄이는 것이 아니라,

이것이 정말 매번 필요한가
같은 책무를 이중으로 가지고 있지는 않은가
필요해진 순간에 되찾을 수 있는가
경량화 메커니즘이 고장 나도 원데이터로 돌아갈 수 있는가

를 보는 것이 더 안전하다고 느낍니다.

컨텍스트 설계의 목적은 짧게 만드는 것이 아닙니다.

그 순간에 필요한 것을 농축하고, 필요할 때 확실히 되돌려 받을 수 있도록 하는 것입니다.

이번 '연마'를 통해 제가 가장 남기고 싶었던 것은 바로 그 부분입니다.

참고 자료

• Obsidian으로 만든 Reasoning Index를 AI 에이전트의 Skill Routing에 이식했더니, 탐색 면적을 72% 줄일 수 있었다
• AI 에이전트는 '모두 읽게 하는 것'으로는 약해진다. 필요한 Skill만 로드하는 설계
• AI 에이전트는 『규칙 부족』뿐 아니라 『있는데 사용되지 않는 경우』에도 망가진다 — Activation Failure라는 문제
• AI 에이전트의 자체 개선에 '로드맵을 버릴 조건'을 넣었다
• Anthropic — AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링 (Effective context engineering for AI agents)
• Anthropic — 에이전트에게 실제 세계를 대비한 에이전트 스킬 장착하기 (Equipping agents for the real world with Agent Skills)

논의