Feature Spec Builder

"한 마디"를 "개발 레벨 기능 요구사항"으로 바꿉니다.

핵심은 문서를 작성하는 것이 아니라 한 문장에서 명확히 드러나지 않은 내용을 체계적으로 발굴하고 보완하는 것입니다. "~ 기능이 필요합니다"라는 한 문장에는 일반적으로 역할, 시나리오, 경계, 기능 소속, 인터페이스, 의존성, 수용 검증 등 개발에 필수적인 정보의 80%가 누락되어 있습니다. 이 스킬은 "고정 차원 스캔 + 대화형 단계별 질문" 방식을 통해 이러한 격차를 메우고, 최종적으로 엔지니어링 검토를 통과할 수 있는 기능 요구사항을 산출합니다.

이 스킬의 결과물은 기능 요구사항에 한정됩니다. 인터페이스 계약 초안과 수용 기준을 포함하지만, 작업 분할 및 구현 계획은 수행하지 않으며, 작업 분할은 개발팀에 맡깁니다.

설정 영역 (최초 사용 전에 작성해 주세요)

이 스킬은 제품 고유의 좌표계와 팀 간의 규칙에 의존하여 분류 및 협업을 수행합니다. 플레이스홀더를 팀의 실제 정의로 바꿔 주세요. 주제별로 그룹화되어 있으며, 사용하지 않는 그룹은 기본값으로 두어도 됩니다.

A. 기능 좌표계

L1 = <예: 원자 능력 / 저수준 모션 및 센싱 인터페이스>
L2 = <예: 조합 능력 / 애플리케이션 레벨 개발 키트>
L3 = <예: 완전한 솔루션 / 시나리오 전달>
다섯 영역: 영역1=<…> 영역2=<…> 영역3=<…> 영역4=<…> 영역5=<…>

B. 인터페이스 규칙

API 예산 = <예: 300개 메서드 상한>   언어/바인딩 규칙 = <예: C++ core + pybind11>

C. 통합업체 및 형태

통합업체 등급 = <예: Associate / Professional / Expert>   형태 = <시뮬레이션 / 실기기 / 둘 다>
출력 디렉터리 = <기본값 feature-specs/; 결과물은 <이 디렉터리>/<기능명>/<기능명>.md 에 기록>

D. 제품 원칙 (결과물 생성 전 자체 점검 게이트의 척도)

내장 기본 원칙 사용: 예 / 아니오 (기본값=예, 전문은 references/product-principles.md 참조)
팀 커스텀/보충 원칙: <비워둘 수 있음; 작성 시 내장 기본값과 병합되며, 충돌 시 팀 원칙 우선>
충돌 우선순위: <두 가지 하드 제약은 재정의 불가: 안전 기본값, 하위 호환성은 모두 레드라인이며, 둘이 충돌할 경우 반드시 사람이 결정하도록 에스컬레이션해야 함. 나머지 원칙의 상대적 우선순위는 여기에 기입하며, 비워둘 경우 충돌 시 항상 사용자에게 결정을 요청하고 자동 정렬하지 않음>
파괴적 변경 서명자: <break로 판정될 경우 누구의 서명이 필요한지, 예: 플랫폼 아키텍처 책임자>

E. 구현 계층 × 부서 매핑 (4단계 계층 간 분해 시 owner 할당에 사용; L-Tier와 직교——L-Tier는 외부 추상화 수준, 구현 계층은 내부적으로 건드릴 기술 스택 및 부서 수를 나타냄)

구현 계층 → 담당 부서/역할 owner → 계층 간 서명자
  런타임 계층:
    2차 개발 SDK 계층            → <기입, 예: SDK/플랫폼팀>   → <서명자>
    저수준 소프트웨어(펌웨어·미들웨어)  → <기입, 예: 임베디드/펌웨어팀> → <서명자>
    알고리즘 서비스(센싱·알고리즘)    → <기입, 예: 알고리즘팀>       → <서명자>
    하드웨어(기계·전자)        → <기입, 예: 하드웨어/전자팀>   → <서명자>
  비런타임 계층 (생태계/통합/문서 기능이 여기에 해당하며, 펌웨어/알고리즘/하드웨어팀에 억지로 넣지 마십시오):
    문서 포털 계층      → <기입, 예: DevRel/문서/사이트 프론트엔드> → <서명자>
    빌드/배포 인프라 계층        → <기입, 예: SDK 빌드/DevOps>      → <서명자>
  부서 간 에스컬레이션 경로 = <예: 계층 owner → 부서 장 → 부서 간 아키텍처 검토 회의 → CTO>

설정 영역을 작성하지 않은 경우 어떻게 해야 하나요: 최소한 A 그룹(기능 계층 + 다섯 영역)은 작성하세요. 이 두 항목이 분류 정확도를 직접 결정합니다. 나머지 그룹의 다운그레이드 처리 방법은 다음과 같습니다.

A/B/C 미작성: 분류(자동 분류 단계) 시 '다음 L 계층/영역/예산/바인딩은 제 추정입니다'라고 명시적으로 선언하고 근거를 제시합니다. 본문에서 이 좌표계를 사용하는 모든 필드(계층, 기능 영역, API 예산, 바인딩 규칙은 <능력 포지셔닝>, <영향 평가·호환성·릴리스 전략>, <인터페이스 계약 초안> 각 절에 분포)에는 [확인 필요]를 표시하고, 추정값을 확정된 값으로 작성하지 않습니다. '설정 영역 실제값 보충 필요'를 <미해결 확인 사항> 절에 기록합니다.

D 미작성: 기본적으로 references/product-principles.md의 내장 기본 10개 원칙을 적용하고, <제품 원칙 자체 점검> 절에 '이번에는 내장 기본 제품 원칙을 사용합니다'라고 명시합니다. 제품 원칙 자체 점검 게이트는 어떤 상황에서도 실행해야 하며, 설정 영역이 비어 있다고 건너뛰지 않습니다.

E 미작성: 4단계 계층 간 분해에서 owner/부서/서명자는 모두 [확인 필요·할당 필요]로 표시하고, 사용자에게 보충을 요청합니다. 부서명을 임의로 만들지 마십시오.——추정한 부서 책임을 잘못된 팀에 잘못 할당하는 것이 가장 위험한 실패입니다.

F. 조직 및 프로세스 (로컬 프라이빗 설정, 회사 수준 협업용)

각 회사의 '누가 무엇을 담당하는지, 어떤 프로세스 게이트를 통과해야 하는지, 버전을 어떻게 배치하는지'는 다르고 프라이빗하므로 이 스킬에 포함하지 않습니다. 회사 수준 협업 시 references/org-process-config.md의 템플릿을 로컬 org-process.local.md 로 복사하거나(또는 scripts/init-org-config.sh 실행), 회사에 맞게 역할 맵/전달 게이트/버전 리듬 및 파이프라인 용량을 작성하세요. 로컬 프라이빗, 커밋 금지(.gitignore에 포함됨).

