개인 개발에서 Claude Code나 Gemini CLI와 같은 AI 에이전트를 사용하다 보면, 권한 설정·상시 읽어들이는 규칙 파일·Skills가 조금씩 쌓여간다. 처음에는 "작동하니까", "매번 제대로 승인했으니까"라는 이유로 쌓아 올릴 수 있다.

하지만, 그 축적물이 규모가 변하는 순간 어떻게 행동할지는 제대로 검증되지 않은 채 방치되기 쉽다. "규모가 변한다"는 것은 두 가지 의미를 갖는다. 시간이 흘러 설정이 늘어나는 것, 그리고 팀이나 여러 AI를 참여시키도록 확장되는 것.

이 기사에서는 자신(Claude Code를 사용하며, 공동 운용으로 Gemini/Antigravity를 사용하는 개인 개발 환경)의 하네스(Harness) 구성 일체를 실제로 열어보고, 5가지 축으로 점검한 결과를 기술한다. 결론부터 말하자면, 같은 "하네스" 안에서도 부품에 따라 내성이 완전히 달랐다. 어떤 부품은 규모가 커져도 망가지지 않았지만, 다른 부품은 이미 망가져 있었다.

이런 분들께 추천합니다:

• Claude Code / Gemini CLI 등의 AI 에이전트에 권한·상시 컨텍스트(Context)·Skills를 설정해 두었으며, 그것이 나중에 보기에 건전한지 궁금한 사람
• 개인 개발 설정을 향후 팀이나 복수의 AI로 확장할 가능성이 있는 사람
• "권한을 제한한다" 이외의 관점에서 AI 에이전트의 안전성·지속성을 평가하고 싶은 사람

하네스와 5가지 축

"AI 에이전트 = 모델 + 하네스(Harness)"라는 정식화가 있다. 하네스란 모델 본체 주위에 둘러싸는 실행 환경 일체를 말한다. 즉, 무엇을 실행시킬 것인가(권한), 무엇을 상시 읽게 할 것인가(컨텍스트), 상태를 어디에 어떻게 남길 것인가를 가리킨다. 2026년에 들어 이 주제를 다루는 Zenn 기사가 급증하고 있지만, 대부분은 권한의 사전 제어·사후 제어·가관측성(Observability) 이야기에 그치고 만다.

이번에 자신의 환경을 점검하며 알게 된 것은, "권한을 제한하고 있는가"라는 한 가지 점만으로는 부족하다는 사실이었다. 실제로 자신의 설정 파일을 다시 열어보고, 다음과 같은 5가지 축으로 진단해 보았다.

A. 스케일 내성 (Scale Resilience): 규모(시간·양)가 늘어나도 망가지지 않는가 -
B. 갱신 가능성 (Updatability): 나중에 개정·가지치기(Pruning)할 수 있는 경로가 있는가 -
C. 추적 가능성 (Traceability): 무엇을·왜 했는지 나중에 추적할 수 있는가 -
D. 최적화 가능성 (Optimizability): 축적된 정보를 실제 개선으로 돌릴 수 있는가 -
E. 다주체 대응 가능성 (Multi-agent Supportability): 팀이나 다른 AI가 나중에 참여해도 기능하는가

이후, 각각을 자신의 실제 설정 파일로 진단해 나간다.

A축: 스케일 내성——허가 리스트는 "매 순간에는 타당"했으나 망가져 있었다

Claude Code는 워크스페이스마다 .claude/settings.local.json에 과거에 승인한 명령어를 허가 리스트(Allowlist)로서 축적해 나간다. 자신의 환경 내부를 열어보니 다음과 같았다 (일부 발췌).

"Bash(curl -sk -i -A \"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36\" \"https://assets.example.com/\")",
"Bash(docker exec myapp-astro-1 *)",
"Bash(MSYS_NO_PATHCONV=1 docker exec *)",
...

한 줄씩 보면, 각각 승인했던 시점에는 타당한 판단이었다. 특정 버그 조사를 위해 UA를 위장한 curl을 한 번 실행할 필요가 있었고, 특정 컨테이너에 대해 docker exec를 허가할 필요가 있었다—모두 문맥상으로는 일리가 있다.

