donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
d6dfda64ab42a97de02624a406caafe594db2d8d
llm-wiki/raw/daily-notes/2026-05-27.md
T

6.5 KiB
Raw Blame History

title, source_type, status, tags, date, branches
title source_type status tags date branches
2026-05-27 일일 노트 daily-note raw
daily
ca-tmpl
ca-skeleton
clean-architecture
2026-05-27
feature-skeleton-package-blueprint-contract

2026-05-27

Layer: raw/daily-notes/ — 그날의 혼합 일일 기록. 그 자체는 wiki로 옮기지 않으며, /ingest가 promotable 항목만 추출.

활성 브랜치

ca-tmpl Phase C2 실 코드 진입을 위한 첫 착수 브랜치. 오늘은 전체 roadmap 구현이 아니라, 첫 브랜치 범위를 확정하고 시작 조건을 정리한다.

오늘의 계획

  • [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 갱신.

잡담 / 회의 / 기타

  • 사용자가 "시간이 너무 지나서 개발 단계로 들어가야 한다"고 판단. 오늘 기록은 그 전환점을 남기는 목적이다.
Reference in New Issue View Git Blame Copy Permalink