donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
58515ab0f3c9b94ed48e9efe7a11bb52c169ce83
llm-wiki/templates/daily-task-develop-template.md
T

9.4 KiB
Raw Blame History

title, source_type, track, status, status_label, difficulty, duration_estimate, prerequisites, parent_project, parent_branch, target_date, created, tags
title source_type track status status_label difficulty duration_estimate prerequisites parent_project parent_branch target_date created tags
daily-task / develop / {{slug}} daily-task develop raw not-started intermediate 120
ca-skeleton-operational-contract YYYY-MM-DD YYYY-MM-DD
daily-task

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: <Gradle 8.x / Maven 3.9>
  • IDE 권장: <IntelliJ IDEA 2025.x>
  • 추가 라이브러리: <ArchUnit / MapStruct / RestAssured 등 — 버전 명시>

사전 셋업:

# 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/<concept-slug>]] — <왜 필요한지 한 줄>
  • [[raw/branch-notes/<related-branch>]] — <관련 결정>
  • [[raw/official-docs/<source-slug>]] — <인용할 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 작성자가 합격 명령어로 조작적 정의해야 함).

자동 검증:

# 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 (있다면):
  • 신규/변경 파일:
    • <path/to/file> — <역할 한 줄>
  • 학습한 개념 (wiki/concepts 로 ingest 후보):
    • <개념 1> — /ingest 시점에 wiki/concepts/<slug> 로 추출 가능 여부 메모
  • 다음 과제 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 → 어떤 명령으로 검증됐는지
  • 추출하지 않을 항목 (단순 학습 / 폐기):
Reference in New Issue View Git Blame Copy Permalink