---
title: 프로젝트 인프라 개요
source_type: project-note
status: raw
confidence: unknown
tags: [project-note, project-overview, infra, stub]
related_projects: []
last_reviewed:
diagrams: []
architecture_review:
status_label: stub
project_revision: 1
url:
semantic_surface_exclusions:
  - artifact-registry|stub project has no project-local Artifact Registry; harness/source/typed-contracts.json is authoritative until facts are supplied
  - contract-gate-registry|stub project has no project-local Contract/Gate Registry; harness/source/typed-contracts.json is authoritative until facts are supplied
  - flow-stage-registry|stub project has no project-local Flow/Stage Registry; harness/source/typed-contracts.json is authoritative until facts are supplied
---

# 프로젝트 인프라 개요

> **작성 안내**
> 이 파일은 첫 `/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/` 승급 시 사용할 템플릿

---

<!-- section-id: project-decisions -->
## 6.1 안정 결정 레지스트리

> `NEEDS_CONFIRMATION`: 이 문서에는 아직 placeholder가 남아 있어서, 문서 자체 근거만으로 확정할 결정이 없다. 사실이 채워질 때까지 registry는 비워 둔다.

| Decision ID | Revision | Domain | Decision Summary | Status | Owner | Evidence |
|---|---:|---|---|---|---|---|

<!-- section-id: project-work-items -->
## 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:
- 캐시 / 메시징:
- 인프라 / 배포:
- 모니터링 / 로깅:
- 기타:

<!-- section-id: sequence -->
## 4. 인프라 구성 요약

<어떤 환경에서 돌고 있는지. 도식이 있으면 붙이고, 없으면 글로 풀어 쓴다. 로컬/dev/staging/prod 중 어디까지 실제로 띄워 봤는지 밝힌다.>

<!-- section-id: architecture-components -->
### 4.1 시스템 아키텍처 (draw.io)

> `templates/project-template.md` §3.1 표준에 따라 작성. 저장 경로: `raw/diagrams/<project-slug>/architecture-overview-YYYY-MM-DD.drawio.svg`.
> 다이어그램이 생기면 아래 wikilink 갱신:

```markdown
실제 사용 예 (drawio 파일 생성 후 placeholder 부분을 실제 값으로 치환):
![[raw/diagrams/<project-slug>/architecture-overview-YYYY-MM-DD.drawio.svg]]
```

(아직 다이어그램 없음. drawio 생성 후 위 code block 밖으로 wikilink 빼기.)

<!-- section-id: runtime-flow -->
### 4.2 핵심 시퀀스 (Mermaid)

> 주요 user flow 1개 이상. happy path + error path 함께.

```mermaid
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:
  - 원인:
  - 시도:
  - 해결:

<!-- section-id: implementation-boundaries -->
## 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: branches:start -->
<!-- GENERATED: branches:end -->

> 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/`에 변환 문서가 만들어집니다.