donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
4e6374141bb9cd108294f7921cd4ff390dfe94bd
llm-wiki/raw/daily-tasks/README.md
T

19 KiB
Raw Blame History

title, source_type, status, tags, last_reviewed
title source_type status tags last_reviewed
daily-tasks / Hub meta stable
meta
daily-task
hub
2026-05-28

daily-tasks / Hub

Layer: raw/daily-tasks/ — 매일 아침 학습용 실습 과제 의 카테고리 진입점. 사수가 신입에게 주는 형식의 자율 학습 과제를 두 트랙으로 분리 누적.

0. 한 줄 요약

항목 값
사용 cadence 매일 아침
트랙 develop/ + infra/ 두 가지 동시 진행 (각 ~2시간)
1과제 분량 duration_estimate: 120 분 default (Pomodoro 4-5개) — 완료 신호 까지의 자기 추정치
Template templates/daily-task-develop-template.md / templates/daily-task-infra-template.md
산출물 branch (daily-task/<track>/<slug>), commit/PR, manifest, dashboard/alert, 회고
Promotion 경로 verified 항목만 /ingest 로 wiki/concepts/ 또는 wiki/projects/ (CLAUDE.md §15)

1. 폴더 구조

raw/daily-tasks/
├── README.md                                          ← 이 파일 (hub)
├── develop/
│   └── YYYY-MM-DD-<implementation-slug>.md            ← 매일 1개
└── infra/
    └── YYYY-MM-DD-<implementation-slug>.md            ← 매일 1개

2. 명명 규칙

  • 파일명: YYYY-MM-DD-<implementation-slug>.md
  • YYYY-MM-DD = target_date (수행 예정일). 미래 과제를 미리 작성해도 무방.
  • <implementation-slug> = 무엇을 배우고 구현하는지 를 4~7 단어 영문 kebab-case 로. 슬러그만 보고도 과제 내용 파악 가능해야 함.
  • 좋은 예:
    • develop/2026-05-29-archunit-controller-domain-return-rule.md
    • develop/2026-05-30-jackson-fail-on-unknown-properties-policy.md
    • infra/2026-05-29-actuator-readiness-probe-db-disconnect.md
    • infra/2026-05-30-prometheus-pod-restart-alert-rule.md
  • 나쁜 예 (금지):
    • ❌ develop/task-1.md (의미 zero)
    • ❌ infra/day-3-monitoring.md (numbered hierarchy + 의미 부족)
    • ❌ develop/오늘과제.md (한글 파일명)
  • 자세한 규칙: rules/naming-conventions (§2.2.1 daily-task 명명)

3. 두 트랙의 차이

항목 develop infra
주 산출물 코드 commit / PR / 테스트 / ArchUnit rule manifest / config / probe / alert rule / dashboard
검증 채널 unit test, contract test, build pipeline kubectl + promql + log query + smoke test (≥2 채널 교차)
§5 흐름 코드 작성 → 테스트 작성 → 빌드 → PR manifest 작성 → apply → 관측 → 롤백 drill
시간 분포 CPU bound (Pomodoro 직접) apply / 수렴 대기 시간 포함
회복력 anchor (§11) 없음 있음 — fail-fast vs degrade, 롤백 트리거
Template templates/daily-task-develop-template templates/daily-task-infra-template

4. 트랙별 6-month 커리큘럼

매일 1과제 × 2트랙을 6개월 (약 130 영업일) 진행했을 때 도달 목표를 시니어 초반급 문제해결력 으로 설정. 단순 지식 누적이 아닌 trade-off articulation / system thinking / failure-mode awareness / root-cause tracing 4역량의 동시 향상.

목표 정의 근거: [[raw/company-tech-blogs/senior-engineer-competency-mubin-shaikh]]#SR-MUBIN-C1 (system thinking — latency/throughput/failure-mode 까지), #SR-MUBIN-C3 (trade-off 명시 — "best practice" 인용은 senior 미달), #SR-MUBIN-C4 (증상 아닌 근본 원인 + 재발 방지까지), #SR-MUBIN-C5 (커리어 초반=무엇을 만드는가, 후반=어떤 결정을 주도하는가).

