7.0 KiB
title, source_type, status, confidence, tags, related_projects, last_reviewed, diagrams, architecture_review, status_label, project_revision, url, semantic_surface_exclusions
| title | source_type | status | confidence | tags | related_projects | last_reviewed | diagrams | architecture_review | status_label | project_revision | url | semantic_surface_exclusions | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 프로젝트 인프라 개요 | project-note | raw | unknown |
|
stub | 1 |
|
프로젝트 인프라 개요
작성 안내 이 파일은 첫
/ingest→/tag→/lint사이클 검증용 raw 문서입니다. 아래<...>자리표시자를 본인 프로젝트의 사실로 교체하세요. 일반론·추측·계획은 적지 말고 실제 한 일·확인한 것만 기록합니다. 작성 후/ingest raw/project-notes/project-infra-overview.md로 파이프라인을 검증합니다.관련 문서:
- CLAUDE — LLM Wiki 운영 규칙
- llm-wiki — vault MOC
- raw/project-notes/ca-skeleton-operational-contract — sister project note (ca-tmpl 운영 계약)
- templates/project-template —
wiki/projects/승급 시 사용할 템플릿
6.1 안정 결정 레지스트리
NEEDS_CONFIRMATION: 이 문서에는 아직 placeholder가 남아 있어서, 문서 자체 근거만으로 확정할 결정이 없다. 사실이 채워질 때까지 registry는 비워 둔다.
| Decision ID | Revision | Domain | Decision Summary | Status | Owner | Evidence |
|---|
8.0 실행계획
NEEDS_CONFIRMATION: 기존 branch decomposition row가 없으므로 stable WI를 생성하지 않는다.
| Work Item ID | branch slug | 완료 조건 (측정가능) | Applies Decisions | Dependencies | Status |
|---|
1. 프로젝트 한 줄 설명
<무엇을 만드는/만든 프로젝트인지 1–2문장>
2. 본인 역할
- 개인/팀 여부: <개인 프로젝트 | 팀 프로젝트 (N인)>
- 본인이 맡은 영역: <예: 백엔드 API, 인프라/배포, DB 모델링 등>
- 기간: <YYYY-MM ~ YYYY-MM>
3. 기술 스택
- 언어:
- 프레임워크:
- DB:
- 캐시 / 메시징:
- 인프라 / 배포:
- 모니터링 / 로깅:
- 기타:
4. 인프라 구성 요약
<어떤 환경에서 돌고 있는지. 도식이 있으면 붙이고, 없으면 글로 풀어 쓴다. 로컬/dev/staging/prod 중 어디까지 실제로 띄워 봤는지 밝힌다.>
4.1 시스템 아키텍처 (draw.io)
templates/project-template.md§3.1 표준에 따라 작성. 저장 경로:raw/diagrams/<project-slug>/architecture-overview-YYYY-MM-DD.drawio.svg. 다이어그램이 생기면 아래 wikilink 갱신:
실제 사용 예 (drawio 파일 생성 후 placeholder 부분을 실제 값으로 치환):
![[raw/diagrams/<project-slug>/architecture-overview-YYYY-MM-DD.drawio.svg]]
(아직 다이어그램 없음. drawio 생성 후 위 code block 밖으로 wikilink 빼기.)
4.2 핵심 시퀀스 (Mermaid)
주요 user flow 1개 이상. happy path + error path 함께.
sequenceDiagram
autonumber
actor User
participant System
User->>System: <action>
System-->>User: <response>
(아직 시퀀스 미정. 작업 진입 후 채움.)
5. 본인이 한 작업 (사실만)
각 항목 옆에 증거 등급을 표기합니다.
가능한 등급: actually-implemented | locally-verified | prod-verified | documented-only | planned | needs-confirmation
- <작업 1 설명> — 등급:
<...> - <작업 2 설명> — 등급:
<...> - <작업 3 설명> — 등급:
<...>
6. 마주친 문제 / 트러블슈팅
<실제 겪은 이슈만. 원인 → 시도 → 해결 순. 일반론 X>
- 이슈 1:
- 원인:
- 시도:
- 해결:
7. 자신 없는 부분
<면접에서 나올 수 있지만 본인이 확실히 답하지 못하는 영역. /interviewize가 "모른다고 답해야 할 범위"를 정리할 때 쓴다.>
8. 관련 자료
- 저장소 URL:
- 관련 PR / 커밋:
- README 경로:
- 설계 문서:
9. 묶음 (이 프로젝트에 묶이는 모든 raw 자료)
본 project-note가 cluster의 entry point다. branch / errors / interviews / lectures / job-postings / sources 는 모두 여기로 upward link 를 건다. hub 쪽에서도 카테고리별로 적어 둔다.
9.1 브랜치 (작업 단위 hub)
generated reverse view는 child branch의 v2 contract migration 후 채운다. 아래 수기 Cluster는 그 전까지 보존한다.
| Branch migration status | Reason |
|---|---|
NEEDS_CONFIRMATION |
placeholder를 실제 project 사실로 교체하기 전에는 branch row를 만들지 않는다 |
최상위 root branch들. sub-branch들은 root branch hub의 Cluster 섹션 참조.
- (없음 — 본 프로젝트 작업 시작 전. branch 생성 시 wikilink 추가.)
9.2 근거 자료 (프로젝트 전체 차원 foundational 조사)
- (없음)
9.3 오류 기록 (branch 외 발생한 환경·운영 이슈)
- (없음)
9.4 면접 준비 (프로젝트 전체 차원 면접 질문)
- (없음)
9.5 Job postings (프로젝트 관련 채용공고)
- (없음)
9.6 파생 wiki 문서
- canonical 검증 사실: (없음)
- 관련 일반 개념: (없음)
- 포트폴리오: (없음)
- 블로그 글: (없음)
10. 아키텍처 검토 체크리스트 (작성/갱신 시 self-check)
본 project-note가 hub 역할을 제대로 하려면 모두 ✓ 여야 함. 현재는 placeholder 상태이므로 모두 미달.
- 한 줄 요약 + 현재 상태 + 나의 역할 채워짐 (§1, §2)
- 측정 가능한 성공 기준 1개 이상
- 아키텍처 다이어그램 (
.drawio.svg) 1개 이상 첨부 (§4.1) - 다이어그램의 모든 컴포넌트가 라벨 + 역할 + 기술 스택 표기
- 다이어그램의 모든 화살표가 프로토콜·데이터 종류 라벨링
- 외부 시스템이 점선 또는 색으로 시각적 구분
- 범례(Legend) 다이어그램에 포함
- 신뢰 경계 / 네트워크 경계 표시
- 시퀀스 다이어그램 1개 이상 (Mermaid) — happy path + error path 함께 (§4.2)
- Cluster 섹션의 root branch 목록 채워짐 (§9.1)
- 마지막 architecture review 날짜 frontmatter
architecture_review:에 기록
다 쓴 뒤에도
status는raw그대로 둡니다(이건 raw 문서니까요). 그 상태에서/ingest를 실행하면wiki/projects/에 변환 문서가 만들어집니다.