d02/00. learning-guide.md

2일차 학습 가이드

오늘의 큰 흐름

2일차는 기준선 확인 -> Brownfield 기능 추가 -> 버그 수정 -> merge -> 변경 대응 순서로 진행합니다.

이 순서를 지키는 이유는 단순합니다.

• 기준선이 흔들리면 오늘 생긴 문제와 원래 있던 문제를 구분할 수 없습니다.
• 기존 코드가 있는 상태에서는 새 기능과 버그 수정의 성격을 먼저 나눠야 합니다.
• 구현이 끝난 뒤에도 merge 전 검토와 변경 요청 대응까지 해야 실제 업무 흐름과 닮아집니다.

교시별 핵심 목표

1교시: Brownfield와 기준선 이해

• Brownfield가 무엇인지 이해합니다.
• baseline-v1.0 태그가 왜 중요한지 이해합니다.
• 참고 문서: 01_brownfield-basics.md

2교시: 기준선 상태 점검

• main 브랜치와 태그, 테스트, 실행 상태를 확인합니다.
• 1일차 작업 이력을 짧게 복기합니다.
• 참고 문서: 02_baseline-check-workshop.md

3교시: 새 기능용 Spec 작성

• 기존 spec을 수정하지 않고 새 spec 폴더를 만드는 이유를 이해합니다.
• issues.md를 먼저 만들고 /speckit.specify를 실행합니다.
• 참고 문서: 03_feature-spec-workshop.md

4교시: Plan / Tasks / Analyze / Implement

• 기존 코드와 어떻게 통합할지를 plan에 적습니다.
• tasks와 analyze를 통해 구현 전 마지막 검증을 합니다.
• 참고 문서: 04_plan-analyze-implement-workshop.md

5교시: 버그 수정 TDD

• 버그 수정은 새 기능과 다른 흐름으로 처리해야 함을 이해합니다.
• fix/ 브랜치를 직접 만들고 재현 테스트부터 작성합니다.
• 참고 문서: 05_bugfix-workshop.md

6교시: Merge 전 검토와 병합

• 어떤 브랜치가 먼저 병합되어야 하는지 판단합니다.
• GitHub 웹 화면이 아니라 로컬 저장소에서 git merge --no-ff로 병합합니다.
• merge 전 체크리스트를 사용해 브랜치 준비 상태를 검토합니다.
• 참고 문서: 06_merge-review-workshop.md

7교시: 요구사항 변경 대응

• 변경이 버그인지 새 요구사항인지 먼저 판정합니다.
• 요구사항 변경이면 spec부터 다시 시작하는 cascade를 이해합니다.
• 참고 문서: 07_change-management-workshop.md

마무리: 흐름 복기와 현업 적용

• 2일간의 SDD 흐름을 설명해 봅니다.
• 다음 주 바로 실행할 첫 행동을 적어 봅니다.
• 참고 문서: 08_recap-and-retrospective.md

오늘 반드시 기억할 개념

Brownfield

이미 동작하는 기존 코드가 있는 상태에서 변경하는 작업입니다.

Baseline

이후 변경의 기준이 되는 안정 상태입니다. 보통 태그로 고정합니다.

Feature Branch

새 기능을 기존 기준선과 분리해서 구현하는 브랜치입니다.

Fix Branch

버그를 빠르게, 좁은 범위로 수정하기 위한 브랜치입니다.

Cascade 재실행

요구사항이 바뀌었을 때 spec, plan, tasks 같은 하위 산출물을 다시 맞추는 흐름입니다.

학습 팁

• 기존 코드를 건드릴 때는 항상 무엇이 원래 동작했는가를 먼저 확인합니다.
• 기능 추가와 버그 수정은 입력 문서와 브랜치 전략이 다르다는 점을 계속 의식합니다.
• 병합은 로컬 main 브랜치에서 먼저 끝내고, 그 다음 원격으로 push합니다.
• AI가 만든 변경도 merge 전에 사람이 검토하고 설명할 수 있어야 합니다.