jun-claude-code 0.0.11 → 0.0.13

package/templates/global/skills/PromptStructuring/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: PromptStructuring
+description: "Claude Code 프롬프트의 XML 태그 구조화 및 긍정 표현 전환 가이드"
+keywords: [prompt, xml-tags, positive-phrasing, structuring, 프롬프트, 구조화, 긍정표현, XML]
+estimated_tokens: 800
+---
+
+# 프롬프트 구조화 스킬
+
+## 개요
+
+프롬프트의 **형식과 표현 방식**은 LLM 출력 품질에 직접적인 영향을 준다.
+
+- **형식**: 동일한 내용이라도 XML 태그로 의미를 구분하면 모델이 역할/지시/규칙을 명확히 구분
+- **표현**: 부정 표현("~금지") 대신 긍정 표현("~한다")을 사용하면 의도한 행동을 직접 유도
+
+### 연구 근거
+
+| 연구 | 핵심 발견 | 시사점 |
+|------|----------|--------|
+| Sclar et al. (2023) | 동일 내용, 형식만 변경해도 최대 76%p 성능 차이 | 프롬프트 구조가 정확도에 직결 |
+| Voronov et al. (2024) | 프롬프트 포맷팅이 Few-shot 성능에 체계적 영향 | 일관된 태그 구조가 안정적 성능 보장 |
+| Anthropic 공식 가이드 | XML 태그 사용을 공식 권장 | Claude 모델에 최적화된 구조화 방식 |
+
+## 핵심 원칙
+
+### 1. XML 태그로 의미 구분
+
+마크다운 제목(`##`) 대신 XML 태그로 역할/지시/규칙/제약을 구분한다.
+
+```
+마크다운만 사용 -> XML 태그로 의미 구분
+
+## 역할          ->  <role>
+## 지시사항      ->  <instructions>
+## 규칙          ->  <rules>
+## 제약사항      ->  <constraints>
+```
+
+### 2. 긍정 표현으로 행동 유도
+
+부정 명령 대신 긍정 행동을 명시한다.
+
+```
+부정 표현 -> 긍정 표현
+
+"코드 직접 수정 금지"    ->  "모든 코드 수정은 code-writer에 위임"
+"git add -A 금지"       ->  "수정한 파일만 개별 지정하여 git add"
+"과도한 추상화 금지"     ->  "필요한 만큼만 추상화"
+```
+
+### 3. `->` 흐름 기호 활용
+
+단계, 변환, 위임을 나타낼 때 `->` 기호를 사용한다.
+
+```
+단계: 계획 -> 구현 -> 검증
+변환: 부정 표현 -> 긍정 표현
+위임: 코드 수정 -> code-writer Agent
+```
+
+## 관련 문서
+
+| 문서 | 설명 |
+|------|------|
+| `xml-tags.md` | XML 태그 표준 목록, 파일 유형별 권장 조합, Before/After 예시 |
+| `positive-phrasing.md` | 부정 -> 긍정 전환 패턴, 카테고리별 변환 테이블, 체크리스트 |

package/templates/global/skills/PromptStructuring/positive-phrasing.md