하지만 이 허가 리스트는 현재 34개의 엔트리로 성장해 있다. 끝부분의 Bash(MSYS_NO_PATHCONV=1 docker exec *)처럼, 도중에 개별 컨테이너 이름 지정을 그만두고 와일드카드로 확장된 엔트리도 있다. "그 자리에서는 타당함"을 쌓아 올린 결과, 전체적으로 무엇을 허가하고 있는지 한눈에 설명할 수 없는 상태가 되어 있었다. 개별 승인이 잘못된 것이 아니라, 승인이라는 행위가 선형적으로 적분되었을 때 감사 가능성(Auditability)이 망가지는 것이다. 이것이 A축(스케일 내성)의 실패 패턴이었다.

B축: 갱신 가능성——일방향으로 쌓이는가, 가지치기할 수 있는가

A축의 문제는 애초에 허가 리스트에 가지치기할 경로가 마련되어 있지 않다는 점에 기인한다. Claude Code의 허가 리스트는 기본적으로 추가만 하는 방식으로 운용되고 있으며, "이 허가는 이제 필요 없으니 지운다"라는 절차가 정의된 운용 방식으로서 존재하지 않는다.

대조적으로, Claude Code의 메모리 기능(사용자 디렉터리 하위의 .claude/projects/<워크스페이스 고유 해시>/memory/, 프로젝트마다 자동 생성됨)은 명확하게 업데이트 및 삭제가 운용에 포함되어 있다. 실제로 기술 기사 작성 절차서(00_config/templates/Technical_Article_Writing_Protocol.md)를 관리하는 메모리는 2026-07-28에 내용 검토가 이루어졌다.

2026-07-28에 템플릿 검토 실시: 실제 기사 파일군과 템플릿 사이에 드리프트(Drift)가 축적되어 있었다(중략). 대응책으로 Article_Plot_Template.md를 신설하고, 프로토콜에 Step 0를 추가하며, 모든 템플릿의 status enum을 실제 사용 값으로 통일……

이것은 "오래된 기록을 다시 쓰는" 개정이 실제로 발생했다는 기록 그 자체이며, 메모리 파일 자체가 해당 개정 이력을 가지고 있다. 허가 리스트(Permission List) 측에는 이러한 종류의 개정 이벤트가 단 한 번도 존재하지 않는다. 늘어나기만 할 뿐, 줄어든 적이 없다.

C축: 추적 가능성(Traceability) —— "왜"가 남는가, 남지 않는가

C축은 B축과 표리 관계에 있다. 메모리 파일의 실물을 보면 다음과 같은 구조로 되어 있다.

---
name: feedback_cybernetics_over_representationism
description: 노치의 설계 사상 (사이버네틱스 우위)...
...

originSessionId를 통해 어느 세션에서 유래했는지 알 수 있으며, Why: 한 줄로 왜 그 판단에 이르렀는지가 반드시 남는 형식으로 되어 있다. 반년 후에 이 파일을 열더라도 "왜 이 방침을 취했는가"를 재구성할 수 있다.

반면 .claude/settings.local.json의 허가 리스트는 명령어의 문자열 패턴만을 가진다. Bash(MSYS_NO_PATHCONV=1 docker exec *)라는 한 줄만을 보고, 이것이 언제, 어떤 작업을 위해, 누구의 승인을 받아 추가되었는지를 재현할 수 있는 수단은 이 파일 단독으로는 존재하지 않는다. 동일한 "하네스(Harness)" 안에 추적 가능한 부품과 추적 불가능한 부품이 공존하고 있다.

D축: 최적화 가능성(Optimizability) —— 관측해도 개선으로 이어지지 않았다

A축의 문제는 사실 한 차례 지적된 적이 있다. 2026-07-19, 하네스 구성을 점검(Inventory)하는 작업 중에 나(Claude Code) 자신이 "매번 승인하는 방식의 누적으로 시작되었으나, 결과적으로 실질적으로 무제한에 가까운 허가가 되어 있다"라고 메모에 남겨두었다.

이 글을 쓰기 위해 2026-08-05 시점에 다시 .claude/settings.local.json을 열어보았으나, 당시 지적했던 엔트리는 그대로 남아 있다. 점검이라는 행위 자체는 일어났지만(관측은 되었지만), 그것이 실제로 허가 리스트를 가지치기하는 개선 행동으로 이어지지는 않았다.

이는 D축 단독의 문제라기보다, B축(개정 경로가 없음)과 D축(개선으로 되돌리는 운용이 없음)이 겹쳐서 발생하는 복합적인 실패라고 생각한다. 관측 결과를 인간이 읽을 수 있는 곳에 두는 것만으로는 최적화 루프가 자동으로 닫히지 않는다. 점검의 결과를 "다음에 무엇을 할 것인가"까지 운용으로 녹여내는 공정이 현재 나의 설정에는 결여되어 있다.

