8주차 과제 체크포인트
기본 과제
필수
- 반복 유형 선택
- 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
- 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
- 31일에 매월을 선택한다면 -> 매월 마지막이 아닌, 31일에만 생성하세요.
- 윤년 29일에 매년을 선택한다면 -> 29일에만 생성하세요!
- 반복 일정 표시
- 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
- 아이콘을 넣든 태그를 넣든 자유롭게 해보세요!
- 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
- 반복 종료
- 반복 종료 조건을 지정할 수 있다.
- 옵션: 특정 날짜까지, 특정 횟수만큼, 또는 종료 없음 (예제 특성상, 2025-06-30까지)
- 반복 일정 단일 수정
- 반복일정을 수정하면 단일 일정으로 변경됩니다.
- 반복일정 아이콘도 사라집니다.
- 반복 일정 단일 삭제
- 반복일정을 삭제하면 해당 일정만 삭제합니다.
선택
- 반복 간격 설정
- 각 반복 유형에 대해 간격을 설정할 수 있다.
- 예: 2일마다, 3주마다, 2개월마다 등
- 예외 날짜 처리:
- 반복 일정 중 특정 날짜를 제외할 수 있다.
- 반복 일정 중 특정 날짜의 일정을 수정할 수 있다.
- 요일 지정 (주간 반복의 경우):
- 주간 반복 시 특정 요일을 선택할 수 있다.
- 월간 반복 옵션:
- 매월 특정 날짜에 반복되도록 설정할 수 있다.
- 매월 특정 순서의 요일에 반복되도록 설정할 수 있다.
- 반복 일정 전체 수정 및 삭제
- 반복 일정의 모든 일정을 수정할 수 있다.
- 반복 일정의 모든 일정을 삭제할 수 있다.
심화 과제
- 이 앱에 적합한 테스트 전략을 만들었나요?
- 유닛, 통합테스트는 각자 구현했습니다.(필요한 범위내에서 회귀 테스트 진행)
- E2E는 유열님과 페어코딩 진행했습니다.
과제 셀프회고
기술적 성장
BMAD Method 적용 경험 이번엔 100% AI를 활용해서 과제를 진행해보았다. 요구사항을 Task 단위로 쪼개고, Test List를 먼저 작성한 뒤 TDD 사이클을 돌리는 과정을 실제로 적용해보았다. Ai agent를 활용한 새로운 개발 패러다임을 경험해봤고 ai를 활용할때 태스크를 작은 단위로 나누는 것이 중요하다는걸 깨달았다.
켄트 백 페르소나 활용
오프 코치님께서 켄트백 페르소나를 만들어서 활용해보라고 했는데 실제로 퍼플렉시티와 GPT를 활용해서 켄트백의 철학을 조사했고 그걸 기반으로 BMAD 에이전트를 만들었다. 일단 기본적으로는 Red → Green → Refactor를 끝내는 원칙을 적용하려고 했고, 이를 통해 테스트를 더 세분화하는 방식을 경험했다. 다만 지나치게 엄격하게 적용하려다 오히려 코드 품질이 떨어지는 순간도 있었다.
- 테스트 주도 사고 확립 Test List 기반으로 어떤 동작을 먼저 검증할지 명확히 정의하면서 “테스트를 실패하게 먼저 작성한다”는 TDD 핵심 철학을 실제로 체득했다. 하지만 과연 프론트에서 어떻게 활용할 지는 아직 어렵다.
학습 효과 분석
- 테스트를 작은 단위로 쪼개야만 빠른 사이클을 유지할 수 있다는 점, 그리고 테스트가 있을 때만 안심하고 리팩토링할 수 있다는 점을 체감했다. 확실히 테스트 코드가 있으니까 리팩토링을 과감하게 할 수 있는점이 좋았다.
- 통합 테스트와 E2E가 상대적으로 부족했으므로, 다양한 수준의 테스트를 더 균형 있게 다루는 연습이 필요하다. 어떨때는 유닛으로 할지 어떨때는 통합할지 어떨때는 E2E를 할지 아직 감이 안잡히지만 그래도 이번 심화과제를 하면서 팀원들끼리 토론해보며 어떤식으로 해야할 지는 감을 익혔다.
- BMAD를 100% 잘 활용하는 것은 어려웠지만, Test List 관리, 체크리스트 기반 리팩토링, 작은 단위 TDD 사이클은 실무에도 충분히 적용 가능할 것 같다. TDD뿐만 아니라 실제 프로덕트 개발에서도 유용할 것 같다.
과제 피드백
BMAD를 통해 “문서 → Task → Test → 코드”로 이어지는 명확한 흐름을 경험할 수 있었고, AI 에이전트를 활용해 놓칠 수 있는 케이스를 보완할 수 있었다. 아쉬운점은.. BMAD를 끝까지 적용하기는 어려웠다. 중간 중간에 채팅 컨텍스트가 끊기는 바람에 이전 맥락을 가져오려면 계속해서 문서화를 하거나 새로 에이전트들을 호출했어야했다. 또한 AI 에이전트 간 협업이 생각보다 복잡했다.
리뷰 받고 싶은 내용
Q1. 실제로도 현업 프로젝트에서 red -> green -> refactor위주로 TDD를 진행하는것이 있다면 어떤것들이 있을까요?
과제 피드백
수고하셨습니다 창준님!
Q1. 실제로도 현업 프로젝트에서 red -> green -> refactor위주로 TDD를 진행하는것이 있다면 어떤것들이 있을까요?
A. 인풋과 아웃풋이 데이터인 모듈은 TDD로 충분히 적용할 수 있을 것 같아요~
예를들어 UI에 직접적으로 사용되진 않지만 UI에 필요한 데이터 관련 코드나 구조적인 코드들일것 같아요.
비니지스 로직을 담는 모듈일 수도 있고요~
red-green-refactor 자체에 너무 매몰될 필요는 없을 것 같습니다. 저도 그때그때마다 달라요 테스트부터 작성할대 있고 아닐때도 많아요!