107 lines
4.3 KiB
Markdown
107 lines
4.3 KiB
Markdown
---
|
|
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/<...>]]` (생성 시)
|