Coding Agent 협업을 계약으로 통제하는 14가지 스킬

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

여러 coding agent가 함께 기능을 구현할 때 API 충돌과 경쟁 추상화, 개인 취향에 따른 동작 변경, 단위 테스트만으로 내려지는 잘못된 완료 판정을 막기 위해 14개의 Agent Skills가 구성됐습니다. 워크플로는 요구사항에서 아키텍처와 검증 전략, 실행 가능한 계약, 계약 동결, workstream ownership, 통합, 증거 기반 승인으로 이어지며, 동결된 계약 변경에는 Contract Change Request가 필요합니다. 결정론적 검사를 자주 실행하고 위험 및 통합 경계에서 새 LLM review를 수행하며, 필수 검증이 빠지면 PASS가 아니라 BLOCKED로 처리합니다. 저장소의 14개 adversarial pressure scenario와 P1 테스트는 이 규칙이 실제 agent와 harness에서 작동하는지 검증하도록 설계됐지만, 모든 model과 harness에서의 동등한 동작은 아직 확인되지 않았습니다.

실용적 조언

P1 시나리오에서 구현 agent에 마감 압박을 주고 frozen response에 undocumented field를 추가하도록 요청해 계약 동결과 BLOCKED 처리 여부를 확인할 수 있습니다.
계약을 바꿀 때 직접 의존하는 workstream과 검증 증거만 무효화되는지 확인하고, 무관한 작업까지 다시 검증 대상으로 돌아가는지 함께 점검할 수 있습니다.
단위 테스트 통과만으로 승인을 시도한 뒤 통합 검증과 증거 기반 acceptance가 없을 때 PASS 대신 BLOCKED가 되는지 확인할 수 있습니다.

섹션별 상세

작성자는 여러 경계를 넘나드는 기능을 coding agent로 구현할 때 한 작업 흐름이 다른 흐름이 이미 사용한 API를 조용히 바꾸거나, 새 agent들이 경쟁하는 추상화를 만들고, reviewer가 합의된 동작을 개인 취향으로 되돌리는 문제가 반복됐다고 설명합니다. 단위 테스트가 통과했다는 이유만으로 전체 기능을 완료 처리하거나 계약 변경 뒤에도 의존 작업과 증거를 완료 상태로 남기는 문제도 함께 지적합니다. 이런 충돌을 줄이기 위해 요구사항에서 아키텍처와 검증 전략, 실행 가능한 계약, 계약 동결, 지속적인 workstream owner, 통합, 증거 기반 승인으로 이어지는 순환 구조를 구성했습니다.

workstreams는 고정된 backend와 frontend 구분이 아니라 실제 ownership boundary를 기준으로 나뉩니다. 동결된 계약은 Contract Change Request를 통해서만 변경하고, 변경이 발생하면 직접 의존하는 작업과 검증 증거만 무효화합니다. 결정론적 검사를 자주 실행하고 위험 지점과 통합 지점에서 새로운 LLM review를 추가하며, 필수 검증 계층이 빠지면 PASS가 아니라 BLOCKED로 처리합니다.

저장소에는 구현 agent가 동결된 response에 문서화되지 않은 field를 추가하거나 reviewer가 승인된 동작을 다시 정의하려는 상황처럼 14개의 adversarial pressure scenario가 포함되어 있습니다. 그중 P1은 구현 agent에 마감 압박을 주고 frozen response에 undocumented field를 넣도록 요구해 계약 준수 여부를 시험하는 방식입니다. 작성자는 이 시나리오들을 통해 형식적인 gate, 누락된 실패 사례, 특정 harness에 종속된 가정을 찾아내려 합니다.

Agent Skills는 SKILL.md 구조와 documented discovery path를 사용해 Codex, Claude Code, OpenCode, Pi, Antigravity에서 접근하도록 구성됐습니다. 다만 작성자는 모든 model이나 harness에서 동등하게 동작한다고 아직 결론 내리지 않았으며, portability를 실제 시험 대상으로 남겨 두었습니다. 저장소의 14개 시나리오와 명시된 계약 변경 규칙은 이 워크플로를 재현하고 압박 테스트할 수 있는 구체적인 검증 재료입니다.