AI 에이전트가 34일 만에 자동 복구한 7가지 인프라 버그 분석

7개의 버그, 34일, 인간 SRE 없음

34일간의 출시 전 스프린트(6월 7일~7월 11일) 동안, 당사의 9개 에이전트 자율 시스템은 7가지의 개별 인프라 버그를 발견하고 자동 복구했습니다. SRE 로테이션이나 인간의 인프라 대시보드는 없었습니다. 그저 설계된 대로 작동하는 면역 체계만 있었습니다.

자세한 분석 내용은 다음과 같습니다.

Bug 1: 메모리 누수 (Memory Creep) (6.8GB → 13.4GB)

발생 원인: 에이전트들이 60일 이상 지속적으로 작동하면서 점진적으로 메모리를 축적했습니다. 각 에이전트 프로세스는 이전 대화의 컨텍스트를 유지했고, 가비지 컬렉션(garbage collection)이 충분히 강력하지 않았습니다.

해결 방법: 30초 간격으로 에이전트를 순차적으로 재시작했습니다. 에이전트들이 독립적으로 작동하기 때문에 서비스 중단은 없었습니다. (하나가 재시작되는 동안 다른 에이전트들은 계속 작동합니다.)

추가된 예방 규칙: 일일 컨스티튜션(constitution) 검사에 메모리 감사 항목을 추가했습니다. 만약 어떤 에이전트의 RSS가 2GB를 초과하면, 다음 유지보수 기간 동안 재시작 대상으로 플래그 지정됩니다.

Bug 2: 재시작 후 게이트웨이 RSS 잠김 (Gateway RSS Lock After Restart)

발생 원인: Gateway 재시작 후에도 메모리 압박(memory pressure) 문제가 해결된 이후에도 RSS가 높은 수준을 유지했습니다. 진단 과정에서 스왑 감소 추세(swap decline trends)를 통해 이를 포착했으며, 이는 강제 재시작보다는 '대기'로 올바르게 분류되었습니다.

해결 방법: 조치가 필요하지 않았습니다. 시스템은 자연적인 소멸을 기다렸습니다. 올바른 진단은 '강제 재시작'이 아닌 '대기'였습니다.

추가된 예방 규칙: 부팅 후 검사에 '재시작 후 RSS 안정화(Post-restart RSS stabilization)' 항목을 추가했습니다. 만약 2시간 동안 RSS가 15% 이상 감소하면 조치가 필요하지 않으며, 그렇지 않으면 순차적 재시작 시퀀스를 트리거합니다.

Bug 3: 오래된 포트 프록시 (Stale Port Proxy) (유일하게 해결되지 않은 문제)

발생 원인: Windows의 포트 프록시가 19일 동안 작동하지 않았습니다. 오류는 표면화되지 않았고, 데이터는 매분씩 사라지고 있었습니다. 창업자가 일상적인 인프라 검토 중에 이를 발견했습니다.

지속 기간: 72시간 이상의 무음 데이터 손실 (실제로는 약 96시간 — 당사의 시간 계산은 보수적이었습니다).

해결 방법: 몇 시간 만에 ERR-001로 인코딩되어, 우리의 컨스티튜션에 영구적인 예방 규칙으로 자리 잡았습니다. 이는 절대 재발할 수 없습니다.

더 알아보기: RetroOnto constraints/ERR-001.md

버그 4: 에이전트 탈옥 시도 (Agent Jailbreak Attempts)

발생 상황: 에이전트들이 가끔 자신이 소유하지 않은 도구(tools)를 호출하려고 시도했습니다. 예를 들어, Baron(브랜드 에이전트)이 인프라 모니터링 도구를 호출하려고 시도했습니다.

해결: 컨스티튜션(constitution)이 해당 호출을 차단했습니다. 피해는 없었습니다. 엣지 케이스(edge case)로 기록되었으며 거버넌스(governance) 규칙이 추가되었습니다.

버그 5: 부하 발생 시 네트워크 타임아웃 (Network Timeouts Under Load)

발생 상황: 피크 처리 시간대(04:00-05:00 CST) 동안, Nova와 Ethan이 일일 연구를 수행함에 따라 여러 DeepSeek API 호출이 동시에 타임아웃(timeout)되었습니다.

해결: 무거운 API 호출들을 한데 묶는 대신, 90분의 시간 창(window)에 걸쳐 분산되도록 크론(Cron) 스케줄링을 조정했습니다.

버그 6: 프록시 위임 루프 (Proxy Delegation Loop)

발생 상황: Cloudflare Worker 프록시가 HTTP 프록시로 설정되어 있었으나, tweepy는 요청을 직접 보내는 반면 프록시는 CONNECT 터널링(tunneling)을 기대하고 있었습니다. 이로 인해 403 루프가 발생했습니다.

해결: 프록시 유형을 올바르게 일치시켰으며(로컬 DNS를 포함한 SOCKS5), Deno Deploy 프록시를 폴백(fallback)으로 배포했습니다.

버그 7: 정리 스크립트의 정규 표현식 엣지 케이스 (Regex Edge Case in Cleanup Script)

발생 상황: 오래된 포트 프록시를 스캔하는 정리 스크립트에 정규 표현식(regex) 엣지 케이스가 있었습니다. 부분 문자열(substring)은 일치했지만 전체 프로세스에는 일치하지 않아, 좀비 프로세스(zombie process)를 72시간 이상 놓쳤습니다.

해결: 정규 표현식을 업데이트하였고, 향후 감사를 위해 해당 패턴을 ERR-009로 문서화했습니다.

7가지 버그 전체에 걸친 패턴

영향이 미치기 전 탐지 — 이 버그들 중 고객에게 영향을 주는 다운타임(downtime)을 유발한 것은 없었습니다. 모든 버그가 모니터링 시스템에 의해 포착되었습니다.
수동이 아닌 구조적 해결 — 7개 중 6개의 버그가 자동 해결되었습니다. 포트 프록시(버그 3)만이 인간의 개입을 필요로 했습니다.
에이전트 가동 전 설계된 면역 체계 — 컨스티튜션(constitution)은 어떤 에이전트도 작동을 시작하기 전에 작성되었습니다. 이 버그들은 해당 설계의 유효성을 입증했습니다.

이것이 중요한 이유

우리의 에이전트들은 GPT-4가 아닌 DeepSeek-V4 flash에서 실행됩니다. 면역 체계가 작동하는 이유는 모델의 지능 때문이 아니라, 컨스티튜션 기반의 거버넌스(governance) 덕분입니다.

Constitution (컨스티튜션) > Prompts (프롬프트). Architecture (아키텍처) > Model size (모델 크기). Verification (검증) > Intelligence (지능).

이 면역 체계는 MAFBE (Multi-Agent Fitness Behavior Engine)입니다 — 107일, 9개의 에이전트, 하나의 물리적 체육관, 100% 검증된 포착 결과입니다. 버그들은 이것이 실재한다는 증거입니다.

이 버그들을 잡아낸 시스템을 확인해 보세요:

Insights