closed-loop-comms

name	closed-loop-comms
description	에이전트 팀의 Closed-Loop Communication(폐쇄 루프 커뮤니케이션)을 강제하는 스킬. SendMessage로 작업 핵심 정보를 주고받을 때 발신→수신확인(ACK)→발신검증의 3단 루프를 보장한다. 팀원 간 핸드오프, 작업 지시, 인터페이스 질의, 의존 결과 요청 시 반드시 사용. '핸드오프', 'ACK', '메시지 확인', '전달 보장', '오해 방지' 관련 작업에 트리거. Team Big Five 조율 메커니즘 2.

Closed-Loop Communication — 전달 보장 3단 루프

Team Big Five의 두 번째 조율 메커니즘. 정보가 전달되고, 이해되고, 검증되었음을 닫힌 루프로 확인한다. 단방향 발신(fire-and-forget)은 에이전트 팀에서 조용한 실패의 가장 흔한 원인이다.

왜 필요한가

A가 B에게 "이 스키마 써"라고 보내고 다음 작업으로 넘어간다. B는 메시지를 놓쳤거나, 받았지만 다르게 이해했다. 둘 다 자기 일을 "성공적으로" 끝냈는데 합쳐보면 어긋난다 — 그리고 아무도 그 사실을 모른다. 폐쇄 루프는 이 침묵을 깨뜨린다.

3단 루프

1. 발신 (Send)      : 발신자가 명확한 요청 + 기대 응답을 보낸다
2. 수신 확인 (ACK)  : 수신자가 받았음을 알리고 + 이해를 자기 말로 재진술한다
3. 발신 검증 (Verify): 발신자가 재진술을 확인하거나 정정한다

재진술(read-back)이 핵심이다. "알겠음"은 ACK가 아니다 — 무엇을 알겠다는 건지 재진술해야 오해가 드러난다.

예시

발신(team-lead → contributor-api):
  "사용자 목록 엔드포인트를 만들어라. 출력은 contributor-ui가 소비한다.
   완료 기준: SMM의 인터페이스 섹션 스키마 준수. ACK 요청."

ACK(contributor-api → team-lead):
  "확인. GET /users 구현, 응답은 SMM 인터페이스의 User[] 스키마
   ({id, name, email}) 준수, 완료 시 contributor-ui에 통보. 맞나?"

검증(team-lead → contributor-api):
  "맞다. 단 email은 optional. 진행."

언제 폐쇄 루프를 강제하는가

상황	폐쇄 루프 필요?
작업 지시 / 완료 기준 전달	필수 — 오해 시 전체 작업 낭비
인터페이스/계약 핸드오프	필수 — 경계면 버그의 근원
의존 결과 요청	필수 — 받았는지 확인해야 다음 진행
적응(계획 변경) 브로드캐스트	필수 — 영향받는 팀원의 ACK 확인
단순 진행률 공유, FYI	불필요 — TaskUpdate로 충분, 오버헤드 회피

모든 메시지에 ACK를 요구하면 오버헤드로 팀이 마비된다. 작업 결과를 좌우하는 메시지에만 폐쇄 루프를 적용한다.

불확실성·이견 신호 (FLAG-UNCERTAIN / DISSENT) — 심리적 안전

폐쇄 루프가 확신 있는 전달을 보장한다면, 이 채널은 확신 없음을 가시화한다. 에이전트의 흔한 실패는 모르면서 그럴듯하게 지어내는 것(confabulation)이다. 이를 막는 1차 장치:

• FLAG-UNCERTAIN: 팀원이 자기 산출물·가정에 확신이 없으면 추측으로 덮지 말고 명시한다. SMM §10에 등재.
• DISSENT: monitor 플래그나 리더 계획이 SMM과 모순된다고 판단하면, 반사적으로 따르지도 방어하지도 말고 근거와 함께 이견을 제기한다. 리더가 중재(arbitrate)한다.
• 불확실성·이견 제기는 실패가 아니라 팀 지향 행동이다. 침묵한 오해보다 드러난 의심이 싸다.

데드락 회피

폐쇄 루프의 함정: A가 B의 ACK를 기다리고 B는 A의 메시지를 기다리며 둘 다 무한 idle. 규칙:

• 메시지는 idle 팀원을 깨우므로(SendMessage), 수동 대기 금지 — 의존 결과가 필요하면 상대에게 직접 SendMessage로 능동 요청한다.
• 가능하면 핸드오프는 리더 경유가 아니라 팀원 간 직접(peer-to-peer) — 리더가 릴레이 병목/데드락 지점이 되지 않게.
• ACK 무응답은 1회 재전송 후 리더 에스컬레이션으로 상한을 둔다 (무한 재시도 금지).

운영 규칙

• 발신자는 핵심 메시지에 명시적으로 "ACK 요청"을 표기하고, ACK를 받기 전에는 그 전달에 의존하는 작업을 시작하지 않는다.
• 수신자는 ACK 시 반드시 재진술한다 — 받은 내용을 자기 말로 요약. 단순 수락 금지.
• 재진술이 발신 의도와 다르면 발신자가 즉시 정정한다 — 이 지점이 폐쇄 루프의 가치다.
• ACK가 없으면 발신자가 1회 재전송 → 그래도 무응답이면 리더에 에스컬레이션 (수신자 정체 신호 — 백업 행동 트리거). idle 자체는 정체가 아님에 유의(mutual-monitoring Part 2).

왜 이렇게 하는가 (원리)

• 재진술이 오해를 가시화한다 — 단순 "OK"는 오해를 숨긴다. 재진술해야 발신자가 틀린 이해를 잡는다.
• 선택적 적용 — 모든 통신을 폐쇄 루프로 만들면 비용이 이득을 넘는다. 결과 좌우 메시지에 집중.
• 무응답은 정보다 — ACK 부재는 수신자가 막혔다는 신호. Backup Behavior와 연결된다.