---
title:
source_type: llm-generated
status: draft
confidence: unknown
tags: []
related_projects: []
last_reviewed:
---

# {{title}}

> Layer: `wiki/concepts/` — 일반 개념. 내 프로젝트 사실(`wiki/projects/`)은 `wiki-project-template` 사용 (raw 프로젝트 hub는 `project-template`).

## Summary

한두 문장으로 핵심 정의.

## Standard (공식 정의)

공식 문서 기준의 정의. 출처는 본문 끝 Sources 섹션에 명시.

## 한계 / 주의점

이 개념의 적용 한계, 흔한 오해, 트레이드오프. 공식 문서가 명시한 부분만 사실로, 그 외는 `needs-confirmation`으로 표기.

## Project Application

내 프로젝트에서 이 개념과 관련된 문서로 **링크**. 실제 구현 여부·검증 등급은 해당 project 문서에서 판정 (concept 문서는 등급을 직접 매기지 않음).

- `[[{{관련-project-문서}}]]`

## Claim-backed Knowledge

> 이 개념 문서의 핵심 설명은 raw source claim 으로 뒷받침되어야 한다.
> 공식 문서 claim, 회사 사례 claim, 내 프로젝트 decision 을 분리한다.

| Knowledge Point | Supporting Claims | Confidence | Notes |
|---|---|---|---|
| <개념 설명> | `raw/official-docs/<slug>.md#C1` | `high` | <공식 문서 기준> |
| <실무 적용 사례> | `raw/company-tech-blogs/<slug>.md#C2` | `medium` | <특정 회사 사례이므로 일반화 주의> |

## 내가 설명할 수 있어야 하는 것

- 이 개념의 공식 정의는 무엇인가?
- 어떤 문제를 해결하는가?
- 어떤 상황에서는 쓰면 안 되는가?
- 공식 문서가 말하지 않는 부분은 무엇인가?
- 회사 기술 블로그 사례를 일반 법칙처럼 말하면 안 되는 지점은 무엇인가?
- 내 프로젝트에서는 어떤 branch decision 으로 연결됐는가?
- 이 개념을 코드나 운영 환경에서 검증하려면 무엇을 확인해야 하는가?


## Interview Questions

- 면접에서 나올 법한 질문 1
- 면접에서 나올 법한 질문 2

## Do Not Overclaim

이 개념을 면접/이력서에서 말할 때 **과장하면 안 되는 지점**.

## 근거 자료

- [공식 문서 제목](https://example.com/...) — 핵심 출처
- `[[raw/{{원본-경로}}]]` — raw에 보존한 원본