격상 위험 주의 (raw 의 ELEV-1, ELEV-2): 본 anchor 는 personal-blog 단독 근거. 커리큘럼 본문에서 인용할 때는 "Mubin Shaikh 관점에서" 또는 "참고 기준으로" 한정. 공식 industry standard 처럼 표현 금지.

4.0 4역량 anchor — 시니어 초반급 의 조작적 정의

역량 의미 측정 신호 (도달 시) 인용
System thinking 코드 한 함수가 아닌 시스템 전체 (request 진입~응답 반환 + 의존성 + 실패 전파) 로 사고 새 feature 를 requirements → deployment → 운영 까지 혼자 설계 가능 #SR-MUBIN-C1
Trade-off articulation 모든 결정에 "왜 이걸 골랐고 왜 다른 걸 안 골랐는가" 를 최소 2-3개 댈 수 있음. "best practice 이니까" 거부 자기 PR 의 design choice 를 1분 안에 3개 trade-off 와 함께 설명 #SR-MUBIN-C3
Failure-mode awareness 정상 path 가 아니라 어떻게 깨지는가 부터 설계. 새 기능 도입 시 새 실패 모드를 함께 명시 새 코드 / manifest 의 §11 운영 회복력 anchor 가 빈칸이 아님 #SR-MUBIN-C1, #SR-MUBIN-C4
Root-cause tracing production issue 를 증상 (retry 실패) 이 아닌 근본 원인 (idempotency 누락) 까지 추적. 재발 방지 (alert / contract test) 까지 책임 issue 1건당 fix + alert + contract test 의 3-pack 결과 #SR-MUBIN-C4

매 phase 끝에 위 4역량을 0~5 self-rate. 6개월 끝에서 모두 ≥ 3 이 목표 (참고 기준, Mubin Shaikh 관점).

4.1 develop 트랙 — 6 phase (각 4주)

Phase 핵심 anchor 시니어 사고 강제 (trade-off) 산출물
D-P1 Boundary Contract Enforcement ArchUnit, Spring MVC exception, Bean Validation 4-layer, mapper boundary 정적 분석 vs runtime 검증 trade-off / false-positive vs leak coverage 5-8 ArchUnit rule, mapping exception classifier, contract test 묶음
D-P2 Mapper & Serialization Safety record + canonical constructor, MapStruct optional, Jackson polymorphic 보안 (CVE-2019-14379 패턴), PATCH semantics (RFC 7396 미채택) 수기 mapper vs generated trade-off / enableDefaultTyping 보안 vs 편의 / null=deletion vs absent 의미 mapper 패턴 카탈로그 + polymorphic deserialization 보안 test + PATCH endpoint 3-상태 contract
D-P3 Data & Transaction Contract JPA, TransactionPort 추상화, optimistic / pessimistic lock, idempotency key, repository capability tx 경계 위치 (controller/service/UC) trade-off / lock 종류 선택 / idempotency table vs request-key cache TransactionPort 구현 + idempotency 처리 + capability 테스트
D-P4 Domain Event & Async Boundary outbox pattern, transactional event publish, async executor, virtual thread (Loom) 호환성 동기 vs 비동기 trade-off / outbox 폴링 주기 vs latency / virtual thread + ThreadLocal MDC outbox publisher + async boundary test + virtual thread compatibility test
D-P5 API Surface & Schema Evolution OpenAPI spec-first, contract test, API versioning, breaking change 분류 spec-first vs code-first trade-off / version 전략 (header/path) / unknown field 허용 시점 OpenAPI v1 + spec drift detection + deprecation policy
D-P6 Performance & Concurrency JMH micro-bench, async profiler, jstack 분석, concurrency primitives (ReentrantLock vs synchronized vs StampedLock) latency vs throughput trade-off / bench reliability (warmup, GC noise) / lock 선택 JMH report + bottleneck analysis + lock comparison

