Claude의 설계 제안을 세 번 뒤집었다 — AI 협업에서 “숨은 운영 비용” 따지기

AI가 먼저 제안한 “영리한” 구조를 단계적으로 거부하면서 더 단순한 결론에 도달한 캐치볼 기록

글로벌 스킬 이관 문제를 풀다가 흥미로운 일이 생겼습니다. 제가 “좋은 방법이 있으려나?” 하고 던진 질문에 Claude가 기술적으로 꽤 영리한 구조를 제안했는데, 저는 그걸 세 번에 걸쳐 뒤집었습니다. 최종 결론은 AI의 제안보다 훨씬 단순했고, 그 과정에서 저는 “영리한 설계일수록 숨은 비용을 먼저 따져야 한다”는 걸 다시 확인했습니다.

발단 — git 밖의 스킬

Claude Code를 쓰다 보면 두 종류의 스킬이 생깁니다. 프로젝트 스킬은 레포 안에 있어서 git clone하면 따라옵니다. 그런데 전역(글로벌) 스킬, 즉 ~/.claude/에 있는 것들은 어떤 레포에도 안 묶여 있어요. 새 머신이나 서버로 이관할 때 그냥 사라져버립니다.

“이거 어떻게 이관하지?” — 이게 시작이었습니다.

Claude의 첫 제안 — SSOT + 얇은 래퍼 (영리해 보였다)

Claude는 현황을 분석하더니 이런 구조를 제안했습니다.

“second 레포를 SSOT(단일 진실 출처)로 두고, 글로벌 ~/.claude/엔 ‘본문을 읽고 따르라’는 얇은 래퍼만 두면 됩니다. 부트스트랩 스크립트가 머신별 경로를 자동 주입하니까 서버에서도 경로가 달라도 자동 대응됩니다.”

중복 0, 한 곳만 고치면 끝. 새 머신 세팅은 git clone + 스크립트 한 번. 기술적으로 깔끔해 보였습니다. 저도 잠깐 “오, 이거 좋은데” 했습니다.

그리고 실제로 구현까지 했어요. 래퍼 파일들이 생겨났고, 스크립트도 만들어졌습니다.

첫 번째 뒤집기 — “루트에 생성되는 게 맞는 거 같고”

구현이 끝나고 나서 저는 “아 이거 아닌 거 같애 ㅋㅋㅋ”라고 했습니다.

직관적으로 뭔가 찜찜했어요. 생각해보니 래퍼는 호출할 때마다 본문을 읽으러 가는 인디렉션 한 단계가 더 생깁니다. 글로벌 스킬은 그냥 글로벌에 실제로 살아야 직관적인 거고, 래퍼라는 간접층을 사이에 두는 게 맞지 않았습니다.

“일단 루트에 생성되는 게 맞는 거 같고.”

한 마디로 래퍼 인디렉션을 거부한 겁니다.

두 번째 뒤집기 — “그냥 임포트 익스포트하는 문서인 거지, 스킬 적용되는 게 아니라”

그럼 second 레포에서는 어떻게 관리하나요? 이 지점에서 저는 프레임 자체를 바꿨습니다.

“내보내고 가져오는 걸 second 로컬 스킬로 하면 될 거 같아. /import-global-skill 하면 second로 다 가져오고, /export-global-skill 하면 second에 임포트되어 있는 글로벌 스킬들 다 루트에 저장하는 식으로. 세컨드에서 관리하는 건 그냥 claude 폴더에서 관리하는 게 아니고 그냥 위키 폴더에서 관리되면 좋을 거 같아. 그냥 임포트 익스포트하는 문서인 거지, 스킬 적용되는 게 아니라.”

이게 핵심이었습니다. 백업과 동작을 분리한 거예요. second에 있는 건 비활성 백업 사본이고, 동기화는 명시적 커맨드로만 하는 구조입니다. Claude의 설계는 second를 SSOT로 삼아 글로벌이 항상 그걸 바라보게 했는데, 저는 그 반대로 방향을 뒤집었습니다. 글로벌이 작업본이고, second는 백업이에요.

