design-radio

name	design-radio
description	RADIO 기반 FE/BE 설계 체크리스트. `/design` command가 각 Step에서 참조하는 판단 기준과 질문 목록.

Design RADIO — 체크리스트

GreatFrontEnd의 RADIO Framework를 실무 확장한 설계 체크리스트. /design command가 C → RADIO → V 각 단계에서 이 스킬을 참조한다.

사용 방법:

• /design command의 각 Step에서 자동 참조됨
• 단독 참조도 가능 (설계 리뷰, 체크리스트 확인 시)

C → RADIO → V

Gate In ─ C  Context        기존 코드·패턴·컨벤션 파악

          R  Requirements   문제 정의 + 기능/비기능 + 스코프 아웃
 RADIO    A  Architecture   주요 컴포넌트 + 책임 할당
          D  Data Model     엔티티, 필드, 데이터 출처/생명주기
          I  Interface      경계를 넘는 계약 (API, props, 이벤트)
          O  Optimizations  NFR에서 도출된 항목만 (YAGNI)

Gate Out ─ V  Verification  Given/When/Then 핵심 3~5개

라디오를 켜기 전에 주파수를 맞추고(C), 끝나면 수신을 확인한다(V).

각 단계의 상세 체크리스트:

• 공통: references/checklist-common.md (항상 참조)
• FE 작업: references/checklist-fe.md (공통 + FE)
• BE 작업: references/checklist-be.md (공통 + BE)

사용법

1. 항상 C부터 시작한다

기존 코드와 컨벤션을 먼저 파악한다. 그 다음 R에서 "X를 하면 Y가 된다"를 한 문장으로 적을 수 없으면, 아직 설계할 준비가 안 된 것. PRD를 다시 읽거나 PM에게 질문한다.

2. 깊이를 작업 크기에 맞춘다

작업 크기	Gate (C/V)	RADIO 단계
버그 수정 / 1일 작업	C, V (항상)	R
기능 추가 / 1주 작업	C, V (항상)	R, D, I
시스템 설계 / 1달+	C, V (항상)	R, A, D, I, O

Gate(C/V)는 항상 수행한다. RADIO 단계는 작업 크기에 맞춰 선택한다.

3. 각 단계의 핵심 질문 (요약)

C — Context (Gate In)

"지금 코드베이스에서 재사용하거나 변경할 것은?"

• 재사용 가능한 기존 코드
• 기존 패턴과 컨벤션
• 변경이 필요한 기존 코드

R — Requirements

"무엇을 해야 하고, 무엇을 하지 않는가?"

• 한 문장 문제 정의
• 기능 요구사항 (핵심 유저 플로우)
• 비기능 요구사항 (성능, 보안, 접근성)
• 스코프 아웃 (명시적으로 하지 않는 것)

A — Architecture

"주요 조각은 무엇이고, 각각 무슨 책임을 가지는가?"

• 주요 컴포넌트 식별
• 컴포넌트 간 관계도
• 계산이 일어나는 위치 (서버 vs 클라이언트)

D — Data Model

"어떤 데이터가 존재하고, 어디서 오고, 어디에 저장되는가?"

• 엔티티 정의 (필드, 타입, 제약조건)
• 데이터 출처 (서버/클라이언트)
• 엔티티 간 관계

I — Interface Definition

"컴포넌트 간 경계에서 무엇이 오고 가는가?"

• 각 경계의 Input/Output 계약
• 에러 처리 계약
• 타입 정의

O — Optimizations

"NFR에서 도출된 최적화는 무엇인가?"

• R 단계의 NFR에서 직접 도출된 항목만
• 추측성 최적화 금지

V — Verification (Gate Out)

"이것이 완료되었다는 것을 어떻게 증명하는가?"

• Given/When/Then 핵심 3~5개
• 정상 → 에러 → 엣지 순서
• 이것이 "완료의 정의"

안티패턴

안티패턴	문제	해결
C 없이 R부터 시작	기존 코드를 모르고 요구사항부터 정의	C(Gate In)부터 시작
C를 건너뜀	이미 있는 걸 새로 만듦	Gate는 항상 수행
D와 I를 동시에 생각	데이터와 계약이 뒤섞임	D(무엇이 존재하는가) 먼저, I(어떻게 주고받는가) 다음
O에서 추측성 최적화	YAGNI 위반	R의 NFR에 없으면 안 함
V 없이 구현 시작	"완료"가 정의되지 않음	최소 3개 Given/When/Then
Domain이 Infrastructure를 import	Dependency Rule 위반	Domain은 순수 비즈니스 규칙만. 외부 의존은 Port interface로 역전