@@ -0,0 +1,206 @@
+---
+name: "Positive Phrasing Guide"
+description: "프롬프트의 부정 표현을 긍정 표현으로 전환하는 가이드"
+keywords: [positive-phrasing, prompt-optimization, negation-removal, 긍정표현, 부정제거]
+estimated_tokens: 2000
+---
+
+# 긍정 표현 전환 가이드
+
+## 왜 긍정 표현인가
+
+부정 명령("~하지 마", "~금지")은 LLM이 **금지 대상을 먼저 인식**하게 만든다.
+
+```
+"코드를 직접 수정하지 마세요"
+  -> 모델이 "코드를 직접 수정" 개념을 활성화한 후 억제 시도
+  -> 의도치 않은 활성화 가능성 존재
+
+"모든 코드 수정은 code-writer에 위임하세요"
+  -> 모델이 "code-writer에 위임" 행동을 직접 활성화
+  -> 원하는 행동을 바로 유도
+```
+
+긍정 표현은 **원하는 행동 자체를 명시**하므로 모델이 바로 올바른 방향으로 행동한다.
+
+---
+
+## 전환 패턴
+
+### 카테고리 1: 금지/제한 패턴
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "~금지" | -> | "~전담/전용" |
+| "절대 ~않는다" | -> | "항상 ~한다" |
+| "NEVER ~" | -> | "ALWAYS ~" |
+| "~하지 마세요" | -> | "~하세요" (원하는 행동) |
+| "~을 사용하지 않는다" | -> | "~을 사용한다" (대안 명시) |
+
+**예시:**
+
+```
+"git add -A 금지"
+  -> "수정한 파일만 개별 지정하여 git add"
+
+"구체 클래스 직접 의존 금지"
+  -> "인터페이스/추상화에 의존한다"
+
+"전역 상태 직접 접근 금지 (Presentational에서)"
+  -> "props로 의존성을 전달한다"
+```
+
+### 카테고리 2: 확인 패턴
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "~없는지 확인" | -> | "~인지 확인" |
+| "에러가 발생하지 않는지 확인" | -> | "정상 동작하는지 확인" |
+| "누락된 것이 없는지 점검" | -> | "모든 항목이 포함되었는지 점검" |
+
+**예시:**
+
+```
+"순환 의존이 발생하지 않는가?"
+  -> "의존 방향이 단방향인가?"
+
+"빌드 에러가 발생하지 않는 상태 유지"
+  -> "빌드 가능 상태를 유지"
+
+"누락된 엣지케이스 없는지 점검"
+  -> "모든 엣지케이스가 처리되었는지 점검"
+```
+
+### 카테고리 3: 과도 방지 패턴
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "과도한 X 금지" | -> | "필요한 만큼만 X" |
+| "불필요한 X 금지" | -> | "필요한 X만 포함" |
+| "복잡한 X 피하기" | -> | "단순한 X 유지" |
+
+**예시:**
+
+```
+"과도한 추상화 금지"
+  -> "필요한 만큼만 추상화"
+
+"불필요한 파일 생성 금지"
+  -> "기존 파일 수정을 우선"
+
+"주석 과다 금지"
+  -> "코드가 자명할 때는 주석 생략"
+```
+
+### 카테고리 4: 위임 패턴
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "직접 수행 금지" | -> | "Subagent에 위임" |
+| "Main Agent에서 직접 X 금지" | -> | "X는 [Agent명]이 전담" |
+| "직접 수정하지 않는다" | -> | "[Agent명]에 위임한다" |
+
+**예시:**
+
+```
+"Main Agent에서 직접 코드 수정 금지"
+  -> "모든 코드 수정은 code-writer가 전담"
+
+"Main Agent에서 직접 Git 명령어 실행 금지"
+  -> "모든 Git 작업은 git-manager에 위임"
+
+"Main Agent에서 직접 여러 파일 탐색 금지"
+  -> "파일 탐색은 explore Agent가 전담"
+```
+
+---
+
+## 파일 유형별 자주 등장하는 전환
+
+### Agent 파일
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "코드 직접 수정 금지" | -> | "모든 코드 수정은 code-writer에 위임" |
+| "여러 기능을 동시에 구현하지 않는다" | -> | "한 번에 하나의 기능만 구현한다" |
+| "import 경로가 올바르지 않은 상태로 두지 않는다" | -> | "각 파일 작성 후 import 경로가 올바른지 확인한다" |
+
+### Skill 파일
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "중첩 요소 사용 금지" | -> | "단일 수준 구조를 유지한다" |
+| "장황한 설명 금지" | -> | "테이블과 코드 예제로 압축한다" |
+| "1000줄 초과 금지" | -> | "500줄 이내로 유지하고, 초과 시 파일을 분리한다" |
+
+### Hook 파일
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "Phase를 건너뛰지 마세요" | -> | "모든 Phase를 순서대로 완료한다" |
+| "검증 없이 진행하지 않는다" | -> | "검증을 통과한 후에만 다음 단계로 진행한다" |
+| "계획 없이 코드를 작성하지 않는다" | -> | "계획을 확인한 후 코드를 작성한다" |
+
+### CLAUDE.md 파일
+
+| 부정 표현 | -> | 긍정 표현 |
+|----------|-----|----------|
+| "git add -A 금지" | -> | "수정한 파일만 개별 지정하여 git add" |
+| "자동으로 커밋/푸시하지 않는다" | -> | "사용자가 명시적으로 요청할 때만 커밋/푸시한다" |
+| "3개 이상 파일 수정 금지" | -> | "파일 수정은 Subagent에 위임한다" |
+
+---
+
+## 전환 시 주의사항
+
+### 맥락을 보존한다
+
+부정 표현을 긍정으로 바꿀 때 원래 의도가 손실되지 않도록 한다.
+
+```
+원문: "Presentational 컴포넌트에서 API 호출, 전역 상태 접근 금지"
+
+나쁜 전환: "Presentational 컴포넌트에서 작업한다"
+  -> 원래 의도(제한 사항)가 사라짐
+
+좋은 전환: "Presentational 컴포넌트는 UI 렌더링만 전담한다. 데이터는 props로 전달받는다"
+  -> 허용 범위를 명시하여 제한 의도를 보존
+```
+
+### 대안을 함께 명시한다
+
+"~하지 마"만 긍정으로 바꾸면 모호해질 수 있다. **대안 행동**을 함께 제시한다.
+
+```
+나쁜 전환: "try-catch 대신 다른 것을 사용한다"
+  -> "다른 것"이 모호
+
+좋은 전환: "Promise 처리 시 then-catch 패턴을 사용한다"
+  -> 구체적 대안 제시
+```
+
+### 정량적 기준이 있으면 유지한다
+
+```
+원문: "1000줄 초과 금지"
+좋은 전환: "500줄 이내로 유지하고, 초과 시 파일을 분리한다"
+  -> 수치 기준을 유지하면서 긍정형으로 전환
+```
+
+---
+
+## 체크리스트
+
+<checklist>
+- [ ] 파일 내에 "금지", "~하지 마", "절대", "NEVER" 문자열이 없는가?
+- [ ] 모든 규칙이 "~한다", "~해야 한다" 형태의 긍정문인가?
+- [ ] 제약사항이 "~만 한다", "~전용", "~전담" 형태로 표현되었는가?
+- [ ] 부정 -> 긍정 전환 시 원래 의도가 보존되었는가?
+- [ ] 대안 행동이 구체적으로 명시되었는가?
+- [ ] 정량적 기준(줄 수, 파일 수 등)이 유지되었는가?
+</checklist>
+
+<reference>
+- `SKILL.md` - 프롬프트 구조화 개요 및 핵심 원칙
+- `xml-tags.md` - XML 태그 표준 및 사용 가이드
+</reference>

