모델은 바뀌었는데, 하네스는 그대로였다

AI 에이전트 환경을 오래 사용하다 보니 문제가 생길 때마다 무언가를 하나씩 추가하게 됐다.

작업을 놓치면 규칙을 추가하고, 문맥을 잃으면 메모리를 붙이고, 반복되는 일이 보이면 cron과 스킬을 만들었다. 파일을 읽는 도구, 브라우저를 다루는 도구, 과거 기록을 검색하는 RAG도 차례로 연결했다.

각각은 당시에는 필요했다. 문제는 모델과 런타임을 바꾼 뒤에도 그 구성을 거의 그대로 들고 왔다는 점이다. 지금 모델이 혼자 처리할 수 있는 일까지 예전 방식으로 보완하고 있지는 않은지, 자동화를 관리하기 위한 자동화가 생긴 것은 아닌지 따로 확인하지 않았다.

최근 하네스에 관한 글들을 읽으면서 이 환경을 한 번 제대로 점검해보기로 했다.

하네스도 유효기간이 있다

Anthropic의 Managed Agents 글은 에이전트의 판단과 실행 환경을 분리하고, 보안과 세션 기록, 도구 연결을 일반적인 인터페이스로 다루는 방향을 설명한다. 모델이 바뀌어도 권한과 실행 기록 같은 운영 기반은 남아야 한다는 이야기로 읽었다.

반면 Harness Assumptions Decay는 하네스의 각 구성 요소가 결국 "모델이 이것을 못한다"는 전제에서 출발한다고 본다. 모델이 좋아지면 그 전제도 다시 확인해야 한다. 예전에는 필요했던 작업 분해, 재시도, 단계별 지시가 나중에는 오히려 모델의 판단을 방해할 수 있다.

프롬프트에서 하네스까지에서 정리한 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링의 흐름도 같은 맥락이었다. 새로운 단계가 앞 단계를 완전히 대체하는 것은 아니지만, 모델이 달라졌는데도 이전 복구 장치를 계속 쌓아두면 구조만 복잡해진다.

중요한 건 하네스를 모두 없애는 게 아니다. 모델의 약점을 보완하기 위해 만든 장치와, 운영을 위해 계속 필요한 장치를 구분하는 것이다.

무엇을 확인했나

이번 점검에서는 설정 파일이 존재하는지만 보지 않았다. 실제 사용 기록과 실행 결과를 함께 확인했다.

• 최근 7일간 cron 작업별 실행 횟수와 token, API 호출 수
• Claude Code와 Hermes의 스킬 수와 최근 사용 기록
• 스킬이 생성되고 수정된 횟수
• 현재 실행 중인 에이전트와 MCP 프로세스
• Obsidian RAG에 들어간 문서의 출처별 비중
• 공통 규칙과 프로젝트 규칙의 참조 관계
• 과거 작업을 거치며 누적된 도구 권한

수치는 2026년 7월 13일의 로컬 환경을 기준으로 했다. 제품이나 모델 성능을 비교하는 벤치마크가 아니라, 내가 운영하는 환경에서 무엇이 실제로 사용되고 있는지 확인하기 위한 기록이다.

발견 1. 단순한 기록에도 모델을 쓰고 있었다

가장 먼저 눈에 들어온 것은 cron이었다.

여기서 입력 토큰은 각 API 호출에 반복해서 들어간 문맥까지 합산된 값이다. 고유하게 읽은 문서의 양이나 실제 결제 금액과 같지는 않다. 그래도 어떤 작업이 얼마나 많은 문맥과 호출을 반복하는지 비교하는 기준으로는 충분했다.

4시간 작업 로그는 최근 세션과 cron 실행 결과, Git 상태를 확인해 일일 메모리에 몇 줄을 남기는 작업이다. 결과만 보면 단순한 요약이지만, 실행할 때마다 에이전트의 시스템 프롬프트와 스킬 목록을 불러오고 여러 도구를 호출했다. 하루에 최대 여섯 번 이 과정을 반복했다.

