---
title:
source_type: official-doc | company-tech-blog | personal-blog
url:
archive_url:
related_branches: []
related_projects: []
tags: []
created: YYYY-MM-DD
---

# {{title}}

> Layer: `raw/` — 외부 자료(공식 문서 / 대기업 기술 블로그)의 **원문 발췌·출처 기록**.
> 본 템플릿은 `raw/official-docs/` 와 `raw/company-tech-blogs/` 두 폴더가 공유.
> 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 `source-summary-template` 형식으로 별도 작성. 원본은 raw에 영구 보관.

## source_type 허용값

frontmatter `source_type:` 에는 다음 중 하나만 사용:

- `official-doc` — 공식 레퍼런스 / 표준 / 사양 (예: Spring Boot reference, RFC, AWS docs)
- `company-tech-blog` — 대기업 엔지니어링 블로그 / 컨퍼런스 발표 글 (예: Stripe, Netflix, Toss, 카카오)

해당하지 않는 자료는 별도 카테고리 검토 (강의는 `raw/lectures/`, 채용공고는 `raw/job-postings/`, 일반 블로그 글감은 `raw/blog-topics/`).

## 활용 branch (필수, 최소 1개+)

> 이 자료는 **혼자 존재하지 않는다.** 어느 branch(또는 project)의 구현 결정의 **근거**로서 보관됨. 어느 작업의 어떤 결정을 정당화하는지 명시. 같은 자료가 여러 branch에서 인용될 수 있으면 frontmatter `related_branches` 에 모두 나열 + 아래 표에 추가.

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| `[[raw/branch-notes/{{branch-name-1}}]]` | <한 줄: 어떤 결정의 근거인지> |
| `[[raw/branch-notes/{{branch-name-2}}]]` | <한 줄> |

특정 branch 없이 foundational 조사로 수집한 경우:

- `[[raw/project-notes/{{project-name}}]]` — <어떤 프로젝트의 초기 조사인지>

## 출처

- 원본 URL:
- 아카이브 URL:
- 저자 / 조직:
- 발행일:
- 마지막 확인일: YYYY-MM-DD

## 왜 저장했는지

> 이 자료를 보관하는 이유 1~2줄. 어떤 개념·문제·결정과 연결되는가. Parent 표의 "정당화하는 결정"과 일관되어야 함.

<이유>

## 핵심 인용

> 원문 그대로. 따옴표·줄바꿈 보존. 페이지·섹션 번호 있으면 같이.

> [§<section>] "원문 발췌 1."

> [§<section>] "원문 발췌 2."

> [§<section>] "원문 발췌 3."

## 추출된 주장

> 이 자료가 **직접 말하는 것만** claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기 쓰지 않는다.
> `Claim ID` 는 같은 raw 문서 안에서 안정적으로 유지한다. 예: `C1`, `C2`, `C3`.

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| C1 | <원문이 직접 지지하는 주장> | [§<section>] "<짧은 원문 인용>" | `official-strong` | <적용 가능한 조건> | <이 claim 으로 증명할 수 없는 것> |
| C2 | <주장> | [§<section>] "<짧은 원문 인용>" | `case-study` | <조건> | <한계> |

### Strength 허용값

- `official-standard` — RFC, 표준 사양, 언어/프로토콜 표준
- `official-vendor-doc` — Spring, Keycloak, AWS, Google 등 공식 벤더 문서
- `official-reference` — 공식 reference/API 문서
- `company-case-study` — 대기업/실무 기술 블로그의 특정 사례
- `engineering-blog` — 개인/팀 블로그의 엔지니어링 해설
- `tutorial` — 튜토리얼/가이드. 일반화 금지
- `needs-confirmation` — 원문만으로는 적용 판단 불가

## 적용 경계

- 이 자료가 직접 증명하는 것:
  - `C1`: <직접 증명 범위>
- 이 자료가 증명하지 않는 것:
  - <예: 특정 설정이 모든 런타임에서 기본 활성화된다는 뜻은 아님>
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  - <예: ca-tmpl 의 실제 Spring Security 설정에서 동작 검증 필요>


## 메모

> 나중에 wiki로 옮길 때 참고할 짧은 메모. 검증되지 않은 내 추론은 여기에 두지 말 것 (그것은 wiki/concepts의 source-summary 또는 wiki/projects 본문에서만 작성).

- 인용 1 해석 후보 (미검증):
- 추가로 봐야 할 동일 출처 페이지:

## 관련

> 같은 주제의 다른 raw 자료, 또는 이 자료를 인용한 wiki 문서.

- 같은 주제 다른 official-doc / company-tech-blog: `[[raw/<...>]]`
- 이 자료를 인용한 wiki 요약: `[[wiki/concepts/<...>]]` (생성 시)