E축: 다주체 대응 가능성(Multi-agent Compatibility) —— 나중에 참여한 AI가 다시 만들지 않아도 되었던 이유

이 환경은 원래 Gemini(Antigravity/SAS)가 선행하여 작동하고 있었으며, Claude Code는 나중에 합류했다. 이 합류가 5개 축 중에서 유일하게 "성공적으로 견뎌낸" 실례가 되고 있다.

Skills 디렉터리의 실체는 .agents/skills/에 있으며, Claude Code용으로는 .claude/skills/에 얇은 프록시(Proxy)로서 미러링되어 있다. 예를 들어 "Zenn에 특화된 Markdown 표기법·임베딩 규칙을 관리하는 zenn-markdown 스킬"의 실체는 222행이지만, Claude Code 측의 실제 파일은 10행뿐이다.

---
name: zenn-markdown
description: Zenn에 특화된 Markdown 표기법·임베딩·표시 사양의 규칙과
...

Claude Code가 합류한 시점에서 Skills를 다시 만들 필요는 없었다 —— 기존의 Markdown을 그대로 읽어 들여 따르는 얇은 프록시(Proxy)를 하나 추가하는 것만으로 충분했다. MOC(Map of Content, 내비게이션용 인덱스 파일군)에 대해서도 마찬가지로, 어느 쪽 AI가 보더라도 동일한 구조를 따라갈 수 있다. 이것이 작동한 이유는 단순하다. Skills도 MOC도 어느 한쪽 AI의 내부 상태(Internal State)로 품고 있었던 것이 아니라, 처음부터 인간이 읽고 쓸 수 있는 Markdown으로서 외부화(Externalization)되어 있었기 때문이다. 만약 어느 한쪽 AI의 전유 포맷으로 가지고 있었다면, 후발 합류 시점에 다시 만들어야 했을 것이다.

다만, 이 해결책에는 환경 특유의 제약이 얽혀 있다. 워크스페이스는 Google Drive의 가상 볼륨 위에 있으며, NTFS의 reparse point에 대응하지 않기 때문에 심볼릭 링크(Symbolic Link)나 정션(Junction)을 생성할 수 없다(ln -s · mklink /J 모두 실패함을 2026-07-07에 확인 완료). 여러 AI 도구 간에 설정 파일을 공유하는 일반적인 해설 기사들은 대개 symlink를 통한 일원 관리를 전제로 하지만, 이 환경에서는 그것을 사용할 수 없어 실체를 한 곳에 두고 나머지는 얇은 프록시 파일로 참조하는 대체 패턴을 취할 수밖에 없었다.

**트랜잭션성(Transactionality)**에 대해서는 AI_Mailbox.md라는 추가 전용 파일이 담당하고 있다. 운용 규칙은 명확하다.

• 끝에 추가만 함. 과거의 엔트리(Entry)는 편집하거나 삭제하지 않음 (로그로서 쌓음).
• 각 엔트리는 ## YYYY-MM-DD HH:MM — [송신처] → [수신처] 헤딩으로 시작함.

여러 AI가 동일한 상태 공유 파일에 쓸 경우, read-modify-write의 경합(Contention)이 최대 리스크가 된다. 추가 전용(Append-only) 방식으로 함으로써 이 경합을 구조적으로 피하고 있다. 최근 4개의 엔트리만 본체에 남기고 오래된 것은 아카이브로 퇴피시키는 로테이션(Rotation) 또한 파일 크기의 비대를 방지하는 형태로 운용에 포함되어 있다.

개인 개발에서 팀 운용으로 확장할 때, 추가로 망가지는 것들

지금까지의 5가지 축 진단은 모두 '나 혼자 + 여러 AI'라는 체제 안에서 성립하던 이야기다. 이것을 인간 팀으로 확장하면, 위의 축만으로는 설명할 수 없는 요인들이 새롭게 등장한다.