D-P1 상세 — 시작 phase, 모든 후속 phase 의 baseline

  • 진입 조건: ca-tmpl 빌드 통과, ArchUnit 의존성 추가 가능
  • 학습 anchor:
  • 변수 / 상황 anchor (매 과제 §8 회고에 답할 것):
    • rule 이 잡지 못하는 우회 패턴 (reflection / generic Object 반환 / dynamic proxy) — 어디까지 ArchUnit 으로 가는 게 합리적인가?
    • false positive 1건 vs leak 1건의 비대칭 비용
    • generated code (MapStruct, Lombok) exemption 의 위치
  • 시니어 초반급 도달 신호 (이 phase 끝났을 때):
    • controller / service / DTO 의 boundary leak 시나리오 5개 를 trade-off 와 함께 설명 가능
    • 새 rule 추가 시 false positive 측정 부터 시작하는 절차가 몸에 익음
  • 예상 과제 흐름 (영업일 기준):
    • W1: controller return type rule + JSON leak integration test (오늘 작성된 첫 과제로 시작)
    • W2: request DTO → application 직접 전달 금지 rule + Bean Validation group sequence
    • W3: Mapping exception classifier + ResponseEntityExceptionHandler 확장
    • W4: Jackson deserialization 정책 강제 + integration cross-check

D-P2 상세

  • 진입 조건: D-P1 의 boundary contract 가 코드로 강제됨
  • 학습 anchor:
  • 변수 / 상황 anchor:
    • MapStruct generated code 가 build 마다 stale 가능 → CI 검증
    • sealed Command interface 의 Jackson 2.15+ 자동 인식 vs 명시 @JsonTypeInfo trade-off
    • PATCH null 의 의미 (3-상태) 를 OpenAPI 에 어떻게 노출하는가
  • 시니어 초반급 도달 신호:
    • polymorphic deserialization gadget chain 의 공격 시나리오 를 1개 그릴 수 있음
    • PATCH 의 silent overwrite 버그 패턴을 코드 리뷰에서 즉시 잡아냄

D-P3 ~ D-P6 (요약, 상세는 phase 진입 시 README 갱신)

각 phase 진입 시 그 phase 의 첫 주차에 본 README 의 해당 sub-section 을 D-P1/D-P2 와 동일 깊이로 채운다 — phase 진입은 README 갱신부터. 이게 진행 추적 anchor.

4.2 infra 트랙 — 6 phase (각 4주)

Phase 핵심 anchor 시니어 사고 강제 (trade-off) 산출물
I-P1 Health & Lifecycle actuator probe (readiness/liveness 분리), graceful shutdown, startup validation, JVM/container 자원 한계 probe period vs detection latency / liveness 에 DB 포함의 치명적 함정 / fail-fast vs degrade probe contract + chaos drill + startup validation matrix
I-P2 Observability Fundamentals structured JSON log, MDC propagation, OpenTelemetry trace context (virtual thread 호환), baseline metric (RED + USE), SLO 정의 observability cost vs coverage / sampling rate / cardinality 폭발 위험 dashboard 묶음 + alert rule + SLO 문서
I-P3 Resilience Pattern circuit breaker (Resilience4j), retry, rate limit, backpressure, bulkhead retry vs idempotency / breaker threshold / queue size 의 latency 영향 resilience 통합 + chaos test (지연/단절/burst)
I-P4 Cluster Operation k8s manifest, helm chart, rollout/rollback drill, secret 관리 (sealed secret / external secret operator) gitops vs imperative / blue-green vs canary / secret rotation 자동화 trade-off helm chart + rollback runbook + secret rotation drill
I-P5 Capacity & Cost HPA (CPU/memory/custom metric), resource limits, profile-driven sizing, cost reporting over-provision (cost) vs under-provision (SLO 위험) / HPA 스파이크 vs 비용 / right-sizing 의 측정 노이즈 sizing report + HPA policy + cost dashboard
I-P6 Security & Supply Chain RBAC, network policy, image scan (Trivy), SBOM 생성, secret rotation, supply chain attestation security vs DX trade-off / scan blocking vs warning / sbom 검증 강도 SBOM pipeline + image scan gate + rotation drill