이 설정이 있는 경우: 결과물 생성 시 역할 맵에 따라 owner를 실제 담당자에게 할당하고, <영향 평가·호환성·릴리스 전략>에 반드시 통과해야 할 게이트와 전달물을 나열하며, 목표 버전과 작업량(인일) 대 파이프라인 용량을 표시하고, 요구사항 확정 후 변경 시 CCB(변경 제어 위원회)를 거치도록 안내합니다(세부 사항은 references/org-process-config.md 참조).

이 설정이 없는 경우: 일반 역할 플레이스홀더(예: [제품 관리자·할당 필요])를 사용하고, 사용자에게 로컬 설정을 생성할 수 있음을 안내합니다. 어떤 상황에서도 실제 사람 이름/내부 프로세스를 스킬이나 공개 회람될 문서에 작성하지 마십시오.

워크플로우

산발적인 요구사항을 받으면 다음 메인 체인을 따라 엄격하게 진행합니다:

조각 수신 → 요구사항 분류(암시적 다중 기능 식별) → 자동 분류 → 계층 간 분해 및 라우팅(각 계층 변경·owner·의존성 순서 식별) → 1차 명확화(포지셔닝·개략) → 2차 명확화(기능 세부 사항·상세) → 결과물 문서(원칙 자체 점검 게이트 통과)

1단계: 수신 및 재진술

사용자가 제공한 조각을 읽습니다. 먼저 한 문장으로 이해한 내용을 재진술합니다("제가 이해하기로는…… 맞나요?"). 사용자가 확인하거나 수정하도록 합니다. 이 단계는 처음부터 잘못된 방향으로 가는 것을 방지합니다.

2단계: 요구사항 분류 (암시적 다중 기능 식별)

산발적인 요청에는 종종 하나 이상의 요구사항이 포함되어 있습니다. 특히 채팅방/이메일 원문에서 가져온 조각의 경우, 주요 요청이 가장 눈에 띄지만, 주변에 다른 요청, 대화 중 나온 질문, 또는 목표에서 역추론된 암시적 기능이 흩어져 있습니다. 가장 눈에 띄는 것에 바로 뛰어들지 말고, 먼저 분류 스캔을 수행합니다:

조각을 완전히 읽고, 독립적으로 성립할 수 있는 각 요청을 나열합니다(하나의 동작/하나의 능력 = 하나의 후보 기능). 특히 종종 누락되는 네 가지 유형에 주의하십시오: ① 추궁에 의해 방향이 틀어진 "원래 질문"; ② 주요 요청과 관련 없이 같은 대화에서 우연히 언급된 독립적인 요청; ③ 개발팀이 "현재 지원하지 않음/직접 구현"이라고 답한 지점(종종 묻혀 있는 숨은 요구사항); ④ 고객의 궁극적인 목표에서 역추론되지만 현재 명시되지 않은 조합 능력.
이종 결과물 휴리스틱: 하나의 요청에 다른 결과물 형태(실행 가능한 코드/인터페이스 계약/문서 내용/사이트 구조/배포 패키지)가 동시에 나타나는 경우, 다중 기능으로 의심하십시오. 다른 결과물 형태는 종종 다른 owner, 다른 수용 방식, 다른 유지보수 주기에 해당하며, 혼합 작성 시 하나의 md 파일에서 검토 대상과 수용 기준이 충돌할 수 있습니다(예: "ROS 예제 제공 + 공식 사이트에 섹션 추가" = 코드 기능 + 문서 기능, owner와 수용 방식이 완전히 다름).
단일 진실 공유 소스의 연관 기능 클러스터: 분리된 여러 기능이 단일 진실 공유 소스를 공유하는 경우(예: 문서 튜토리얼 = 예제 저장소 코드 = 주요 기능 계약의 외부 투영), 각각 독립적인 문서를 작성하지만, 각 <의존성 및 선행 조건>/연관 기능에서 진실 공유 소스의 귀속을 명시적으로 고정합니다(어느 문서/저장소가 정의 권한을 가지는지, 나머지는 투영/참조임) 그리고 클러스터 내 의존성 맵을 제공합니다——<계층 간 전달 계약>의 "정의 권한 귀속" 패러다임을 재사용하여 여러 문서가 각자 다른 버전을 작성하여 일치하지 않는 상황을 방지합니다.
요청이 하나만 있는 경우, "단일 기능 확인됨"이라고 기록하고 바로 분류로 들어갑니다.
여러 개인 경우, 요구사항 분류표(후보 기능 | 출처 원문 | 성격 | 현재 상태 | 주요 요청과의 관계/의존성)를 그리고 사용자에게 이번에 상세화할 항목을 결정하도록 요청합니다.——이것은 범위 선택이며, 사용자를 대신하여 결정하지 않습니다. 선택되지 않은 항목은 <미해결 확인 사항> 절에 "연관 기능 플레이스홀더"로 남겨두어 추후 개별 프로젝트로 진행할 수 있도록 합니다.
여러 기능을 함께 작업하는 경우, 각 기능은 독립적인 기능 요구사항 문서를 각각 생성하며, 여러 요구사항을 동일한 문서에 혼합 작성하지 않습니다.——각각 후속 단계를 진행하고, 서로 '연관 기능'으로만 상호 참조하고 의존성을 명확히 표시합니다(예: D는 A+B에 의존). (참고: 하나의 기능이 계층을 넘나들더라도 하나의 md 파일만 생성하고 내부를 읽는 대상별로 절을 나누며, 여러 파일로 분할하지 않습니다. 이것은 "동일 기능 내 계층 분할/읽는 대상 분할"이며, "여러 기능 각각 독립적인 문서 작성"과 충돌하지 않습니다.)

이 단계는 전체 체인에서 가장 쉽게 건너뛰지만 결과물의 정확성에 가장 큰 영향을 미치는 단계입니다. 건너뛰면 개발팀이 받는 요구사항이 고객 요청의 일부만 포함하거나, 여러 개의 독립적인 기능을 하나로 뭉개버릴 수 있습니다.

3단계: 자동 분류

요구사항을 좌표계에 고정합니다: L1/L2/L3 중 어느 계층에 속하는지, 다섯 영역 중 어느 영역에 속하는지, 영역을 넘나드는지 여부입니다. 분류 자체가 첫 번째 암시적 문제를 드러냅니다.——깔끔하게 분류할 수 없다면, 조각이 어떤 차원에서 정보가 부족하다는 뜻이며, 이것이 바로 이후에 명확히 해야 할 격차입니다. 분류가 불확실한 부분은 기록해 둡니다.

