Cocode ADE · 01

Discovery — 사용자 · 시장 조사

후보 페르소나 · 경쟁 구도(Zed · Cursor · Antigravity · Lumide · Serverpod 4) · 검증된 가정과 미검증 가정

파이프라인 1단계(Discovery) 산출물. 출처: 코코드 ADE 설계 노트 (Lumide 0.20.0 실사, 2026-08-25) + 보강 조사. 상태: .pipeline/cocode.yaml · Level 4(신규 프로젝트, deep)

User Research

Target Personas

이 항목은 미검증 상태다. 설계 노트는 제품의 시장 포지셔닝(가격대·경쟁 구도)을 다루지만 "누가 처음 쓰는가"는 명시하지 않았다. 다만 이번 세션에서 관찰 가능한 사실로부터 두 개의 후보 페르소나를 도출했다 — 이것도 확정이 아니라 다음 단계(Specification 인터뷰)에서 사용자에게 직접 확인해야 할 항목이다.

후보	근거	특징
P1. 코코드 내부 Flutter 팀 자신	이 세션에서 확인 가능한 코코드의 플러그인 생태계(`cc-bricks`, `cc-flutter`, `cc-coui`, `cc-serverpod`, `cc-i18n`, `cc-e2e`, `cc-marionette`, `cc-inspector`, `cc-dev`/ZenHub 연동 등)는 이미 "Flutter 전용 에이전틱 워크플로"를 Claude Code 플러그인 형태로 상당히 성숙하게 구축해 놓은 상태임을 보여준다. cocode ADE는 이 사내 축적물을 네이티브 앱으로 제품화하는 시도일 가능성이 높다.	사내 도구 관점 — bricks/skills가 이미 존재, ZenHub·CoUI 컨벤션과 강결합
P2. 외부 Flutter/Dart 개발자(제품으로서의 코코드 ADE)	설계 노트의 "가격의 빈 구간"(BYOK $0 vs 재판매 $20/월 사이 $5~9/월) 분석과 "Flutter 전용 개발 환경 부재" 시장 갭 분석은 명백히 외부 판매를 전제로 한 서술이다.	시장 상품 관점 — 범용 Flutter 개발자, ACP로 자기 구독(Claude/ChatGPT) 재사용

미검증 가정: P1과 P2는 로드맵 순서(P1 도그푸딩 → P2 확장)로 양립 가능할 수도, 처음부터 분리된 트랙일 수도 있다. 이 구분에 따라 Level 4 Discovery의 다음 단계(Specification)에서 물어야 할 1순위 질문이 달라진다.

Key Insights

설계 노트가 이미 실측으로 확보한 인사이트를 정리하면:

"가볍다"의 원인은 Flutter가 아니라 Electron을 안 쓴 것이다. 설치 55.8MB 중 Electron/Chromium 런타임 부재가 VS Code 대비 격차의 본체. Flutter는 그 수단 중 하나였을 뿐 — cocode ADE가 "Flutter라서 가볍다"고 마케팅하면 반박당하기 쉬운 주장이다.
ACP는 이미 표준화 궤도에 올랐다 (아래 보강 조사 참고). Lumide가 검증한 "자체 렌더링 X, 남의 에이전트 호스팅"이라는 전략이 리스크가 아니라 점점 안전해지는 베팅이라는 뜻.
테마 스키마(LSP 시맨틱 토큰 24종 + UI 9색)는 그대로 채택 가치가 있는 설계다 — 아이디어이지 저작물이 아니므로 법적 문제 없이 재사용 가능.
핵심 부품 다수가 이미 MIT로 공개되어 있다(lumide_api, panes, xterm2, flutter_pty2) — cocode ADE의 초기 개발 리스크를 크게 낮추는 요인.

Validated/Unvalidated Assumptions

가정	상태	근거/검증 방법
Flutter로 IDE급 에디터가 실제로 만들어진다(`re_editor` 성능)	미검증	설계 노트 로드맵 1단계가 정확히 이 가정을 검증하기 위해 설계됨. 10만 줄 파일 스크롤/커서 프레임타임 실측 필요
한글 IME가 에디터·터미널 양쪽에서 정상 동작한다	미검증, 반증 사례 있음	Lumide 자체가 이슈 #64(2026-07-29 등록)로 아직 못 고친 버그. cocode ADE가 반드시 별도로 검증해야 할 항목
ACP 클라이언트만으로 "멀티 LLM" 요구를 충족한다	검증됨(거짓)	설계 노트 §ACP 섹션: ACP는 에이전트가 노출한 목록 안에서만 모델 선택 가능. 자체 런타임(agent) 없이는 "OpenAI/Claude/Grok 드롭다운"이 불가능
Serverpod 4가 이미 "번들된 skills + MCP 서버 + 대화형 에디터"를 출시했다	검증됨(사실)	설계 노트에 근거 명시. 경쟁이 아니라 통합 대상으로 재정의 필요
코코드 브랜드가 "누구를 위한 제품인가"를 이미 결정했다	미검증	위 Target Personas 참고 — Specification 단계 1순위 질문