세 번째 뒤집기 (결정타) — “소화하면서 수정되거나 의도치 않게 스킬 추가되거나”

Claude는 백업을 wiki/ 안 어딘가에 두자고 했습니다. 그런데 저는 또 한 가지를 짚었어요.

“wiki 폴더 말고 편집 불가능한 관리 폴더도 만들어야 하나, 위키 밖으로? 소화하면서 수정되거나 그럴 수도 있을 거 같은데, 의도치 않게 스킬 추가되거나.”

이게 결정타였습니다. wiki/는 digest·lint·capture 같은 자동화 파이프라인이 자유롭게 읽고 고치는 영역입니다. 백업을 거기 두면 소화 중에 “이 파일 정리해야겠다” 하고 건드리거나, lint가 “고아 페이지네” 하고 손을 댈 수 있어요.

Claude의 답변이 인상적이었습니다.

“규칙(‘이 폴더는 건드리지 마’)으로 막는 건 LLM이 깜빡할 수 있어서 약해. 폴더를 아예 처리 범위 밖에 두는 구조적 격리가 안전하지.”

그래서 claude-skills/라는 폴더를 레포 루트에 wiki/ 밖으로 새로 만들었습니다. raw/와 같은 불변 위상을 갖는 영역입니다. digest/lint/capture는 wiki/만 대상으로 삼으니, 이 폴더는 자동으로 손이 안 닿습니다.

전과 후 — 무엇이 사라졌나

AI의 첫 제안:

second/.claude/  ← SSOT (본문)
~/.claude/       ← 얇은 래퍼 (포인터만)
scripts/install-global-skills.sh  ← 경로 주입 스크립트

비용: 인디렉션 한 단계 + second 세션에서 같은 커맨드 두 번 로드 + 백업이 실제 스킬로 활성화될 위험 + 소화 파이프라인 오염 가능성

최종 구조:

~/.claude/       ← 글로벌 작업본 (직접 수정)
second/claude-skills/  ← 비활성 백업 (불변 영역)
/import-global-skill, /export-global-skill  ← 명시적 동기화

비용: 없음. 인디렉션 0, 중복 로드 0, 소화 오염 0.

교훈 — AI의 영리함이 숨긴 것들

이 경험을 돌아보면 AI(Claude)는 기술적으로 우아한 해법을 먼저 봅니다. SSOT + 래퍼 패턴은 실제로 소프트웨어 설계에서 잘 쓰이는 패턴이고, 그 자체로 나쁘지 않습니다.

다만 저는 지금 보이는 깔끔함 뒤에 나중에 드러나는 운영 비용을 물어봤어요. 인디렉션이 늘진 않나? 의도치 않게 활성화되거나 다른 자동화가 건드리진 않나? 이 질문들이 구조를 세 번 뒤집게 했고, 결국 훨씬 단순한 곳에 도달했습니다.

스킬의-비밀-자연어가-로직이-되는-순간에서 제가 스킬이라는 개념을 처음 도입했을 때도 비슷한 패턴이 있었습니다. 처음엔 복잡해 보이는 구조에서 시작해, 운영해보면서 불필요한 층을 걷어내는 흐름이요.

AI가 구조를 제안하면 받아 적기 전에 물어보세요. “이거 6개월 뒤 어떻게 유지되지? 인디렉션이 늘진 않나? 의도치 않게 활성화되거나 다른 자동화가 건드리진 않나?” 영리한 설계일수록 숨은 운영 비용을 먼저 따져야 합니다.

<- 이전 편: 스킬의 비밀: 자연어가 로직이 되는 순간 함께 보기: Claude Code 4레버 방법론 · 빌드플랜 스킬로 개발시간 단축 배경: 나만의 세컨드브레인 설계 결정