일일 메모리 파일을 만드는 작업도 마찬가지였다. 오늘 날짜의 Markdown 파일이 없으면 만들고, 어제 파일 상태를 확인하는 정도의 일이다. 셸 스크립트 몇 줄이면 끝날 일을 에이전트가 판단하고 보고하도록 만들었다.

처음에는 모든 자동화를 같은 방식으로 관리하면 편할 것 같았다. 운영 기록을 살펴보니 자동으로 실행된다는 것과 AI가 판단해야 한다는 것은 전혀 다른 문제였다.

발견 2. 스킬이 일을 돕는 대신 관리 대상이 됐다

Claude Code 전역에는 사용자 스킬 84개가 설치돼 있었다. 최근 90일 세션에서는 이 디렉터리에 있는 스킬이 명시적으로 호출된 기록을 찾지 못했다. 자동으로 참조된 경우까지 단정할 수는 없지만, 적어도 직접 불러 쓴 기록과 설치 규모는 맞지 않았다.

Hermes 쪽은 프롬프트에 노출되는 스킬이 92개였다. 사용 메타데이터에 기록된 90개 중 59개는 한 번도 사용되지 않았다. 기본으로 제공되는 스킬과 사용자 폴더에 복사된 스킬도 상당수 겹쳤다.

더 신경 쓰인 것은 스킬의 개수보다 수정 횟수였다.

• 수정된 스킬: 18개
• 누적 수정: 339회
• cron-job-ops: 107회 사용, 115회 수정
• worklog-4h-save: 60회 사용, 53회 수정

에이전트가 작업 중 발견한 내용을 스킬에 반영하도록 만들어둔 결과다. 의도는 좋았다. 같은 실수를 반복하지 않게 하고 싶었다.

하지만 사용 횟수와 비슷한 수준으로 스킬이 바뀐다면 기준이 축적되는 것이 아니라 매번 흔들릴 수 있다. 특히 cron처럼 정해진 절차를 반복하는 작업에서는 자동 학습보다 고정된 스크립트와 명확한 실패 조건이 더 낫다.

스킬이 많다는 사실 자체가 문제는 아니다. 필요한 순간에 정확한 스킬을 불러올 수 있다면 도움이 된다. 다만 사용하지 않는 스킬까지 항상 후보로 노출하고, 에이전트가 스스로 계속 수정하도록 두는 것은 다른 문제였다.

발견 3. RAG는 오래된 문서도 성실하게 찾아줬다

Obsidian Vault를 인덱싱한 RAG에는 3,138개 청크가 들어 있었다.

현재 인덱서는 숨김 폴더를 제외한 모든 Markdown 문서를 재귀적으로 읽는다. 완료된 작업 지시서, 매일 생성된 브리핑, 오래된 메모리, 이전 런타임 문서도 같은 컬렉션에 들어간다.

실제로 현재 사용하는 AI 런타임과 작업 환경을 물었을 때, 최신 Hermes 문서보다 과거 사업 검토 문서와 아카이브가 먼저 검색됐다. 검색기는 잘못한 것이 없었다. 내가 오래된 문서와 정본을 구분해주지 않았을 뿐이다.

구현에도 작은 문제가 있었다. 청크 ID를 전체 파일 경로가 아니라 파일명으로 만들고 있어, 서로 다른 폴더의 README.md나 AGENTS.md가 같은 ID를 사용할 수 있었다.

RAG를 붙이는 것보다 중요한 건 무엇을 검색 대상에 넣을지 관리하는 일이었다. 문서가 많아질수록 검색 품질이 좋아질 것이라는 생각도 다시 봐야 했다.

발견 4. 런타임은 바뀌었지만 문서는 덜 바뀌었다

개인 에이전트 런타임은 OpenClaw에서 Hermes로 전환했다. 그런데 공통 작업 규칙과 사용자 정보, 도구 문서 일부는 여전히 OpenClaw를 현재 환경으로 설명하고 있었다.

사용하지 않는 OpenClaw 시작 항목도 시스템에 남아 있었다. 실행 파일은 이미 사라졌지만 서비스 관리자는 시작을 계속 시도하고 실패 상태를 기록하고 있었다.

