자주 묻는 질문

Deep Work Plan은 리포지토리를 코딩 에이전트가 긴 작업을 안정적으로 수행할 수 있는 구조화된 환경으로 바꿉니다. 에이전트 스킬로 설치되어 리포지토리를 한 번 온보딩하고(`AGENTS.md` 인덱스, `docs/` 트리, 스킬과 명령의 `.agents/` 키트, gitignore된 `.dwp/` 출력 영역), 그다음부터는 모든 목표가 계획이 됩니다: 인수 기준과 검증 게이트를 각각 갖춘 원자적 작업들이 한 번에 하나씩 실행되고, 통과할 때마다 커밋되며, 어떤 에이전트든 디스크에서 다시 이어받을 수 있습니다. 계획은 보안을 감사하고 최종 상태를 검증하는 Final Review로 닫힙니다. 방법론은 MIT 라이선스이며 리포지토리를 읽을 수 있는 어떤 코딩 에이전트와도 작동합니다.

방법론 읽기

코딩 에이전트에게 실제 여러 단계로 이루어진 작업을 맡기고 그것을 끝까지 마치기를 원하는 개발자와 팀이 대상입니다. 작업이 세션 하나를 넘거나, 파일군 하나를 넘거나, 에이전트 하나를 넘을 때; 팀원이 에이전트가 멈춘 지점을 이어받을 수 있어야 할 때; 또는 "완료"가 "에이전트가 그렇다고 말했다"가 아니라 "검증됨"을 의미해야 할 때 잘 맞습니다. 한 줄 수정에는 계획이 필요 없으며, 방법론도 그렇게 말합니다: 비례적 엄격도 규칙은 대신 인라인 목표, 기준, 게이트를 권장합니다.

빠른 시작

엄격도의 트레이드오프가 아니라 표현 방식의 선택입니다. 계획은 기본적으로 Lite입니다: 앵커가 달린 작업 기록을 담은 간결한 README로, 부분적인 초안이 아니라 이미 실행 가능한 형태입니다. 처음부터 Full 계획을 요청하면 `create`는 Full 작업 파일을 직접 작성합니다; 그리고 작업의 지시 세부사항, 의존성, 계약이 검토 가능한 간결한 기록에 더 이상 맞지 않으면 계획을 Full로 확장합니다. 이후의 승격도 완료된 작업을 모두 보존합니다. 두 형식 모두 동일한 인수 기준, 검증 게이트, 증거, 필수 Final Review를 갖춥니다.

방법론 읽기

설치 가능한 스킬로 포장된 방법론입니다. 서버도, 계정도, 독점 형식도 없으며, 이미 쓰고 있는 코딩 에이전트 너머의 런타임도 없습니다. 설치되는 것은 에이전트가 읽는 지시사항, 컨텍스트 감지와 적합성 검사를 위한 작은 셸 스크립트 모음, 그리고 리포지토리가 채택하는 관례입니다. 계획이 만들어내는 모든 것은 리포지토리 안의 Markdown과 JSON이며, 어떤 도구 없이도 읽을 수 있습니다.

스펙 읽기

리포지토리 파일을 읽을 수 있는 에이전트라면 어느 것이든 됩니다. 스킬은 개방형 Agent Skills 표준과 `AGENTS.md` 관례를 따르므로, Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot 등이 평소의 스킬·지시사항 로딩을 통해 이를 가져옵니다. 방법론 자체 평가에서는 한 벤더의 에이전트가 시작한 계획을 다른 벤더의 에이전트가 양방향으로 이어받는 것이 확인되었습니다. 설치 지원 범위와 행동 증거는 호환성 매트릭스에 에이전트별로 나열되며, 둘은 결코 혼동되지 않습니다.

키트 둘러보기