package/templates/global/skills/PromptStructuring/xml-tags.md

@@ -0,0 +1,330 @@
+---
+name: "XML Tags Guide"
+description: "Claude Code 프롬프트용 XML 태그 표준 및 사용 가이드"
+keywords: [xml, tags, structuring, prompt-format, XML태그, 프롬프트형식]
+estimated_tokens: 2500
+---
+
+# XML 태그 가이드
+
+## 표준 태그 목록
+
+| 태그 | 용도 | 대상 파일 |
+|------|------|----------|
+| `<role>` | Agent 정체성/책임 정의 | Agent |
+| `<instructions>` | 절차/단계 가이드 | Agent, Skill |
+| `<rules>` | 필수 준수 규칙 | 전체 |
+| `<constraints>` | 경계/제약 (긍정 표현) | Agent, CLAUDE.md |
+| `<output_format>` | 출력 구조 정의 | Agent |
+| `<examples>` / `<example type="good/bad">` | 예시 | Skill |
+| `<checklist>` | 검증 항목 | 전체 |
+| `<workflow>` | 다단계 프로세스 | CLAUDE.md, Hook |
+| `<phase name="...">` | 워크플로우 단계 | Hook |
+| `<delegation_rules>` | Subagent 위임 규칙 | CLAUDE.md, Hook |
+| `<reference>` | 문서 상호참조 | 전체 |
+
+---
+
+## 파일 유형별 권장 태그 조합
+
+### Agent 파일
+
+```
+필수: <role>, <instructions>, <constraints>, <output_format>
+선택: <rules>, <examples>, <reference>
+```
+
+Agent는 **정체성 -> 절차 -> 제약 -> 출력** 순서로 구성한다.
+
+### Skill 파일
+
+```
+필수: <instructions>, <rules>, <checklist>
+선택: <examples>, <constraints>, <reference>
+```
+
+Skill은 **절차 -> 규칙 -> 예시 -> 검증** 순서로 구성한다.
+
+### CLAUDE.md
+
+```
+필수: <workflow>, <delegation_rules>, <constraints>
+선택: <rules>, <reference>
+```
+
+CLAUDE.md는 **워크플로우 -> 위임 규칙 -> 제약** 순서로 구성한다.
+
+### Hook 파일
+
+```
+필수: <phase name="...">, <checklist>
+선택: <delegation_rules>, <rules>, <reference>
+```
+
+Hook은 **Phase별 단계 -> 검증 체크리스트** 순서로 구성한다.
+
+---
+
+## Before/After 예시
+
+### 예시 1: Agent - 역할 설명
+
+**Before** (마크다운만 사용):
+
+```markdown
+# Code Writer Agent
+
+## 역할
+
+코드를 작성하는 전문 Agent입니다.
+
+## 해야 할 일
+
+1. task-planner의 계획에 따라 코드 작성
+2. 프로젝트 규칙 준수
+3. 작은 단위로 구현
+
+## 출력
+
+작성한 파일 목록과 변경 내용을 정리하여 출력합니다.
+```
+
+**After** (XML 태그로 의미 구분):
+
+```markdown
+# Code Writer Agent
+
+<role>
+task-planner의 계획에 따라 실제 코드를 작성하는 전문 Agent
+</role>
+
+<instructions>
+1. task-planner의 계획에 따라 코드 작성
+2. 프로젝트 규칙 준수
+3. 작은 단위로 구현하여 빌드 가능 상태 유지
+</instructions>
+
+<output_format>
+## 작성한 파일
+
+### 1. [파일 경로]
+- 변경 유형: 신규 생성 / 수정
+- 주요 내용: ...
+</output_format>
+```
+
+**개선 포인트**: `<role>`로 정체성, `<instructions>`로 절차, `<output_format>`으로 출력 구조를 명확히 분리
+
+---
+
+### 예시 2: Skill - 규칙 목록
+
+**Before** (마크다운만 사용):
+
+```markdown
+# 코딩 규칙
+
+## 규칙
+
+- 하나의 모듈은 하나의 책임만 가진다
+- 순환 의존을 만들지 않는다
+- Promise 처리 시 then-catch 패턴을 사용한다
+
+## 확인
+
+- 이 파일의 책임은 하나인가?
+- 순환 의존이 없는가?
+```
+
+**After** (XML 태그로 의미 구분):
+
+```markdown
+# 코딩 규칙
+
+<rules>
+- 하나의 모듈은 하나의 책임만 가진다 (SRP)
+- 모듈 간 의존 방향은 단방향으로 유지한다
+- Promise 처리 시 then-catch 패턴을 사용한다
+</rules>
+
+<checklist>
+- [ ] 이 파일의 책임은 하나인가?
+- [ ] 의존 방향이 단방향인가?
+- [ ] then-catch 패턴을 사용했는가?
+</checklist>
+```
+
+**개선 포인트**: `<rules>`와 `<checklist>`를 분리하여 "따라야 할 것"과 "검증할 것"을 명확히 구분
+
+---
+
+### 예시 3: Hook - Phase 구분
+
+**Before** (마크다운만 사용):
+
+```markdown
+# Pre-commit Hook
+
+## 단계 1: 계획 확인
+
+계획이 있는지 확인합니다. 계획이 없으면 중단합니다.
+
+## 단계 2: 코드 검증
+
+lint와 type check를 실행합니다.
+
+## 단계 3: 커밋
+
+변경사항을 커밋합니다.
+```
+
+**After** (XML 태그로 Phase 구분):
+
+```markdown
+# Pre-commit Hook
+
+<workflow>
+
+<phase name="계획 확인">
+계획이 존재하는지 확인한다. 계획이 있을 때만 다음 Phase로 진행한다.
+</phase>
+
+<phase name="코드 검증">
+lint와 type check를 실행한다. 모든 검증을 통과할 때만 다음 Phase로 진행한다.
+</phase>
+
+<phase name="커밋">
+변경사항을 커밋한다.
+</phase>
+
+</workflow>
+```
+
+**개선 포인트**: `<workflow>` > `<phase>` 구조로 단계 간 경계와 진행 조건을 명확히 표현
+
+---
+
+## `->` 기호 사용 가이드
+
+`->` 기호는 **방향성이 있는 흐름**을 간결하게 표현할 때 사용한다.
+
+### 단계 표현
+
+순서가 있는 프로세스를 나타낸다.
+
+```
+계획 -> 구현 -> 검증 -> 리뷰
+Context 수집 -> TaskList 생성 -> 코드 수정 계획
+```
+
+### 변환 표현
+
+입력이 출력으로 바뀌는 과정을 나타낸다.
+
+```
+부정 표현 -> 긍정 표현
+마크다운 제목 -> XML 태그
+"~금지" -> "~전담/전용"
+```
+
+### 위임 표현
+
+작업이 특정 Agent로 전달됨을 나타낸다.
+
+```
+코드 수정 -> code-writer Agent
+Git 작업 -> git-manager Agent
+코드베이스 탐색 -> explore Agent
+```
+
+### 테이블에서 사용
+
+변환 관계를 테이블로 정리할 때도 `->` 를 활용한다.
+
+```markdown
+| Before | -> | After |
+|--------|-----|-------|
+| "~금지" | -> | "~전담" |
+| `## 역할` | -> | `<role>` |
+```
+
+---
+
+## 주의사항
+
+### XML 태그는 마크다운을 보완한다
+
+XML 태그는 마크다운을 대체하는 것이 아니라 **의미 계층을 추가**하는 것이다.
+
+```markdown
+<rules>
+## 네이밍 규칙
+
+| 대상 | 규칙 | 예시 |
+|------|------|------|
+| 변수 | camelCase | `userName` |
+| 상수 | UPPER_SNAKE | `MAX_COUNT` |
+
+## 구조 규칙
+
+- 한 파일에 한 컴포넌트만 정의한다
+- index.ts를 통해 export한다
+</rules>
+```
+
+태그 내부에서 `##`, 테이블, 코드블록을 정상적으로 사용한다.
+
+### 태그 중첩은 2단계까지
+
+```markdown
+<!-- 허용: 2단계 -->
+<workflow>
+  <phase name="계획">...</phase>
+</workflow>
+
+<!-- 지양: 3단계 이상 -->
+<workflow>
+  <phase name="계획">
+    <sub-step>...</sub-step>    <!-- 과도한 중첩 -->
+  </phase>
+</workflow>
+```
+
+3단계 이상 중첩이 필요하면 마크다운 제목(`###`)이나 리스트로 대체한다.
+
+### 닫는 태그를 반드시 포함한다
+
+```markdown
+<!-- 올바름 -->
+<role>
+Agent의 역할 설명
+</role>
+
+<!-- 오류 -->
+<role>
+Agent의 역할 설명
+```
+
+모든 XML 태그는 여는 태그와 닫는 태그를 쌍으로 작성한다.
+
+### 태그 이름은 표준 목록에서 선택한다
+
+이 가이드의 **표준 태그 목록**에 정의된 태그만 사용한다. 커스텀 태그가 필요한 경우 기존 태그로 대체할 수 있는지 먼저 검토한다.
+
+---
+
+## 체크리스트
+
+<checklist>
+- [ ] 파일 유형(Agent/Skill/CLAUDE.md/Hook)에 맞는 태그 조합을 사용했는가?
+- [ ] 태그 내부에서 마크다운 문법(제목, 테이블, 코드블록)을 정상 활용하는가?
+- [ ] 태그 중첩이 2단계 이하인가?
+- [ ] 모든 태그에 닫는 태그가 포함되어 있는가?
+- [ ] 표준 태그 목록에 정의된 태그만 사용했는가?
+- [ ] `->` 기호를 단계/변환/위임 표현에 활용했는가?
+</checklist>
+
+<reference>
+- `SKILL.md` - 프롬프트 구조화 개요 및 핵심 원칙
+- `positive-phrasing.md` - 부정 -> 긍정 전환 패턴
+</reference>

