143 lines
6.5 KiB
Markdown
143 lines
6.5 KiB
Markdown
---
|
|
title: 2026-05-27 일일 노트
|
|
source_type: daily-note
|
|
status: raw
|
|
tags: [daily, ca-tmpl, ca-skeleton, clean-architecture]
|
|
date: 2026-05-27
|
|
branches: [
|
|
feature-skeleton-package-blueprint-contract
|
|
]
|
|
---
|
|
|
|
# 2026-05-27
|
|
|
|
> Layer: `raw/daily-notes/` — 그날의 혼합 일일 기록. 그 자체는 wiki로 옮기지 않으며, `/ingest`가 promotable 항목만 추출.
|
|
|
|
## 활성 브랜치
|
|
|
|
ca-tmpl Phase C2 실 코드 진입을 위한 첫 착수 브랜치. 오늘은 전체 roadmap 구현이 아니라, 첫 브랜치 범위를 확정하고 시작 조건을 정리한다.
|
|
|
|
- `feature-skeleton-package-blueprint-contract` (planned) — [[raw/branch-notes/feature-skeleton-package-blueprint-contract]]
|
|
|
|
## 오늘의 계획
|
|
|
|
- [ ] [ca-tmpl] Phase C2 전체 구현 순서를 dependency-first roadmap으로 고정한다.
|
|
- [ ] [feature-skeleton-package-blueprint-contract] 오늘 실제 착수 범위를 package/module skeleton으로 제한한다.
|
|
- [ ] [feature-skeleton-package-blueprint-contract] 완료 조건을 `actually-implemented`와 `locally-verified` 증거로 갱신할 수 있게 정의한다.
|
|
|
|
## 구현 순서 메모 / Phase C2 roadmap
|
|
|
|
> 아래 목록은 오늘 하루 작업량이 아니라 Phase C2 전체 roadmap이다. 오늘은 1단계의 첫 브랜치 착수까지만 현실적인 범위로 둔다.
|
|
|
|
### 0. 전제
|
|
|
|
- ca-tmpl은 현재 Phase A-E 문서/설계 완료, Phase C2 실 코드 미진입 상태다.
|
|
- `wiki/projects/ca-tmpl.md` 기준으로 모든 16개 의사결정 문서는 `documented-only`다.
|
|
- 따라서 개발 브랜치는 "기능 추가"가 아니라 `documented-only` 결정을 실제 코드와 테스트 증거로 승급시키는 작업이다.
|
|
|
|
### 1. Foundation / package skeleton
|
|
|
|
1. `feature-skeleton-package-blueprint-contract`
|
|
2. `feature-architecture-enforcement-rules`
|
|
3. `feature-application-port-usecase-contract`
|
|
|
|
이 단계에서 module/package layout, use case/port 기본 타입, ArchUnit boundary rule을 먼저 만든다. 이후 작업은 이 구조를 기준으로 파일 위치와 의존 방향을 맞춘다.
|
|
|
|
### 2. API boundary + error envelope
|
|
|
|
1. `feature-boundary-validation-mapping-contract`
|
|
2. `feature-api-contract-baseline`
|
|
3. `feature-operational-error-observability-foundation`
|
|
|
|
Controller DTO validation, request/response mapper, structured success/error envelope, exception ownership을 먼저 고정한다. 이후 persistence/outbound/runtime 오류도 같은 envelope와 category로 흘려보낼 수 있어야 한다.
|
|
|
|
### 3. Observability baseline
|
|
|
|
1. `feature-log-management-contract`
|
|
2. `feature-distributed-tracing-contract`
|
|
3. `feature-metrics-alerting-contract`
|
|
4. `feature-operational-runbook-contract`
|
|
|
|
로그/MDC/trace/metric key는 후속 adapter와 background job에서 공통으로 소비한다. runbook은 stub로 먼저 두고, 실제 장애 재현이 생기면 갱신한다.
|
|
|
|
### 4. Config + optional adapter switch
|
|
|
|
1. `feature-env-driven-runtime-configuration`
|
|
2. `feature-secrets-config-source-contract`
|
|
3. `feature-integration-adapter-templates`
|
|
4. `feature-outbound-http-client-baseline`
|
|
|
|
환경 변수와 secret 분류, adapter on/off 조건, outbound timeout/retry 기본값을 묶는다. 이 단계가 끝나야 DB/cache/message adapter를 같은 방식으로 붙일 수 있다.
|
|
|
|
### 5. Data consistency + sample domain fixture
|
|
|
|
1. `feature-persistence-failure-baseline`
|
|
2. `feature-transaction-concurrency-contract`
|
|
3. `feature-cache-consistency-contract`
|
|
4. `feature-domain-event-outbox-contract`
|
|
5. `feature-sample-domain-contract-fixture`
|
|
|
|
sample-ticket fixture를 사용해 persistence failure, transaction boundary, cache degradation, outbox publish 흐름을 검증한다. 이때 sample은 비즈니스 기능이 아니라 contract 검증 fixture로만 둔다.
|
|
|
|
### 6. Security + tenant + idempotency
|
|
|
|
1. `feature-security-operational-baseline`
|
|
2. `feature-management-actuator-security-contract`
|
|
3. `feature-tenant-context-policy`
|
|
4. `feature-repository-access-permission-contract`
|
|
5. `feature-rate-limit-idempotency-contract`
|
|
|
|
인증/인가/actuator 분리, tenant context propagation, repository access capability, idempotency key 저장소를 묶어 검증한다.
|
|
|
|
### 7. Runtime + lifecycle + migration
|
|
|
|
1. `feature-runtime-health-lifecycle-contract`
|
|
2. `feature-migration-startup-contract`
|
|
3. `feature-container-runtime-contract`
|
|
4. `feature-background-job-async-contract`
|
|
|
|
health endpoint, readiness/startup, migration ordering, container shutdown, async context propagation을 검증한다. 로컬 docker-compose에서 재현 가능한 확인 절차를 남긴다.
|
|
|
|
### 8. Governance + CI quality gate
|
|
|
|
1. `feature-contract-registry-governance`
|
|
2. `feature-contract-verification-test-suite`
|
|
3. `feature-ci-quality-gates-contract`
|
|
4. `feature-build-release-supply-chain-contract`
|
|
5. `feature-developer-experience-contract`
|
|
6. `feature-implementation-readiness-scorecard`
|
|
|
|
registry yaml 기반 generated constants, contract test suite, CI gate, supply chain metadata, README/onboarding, readiness scorecard를 마지막에 묶는다. 앞 단계의 산출물이 있어야 gate가 실제로 검증할 대상이 생긴다.
|
|
|
|
## 한 일
|
|
|
|
- [ca-tmpl] branch-note 기반 Phase C2 구현 순서 초안을 daily-note에 기록했다.
|
|
- [ca-tmpl] 오늘 하루 범위와 Phase C2 전체 roadmap을 분리했다.
|
|
|
|
## 배운 점
|
|
|
|
> wiki/concepts/로 promotable 후보
|
|
|
|
- ca-tmpl의 다음 단계는 새 설계가 아니라 `documented-only` 결정을 코드와 로컬 검증 증거로 승급시키는 단계다.
|
|
- 구현 순서는 domain feature가 아니라 contract dependency 순서로 잡아야 한다.
|
|
|
|
## 트러블슈팅
|
|
|
|
- 없음. 오늘 기록은 개발 진입 순서 정리이며 코드 실행은 아직 하지 않음.
|
|
|
|
## 면접·포트폴리오로 옮길 만한 것
|
|
|
|
> 후보 표기만. daily-note에서 `wiki/interview/` 또는 `wiki/portfolio/`를 직접 만들지 않는다.
|
|
|
|
- "documented-only 설계를 actually-implemented로 승급시키는 절차" → `wiki/projects/ca-tmpl.md` 갱신 후 파생 가능.
|
|
- "Clean Architecture skeleton에서 구현 순서를 contract dependency 기준으로 잡은 이유" → Phase C2 로컬 검증 후 portfolio 후보.
|
|
|
|
## 내일로 넘긴 것
|
|
|
|
- [ca-tmpl] `/home/donghyeon/workspace/ca-tmpl/`에서 `feature-skeleton-package-blueprint-contract` 구현 시작.
|
|
- [ca-tmpl] 첫 구현 브랜치 완료 후 `wiki/projects/ca-tmpl/clean-architecture-package-layout.md`의 evidence section 갱신.
|
|
|
|
## 잡담 / 회의 / 기타
|
|
|
|
- 사용자가 "시간이 너무 지나서 개발 단계로 들어가야 한다"고 판단. 오늘 기록은 그 전환점을 남기는 목적이다.
|