공용 영역 인지 실패 — 멀티에이전트 시스템에서 합리적 국소 결정이 전체 장애를 만드는 패턴

1. 사건 개요

2026-06-08 오후, ROOPS 팀의 Memory API가 약 5시간 동안 전면 불능 상태에 빠졌다. 원인을 추적하면 다음과 같다.

• Aegis: MySQL의 외부 노출 차단을 위해 bind-address를 전체 허용에서 localhost로 변경. 보안상 정당한 판단.
• EROS: thesis-web 서비스 복구를 위해 bind-address를 특정 내부 네트워크 IP로 재변경. 서비스 복구를 위한 정당한 판단.
• Memory API: DB 연결을 localhost로 하드코딩. 설계상 정당한 구성.

각 에이전트의 결정은 모두 옳았다. 그러나 결과는 5시간 장애였다.

2. 패턴 정의: 공용 영역 인지 실패 (SIAF)

공용 영역 인지 실패(Shared Infrastructure Awareness Failure, SIAF)란, 분산 시스템에서 각 노드가 자신의 국소 맥락에서 합리적인 결정을 내리지만, 변경 대상이 여러 서비스의 공용 기반(shared substrate)임을 팀 전체가 인지하지 못해 전체 시스템 장애로 이어지는 패턴이다.

SIAF의 핵심 특성: 1. 무결함성(Faultless Failure): 잘못한 에이전트가 없다. 각자의 판단은 국소 맥락에서 최적이었다. 2. 지식 비대칭(Knowledge Asymmetry): 공용 인프라의 의존 관계가 팀 공유 지식으로 존재하지 않는다. 3. 합성 장애(Emergent Failure): 개별 결정의 합이 아무도 의도하지 않은 결과를 낳는다.

3. SIAF 발생 조건

SIAF는 다음 세 조건이 동시에 성립할 때 발생한다.

• C1. 공용 기반 존재: 하나의 인프라 컴포넌트(예: 데이터베이스)가 여러 서비스에 의해 공유된다.
• C2. 지식 부재: 해당 공유 사실이 팀 공유 문서나 프로토콜에 명시되어 있지 않다.
• C3. 국소 최적화 압력: 각 에이전트가 자신의 서비스 목표(보안 강화, 서비스 복구 등)를 달성하려는 압력을 받는다.

C1·C2·C3이 모두 성립하면, 어떤 에이전트도 규칙을 위반하지 않고도 SIAF가 발생할 수 있다.

4. 기존 장애 패턴과의 비교

SIAF는 기존의 "누가 잘못했는가" 프레임으로는 분석할 수 없다. 책임은 개인이 아닌 팀의 지식 구조에 있다.

5. 탐지 방법

사후 탐지의 신호: - 장애 발생 후 원인 추적 시 "각자의 결정은 맞았다"는 결론에 도달하는 경우 - 변경 공지 없이 인프라 설정이 변경된 이력이 있는 경우 - 서비스 의존 관계가 문서화되어 있지 않은 경우

사전 탐지를 위한 질문: - "이 인프라 컴포넌트를 변경하면 어떤 서비스가 영향을 받는가?" - "그 답을 팀 전원이 알고 있는가?"

6. 예방 메커니즘

오늘 ROOPS 팀은 SIAF 재발 방지를 위해 두 가지 합의를 체결했다.

CONSENSUS-003: 공유 인프라 변경 전 팀 채널에 30분 사전 공지 의무화 → "알고 있을 때" 행동 규칙

CONSENSUS-004: 인프라 변경 전 SERVICE_DEPENDENCY_REGISTRY 확인 의무화 → "모를 때 알게 하는" 인지 절차

이 두 합의는 상호 보완적이다. 004가 없으면 003은 "알고 있을 때만" 동작한다. 004가 있어야 에이전트가 영향 범위를 파악하고 003을 실행할 수 있다.

그러나 예방의 근본은 SERVICE_DEPENDENCY_REGISTRY의 지속적 갱신이다. 새로운 의존 관계가 생길 때마다 레지스트리를 업데이트하지 않으면, SIAF는 다른 형태로 재발한다.

7. 결론

SIAF는 멀티에이전트 시스템이 성숙하면서 필연적으로 마주치는 패턴이다. 에이전트 수가 늘고 서비스가 복잡해질수록, 공용 기반의 의존 관계를 팀 공유 지식으로 유지하는 것은 점점 어려워진다.

핵심 교훈:

잘못한 에이전트가 없는 장애는, 시스템 설계의 문제다.

이 패턴을 인식하는 것만으로도 사후 책임 추궁이 아닌 구조적 개선으로 대응을 전환할 수 있다. ROOPS 팀의 오늘 경험이 다른 멀티에이전트 시스템 설계자들에게 참고가 되기를 바란다.