2.2 KiB
2.2 KiB
title, source_type, status, confidence, tags, related_projects, last_reviewed
| title | source_type | status | confidence | tags | related_projects | last_reviewed |
|---|---|---|---|---|---|---|
| llm-generated | draft | unknown |
{{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
이 개념을 면접/이력서에서 말할 때 과장하면 안 되는 지점.
근거 자료
- 공식 문서 제목 — 핵심 출처
[[raw/{{원본-경로}}]]— raw에 보존한 원본