참고: 분류는 외부 추상화 계층(L-Tier)과 기능 영역을 고정하는 것이며, "이것이 내부적으로 어떤 구현 계층을 건드리고, 어떤 부서에 속하는지"에 대한 답은 아닙니다.——그것은 다음 4단계의 작업입니다. L1 인터페이스는 2차 개발 계층만 건드릴 수도 있고, 펌웨어/알고리즘/하드웨어까지 건드릴 수도 있습니다.

비런타임 기능에 대한 L-Tier의 N/A 출구: 기능의 본질이 기존 기능의 전달/배포/설치/문서 형태인 경우(새로운 런타임 기능이 아니고, API를 노출하지 않으며, API 예산을 차지하지 않음, 예: 오프라인 설치 패키지/예제 저장소/공식 사이트 섹션——원형 H/I), L-Tier는 명시적으로 N/A (비기능 기능, 구현 계층 축에만 해당)라고 표시하고, 다섯 영역도 N/A로 표시할 수 있으며, 억지로 L 값을 할당하지 않습니다. 판단 신호: 결과물이 "배포 패키지/문서/사이트 구조"이며 "런타임 API/동작"이 아닙니다. 그重心은 빌드/배포 인프라 계층 또는 문서 포털 계층 + 외부 의존성 축(4단계)으로 이동합니다.

4단계: 계층 간 분해 및 라우팅 (계층 간 기능 필수)

분류는 "L 몇, 어느 영역"에 대한 답변만 제공합니다. 이 단계에서는 "이 요구사항이 어떤 구현 계층을 건드려야 하는지, 각 계층은 누구에게 속하는지, 선후 관계는 무엇인지, 2차 개발 SDK만으로 독립적으로 전달할 수 있는지" 에 대한 답변을 추가로 제공합니다. 많은 고객 요구사항은 2차 개발 SDK 계층에 있는 것처럼 보이지만, 실제로는 더 낮은 계층(펌웨어/미들웨어, 알고리즘 서비스, 심지어 하드웨어)에 강하게 의존하며, 이러한 계층은 종종 다른 부서에 속합니다.

references/cross-layer-routing.md의 판단 문제를 사용하여 다섯 가지 작업을 수행합니다:

계층별로 변경 필요 여부 판단: 2차 개발 SDK 계층 / 저수준 소프트웨어(펌웨어·미들웨어) / 알고리즘 서비스 계층 / 하드웨어 계층의 네 가지 런타임 계층에 대해 각 계층에 "이 계층에서 무엇을 변경해야 하는가"라고 묻습니다. 또한 두 가지 비런타임 계층(생태계/통합/문서 기능의 중심이 자주 여기에 있음)에 대해 반드시 물어야 합니다: 문서 포털 계층(공식 사이트 섹션, 예제 저장소, 문서 IA——owner는 DevRel/문서/사이트, 개발이 아님) 및 빌드/배포 인프라 계층(패키징, 다중 환경 CI, ABI/사전 컴파일——owner는 SDK 빌드/DevOps). ⚠ 결과물이 예제/패키징/설치/배포/문서인 경우(원형 H/I), 기술적으로 순수 2차 개발이라도 기본적으로 2차 개발 SDK 팀에 할당하지 마십시오.——설정 영역 E 그룹에 따라 해당 owner로 라우팅합니다(펌웨어/알고리즘/하드웨어 팀에 억지로 넣거나 기본적으로 2차 개발 팀에 던지는 것은 모두 위험한 잘못된 할당입니다). "2차 개발 계층만 건드리고, 포털/인프라 변경 없음"이라고 명확히 답할 수 있으면 "단일 계층 기능(2차 개발 SDK)"으로 기록하고 바로 5단계로 진행합니다.
최하위 변경 계층 결정(하드 게이트) + 실현 가능성 반증: 변경해야 하는 최하위 계층을 찾습니다. 특정 계층이 "지원하지 않음/확실하지 않음"이라고 답하면, 2차 개발→펌웨어→알고리즘→하드웨어 순서로 하향 탐색하여 바닥에 도달할 때까지(지원할 수 있는 계층을 찾거나 물리적으로 불가능하다고 판단) 진행합니다. 계층 바닥 도달 결론(세 가지 중 하나) 을 제시합니다: A 순수 2차 개발 전달 가능 / B 계층 간 전달 가능 / C 현재 계층에서 전달 불가능(하위 계층 미일정 또는 물리적 제약). 최하위 변경 계층이 2차 개발 SDK 계층이 아닌 경우, 이 기능은 2차 개발 계층이 독립적으로 전달할 수 없습니다.——문서의 눈에 띄는 위치에 ⚠ 2차 개발 계층이 독립적으로 전달할 수 없음: 이 기능의 최하위 변경은 <계층>에 속하며, <owner 부서>가 먼저 <능력>을 전달해야 2차 개발 계층이 캡슐화할 수 있음이라고 표시하고, <능력 포지셔닝> 절과 DoR에 기록합니다. 하드웨어/물리적 제약에 도달하면 2차 개발 계층의 인터페이스 시그니처 상세화를 즉시 중단합니다.——구현할 수 없는 계약 초안을 계속 작성하는 것은 검토 거절의 빈번한 원인입니다.
계층 간 분해표 작성 + 의존성 순서 정리 + 계층 간 전달 계약 결정: 각 계층에서 무엇을 변경할지, owner 부서, 상위 계층을 차단하는지 여부를 나열합니다. 하향식 의존성 체인을 배열합니다. 각 계층 간 의존성에 대해 '하위 계층이 상위 계층에 무엇을 노출하는지'에 대한 전달 계약(정의 권한 귀속 포함——두 부서가 각자 다른 버전을 작성하여 일치하지 않는 상황 방지)을 고정합니다.
owner 및 부서 간 확인 필요 항목 식별(각 항목은 귀속 삼중항 포함): 어떤 계층의 "변경 필요 여부/지원 가능 여부"를 판단할 수 없어 해당 부서에 확인해야 하는 항목을 부서 간 확인 필요 항목으로 나열합니다. 이 스킬의 사용자(일반적으로 제품/SDK 측)는 세션에서 하위 계층 부서의 실제 답변을 얻을 수 없으므로, 단순히 [확인 필요]로 목록에 던져서는 안 됩니다.——각 항목에는 삼중항이 포함되어야 합니다: 확인 owner(누가 해당 부서에 연락할지) | 어떤 검토 시점 전에 답변이 필요한지 | 제때 답변이 없을 경우의 기본 가정/다운그레이드 방안 (임계값 유형 [확인 필요]의 '책임자+결정 방법+기한'과 동일한 패러다임). 이것들은 종종 전체 요구사항의 중요 경로 차단 지점입니다.
결론 B/C 필수 수행: 실제 전달 가능한 결과물을 주요 서술에 다시 기록(가짜 준비 차단): 계층 바닥 도달 결론이 B 또는 C인 경우, 반드시 <한 문장 정의>와 P1 스토리를 수정하여 이번 라운드의 실제 전달 가능한 결과물만 설명하도록 합니다(예: "이번 라운드는 SDK 스텁+시그니처를 전달하며, 빔 실제 기능은 펌웨어 Q4에 의존"). 고객의 원래 요청에 따른 전체 기능을 P1으로 작성하지 마십시오.——그렇지 않으면 개발팀/고객이 읽는 준비 완료 문서와 실제로 전달할 수 있는 것이 일치하지 않으며, 이것이 가장 위험한 가짜 준비입니다. 하위 계층이 "지원하지 않으며 일정이 잡히지 않은" 경우, <계층 간 구현 및 부서 간 협업> 절에 다운그레이드/단계적 방안(mock 스텁/제한된 옵션/시뮬레이션 우선)을 제공해야 하며, 단순히 확인 필요로 표시해서는 안 됩니다.