Market Analysis

Competitive Landscape

경쟁축	대표 사례	cocode ADE와의 관계
범용 AI 에디터	Zed, Cursor	정면 승부 금지 대상(설계 노트 권고). Lumide(★77)조차 이 시장에서 고전 중이고, Void(★28.8k)도 2026-06 아카이브됨
Google Antigravity	VS Code 포크 + Gemini, Stitch(디자인 생성)와 연계해 Flutter+Dart 코드로 변환	Flutter를 다루지만 범용 에이전틱 IDE에 Flutter 지식을 얹은 구조(MCP/Agent Skills 경유)라는 점에서 설계 노트의 "Flutter 전용 목적 지향 IDE 부재" 주장과 상충하지 않음 — 오히려 그 주장을 뒷받침하는 사례
Lumide	이번 실사 대상. Flutter 기반, ACP 클라이언트, 오픈소스 부품 다수	가장 가까운 구조적 선례. 직접 경쟁보다는 부품(panes/xterm2/flutter_pty2/lumide_api) 재사용 + 설계 학습 대상
Serverpod 4	번들 agent skills + MCP 서버 + 대화형 에디터 선택 + 풀스택 핫 리로드	설계 노트 권고대로 경쟁자가 아니라 통합 대상
ACP 에이전트 생태계	Claude Code, Codex, Gemini CLI, Copilot CLI 등	acp가 이들을 그대로 흡수하는 대상이지 경쟁자가 아님. 2026년 8월 기준 등록 에이전트 50개 이상, JetBrains·Zed·Google·GitHub 참여(아래 보강 조사)

보강 조사 (2026-08-25 기준, 설계 노트 이후 갱신분)

ACP 생태계가 설계 노트 작성 시점보다 더 빠르게 성숙 중이다. JetBrains가 2025-12 ACP 지원을 추가했고, 2026-01-28 Zed와 공동으로 ACP Agent Registry를 공개, 2026년 3월 25개 → 4월 40개 → 6월 50개 이상으로 등록 에이전트가 늘었다. Google·GitHub도 프로토콜에 합류. → acp를 "남의 에이전트를 그대로 호스팅"하는 전략은 지금 시점에 리스크가 아니라 순풍이라는 설계 노트의 결론이 최근 데이터로 더 강하게 뒷받침된다.
fdemon — Rust로 작성된 Flutter 전용 터미널 UI(hot reload, 멀티 디바이스 세션, 내장 DevTools 위젯 인스펙터). IDE는 아니지만 "Flutter 개발 루프를 얼마나 좁게 만들 수 있는가"를 보여주는 참고 사례. cocode ADE의 6단계 로드맵("닫힌 검증 루프") 설계 시 벤치마크 대상으로 유용 — 사용자가 직접 제보. (출처: edTheGuy00/fdemon)
Google Antigravity + Stitch 조합이 "AI로 Flutter 앱 만들기" 워크플로를 이미 상당히 매끄럽게 제공 중이나, 이는 디자인→코드 생성에 방점이 있고 코코드가 겨냥한 "실행 상태를 아는 에이전트"(핫 리로드·위젯 트리 1급 통합)나 "결정론적 스캐폴딩"(bricks) 축과는 다른 축이다. → 시장 갭 주장은 유효.

Differentiation Points

설계 노트가 제시한 3대 차별화 축은 보강 조사로도 반증되지 않았다:

실행 상태를 아는 에이전트 — vm_service 직결로 핫 리로드·위젯 인스펙터를 에이전트 도구로 노출. 웹은 브라우저 자동화로 이미 닫힌 루프가 있지만 Flutter/모바일에는 1급 사례가 없음.
스캐폴딩을 1급 기능으로 — bricks(결정론적) → skill(그 규약 안에서만 에이전트 작동). Kiro Specs, Claude Skills, Flutter Agent Skills는 전부 프롬프트 재사용 계층이지 검증된 프로젝트 골격이 아님.
가격의 빈 구간 — ACP 위임으로 모델 마진 없이 도구값만 받는 $5~9/월 구간.

Vision

Vision Statement (초안 — Specification 단계에서 확정 필요)

"코코드가 이미 사내에서 검증한 Flutter 에이전틱 워크플로(bricks·skills·ZenHub 컨벤션)를, 그 워크플로를 그대로 실행할 수 있는 목적 지향 데스크톱 환경으로 제품화한다 — 자체 멀티 LLM 런타임과 외부 ACP 에이전트를 같은 코드 경로로 다루면서."

이 문장은 P1(내부 도그푸딩)을 1차 사용자로 가정하고 쓴 초안이다. P2(외부 판매)가 1차라면 비전 문장 자체가 달라진다 — Specification 인터뷰 Level 1의 첫 질문으로 확정해야 함.

North Star Metric (후보, 미확정)

