TM06 · 기술머신 6 / 6

스킬이 늘어날 때 — 상한과 가지치기

훅프롬프트 예산온톨로지
4,056자스킬 12개·에이전트 9개를 깔고 매 턴 실리는 글자 (상한 검사 중)
▶ 기술머신 · TM06

스킬이 6개에서 12개로, 역할 에이전트가 9개로 늘며 생긴 문제 — 매 턴 실리는 설명 글자, 문서로만 있던 금지 규칙, 읽기만 하던 레퍼런스 512개 — 를 상한·훅·온톨로지로 관리하고, 새 모델은 스킬 0개에서 다시 붙이도록 설계했습니다.

스킬은 만들 때보다 늘어날 때 문제가 됩니다. 설명문은 발동과 무관하게 매 턴 실리고, 문서로 적은 금지는 급할 때 건너뛰고, 모델이 좋아지면 예전 약점을 메우려던 스킬이 소음이 됩니다. TM01에서 스킬로 옮긴 규칙들을 저장소 차원에서 운영하며 생긴 장치들입니다.

01사례

  1. TM06-1

    매 턴 실리는 글자에 상한을 건다

    문제
    스킬과 에이전트의 설명은 쓰이든 안 쓰이든 매 턴 컨텍스트에 실립니다. 스킬이 12개, 역할 에이전트가 9개로 늘었을 때 그 무게가 얼마인지 아무도 몰랐습니다.
    설계
    스킬 설명 하나 350자·합 4,200자, 에이전트 설명 하나 160자, 항상 로드되는 메모리 문서 1,500자를 상한으로 정하고 린트가 검사합니다. 본문은 발동했을 때만 읽히므로 상한은 설명에만 겁니다. 린트는 검증 스크립트의 한 단계라 상한을 넘기면 다음 응답에서 실패로 되먹여집니다.
    결과
    스킬 설명 합 2,335 / 4,200자, 에이전트 설명 773자, 메모리 948 / 1,500자 — 매 턴 4,056자.
  2. TM06-2

    금지는 훅으로, 검증은 통과하면 침묵

    문제
    '구현 AI는 테스트 케이스를 쓰지 않는다', '보호 브랜치에 직접 push하지 않는다'는 규칙 문서에만 있어, 지켜지는지는 모델이 그 문장을 기억하느냐에 달려 있었습니다.
    설계
    판단이 필요 없는 금지는 도구 호출 직전 훅으로 옮겼습니다 — 보호 브랜치 push·강제 push·git stash 차단(--force-with-lease는 허용), 개인키·클라우드 키·토큰 모양 값 쓰기 차단, 검증 AI 계약 파일이 있는 프로젝트에서 테스트 케이스 문서 쓰기 차단. Bash·쓰기마다 돌기 때문에 git이 없는 명령이면 파이썬을 띄우지 않는 빠른 길을 뒀습니다. 스킬 생성기도 판단이 필요 없는 금지 규칙이 들어오면 스킬 대신 훅을 만들라고 돌려보냅니다.
    결과
    파이프라인 불변 규칙 '테스트 케이스는 구현 AI가 쓰지 않는다'가 문서 규칙에서 기계 차단이 됐습니다. 가드 훅의 동작은 검증 스크립트가 응답마다 확인하고, 검증 스크립트는 통과하면 아무것도 출력하지 않아 토큰을 쓰지 않습니다. 매 응답 도는 만큼 속도가 곧 지연이라 검사를 묶어 1.77초 → 0.56초(같은 컴퓨터)로 줄였습니다.
  3. TM06-3

    레퍼런스 512개를 그래프로 — 관계는 한 곳에만

    문제
    상황 검색으로 조회 비용은 1/12로 줄었지만(TM04), '이 자료 대신 저 자료' 같은 관계는 항목 본문의 링크에만 있어 개념 단위로 묶어 볼 수 없었습니다. 관계를 별도 파일에 다시 적으면 본문과 어긋납니다.
    설계
    2단계 개념 어휘 139개와 관계 5종(다룬다·대신 본다·반대한다·대체한다·상위 개념)을 정의 파일 하나에 두고, 512개 항목에는 개념만 붙였습니다. '대신 본다'는 본문의 '이럴 땐 아니다' 링크를 그대로 읽어 두 곳에 적지 않습니다. 검색에 개념 필터(하위 개념 포함)를 넣고, 대체된 항목은 기본 검색에서 뺐습니다.
    결과
    512개 전부 배정 — 개념 태그 632건, '대신 본다' 2,668건, 반대 4쌍, 관계 총 3,304개. 무결성 검사가 검증 스크립트에 들어가 응답마다 돌고, 검색 품질 회귀 11/11을 유지했습니다.
  4. TM06-4

    새 모델은 스킬 0개에서 시작한다

    문제
    모델이 좋아지면 예전 모델의 약점을 메우려 만든 스킬이 소음이 됩니다. 쌓기만 하는 저장소는 어떤 스킬이 아직 필요한지 답할 수 없었습니다.
    설계
    새 모델은 스킬 0개 프로필에서 시작합니다. 스킬마다 '발동해야 할 요청 2개 + 발동하면 안 될 요청 1개' 평가 케이스를 두고, 빈 설정 디렉터리에서 '스킬 없음'과 '그 스킬 하나만'을 비교해 나아지면서 오발동이 0이면 유지, 아니면 빼기 후보로 둡니다. 반대 방향으로는 스킬이 안 뜬 반복 요청(세션 2개 이상·3회 이상)을 세션 기록에서 찾아 새 스킬 뼈대를 만듭니다. 사용 순위·후보·온톨로지·프롬프트 무게는 서버 없는 HTML 한 장으로 보고, 사용 기록은 저장소에 올리지 않습니다.
    결과
    10개 스킬에 평가 케이스 36개. 실행 결과는 아직 없습니다 — 호출마다 비용이 들어 자동으로 돌리지 않고, 새 모델이 나왔을 때 사람이 돌립니다. 만들기와 평가는 자동이지만 프로필 반영은 사람이 합니다.

02남은 규칙

  1. 01매 턴 실리는 글자에는 상한을 두고 기계가 검사한다.
  2. 02판단이 필요 없는 금지 규칙은 스킬이 아니라 훅으로 만든다.
  3. 03매 응답 도는 검증은 통과하면 침묵한다. 그래서 속도가 곧 지연이다.
  4. 04관계는 한 곳에만 적는다. 본문에 있는 링크를 다시 적지 않고 읽는다.
  5. 05새 모델은 스킬 0개에서 시작해, 붙였을 때 나아지는 것만 남긴다.
  6. 06만들기와 평가는 자동, 켜기와 빼기는 사람이 한다.
◀ 기술머신으로B
START
SELECT