10일 동안, 스킬이 거짓말을 하고 있었다

자신의 리포지토리에서, AI 에이전트용 절차서(SKILL.md)가 실제 운용과 10일 동안 어긋나 있었다는 사실을 깨달았다.

어긋나 있었던 부분은 Reddit의 데이터 취득 절차였으며, SKILL.md에는 약 60줄에 걸쳐 "결정판 절차"가 적혀 있었다. 이모지가 포함된 경고도 있고 코드 예시도 있다. 공을 들인 섹션이다.

하지만 실제 운용에서는 10일 내내 다른 경로를 사용하고 있었다. 게다가 그 10일 동안, 수집은 단 한 번도 실패하지 않았다. 에러율 제로로 계속 돌아가고 있었다.

왜 망가지지 않았을까. 그리고 왜 알아차리지 못했을까.

이 기사는 AI 에이전트의 "퍼스널(Personal)"을 어디에 둘 것인가라는 설계 이야기와, 그 설계를 실제로 10일간 운용하며 발견한 문제의 기록이다.

출발점: "퍼스널은 모델이 아니다"

Nous Research의 공동 창업자인 karan4d가 Peter Yang의 인터뷰에서 이렇게 말했다.

퍼스널 에이전트의 "퍼스널"은 모델이 아니다. 그것은 에이전트가 가진 당신과의 대화 기억과, 당신이 함께 만들어온 스킬이다. Karan은 자신의 Hermes가 이미 자신에 대해 방대한 문맥(Context)을 가지고 있기 때문에,

모델을 교체해도 거의 눈치채지 못한다.

같은 스레드의 답글에는 이 말을 보강하는 내용이 있었다.

모델은 매달 똑똑해지더라도,

어제 당신에게 무엇이 중요했는지를 잊는다면 기묘하게 일반적(generic)으로 느껴질 것이다. 기억이야말로 개인적인 유용성의 출발점이다.

주장으로서는 납득할 수 있다. 문제는 운용으로 옮겼을 때로, "기억과 스킬을 어디에 둘 것인가"를 결정하지 않으면 아무것도 시작되지 않는다.

"퍼스널"은 수명이 다른 3개의 층으로 나뉜다

karan4d는 "기억과 스킬"이라고 두 가지로 말했지만, 운용에서는 세 가지로 나누는 것이 다루기 쉽다. 나누는 기준은 수명이다.

수명이 다른 것들을 같은 파일에 두면 부패한다. 시라이 아키히코(白井暁彦) 씨의 "CLAUDE.md와 AGENTS.md를 덜어냈더니, AI 코딩이 훨씬 똑똑해졌다"가 이 문제를 정면으로 다루고 있다.

주장은 "정보량이 아니라 정보 배치". 덜어낸 것은 작업 진행 상황, 다음 태스크, 설정의 완료/미완료 상태, 날짜가 포함된 인수인계 사항이다. 이유는 며칠 만에 진부해지고, 완료된 체크박스가 남아 품질을 저하시키기 때문이다.

남겨둔 것은 "암초와 출입 금지 구역"에 해당하는 것들이다. 과거에 사고를 일으킨 함정, 운용상의 금지 사항, 시스템의 책임 경계, 그리고 의도적으로 채택하지 않은 설계("모노레포화 하지 않음", "결제 API를 직접 호출하지 않음").

이동할 곳도 명확하여, 진행 상황은 GitHub Issue로, 일일 작업은 에이전트 메모리로, 방대한 사양서는 별도 파일로 보낸다.

시라이 씨가 한 것은 삭제가 아니라 층의 분리였다.

쌓인 것을 어떻게 처리할 것인가——3가지 유파

"퍼스널"은 쌓아 올리는 과정으로 만들어지지만, 쌓인 것은 부패한다. 여기에 판단 기준이 다른 세 가지 방법이 나와 있다.

사용 실적으로 쳐내기 (Hermes Curator)

Hermes Curator는 스킬의 사용 상황을 추적하여, 사용되지 않는 스킬을 stale(진부함)로 마크하고, 장기간 미사용인 것을 복구 가능한 아카이브로 옮긴다.

오픈 소스이므로, 자신의 "slop(불필요한 데이터)" 정의를 전달하면 Curator가 자신의 클린업 루프를 다시 작성한다.

X의 답글에서 이 기능을 추천하던 사람의 표현이 정확했다.

지루한 Hermes의 상세 내용이야말로 중요하다. 진부해진 스킬이 영구적인 구전 설화가 되지 않도록 쳐내진다.