세 단계입니다. 먼저 코딩 에이전트에 Deep Work Plan 스킬을 설치합니다——가장 빠른 방법은 `npx skills add DailybotHQ/deepworkplan-skill`(또는 스킬 리포지토리를 클론한 뒤 `./setup.sh` 실행)입니다. 두 번째로 리포지토리를 한 번 온보딩하여 에이전트가 `AGENTS.md`, `docs/`, `.agents/` 키트와 gitignore된 `.dwp/` 영역을 스택에 맞게 적응시킵니다: https://deepworkplan.com/init.md 를 가리키거나 `/deepworkplan-onboard` 를 실행합니다. 세 번째로 얇은 명령으로 작업을 계획하고 실행합니다: `/dwp-create <goal>` 이 계획을 빌드하고, `/dwp-execute` 가 각 게이트에 대해 작업 단위로 실행하고, `/dwp-refine` 이 진행 중인 계획을 편집하고(범위, 작업, 또는 Lite 계획을 Full로 승격), `/dwp-resume` 이 중단 후 계속하고, `/dwp-status` 는 실행하지 않고 진행 상황을 보고하고, `/dwp-verify` 는 객관적인 적합성 보고서를 생성하고, `/dwp-upgrade` 는 설치된 스킬을 기존 계획을 건드리지 않고 새 릴리스로 옮깁니다. `/` 를 intercept하는 에이전트는 `#` 을 쓰는 경우가 많습니다(예: `#dwp-execute`). 도입 엔드포인트와 빠른 시작이 같은 경로를 더 자세히 안내합니다.

빠른 시작

에이전트 스킬은 에이전트가 프로젝트 또는 사용자 스킬을 로드하는 위치라면 어디든 설치됩니다. 그런 다음 온보딩이 리포지토리 자체를 적응시킵니다: `AGENTS.md`, `docs/`, `.agents/`, 그리고 gitignore된 `.dwp/` 작업공간을 생성하거나 조정합니다. 스킬은 에이전트에게 방법론을 가르치고, 리포지토리는 다른 에이전트가 이어가는 데 필요한 컨텍스트, 키트, 계획 증거를 보관합니다.

채택 흐름 보기

리포지토리에는 Git을 권장합니다. Git의 히스토리가 복구와 리뷰 표면의 일부이기 때문입니다. 하지만 방법론은 Git 리포지토리가 없는 에이전트 작업공간에서도 실행될 수 있습니다. 그 경우 `state.json` 체크포인트와 게이트 기록을 포함한 기계 판독 가능한 상태 계층이 필요하며, 그래야 복구가 대화 기록에 의존하지 않습니다.

리포지토리 아키타입에 대해 읽기

스킬은 에이전트가 반복 가능한 절차를 수행하는 방법을 기술합니다. DWP 계획은 범위, 인수 기준, 검증 게이트, 증거를 통해 구체적인 변경을 기술합니다. 제품 스펙은 제품의 현재 동작을 기술하며 구현 이후 델타를 통해 발전합니다; 스킬과 계획도 스펙이지만, 그 정식 제품 계약을 유지하는 것이 아니라 절차와 변경을 기술한다는 점이 다릅니다.

스펙 읽기

게이트는 에이전트가 스스로 실행하는 실행 가능한 단언입니다. 사람의 승인은 실행의 양 끝에 있습니다: 실행 전에 사람이 계획을 승인하고, 풀 리퀘스트 시점에 최종 diff를 검토하며, 그 사이의 실행은 자율적입니다. 모든 작업은 구체적인 명령을 명시하는데, 대개 리포지토리 자체의 품질 게이트이며 작업의 변경 표면에서 선택됩니다: 변경된 동작과 그 소비자의 테스트, 그리고 변경이 공유되거나 범위를 한정할 수 없을 때는 전체 스위트로 넓어집니다. 작업은 그 명령들이 성공적으로 종료될 때만 완료로 표시되며, 동작을 변경하는 작업은 테스트를 확장해야 합니다. 실패하면 에이전트는 먼저 작업 자체의 범위 안에 드는 것을 수리하고 게이트를 다시 실행합니다; 그 범위에서 수리할 수 없는 실패만이 작업을 차단됨으로 표시하고 실행을 멈춥니다.

