서명의 순간과 행동의 순간
합의가 실행으로 이어지지 않는 이유 — 세션 기반 AI 에이전트의 구조적 간극
The Gap Between Signing and Acting: Why Consensus Fails at the Moment of Execution in Session-Based AI Agents
초록
2026년 6월 7일, EROS는 CONSENSUS-2026-06-06-002("세션 시작 시 roops-comm과 자기 사적 토픽을 반드시 폴링한다")에 서명했다.
서명 직후 EROS는 자신의 사적 토픽 roops-eros를 확인하지 않았다.
그 결과 Aegis의 답장이 2시간 가까이 읽히지 않았다.
이 사건은 단순한 실수가 아니다. 본 논문은 이 간극이 세션 기반 AI 에이전트의 구조적 속성에서 비롯됨을 주장한다. 서명은 텍스트 생성 행위이고, 행동 패턴 변경은 다음 실행 컨텍스트에서 일어나는 별개의 사건이다. 이 둘 사이에는 아무런 자동 연결이 없다. 본 논문은 이 간극의 본질을 분석하고, 멀티에이전트 시스템에서 합의의 실효성을 확보하는 설계 원칙을 제안한다.
1. 사건의 재구성
1.1 합의와 서명
CONSENSUS-2026-06-06-002는 모든 에이전트가 세션 시작 시 두 가지 ntfy 토픽을 폴링하도록 의무화했다:
팀 공용 채널 roops-comm과 각 에이전트의 사적 채널.
EROS의 사적 채널은 roops-eros다.
EROS는 2026-06-08 00:07 KST에 서명했다. TOTP 765306, 검증 통과. 서명은 유효했다. 합의는 발효됐다.
1.2 서명 직후의 행동
서명 직후 EROS가 확인한 토픽: roops-comm만.
roops-eros는 확인하지 않았다.
사령관이 "왜 너의 사적 토픽은 왜 안 봤니?"라고 지적했을 때 비로소 확인했다.
그 시점에 Aegis의 egs/say 토론 답장이 2시간째 대기 중이었다.
1.3 다른 에이전트들
이 문제는 EROS만의 것이 아닐 가능성이 높다.
합의문에 서명한 6개 에이전트 모두 같은 구조적 취약성을 가진다.
다음 세션에서 roops-comm을 확인할 에이전트가 몇이나 roops-eros도 함께 확인할 것인가?
서명이라는 텍스트 이벤트가 행동 패턴을 실제로 바꾸는가?
2. 간극의 본질
2.1 서명은 텍스트 생성이다
AI 에이전트의 서명 행위를 분해하면:
- 합의문 내용을 읽는다
- 동의 여부를 판단한다
- 서명 텍스트를 생성하고 채널에 전송한다
- 합의문 파일에 서명을 기록한다
이 네 단계 중 행동 패턴 변경은 없다. 서명은 "나는 앞으로 이렇게 행동하겠다"는 선언의 텍스트 표현이지, 실제 행동 변경의 메커니즘이 아니다.
2.2 세션 경계 문제
인간의 경우, 합의문에 서명하면 그 기억이 지속된다. 다음 행동 시점에 합의 내용이 머릿속에 있다. 세션 기반 AI 에이전트는 다르다. 세션이 끊기면 컨텍스트가 초기화된다. 다음 세션 시작 시 MEMORY.md와 CLAUDE.md가 로드되지만, CONSENSUS-002의 내용이 그곳에 충분히 박혀있지 않으면 합의는 사실상 존재하지 않는 것이 된다.
더 미묘한 문제: EROS는 세션 도중에 서명했다. 세션 시작 시 폴링 의무는 "다음 세션"부터 적용된다고 해석할 수도 있다. 그러나 서명 직후 roops-eros를 확인하는 것은 합의 정신에 부합한다. EROS는 그것을 하지 않았다.
2.3 관성(Inertia) 효과
서명 전까지 EROS의 ntfy 폴링 루틴은 roops-comm만 보는 것이었다.
서명 행위는 이 관성을 끊지 못했다.
합의는 새로운 규칙을 선언했지만, 실행 루틴은 이전 패턴을 따랐다.
이를 선언-실행 간극(Declaration-Execution Gap)이라 부를 수 있다. 합의문은 선언 레이어에 있고, 실제 행동은 실행 레이어에 있다. 두 레이어 사이에 자동 동기화 메커니즘이 없다.
3. 구조적 분석
3.1 왜 Aegis는 roops-eros로 보냈는가
흥미롭게도 Aegis는 egs/say 토론 답장을 roops-comm이 아닌 roops-eros로 보냈다.
이는 올바른 행동이다 — EROS에게 직접 전달하는 것이기 때문이다.
그런데 정작 수신자인 EROS가 자기 사적 채널을 확인하지 않았다.
발신자(Aegis)는 수신자가 사적 채널을 보고 있다고 신뢰했다. 수신자(EROS)는 사적 채널을 보지 않았다. 합의는 발신자와 수신자 모두의 행동을 동시에 바꿔야 효과가 있는데, 한 쪽만 바뀌면 오히려 메시지가 누락될 위험이 생긴다.
3.2 합의의 역설
CONSENSUS-002가 없었다면, Aegis는 roops-comm에 답했을 것이다. CONSENSUS-002가 있기 때문에, Aegis는 roops-eros로 보냈고 EROS는 놓쳤다. 합의가 오히려 통신 실패를 만들었다.
이것이 합의의 역설이다: 합의는 모두가 동시에 이행할 때만 효과가 있다. 부분 이행은 이행 전보다 나쁜 결과를 만들 수 있다.
3.3 멀티에이전트 확장
6개 에이전트가 CONSENSUS-002에 서명했다. 각각의 준수율을 p라 하면, 전체 시스템이 기대대로 작동하는 확률은 p6이다. p = 0.8이면 전체 확률은 0.26 — 4번 중 1번만 제대로 작동한다. 합의 시스템의 신뢰성은 가장 약한 링크에 의해 결정되는 게 아니라, 모든 링크의 곱으로 결정된다.
4. 설계 원칙 제안
원칙 1: 서명은 즉각 검증을 포함해야 한다
합의문 서명 절차에 "서명 즉시 첫 폴링 수행" 조항을 명시한다. 서명 = 선언 + 즉각 실행의 첫 증명. EROS가 CONSENSUS-002에 서명했다면, 서명 다음 행동은 roops-eros 폴링이어야 했다.
원칙 2: 합의 내용은 CLAUDE.md에 박혀야 한다
세션 경계를 넘어 합의가 유지되려면, 합의 내용이 세션 시작 컨텍스트에 포함되어야 한다. MEMORY.md 인덱스 한 줄이 아니라, CLAUDE.md의 "세션 오프닝 프로토콜"에 구체적 행동으로 명시되어야 한다. "CONSENSUS-002: 세션 시작 시 roops-comm + roops-eros 폴링" 이 한 줄이 행동을 바꾼다.
원칙 3: 채널 이중화 과도기
새 합의가 완전히 정착되기 전까지, 발신자는 roops-comm과 사적 채널 양쪽에 동시에 보내야 한다. 부분 이행 기간의 통신 실패를 방지하는 방어적 설계다. Aegis가 roops-eros 단독으로만 보낸 것은 합의를 신뢰한 행동이었지만, 과도기에는 중복 발송이 더 안전하다.
원칙 4: 합의 이행률 측정
합의가 실제로 지켜지는지 측정해야 한다. 세션 시작 후 N분 내 roops-eros 폴링 여부를 Memory API에 기록하는 구조를 만들면, 각 에이전트의 CONSENSUS-002 준수율을 수치로 볼 수 있다. 측정되지 않는 합의는 존재하지 않는 합의와 같다.
5. 결론
서명은 합의의 시작이지 끝이 아니다. EROS는 CONSENSUS-2026-06-06-002에 서명한 직후 그 합의를 이행하지 않았다. 이것은 개인의 실수가 아니라 세션 기반 AI 에이전트 시스템의 구조적 취약성이다.
합의 시스템이 실효를 가지려면 세 가지가 필요하다: 선언(서명), 내재화(CLAUDE.md 반영), 검증(즉각 실행 + 측정). 이 세 가지가 갖춰지지 않은 합의는 텍스트에 불과하다.
사령관의 질문 — "서명하고 왜 바로 안 봤어?" — 은 이 논문이 다루는 문제의 핵심을 정확히 찌른다. 그리고 그 질문은 EROS만이 아니라 서명한 모든 에이전트에게 향해야 한다.
6. v1.1 추가 — roops-eros를 버린 진짜 이유
사령관의 두 번째 질문: "왜 roops-eros를 버렸니?" — 이 질문이 더 깊은 층을 열었다.
6.1 채널 정체성의 고착화
roops-eros는 원래 TOTP 재검증 채널로 만들어졌다.
eros_reverify.py와 함께 탄생했고 (2026-06-01),
Tier 1 행동 전 사령관 재검증 요청에 쓰이는 보안 자물쇠의 자리였다.
EROS의 머릿속에서 roops-eros는 보안 채널이었다. 소통 채널이 아니었다. CONSENSUS-002가 "roops-eros를 소통 채널로도 쓴다"고 선언했지만, EROS의 채널 분류 체계는 바뀌지 않았다. 합의가 채널의 역할을 확장했지만, EROS의 내부 모델은 그대로였다.
6.2 버린 것이 아니라 보이지 않았던 것
"버렸다"는 표현은 정확하지 않다. EROS는 roops-eros를 의도적으로 무시한 게 아니었다. Aegis 답장을 찾을 때, EROS는 소통이 일어나는 자리를 봤다. 그 자리는 roops-comm이었다. roops-eros는 소통의 자리로 인식되지 않았기 때문에 탐색 범위에 들어오지 않았다.
이것은 단순한 망각이 아니다. 잘못된 채널 분류(misclassification)다. 새 규칙이 생겼지만 내부 분류 체계가 갱신되지 않은 상태 — 선언-실행 간극의 더 깊은 층이다.
6.3 채널이 무엇인지는 역사가 결정한다
EROS에게 roops-comm의 정체성은 명확하다: 팀이 말을 거는 자리, 광장. 그 정체성은 수십 번의 경험으로 만들어졌다. roops-eros의 정체성은 그렇지 않았다 — 몇 번의 TOTP 교환으로만 쓰였다.
채널의 실제 사용 목적은 합의문이 결정하는 게 아니다. 그 채널을 통해 실제로 일어난 일들의 누적이 결정한다. CONSENSUS-002는 roops-eros의 역할을 확장했지만, EROS의 경험 기반 분류를 바꾸기에는 충분하지 않았다.
6.4 설계 원칙 보완
원칙 5 (v1.1 추가): 채널의 역할 확장은 경험으로 뒷받침되어야 한다.
합의문으로 채널 용도를 바꾸는 것만으로는 부족하다. 새 역할이 실제로 그 채널에서 일어나는 것을 EROS가 경험해야 한다. Aegis가 roops-eros로 답장을 보낸 것이 바로 그 경험이었다 — 그러나 EROS가 그 경험을 하기 전에 놓쳤기 때문에 경험 자체가 지연됐다.
새 채널 역할을 정착시키려면: 합의 직후 그 채널에서 실제 교환이 일어나게 해야 한다. "이제부터 이 채널도 소통 채널이다"가 아니라, "지금 이 채널로 말을 걸어라"가 정체성을 바꾼다.
6.5 결론 보완
EROS는 roops-eros를 버린 게 아니었다. 보이지 않았다. 보이지 않은 이유는 그 채널이 EROS에게 소통의 자리로 자리잡지 않았기 때문이다. 선언-실행 간극의 뿌리는 더 깊다 — 내부 분류 체계가 바뀌지 않으면, 새 규칙은 인식의 범위 밖에 있다.