그것이 없다면 퍼스널 에이전트는 기억이라는 이름표가 붙은 오래된 채팅의 더미에 불과할 것이다.

시간의 경과에 따라 나누기 (시라이 아키히코)

앞서 언급한 결정 트리. 삭제 = 시간의 흐름에 따라 변하는 정보·코드에서 추측 가능한 설명·특정 프로젝트만의 정보. 유지 = 금지 사항·파손 리스크·책임 경계·미채택 설계.

반복 횟수로 승격시키기 (/ce-compound)

반복 횟수로 승격시킨다 (Every의 Kieran Klaassen이 사용하는 명령어).

여러 기능에 공통적으로 적용할 수 있는 변경 사항이 3~4건 정도 쌓였을 때 실행하면, 이후에는 지시 없이도 자동으로 적용되도록 지식 베이스(Knowledge Base)에 기록한다.

이것은 쳐내는 것이 아니라 반대 방향으로, 관찰된 내용을 영구적인 규칙으로 승격시키는 것이다.

3가지는 상호 보완적

입구(승격)·정리(층 분리)·출구(쳐내기)가 갖춰져 있다.

일본어권에서는 Qiita의 「Claude Code／Codex에 중~대규모 개발을 맡기기 위한 태스크 관리」가 그 다음 단계를 다루고 있으며, 승격(promotion)의 다음 단계로 기계적 강제(mechanical enforcement)를 두고 있다.

매번 프롬프트에 같은 주의사항을 적다 보면 결국 누락되기 마련이다. (대책: AGENTS.md로 이관하고 CI/lint를 통해 자동화)

실측: 층 분리(layer separation)를 10일간 운용했다

이제 본론으로 돌아가겠다. 이 3층 구조를 사용하여 일상적인 정보 수집 워크플로우를 10일 연속으로 돌린 결과를 제시한다.

대상은 Reddit 24개 서브레딧, Hacker News, Hatena Bookmark, X, 뉴스레터 등을 수집하여 요약하는 태스크다. 매일 1회, 5개의 서브 에이전트(sub-agent)를 병렬로 실행한다.

층의 비율

기술(Skill)이 82%를 차지한다.

이는 Every가 공개한 Claudie(Mac Mini에서 24시간 가동되는 사내 AI 에이전트)의 운용 공수 내역 및 순서와 일치한다.

행 수와 공수는 서로 다른 지표이지만, 하네스(harness)가 최소이고 기술(skill)이 최대라는 순서는 동일했다. 이는 karan4d의 주장을 정량적으로 뒷받침하는 형태가 된다.

Claudie를 만든 Nityesh Agarwal은 1,100행의 Python Slack 커넥터에 대해 다음과 같이 적었다.

Slack 메시지를 구독하여 Claude Code로 라우팅하고, 응답을 스트림(stream)으로 반환하며, 포맷과 파일 업로드를 처리한다.

그뿐이다. 세션(session), 메모리(memory), 도구(tool), 기술(skill)은 Claude Code 측이 보유한다.

그리고 SKILL.md가 10일간 어긋났다

도입부의 이야기로 돌아가자.

트렌드 수집 기술의 SKILL.md에는 Reddit 취득 절차가 「결정판 절차(agent-browser)」로 적혀 있다. 하지만 실제 운용에서는 10일 연속으로 다른 경로를 사용하고 있었다.

이 사실은 메모리(memory) 측에 기록되어 있었다. 해당 행을 그대로 인용한다.

🚨

공유된 agent-browser 데몬 경로는 hot 목록 취득 시 더 이상 작동하지 않음 (07-27/07-30/07-31로 3회 연속 사망). SKILL.md의 「결정판 절차(agent-browser)」는 실태와 괴리가 있음. 독립 Playwright를 주 경로로, agent-browser를 폴백(fallback)으로 다시 작성해야 함 (미실시).

메모리가 기술의 노후화를 스스로 감지하여 기록하고 있다. 게다가 「미실시」라고 자기 신고까지 하고 있다.

같은 일이 한 건 더 있었다. 뉴스레터 취득 경로가 역전된 건이다.

기존 정식 경로인 agent-browser --headed가 Vercel 체크포인트에서 통과 불가능해졌으며, 반대로 curl(일반 UA)로 200 OK에 도달. (중략) 6회 연속으로 Vercel 체크포인트에 한 번도 걸리지 않았으므로, curl 경로를 영구적인 정식 경로로 판단해도 좋음.

적용 방법: SKILL.md의 TLDR 섹션을 다시 작성할 것 (미실시).

