Skip to content
Deep Work Plan이 오늘 Product Hunt에 출시됐어요 추천하기

비교

Deep Work Plan과 대안들

상황에 맞는 계층을 고르세요. 각 대안은 그 자신의 관점에서 설명되고, 모든 사실은 공식 문서로 거슬러 추적되며, 이 페이지는 마지막으로 검토된 시점을 밝힙니다. 이것은 순위표가 아니라 지도입니다.

이 페이지 읽는 법

세 가지 값이 각 기능을 설명합니다. 이 값들은 도구가 얼마나 좋은지가 아니라 기능이 도구의 어디에 있는지를 말합니다.

  • 내장
  • 선택 사항 또는 확장 경유
  • 범위 외

마지막 검토:

대안들, 각자의 관점에서

스펙 주도 개발 도구

  • 스펙 주도 개발 도구

    GitHub Spec Kit

    컨스티튜션, 스펙, 계획, 작업 목록을 통해 기능을 실행 가능한 스펙으로 바꾸며, 50개가 넘는 코딩 에이전트와 통합되는 슬래시 명령으로 구동됩니다. 구현을 시작하기 전에 산출물들이 서로 일관되는지 확인할 수도 있습니다.

    이미 쓰고 있는 에이전트 안에서 반복 가능한 스펙 작성, 계획, 작업화, 구현 워크플로를 원하는 팀.

    비교 보기 공식 사이트

  • 스펙 주도 개발 도구

    OpenSpec

    각 변경을 델타 스펙(추가, 수정, 제거)과 시나리오를 갖춘 RFC 2119 요구사항의 제안으로 포착한 뒤, 살아있는 스펙으로 보관합니다. 변경이 수락되기 전에 제안의 완전성과 시나리오 커버리지를 검사하는 검증기도 갖추고 있습니다.

    기존 시스템에서 스펙이 변경 한 번에 한 걸음씩 자라나기를 원하는 팀.

    비교 보기 공식 사이트

  • 스펙 주도 개발 도구

    Amazon Kiro

    EARS 스타일 요구사항에서 설계로, 다시 작업으로 이동하는 스펙을 갖춘 에이전트형 IDE와 CLI이며, 편집기 이벤트에서 실행되는 스티어링 파일과 훅을 제공합니다. 기존 코드베이스에 대한 스펙을 생성해 설계를 시작하기 전에 요구사항의 공백을 찾아낼 수도 있습니다.

    AWS 지원 도구와 함께 편집기에 스펙 주도 개발이 내장되기를 원하는 개발자.

    비교 보기 공식 사이트

에이전트 워크플로 프레임워크

  • 에이전트 워크플로 프레임워크

    BMAD Method

    전문화된 에이전트 역할(분석, 제품, 아키텍처, 개발, 품질)이 브리프, 요구사항, 아키텍처 문서, 스토리 파일을 만들어 내는 애자일 프레임워크입니다. 완료의 정의(Definition of Done)에는 각 스토리가 완료로 인정되기 전에 팀원이나 AI 동료 리뷰어의 검토를 받도록 요구하는 절차가 포함되어 있습니다.

    역할 기반 세레모니를 선호하고 에이전트 작업을 위한 완전한 애자일 라이프사이클을 원하는 팀.

    비교 보기 공식 사이트

  • 에이전트 워크플로 프레임워크

    Superpowers

    브레인스토밍, 작은 테스트 우선 단계로 계획하기, 서브에이전트로 실행하기, 완료 전에 검토하기 위한 스킬 라이브러리와 워크플로이며, 여기 소개된 다른 어떤 대안보다 많은 코딩 에이전트 호스트와 통합되어 있고, 모든 작업에 2단계 서브에이전트 검토(스펙 준수 확인 후 코드 품질 확인)를 적용합니다.

    코딩 에이전트 안에서 규율 있는 테스트 주도 실행을 원하는 개발자.

    비교 보기 공식 사이트

  • 에이전트 워크플로 프레임워크

    GSD Core

    .planning 디렉터리, 요구사항 id, 단계 계획, 새 컨텍스트 실행, 그리고 각 계획의 요약에서 추출한 사용자가 관찰 가능한 산출물에 대한 검증 패스를 갖춘 계획 시스템입니다. 연구·계획·실행을 일회용 서브에이전트에서 실행하고 콘텐츠 지문(fingerprint) 검사로 오래된 검증을 잡아내어, 컨텍스트 저하(context rot)에 정면으로 맞서도록 설계되었습니다.

    적은 세레모니로 컨텍스트 엔지니어링과 검증을 원하는 1인 개발자와 소규모 팀.

    비교 보기 공식 사이트

  • 에이전트 워크플로 프레임워크

    Gentle-AI

    이미 사용 중인 코딩 에이전트를 세션과 모델을 넘나들며 라우팅도 수행하는 영구 메모리, 엄선된 스킬, MCP 서버, 페르소나, 그리고 선택적인 Spec-Driven Development 또는 Receipt-Driven Development로 구성합니다. 설정은 기본적으로 에이전트의 전역 설정에 기록되며, 워크스페이스 범위 설치는 선택 사항입니다.

    세션 전반에 걸쳐 작업을 기억하고 필요할 때 근거 자료를 생성할 수 있는, 구성된 에이전트 생태계를 원하는 개발자를 위한 것입니다.

    비교 보기 공식 사이트