package/{.claude → templates/global}/skills/React/SKILL.md

@@ -43,6 +43,8 @@ src/
 | Layout | 페이지 레이아웃 구조 | Header, Sidebar, Footer |
 | Page | 라우트에 매핑되는 페이지 | HomePage, LoginPage |
 
+<rules>
+
 ## 필수 준수 사항
 
 ### 컴포넌트 작성
@@ -58,20 +60,22 @@ src/
 
 | 규칙 | 설명 |
 |------|------|
-| 상태 최소화 | 파생 가능한 값은 상태로 두지 않음 |
+| 상태 최소화 | 파생 가능한 값은 계산으로 처리 |
 | 상태 위치 | 필요한 가장 가까운 공통 조상에 배치 |
-| 불변성 유지 | 상태 직접 수정 금지, 새 객체/배열 생성 |
+| 불변성 유지 | 상태 업데이트 시 새 객체/배열을 생성 |
 | 복잡한 상태 | useReducer 또는 상태 관리 라이브러리 사용 |
 
 ### Hooks 규칙
 
 | 규칙 | 설명 |
 |------|------|
-| 최상위에서만 호출 | 조건문, 반복문 내부에서 호출 금지 |
-| 의존성 배열 정확히 | useEffect, useMemo, useCallback의 deps 누락 금지 |
+| 최상위에서만 호출 | 조건문, 반복문 바깥의 최상위 레벨에서 호출 |
+| 의존성 배열 정확히 | useEffect, useMemo, useCallback의 deps를 빠짐없이 명시 |
 | 커스텀 훅 추출 | 재사용 가능한 로직은 커스텀 훅으로 분리 |
 | 훅 네이밍 | `use` 접두사 필수 (예: `useAuth`, `useFetch`) |
 
