일반 사용자를 위한 소프트웨어 요청 콘솔

만들고 싶은 소프트웨어를 AW에게 말하세요.

AW는 요청을 스펙, 코드 변경, 검증 증거, 리뷰 가능한 딜리버리 산출물로 바꿉니다.

시작
자연어 요청
게이트
작업 전 범위 승인
결과
프리뷰, 리포트, PR

Request Console

IDE를 열지 않고 소프트웨어를 요청하세요.

승인 필요
서비스 요청용 고객 포털
  1. 스펙
  2. 구현
  3. 검증
  4. 승인
  5. 완료
신규 고객 온보딩 체크리스트승인 대기
Stripe 인보이스 결제 흐름완료

내 요청

인터넷 연결 문제진행 중
결제 문의응답 대기
로그인 문제해결됨

기존 AI 하니스 어려우신가요?도깨비 하니스로 쉽게 자율 출하.

아키텍처 · 7단계

한 줄 요청이 PR 이 되기까지

  1. 1요청

    기획자/PM이 자연어 한 줄로 의뢰합니다. 코드는 한 줄도 쓰지 않습니다.

  2. 2스펙 제안

    도깨비가 spec.md 초안을 씁니다. 사람이 한 번 승인하면 본격 작업이 시작됩니다.

  3. 3에이전트 호출

    Claude / Codex / Gemini / Ollama 중 작업에 맞는 모델을 자동으로 골라서 호출합니다.

  4. 4리뷰 / 픽스 루프

    다른 에이전트가 리뷰하고 픽서가 수정합니다. 사람 개입 없이 통과할 때까지 반복합니다.

  5. 5AOP 게이트

    보안, 클린 아키텍처, 관측성 등 10개 영역을 정적 분석으로 검증합니다. Security HIGH 는 면제 불가.

  6. 6원장

    모든 결정과 이유를 JSONL append-only 로 기록합니다. 나중에 누가 왜 무엇을 했는지 추적 가능합니다.

  7. 7PR

    GitHub PR 을 만들어 트러스트 리포트와 함께 사람에게 전달합니다. 머지/배포는 사람이 결정합니다.

기존 흐름 그대로

기존 워크플로의 어디에 끼워 넣는가

  1. 기획자
  2. 도깨비
  3. GitHub PR
  4. 기존 CI
  5. 코드 리뷰
  6. merge
  7. 배포

기존 도구를 안 바꿔도 됩니다. GitHub Actions, Slack 코드 리뷰, 기존 배포 파이프라인 — 그대로 유지하시고, 도깨비는 요청 → PR 만드는 단계까지만 맡습니다. 그 뒤는 평소처럼 사람이 결정합니다.

vs Claude Code · Codex · Cursor · Aider

다른 AI 코딩 도구와의 비교

기능도깨비Claude CodeCodexCursorAider
스펙 게이트 (사람 승인 1회)
원장 (모든 결정 + 이유)
픽스 루프 (자동 반복)부분부분부분
AOP 게이트 (10개 영역)
병렬 에이전트
트러스트 리포트 (PR 동봉)
며칠 단위 자율 작업

"부분" = 있긴 하나 약함 (스펙 게이트/원장/AOP 가 없음).

운영자가 보는 화면

도깨비가 일하는 동안

homepage.rs · diff
@@ push_developer_hero(&mut body, language);
+ push_d1_architecture(&mut body, language);
+ push_d9_workflow_fit(&mut body, language);
+ push_d7_comparison(&mut body, language);
+ push_d2_workspace_mock(&mut body, language);
+ push_d8_adoption_steps(&mut body, language);
  push_hero_and_request_console(&mut body, copy);
$ dokkaebi reconcile
▸ phase: implement
  agent: codex (gpt-5.4:xhigh)
  files changed: 3 · tests: 0 → 4 passing
▸ phase: review-loop
  reviewer: claude-cli → 2 findings (auto-fix)
  fixer: codex → patched ✓
▸ phase: aop-weave
  security: ✓  clean-arch: ✓  observability: ✓
▸ PR opened: #312

이게 도깨비가 일하는 동안 운영자가 보는 화면입니다. 사람은 게이트가 빨강 뜰 때만 개입합니다.

노트북에서 회사 전체까지

도입은 당신의 페이스대로 — 5분 / 1일 / 1주

5분개인 / 사이드 프로젝트
pip install dokkaebi
dokkaebi init my-app
dokkaebi intake "고객 포털을 만들어 주세요"
dokkaebi reconcile

CLI 만. GitHub 도 필요 없습니다. 노트북에서 곧장 돌아갑니다. 첫 PR 후보가 5~10분 안에 손에 들어옵니다.

1일팀 / 스타트업
dokkaebi init --github-repo your-org/your-app
dokkaebi intake "..." --approver @teamlead

