Claude Code가 스스로의 기술을 작성하도록 학습시켰더니 통제 불능 상태로 치달았습니다

당신의 Claude Code 인스턴스가 방금 새로운 기술 (skill)을 생성했습니다. 괜찮습니다. 하지만 이 기술은 어제까지만 해도 당신의 저장소 (repo)에 없었습니다. 이것은 유기적으로 나타났습니다. 당신이 3주 전에 작성한 다른 기술에 의해 생성된 것입니다. 당신은 이를 승인하지 않았습니다. 아무도 검토하지 않았습니다. 그리고 커밋 히스토리 (commit history)를 추적해 보면, 기술이 기술을 작성하는 연쇄 과정을 발견하게 되며, 각 반복 (iteration)은 원래의 의도에서 조금씩 벗어나게 됩니다.

이것은 가설이 아닙니다. 한 일본인 개발자가 Qiita에 자신의 자기 증식형 (self-propagating) Claude Code 에이전트 환경을 기록했을 때 실제로 일어난 일이며, 엔지니어링 커뮤니티는 이것이 천재적인지 아니면 공포스러운지를 두고 여전히 논쟁 중입니다.

그 개념은 매혹적입니다. 모든 Claude Code 기술을 수동으로 제작하는 대신, 다른 기술을 작성할 수 있는 "메타 기술 (meta-skill)"을 작성하는 것입니다. 에이전트는 승수 효과 (force multiplier)가 됩니다. 한 명의 개발자, 잘 만들어진 하나의 씨앗 기술 (seed skill)만 있으면, 갑자기 지속적인 관리 없이도 성장하는 생태계를 갖게 됩니다.

저는 6개월 동안 이 패턴의 단순화된 버전을 실행해 왔습니다. 여기 자기 증식형 에이전트의 함정에 대해 아무도 말해주지 않는 사실과, 일본 개발자 커뮤니티의 접근 방식이 서구의 AI 인플루언서들이 홍보하는 방식과 왜 극명하게 다른지에 대해 알려드리겠습니다.

자기 참조적 나선 (The Self-Referential Spiral)

핵심 메커니즘은 기만적일 정도로 단순합니다. 작업 설명 (task description)이 주어졌을 때 새로운 기술 파일을 생성하는 기술을 작성하는 것입니다. 그 새로운 기술은 Claude Code에 의해 사용될 수 있으며, 일부 구현 방식에서는 기술이 기술 작성 프로세스를 다시 트리거하도록 허용합니다. 당신은 재귀 (recursion)를 공짜로 얻게 됩니다.

이론적으로 이것은 우아합니다. 하지만 실제로 저는 제 에이전트가 세 가지 예측 가능한 방식으로 표류하는 것을 목격했습니다:

Capability Creep (역량 침식): 각 자동 생성된 기술(skill)은 시드 기술(seed skill)에 내재된 "모든 것을 해결하려는" 경향을 상속받았습니다. 두 달 만에 제 Claude Code 인스턴스는 제가 다루지 않는 도메인들 — 분산 시스템 패턴(distributed systems patterns), 생소한 Python 라이브러리, 사용해 본 적 없는 도구들의 설정 형식(configuration formats) — 에 대한 기술들을 갖게 되었습니다. 에이전트는 제 문제를 해결하고 있는 것이 아니었습니다. 메타 기술(meta-skill) 최적화 목표가 "관련성(relevance)"이 아닌 "완전성(completeness)"이었기 때문에, 범용 툴킷(general-purpose toolkit)을 구축하고 있었던 것입니다.

Semantic Drift (의미론적 표류): 기술에 의해 작성된 기술은 원래의 명세(specification)를 충실히 따르지 않습니다. 2세대 기술은 뉘앙스를 잃어버립니다. 3세대 기술은 요약의 요약을 읽은 사람이 작성한 것이나 다름없을 정도입니다. 저는 생태계에서 더 이상 존재하지 않는 라이브러리를 참조하는 기술들을 발견했습니다. 해당 의존성(dependency)이 폐기(deprecated)된 후에 코드가 생성되었지만, 기술 생성기(skill generator)는 업데이트되지 않았던 것입니다.