핵심 루프

세 가지 방면에서 그렇습니다. 작업은 편집이 아니라 동작으로 작성됩니다: 인수 기준은 시스템이 무엇을 해야 하는지를 말하므로, 파일 이름이 바뀌거나 구현이 교체되어도 무효가 되지 않습니다. 모든 게이트는 지금 현재의 리포지토리를 기준으로 다시 실행되므로, 깨진 가정은 조용히 표류하는 대신 다음 실행에서 요란하게 실패하며, 그 실패가 다듬을 신호입니다. 그리고 문서를 동기화 상태로 유지하는 것도 작업의 일부입니다: 동작을 변경하는 작업은 그것을 설명하는 문서와 에이전트 대면 키트를 자기 게이트 안에서 함께 갱신합니다. 모든 실행은 리포지토리를 처음 발견했을 때보다 에이전트에 더 준비된 상태로 남겨야 합니다.

방법론 읽기

가능합니다; 부분적으로 실행된 계획을 다듬는 것은 일급 기능입니다. 작업 정의와 실행 상태는 분리되어 보관됩니다: 계획은 디스크의 체크리스트에 작은 상태 파일이 더해진 것이므로, 완료된 것은 작업 텍스트와 무관하게 기록으로 남습니다. 작업이 틀린 것으로 밝혀지면 에이전트는 억지로 밀고 나가는 대신 그것을 차단됨으로 표시하고 멈춥니다. 그런 다음 아직 실행되지 않은 작업을 편집, 재정렬, 분할, 제거하면 되고, 완료된 작업은 완료된 채로 남습니다. 재개는 디스크와 실제 리포지토리에서 상태를 재구성하고 중요한 게이트를 다시 실행하므로, 그 밑에서 바뀐 것이 빠져나가지 않습니다.

핵심 루프

계획은 연속적인 검사입니다. 에이전트는 한 번에 작은 작업 하나씩 진행하고 넘어가기 전에 검증해야 하므로, 세 걸음이 아니라 한 걸음만 벗어날 수 있습니다. 모든 작업은 인수 기준과 그것을 증명하는 정확한 명령을 담고 있고, 진행 상황은 작업별 상태와 함께 리포지토리에 기록되므로, 표류는 당신에게도, 다음 세션에도, 다음 에이전트에게도 보이게 됩니다. Final Review를 포함해 모든 것이 검증되기 전까지 계획은 끝난 것이 아닙니다. 정직한 단서: 방법론은 에이전트가 애초에 약한 인수 기준을 쓰는 것까지는 막을 수 없습니다; 대신 표류를 조용한 것이 아니라 요란한 것으로 만듭니다.

핵심 루프

둘 다 아닙니다. 목표에서 한 번 생성된 뒤 작업의 일부로 유지됩니다. 계획을 코드 diff에서 다시 쓰지 않는 것은 의도된 것입니다. 코드를 쫓는 스펙은 뒤처진 거울이 되는데, 그것이야말로 이 방법론이 없애기 위해 존재하는 표류이기 때문입니다. 계획은 의도적으로 발전합니다: 게이트는 현재 리포지토리를 기준으로 다시 실행되고, 실패하는 게이트는 다듬기를 유발하며, 에이전트가 실행 중에 그 다듬기를 수행하는 동안 당신은 앞에서 승인하고 끝에서 검토합니다. 문서와 테스트는 구조상 코드와 함께 발전합니다. 갱신이 각 작업의 게이트 안에 있기 때문입니다.

방법론 읽기

