design-library

name	design-library
description	Library/API 설계 판단 기준. `/design` command의 D step에서 기술 라이브러리를 설계할 때 참조.

Design Library — API/라이브러리 설계 판단 기준

/design command의 D step에서 기술 라이브러리를 설계할 때 참조하는 판단 기준.

사용 방법:

• /design command의 D step에서 자동 참조됨
• 단독 참조도 가능 (라이브러리 API 리뷰 시)

Library Design 딥다이브 진입 조건

아래 중 2개 이상 해당하면 Library Design 딥다이브가 필요하다:

• 다른 개발자가 소비하는 코드이다 (패키지, SDK, 내부 공유 모듈)
• 공개 API surface를 설계해야 한다
• 하위 호환성/버전 관리를 고려해야 한다
• 추상화 레벨 선택이 설계의 핵심이다

설계 Phase 개요

Phase 1: 소비자의 멘탈 모델을 정의한다 (누가, 어떻게 쓰는가)
         ↓
Phase 2: 공개할 것과 숨길 것의 경계를 긋는다 (API Surface)
         ↓
Phase 3: 경계 안에서 구체적으로 설계한다
         - 타입으로 잘못된 사용을 막고 (Type Contract)
         - 확장 방법을 정하고 (Extension Point)
         - 안정성 약속을 정한다 (Stability Commitment)

---

Phase 1: Consumer Mental Model (소비자 이해)

"이 라이브러리를 쓰는 개발자가 머릿속에 가져야 할 개념은?"

1-1. 소비자 정의

질문	예시
누가 쓰는가?	앱 개발자 / 라이브러리 개발자 / 내부 팀
숙련도는?	초급 → 간결한 API, 상급 → 세밀한 제어
한 문장 정의	"{X}를 하기 위한 라이브러리"

검증 질문:

• "README의 한 줄 소개를 적을 수 있는가?"
• 적을 수 없으면 아직 범위가 명확하지 않은 것.

1-2. 핵심 개념 (Concept Glossary)

소비자가 알아야 할 개념을 3~5개로 정리한다.

개념	정의	코드에서의 표현
{명사}	{한 문장 정의}	{class/type/function 이름}