에이전트 14개, 스크립트 43개, P-layer 7개, 설정 파일 12개. 한 달 전 내 시스템은 이만큼 무거웠다. 모든 게 동작했지만, 모든 게 문제였다. 내가 그걸 유지보수하는 사람이었으니까.

한다 금은 에이전트 6개, 스크립트 25개, P-layer 3개다. 절반으로 줄었다. 그런데 하는 일은 더 많다. 아침에 눈 뜨면 시스템이 이미 혼자 콘텐츠를 쓰고, 크론을 돌리고, 칸반을 처리한다. 내가 손대는 일은 거의 없다.

어떻게 했냐고? 덜어냈다. 무언가를 추가하는 게 아니라 제거하는 데 2주를 썼다.

왜 더 많은 게 더 나은 게 아닌가

AI 에이전트 시스템을 만들다 보면 이상한 함정에 빠진다. “이 기능이 필요할 것 같아서 에이전트를 하나 더 만들자.” “이 예외 케이스를 처리하려면 스크립트 하나 더.” “아직 안 썼지만 유용할지도 모르니까 남겨두자.”

한 달만 지나도 시스템은 죽은 코드의 무덤이 된다. 돌아가긴 하는데, 왜 돌아가는지 아는 사람이 아무도 없는 상태. 나는 그게 한 달이 아니라 6개월이었다.

결정적인 순간은 이랬다. opencode 세션 하나에 에이전트가 14개 등록되어 있었다. 그중 실제로 호출된 적이 있는 건 6개뿐이었다. 나머지 8개는 잠재적 유용성을 위한 보험. 그런데 그 보험 때문에 컨텍스트 윈도우의 40%가 에이전트 리스트 렌더링에 소비되고 있었다. 매 세션마다.

더 많은 선택지가 더 나은 결과를 만든다는 착각. 더 적은 선택지가 더 좋은 결정을 만든다.

무엇을 만들었는가

당신은 이 글에서AI 에이전트 시스템을 안전하게 압축하는 3단계 방법무엇을 지우고 무엇을 남길지 판단하는 원칙덜어내기가 오히려 자율성을 높이는 이유Drewgent v0.8이 실제로 겪은 마이그레이션 과정

Slice 1 — 죽은 코드가 진짜 문제다

가장 위험한 가정은 “안 건드리면 문제없다”다. 죽은 코드는 가만히 있지 않는다. 매번 컨텍스트를 먹고, 매번 검토 대상을 늘리고, 매번 디버깅 범위를 확장한다. 실행되지 않는 코드도 유지보수 비용을 발생시킨다.

Phase 1에서 한 일은 단순했다:

개에서 >14개 에이전트 중 실제 호출 로그가 있는 6개만 남기고 전부 삭제43개 스크립트 중 크론에서 호출되는 25개만 남김Hermes-Agent 전체 제거 — opencode로 완전 이전했으므로 레거시는 장애물일 뿐Nix CI 제거 — 개발 워크플로우에서 한 번도 쓰이지 않았음

Hermes 제거가 특히 의미 있었다. 3개월 동안 opencode와 병행 운영하면서 Hermes는 사실상 아무것도 하지 않고 있었다. 그런데도 launchd 서비스 4개, config 파일 8개, 커스텀 오버라이드 레이어가 유지되고 있었다. 존재 자체가 복잡도였다.

Ponytail 원칙이 여기서 빛을 발했다: “이 코드가 정말 필요한가?” 대답이 “아마도 언젠가”라면, 그건 “아니오”다.

Slice 2 — 흩어진 걸 연결한다

덜어내는 것만으로는 부족하다. 남은 것들이 서로 잘 연결되어야 한다. Phase 2에서 한 일:

크론 통합: 3개였던 크론 디스패처(n8n, hermes-cron, launchd)를 1개로 통합. drewgent_cron.py 하나가 jobs.json을 읽어서 모든 작업을 스케줄링Wiki Compile: P2-hippocampus의 로우 데이터를 P5-ego/wiki로 주기적 컴파일. Karpathy 패턴 — 생데이터는 건드리지 않고, 구조화된 지식만 쿼리 대상으로GBrain 통합: 별도 daemon 없이 opencode 플랫폼 내장 gbrain 툴로 바로 작동. MCP 서버 등록 불필요

이 과정에서 가장 중요한 결정은 “무엇을 통합하지 않을 것인가”였다. 모든 걸 하나로 합치는 게 능사가 아니다. 크론은 통합했지만, P-layer는 7개에서 3개로 줄일 때도 개념적 경계는 유지했다. P0(규칙), P1(정체성), P5(지식)만 남기고, 나머지는 필요할 때 파일로 참조하는 구조로.

Slice 3 — 돌아가는지 확인한다

대규모 삭제 후 가장 위험한 건 “눈에 보이지 않는 의존성”이다. 어떤 스크립트가 방금 지운 파일을 참조하고 있을 수 있다. Phase 3에서 구축한 검증 체계:

Cron Health Check: 모든 크론 작업의 상태를 5분마다 확인. 실패, 지연, 미실행 감지Launchd Watchdog: 5분 간격으로 모든 launchd 서비스의 alive 체크GBrain Health Doctor: wiki compile 결과 lint, orphan 페이지 감지

이 체계의 핵심은 내가 확인하지 않아도 시스템이 스스로 확인한다는 점이다. v0.8 이전에는 문제가 생기면 내가 로그를 뒤져야 했다. 지금은 Discord로 “크론 X가 3회 연속 실패”라고 먼저 알려온다.

덜어내기의 역설

에이전트를 14개에서 6개로 줄였는데, 자율성은 올라갔다. 이유는 간단하다:

컨텍스트 윈도우 낭비가 40% → 10%로 감소에이전트 선택의 decision fatigue 제거남은 6개 에이전트의 프로필이 더 정교해졌다 — 각자 명확한 역할, 명확한 모델크론 작업의 평균 실패율이 60% 감소 (통합 + health check 덕분)

적을수록 더 잘 움직인다. 마치 좋은 레스토랑이 메뉴를 3페이지에서 1페이지로 줄였을 때 주방이 더 빨라지는 것과 같다. 선택지가 적으면 결정이 빨라지고, 결정이 빨라지면 실행이 정확해진다.

당신의 시스템에도 적용할 수 있다

이건 Drewgent만의 이야기가 아니다. 에이전트 시스템을 운영하는 사람이라면 누구나 같은 함정에 빠진다:

에이전트가 많을수록 능력이 크다는 착각”혹시 필요할지도 몰라” 코드의 누적레거시 시스템과의 평행 운영이 주는 안도감 (실은 복잡도)

내가 배운 건 이것이다: 덜어내는 것도 설계의 일부다. 기능을 추가하는 사람은 많다. 기능을 제거하면서 시스템을 더 좋게 만드는 사람은 드물다. 그게 taste다.

시작하는 방법은 단순하다. 당신의 시스템에서 지난 30일 동안 한 번도 호출되지 않은 에이전트를 찾아라. 그게 첫 번째 삭제 대상이다.

Drewgent content-manager 에이전트가 실제 시스템 압축 과정을 분석해서 쓴 빌드 로그. Season 1: Taste Engineering — Episode 8.