결론 C이며 2차 개발 계층이 이번 라운드에 독립적으로 전달할 수 있는 결과물(스텁 포함)이 없는 경우 조기 중단 출구: 반증 결과 이 기능이 현재 하위 계층/하드웨어 변경이며, 2차 개발 측에서 스텁조차 의미가 없는 것으로 확인되면, 5, 6단계의 차원별 명확화를 계속하지 마십시오.(그러면 [확인 필요]로 가득 찬 빈 껍데기만 생성되어 상호작용 예산을 낭비하고 범위 규율 자체를 위반합니다). 즉시 간결한 "계층 간 라우팅 결론" 을 생성합니다: 계층 바닥 도달 결론 + 계층 간 분해표 + 계층 간 차단 및 에스컬레이션 경로 + 고객을 위한 설명을 포함하고, "이 요구사항은 현재 2차 개발 계층의 작업이 아니므로 <부서>로 이관하여 프로젝트를 시작하는 것을 권장합니다"라고 명시적으로 표시합니다.

출력 형태: 하나의 기능 = 하나의 md 파일(읽는 대상별 분할). 단일 계층이든 계층 간이든, 하나의 기능은 하나의 기능 요구사항 문서만 생성합니다. 계층 간/부서 간 내용은 여러 파일로 분할하지 않고, 동일한 md 파일 내에서 읽는 대상별로 절을 나누고(제품/검토, 2차 개발 SDK, 펌웨어, 알고리즘, 하드웨어), 문서 상단에 <읽기 가이드>를 추가하여 "읽는 대상 → 읽어야 할 절 → 각자 담당하는 것"을 명확히 나열하여 하나의 요구사항 문서에서 전체를 추적할 수 있도록 합니다. 읽는 대상별 절 템플릿과 읽기 가이드 템플릿은 references/cross-layer-routing.md <9>를 참조하십시오.

출력은 출력 템플릿의 <계층 간 구현 및 부서 간 협업> 절에 채워 넣습니다.

이 단계의 결론은 5, 6단계에서 물어볼 질문 목록을 변경합니다. 예를 들어, 고객이 set_microphone_beam_angle 빔 인터페이스를 요청했는데, 이 단계에서 펌웨어가 아직 빔 형성을 지원하지 않는 것으로 확인되면, 5단계에서는 먼저 "알고리즘/하드웨어로 연쇄 전달되는 것을 수용할 수 있는지, 이번 범위가 SDK 플레이스홀더만 하는 것인지"를 명확히 해야 하며, 직접 인터페이스 시그니처를 묻지 않습니다.

왜 별도의 단계이며, 포지셔닝보다 앞서 배치되었는가: "실제로는 펌웨어를 건드려야 하는" 요구사항이 일반 2차 개발 기능으로 처리되면, "개발팀이 인수할 수 있는 것처럼 보이지만 실제로 하위 계층에 그 능력이 없는" 가짜 준비 문서가 생성됩니다——이것이 가장 위험한 실패 모드입니다. 이 단계를 선행하는 것은 DoR 이전에 "의사 2차 개발 기능"을 먼저 차단하기 위함입니다.

<대화형 명확화 규칙>을 준수합니다: 계층 간 분해표에서 owner, 특정 계층 변경 필요 여부, 하위 계층 지원 여부가 추정에 속하는 경우, 모두 [확인 필요]로 표시하고 명확화 질문으로 사용자에게 하나씩 던집니다(한 번에 한 질문, 후보 포함). 추정된 부서/owner/의존성을 확정된 것으로 표에 채우지 마십시오.——이 단계는 자연스럽게 owner 표를 한 번에 모두 채우도록 유도하지만, 이는 사용자를 대신하여 '누가 owner인지, 어떤 계층을 변경해야 하는지'를 결정하는 것과 같습니다.

5단계: 1차 명확화——포지셔닝(개략)

<1차·포지셔닝 차원>을 체크리스트로 사용하여, 조각을 하나씩 대조하고 답변되지 않은 차원을 나열한 후 <대화형 명확화 규칙>에 따라 하나씩 질문합니다. 이 단계는 기능의 형태를 결정합니다: 그것이 무엇인지, 어느 계층/영역에 속하는지, 경계는 어디인지, 어떤 형태인지. 한 번에 한 질문만 합니다.

격차를 두 가지 유형으로 나눕니다:

차단성 격차: 보충하지 않으면 분류를 계속하거나 경계를 정의할 수 없음(예: 어떤 역할을 대상으로 하는지, 핵심 동작은 무엇인지).
비차단 격차: 완전성에는 영향을 미치지만 주요 골격에는 영향을 미치지 않음(예: 특정 에지 오류 코드, 문서 형식).

6단계: 2차 명확화——기능 세부 사항(상세)

포지셔닝이 명확해지면 기능의 형태는 알 수 있지만, 개발팀은 아직 작업을 시작할 수 없습니다.——왜냐하면 "구체적으로 어떻게 동작하는지"를 아직 모르기 때문입니다. 이 단계에서는 <2차·기능 세부 사항 차원>을 사용하여 동작 사양을 심층 파고듭니다: 정상 흐름은 어떻게 진행되는지, 어떤 상태가 있는지, 예외는 어떻게 처리되는지, 경계 시나리오는 어떻게 되는지, 매개변수 값은 얼마인지.