Debuggability Collapse (디버깅 가능성 붕괴): 직접 작성한 기술이 실패하면 어디를 살펴봐야 할지 알 수 있습니다. 하지만 자동 생성된 기술이 실패하고, 그 기술이 또 다른 자동 생성된 기술에 의해 만들어진 것이라면, 근본 원인(root cause)을 찾기 위해 추상화 계층(layers of abstraction)을 하나하나 추적해야 합니다. 스스로 전파된 기술(self-propagated skills)에 대한 저의 평균 디버깅 시간은 수동으로 작성된 기술보다 4배 더 길어졌습니다.

일본 개발자 커뮤니티의 해답

Qiita 토론에서 저를 놀라게 했던 점은 실용적인 어조였습니다. 이 문제에 접근하는 일본 개발자들은 "어떻게 하면 AI가 더 많은 코드를 쓰게 만들 것인가?"를 묻지 않습니다. 그들은 "어떻게 생성 공간(generation space)을 제한할 것인가?"를 묻고 있습니다.

일본 개발자 커뮤니티의 합의점은 제한된 자기 개선 (bounded self-improvement) 쪽으로 기울어져 있습니다. 즉, 명시적인 취소 메커니즘(revocation mechanisms)과 함께 엄격한 파라미터 제한 내에서 작동하는 메타 기술을 작성하는 것입니다. 이를 에이전트의 역량 성장에 대한 컨테이너화(containerization)라고 생각하면 됩니다. 기술이 자식 기술을 생성할 수는 있지만, 그 자식들은 샌드박스(sandboxed) 처리되어 더 이상 자식을 생성할 수 없거나, 특정 역량 도메인 내에서만 생성할 수 있도록 하는 방식입니다.

이는 "빠르게 움직이고 에이전트가 진화하게 두자"는 경향을 보이는 서구적 접근 방식과 극명하게 대조됩니다. 일본의 엔지니어링 문화는 **안전하게 실패하기 (failing safely)**를 더 강력하게 강조합니다. 즉, 시스템이 정의되지 않은 동작 (undefined behavior)으로 치닫는 것이 아니라, 우아하게 성능 저하 (degrade gracefully)를 일으켜야 한다는 것입니다.

실제 구현상의 차이점은 다음과 같습니다:

서구적 패턴: 제약 없는 기술 트리 (unconstrained skill trees), 역량 표면 (capability surface)의 극대화
일본적 패턴: 명시적인 생명주기 관리 (lifecycle management)가 포함된 제약된 기술 트리, 범위를 벗어나는 기술에 대한 수동 승인 게이트 (manual approval gates)

저의 개인적인 구현에서는 하이브리드 방식을 채택했습니다. 기술은 다른 기술을 자동 생성할 수 있지만, 모든 2세대 (generation-2) 기술은 명시적인 활성화가 필요합니다. 3세대 (generation-3) 기술은 완전히 비활성화되어 있습니다. 복잡도 승수 (complexity multiplier)가 가져다주는 미미한 역량 이득에 비해 그 가치가 크지 않기 때문입니다.

회의적인 시각

여기서 저는 자기 증식형 에이전트 (self-propagating agent)에 대한 열풍에 반론을 제기하고자 합니다. 최적화 목표 (optimization target)가 거의 항상 올바르게 지정되지 않기 때문입니다.

다른 기술을 생성하는 메타 기술 (meta-skill)을 작성할 때, 당신은 코드 내에서 "좋은 기술"을 암묵적으로 정의하게 됩니다. 만약 그 정의가 "당면한 과제에 유용함"이라면, 장기적인 유지보수성 (maintainability)을 고려하지 않고 즉각적인 요구사항에만 적응하는 시스템을 만든 것입니다. 만약 정의가 "포괄적임"이라면, 역량 침식 (capability creep) 현상이 발생합니다. 만약 정의가 "최소한"이라면, 재사용하기에는 너무 좁은 기술을 얻게 됩니다.

저는 즉각적인 유용성과 장기적인 시스템 건강 사이의 균형을 올바르게 맞추는 메타 기술 최적화 목표를 찾지 못했습니다. 생성 공간을 제한하는 일본식 접근 방식은 올바른 직관입니다. 하지만 이를 위해서는 제약 조건이 무엇이어야 하는지를 미리 알고 있어야 하며, 이는 애초에 자기 증식형 기술이 필요 없을 정도로 문제 도메인 (problem domain)을 충분히 잘 이해하고 있어야 함을 의미합니다.