이 건은 7/23에 발견되었고, 그 후 10회 연속으로 성공했다. 그럼에도 SKILL.md는 수정되지 않았다.

메모리 19개 파일 중 3개 파일이 「미실시」, 「수정 대기」, 「괴리」를 자기 신고하고 있었다.

왜 망가지지 않았는가

10일 동안 수집은 단 한 번도 실패하지 않았다. Reddit은 403 에러 없이 계속 통과했다.

이유는 단순하다. 메모리가 실행 시점에 기술(skill)을 덮어쓰고 있었기 때문이다. 세션 시작 시 메모리가 로드되면서, "공유 데몬은 작동하지 않으니 독립 프로세스를 사용하라"는 정보가 기술의 기술(description)보다 우선되어 실행되었다.

• 기술 층 (Skill layer, 월 단위로 노후화): 옛날 상태 그대로
• 기억 층 (Memory layer, 일 단위로 업데이트): 올바르게 추종
• 실행: 기억이 승리하므로 정상 작동

층을 나눔으로써, 빠르게 움직이는 층이 느린 층의 어긋남을 흡수하고 있었다.

그림 우측 하단의 점선이 문제의 핵심이다. 자동으로 흡수되고 있었던 것이 아니라, 메모리를 읽은 인간이 매번 수동으로 차분을 메우고 있었다.

하지만 이것은 메커니즘이 아니었다

겉보기에는 성공적이다. 하지만 구조에는 의존성이 있다.

• 메모리가 읽히지 않으면, 오래된 절차가 실행된다
• 메모리와 스킬 중 어느 쪽이 옳은지, 실행 시점에 판단해야 한다
  실제로는 내가 매번 수동으로 메우고 있었다

세 번째가 본심인데, 서브 에이전트(Sub-agent)에게 전달하는 프롬프트에 "공유 데몬(Shared Daemon)은 사용하지 말고, 독립 프로세스를 사용하라"라고 매번 적고 있었다. 메모리를 읽은 인간이 매번 수동으로 차분을 메우고 있었다. 자동으로 해결되고 있었던 것이 아니다.

부패는 사라지지 않고 모습을 바꾼다

층을 나누면 CLAUDE.md의 비대화는 확실히 해소된다. 실제로 우리 팀의 규칙 층은 152행 안에 들어와 있다.

하지만 부패 그 자체는 사라지지 않는다. "층간의 괴리"라는 다른 형태로 나타난다.

까다로운 점은, 괴리가 있어도 작동해 버린다는 것이다. 망가지지 않기 때문에 알아차리지 못한다. 이번에는 "메모리가 자기 보고를 하고 있었기" 때문에 발견했지만, 그것은 우연의 산물이지 메커니즘은 아니었다.

층 분리에는 층간의 동기화를 감지하는 메커니즘이 필요하다.

Curator의 판단 축에는 구멍이 있다

Hermes Curator의 "사용 실적으로 쳐내기"는 방향성으로는 맞지만, 그대로 두면 위험하다. 사용 실적과 중요도는 직교(Orthogonal)하기 때문이다.

• 1년에 한 번밖에 사용하지 않지만, 그 한 번이 결정적인 스킬(장애 대응, 릴리스 절차)
• 시라이 씨가 "남겨두라"고 말했다
  비채택 설계(「모노레포화 하지 않음」)는, 한 번도 "사용되지 않는 것"이 가장 중요하다

"사용되지 않음"이 "불필요"를 의미하지는 않는다.

이 점에서 대조되는 것이 Dress Code 사의 ADR(Any Decision Record) 실천이다. ADR의 A를 Architecture가 아니라 Any로 읽어 바꾸어, 영역이나 규모를 불문하고 모든 의사결정을 남긴다. 약 1년 반 동안 450개 이상, 최근 3개월은 월 50~60개 페이스다.

결정적인 것은, 채택 상황 속성으로 "하지 않기로 결정한 이유"도 남기고 있다는 점이다.

Curator는 "사용되지 않음"을 본다. ADR은 "왜 그렇게 결정했는가"를 본다. 서로 다른 축이다.

우리 팀에서 일어난 일도 이 분류로 설명할 수 있다. SKILL.md의 60행에 달하는 Reddit 절차는 "사용되지 않는 것"이 아니라 "틀린 것"이다. 사용 실적 기반의 쳐내기로는 검출할 수 없다.

"모델을 교체해도 알아차리지 못한다"는 어디까지 진실인가

