--- title: daily-task / develop / {{slug}} source_type: daily-task track: develop status: raw status_label: not-started difficulty: intermediate duration_estimate: 120 prerequisites: [] parent_project: ca-skeleton-operational-contract parent_branch: target_date: YYYY-MM-DD created: YYYY-MM-DD tags: [daily-task] # 트랙 구분은 폴더 경로 + frontmatter `track:` 가 SSOT. tag 에 develop/infra 중복 금지. # 추가 tag 는 도메인별 (예: `validation`, `testing`, `archunit`) 1~2개 권장. --- # daily-task / develop / {{slug}} > Layer: `raw/daily-tasks/develop/` — **개발 트랙 일일 실습 과제**. 사수가 신입에게 주는 형식의 자율 학습 과제. 매일 아침 1개 수행. > `status_label`: `not-started` | `in-progress` | `done` | `abandoned` > `difficulty`: `starter` (오늘이 처음) | `intermediate` (기본 흐름 익숙) | `advanced` (실패 모드 / 트레이드오프 탐구) > `duration_estimate`: 분 단위. 기본 120분 (Pomodoro 4-5개). 단순 일정이 아니라 *완료 신호가 뜰 때까지* 의 자기 추정치. > > **체계 근거**: 본 template 구조는 두 raw 자료로 정당화된다 — 9-section anchor 는 vendor-normative 가이드 (`[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]`), 단계 분할·자기평가·회고 원리는 deliberate-practice 개인 블로그 (`[[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]]`) 기반. 두 자료 모두 *공식 best practice 가 아니다* — 본 template 도 best practice 가 아닌 **운영 가능한 학습 구조**로만 인용할 것. ## 부모 (필수) - **Parent project**: `[[raw/project-notes/ca-skeleton-operational-contract]]` (또는 해당하는 다른 project-note) - **연관 branch** (선택, 있을 때만): `[[raw/branch-notes/{{branch-slug}}]]` > 본 과제가 어느 작업 묶음에 속하는지 명시. parent 없는 과제는 금지 (raw 영구 보관 정책 + ingest 시 추적 불가). ## 1. 학습 목표 > 3-5개 측정 가능 목표. "이 과제 끝났을 때 다음을 *할 수 있어야* 한다" 형식. > 근거: `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]#SKILL-LAB-C1` — Learning Objectives 는 hands-on lab 의 7 functional spec 중 첫 anchor. - [ ] L1: <할 수 있어야 하는 것 — 동사로 시작 (예: "ArchUnit rule 로 controller→domain 직접 의존을 빌드 실패로 검출할 수 있다")> - [ ] L2: <...> - [ ] L3: <...> ## 2. 스토리라인 > *왜* 이 과제가 필요한가. 실무 시나리오 1-2 문단. 단순한 코드 따라치기를 막는 anchor. > 근거: `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]#SKILL-LAB-C2` — storyline 이 없으면 lab 은 "clicking things" 가 되고 학습자는 skill 향상 없이 끝난다. (예시: "ca-tmpl 의 `feature-boundary-validation-mapping-contract` branch D7 결정 — controller 가 domain object 를 직접 반환하지 않는다 — 을 ArchUnit 으로 강제하려 한다. 다음 신입이 그 결정을 모르고 controller method 의 return type 에 domain entity 를 넣어도 build 가 통과되면 boundary contract 가 사실상 무력화된다. 오늘은 그 단 한 가지 시나리오만 막는 rule 을 작성하고 의도적인 위반으로 빌드를 깬다.") ## 3. 환경 > 사용 도구·버전·사전 셋업. > 근거: `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]#SKILL-LAB-C1` — Prospective environment + Technologies used. **개발 도구**: - Java: <버전, e.g., 21 LTS> - Build: - IDE 권장: - 추가 라이브러리: **사전 셋업**: ```bash # repo clone / branch 전환 cd ~/workspace/ca-tmpl git checkout -b daily-task/develop/{{slug}} # 빌드 확인 ./gradlew clean build ``` **예상 디렉토리 변경**: - 추가/수정될 파일 경로 미리 명시 (예: `adapter-web/src/test/java/.../CleanArchitectureTest.java`) ## 4. 사전 지식 > 알아야 할 개념·결정. 모르면 wikilink 먼저 정독한 뒤 진행. - `[[wiki/concepts/]]` — <왜 필요한지 한 줄> - `[[raw/branch-notes/]]` — <관련 결정> - `[[raw/official-docs/]]` — <인용할 claim> ## 5. 단계별 과제 > Pomodoro (~25분) 단위로 분할. 각 단계는 *현재 능력보다 약간 높은* 도전이어야 한다 — 너무 쉬우면 학습 0, 너무 어려우면 좌절. > 근거: `[[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]]#DP-RGC-C2` (slightly higher than current ability — Ericsson 연구의 *개인 블로그 2차 인용*. 공식 best practice 표현 금지), `#DP-RGC-C5` (25-min Pomodoro 는 권고 시작점일 뿐 규범 아님). ### Step 1: <단계 제목> (~25min) - **무엇을 (What)**: <구현해야 할 단위. 단일 commit 이 떠올라야 함> - **어떻게 (How — hint, *spoiler 아님*)**: <어떤 클래스를 만져야 하는지 / 어떤 패턴을 찾아야 하는지. 코드 정답 X> - **합격 신호 (Done when)**: <이 단계가 끝났음을 어떻게 알 수 있는가 — 명령어 / 로그 / 빨강↔초록 전환 / test name> ### Step 2: <단계 제목> (~25min) - **What**: - **How (hint)**: - **Done when**: ### Step 3: <단계 제목> (~25min) - **What**: - **How (hint)**: - **Done when**: ### 실패 모드 탐구> (~25min) - **What**: - **How (hint)**: - **Done when**: > *단계 갯수는 difficulty 에 따라*: starter=2, intermediate=3-4, advanced=4-5. 총 시간은 frontmatter `duration_estimate` 와 일치. ## 6. 검증 > 객관적 합격 기준. 단계 통과 = 측정 가능한 contract. *느낌* 으로 끝내지 않는다. > 근거: `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]#SKILL-LAB-C4` (assessment = immediate feedback for success / additional help), `[[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]]#DP-RGC-C3` (objective standard 로 평가 — 단 "objective standard" 의 구체 정의는 본 template 작성자가 합격 명령어로 조작적 정의해야 함). **자동 검증**: ```bash # 1) 빌드 + 단위 테스트 ./gradlew clean build test # 합격 기준: exit code 0 # 2) ArchUnit / contract test (해당 시) ./gradlew :adapter-web:test --tests '*CleanArchitectureTest' # 합격 기준: PASS 로그 # 3) 의도적 위반 빌드 깨기 (해당 시 — rule 검증) # 임시로 위반 코드 추가 → 빌드 → 실패 확인 → 위반 코드 제거 ``` **수동 self-check**: - [ ] 위 자동 명령 모두 exit 0 - [ ] 의도적 위반 시 *정확히* 의도된 rule 이름이 실패 메시지에 포함됨 - [ ] L1~L3 학습 목표가 실제로 *할 수 있다* 상태인지 (1줄로 설명 가능) - [ ] commit 메시지가 "왜" 를 답함 ("Add X" 가 아니라 "Enforce X to prevent Y") ## 7. 결과물 > 과제가 끝났을 때 남는 산출물. 휘발성 학습이 아니라 *재사용 가능한 흔적* 을 남긴다. > 근거: `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]#SKILL-LAB-C1` — Outcomes 는 7-component spec 의 마지막 anchor. - **commit / PR**: - 브랜치: `daily-task/develop/{{slug}}` - commits: <해시 + 1줄 메시지> - PR URL (있다면): - **신규/변경 파일**: - `` — <역할 한 줄> - **학습한 개념** (wiki/concepts 로 ingest 후보): - <개념 1> — `/ingest` 시점에 `wiki/concepts/` 로 추출 가능 여부 메모 - **다음 과제 thread** (실수·궁금증·심화 주제): - <오늘 막혔던 지점에서 자연스럽게 파생되는 과제 후보 — 내일 또는 다음 주 daily-task 시드> ## 8. 회고 > 과제 끝난 직후 5분 회고. 빈칸으로 두지 말 것. 빈 회고 = 학습 손실. > 근거: `[[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]]#DP-RGC-C4` — "After you finish each problem, ask yourself if you can improve any aspect of your problem-solving process based on your experience with that problem." - **막혔던 곳** (몇 분 / 어디서): - **예상과 다른 점** (가정이 깨진 부분): - **다음 반복에서 개선할 점** (방법론 / 도구 / 정보 수집 순서): - **부수 효과로 발견한 것** (의도 외 학습): - **이 과제의 난이도가 적정했는가** (`너무 쉬움` / `적정` / `너무 어려움` — frontmatter `difficulty` 조정 신호): ## 9. 출처 > 본 과제의 구조 근거 + 도메인 근거. | Source | 정당화 영역 | |---|---| | `[[raw/company-tech-blogs/skillable-hands-on-lab-structure]]` | template 9-section 구조 자체 (§1, §2, §3, §6, §7) | | `[[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]]` | §5 단계 분할 + §6 objective 평가 + §8 reflection 원리 | | `[[raw/official-docs/<...>]]` | 도메인 결정 근거 (Spring Boot / Java spec / Jackson 등) | | `[[raw/branch-notes/<...>]]` | 본 과제가 검증하려는 branch 결정 | ## 10. 완료 후 정리 > done 으로 바뀌는 순간 채움. `/ingest` 가 이 섹션을 기준으로 wiki 영역으로 promotable 항목 추출. - **최종 status_label**: `done` | `abandoned` - **소요 시간 실측**: <분> (vs frontmatter `duration_estimate` <분>) — 차이 분석은 §8 회고에 - **promotable 후보**: - `actually-implemented` → 어느 branch-note 의 어느 결정과 연결되는지 - `locally-verified` → 어떤 명령으로 검증됐는지 - **추출하지 않을 항목** (단순 학습 / 폐기):