GitHub PR 흐름에 자동 연동. Telegram / Slack / GitHub Review 중 승인 채널을 선택하세요. 기존 코드 리뷰 흐름은 그대로 유지됩니다.

1주회사 / 다중 레포
.github/workflows/dokkaebi-gates.yml
.harness/CONSTITUTION.md
dokkaebi cron --start
dokkaebi skills scan

CI 에 AOP 게이트를 추가하고, 회사 정책 (allowlist, 토큰 한도) 을 강제합니다. 다중 레포 / 다중 에이전트 / 권한 관리까지 켭니다.

회의적 시니어가 멈춰서 읽는 5가지

토큰은 라우터가 정한다. 멍청한 일은 T0, 비싼 모델은 정말 비쌀 때만.

  • 모든 작업은 라우팅 테이블로 4단계 tier 매핑 — T0(알고리즘, LLM 없음), T1(로컬 Ollama), T2(가벼운 클라우드/CLI), T4(고추론).
  • model별 단가는 코드에 박혀있고, 모든 호출에 USD 추정치 부착. 로컬 모델은 0 회계.
  • CostGovernor 가 reserve → commit / release 3단 트랜잭션으로 LLM 호출 게이팅. GovernedLLMClient 가 모든 non-stub 백엔드를 wrap → 우회 불가. 초과 시 BudgetExceededError 하드스톱.
  • 모든 사용량은 append-only JSONL ledger 에 기록. `dokkaebi tokens --summary / --hotspots / cost` 사후 회계.

왜 중요한가 Cursor / Claude Code 는 한 모델로 다 처리. Wand 는 task 단위 라우팅 + 호출 전 예산 reserve → "왜 이번 달에 $400 나왔지" 가 사후가 아니라 사전에 막힘.

정직하게: 공급자가 모델 가격을 바꾸면 단가표는 수동 업데이트. CLI 백엔드(Claude/Codex CLI)는 호출당 추정치만 — 정확 토큰은 외부 미노출.

Wand 가 못하는 것 — 새 알고리즘 설계, 디자인 취향, 답이 수렴 안 하는 문제.

  • Fix-retry 를 quality preset 마다 명시 캡 (basic / medium / advanced / premium). 초과 시 max_fix_retries_exceeded → failed 종착. 무한 루프 대신 escalate.
  • Review-loop 도 round 한도. 그 안에 reviewer ↔ fixer 합의 안 되면 멈춤.
  • Reverse-clone / site-clone: 동작하나 픽셀 1:1 보장 X. JS-heavy SPA 는 crawl 엔진 한계 그대로.
  • 로컬 Ollama 는 HDD 에 두면 cold-start ~2분, 대형 prompt 타임아웃 가능. 진짜 빠른 추론은 클라우드 T2/T4.
  • 'Security HIGH = waiver 불가능' (CONSTITUTION + RG-12) → 보안 결함 잡힌 spec 은 merge 불가, 정지. 의도된 실패 모드.

왜 중요한가 다른 도구는 "안 됨" 을 침묵으로 처리. Wand 는 retry / round / budget 을 숫자로 잘라놓고, 멈춘 자리에 ledger 증거를 남김. 디버깅할 게 있다.

정직하게: 멈춘 뒤 escalation UX 는 거칠다. 사람이 ledger / failure 기록을 직접 읽어야 하는 경우 많음.

예산, 승인 게이트, 모델 선택, 샌드박스 — 전부 다이얼이다. 다 잠그면 dry-run.

  • Quality preset (basic / medium / advanced / premium) 하나로 fix retry, review-loop on/off, 라운드 한도, review tier 일괄 설정.
  • 20개 release gate (RG-01~RG-20). RG-02 (HIGH/CRITICAL AOP gap 0), RG-04 (Intent-Lock 미해결 0), RG-05 (테스트 100%), RG-12 (Security 0 HIGH), RG-14 (GitHub 승인).
  • Intent-Lock — 의미 변경은 사람 결정 필수. canonical 문서 (SPEC.md / ROADMAP.md / CONSTITUTION.md) 는 proposal_only.
  • SecuritySandbox + StageToolRouter — 단계별 사용 가능 tool 정해짐. `rm -rf /`, `curl | bash` 등 deny-list. 경로 컨테인먼트 강제.
  • Self-host + 5 backend 선택. 전부 로컬 Ollama setup 합법. GitHub approval adapter 가 merge 직전 승인 이벤트 ledger 기록 필수.

왜 중요한가 Claude Code / Cursor 는 "허용/거부" 다이얼로그가 통제의 전부. Wand 는 코드 / 머신 / 예산 / 사람-승인 4축 다이얼.