• 감사 로그(Audit Log)의 주체 특정: 개인 개발에서는 '매번 내가 승인했다'로 책임 소재가 일의적으로 결정되었다. 팀에서는 '누가 승인했는가'를 기록하고 특정하는 메커니즘이 별도로 필요하다. 현재의 허가 리스트 형식(커맨드 패턴만 지원)으로는 이것에 처음부터 대응할 수 없다.
• 승인 기준의 편차: 개인은 일관된 기준으로 허가를 쌓아왔지만, 팀에서는 사람에 따라 '이것을 허가해도 되는가'의 임계값(Threshold)이 어긋난다. A축에서 보았던 '그 자리에서는 타당함'의 적분(Integration)에 의한 붕괴는, 팀에서는 한 사람의 페이스보다 빠르게 진행될 가능성이 높다.
• 복수 "인간"의 동시 쓰기: AI_Mailbox.md의 append-only 설계가 해결했던 것은 복수의 "AI"의 동시 쓰기였다. 복수의 "인간"이 동일한 memory나 설정 파일을 동시에 편집하는 경우에는 Git의 머지 컨플릭트(Merge Conflict)와 같은 별종의 충돌이 발생할 수 있다. append-only 설계만으로는 이러한 종류의 충돌을 막을 수 없다.
• 온보딩 비용(Onboarding Cost)의 비대칭성: AI가 Skills/MOC를 읽어 들이는 비용과, 새로 들어온 인간 멤버가 CLAUDE.md·memory 전체를 읽고 문맥을 파악하는 비용은 같지 않다. AI는 (컨텍스트 길이의 제약은 있을지언정) 지시된 파일을 기계적으로 전부 읽을 수 있지만, 인간은 전부 읽지 않거나 읽을 수 없다. E축에서 '잘 버텨냈다'고 평가한 메커니즘도, 읽는 이가 인간으로 바뀌는 순간 전제가 무너진다.

요약

'하네스를 폐쇄 루프(Closed Loop)로 만들었는가'도 '권한을 얼마나 제한했는가'도 아니라, 규모가 변했을 때 실제로 망가지는지를 기준으로 보면, 동일한 설정 안에서도 부품마다 평가가 갈렸다.

• 허가 리스트 (settings.local.json): A·B·C·D 축 모두에서 취약했다. 개별 승인은 타당할지라도, 적분되고, 전정(Pruning)되지 않으며, 이유가 남지 않고, 지적을 받아도 개선으로 돌아가지 않았다.
• memory + AI_Mailbox.md: B·C·E 축에서 기능했다. 업데이트 이력이 남고, 이유가 남으며, 복수 AI의 합류에도 견뎌냈다.

독자가 자신의 AI 에이전트 설정을 재검토할 때는, 다음을 자문해 보길 바란다.

• 개별적인 권한과 규칙이 쌓여 만들어진 전체로서, 지금도 한눈에 설명 가능한가 (A)
• 오래된 설정을 가지치기(Pruning)할 경로가 애초에 마련되어 있는가 (B)
• "왜 이 설정으로 했는가"를, 반년 뒤의 내가 재구축할 수 있는가 (C)
• 문제를 지적받았을 때, 그것이 실제로 설정 변경에 반영되는 메커니즘이 있는가 (D)
• 지금 팀이나 다른 AI가 합류한다면, 그 부분을 새로 만들지 않고 해결할 수 있는가 (E)
• 팀으로 확장했을 때, 승인 주체 특정 · 기준의 불일치 · 인간 간의 동시 편집 · 온보딩 비용(Onboarding cost) 문제는 별도로 대처되어 있는가

자신의 AI에게 이 5가지 축으로 진단하게 하는 프롬프트

위의 체크리스트는 머릿속으로만 살펴보는 것이 아니라, 그대로 AI 에이전트에게 던져 실행하게 할 수도 있다. 일반론이나 인상으로 채우게 하지 말고, 실제 파일을 열게 하여 답하게 하는 것이 포인트다.

현재 이 프로젝트에서 나(AI)가 사용하고 있는 하네스(Harness) 구성을 다음 5가지 축으로 진단해 주길 바란다.
【전제】
- 반드시 실제 파일을 열어서 확인할 것 (권한·허가 리스트 설정 파일, 상시 로드되는 규칙 파일, memory나 상태 관리 메커니즘). 일반론이나 추측으로 채우지 말 것.
...

나의 경우, 5가지 축 중 적어도 하나(허가 리스트)는 이미 망가져 있었다. "작동하고 있으니까 괜찮다"와 "규모가 바뀌어도 망가지지 않는다"는 별개의 문제라는 것이 이번 점검(Inventory)을 통해 얻은 가장 명확한 수확이었다.

Discussion