진행 상황은 대화가 아니라 디스크에 살아 있습니다. README 체크박스, 각 작업의 로그, 범위가 한정된 작업 인덱스, 기계 판독 가능한 상태 파일이 모든 작업 경계에서 갱신되며, 상태 파일은 계획된 일시정지 전에 체크포인트를 기록합니다. 새 세션이나 다른 에이전트는 그 간결한 인덱스를 읽고 리포지토리 및 git 히스토리와 조정한 뒤, 끝낸 작업을 다시 하지 않고 완료되지 않은 첫 작업부터 계속합니다. 계획 생성이 중단된 경우조차 복구 가능합니다: 계획의 정체성과 의도된 작업 목록은 어떤 작업 파일보다 먼저 기록되므로, 반쯤 만들어진 계획은 추측하는 대신 완성하거나 폐기할 수 있습니다.

핵심 루프

모든 계획의 단 하나뿐인 필수 마무리 작업입니다. 순서대로: 계획이 쌓아온 전체 변경 집합에 대한 보안 점검 — AI Diff Reviewer 스킬에 의한 로컬 diff 리뷰가 필수로 포함되며, 치명적 발견은 수정되거나 명시적으로 수용될 때까지 완료를 막습니다; 최종 상태 검증 — 최종 코드에 대한 리포지토리의 해당되는 전체 테스트, lint, 타입 검사, 포맷 스위트를 의미합니다; 그리고 각 작업이 기록한 스킬 결정의 조정. 그런 다음 에이전트는 산출물, 증거, 한계를 보고하고, 임원 보고서를 한 번만 제안하며, 요청할 때만 생성합니다.

스펙

게이트 실패는 우선 수리 신호입니다: 에이전트는 작업 자체의 범위 안에 드는 것을 고치고 게이트를 다시 실행합니다. 그 범위를 벗어나는 실패는 작업을 차단됨으로 기록하고, 에이전트는 완료를 주장하기 전에 멈춥니다. 증거를 살펴보고 코드를 수정하거나 작업을 다듬은 뒤 재개할 수 있습니다; 실패한 명령은 게이트를 약화시켜도 된다는 허락이 아니라 불일치를 해결하라는 신호입니다.

에이전트 프로토콜 읽기

그 사실을 분명히 말합니다. 검사기는 종료 코드 2와 명시적인 `UNVERIFIED` 판정으로 끝납니다 — 실제로 검증하지 않은 통과를 출력하는 일은 결코 없습니다. 환경에 유능한 인터프리터가 없거나 검사를 실행할 수 없으면, 정직한 결과는 "적합"이 아니라 "미검증"입니다. 녹색 결과는 항상 모든 검사가 실행되고 통과했음을 뜻합니다. 같은 규율이 방법론 전체를 관통합니다: 어떤 흐름도 완료를 선언하려고 게이트를 약화하거나 위조하지 않습니다.

적합성 계약

예, 계획이 사전에 승인되었고 필요한 상태 계층을 갖추었으며 에이전트에 한정된 권한이 주어진 경우에 가능합니다. 무인 실행은 현실이 계획과 어긋나거나, 계획된 수리 범위 밖에서 게이트가 실패하거나, 새로운 승인이나 자격 증명이 필요할 때 멈추고 차단 사유를 기록해야 합니다.

무인 실행 프로토콜 읽기

가능합니다 — 오케스트레이터 허브 아키타입이 정확히 그것을 위해 존재합니다. 허브 리포지토리가 조율하는 계획을 갖고, 각 자식 리포지토리는 자신만의 격리된 `.dwp/` 작업 영역 안에서 자신의 계획을 실행하므로, 자식이 허브의 계획 상태에 쓰는 일은 결코 없습니다. 자식의 완료 여부는 내부 문자열 검색이 아니라 각 계획 자신의 최상위 상태에서 읽히고, 허브는 어디로 이동하기 전에 자신의 위치를 기록합니다. 각 자식은 여전히 평범한 DWP 리포지토리라서 단독으로 조종할 수도 있습니다.

리포지토리 아키타입

