Simplifier Review — 단순화 검토

Complexity Measurement (v1.0.0 기준)

계산식: entities(4×1) + relationships(4×1.5) + constraints(9×0.5) + must(5×1) + unverified(5×2) = 4 + 6 + 4.5 + 5 + 10 = 29.5

Simplification Proposals

S-001: 장기 "배제 카테고리 없음" 클러스터 제거 (게임/임베디드)

• Target: C-05(불변 제약) + AC-07(May 인수 기준) + A-05(미검증 가정)
• Current (Before): v1부터 "cocode ADE는 어떤 소프트웨어 카테고리도 영구히 배제하지 않는다"를 불변 제약으로 선언하고, May 유형 인수 기준과 "Dart/Flutter+FFI로 만들지 못하는 소프트웨어는 없다"는 미검증 가정으로 뒷받침. 그러나 같은 스펙의 C-01은 이미 개발자 MVP 외 모든 것을 순연시킨 상태.
• Proposed (After): C-05·AC-07·A-05를 v1 Seed spec에서 제거. 이는 MVP 요구사항이 아니라 MVP 이후 포지셔닝 서술이며, 특정 카테고리(예: 게임)를 실제로 스코프에 넣는 시점에 실질적 검증과 함께 재도입한다.
• Complexity Change: constraints 9→8, unverified 5→4 · 29.5 → 27.0 (-2.5)
• Trade-off: "배제 카테고리 없음" 포지셔닝 서술과 그 근거가 문서에서 사라져, 훗날 게임/임베디드 지원을 재검토할 때 논거를 처음부터 다시 도출해야 한다. 위험은 낮다 — 해당 항목은 이미 "MVP 범위 아님"으로 표기됐고, Must가 아닌 May였으며, 가정 자체가 미검증이었다.
• Decision: Accept — Contrarian CH-013(Critical), CH-014, CH-015, CH-031, CH-036이 모두 같은 클러스터를 지목했고, 특히 CH-013은 "스스로 미검증이라 표시한 믿음을 불변 제약으로 잠그는 것"을 Critical로 판정. 제거가 그 Critical 반론의 직접 해소책이다.

S-002: 드리머 모드 운영 모델 가정 제거 (해당 모드 자체가 순연된 상태에서)

• Target: A-02(미검증 가정 — "도메인 전문가가 coco-de/skills로 제품화하고, 부족분은 코코드 팀이 채운다")
• Current (Before): C-01이 이미 드리머 모드 관련 작업 전체를 MVP 이후로 순연시켰는데도, 그 모드의 제품화 운영 모델에 관한 미검증 가정을 v1 스펙이 계속 안고 있음.
• Proposed (After): A-02를 v1 Seed spec에서 제거. 드리머 모드 기획을 실제로 시작하는 시점에 검증과 함께 재도입한다.
• Complexity Change: unverified -1 · S-001과 합산 시 5→3 · 단독 -2.0
• Trade-off: 알려진 미래 리스크(비개발자 제품화를 위한 skill 커버리지 격차)에 대한 조기 가시성을 잃는다. 위험은 낮다 — C-01이 이 영역을 현재 빌드 지평 밖으로 명시적으로 밀어냈고, v1의 어떤 인수 기준도 이 가정에 의존하지 않는다.
• Decision: Accept — Contrarian CH-028(Critical, "수용 한계·컷오프 없는 무한정 운영 부담")의 직접 해소책이다.

S-003: AgentBackend 엔티티를 DelegatedTask로 통합

• Target: AgentBackend 엔티티 및 DelegatedTask와의 "처리함" 관계
• Current (Before): AgentBackend가 독립 엔티티(backend_id, kind, provider)로 존재하면서 DelegatedTask와 관계선을 갖는데, 정작 DelegatedTask는 이미 agent_backend 속성으로 같은 agent/acp 구분을 표현하고 있음 — 동일 사실의 이중 기록.
• Proposed (After): AgentBackend를 1급 엔티티에서 제거. kind/provider를 DelegatedTask의 속성으로 직접 보유하고, "acp는 자체 모델 계약이 없다"는 규칙은 엔티티 불변식이 아니라 필드 수준 검증 규칙으로 처리. AC-06(자체 런타임과 외부 ACP 경로 모두 제공)은 열거형 속성만으로 완전히 충족 가능하므로 인수 커버리지 손실 없음.
• Complexity Change: entities 4→3, relationships 4→3 · -2.5
• Trade-off: 훗날 백엔드별 메타데이터(요청 한도, 인증 토큰, 사용량 통계)가 풍부해질 때 그것을 담을 자연스러운 자리를 잃어, 다시 엔티티로 승격해야 할 수 있다. 현시점에는 수용 가능 — AgentBackend는 불변식 1개뿐이고 DelegatedTask가 이미 재기술하는 것 외에 고유 속성이 없다.
• Decision: Accept — Contrarian CH-026(Major, "ACP v1→v2 분기 시 엔티티 잠금 규칙이 불변식 수정을 금지")도 이 통합으로 함께 해소된다. 엔티티가 사라지면 잠글 불변식도 사라지고, 프로토콜 분기 리스크는 가정 A-05로 이전된다.

Summary

• Total proposals: 3
• 전량 수용(Accept 3 / Reject 0 / Defer 0)
• Complexity if accepted (원 계산): 29.5 → 22.5
• Recommendation(원문): "Review recommended — S-001·S-002는 이미 순연·선택 항목의 저위험 제거이므로 수용하고, S-003는 근시일 내 AgentBackend 확장 계획과 견주어 오너가 판단할 것"

v1.1.0 실제 반영 후 복잡도

세 제안을 모두 수용했으나, 동시에 Contrarian Critical 반론 14건을 해소하기 위해 불변식·인수 기준·비기능 요구를 새로 추가했다. 따라서 최종 복잡도는 원 예상치(22.5)보다 높다:

계산식(v1.1.0): 3×1 + 3×1.5 + 14×0.5 + 13×1 + 4×2 = 3 + 4.5 + 7 + 13 + 8 = 34.5

이 증가는 의도된 것이며 단순화 실패가 아니다. 근거:

1. 증가분의 대부분(+8)은 Must 항목 증가인데, 이는 새 기능 추가가 아니라 기존 요구사항을 검증 가능한 형태로 분해한 결과다. v1.0.0의 AC-08 한 줄("자가 검증한다")이 v1.1.0에서 AC-07(재시도 상한) + AC-08(검증 실행·기록) + C-04의 방법 폐쇄 집합으로 쪼개졌다 — 같은 요구를 테스트 가능하게 만든 것이지 요구를 늘린 것이 아니다.
2. NFR-01~04(+4)는 v1.0.0에서 "미검증 가정"으로만 존재하던 리스크(경량성, 대용량 성능, 한글 IME, 샌드박싱)를 측정 가능한 기준으로 승격한 것이다. 모호성 평가가 "committed non-functional requirements가 전혀 없다"고 지적한 항목이며, 가정으로 두는 것보다 기준으로 두는 편이 안전하다.
3. 불변식 증가(+5)는 전부 Critical 반론의 직접 해소책이다 — 동시 편집 잠금(CH-017/024), 롤백 원자성·충돌 감지(CH-005/023), 실패 상태 전이(CH-021), 비코드 작업 완료 기준(CH-020). 이들을 빼면 복잡도 점수는 내려가지만 데이터 손실·무한 루프·실패 은폐라는 실제 결함이 스펙에 남는다.
4. Simplifier 자신의 규칙 1("핵심 가치에 필수적인 항목은 제거 제안하지 않는다")에 따라, 위 항목들은 애초에 제거 대상이 아니다. 이 스펙의 핵심 가치가 "안전한 위임"이므로 안전 장치는 핵심 클러스터에 속한다.

결론: 복잡도 34.5는 Excessive 구간이나, 그 구성이 "불필요한 기능"이 아니라 "안전 요구사항의 명세화"이므로 추가 단순화를 권고하지 않는다. 다만 Design 단계에서 엔티티 불변식 중 일부(스캐폴딩 원자성 등)를 구현 세부로 이관할 여지는 있다.

Generated by cc-spec Simplifier agent (독립 실행) · 2026-08-25 · 판정 반영 대상: seed-spec-cocode.md v1.1.0