I-P1 상세 — 시작 phase, 모든 infra 작업의 baseline

  • 진입 조건: 로컬 cluster (kind/k3d/minikube) + Prometheus/Grafana 가 동작
  • 학습 anchor:
  • 변수 / 상황 anchor (매 과제 §8 회고에 답할 것):
    • probe 가 측정하려는 것 (트래픽 받을 준비) 과 실제로 측정되는 것 (HTTP 200) 사이의 갭
    • 측정값 간 시간차 (actuator vs kubectl vs prometheus) — scrape interval 영향
    • liveness/readiness 혼동 시 발생하는 cascade failure (재기동 폭주)
    • probe 자체의 timeout (actuator hang) — DB 가 죽었는데 readinessProbe 도 timeout
  • 시니어 초반급 도달 신호:
    • readiness/liveness 의 운영적 차이를 1분 안에 설명 + 잘못 설정한 시스템의 cascade failure 시나리오 2개 묘사 가능
    • 새 운영 변경 도입 시 측정값 baseline → 변경 → 측정값 after → 차이 분석 흐름이 자동
  • 예상 과제 흐름:
    • W1: actuator readiness probe 분리 + DB 단절 시 측정 (오늘 작성된 첫 과제)
    • W2: graceful shutdown + in-flight 요청 처리 (terminationGracePeriodSeconds 와 actuator 의 관계)
    • W3: startup validation + 의도적 잘못된 env 로 fail-fast 시간 측정
    • W4: JVM/container 자원 한계 시뮬레이션 + OOM 시 cleanup

I-P2 ~ I-P6 (요약)

D-P3~D-P6 와 동일 — phase 진입 시 본 README 의 해당 sub-section 을 채우는 것이 phase 시작.

4.3 변수 / 상황 anchor — 공통 메타 패턴

매 phase, 매 과제 §8 회고에 답해야 하는 메타 질문 (시니어 사고 강제):

  1. 베이스라인 측정 없이 시작했는가? — 없으면 변경 후의 "좋아졌다" 가 측정 불가. 매 과제 §5 Step 1 은 항상 baseline.
  2. 예상 결과 vs 실측의 차이는 몇 %인가? — 일치하면 학습 0, 차이 클수록 학습 ↑. 차이가 0% 면 과제 너무 쉬움 (difficulty 조정 신호).
  3. 이 결정의 우회 가능 경로 는 무엇인가? — 정적 분석은 reflection 우회, alert 는 silent failure 우회, contract test 는 misconfig 우회. 우회 1개를 매번 명시.
  4. 이 결정이 추가하는 실패 모드는 무엇인가? — 새 rule 은 false positive, 새 probe 는 toggle 폭주, 새 alert 는 fatigue. 추가 실패 1개를 매번 명시.
  5. 되돌릴 명령은 무엇인가? — 롤백 명령을 작성하기 전에 코드/manifest 작성 금지. 매 infra 과제는 snapshot first.

이 5개 질문이 4역량 anchor (§4.0) 의 일상 운영판.

4.4 cross-track integration

매 phase 끝에 두 트랙이 같은 도메인을 다르게 보는 cross-check 1개:

시점 develop ↔ infra cross-check
P1 끝 D-P1 의 ArchUnit rule 이 I-P1 의 probe-on-startup 검증과 일관: rule 위반 build 가 startup validation 단계에서도 잡히는가?
P2 끝 D-P2 의 mapper masking 정책 ↔ I-P6 의 image scan 의 PII pattern. 둘이 동일 PII set 을 cover?
P3 끝 D-P3 의 idempotency key ↔ I-P3 의 retry policy. retry 가 idempotency 없이 발동 시 contract test 가 잡는가?
P4 끝 D-P4 의 outbox + virtual thread ↔ I-P2 의 trace propagation. virtual thread 경계에서 trace 가 끊기는가?
P5 끝 D-P5 의 OpenAPI spec drift ↔ I-P4 의 helm rollout. spec drift 가 rollout 차단으로 이어지는가?
P6 끝 D-P6 의 bottleneck profiling ↔ I-P5 의 HPA policy. 측정된 bottleneck 이 HPA metric 으로 연결되는가?

4.5 진행 추적 / 자가평가

  • 매 phase 끝 (4주차 금요일 권장): §4.0 4역량 표를 0-5 self-rate
  • phase 가 4주를 넘으면 진척이 안 나는 신호 → 학습 anchor 분할 (예: D-P2 를 mapper + Jackson 보안 2개로 쪼개기)
  • 6개월 끝: 6회 self-rate 누적 → 역량별 성장 곡선 그리기