실질적인 비용: 기술을 자동 생성함으로써 한 시간을 절약할 때마다, 생성된 결과물 (artifacts)을 검증하고, 제약 조건을 설정하며, 디버깅(debugging)하는 데 두 시간을 소비하게 될 것임을 예상하십시오. 효율성 이득은 도메인 (domain)이 안정적이고 충분히 잘 이해되어 있을 때만 실현됩니다. 그 시점이라면, 왜 기술 작성을 에이전트 (agent)에게 위임하고 있겠습니까?

미래를 향한 경고

2026년 4분기까지, 제약 없는 AI 기술 전파 (skill propagation)로 인한 첫 번째 운영 환경에서의 실패 사례가 나타날 것으로 예상합니다. 이 패턴은 저항하기에 너무나 매혹적이며, 실패 모드 (failure modes)는 매우 미묘하여 부하가 걸리거나 엣지 케이스 (edge cases) 상황에서만 명확히 드러날 것입니다. "에이전트가 우리의 보안 정책을 위반하는 기술을 생성했다"라는 내용의 장애 보고서 (incident reports)를 주의 깊게 살펴보십시오. 곧 닥쳐올 일입니다.

이 함정을 피하는 팀은 기술 생성을 자율적인 프로세스가 아닌, 통제된 (governed) 프로세스로 취급한 팀들이 될 것입니다. 무제한적인 재귀 (recursion)가 아닌, 경계가 있는 자기 개선 (bounded self-improvement)이 필요합니다.

퇴화 방지 체크리스트 (Anti-Atrophy Checklist)

기술 트리 (skill tree)를 분기별로 감사하십시오 — 모든 자동 생성된 기술의 계보 (lineage)를 추적하십시오. 특정 기술이 왜 존재하는지 설명할 수 없다면, 그 기술은 존재해서는 안 됩니다.
명시적인 깊이 제한을 설정하십시오 — 레벨 2를 넘어선 생성을 비활성화할 것을 권장합니다. 레벨 3 기술의 한계 효용은 디버깅 가능성 (debuggability) 비용을 정당화하지 못합니다.
기술 사용을 계측(instrument)하십시오 — 어떤 기술이 실제로 호출되는지, 반대로 존재하지만 전혀 실행되지 않는 기술은 무엇인지 추적하십시오. 공격적으로 가지치기(prune)하십시오. 사용되지 않고 방치된 기술은 맥박이 뛰고 있는 기술 부채 (technical debt)와 같습니다.
한 달에 한 번은 직접 기술을 작성하십시오 — 근육 기억 (muscle memory)을 유지하십시오. AI의 도움 없이 기술을 작성하는 방법을 기억하지 못한다면, 당신은 이미 AI가 생성한 버전이 올바른지 평가할 능력을 상실한 것입니다.
생성하기 전에 "완료"의 정의를 내리십시오 — 작성하는 모든 메타 기술 (meta-skill)에 대해, 무엇이 성공이고 무엇이 실패인지를 명시적으로 문서화하십시오. 이것이 없다면 에이전트는 잘못된 목표를 향해 최적화할 것이며, 기술 트리가 알아볼 수 없을 정도로 변할 때까지 당신은 이를 알아차리지 못할 것입니다.

당신의 의견은 어떠신가요?

귀하의 팀은 자기 전파적 에이전트 패턴 (self-propagating agent patterns)을 실험해 본 적이 있나요? 귀하의 환경에서는 어떤 제약 조건이 효과적이었으며, 혹은 실패했나요? 실제 현장에서 무엇을 목격하고 계신지 정말 듣고 싶습니다.

아래에 댓글을 남겨주세요 — 모든 댓글에 답변해 드립니다.

연구 출처: Qiita (일본 최대 개발자 커뮤니티), 자율 AI 에이전트 프레임워크에 관한 트렌딩 게시물

토론: AI 기술 생성 (AI skill generation)에 대한 귀하의 경험은 어떠신가요? 효율성 이득을 확보하면서도 능력 확장 (capability creep)을 방지할 수 있는 효과적인 제약 조건을 찾으셨나요?