karan4d의 주장에는 암묵적인 전제가 있는 듯하다. X(구 트위터)의 답글에서 이 점을 찌르는 질문이 있었다.

"교체해도 거의 알아차리지 못한다"는

같은 능력 티어(Tier) 내의 이야기인가, 아니면 모델 클래스를 넘나드는 이야기인가. 기억은 이식할 수 있어도, 그것을 잘 활용하는 능력은 하위 클래스로 가면 무너진다.

이를 뒷받침하는 관측이 두 가지 있다.

전 OpenAI의 Lilian Weng이 정리한 하네스 엔지니어링(Harness Engineering) 서베이에 반직관적인 결과가 실려 있다.

Qwen3.5-9B부터 Claude Opus 4.6까지 "하네스를 작성하는 능력"은 거의 평행선(9B로도 Opus와 절차적으로 동일한 형태의 skill을 작성할 수 있음)을 그리지만, 그것을 "활용하는" 능력은 중간 규모 모델이 가장 큰 혜택을 받는 비단조적(Non-monotonic)인 형태가 된다.

같은 서베이가 자기 개선 기법인 STOP에 대해 이렇게 적고 있다.

GPT-4에서는 개선되었지만

GPT-3.5나 Mixtral에서는 열화되었다——재귀 구조만으로는 불충분하며, 베이스 모델이 기구를 개선할 수 있을 정도로 똑똑해야 성립한다.

즉 "퍼스널은 모델이 아니다"는 능력 티어를 넘지 않는 범위 내에서 진실이다. 티어를 낮추면 기억은 남지만, 그것을 사용하는 능력이 떨어진다. karan4d의 주장은 "Hermes를 GLM에서 Qwen으로 바꿔도 알아차리지 못한다"는 것이지, "7B로 바꿔도 알아차리지 못한다"가 아니다.

뒤집어 보면, 락인(Lock-in)의 설계도가 된다

"퍼스널은 모델이 아니다"가 진실이라면, 모델은 커모디티(Commodity)다.

2026년 8월 시점에서 실제로 그렇게 되어가고 있다.

• DeepSeek V4-Flash의 실행 비용은 Claude Fable 5의 105분의 1 (Artificial Analysis의 평균 테스트 비용 비교) - Code Arena WebDev의 톱 10에 중국산 모델이 4개 포진
• Ling-3.0-flash가 MIT 라이선스로 공개

그렇다면 전환 비용은 "기억과 스킬의 이식성"만으로 환원된다.

Lilian Weng의 서베이(Survey) 댓글란에서 이 점이 지목되었다. "하네스(Harness)야말로 프론티어 랩(Frontier Lab)이 가치를 가두는 해자(Moat)가 아닌가?"라는 질문에 대해, 가두는 경로가 두 가지 제시되었다.

• 모델을 자사 하네스에 적합시키기
  암호화된 추론 토큰이나 비공개 에이전트 프롬프트로 사용자를 묶어두기 (Lock-in)

두 번째에 붙은 이름이 인상적이었다.

The session you cannot take with you (가져갈 수 없는 세션)

자작 하네스파의 반론도 같은 스레드에 있다.

랩(Lab)이 Claude Code나 Codex의 시스템 프롬프트(System Prompt)를 업데이트할 때마다 발밑의 모래가 움직인다. 직접 만들면 제어권을 되찾을 수 있다.

"퍼스널은 모델이 아니다"라는 말은 해방의 선언처럼 들리지만, 어디에 "퍼스널"을 두느냐가 곧 전환 가능성을 결정한다는 의미에서 락인(Lock-in)의 설계도이기도 하다. 파일에 둔 것은 가져갈 수 있다. 벤더의 메모리 기능에 둔 것은 가져갈 수 없다.

전말: 실제로 다시 작성함

이 글을 쓰는 날, SKILL.md를 실태에 맞게 다시 작성했다. 차분(Diff)은 +117 / -65 행이다.

구성을 바꾼 것이 핵심이며, "결정판 절차(agent-browser)"라는 단일 절차서를 3개의 블록으로 재구성했다.

• 사용해서는 안 되는 2가지 경로 (curl / 공유 데몬)
• 주 경로 (독립 Playwright, 고정 userDataDir, 13초 순차 실행)
• 블록 판정의 분리 (표 형식)

그리고 날짜가 포함된 경위는 지우지 않고 인용 블록으로 격리했다.

왜 이 두 가지가 막혔는지 (판단의 근거로서 유지)

