Claude Code의 사양 주도 개발(SDD) 스킬은 EARS 요구사항을 어떻게 작성하는가: Kiro 방식과 cc-sdd의 SKILL.md

Claude Code에서 사양 주도 개발(Specification-Driven Development, SDD)을 진행하려면, 요구사항을 EARS 표기법으로 작성하게 하는 것이 테스트에 적용하기 가장 쉽습니다. Kiro 방식을 그대로 사용하고 싶다면 jasonkneen/kiro의 requirements-engineering 스킬이 적합하며, 한국어로 요구사항을 작성하고 싶다면 gotalab/cc-sdd가 좋습니다. 게이트(Gate)가 있는 범용 플로우를 원한다면 설치 수가 가장 많은 addyosmani/agent-skills의 spec-driven-development가 안전한 출발점입니다.

최종 업데이트: 2026년 10월 28일

이 기사에서 언급하는 설치 수는 skills.sh, GitHub, MCP 레지스트리로부터 매일 업데이트되는 실제 설치 수에 따른 라이브 카탈로그 값이며, 이는 2026년 10월 28일 기준입니다. 영어 버전의 전체적인 내용은 사양 주도 개발 스킬 순위 가이드에 정리되어 있습니다. 이 기사는 그중 '요구사항을 어떻게 작성하게 할 것인가'에 초점을 맞춰 각 스킬의 SKILL.md를 읽은 기록입니다.

사양 주도 개발(SDD) 스킬이 하는 일

SDD 스킬의 역할은 에이전트에게 바로 코드를 작성하도록 시키지 않고, '요구사항 → 설계 → 태스크' 순서로 문서를 만들게 하고 인간의 승인을 거치도록 하는 것입니다. 모든 스킬은 이 골격은 같지만, 차이가 발생하는 3가지 지점은 다음과 같습니다.

• 요구사항(수용 기준)을 어떤 형식으로 작성하게 할 것인가
• 프로젝트 전체의 전제(조정/Steering)를 어디에 둘 것인가
• 태스크를 어느 정도의 단위로 나누고, 요구사항과 어떻게 연결할 것인가

아래에서 이 3가지 관점에 따라 살펴보겠습니다.

EARS 표기법으로 요구사항을 작성하게 하는 방법

EARS(Easy Approach to Requirements Syntax)는 요구사항을 '조건 + 주어 + 응답'의 정해진 형식으로 작성하는 표기법입니다. 모호한 '빨리', '사용하기 쉽게' 같은 표현을 테스트 케이스에 그대로 변환할 수 있는 문장으로 대체하는 것이 목적입니다.

jasonkneen/kiro 방식: WHEN ... THEN ... SHALL

Kiro 방식의 요구사항 정의 스킬인 requirements-engineering(GitHub)은 Kiro의 SDD를 Claude Code용 스킬로 추출한 것입니다. 설치 수는 330개입니다. SKILL.md가 기본 형태로 제시하는 것은 이 형식입니다.

WHEN [triggering event] THEN [system] SHALL [required response]

