fix: 하네스 제거 및 keycloak 문서 보강

This commit is contained in:
DongHyeonka
2026-07-25 12:53:13 +09:00
parent 6c53ded9cb
commit d71669eb59
2329 changed files with 138239 additions and 172816 deletions
-1
View File
@@ -1 +0,0 @@
../vault/00-system/templates/concept-template.md
+66
View File
@@ -0,0 +1,66 @@
---
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에 보존한 원본