파이프라인 2단계(Specification) Phase 1 산출물.
/cc-spec:interview5단계 라이브 인터뷰 결과. 인터뷰 대상: 프로젝트 오너(Dart/Flutter 7년 경력 엔지니어) · 진행: 2026-08-25 수렴도: 15/15 질문 응답 (재확인 1회 포함) → 1.0 (임계값 0.95 통과)
Level 1: 표면 (Surface)
| 질문 | 답변 요지 |
|---|---|
| 이 프로젝트가 풀려는 문제는? | ADE는 개발자를 타겟으로 적었으나, AI를 통해 누구나 소프트웨어 제품을 만들 기회를 갖게 하는 것이 목적. 기존 도구(특히 Zed)는 가벼워서 성공했지만 Flutter/Dart 지원이 부족. Dart는 모든 소프트웨어를 만들 수 있는 강력한 엔진이라는 믿음 위에, 쉽고 빠르게 제품화할 수 있는 ADE를 제공 |
| 핵심 사용자는? | 도메인 이해도가 높은 전문가/시니어/드리머 + Dart를 좋아하는 엔지니어 (→ Level 2에서 "주 고객=개발자"로 정정됨) |
| 성공하면 사용자의 삶이 어떻게 바뀌나? | 돈을 내고 AI에게 일을 맡기고 다른 작업을 할 수 있게 됨. 성공적인 위임 경험이 반복되면 이탈하지 않는 제품이 됨 |
Level 2: 가정 (Assumptions)
| ID | 가정 | 결과 |
|---|---|---|
| A-01 | "가벼움"이 비개발자에게도 체감 가치다 → 정정: 주 고객은 개발자, AI로 비개발자 접근성 확장은 "목표"이지 1차 스코프 아님 | 정정 반영 |
| A-02 | 도메인 전문가가 코딩 지식 없이도 요구사항을 명확히 표현해 위임 가능 | 확인 — coco-de/skills가 격차를 메우고, 부족하면 코코드 팀이 직접 skill을 채움(운영 부담을 팀이 진다는 뜻) |
| A-03 | 한 제품이 "드리머 모드"(자연어 위임)와 "엔지니어 모드"(코드/IDE)를 동시에 1급으로 서빙 | 최초 확인(맞음) → Level 3에서 순서가 있다로 정정(아래 C-01) |
| A-04 | "맡기고 떠난다"는 비동기(fire-and-forget) 위임 모델이며, 원래 설계 노트의 "실행 상태를 아는 에이전트"는 사람이 아니라 에이전트 자신의 자가 검증·재시도를 위한 장치 | 확인 — 이유: 코딩을 좋아하는 인구는 줄고, 개발자조차 AI 위임이 늘어나는 추세가 가속화될 것이라는 전망 |
| A-05 | Dart/Flutter(+Serverpod)가 다루지 못하는 소프트웨어 카테고리가 있다(임베디드/대규모 ML/AAA 게임 등은 처음부터 배제) | 부정 — Dart로 못 만드는 소프트웨어/기술은 없다는 입장. FFI를 근거로 제시. 게임·임베디드도 이미 Dart/Flutter 채택 사례가 늘고 있음(B-03 참고) |
Level 3: 모순 (Contradictions)
| ID | 충돌 | 해결 |
|---|---|---|
| C-01 | A-01(주 고객=개발자) vs A-03(드리머 모드·엔지니어 모드 동시 1급) — 두 페르소나를 출시일부터 동등 우선순위로 다룰 수 있는가? | 해결: 초기 버전(MVP)은 개발자 인터페이스로 진행. 드리머 모드는 이후 업데이트로 순서를 둔다. → 로드맵의 순서를 확정하는 결정 |
| C-02 | A-05(Dart로 못 만드는 게 없다) vs Discovery가 이미 확인한 리스크(re_editor 대용량 성능 미검증, flutter#128575 open, 한글 IME 미해결 — Lumide도 실패) | 해결: "Dart로 못 만드는 게 없다"는 **사용자가 만드는 결과물(output)**에 대한 믿음이며, cocode ADE 자기 자신의 에디터 코어 구현 리스크와는 별개 층위. 프로젝트 오너의 7년 Dart/Flutter 경력을 근거로 해결 가능하다고 판단 — Discovery 로드맵 1단계(성능·IME 스파이크)는 형식 절차가 아니라 여전히 MVP의 실질적 게이팅 리스크로 유지 |
Level 4: 경계 (Boundaries)
| ID | 가정이 틀렸을 때 | 결정 |
|---|---|---|
| B-01 | 비동기 위임 중 에이전트가 사람 없이 잘못된 방향으로 진행하면? | 롤백 + diff 리뷰를 MVP 범위에 필수 포함. ADE라면 당연히 갖춰야 한다는 강한 확언 — Lumide의 local_history(파일 버전 스냅샷) 설계와 정확히 같은 축 |
| B-02 | Discovery가 "Zed·Cursor와 정면 승부 금지"를 경고했는데, MVP가 개발자용 경량 에디터+에이전트라면 이 경고와 충돌하지 않는가? | 재발견: 실제 인지된 경쟁자는 Zed/Cursor가 아니라 Orca(Stably AI, MIT 오픈소스, ★2만+, 27개+ CLI 에이전트를 격리 worktree에서 병렬 실행하는 범용 ADE). 보강 조사로 확인: Orca는 언어/에이전트 불문 수평적 오케스트레이터이고 결정론적 스캐폴딩(bricks)도 Flutter 런타임 상태 인지도 없음. → cocode ADE는 Dart/Flutter 특화 수직 딥 IDE로 포지셔닝 (확정) |
| B-03 | cocode ADE가 처음부터 명시적으로 지원 범위 밖이라고 선언할 카테고리가 있는가? | 없음. 게임·임베디드도 이미 Dart/Flutter로 개발되는 사례가 늘고 있고 반영 사례도 존재 — 배제 카테고리를 두지 않음 |
Level 5: 수렴 (Convergence)
정제된 핵심 문제 정의 (가정 없이, 한 문장):
Dart/Flutter 개발자가 반복 작업을 AI에게 안전하게(롤백 가능하게) 위임하고 떠날 수 있는, 기존 범용 도구보다 가볍고 언어 전용인 IDE가 없다.
추가로 확정된 장기 비전 (Level 5에서 확장):
MVP는 Dart/Flutter 특화 수직 딥 IDE로 시작하되, 장기적으로는 Orca급 멀티 에이전트 오케스트레이션 기능 전체를 커버하는 방향으로 성장한다 — Orca가 "현존 최고의 ADE"라는 전제 위에, 그 기능 전체를 흡수하는 것이 목표.
Level 5 명확화 (추가 확인): "Orca급 전체 기능 커버"는 Orca처럼 언어/스택에 무관한 범용·수평 도구가 된다는 뜻이 아니다. 기능의 폭(멀티 에이전트 오케스트레이션, 워크트리 관리, task handoff 등)은 Orca 수준으로 넓히되, 그 모든 기능의 구현·UX는 처음부터 끝까지 Dart/Flutter 특화를 유지한다 — 웹 특화(브라우저 자동화 중심)도 아니다. B-02의 "수직 딥 IDE" 포지셔닝은 장기 확장 이후에도 희석되지 않는다.
수렴도: 15/15 응답 (100%) — 임계값 0.95 통과. 후속 질문 없이 인터뷰 종료.
다음 단계
/cc-spec:seed로 이 결과를 Seed spec으로 전환 — 모호성 점수 산출, Contrarian/Simplifier 병렬 검토, 3단계 평가(Specification Gate)로 이어진다.
Generated by cc-spec:interview (BMAD v6) · 2026-08-25