AI-native SDLC

  • AI-native SDLC

    Claude's AI-native SDLC

    Plan과 Design에서 Build, Test, Deploy, Maintain으로 이어지는 6단계 루프이며, 각 단계마다 사람의 승인을 거치도록 게이트가 걸려 있고, 단계 사이마다 저장소에 내구성 있는 산출물을 커밋하며, 배포 전에 보안 전용 검토 패스를 두고, 선행 및 후행 딜리버리 지표를 공개하는 지속적인 평가를 갖추고 있습니다.

    Claude Code의 엔드투엔드 소프트웨어 제공 플레이북과 그 프로덕션 피드백 루프를 평가하는 팀을 위한 것입니다.

    비교 보기 공식 사이트

벤더 네이티브 계획 모드

  • 벤더 네이티브 계획 모드

    벤더 네이티브 계획 모드

    에이전트 제품은 개방적이고 벤더에 종속되지 않는 AGENTS.md 및 Agent Skills 표준을 기반으로 계획 모드, 지시사항 파일, 스킬을 제공할 수 있지만, 계획 모드의 정확한 동작은 여전히 벤더, 클라이언트, 버전에 따라 달라집니다. 특히 Agent Skills는 시작 시 짧은 요약만 불러오고 활성화될 때 전체 지시사항을 불러오므로, 사용하지 않는 기능을 컨텍스트 밖에 둘 수 있습니다.

    방법론을 채택하지 않고 단일 에이전트 안에서 계획을 원하는 모든 사람.

    비교 보기 공식 사이트

Deep Work Plan이 가져오는 것

  • 도구 비종속이며 리포지토리 네이티브

    하니스와 계획은 리포지토리 안의 파일이며, AGENTS.md와 Agent Skills 표준을 따르는 어떤 에이전트든 읽습니다. 에이전트를 바꿔도 계획을 잃지 않습니다.

  • 각 작업이 건드린 것에서 선택되는 검증

    모든 작업은 자신의 변경 표면을 선언하고 변경된 동작과 그 소비자의 테스트를 실행하며, 영향을 한정할 수 없을 때는 전체 스위트로 넓힙니다. 선택된 테스트가 0개인 경우는 결코 통과가 아닙니다.

  • 보안 점검을 동반하는 하나의 Final Review

    계획은 누적된 변경 집합에 대한 보안 검토 — 필수 로컬 diff 리뷰 포함 — 와 최종 상태 검증으로 닫힙니다. 치명적 발견은 완료를 막습니다.

  • 세션과 에이전트를 넘어 살아남는 상태

    README 체크박스, 작업 로그, 범위가 한정된 작업 인덱스, 기계 판독 가능한 상태 파일이 모든 경계에서 기록되므로, 다른 세션이나 다른 에이전트가 디스크에서 이어갑니다. 계획 생성이 중단된 경우조차 복구 가능합니다.

  • 리포지토리 자체를 위한 적합성 검사기

    읽기 전용 스크립트가 하니스와 모든 계획을 스펙에 대비해 검증하고, 두 가지 계획 수명 주기를 모두 이해하며, CI 친화적 코드로 종료합니다.

  • 측정되고 공개되는 지시사항 로드량

    커밋된 스크립트가 플로우마다 두 가지 측정값을 공개합니다 — 세션 시작 시 로드하는 진입 번들과, 실제 트리거가 발동한 이후의 엔드투엔드 경로 — 그리고 각각이 무엇을 제외하는지도 함께 공개하여, 진입 수치만으로 실행의 총비용을 읽지 않도록 합니다. 증가를 포함한 결과는 바이트로 공개되며, 토큰이나 비용 백분율로는 결코 공개되지 않습니다.

정직한 한계

Deep Work Plan에는 살아있는 스펙이나 델타 스펙 메커니즘이 없습니다; 그 부분에서는 OpenSpec과 유사한 도구가 더 강합니다. 방법론의 독립적인 벤치마크는 아직 존재하지 않습니다. 다만 자체적으로 새로운 에이전트 대상 평가가 동결된 프로토콜 아래 이미 실행되었습니다 — 규모는 작습니다: 단일 워크로드, 구성별 두 기능, 한 대의 머신 — 그 결과는 양방향으로 공개됩니다: 하네스가 있는 트리의 에이전트는 두 작업 모두에서 바이트를 덜 읽었고, 현재 버전의 세션은 하네스가 보고한 모델 입력과 출력을 이전 메이저 버전보다 덜 소비했습니다. 반면 워크로드별 토큰 순 방향은 섞여 있었고 경과 시간 우위는 주장되지 않습니다. 지시사항 로드 원장은 로드된 바이트를 측정하며, 토큰, 비용, 결과가 아닙니다. 진입 번들 수치는 실행에서 실제로 읽히는 양의 상한이 아닙니다. DWP는 의도적으로 저장소 범위로 한정되어 있습니다. 프로젝트 간 메모리 시스템도, 역할 기반 에이전트 프레임워크도, IDE도 아니므로 이러한 축에서는 경쟁하지 않습니다 — 그런 능력이 필요한 작업에는 이를 제공하는 도구와 함께 사용하세요.

정확성을 유지하도록 도와주세요

정확성을 유지하도록 도와주세요

이 페이지는 표시된 날짜에 검토되었으며 요청에 따라 수정됩니다. 당신의 도구 설명이 오래되었거나 불완전하다면 이슈를 열어 주세요. 수정하겠습니다.

이슈 열기