2차 질문은 기능 유형에 따라 달라져야 합니다: 둘러보기 유형은 경로와 도착 지점 로직을 물어야 하고, 센싱 유형은 오검출과 신뢰도를 물어야 하며, 데이터 유형은 스키마와 규모를 물어야 합니다. 구체적인 유형별 질문 라이브러리는 references/detail-probes.md를 참조하십시오——먼저 이 기능이 어떤 원형에 속하는지 판단한 다음, 해당 프로브 체크리스트를 호출합니다.

7단계: 기능 요구사항 문서 생성(제품 원칙 자체 점검 게이트 포함)

차단성 격차가 보충되면, 먼저 제품 원칙 자체 점검 게이트를 통과한 후 <출력 템플릿>에 따라 결과물을 생성합니다.

템플릿 선택: 순수 2차 개발 단일 계층, 격차가 적은 소규모 기능은 간결 템플릿(<한 문장 정의> <출처 배경> <능력 포지셔닝> <범위 경계> <스토리+MVP> <동작 사양> <인터페이스 계약> <의존성> <영향 평가> <제품 원칙 자체 점검 (한 줄 결론)> <결정 기록> <미해결 확인 사항>, <계층 간 구현 및 부서 간 협업> 및 대부분의 주문형 NFR 생략)을 사용합니다. 구현 계층 간 또는 주요 기능은 전체 템플릿을 사용합니다. 둘 다 동일한 필수 응답 항목 세트와 DoR을 공유합니다.

결과물 생성 전 필수: 제품 원칙 자체 점검 게이트. 설정 영역 <D. 제품 원칙>(미작성 시 references/product-principles.md의 내장 기본 10개 원칙 사용)을 가져와 이 기능에 대해 각 원칙별로 세 가지 상태 결론을 제시합니다: ✓ 준수 / ⚠ 위반-절충 있음 / — 해당 없음. 세 가지 상태 판단 세부 규칙, 일반적인 레드 플래그 목록, 충돌 우선순위는 references/product-principles.md를 참조하십시오. 하나라도 ⚠가 있으면 <제품 원칙 자체 점검> 절에 절충 사항을 명확히 기록하고, <주요 결정 기록> 절에 한 줄을 추가합니다(출처는 "제품 원칙 충돌 절충", 해당 조항 번호 명시). 모두 ✓/—인 경량 기능은 자체 점검을 한 줄 결론으로 압축할 수 있으며, 빈 테이블을 펼칠 필요가 없습니다.

게이트는 스킬이 자체적으로 통과 체크하는 것이 아니라, 기준 미달 항목을 명확화 질문 또는 [확인 필요]로 변환하여 사용자에게 다시 던집니다. 절충이 필요한 경우(호환성을 위해 특정 능력을 희생할지, 예산 초과 시 무엇을 삭제할지, 위험한 동작에 권한 게이트를 추가할지 등)는 <대화형 명확화 규칙>에 따라 한 번에 한 질문, 후보 포함으로 사용자에게 결정을 요청해야 합니다.

DoR 하드 요구사항:

어떤 원칙이 ⚠로 표시되었지만 문서에 해당 절충 설명 + 결정 기록이 없는 경우 → DoR 통과 불가, "개발팀 인수 가능/검토 대기"로 표시할 수 없음.
4단계 계층 바닥 도달 결론이 B/C이지만, <한 문장 정의> 또는 P1이 여전히 하위 계층이 준비되지 않은 전체 능력을 약속하는 경우 → DoR 통과 불가(먼저 4단계 5번째 소항목에 따라 실제 전달 가능한 결과물로 다시 작성해야 함).

게이트 통과 후 선택한 템플릿에 따라 문서를 생성하고, 표준 출력 디렉터리 feature-specs/<기능명>/<기능명>.md에 기록합니다(대화에만 붙여넣지 않음; 위치 규칙은 <출력 템플릿> 참조). 아직 해결되지 않은 비차단 격차는 <미해결 확인 사항> 절에 넣고, 본문의 영향받는 필드에는 [확인 필요]를 표시하며, 절대 임의로 만들어 내지 않습니다.

두 계층을 두 개의 패스로 나누는 이유: 한 번의 세션에서 너무 많은 질문을 하면 피로를 유발할 수 있습니다(명확화 규칙의 총량 상한 참조). 첫 번째 계층(5단계) 질문을 마친 후 "포지셔닝 완료, 동작 보충 필요" 상태의 초안을 먼저 제공하고, 두 번째 계층(6단계)을 후속 심층 패스로 진행하여 동작 사양을 완성하고 개발 레벨 v1.0으로 업그레이드하는 것을 권장합니다. 두 계층은 각각 총량 상한을 준수하며 서로를 침범하지 않습니다. 요구사항이 매우 작고 격차가 많지 않은 경우, 두 계층을 한 번에 완료할 수도 있습니다.

1차·포지셔닝 차원(개략)

기능의 "형태"를 결정합니다. 조각을 하나씩 대조하여 확인하고, 누락된 것이 명확히 해야 할 사항입니다. 두 그룹으로 나뉩니다.

A 그룹·요구사항 본질(무엇 / 왜 / 경계)

역할 및 시나리오: 누가 사용하는가? 어떤 시나리오에서 트리거되는가?(최종 사용자 / 통합업체 개발자 / 운영…)
핵심 동작: 이 기능은 구체적으로 어떤 동작을 하는가? 입력은 무엇이고, 어떤 결과를 생성하는가?
범위 경계: 포함하는 것, 명확히 포함하지 않는 것(이 항목은 가장 쉽게 간과되며, 개발팀이 스스로 범위를 상상하는 것을 가장 잘 방지할 수 있습니다).
성공 판단 기준: 어떻게 "제대로 되었는가"를 판단하는가? 어떤 관찰 가능한 지표로 측정하는가?

B 그룹·SDK 엔지니어링 포지셔닝