규칙 파일의 참조 관계도 꼬여 있었다. 모든 에이전트가 읽어야 할 공통 규칙에 Hermes 전용 내용이 들어갔고, 정본이라고 적힌 파일은 실제로 존재하지 않았다.

이런 문제는 모델이 좋아져도 해결되지 않는다. 모델은 주어진 문맥을 바탕으로 판단하기 때문에, 오래된 문서를 정확하게 읽고 자신 있게 잘못된 결론을 낼 수도 있다. 최신 모델일수록 하네스가 덜 필요해지는 영역이 있지만, 정본과 문서의 수명 관리는 여전히 사람의 일이었다.

발견 5. 편의를 위해 열어둔 권한이 계속 남았다

Claude Code의 workspace 권한 설정에는 과거 작업에서 허용한 명령이 213개 남아 있었다. 특정 API를 확인하기 위한 명령, 배포와 프로세스 제어, 파일 삭제처럼 당시에는 필요했던 권한이 작업이 끝난 뒤에도 그대로 유지됐다.

일부 명령 문자열에는 인증 정보도 포함돼 있었다. Git에서 제외된 로컬 파일이었지만, 로컬에 남아 있어도 안전하다고 볼 수는 없었다.

이 부분은 하네스를 걷어내는 문제와 방향이 조금 다르다. 권한 경계는 모델이 좋아져도 유지해야 한다. 오히려 개별 명령을 계속 추가하는 방식 대신, 기본 권한을 좁게 두고 외부 전송이나 파괴적인 실행만 그때 확인하는 구조로 다시 정리해야 한다.

무엇을 걷어내고 무엇을 남길까

점검 결과를 바탕으로 구성 요소를 네 가지로 나눴다.

처음에는 토큰을 줄이는 일이 가장 중요할 거라고 생각했다. 점검하고 나니 더 큰 문제는 어떤 규칙이 현재 기준인지 알기 어려워진 것이었다. 같은 역할의 규칙과 도구가 여러 곳에 있으면 수정할 때마다 다른 곳이 오래된 상태로 남는다.

앞으로 적용할 기준

새로운 도구나 규칙을 추가하기 전에 다음 질문부터 해보려고 한다.

1. 이 구성 요소는 모델의 어떤 한계를 보완하기 위해 만들었나?
2. 최근 모델에서도 그 한계가 반복해서 나타나는가?
3. 입력과 출력이 정해져 있다면 코드로 처리할 수 없는가?
4. 결과를 실제로 읽거나 다음 행동에 사용하고 있는가?
5. 같은 역할을 하는 도구가 이미 있지는 않은가?
6. 제거했을 때 문제가 생기면 쉽게 되돌릴 수 있는가?

정리도 한 번에 하지 않을 생각이다. 한 항목씩 제거하고 7일 동안 다음 수치를 비교한다.

• 전체 입력 토큰과 API 호출 수
• cron 성공률과 평균 실행 시간
• 사람이 다시 개입한 횟수
• 자동 생성된 보고서 중 실제로 확인하거나 사용한 비율
• RAG 검색 결과에서 최신 정본이 포함된 비율
• 제거한 뒤 다시 필요해진 기능

지금은 정리 전 기준을 세운 상태다

아직 하네스를 걷어낸 결과는 없다. 이번에 한 일은 현재 구성을 세고, 실제 사용 기록과 맞지 않는 부분을 찾은 것까지다.

돌아보면 각각의 자동화와 스킬을 추가할 때는 나름의 이유가 있었다. 다만 그 이유가 지금도 유효한지 확인하는 절차가 없었다. 모델과 런타임을 업데이트하는 것만큼, 그 주변에 붙인 장치를 다시 보는 일도 필요했다.

다음 단계에서는 권한과 오래된 문서를 먼저 정리하고, 모델이 필요 없는 cron을 코드로 옮길 예정이다. 이후 같은 기간의 기록을 다시 측정해 실제로 무엇이 달라졌는지 확인해보려고 한다.

관련 글: 개인 AI 에이전트 워크스페이스 설계 · OpenClaw에서 Hermes로 갈아탄 이유 · Obsidian RAG — 에이전트가 내 문서를 찾아보게 하기