4.6 커리큘럼이 틀어졌을 때

  • production / 회사 일정으로 1주 이상 멈추면: 멈춘 시점의 phase 마지막 과제 §8 회고를 다시 읽고 그 phase 의 학습 anchor 만 5분 재정리. 연속성 회복 후 재개.
  • 한 phase 가 너무 쉬워서 2주 만에 끝나면: 다음 phase 진입 전 에 cross-track integration 과제 1개 (§4.4) 를 끼워 깊이 보강.
  • 한 phase 가 너무 어려워서 6주 넘어가면: 학습 anchor 를 반으로 자르고 새 phase 추가. 6 phase → 7 phase 로 확장 허용.

5. 하루 흐름 권장

07:00 - 09:00   develop 과제 1개 (~2h)
09:00 - 09:15   회고 (§8) + commit/PR
09:15 - 11:15   infra 과제 1개 (~2h)
11:15 - 11:30   회고 (§8) + apply 결과 정리

총 4시간 (이동시간 / 휴식 미포함). 각 트랙 회고 5분은 반드시 — 회고 없는 과제 = 학습 손실 (raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode#DP-RGC-C4).

5. 과제 시작 / 종료 절차

시작 시

  1. 어제의 §7 "다음 과제 thread" 를 본다 → 오늘 과제 후보 선정
  2. 해당 template 복사 → raw/daily-tasks/<track>/YYYY-MM-DD-<slug>.md
  3. frontmatter 채움 (target_date, difficulty, duration_estimate, parent_project, prerequisites)
  4. §1~§4 채움 (목표 / 스토리라인 / 환경 / 사전 지식) — 과제 시작 전 완료
  5. status_label: in-progress 로 변경

종료 시

  1. §5 단계 모두 체크
  2. §6 자동 검증 명령 모두 통과
  3. §7 결과물 + §8 회고 채움
  4. §10 Closure — status_label: done, 소요 시간 실측, promotable 후보
  5. (infra) §11 운영 회복력 anchor 채움
  6. commit / PR 푸시

6. Promotion / Ingest

  • done + actually-implemented 또는 locally-verified 등급 항목만 /ingest 대상
  • 절대 wiki/interview/ 나 wiki/portfolio/ 로 직접 이동 금지 (CLAUDE.md §15) — 반드시 wiki/concepts/ 또는 wiki/projects/ canonical 경유
  • documented-only / planned 항목은 raw 영구 보관, wiki 추출 대상 아님

7. Sources / 근거 자료

본 hub 와 두 template 의 구조 근거:

Source 정당화
raw/company-tech-blogs/skillable-hands-on-lab-structure 9-section anchor (Learning Objectives / Storyline / Environment / Exercises / Assessments / Outcomes / Sources / Closure / Reflection) 의 vendor-normative 근거. 공식 best practice 격상 금지 — company-case-study 강도.
raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode §5 단계 분할 (slightly higher than current), §6 objective 평가, §8 reflection 의 deliberate-practice 원리. personal-blog 강도 — Ericsson 연구 2차 인용이므로 "Ericsson 연구 기반" 표현 금지, "경험 기반 권고" 로만 인용.
raw/company-tech-blogs/senior-engineer-competency-mubin-shaikh 커리큘럼 "시니어 초반급 문제해결력" 목표의 외부 anchor — mid→senior 갭(trade-off articulation, system thinking, failure-mode awareness). personal-blog 강도 — 공식 best practice 격상 금지.

8. 누적 인덱스 (수동 또는 Dataview)

현재는 비어 있음. 과제가 쌓이면 트랙별로 최신 N개를 본 섹션에 손으로 적거나 Obsidian Dataview 쿼리로 자동화.

develop (최신 순)

날짜 슬러그 Phase difficulty status 검증 결과
2026-05-29 raw/daily-tasks/develop/2026-05-29-archunit-controller-domain-return-rule D-P1 W1 intermediate not-started —

infra (최신 순)

날짜 슬러그 Phase difficulty status 측정값 / 검증
2026-05-29 raw/daily-tasks/infra/2026-05-29-actuator-readiness-probe-db-disconnect-detection I-P1 W1 intermediate not-started —
Reference in New Issue View Git Blame Copy Permalink