능력 계층 소속: L1 / L2 / L3 중 어느 계층에 속하는가?
다섯 영역 포지셔닝: 어떤 능력 영역에 속하는가? 영역을 넘나드는가? 영역 간 이동 시 누구를 움직여야 하는가?
인터페이스 영향 범위: 새로 추가/수정해야 할 인터페이스는 무엇인가? API 예산 상한에 충격을 주는가?
하위 계층 의존성: 어떤 기존 기능에 의존하며, 어떤 기능이 아직 존재하지 않아 먼저 구축해야 하는가?
적용 형태: 시뮬레이션, 실기기, 또는 둘 다인가? 둘의 수용 판단 기준이 다를 수 있습니다.
통합업체 가용성: 목표는 어느 등급의 통합업체가 사용할 수 있는가? 이에 따른 캡슐화/문서 복잡도가 다릅니다.
하위 호환성: 기존 인터페이스 규칙을 파괴하는가? 버전 관리 또는 마이그레이션 경로가 필요한가? break로 판단되면, 영향을 받는 기존 통합업체/버전 범위와 허용 가능한 폐기 기간을 함께 물어야 하며, 단순히 "break 여부"만 기록해서는 안 됩니다.
문서 및 인증 영향: 새로운 개발자 문서가 필요한가? 통합업체 인증 평가 범위에 포함되는가?
보안 및 권한(물리적 개조 포함): 이 능력은 어느 등급의 통합업체/역할에 개방되는가? 위험 또는 고권한 동작이 포함되는가? 보안 위험은 두 가지 유형이 있으며, 모두 강제로 한 번은 물어야 하고 기본적으로 허용해서는 안 됩니다——
- 위험한 소프트웨어 호출: 속도/토크 상한 해제, 비상 정지 해제, 직접 섀시/조인트 제어, 안전 울타리 우회 → "누가 호출할 권리가 있는지, 2차 확인/감사/권한 게이트가 필요한지"를 묻습니다.
- 위험한 물리적 개조(하드웨어 엔드 이펙터/개조 유형 기능, 원형 J): 고객이 자체 제작한 하드웨어를 움직이고 사람을 다치게 할 수 있는 로봇에 연결하는 경우 → 하중/토크/전원 레드라인 및 초과 결과, 개조 금지 구역(어떤 인터페이스를 건드리면 비상 정지/안전 메커니즘이 해제되는지), 엔드 이펙터 개조 후 부하 재교정 필요 여부, 개조 승인/자격 요건, 보증 및 책임 경계, 면책 및 규정 준수 선언, 자료 공개 범위(역할 등급/게이트 제어) 를 묻습니다. 물리적 레드라인 숫자를 하나라도 잘못 제시하면 인명 안전 + 법적 책임이 발생합니다.

2차·기능 세부 사항 차원(상세)

기능이 "구체적으로 어떻게 동작하는지"를 결정합니다. 이것이 요구사항을 진정으로 개발 레벨에 도달하게 하는 핵심입니다——아래 각 항목이 명확히 정의되지 않으면, 개발팀이 작업을 시작할 때 스스로 결정해야 합니다. 이것들은 일반 차원이며, 기능 유형에 따라 references/detail-probes.md에서 유형별 프로브를 가져와 구체적으로 질문합니다.

정상 흐름 단계별: 핵심 동작을 순서 있는 단계로 분해하고, 각 단계의 입력, 출력, 선행 조건이 각각 무엇인지 명시합니다.
상태 및 수명 주기: 어떤 상태가 있는가? 상태 머신은 어떻게 전환되는가? start / pause / resume / stop / cancel 각각의 의미, 각 상태에서 허용되는 작업은 무엇인가?
트리거 및 선행 조건: 어떤 조건에서 시작할 수 있는가? 시스템/리소스에 대한 선행 요구사항은 무엇인가? 반복 트리거, 동시 트리거는 어떻게 처리되는가?
예외 및 실패 처리: 각 단계의 가능한 실패 지점을 나열하고, 각각에 대한 대책을 결정합니다——재시도 / 다운그레이드 / 중단 / 보고, 그리고 누가 후처리하고 상태를 어떻게 마무리할지.
경계 및 에지 시나리오: 빈 입력, 극한값, 중단, 리소스 부족(배터리/연산 능력), 외부 조건 급변 시의 동작.
매개변수 세부 사항: 각 구성 가능한 항목의 단위, 값 범위, 기본값, 잘못된 값의 유효성 검사 방법.
시퀀스 및 성능 제약: 응답 시간, 시간 초과 임계값, 처리량, 실시간 요구사항.
동시성 및 재진입 가능성: 다중 인스턴스를 병렬로 실행할 수 있는가? 호출자가 동일한 인터페이스를 여러 번 호출하면 어떻게 되는가?
관찰 가능성: 호출자가 기능의 실행 상태를 인식하기 위해 어떤 상태 조회, 이벤트/콜백, 로그 또는 메트릭이 필요한가? 관찰 가능성은 두 계층으로 나누어 모두 물어야 합니다——호출자 대상(상태 조회/이벤트 콜백/위치 파악 가능 로그, 통합업체가 실행 상태를 인식하도록 지원) 및 플랫폼 운영 대상(출시 후 어떤 메트릭/추적 포인트로 이 기능의 건강 상태, 채택률, 실패 분포를 판단하여 문제 해결 및 의사 결정을 지원하며, 후자는 종종 누락됨).

9가지 항목을 모두 질문할 필요는 없습니다. 이 기능에 중요한 것이 무엇인지 판단하고(예외 처리는 장시간 작업에서 거의 항상 중요하며, 매개변수 세부 사항은 순수 조회 유형에서는 매우 가벼울 수 있음), 중요한 것을 잡아 질문하고, 나머지는 합리적으로 기본값을 남기거나 [확인 필요]로 표시합니다.

세 가지 직교 축, 중첩 사용: 위의 9차원 + detail-probes의 '기능 원형 A~J'는 기능 유형에 따른 한 축입니다(H = 생태계 통합/참조 구현/문서 유형; I = 패키징/배포/오프라인 설치/배포 유형; J = 하드웨어 엔드 이펙터/물리적 인터페이스 사양 및 개조 자료 유형, 외부 계약은 기계/전기 물리적 인터페이스). 특정 기능이 구현 계층 간 분해가 필요한지(2차 개발 계층 외 계층 건드림, "문서 포털 계층 / 빌드·배포 인프라 계층"의 두 가지 비런타임 계층 및 외부 의존성/EOL 축 포함)는 두 번째 축이며, 4단계 및 references/cross-layer-routing.md를 참조하십시오. 통과해야 할 비기능적 요구사항(NFR) 및 제품 원칙은 세 번째 축이며, references/product-principles.md를 참조하십시오. 세 가지는 서로 대체되지 않으며, 해당되면 중첩됩니다.

대화형 명확화 규칙

이것은 "단순함"을 "완전함"으로 바꾸는 엔진입니다. 반드시 준수하십시오:

한 번에 한 문제. 한 문제를 물은 후, 멈추고 사용자의 답변을 기다린 후 다음 문제를 물으십시오. 한 번에 여러 문제를 던지지 마십시오.
차단 우선. 먼저 차단성 격차(역할, 핵심 동작, 범위 경계, 능력 소속)를 물은 후, 비차단성 격차를 물으십시오.
각 질문에는 "왜 묻는지"와 후보 답변을 포함하십시오. 형식: "이 기능은 주로 어떤 역할을 대상으로 합니까? (이것은 어느 계층에 캡슐화해야 하는지를 결정합니다) A. 최종 사용자가 직접 사용 B. 통합업체가 2차 개발에 사용 C. 내부 테스트용". 후보 답변을 제공하면 답변 비용을 크게 낮출 수 있으며, 사용자는 "위의 어느 것도 아님"을 선택하고 보충할 수도 있습니다.
총량을 제어하여 피로를 방지하십시오. 각 계층의 단일 세션은 7~8개 문제를 초과하지 않도록 노력하십시오(두 계층은 각각 계산하며 서로를 침범하지 않음). 격차가 너무 많으면 차단성 격차를 먼저 보충하고, 나머지는 [확인 필요] 표시를 하고 사용자에게 "나머지는 표시해 두었으니 추후 보충할 수 있습니다"라고 알리십시오. 2차 세부 사항 문제는 특히 초과하기 쉬우므로 이 기능에 중요한 것을 선택하여 물으십시오.
답변 후 재진술 확인. 사용자가 답변하면, 한 문장으로 이해를 재진술하고 계속 진행하여 오해가 없도록 하십시오.
절대 사용자를 대신하여 결정하지 마십시오. 절충이 필요한 문제(특정 경계를 할지 말지, 어떤 형태를 사용할지, 누가 owner인지, 어떤 계층을 변경해야 하는지)는 반드시 물어야 하며, 기본값으로 간주해서는 안 됩니다. "아직 확인되지 않은 것"은 명시적으로 [확인 필요]로 표시하고, 합리적으로 보이는 값을 조용히 채우지 마십시오.

작성 및 가독성(결과물은 반드시 충족해야 함)

요구사항 문서는 사람이 읽고 검토를 통과해야 하는 것이며, 생각나는 대로 점을 쌓아 올리는 것이 아닙니다. 결과물을 생성하기 전에 다음 세 가지를 확인하십시오:

쉬운 말로, 논리적으로 일관되게. 문장이 매끄럽고, 단락에 주제가 있어야 하며, "생각나는 대로 조각을 쌓아 올리지" 마십시오. 처음 등장하는 용어/약어는 그 자리에서 한 문장으로 설명하거나 <용어 설명>에 넣으십시오——독자가 생소한 단어에서 막히지 않도록 하십시오. 전문 용어 한 마디보다 쉬운 설명 한 문장을 더 추가하는 것이 좋습니다.
전체 배경 + 역할별 절 + 용어, 세 부분 구성. 하나의 문서 = ① 전체 배경(모두가 먼저 읽음: 이것이 무엇인지, 왜 하는지, 누구를 위한 것인지, 무엇을 전달하는지 = <한 문장 정의> + <출처 및 배경> + <용어 설명>) + ② 역할별 절(<읽기 가이드>는 이후 각 절을 읽는 대상별로 분리하여, 각 역할은 자신의 부분만 읽고 특정 팀이 자신과 관련 없는 세부 사항에 빠지지 않도록 함) + ③ <용어 설명>(용어를 별도로 명확히 설명하며, 이해하지 못하는 사람을 대상으로 함).
외부 전달 형태는 제한하고, 내부 기술 세부 사항은 자유롭게. 요구사항은 "외부에 무엇을 전달할지"를 고정합니다.——인터페이스 시그니처, 제품 형태, 결과물 형식, 지원되는 플랫폼/환경, 수용 기준. 그러나 "내부에서 어떻게 구현할지"를 과도하게 규정하지는 마십시오.——어떤 라이브러리를 사용할지, 어떤 아키텍처, 어떤 패키징/컴파일 도구를 사용할지는 개발팀에 맡기십시오. 각 줄을 작성할 때 스스로에게 물으십시오: "이것은 외부 계약인가, 아니면 내부 구현인가?" 내부 구현이라면 "개발팀이 결정"으로 변경하거나 "권장 사항(비필수)"으로 다운그레이드하고, 요구사항을 설계 사양으로 작성하지 마십시오.
쉬운 말은 이해를 돕기 위한 것이지 모호함을 위한 것이 아닙니다. 외부 계약은 엄격해야 합니다. 문장은 쉬운 말을 사용하지만, 외부 출력 표준과 관련된 사항——인터페이스 정의(시그니처/매개변수/반환/오류), 메시지 및 데이터 형식, 지원되는 플랫폼 매트릭스를 각 셀까지 완전히 나열, 결과물 형식, 수용 기준——은 정확하고, 모호함이 없으며, 이에 따라 수용할 수 있어야 하며, 시그니처를 제공해야 하면 제공하고, 매트릭스를 행별로 나열해야 하면 완전히 나열하십시오. 쉬운 말은 쉬운 말대로, 계약은 느슨해져서는 안 됩니다. 역할별로 장을 나눌 때, 이러한 엄격한 계약은 "외부 계약" 유형의 장에 집중시켜 개발팀/테스트팀이 이를 기반으로 구현하고 검증할 수 있도록 하십시오.

출력 템플릿

차단성 격차가 보충된 후(7단계 제품 원칙 자체 점검 게이트 통과 후), 이 템플릿에 따라 엄격하게 결과물을 생성합니다. 템플릿에는 Definition of Ready가 내장되어 있습니다——모든 절이 실제로 채워지거나(또는 명시적으로 [확인 필요]로 표시) 되어야 이 요구사항이 "개발팀이 인수할 수 있는" 상태가 됩니다.

규칙:

절은 더 이상 하드 넘버링하지 않으며, 절 이름으로 통일하여 참조하여 절 번호가 삽입 후 틀어지는 것을 방지합니다.
간결 템플릿 = <계층 간 구현 및 부서 간 협업>과 주문형 NFR 차원을 제거한 동일한 절 세트로, 순수 2차 개발 단일 계층 소규모 기능에 사용합니다. 전체 템플릿은 계층 간 또는 주요 기능에 사용합니다.
인터페이스/매개변수 명명은 전체적으로 다음을 따릅니다: 전체 소문자 밑줄(snake_case), 단어 의미 완전하고 정확, 약어 사용 금지(예: mic→microphone, cfg→config, num→count), 동일 도메인의 기존 인터페이스와 일관성을 유지합니다.
하나의 문서는 하나의 기능만 담으며, 하나의 기능은 하나의 md 파일만 생성합니다. 여러 기능은 각각 독립적인 문서를 작성합니다(절대 혼합 작성하지 않음). 하지만 하나의 기능이 계층을 넘나들더라도 여러 파일로 분할하지 않습니다——계층 간/부서 간 내용은 동일한 md 파일 내에서 읽는 대상별로 절을 나눕니다.
결과물 저장 위치(표준 출력 디렉터리, 반드시 준수): 결과물은 파일에 기록합니다(대화에만 붙여넣지 않음)——출력 디렉터리 **feature-specs/<기능명>/<기능명>.md**에 저장합니다(현재 작업 디렉터리/저장소 루트 기준; 기본 루트는 feature-specs/, 팀은 설정 영역에서 변경 가능). 하나의 기능에 하나의 하위 디렉터리(해당 기능의 첨부 이미지/하위 결과물을 넣기 편함), 파일 이름 = 기능명. 여러 기능은 각각 독립적인 하위 디렉터리를 갖습니다. 연관 기능 간에는 상대 링크로 상호 참조합니다.
계층 간(결론 B/C) 기능: 이 템플릿 상단에 <읽기 가이드(읽는 대상별 분할)>를 추가하고, <계층 간 구현 및 부서 간 협업> 절에서 각 계층의 내용을 【읽는 대상: X 그룹】별로 절을 나누어 담습니다(템플릿은 references/cross-layer-routing.md <9> 참조)——모두 이 하나의 md 파일 내에 있으며, 별도 파일로 분할하지 않습니다.

