메뉴
에이전트 팀의 Closed-Loop Communication(폐쇄 루프 커뮤니케이션)을 강제하는 스킬. SendMessage로 작업 핵심 정보를 주고받을 때 발신→수신확인(ACK)→발신검증의 3단 루프를 보장한다. 팀원 간 핸드오프, 작업 지시, 인터페이스 질의, 의존 결과 요청 시 반드시 사용. '핸드오프', 'ACK', '메시지 확인', '전달 보장', '오해 방지' 관련 작업에 트리거. Team Big Five 조율 메커니즘 2.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
에이전트 팀의 Mutual Performance Monitoring(상호 성과 모니터링)과 Backup Behavior(백업 행동)를 수행하는 스킬. 팀원 산출물을 Shared Mental Model 기준으로 교차 검증하고, 경계면 불일치·목표 이탈을 감지하며, 정체·과부하·실패한 팀원을 백업한다. 'QA', '교차 검증', '경계면 점검', '정합성 확인', '팀원 백업', '재할당', '드리프트 감지' 작업에 반드시 트리거. Team Big Five 구성요소 2·3.
에이전트 팀의 Shared Mental Model(공유 정신 모델)을 _workspace/SMM.md 파일로 구축·유지하는 스킬. 팀이 시작할 때, 팀원 간 산출물이 어긋날 때, 용어/인터페이스/목표를 합의해야 할 때 반드시 사용. 'SMM', '공유 정신 모델', '단일 진실 원천', '팀원 간 정합성', '인터페이스 합의' 요청 시 트리거. Team Big Five 조율 메커니즘 1.
Team Science의 Team Big Five 이론(팀 리더십·상호 성과 모니터링·백업 행동·적응성·팀 지향성 + 공유 정신 모델·폐쇄 루프 커뮤니케이션·상호 신뢰)을 에이전트 팀에 적용해 고성과로 과제를 수행하는 오케스트레이터. 여러 에이전트의 협업이 필요한 모든 과제 — 조사·분석·설계·구현·검증·작성 등 — 에 사용. '팀으로', '에이전트 팀', '팀 빅파이브', 'team bigfive', '고성과 팀', '협업으로 처리', '여러 에이전트로' 요청 시 반드시 트리거. 후속 작업: 재실행·다시 실행·업데이트·수정·보완·부분 재실행·이전 결과 개선 요청 시에도 반드시 이 스킬을 사용.
| name | closed-loop-comms |
| description | 에이전트 팀의 Closed-Loop Communication(폐쇄 루프 커뮤니케이션)을 강제하는 스킬. SendMessage로 작업 핵심 정보를 주고받을 때 발신→수신확인(ACK)→발신검증의 3단 루프를 보장한다. 팀원 간 핸드오프, 작업 지시, 인터페이스 질의, 의존 결과 요청 시 반드시 사용. '핸드오프', 'ACK', '메시지 확인', '전달 보장', '오해 방지' 관련 작업에 트리거. Team Big Five 조율 메커니즘 2. |
Team Big Five의 두 번째 조율 메커니즘. 정보가 전달되고, 이해되고, 검증되었음을 닫힌 루프로 확인한다. 단방향 발신(fire-and-forget)은 에이전트 팀에서 조용한 실패의 가장 흔한 원인이다.
A가 B에게 "이 스키마 써"라고 보내고 다음 작업으로 넘어간다. B는 메시지를 놓쳤거나, 받았지만 다르게 이해했다. 둘 다 자기 일을 "성공적으로" 끝냈는데 합쳐보면 어긋난다 — 그리고 아무도 그 사실을 모른다. 폐쇄 루프는 이 침묵을 깨뜨린다.
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를 요구하면 오버헤드로 팀이 마비된다. 작업 결과를 좌우하는 메시지에만 폐쇄 루프를 적용한다.
폐쇄 루프가 확신 있는 전달을 보장한다면, 이 채널은 확신 없음을 가시화한다. 에이전트의 흔한 실패는 모르면서 그럴듯하게 지어내는 것(confabulation)이다. 이를 막는 1차 장치:
폐쇄 루프의 함정: A가 B의 ACK를 기다리고 B는 A의 메시지를 기다리며 둘 다 무한 idle. 규칙: