Contrarian Review — 반대 검토

Summary

• Evaluation Date: 2026-08-25
• Target: docs/seed-spec-cocode.md v1.0.0 (DRAFT)
• Total Challenges: 36 (Critical 등급 식별자 15개 / 아래 본문에서 13개 항목으로 기술 — CH-005·CH-023과 CH-011·CH-030이 각각 한 항목으로 병합됨. Major: 16, Minor: 5)
• 판정 이력:
  • v1.1.0 대상 자체 판정(2026-08-25): Critical 전량 해소 주장
  • 적대적 감사(2026-08-26)가 그중 3건(CH-009 · CH-011 · CH-030)의 해소 주장을 기각 — 근거: CH-009는 실제로는 CH-007을 고친 것이고, CH-011/CH-030은 믿음만 가정으로 옮겼을 뿐 잠기는 행동은 그대로였음
  • v1.2.0 대상 재판정(2026-08-26): 아래 표 반영
• Disposition against v1.2.0: Critical 15개 식별자 중 14개 해소, 1개 위험 인수(CH-009) · Major 16건 중 13건 해소, 3건 위험 인수 · Minor 5건 중 3건 해소, 2건 위험 인수
• 미해소 Critical: 0건(CH-009는 Accepted — 위험 인수 사유를 의사결정 일지 D-011에 기록)

이 문서는 시점별 판정 기록이다. 각 반론의 Response·Evidence는 그 판정을 내린 시점의 Seed Spec 버전을 가리키며, 이후 버전에서 해당 조항이 이동·개명·삭제됐을 수 있다. 특히 v3.0.0에서 §4가 전면 재작성되며 AC-NN 번호가 재배치됐다 — 현재 상태는 항상 docs/seed-spec-cocode.md를 정본으로 확인할 것. 이 문서의 인용을 현재 스펙의 위치로 읽으면 안 된다.

Evidence가 비어 있으면 Status는 Unresolved 또는 Accepted여야 한다(cc-spec contrarian 규칙 5).

Critical 반론 (14건)

CH-001: C-01이 미해결 입력(P1 vs P2) 위에 세워짐

• Type: Assumption Attack · Target: C-01 · Severity: Critical
• Challenge: C-01은 "개발자 우선" 순서를 못박았지만, Discovery 문서 §Recommendations 1번은 "1차 사용자가 코코드 내부 도그푸딩(P1)인지 외부 시장(P2)인지"를 미해결로 남겼다. P1이라면 드리머 모드 순연 논리 자체가 무의미해진다.
• Expected Impact: 불변 제약이 미해결 입력 위에 서게 되어, 잠금 후 수정 불가 상태로 죽은 로드맵 논리를 안고 가야 함.
• Response: 사용자에게 직접 질의해 **"처음부터 외부 개발자 대상(P2)"**으로 확정했다. C-01 본문에 1차 고객 정의를 명시적으로 포함시켰다.
• Evidence: v1.1.0 §2 C-01 ("1차 고객은 코코드 내부 팀이 아니라 외부 Dart/Flutter 개발자 시장이다") + §5 A-01
• Status: Resolved

CH-004: "완료" 전이에 사람 diff 검토가 게이트인지 불명

• Type: Scale Challenge · Target: C-02 × C-04 · Severity: Critical
• Challenge: 대규모 리팩터링(500개 파일 등)을 무인으로 수행할 때, DelegatedTask가 사람의 diff 검토 없이 "완료"에 도달할 수 있는지 v1.0.0은 명시하지 않았다.
• Expected Impact: 사람 검토가 게이트가 아니라면 C-02의 diff 요구는 사후적·선택적이 되어 "감시받지 않는 에이전트의 안전망"이라는 목적을 상실.
• Response: 사용자 결정 — 자가 검증만으로 완료 가능, diff는 사후 안전망이며 선행 게이트가 아님. 이 의도를 엔티티 불변식에 명시적으로 기록해 모호함을 제거했다.
• Evidence: v1.1.0 §3 DelegatedTask 불변식 2번("'완료' 전이에 사람의 diff 승인은 요구하지 않는다 — diff 리뷰는 사후 안전망이며 선행 게이트가 아니다") + AC-08
• Status: Resolved

CH-005 / CH-023: EditSnapshot에 base-revision이 없어 사람 작업을 덮어쓸 수 있음

• Type: Assumption Attack / Removal Test · Target: C-02, EditSnapshot · Severity: Critical
• Challenge: 두 에이전트 스냅샷 사이에 사람이 같은 파일을 직접 편집하면, EditSnapshot에 base 리비전·해시가 없어 롤백이 사람의 작업을 조용히 훼손할 수 있다.
• Expected Impact: "안전한 롤백" 기능이 오히려 사람 작업을 잃게 만드는 정반대 결과.
• Response: EditSnapshot에 base_content_hash 속성을 추가하고, 롤백 시 현재 내용 해시가 불일치하면 자동 적용 대신 충돌로 제시하도록 불변식을 신설했다.
• Evidence: v1.1.0 §3 EditSnapshot Attributes(base_content_hash) + 불변식 2번 + AC-02
• Status: Resolved

CH-009: C-03 포지셔닝이 검증된 고객 선호가 아닌 오너 개인 견해에 기반

• Type: Assumption Attack · Target: C-03 · Severity: Critical
• Challenge: Flutter 개발자가 수직 깊이보다 수평 넓이(Flutter + Terraform/CI/백엔드를 한 도구에서)를 더 원할 가능성. C-03은 Socratic 인터뷰의 오너 선호에서 도출됐을 뿐 고객 리서치 결과가 아니다.
• Expected Impact: 잠금 후 수정 불가한 제약이 단일 이해관계자 의견 위에 서게 됨.
• Response (v1.1.0, 기각됨): 최초에는 C-03에 "프로젝트 내부의 비-Dart 파일 편집은 제한하지 않는다"는 파일 수준 경계를 추가하고 해소를 주장했다. 적대적 감사(2026-08-26)가 이를 기각했다 — 그 조항은 CH-007(파일 수준 편집 범위)을 고친 것이며, CH-009가 지적한 인식론적 공백(수직 포지셔닝에 고객 검증이 없음)은 손대지 않은 채 "오너가 결정했다"로 재천명했을 뿐이라는 판정. 구조적으로 동일한 CH-008을 같은 보고서가 Accepted로 분류한 것과 불일치한다는 지적도 함께 받았고, 둘 다 타당하다.
• Response (v1.2.0, 최종): 해소 주장을 철회하고 위험 인수로 재분류한다. C-03 본문에 "이 포지셔닝은 고객 리서치가 아니라 프로젝트 오너의 판단에 근거한다"를 경고 표시와 함께 명시하고, 별도 가정 A-07("Dart/Flutter 개발자가 수평적 넓이보다 수직적 깊이를 선호한다")을 신설해 MVP 출시 후 사용자 인터뷰로 검증하도록 추적한다. 착수 자체를 고객 리서치 완료까지 미루지는 않되, 무엇을 검증 없이 잠갔는지 문서에 남긴다.
• Evidence: v1.2.0 §2 C-03 경고 문구 + §5 A-07 + 의사결정 일지 D-011
• Status: Accepted (risk acknowledged)

CH-010: 자가 검증·재시도 루프에 상한이 없음

• Type: Scale Challenge · Target: C-04 · Severity: Critical
• Challenge: 재시도 횟수·타임아웃·비용 한도가 어디에도 없어, 무인 상태에서 빌드 실패↔재시도를 무한 반복하며 자원을 소모할 수 있다.
• Expected Impact: 잘못된 편집이 아니라 "사용자가 자리를 비운 사이 조용히 무한정 자원 소모"라는 실패 모드.
• Response: 사용자 결정 — 최대 3회 재시도, 초과 시 "실패" 상태 전이 + 사람 에스컬레이션. cc-spec 자체 피드백 루프 정책(max_retries: 3)과 일관.
• Evidence: v1.1.0 §2 C-04 후단 + §3 DelegatedTask 불변식 3번 + AC-07
• Status: Resolved

CH-011 / CH-030: 자가 검증이 미검증인 채 불변 제약으로 승격됨 / 에이전트가 자기 검증을 속일 수 있음

• Type: Assumption Attack · Target: C-04, A-04(구) · Severity: Critical
• Challenge: A-04는 스스로 "기술 검증 미완료"라고 인정하는데도 C-04라는 불변 제약으로 승격됐다. 특히 에이전트가 자기가 작성한 테스트를 통과시키는 실패 모드를 아무도 다루지 않는다.
• Expected Impact: 자가 검증이 실제로 불가능한 것으로 판명되면, 핵심 상호작용 모델이 잠긴 채 수정 불가.
• Response (v1.1.0, 기각됨): 최초에는 두 층위 분리로 해소를 주장했다 — 제약(C-04)은 "자가 검증을 한다"는 행위만 규정하고, "자가 검증이 사람 판단을 대체할 만큼 신뢰할 수 있는가"라는 믿음은 가정 A-02로 분리. 적대적 감사(2026-08-26)가 이를 기각했다: 믿음의 이름표만 옮겼을 뿐, 그 믿음이 뒷받침하는 행동(비동기·자가검증만으로 완료·사람 게이트 없음)은 C-04(불변 제약)와 DelegatedTask 불변식(추가만 허용) 양쪽에 여전히 잠겨 있어, A-02 스파이크가 실패해도 되돌릴 장치가 없다. 반론이 경고한 잠금 실패 모드를 해소한 게 아니라 재현했다는 판정이며, 정확한 지적이다. CH-030(에이전트가 자기 검증을 속이는 실패 모드)에 대해서도 v1.1.0은 아무 완화 장치를 추가하지 않았다.
• Response (v1.2.0, 최종): C-04에 전환 조항을 잠금 전에 명시했다 — "A-02 스파이크가 목표 기준(AC-10)에 미달하면 기본 완료 모드는 자동으로 '사람 diff 승인 후 완료'로 전환되며, 이 전환은 제약 위반이 아니라 제약이 미리 규정한 동작이다." 이를 실행 가능하게 하려고 DelegatedTask에 completion_mode 속성과 "사람승인대기" 상태를 신설했고, AC-10으로 판정 기준을 수치화했다(의도적 결함 30건 주입, 검출률 80% 이상). CH-030이 지목한 "자기 검증 속이기" 실패 모드는 바로 이 결함 주입 실측이 직접 겨냥하는 대상이다.
• Evidence: v3.0.0 §2 C-04 전환 조항 + §3 DelegatedTask(completion_mode, pending_approval_kind, 사람승인대기) + §2 C-05 + §4 AC-10·AC-11 + §5 A-02 + 의사결정 일지 D-012, D-014
• ⚠️ 위 Response 의 수치는 폐기됨 (2026-08-26): "의도적 결함 30건 주입, 검출률 80% 이상"은 v1.2.0 당시 작성자가 근거 없이 지어낸 값이며 v2.0.0에서 제거됐다(D-013, D-015). 현재 표본 수와 합격 기준은 Planning 단계 미결이고, 미설정 시 C-04 전환 조항이 발동해 기본이 "사람 승인 모드"가 된다. 또한 5차 감사가 지적했듯 결함 주입 실측(외생적)만으로는 CH-030 의 내생적 실패 모드가 측정되지 않는다 — 현재 A-02 는 ⓐ 제3자 주입 결함과 ⓑ 에이전트 자신이 만든 결함의 검출률을 분리 측정하도록 규정하며, 실질적 차단은 C-05(기존 테스트 변경 금지)가 담당한다
• Status: Resolved

CH-013: C-05가 스스로 "미검증"이라 인정한 믿음 위에 세워짐

• Type: Assumption Attack · Target: C-05(구), A-05(구) · Severity: Critical
• Challenge: "Dart로 못 만드는 카테고리는 없다"는 오너의 경력 기반 확신이며 A-05 스스로 미검증이라 표기한다. 그 위에 "영구히 배제 없음"을 불변 제약으로 잠그면, 실제로 지원 불가한 카테고리가 나와도 제약 위반 없이는 인정할 수 없다.
• Expected Impact: 스스로 미검증이라 표시한 주장에 영구히 묶임.
• Response: Simplifier 제안 S-001을 수용해 C-05·AC-07(구)·A-05(구) 클러스터를 v1.1.0에서 전량 제거했다. 이는 MVP 범위 밖의 장기 포지셔닝 서술이며 불변 제약의 엄격성을 부여할 이유가 없다. 게임·임베디드 지원 판단은 해당 카테고리를 실제로 스코프에 넣는 시점에 근거와 함께 재도입한다.
• Evidence: v1.1.0 §2 제약 목록(C-05 부재) + §6 Evolution Log v1.1.0 항목 ④
• Status: Resolved

CH-020: 빌드/테스트 신호가 없는 작업은 "완료"에 도달할 수 없음

• Type: Assumption Attack · Target: DelegatedTask 불변식 · Severity: Critical
• Challenge: 문서 편집·자산 이름 변경·시각적 UX 조정처럼 빌드/테스트/핫 리로드 신호가 전혀 없는 작업은, "자가 검증 필수" 불변식 하에서 영원히 완료될 수 없거나 팀이 무의미한 검증 단계를 조작하게 된다.
• Expected Impact: 흔한 워크플로가 지원 불가하거나, 자가 검증의 안전 근거 자체가 형해화됨.
• Response: 불변식을 "해당 작업에 적용 가능한 방법 1종 이상"으로 한정하고, 적용 가능한 방법이 하나도 없는 작업에 대해서는 "정적 분석 통과 + 편집이 문법적으로 유효함"이라는 최소 기준을 명시했다.
• Evidence: v1.1.0 §3 DelegatedTask 불변식 1번 + AC-08("해당 작업에 적용 가능한 1종 이상")
• Status: Resolved

CH-021: DelegatedTask에 실패/에스컬레이션 상태가 없음

• Type: Historical Challenge · Target: DelegatedTask status enum · Severity: Critical(원 분류 Major, 상향)
• Challenge: 상태 집합(대기/실행중/자가검증중/완료/롤백됨)에 "실패"나 "사람 검토 필요"가 없어, 자가 검증이 끝내 실패한 작업을 표현할 방법이 없다.
• Expected Impact: 실패한 작업이 기존 상태 중 하나로 잘못 표현되어, 돌아온 사용자에게 실패가 은폐됨.
• Response: status 집합에 **"실패"**를 추가하고 폐쇄 집합임을 명시했다. retry_count 초과 시 이 상태로 전이하며 사람에게 에스컬레이션한다.
• Evidence: v1.1.0 §3 DelegatedTask status 값 집합 + 불변식 3번 + AC-07
• Status: Resolved

CH-025: AC-06(둘 다 MVP 필수)이 Discovery 로드맵과 모순

• Type: Removal Test · Target: AC-06 · Severity: Critical
• Challenge: Discovery의 6단계 로드맵은 ACP 클라이언트를 3단계, 자체 런타임(agent)을 5단계에 배치한다. 그 순서대로면 MVP 시점에 agent가 존재하지 않아 AC-06과 정면 충돌한다.
• Expected Impact: 같은 프로젝트의 두 문서가 MVP 범위에 대해 서로 다른 답을 주며, 어느 쪽이 지배하는지 정해지지 않음.
• Response: 사용자에게 직접 질의해 **"둘 다 MVP부터 필수"**로 확정했다. 즉 Seed spec이 지배하며, Discovery의 단계 순서는 구현 순서 제안일 뿐 MVP 범위 정의가 아니다. AC-06에 최소 요건(agent는 프로바이더 2개 이상, acp는 ACP 에이전트 1개 이상)을 수치로 명시해 검증 가능하게 만들었다.
• Evidence: v1.2.0 §4 AC-06 + 의사결정 일지 D-006 (※ 이 보고서 초판은 D-005를 인용했으나 D-005는 고객 정의 항목이며, AC-06/로드맵 모순을 다루는 것은 D-006이다 — 적대적 감사 지적으로 정정)
• Status: Resolved

CH-028: A-02(코코드 팀이 skill 격차를 메운다)가 무한정 운영 부담

• Type: Historical Challenge · Target: A-02(구) · Severity: Critical
• Challenge: "부족분은 코코드 팀이 skill로 채운다"는 약속에 수용 한계·우선순위 기준·범위 컷오프가 없다.
• Expected Impact: 드리머 모드 비즈니스 모델 전체가 이 가정에 의존하는데, 검증 방법이 모호하고 담당자·기한·투입 상한이 없음.
• Response: Simplifier 제안 S-002를 수용해 A-02(구)를 v1.1.0에서 제거했다. C-01이 드리머 모드 자체를 MVP 이후로 순연했으므로, 그 운영 모델 가정을 현재 스펙이 안고 갈 이유가 없다. 드리머 모드 기획을 실제로 시작하는 시점에 수용 한계·컷오프와 함께 재도입한다.
• Evidence: v1.1.0 §5 가정 목록(구 A-02 부재) + §6 Evolution Log v1.1.0 항목 ⑤
• Status: Resolved

CH-033: A-06(re_editor 성능)이 상류 Flutter 엔진 이슈에 묶여 있을 수 있음

• Type: Historical Challenge · Target: A-06(구) → A-03 · Severity: Critical
• Challenge: flutter#128575는 re_editor가 아니라 Flutter 엔진의 텍스트 편집 파이프라인 이슈다. 근본 원인이 상류에 있다면 cocode ADE 자체 노력으로 해결 불가능할 수 있고, 이는 "우리가 완화할 리스크"가 아니라 "우리가 통제 못 하는 의존성"이라는 다른 범주의 리스크다.
• Expected Impact: 스파이크로 해결 가능하다는 로드맵 전제가 성립하지 않을 수 있음.
• Response: A-03(구 A-06) 본문에 이 구분을 명시하고, 실패 시 분기(자체 렌더링 텍스트 레이어 검토)를 검증 방법에 포함시켰다. 또한 NFR-02로 승격해 측정 가능한 기준(p95 16.7ms)을 부여했다.
• Evidence: v1.1.0 §5 A-03(단서 및 분기 명시) + §4 NFR-02
• Status: Resolved

CH-034: A-07(한글 IME) — 재사용 컴포넌트가 Lumide의 미해결 버그를 그대로 물려받음

• Type: Historical Challenge · Target: A-07(구) → A-04 · Severity: Critical
• Challenge: Discovery는 xterm2/flutter_pty2를 저위험 재사용 후보로 지목하면서 동시에 Lumide 이슈 #64(한글 IME, 미해결)를 리스크로 든다. 같은 컴포넌트를 재사용하면 바로 그 결함을 수입하게 되는데 스펙이 이 모순을 조정하지 않았다.
• Expected Impact: 빌드 리스크를 줄이려는 재사용 전략이 최상위 게이팅 리스크를 오히려 확정적으로 끌어들임.
• Response: A-04(구 A-07) 본문에 이 위험을 명시하고, 검증 방법을 "재사용 컴포넌트에 대해 먼저 결함 재현 여부를 확인한 후 자체 수정 가능성을 판단"으로 구체화했다. NFR-03으로 승격해 합격 기준(조합 중 글자 깨짐·중복 입력·커서 오류 없음)을 명시했다.
• Evidence: v1.1.0 §5 A-04 + §4 NFR-03
• Status: Resolved

Major 반론 (17건)

Minor 반론 (5건)

위험 인수 항목 (Accepted — 5건)

다음 5건은 해소되지 않았으며, 의도적으로 위험을 인수한다. 각 항목이 무엇을 검증 없이 진행하는지 명시한다.

적대적 감사 이력 (2026-08-26)

이 보고서의 v1.1.0 대상 판정은 독립 감사 에이전트의 검증을 받았다. 감사는 Critical 15개 식별자 각각에 대해 인용된 Evidence 위치를 직접 열어보고 실제로 반론을 해소하는지 확인했다.

감사가 추가로 지적한 신규 결함 3건:

1. NFR-01 근거 부재 — v1.1.0에서 신설된 성능 목표치(150MB/2초/400MB)가 가정·검증 방법·기준선 없이 곧바로 Must로 잠김. 이 문서가 다른 곳에서 일관되게 Critical로 취급하는 패턴. → v1.2.0에서 A-06으로 강등, 목표치를 스파이크 결과로 이관(D-013)
2. 구조적 잠금 리스크 — CH-011/CH-030 기각 사유와 동일. → v1.2.0 C-04 전환 조항으로 해소(D-012)
3. 보고서 자체의 인용 오류 — Critical 개수 표기(14 vs 실제 15개 식별자), CH-025의 D-005 오인용(D-006이 정답). → 이 개정에서 모두 정정

감사가 UPHELD 판정에 덧붙인 잔여 지적 2건도 v1.2.0에 반영했다: CH-010의 "재시도 횟수만 제한하고 시도별 시간 상한은 없음" → NFR-05 신설(10분), CH-020의 "정적 분석조차 적용 불가한 작업이 있음" → 비코드 작업 완료 기준을 순환 참조 없이 재작성(파일 손상 없음 기준).

최초 생성: cc-spec Contrarian agent (독립 실행) · 2026-08-25 (대상 v1.0.0) 적대적 감사 반영 및 판정 정정: 2026-08-26 (대상 seed-spec-cocode.md v1.2.0)