+</rules>
+
 ## 성능 최적화
 
 ### 메모이제이션
@@ -87,6 +91,8 @@ const expensiveValue = useMemo(() => computeExpensive(a, b), [a, b]);
 const handleClick = useCallback(() => doSomething(id), [id]);
 ```
 
+<rules>
+
 ### 최적화 적용 기준
 
 | 상황 | 적용 |
@@ -96,10 +102,16 @@ const handleClick = useCallback(() => doSomething(id), [id]);
 | 비용이 큰 계산 | `useMemo` 사용 |
 | 자식에게 전달하는 콜백 | `useCallback` 사용 |
 
-### 불필요한 최적화 금지
+<constraints>
+
+### 최적화 시 주의사항
+
+- memo는 측정 결과 리렌더링이 잦은 컴포넌트에만 적용 (React DevTools Profiler 사용)
+- 성능 측정 후 필요한 곳에만 최적화 적용
 
-- 모든 컴포넌트에 무조건 memo 적용 금지
-- 측정 없이 최적화하지 않음 (React DevTools Profiler 사용)
+</constraints>
+
+</rules>
 
 ## useEffect 패턴
 
@@ -128,6 +140,8 @@ useEffect(() => {
 | 렌더링 중 상태 업데이트 | 조건부 렌더링 또는 useMemo |
 | 불필요한 Effect | 이벤트 핸들러로 처리 |
 
+<checklist>
+
 ## 체크리스트
 
 ### 컴포넌트 작성 시
@@ -147,9 +161,13 @@ useEffect(() => {
 
 ### 성능
 - [ ] 리스트에 적절한 key가 사용되었는가?
-- [ ] 불필요한 리렌더링이 없는가?
+- [ ] 불필요한 리렌더링이 있는가? (있다면 memo 검토)
 - [ ] 메모이제이션이 적절히 사용되었는가?
 
+</checklist>
+
+<reference>
+
 ## 관련 문서
 
 | 문서 | 설명 |
@@ -157,3 +175,5 @@ useEffect(() => {
 | `tanstack-router.md` | TanStack Router 파일 기반 라우팅 패턴 |
 | `react-hook-form.md` | React Hook Form + Zod 폼 검증 패턴 |
 | `tailwind-styled.md` | tailwind-styled-components DOM depth 최소화 |
+
+</reference>