정직하게: 다이얼이 많으면 학습 곡선. 디폴트 (medium) 는 합리적이나 첫 1주는 어떤 게이트가 왜 막는지 따라가는 데 시간.

Aspect 도, Tool 도, Adapter 도 — 추상 클래스 하나 상속하면 끝.

  • Aspect: AspectRunner 상속 → AOPEngine.register_aspect() 로 등록. 기본 11 aspect (security / clean_arch / observability / resilience / api_contract / test_quality / performance / llm_security 등) + 회사 룰 추가.
  • Tool: ToolRegistry.register(ToolDef) — JSON-schema 기반, P0/P1 레지스트리 plug-in. StageToolRouter 가 stage별 노출 자동 통제.
  • WorkerAdapter: 인터페이스 구현 → 자체 백엔드 (사내 모델 / 다른 CLI agent) 붙임. 현재 LLM / ClaudeCode / CodexCLI / QA / DryRun 5종.
  • LLM backend: LLMClient 베이스. 5번째 백엔드 추가는 클래스 하나.
  • Skills: install 시 scan + 사람 승인 (`skills scan / approve / install / revoke`). Routing override 도 가능.

왜 중요한가 Cursor 는 모델 메뉴, Aider 는 백엔드 메뉴 정도. Wand 는 검증 룰 (aspect) / 도구 (tool) / 백엔드 (adapter) / 라우팅 (router) 4 확장점.

정직하게: 플러그인 SDK 문서는 spec / code 안에 분산. 외부 개발자용 정리된 가이드는 빈약 — 일단 코드 읽고 상속.

MIT 라이선스. 모든 상태는 JSONL 평문. 떠나고 싶으면 .harness 폴더만 들고 가라.

  • License: pyproject.toml 명시 — MIT. 상업 이용 / 포크 / 재배포 모두 허용.
  • Self-host: 전 구간 로컬 가능 — Ollama T1/T2 + CLI agent T4. 클라우드 API 키 없이도 동작 (속도 트레이드오프).
  • Data portability: 모든 의미 상태 .harness/ 평문. decisions / actions / tokens ledger 는 append-only JSONL, schema 는 schemas/ 에 JSON Schema 로 공개. atomic write (temp → fsync → os.replace) 일관성 보장.
  • Audit trail: 모든 decision / action 에 summary_human — `cat` / `jq` 로 읽힘. `dokkaebi why / timeline / explain` 은 이 평문 위.
  • No lock-in: Wand 가 만든 코드는 그냥 코드. 별도 런타임 의존성 없음. agent-to-agent 통신 프로토콜 DCL/1 도 공개.

왜 중요한가 Cursor / Devin 등은 SaaS lock-in 기본. Wand 는 코드 / 상태 포맷 / 통신 프로토콜 모두 공개 → "내일 Wand 회사가 망해도 내 리포는 그대로 굴러간다" 가 진짜.

정직하게: MIT 라고 호스팅 서비스가 무료라는 뜻은 아님. 셀프호스트 운영 비용 (머신 / 모델 API) 은 사용자 몫. OQ 플랫폼 통합 부분 일부는 사내 — 오픈코어 모델.

AW가 만들 수 있음을 증명하는 법

AW는 직접 만들고, 스스로를 고치며 신뢰를 얻는다

AW는 100단계 능력 사다리의 실제 도구를 직접 만든다. 벽에 부딪힐 때마다 자신의 하니스 결함이 드러나고, AW는 근본 원인을 찾아 수정을 리뷰 가능한 스펙으로 만들어 다시 등반한다. 그러면 벽은 한 단계 하류로 이동한다.

  1. 등반
  2. 벽에 부딪힘
  3. 근본원인 분석
  4. 하니스 수정
  5. 재등반
  6. 벽이 하류로 이동

이것은 게이트로서의 도그푸딩이다. AW는 데모가 아니라 '직전에 못 만든 다음 도구를 만들 수 있는가'로 평가된다. L005는 사다리의 첫 완전 그린이었다 — 수용 기준만 주어졌는데도 AW는 사람의 힌트 없이 카디널리티 도구를 HyperLogLog 하이브리드로 스스로 수렴시켰다.

AW가 이미 할 수 있는 것

1

스스로 진화하는 하니스

AW는 벽에 부딪히면 자신의 엔진 결함을 진단하고, 수정을 리뷰 가능한 스펙으로 만들어 다시 등반한다. 100개가 넘는 수렴 스펙 체인이 이 루프의 결과다 — 만드는 하니스가 스스로를 고친다.

2

리버스클론 파이프라인

URL을 가리키면 AW가 크롤링하고 타입 있는 IR을 추출해 Next.js 프론트엔드·Bun/Elysia 백엔드·타입드 모노레포·Cloud Run 배포 산출물을 결정론적으로 생성한다 — 측정된 충실도(fidelity) SLA로 평가된다.