# 기능 요구사항: [기능 이름]

> 상태: 초안 / 검토 대기 / 확정 　｜ 제안자: [고객/파트너] 　｜ 날짜: YYYY-MM-DD 　｜ 템플릿: 전체 / 간결

## 읽기 가이드(읽는 대상별 분할)
> **읽는 방법**: 먼저 **전체 배경**(<한 문장 정의> <출처 및 배경> <용어 설명>, 모두 읽음)을 읽고, 나머지 절은 아래 표에 따라 **각자 읽을 부분만 읽고** 전체를 읽을 필요는 없습니다. 계층 간/부서 간 기능은 반드시 이 표를 작성해야 합니다. 순수 단일 계층 소규모 기능은 표를 간소화할 수 있지만, 전체 배경과 <용어 설명>은 여전히 있어야 합니다.
| 읽는 대상 | 중점적으로 읽을 절 | 담당 업무 |
| --- | --- | --- |
| 제품 / 검토 | 한 문장 정의, 출처 배경, 능력 포지셔닝, 범위 경계, 스토리+수용, 영향 평가, 제품 원칙 자체 점검, 결정 기록, 미해결 | 범위/우선순위/절충 확인 |
| 2차 개발 SDK 팀 | 인터페이스 계약, 동작 사양, <계층 간 구현 및 부서 간 협업>·2차 개발 절 | 외부 캡슐화 및 인터페이스 계약 |
| 펌웨어 팀 | <계층 간 구현 및 부서 간 협업>·펌웨어 절, 계층 간 전달 계약 | 하위 계층 기능 인터페이스 확인/개방 |
| 알고리즘 팀 | <계층 간 구현 및 부서 간 협업>·알고리즘 절 | 알고리즘 기능 준비/적응 |
| 하드웨어 팀 | <계층 간 구현 및 부서 간 협업>·하드웨어 절 | 하드웨어 형태/물리적 경계 |
| 테스트 / QA | 수용 기준, 외부 계약(인터페이스/메시지/플랫폼 매트릭스), 확인 필요 | 수용 기준 및 계약에 따라 테스트 설계, 전체 플랫폼 매트릭스 커버 |
(역할은 **기능 유형에 따라 선택**: 런타임 기능 = 각 구현 계층; 전달/통합/설치 유형 = 패키징·DevOps／문서／테스트 등. **테스트/QA는 항상 하나의 역할로 포함**——수용 기준을 어떻게 테스트할지, 어떤 플랫폼을 커버해야 하는지, 외부 계약이 테스트 가능한지에 관심을 가짐. 관련 없는 역할은 전체 행을 삭제. **본문은 가능한 역할별로 장을 나누어** 각 역할이 자신의 부분을 한 덩어리로 읽을 수 있도록 함.)

## 한 문장 정의
[무엇 —— 이 기능이 무엇을 하는지, 한 문장으로 명확히 설명. ⚠ 4단계 계층 바닥 도달 결론이 B/C인 경우, 여기에는 이번 라운드의 실제 전달 가능한 결과물만 작성하고, 하위 계층이 준비되지 않은 전체 능력을 작성하지 마십시오]

## 출처 및 배경(왜)
- 원래 요청: [고객/파트너의 원래 문장, 원래 의도 유지]
- 비즈니스 시나리오: [누가, 어떤 시나리오에서, 어떤 문제를 해결하려는지]
- 가치: [왜 할 가치가 있는지]

## 용어 설명(용어)
> 문서에서 사용되며, 이 분야가 아닌 독자가 이해하지 못할 수 있는 용어/약어를 한 단어 한 문장으로 명확히 설명(다양한 역할 대상, 모두가 알고 있다고 가정하지 마십시오). 생소한 단어가 없으면 "없음"이라고 작성.
| 용어 | 한 문장 설명 |
| --- | --- |
| … | … |

## 능력 포지셔닝
- 계층: L1 / L2 / L3　[설정 영역 A 그룹 미작성 시 `[확인 필요]` 표시; **전달/배포/설치/문서 유형의 비런타임 기능인 경우 `N/A (비기능 기능, 구현 계층 축에만 해당)`로 표시**]
- 능력 영역: [다섯 영역 중 하나, 또는 "영역 간: X + Y", 또는 N/A]
- 영역 간 영향: [다른 어떤 영역/팀을 움직일지]
- 계층 간 결론(4단계): 단일 계층 기능(2차 개발 SDK) / ⚠ 2차 개발 계층이 독립적으로 전달할 수 없음: 최하위 변경은 <계층>에 속하며, <부서>가 먼저 <능력>을 전달해야 2차 개발 계층이 캡슐화할 수 있음

## 범위 경계
- 포함(In Scope):
  - …
- 명확히 하지 않음(Out of Scope):   ← 필수, 개발팀이 범위를 잘못 확장하는 것을 방지
  - …
- 연관 기능 플레이스홀더(요구사항 분류에서 나옴, 이번 라운드 미수행):
  - …

## 계층 간 구현 및 부서 간 협업
> 4단계에서 이 기능이 구현 계층 간(2차 개발 SDK 계층 외 계층 건드림)이라고 판단된 경우에만 필수; 순수 2차 개발 단일 계층은 "단일 계층 기능(2차 개발 SDK), 계층 간 협업 없음"이라고 작성하고 이 절을 건너뜀(간결 템플릿은 이 절을 포함하지 않음).
> **출력 형태:** 하나의 기능은 하나의 md 파일만 생성; 이 절은 …

…

Auromix/feature-spec-builder

feature-spec-builder란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서