장 01
매니페스토
Deep Work Plan(DWP)은 AI 코딩 에이전트의 구조화된 자율 실행을 위한 Markdown 전용 방법론입니다. 모호한 목표를 검토 가능한 계획 — 하나의 스펙 — 으로 바꾸어, 에이전트가 컨텍스트를 잃거나 즉흥적으로 일관성 없는 결과로 빠지지 않고 실행하고, 멈추고, 재개하고, 보고할 수 있게 합니다.
에이전트를 위한 깊은 작업
이 이름은 그것이 만들어 내는 실천을 그대로 묘사합니다. 의지력이 아니라 구조로 지탱되는, 인지적으로 까다로운 작업에 대한 집중되고 지속적인 노력 말입니다. 깊은 작업을 사람에게 가치 있게 만드는 바로 그 속성 — 방해 없는 집중을 긴 시간에 걸쳐 유지하는 것 — 이 AI 코딩 에이전트가 여러 시간 또는 여러 날에 걸친 작업을 끝내는 데 필요한 것입니다. Deep Work Plan은 그 구조를 제공하며, 그렇게 함으로써 리포지토리를 AI-first이며 에이전트가 조종 가능한 코드베이스로 바꿉니다.
계획이 없는 에이전트는 결코 시간을 비워 두지 않고, 아무것도 기록하지 않으며, 방해받을 때마다 맥락을 전환하는 지식 노동자처럼 행동합니다. Deep Work Plan은 에이전트에게 비워 둔 캘린더와 작성된 브리프에 해당하는 것을 줍니다. 즉, 한정된 범위, 명확한 순서, 그리고 진행 상황을 기록하는 견고한 장소입니다.
방향이 곧 증폭기다
AI 코딩 에이전트의 역량은 모델보다 주어진 방향의 품질에 더 좌우됩니다. 유능한 모델이 모호한 요청을 향하면 모호함을 증폭하고, 같은 모델이 정밀한 스펙을 향하면 정밀함을 증폭합니다. 모델이 발전할수록 이 격차는 좁아지기보다 벌어집니다 — 병목이 상류로, 즉 코드를 작성하는 일에서 작업을 정의하는 일로 옮겨 갑니다. 관건이 되는 기술은 더 이상 실행이 아니라 방향입니다.
이는 잘 위임한다는 것이 무엇인지 다시 정의합니다. 좋은 위임은 에이전트에게 작업을 요청하는 것이 아니라, 올바르게 실행될 수 있을 만큼 명확하게 작업을 정의하는 것입니다. 즉 목표, 제약, 에이전트가 그렇지 않으면 갖지 못할 컨텍스트, 그리고 성공 여부를 가르는 기준입니다. 가치의 대부분은 실행이 시작되기 전에 만들어집니다.
Deep Work Plan은 그 상류 작업을 견고하고 반복 가능한 형태로 수행하는 규율입니다. 두 기둥은 좋은 방향의 두 절반입니다. 스펙은 “올바름“이 어떤 모습인지를 명시하고, **하니스(harness)**는 에이전트가 거기에 도달하도록 컨텍스트와 도구를 제공합니다. 둘이 함께 모델의 원초적 능력을 신뢰할 수 있는 엔지니어링으로 바꿉니다 — 여러 시간 동안 실행되는 작업 전반에 걸쳐 유지되고, 세션마다 바뀌는 에이전트들 사이에서도 보존됩니다.
설계상 스펙 주도
이것이 방법론의 첫 번째 기둥이며, “하니스“와 마찬가지로 분명하게 정의할 가치가 있습니다.
스펙 주도 개발이란. 일반적인 프롬프트 주도 작업에서 진실 공급원은 대화입니다. 에이전트에게 무언가를 요청하면 파일을 편집하고, 의도에 대한 유일한 기록은 흘러가 버려 다시는 검토되지 않는 채팅 로그뿐입니다. 스펙 주도 개발(SDD)은 이를 뒤집습니다. 먼저 무엇이 참이어야 하는지 — 목표, 범위, 인수 기준, 완료를 증명하는 검증 — 를 적어 두고, 대화가 아니라 그 작성된 스펙이 진실 공급원이 됩니다. 그러면 에이전트는 한 줄 프롬프트에서 즉흥적으로 만들어 내는 대신 스펙에 맞춰 실행합니다.
DWP가 이를 구현하는 방식. Deep Work Plan에서 계획이 곧 스펙입니다. 목표가 검토 가능한 계획이 되고, 계획은 원자적 작업으로 분해되며, 각 작업은 명시적인 인수 기준과 검증 게이트를 담고, 완료 프로토콜이 그것들에 대비해 작업을 확인합니다. 계획 → 작업 → 게이트 → 완료는 구체적이고 실행 가능하게 만든 SDD입니다.
왜 중요한가. 스펙을 먼저 작성하면 세 가지로 보상이 돌아옵니다. 방향 이탈을 줄입니다. 에이전트가 흐려져 가는 요청의 기억이 아니라 명시된 기준으로 측정되기 때문입니다. 작업을 검증 가능하게 만듭니다. 모든 게이트가 합격이거나 불합격이기 때문입니다. 그리고 작업을 재개 가능하게 만듭니다. 스펙이 어떤 단일 세션이나 에이전트보다 오래 살아남기 때문입니다 — 다른 에이전트가 내일 이어받아 “완료“가 정확히 무엇을 뜻하는지 알 수 있습니다.
DWP가 다른 점. 이 아이디어를 중심으로 GitHub Spec Kit, Amazon Kiro, Tessl을 포함한 더 넓은 스펙 주도 흐름이 형성되었습니다. 그러한 접근은 특정 도구나 플랫폼에 묶이는 경향이 있습니다. DWP는 의도적으로 다릅니다. 도구에 비종속적이고 리포지토리 네이티브입니다. 스펙은 일반 Markdown으로 리포지토리 안에 존재하므로, 벤더의 제품이 아니라 코드와 함께 움직입니다 — 그리고 스펙 자체가 리포지토리가 지니는 하니스의 일부이므로 두 번째 기둥과 직접 결합됩니다.
리포지토리가 하니스가 된다
이것이 방법론의 두 번째 기둥이며, 분명한 정의가 필요합니다 — “하니스“는 의미가 많이 실린 용어가 되었고, 업계의 상당수는 그것이 무엇을 뜻하는지 말하지 않은 채 사용합니다.
에이전트 하니스란. 거대 언어 모델은 그 자체로는 텍스트 예측기일 뿐입니다. 그것을 신뢰할 수 있는 엔지니어로 바꾸는 것은 그것을 둘러싼 모든 것입니다. 주어지는 컨텍스트, 호출할 수 있는 도구, 다음에 무엇을 할지 결정하는 제어 루프, 실수를 잡아내는 가드레일, 멈추고 재개할 수 있게 하는 영속적 상태 말입니다. 그 둘러싼 발판이 하니스입니다. 모델은 엔진이고, 하니스는 그 엔진을 안전하게 운전할 수 있게 하는 섀시, 조향, 브레이크입니다.
하니스 엔지니어링이란. 대부분의 팀은 그 발판을 단일 도구 — 특정 IDE, 에이전트 제품, 맞춤형 프레임워크 — 안에서 암묵적으로 구축합니다. 그래서 그곳에서만 작동하고, 도구를 바꾸는 순간 사라집니다. 하니스 엔지니어링은 그 발판을 일급 산출물로서 의도적으로 설계하는 규율입니다. Deep Work Plan은 그것이 어디에 있어야 하는지에 대해 하나의 강한 입장을 취합니다. 도구가 아니라 리포지토리 자체에.
왜 리포지토리가 올바른 장소인가. 하니스가 리포지토리 안에 있으면 코드와 함께 움직이고, 리포지토리를 여는 모든 에이전트가 그것을 물려받으며, 다른 어떤 코드와도 마찬가지로 버전 관리되고, 검토되고, 개선됩니다. DWP는 하니스의 각 부분을 구체적이고 견고한 산출물로 설치합니다.
| 하니스 요소 | 무엇을 제공하는가 | DWP가 리포지토리의 어디에 두는가 |
|---|---|---|
| 컨텍스트 | 에이전트가 알아야 할 것 | AGENTS.md, docs/, 모듈별 README |
| 도구 | 에이전트가 할 수 있는 것 | .agents/ 스킬, 에이전트, dwp-* 명령 |
| 제어 루프 | 작업이 진행되는 방식 | Deep Work Plan: 계획 → 원자적 작업 → 게이트 → 완료 |
| 가드레일 | 올바름을 지키는 것 | 명시적인 인수 기준과 검증 게이트 |
| 상태 | 중단을 견디는 방식 | gitignore된 .dwp/ 계획, 초안, 진행 로그 |
- 컨텍스트
- 도구
- 제어 루프
- 가드레일
- 상태 / 재개성
모든 요소가 도구의 기능이 아니라 리포지토리 안의 파일이기 때문에, 하니스는 본질적으로 이식 가능합니다. 그것이 나머지 방법론이 기대고 있는 한 줄의 주장입니다. 리포지토리 자체가 하니스가 된다. 그래서 어떤 에이전트든 어떤 리포지토리든 조종할 수 있습니다 — 도구별 맞춤 프레임워크 없이.
구조화된 자율 실행이 왜 중요한가
현대의 AI 코딩 에이전트는 유능하지만 방향이 없습니다. 단순하지 않은 작업을 하나 맡기면 즉시 파일을 편집하기 시작하고, 무엇을 바꿨는지 놓치며, 검토하기 어렵고 재개하기 불가능한 결과를 만들어 내는 경향이 있습니다.
DWP는 각 실패를 직접 다루는 가벼운 구조를 부과합니다.
- 검토 가능한 작업 — 작업은 명시적 범위와 인수 기준을 갖춘 순차적 단위로 분해됩니다.
- 영속화된 상태 — 진행 상황이 기록되어 작업이 중단을 견디고 세션과 에이전트를 넘어 재개될 수 있습니다.
- 표준화된 문서화 — 사람과 에이전트가 공통 형식을 통해 하나의 멘탈 모델을 공유합니다.
- 에이전트 이식성 — 방법론은 재구현이 아니라 얇은 어댑터를 통해 어떤 에이전트와도 작동합니다.
끝까지 Markdown
DWP는 소프트웨어가 아니라 구조를 정의합니다. 설치할 런타임도, 의존성 트리도, 종속도 없습니다. 계획, 작업, 실행 로그는 모두 일반 Markdown으로, 어떤 에이전트든 읽을 수 있고, 누구든 검토할 수 있으며, 어떤 버전 관리 시스템이든 깔끔하게 추적할 수 있습니다. 그 결과는 읽고, 감사하고, 신뢰할 수 있는 실행입니다.