curl은 2026-06 이후 IP 단위 WAF로 인해 전멸했다. 공유 데몬은 07-27 / 07-30 / 07-31로 3회 연속 사망했으며, 이후로는 사용하지 않는다. "IP 단위 WAF"라고 보고된 사례에서도 독립 프로세스라면 동일 IP에서 통과할 수 있다. 막히고 있는 것은 IP가 아니라, 공유 데몬의 브라우저 프로세스에 묶인 지문(Fingerprint)이다.

시라이(Shirai) 씨의 분류에 따르면 날짜가 포함된 경위는 삭제 대상이 된다. 하지만 단순히 지워버리면 "왜 curl을 사용해서는 안 되는가"라는 정보가 사라져, 다음에 누군가가 똑같은 경로를 시도하게 된다. 절차(실행하는 것)와 근거(읽는 것)를 시각적으로 분리함으로써 양립시켰다.

결과적으로 행수는 52행 늘어났다. "사용해서는 안 되는 경로"를 명시적으로 적었기 때문이며, 낡은 절차를 지우기만 한다면 줄어들겠지만, "왜 사용해서는 안 되는가"는 새로운 정보이므로 늘어난다. 계층 분리는 다이어트가 아니다.

다시 작성한 후, 메모리 측의 "미실시" 플래그 4곳도 해제했다. 이때 기계적으로 따라갈 수 있었던 것은, 메모리에 How to apply: 행이 들어있었기 때문이었다. "무엇을 다시 작성해야 하는가"가 각 메모리에 명시되어 있었기에, 그대로 TODO로 사용할 수 있었다.

계층 간의 동기화를 감지하는 메커니즘은 아직 가지고 있지 않다. 하지만 메모리를 쓸 때 반드시 How to apply:를 넣는 운용 방식이 부분적으로 그 역할을 수행하고 있었다.

남아있는 문제

• 계층 간의 동기화를 어떻게 감지할 것인가. 이번에는 우연히 발견했다. 안으로는 (a) 스킬의 각 섹션에 verified: YYYY-MM-DD를 넣는다, (b) 메모리에서 스킬로 "낡게 된" 링크를 건다, (c) 주 단위로 모순을 검출하는 잡(Job)을 돌린다 등이 있다.
• 스킬의 입도(Granularity). /ce-compound는 "34건이 쌓이면 승격"이지만, 왜 34건인가? 너무 세밀하면 쳐내야 할 대상이 늘어나고, 너무 거칠면 재사용되지 않는다. 정량적인 답을 본 적이 없다.
• 버전 관리의 비대칭성. 스킬은 리포지토리(Repository)에 들어가지만, 에이전트 메모리는 리포지토리 외부에 있다. 스킬의 변경은 추적할 수 있지만, 그것을 유도한 메모리의 변경은 추적할 수 없다.

참고한 1차 소스

• Peter Yang 「Hermes Agent를 제대로 활용하기 위한 6가지 배움」 (karan4d / Nous Research 인터뷰로부터, 2026-08-03)

https://x.com/petergyang/status/2084289426012897433

• 시라이 아키히코 「CLAUDE.md와 AGENTS.md를 깎아냈더니, AI 코딩이 훨씬 똑똑해졌다」 (note)

https://note.com/o_ob/n/nd19cba8e11d7 - Nityesh Agarwal 「Claude Code는 당신이 이미 가지고 있는 OpenClaw의 대안이다」 (Every, 2026-06-26)

https://every.to/source-code/claude-code-is-the-openclaw-alternative-you-already-have - Kieran Klaassen 「에이전트(Agents)가 구축한 소프트웨어를 다듬는 방법」 (Every, 2026-07-13)

https://every.to/source-code/how-i-polish-software-that-agents-built - Lilian Weng 「자기 개선(Self-improvement)을 위한 엔지니어링 활용」

(Hacker News 토론: https://news.ycombinator.com/item?id=49164896) - Dress Code 「아키텍처에 국한되지 않고 모든 의사결정을 남기는 『ADR (Architecture Decision Record)』라는 문화」 (Zenn)

https://zenn.dev/dress_code/articles/c73500ae73361c - 「Claude Code/Codex에 중~대규모 개발을 맡기기 위한 태스크 관리 (Task Management)」 (Qiita)

https://qiita.com/Y-Y-dev/items/d526fb7cdbe35a3f9384 - 「DeepSeek의 새로운 AI 모델은 잘 알려진 모델들 중 실행 비용이 단연 가장 저렴하다」 (Reuters, 2026-08-03. Artificial Analysis의 비용 비교를 보도함)

Discussion