그 외에 IF [precondition is met] THEN [system] SHALL ...와 같은 조건형, AND/OR로 조건을 추가하는 복합형, 상태·성능·보안을 위한 응용형 등이 나열됩니다. 실용적인 것은 '자주 하는 실수' 부분으로, 예를 들어 구현 상세를 요구사항에 작성하는 예시(

(옵션 기능)이 있고, 조건 없는 상시 요구사항이 독립된 유형으로 준비되어 있다는 점입니다. '결제 처리 중에는 로딩을 표시한다'와 같은 상태 의존적 요구사항을 WHEN 키워드를 사용하지 않고도 작성할 수 있습니다.

주어 선택 방법에도 지침이 있어, 소프트웨어의 경우 "Checkout Service"처럼 구체적인 서비스명을 사용하라고 명시되어 있습니다. 만약 전부 "시스템은"으로 처리하면 마이크로 서비스 구성에서 어느 쪽의 책임인지 알 수 없게 되므로, 이 부분이 효과적입니다.

일본어로 요구사항을 작성할 때 무엇이 달라지는가

이곳이 일본 개발자에게 실제로 차이가 발생하는 지점입니다. cc-sdd의 ears-format.md에는 트리거 키워드와 정형구(When, If, While, Where, The [system] shall)는 영어 그대로 유지하고, [event]나 [response/action]과 같은 가변 부분만 대상 언어로 번역한다는 규칙이 명시되어 있습니다. 설치 시에도 npx cc-sdd@latest --lang ja와 같이 언어를 지정할 수 있습니다.

즉, 요구사항은 다음과 같은 방식으로 작성됩니다 (cc-sdd의 ears-format.md에 있는 예시를 규칙대로 가변 부분만 일본어로 수정한 것입니다).

When ユーザーが購入ボタンを押す, the Checkout Service shall カートの内容を検証する
While 決済処理中, the Checkout Service shall ローディング表示を出す

언뜻 보기에는 일관성이 없어 보이지만, 키워드가 영어로 고정되어 있기 때문에 grep이나 간단한 스크립트로 유형별 요구사항을 개수하거나 테스트 케이스로 기계적으로 변환할 수 있습니다. 전체를 일본어로 번역하면 '〜했을 때', '〜인 경우' 등의 어휘 변화(揺れ)로 인해 이 부분이 무너지기 쉽습니다.

jasonkneen/kiro 스킬에는 언어 지정 기능이 없고, 예문도 모두 영어입니다. 일본어로 작성하게 할 수는 있지만, 키워드를 영어로 고정할지 여부는 사용자가 직접 프롬프트나 스테어링에 명시해야 합니다.

또한, cc-sdd의 requirements 스킬에는 판정 기준으로서 "기술에 관여하지 않고 작성할 수 있는 인수 기준은 요구사항이며, 기술 선택이 필요한 것은 설계"라는 문장이 있습니다. 이는 jasonkneen 버전의 Redis 예시와 동일한 사고방식을 1줄의 리트머스 시험지로 만든 것입니다.

스테어링 파일에는 무엇을 작성하는가

스테어링은 스펙별이 아니라 프로젝트 전체에서 매번 에이전트에게 읽히는 전제 지식입니다. CLAUDE.md와 유사한 역할을 하며, 파일을 나누어 읽기 조건을 붙일 수 있습니다 (Claude Code 측에서도 .claude/rules/에서 파일 유형별로 규칙을 나눌 수 있으므로, 사고방식이 비슷합니다).

Kiro 방식의 스테어링 생성 스킬 create-steering-documents(GitHub)는 .kiro/steering/ 하위에 파일을 만듭니다. 설치 수는 83개입니다. 읽기 방법은 세 가지가 있습니다.

• front-matter 없음: 매번의 상호작용에 항상 포함
• inclusion: fileMatch: 특정 파일이 컨텍스트에 있을 때만 포함 (예시에서는 '*.tsx|*.jsx|*.vue|*.svelte')
• inclusion: manual: 명시적으로 참조했을 때만 포함

프론트엔드 규약은 .tsx 파일을 건드릴 때만, API 설계 가이드는 필요할 때만 등 분리가 가능하여 컨텍스트를 낭비하지 않습니다. #[[file:path]]로 OpenAPI 사양이나 DB 스키마를 참조시키는 작성 방법도 포함되어 있습니다.

cc-sdd의 kiro-steering은 사고방식이 조금 다릅니다. 스테어링을 "영구적인 프로젝트 메모리"로 취급합니다. 핵심은 product.md, tech.md, structure.md 세 파일이며, 첫 실행 시에는 코드베이스로부터 생성하고(Bootstrap), 이후에는 코드와의 불일치를 감지하여 추가하는(Sync) 두 가지 모드로 작동합니다. SKILL.md에는 사용자가 수동으로 작성한 커스터마이징은 존중하며 업데이트는 추가 방식으로 진행한다는 방침이 적혀 있습니다. 기존 리포지토리에 나중에 적용한다면, 이쪽 방식이 더 수월할 것입니다.

태스크 분해는 어떤 수준(granularity)으로 자를 것인가

Kiro 방식의 태스크 분해 스킬 task-breakdown(GitHub)(설치 수 97)은 2단계 체크리스트로 태스크를 작성하게 합니다. 각 태스크 끝에 _Requirements: 1.2, 2.1_와 같이 요구사항 번호를 붙이는 것이 특징이며, 이를 통해 어떤 태스크가 어떤 EARS 요구사항을 충족하는지 나중에 추적할 수 있습니다. 적절한 세분화 정도는 "집중하여 2~4시간 동안의 작업"으로 간주되며, "Build user stuff"와 같이 내용이 없는 태스크는 나쁜 예시로 언급됩니다.

cc-sdd의 kiro-spec-tasks는 병렬 실행 가능한 태스크에 (P) 마커를 붙입니다. 병렬처럼 보이지만 안전하지 않은 태스크에는, (P)를 붙이지 않는 이유로 의존 관계를 명시하도록 지시하는 경우도 있습니다. 서브 에이전트로 병렬 구현을 진행한다는 전제라면, 이 정보의 유무에 따라 사고 발생 가능성이 달라집니다. 병렬 구현 진행 방식은 서브 에이전트 구동 개발 스킬 가이드에서도 다루고 있습니다.

이 세 가지(요구사항・설계・태스크)를 하나로 통합한 것이 Kiro 방식의 SDD 스킬 spec-driven-development(GitHub)이며, 설치 수는 428입니다. 요구사항을 마친 후 설계, 설계를 마친 후 태스크 순서로 페이즈를 건너뛰지 않도록 반복적으로 요구하고 있습니다.

Kiro 계열 외의 SDD 스킬은 어떻게 다른가?

EARS에만 집착하지 않는다면, 설치 수 기준으로 상위 3개는 다음과 같습니다(2026년 10월 28일 기준).

• addyosmani의 사양 주도 개발 스킬(GitHub): 설치 수 65,697. Specify, Plan, Tasks, Implement의 4단계로 구성되어 있으며, 스펙을 저장하면 "STOP YOUR TURN IMMEDIATELY."라고 작성하여 승인 전에 계획이나 코드로 진행시키지 않습니다. 경계를 Always do / Ask first / Never do 세 단계로 작성하게 하는 것도 팀의 암묵적인 규칙을 명문화하는 데 편리합니다.
• warpdotdev의 스펙 주도 구현 스킬(GitHub): 설치 수 28,729. specs/<linear-ticket-number>/ 아래에 PRODUCT.md를 먼저 작성하고 필요한 경우에만 TECH.md를 추가합니다. 티켓 단위로 사양을 관리하는 팀에게 적합합니다.
• tech-leads-club의 tlc-spec-driven 스킬(GitHub): 설치 수 1,209. validate_spec.py, validate_tasks.py, check_commit.py와 같은 Python 스크립트로 게이트를 검증합니다. validate_spec.py는 EARS 형식의 인수 기준도 체크합니다. 모델의 기억이 아닌 코드로 사양을 지키게 하고 싶을 때 선택할 수 있는 옵션입니다.

addyosmani 버전의 Specify 단계에 EARS 형식의 인수 기준을 작성하게 하는 조합도 충분히 가능합니다. EARS 요구사항은 그대로 테스트로 변환할 수 있기 때문에, TDD 스킬 가이드에서 소개하는 테스트 주도(Test-First) 흐름과도 궁합이 좋습니다.

결국 어떤 것을 사용해야 할까?

jasonkneen 버전은 스킬 단위로 추가할 수 있으므로, 요구사항 정의만 테스트해 보는 것도 가능합니다.

npx skills add https://github.com/jasonkneen/kiro --skill requirements-engineering

설계서나 계획 관련 스킬을 더 비교하고 싶다면, 문서/계획 스킬 순위와 문서/계획 카테고리 목록에 정리되어 있습니다.

자주 묻는 질문

Q. EARS 키워드는 일본어로 번역하지 않는 것이 좋은가요?

cc-sdd 규칙에서는 When이나 shall 같은 정형구는 영어 그대로 두고, 가변 부분만 일본어로 처리합니다. 키워드가 고정되어 있으면 요구사항을 유형별로 집계하거나 테스트로 변환하는 처리가 단순해집니다.

Q. Steering과 CLAUDE.md는 무엇이 다른가요?

둘 다 프로젝트의 전제를 작성하는 장소이지만, Kiro 방식의 Steering은 파일을 분리하고 inclusion: fileMatch나 inclusion: manual

읽어들이는 조건을 설정할 수 있습니다. 상시적으로 제공해야 하는 정보와 특정 파일을 다룰 때만 제공하면 되는 정보를 분리할 수 있다는 것이 장점입니다.

질문: 작은 버그 수정에도 사양 주도 개발(SDD)이 필요한가요?

warpdotdev 스킬은 작고 국소적인 버그 수정의 경우 사양이 필요하지 않은 경우가 많다고 합니다. tlc-spec-driven 역시 작은 기능에서는 설계와 태스크 단계를 생략합니다.

각 스킬의 최신 설치 수와 순위는 Claude Code용 사양 주도 개발(SDD) 스킬 비교 페이지에서 확인할 수 있습니다.

토론