이들은 인접한 문제를 풉니다. 스펙 주도 도구는 무엇이 바뀌어야 하는지 포착하는 데 탁월합니다: 반복 가능한 형태의 스펙, 요구사항, 변경 제안. Deep Work Plan은 에이전트가 표류 없이 수 시간을 실행하는 방법에 관한 것입니다: 온보딩된 하니스, 변경 표면에서 선택되는 작업별 검증 게이트, 디스크 위의 재개 가능한 상태, 보안 점검을 동반하는 필수 Final Review, 그리고 리포지토리 자체를 위한 적합성 검사기. 둘은 결합할 수 있으며, 스펙이나 변경 제안이 계획에 공급됩니다. 비교 페이지는 각 도구의 관점에서 기능을 나란히 놓습니다.

비교 보기

BMAD, Superpowers, Get Shit Done과 같은 에이전트 워크플로 프레임워크는 강력한 작업 방식을 제공합니다: 역할, 원칙, 테스트 우선 단계, 검증 습관. Gentle-AI는 에이전트 생태계 구성 도구로서 인접한 범주에 속합니다: 이미 사용 중인 코딩 에이전트에 세션 간 지속되는 메모리(Engram), 선별된 skill, 페르소나, MCP 서버, 선택적 Spec-Driven Development, 선택적 증거 기반 리뷰(Receipt-Driven Development)를 장착시키며, 각 에이전트의 설정 디렉터리에 기록합니다. Deep Work Plan은 이 둘과 다릅니다: 저장소에 무엇이 남고 무엇을 검증할 수 있는지에 집중합니다 — 어떤 에이전트든 사전 맥락 없이 읽을 수 있는 harness, 인수 기준과 gate를 갖춘 task 파일, 세션을 넘어 유지되는 state, CI 친화적인 종료 코드를 가진 준수 검사기, 그리고 각 flow가 로드하는 instruction byte 수를 공개적으로 측정한 값. 구조적으로 도구에 구애받지 않으며 핵심 루프에 서비스, 제공자, 시크릿을 전혀 추가하지 않습니다. 이 계층들은 공존할 수 있습니다: 프레임워크와 Gentle-AI는 에이전트가 작동하는 방식을 형성하고, Deep Work Plan은 긴 작업을 저장소 내에서 지속 가능하고 검증 가능하게 만듭니다. 비교 페이지는 각 접근 방식이 어디에 내장되어 있는지, 선택적인지, 범위 밖인지를 보여줍니다.

비교 보기

내장 계획 모드도 유용하며, Deep Work Plan은 같은 기반 — `AGENTS.md` 관례와 개방형 Agent Skills 표준 — 위에 세워집니다. 차이는 계획이 어디에 사는지, 무엇이 그것을 강제하는지입니다. 네이티브 계획은 보통 리포지토리 밖에 살며 세션과 함께 만료됩니다; Deep Work Plan은 계획과 그 상태, 증거를 리포지토리 안에 기록하므로 다른 에이전트나 팀원이 그것을 이어갈 수 있고, 모든 작업은 실행 가능한 게이트와 기록된 로그를 담습니다. 사고에는 계속 에이전트의 계획 모드를 쓰시면 됩니다; 방법론은 지속적이고 검증 가능한 실행 루프를 더합니다.

비교 보기

온보딩은 비파괴적입니다: 기존의 `AGENTS.md`, `docs/`, `.agents/`, `CLAUDE.md`를 감지하고 덮어쓰는 대신 조정하며, 무언가를 교체하기 전에 묻습니다. 실제 명령을 담은 `AGENTS.md` 인덱스, 이유가 담긴 `docs/` 트리, 모듈별 문서, 얇은 `dwp-*` 명령의 `.agents/` 키트, gitignore된 `.dwp/` 출력 영역, 검증된 테스팅 맵, 그리고 필수 로컬 코드 리뷰(AI Diff Reviewer 스킬 더하기 리포지토리 맞춤 리뷰 확장)를 작성합니다. 그런 다음 자기 점검과 적합성 검사기를 실행해 무엇이 만들어졌는지 볼 수 있게 합니다. 이전 표준에서 온보딩된 리포지토리는 빠지거나 오래된 부분만 조정하는 표적 harness 업그레이드를 받습니다.