3

실행 근거 기반 수용 판정

AW는 그린 빌드를 믿지 않는다. 산출된 도구를 행위 프로브와 실행 증거로 직접 구동해, 컴파일되고 테스트는 통과하지만 실제로는 동작하지 않는 기능을 잡아낸다.

4

점진적 결정론 코드생성

커지는 결정론 코어가 LLM 없이 바이트 단위로 동일한 출력을 내고, 재현 가능한 LLM 테일이 이를 감싼다 — AW가 내보내는 결과의 더 많은 부분이 기대가 아니라 구성으로 검증된다.

다음 단계

AW가 나아가는 방향

스스로 발전하는 빌더의 복리 효과.

도깨비가 도깨비를 만들고 있습니다.

이 사이트가 증거입니다.

지금 보고 계신 페이지, 캐러셀, 카드, 숫자 — 모두 도깨비 방망이가 직접 작성했습니다. 운영자는 "이런 사이트 만들어줘" 라고만 했습니다. 코드는 도깨비가 짰고, 테스트도 도깨비가 짰고, 배포도 도깨비가 했습니다.

어제 만든 도깨비가 오늘의 도깨비를 만듭니다.

73개 스펙은 각각이 다음 스펙의 도구가 됩니다. 도깨비가 새 능력을 만들면, 그 능력으로 더 큰 다음 능력을 만듭니다. 사람은 방향만 잡아주면 됩니다.

당신이 받는 결과물은 매주 더 좋아집니다.

오늘 의뢰하시면 "이번 주의 도깨비"가 만들어 드립니다. 다음 달에 또 의뢰하시면 "한 달 더 발전한 도깨비"가 더 적은 비용으로 더 좋은 걸 드립니다. 외주는 이런 복리를 못 줍니다.

클로드, 코덱스에만 묶여 있지 않습니다.

도깨비는 단계마다 가장 잘 맞는 백엔드로 일을 보냅니다. 한 회사가 가격을 올리거나, 다운되거나, 모델을 단종해도 — 우리는 바꿉니다. 당신의 배송은 멈추지 않습니다.

대부분의 작업이 2~3개 백엔드를 동시에 거칩니다. 한 벤더에 발목 잡히는 일은 우리 리스크가 아닙니다.

AW만의 세 가지 이유

AW가 다른 세 가지 이유

1

요청에서 서브스펙 게이트까지

넓은 요청을 구현 전에 검토 가능하고 독립 테스트 가능한 작은 범위로 나눕니다.

2

원장과 증거가 남는 딜리버리

결정, 액션, 게이트, 테스트, 스크린샷, 추적, 비용, 실패 이유가 실행 기록에 남습니다.

3

리뷰/수정 루프와 AOP 품질 게이트

에이전트 결과는 PR 전달 전에 리뷰/수정 루프와 품질 게이트를 통과합니다.

요청에서 리뷰 가능한 딜리버리까지

AW 엔드투엔드 딜리버리 프로세스

  1. 요청
  2. 스펙
  3. 서브스펙 게이트
  4. 태스크
  5. 에이전트 구현
  6. 테스트/AOP
  7. 리뷰/수정
  8. 증거/원장
  9. 프리뷰/PR/배포 인계

깊이가 필요한 전문가용

깊이가 필요할 때 워크스페이스를 여세요.

AW Workspace는 실행을 점검해야 하는 팀을 위해 파일, 스펙, diff, 게이트, 로그, 검증, 에이전트 진행을 보여줍니다.

범위 조정, 증거 점검, 실행 계속을 AW에게 요청하세요...

01-overview.md

Customer Portal - 개요

고객이 서비스 요청을 만들고, 추적하고, 관리할 수 있는 역할 기반 포털을 제공합니다.

[tests] 128 passed[aop] 2 warnings[review] handoff 대기

개발팀을 위한 딜리버리 하니스

AW를 개발 프로세스에 연결하세요.

AW는 저장소, CI, 리뷰, 에이전트, 테스트, 증거, PR 워크플로에 연결됩니다. Claude Code, Codex, ScreenPlay, 커스텀 자동화를 감싸는 하니스로 쓸 수 있습니다.

비개발자용

IDE를 열지 않고 소프트웨어를 요청하고, 상태를 보고, 결과를 미리 보고, 범위를 승인하세요.

요청에서 시작

전문 개발팀용

기존 저장소, 에이전트, 체크, 리뷰, PR 인계를 감싸는 governed delivery harness로 AW를 사용하세요.

팀 연동 논의

카테고리 경계

Antigravity는 AI IDE입니다. AW는 범위 게이트, 원장 증거, 리뷰 루프를 갖춘 요청 콘솔이자 딜리버리 하니스입니다.