후보 지표	적용 시나리오
에이전트 편집 1회당 "핫 리로드 → 자동 검증 → 성공" 사이클 완주율	P1/P2 공통, 6단계 로드맵의 "닫힌 검증 루프"가 핵심 가치라면
cocode ADE로 생성된 brick 기반 프로젝트 수	bricks가 핵심 차별화라면
MAU 대비 유료 전환율(가격 빈 구간 가설 검증)	P2(외부 판매)가 우선순위라면

Ideation

Solution Direction

설계 노트가 제시한 하이브리드 아키텍처를 그대로 채택 방향으로 제안한다:

cocode_ade (Flutter 데스크톱 셸: 에디터·터미널·파일트리·도킹·Git)
                       ├─ agent (자체 에이전트 런타임 — 멀티 LLM의 자리)
                       │    openai_dart + anthropic_sdk_dart + OpenAI 호환 게이트웨이(Grok/OpenRouter)
                       │    → 스스로도 ACP 서버로 노출해 UI 코드 경로를 하나로 통일
                       └─ acp (ACP 클라이언트 — 외부 생태계 흡수: Claude Code/Codex/Gemini CLI/Copilot CLI)

bricks(결정론적 골격) → co-bricks(증분 확장) → skills(절차적 지식, 골격 규약 안에서만 에이전트를 움직임)의 3단 분리가 "LLM이 가장 헛발질하는 구간(프로젝트 초기 아키텍처 결정)을 가장 결정론적으로 처리 가능한 구간으로" 바꾸는 핵심 논리.

Technical Feasibility

설계 노트의 기술 선택 실사(2026-08 기준)를 그대로 인용한다 — 별도 재검증 없이 신뢰 가능한 수준의 근거(공식 문서·pub.dev 릴리스 동기화·오픈소스 라이선스 고지)를 갖추고 있음:

영역	권장	리스크
모노레포	pub workspaces + 선택적 Melos 8.3	낮음
스캐폴딩	`package:mason` 코어 인프로세스 링크	낮음 — `mason_cli` 셸아웃 금지(9개월 무릴리스)
에디터 코어	`re_editor` 0.10.0	높음 — 10만 줄 파일 성능 미검증, flutter#128575(TextField 대용량 성능) 아직 open
하이라이팅	LSP 시맨틱 토큰 정규화	낮음 — Lumide가 검증한 설계
LLM 클라이언트	`openai_dart` + `anthropic_sdk_dart`	낮음 — 동일 메인테이너, 릴리스 동기화
MCP	`mcp_dart` 2.4.x	낮음
ACP	`acp_dart` 포크 또는 직접 구현	중간 — v1 전용, 5개월 무갱신, v1/v2 병행 설계 필요. 다만 생태계 자체는 가속 중(보강 조사 참고)
UI	`material_ui`/`cupertino_ui` 1.0	낮음 — 기존 패키지 2026-11 stable deprecation 예정이라 새 프로젝트는 새 쪽이 맞음
한글 IME	미해결	높음 — Lumide도 못 고친 버그(이슈 #64)

가장 위험한 두 가정(로드맵 1단계가 정확히 이걸 겨냥): (1) re_editor 대용량 성능, (2) 한글 IME. 둘 다 실패 시 나머지 설계 전체가 재검토 대상이 되는 게이팅 리스크.

Recommendations

Input Items for Planning Stage

Specification 단계(다음 단계)에서 반드시 확정해야 할 항목:

1차 사용자 확정 — P1(내부 도그푸딩) vs P2(외부 판매) vs 순차(P1→P2). 비전 문장·North Star·MVP 범위가 전부 이 답에 종속됨.
MVP 범위 — 설계 노트의 6단계 로드맵(1: 리스크 검증 2~3주 / 2: 모노레포 골격 1~2주 / 3: ACP 클라이언트 2~3주 / 4: bricks 엔진 3~4주 / 5: 자체 런타임+멀티 LLM 4~6주 / 6: 닫힌 검증 루프 지속) 중 어디까지가 "Planning 단계가 다루는 첫 PRD/Tech Spec의 범위"인지. 전체를 한 PRD로 묶을지, 단계별로 쪼갤지.
한글 IME·re_editor 성능 검증을 Specification 이전에 스파이크할지, Planning 이후 첫 스토리로 넣을지 — 게이팅 리스크이므로 순서에 영향.
GitHub 원격 저장소 및 ZenHub 워크스페이스 연결 — 현재 미설정. Breakdown/Launch 단계의 PR 병합·이슈 생성이 이걸 전제로 함(.pipeline/cocode.yaml blockers 참고).
Serverpod 4/SSPL-1.0 라이선스 검토 — cocode ADE 제품 자체에 Serverpod 서버 패키지를 임베드/재배포할 계획이 있다면 사전 법무 검토 필요(설계 노트 명시 경고).

Generated by cc-product Discovery stage (BMAD v6) · 2026-08-25