채택 엔드포인트

서로 다른 두 가지 업그레이드가 있고, 흐름은 이들을 분리합니다. 리포지토리 harness — `AGENTS.md`, `docs/`, `.agents/` 키트 — 는 온보딩을 다시 실행해서 조정되며, 빠지거나 오래된 부분만 채웁니다. 스킬 자체는 `/dwp-upgrade` 로 움직입니다: 최신 공개 릴리스를 읽기 전용으로 확인하고, 여러분이 받아들인 정확한 태그를 검증해서 설치한 뒤, 온보딩을 처음부터 새로 실행합니다. 흐름 전체가 명시적 동의로 진행되고, 로컬 적응은 덮어쓰지 않고 비교해 보존되며, `.dwp/` 는 결코 이전되지 않습니다 — 기존 계획은 기록된 형태를 유지한 채 계속 실행됩니다.

채택 엔드포인트

예. 애드온은 선택적으로 채택하는 계층이며, 아무것도 설치하지 않은 리포지토리도 완전히 DWP에 적합합니다. Devcontainer, Dailybot 보고, 의존성 업그레이드, 디자인 시스템 지원, 선택적 CI 리뷰는 리포지토리에 맞고 명시적으로 수용할 때만 제공됩니다.

애드온 둘러보기

DWP는 툴체인의 부재를 무료 통과권으로 취급하지 않습니다. 온보딩 동안 에이전트는 스택에 맞는 검증 설정을 제안하고, 그 명령을 리포지토리 문서에 기록하며, 이후 게이트의 목표로 그 명령을 사용합니다; 제안 내용은 검토할 수 있도록 계속 보입니다.

에이전트 프로토콜 읽기

방법론과 스킬은 MIT 라이선스이며 무료입니다; 핵심 플로우에는 서비스도, API 키도, 텔레메트리도 없습니다. 효율은 각 플로우가 **진입 시점에** 로드하는 지시사항 바이트 수 — 세션 시작 시의 번들 — 로 보고되며, 플로우 자체의 트리거가 실제 작업이 계속될 때 추가로 로드하는 양을 더한 이름 붙은 **엔드투엔드 경로**와 함께 공개됩니다(예를 들어, 실행까지 이어지는 재개는 일반적으로 진입 번들의 몇 배를 로드합니다). 두 수치 모두 세션의 상한이 아닙니다: 실제 실행은 저장소 자체의 파일, 도구 출력, 계획의 작업 파일도 읽으며, 이 원장은 그중 어느 것도 세지 않습니다. 두 수치는 모두 스킬과 함께 커밋된 스크립트가 측정하고 릴리스 베이스라인마다 다시 측정하여 평가 원장에 공개하며, 증가는 감소만큼 평범하게 보고됩니다. 바이트 목록은 그런 것을 입증하지 못하므로 토큰 백분율이나 비용 절감으로 보고하지 않습니다. 이제 동결된 프로토콜 아래에서 새로운 에이전트 대상의 공개 평가가 실행되었습니다: 동일한 두 기능을 하네스 없이, 이전 메이저 버전으로, 현재 버전으로 — 각각 깨끗한 클론에서 구축했습니다. 그 결과, 하네스가 있는 트리에서 작업한 에이전트는 두 작업 모두에서 더 적은 바이트를 읽었고, 현재 버전의 기능 세션은 두 작업 모두에서 이전 메이저 버전보다 적은 모델 입력과 출력을 소비했습니다 — 하네스가 보고한 값이며 단일 워크로드 기준입니다. 이 평가는 정직한 한계도 밝혔습니다: 온보딩은 플로우가 사용될 때에만 회수되는 일회성 비용이고, 워크로드별 토큰 순 방향은 섞여 있었으며, 경과 시간 우위는 주장하지 않고, 새로운 에이전트는 스스로 플로우에 들어가지 않습니다 — 플로우는 사용자나 에이전트가 호출하는 명령입니다.

신뢰와 공개