8주차 과제 체크포인트

기본 과제

필수

• 반복 유형 선택
  • 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
  • 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
    • 31일에 매월을 선택한다면 -> 매월 마지막이 아닌, 31일에만 생성하세요.
    • 윤년 29일에 매년을 선택한다면 -> 29일에만 생성하세요!
• 반복 일정 표시
  • 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
    • 아이콘을 넣든 태그를 넣든 자유롭게 해보세요!
• 반복 종료
  • 반복 종료 조건을 지정할 수 있다.
  • 옵션: 특정 날짜까지, 특정 횟수만큼, 또는 종료 없음 (예제 특성상, 2025-06-30까지)
• 반복 일정 단일 수정
  • 반복일정을 수정하면 단일 일정으로 변경됩니다.
  • 반복일정 아이콘도 사라집니다.
• 반복 일정 단일 삭제
  • 반복일정을 삭제하면 해당 일정만 삭제합니다.

선택 (작업X)

- [ ] 반복 간격 설정 - 각 반복 유형에 대해 간격을 설정할 수 있다. - 예: 2일마다, 3주마다, 2개월마다 등 - [ ] 예외 날짜 처리: - 반복 일정 중 특정 날짜를 제외할 수 있다. - 반복 일정 중 특정 날짜의 일정을 수정할 수 있다. - [ ] 요일 지정 (주간 반복의 경우): - 주간 반복 시 특정 요일을 선택할 수 있다. - [ ] 월간 반복 옵션: - 매월 특정 날짜에 반복되도록 설정할 수 있다. - 매월 특정 순서의 요일에 반복되도록 설정할 수 있다. - [ ] 반복 일정 전체 수정 및 삭제 - 반복 일정의 모든 일정을 수정할 수 있다. - 반복 일정의 모든 일정을 삭제할 수 있다.

---

• 이 앱에 적합한 테스트 전략을 만들었나요?

각 팀원들의 테스트 전략은?

팀원들과 함께 전략을 쌓고 심화과제 진행했습니다!

기능 회귀 테스트

합의된 테스트 전략과 그 이유는 무엇인가요?

"회귀테스트 중심의 안정성 보장 전략"

회귀 테스트는 새로운 기능 추가나 리팩터링이 기존 기능을 깨뜨리지 않았는지 보장하는 것이 핵심 목적입니다. 단순히 "전체 테스트"가 아니라 기존 기능 유지에 초점을 맞춘 안전망 역할을 합니다.

핵심 전략

1. 회귀테스트 중심 접근

   • 새로운 기능 추가 시 기존 기능이 깨지지 않았음을 보장
   • 기능 간 상호작용 검증에 집중
   • 통합적인 관점에서의 기능 검증

2. 기존 기능 유지 보장

   • 스키마 변경과 필드 추가에 대한 대응
   • 새로운 필드나 로직 추가 시 기존 로직의 안정성 보장
   • 연관 기능들의 정상 동작 검증

3. 실제 사용자 시나리오 중심 테스트

   • 이전 기능 재테스트가 아닌 기능 간 상호작용 검증
   • 실제 사용자 플로우를 시뮬레이션하는 realistic한 테스트 구현

선택 이유

문제 상황

신규 기능 개발 진행 과정에서 기존 기능과 테스트 코드의 안정성을 보완하기 위해 회귀 테스트 도입을 검토하게 되었습니다. 그러나 팀원들 간 회귀 테스트에 대한 이해도가 상이하여 명확한 개념 정립이 필요한 상황이었습니다.

특히 회귀 테스트의 필요성에 대한 근본적인 의문이 제기되었습니다. 한 팀원이 "회귀 테스트가 새로운 기능을 붙일 때 안정성을 주는 것과 전체 테스트를 하는 것과 차이가 무엇인지", "회귀 테스트는 꼭 신규 기능 붙일 때만 의미 있는 건가요?"라는 질문을 던지면서 팀 차원의 논의가 시작되었습니다.

또한 회귀 테스트의 유형 선택에 대한 고민도 있었습니다. 시각적 회귀 테스트(Storybook의 크로마틱을 활용한 UI 기준 테스트)를 진행할 것인지, 아니면 기능 회귀 테스트(유닛테스트와 함께 사용하는 방식)를 진행할 것인지에 대한 결정이 필요했습니다. UI 픽셀 기반 회귀 테스트 전략의 필요성에 대해서는 팀 내에서 크게 필요하다는 의견이 없어, 기능 회귀 테스트 중심으로 논의를 진행하기로 했습니다.

주요 논의 과정

1단계: 회귀 테스트의 본질적 의미 탐구 앞서 제기된 질문에 대한 답변으로, 회귀 테스트는 새 기능이 아니라 기존 기능이 깨지지 않았는지 확인하는 것에 목적이 있다는 점이 강조되었습니다. 기능을 추가할 때 흔히 발생하는 문제는 이미 수정한 기능이 롤백되거나 다른 부분에 사이드이펙트를 주는 것인데, 이를 방지하는 것이 회귀 테스트의 핵심 역할이라고 정의했습니다.

"기능 A, B를 개발한 후 다시 테스트하는 것이 회귀 테스트인가?"라는 근본적인 질문부터 시작하여, 단순한 기능 재테스트와 회귀 테스트의 차이점을 명확히 구분하고자 했습니다.

이러한 논의 과정에서 회귀 테스트와 전체 테스트 간의 명확한 차이점을 정리했습니다:

구분	회귀테스트 (Regression Test)	전체테스트 (Full Test Suite)
목적	기존 기능이 여전히 잘 작동하는지 확인	애플리케이션의 모든 기능을 검증
실행 시점	코드 변경 후	정기적 또는 릴리스 전
테스트 범위	변경 영향을 받을 수 있는 기존 기능들	모든 기능 (신규 + 기존)
실행 시간	⚡ 빠름 (일부 테스트만)	⏱️ 오래 걸림 (모든 테스트)
주요 관심사	기존 기능의 안정성	애플리케이션의 완전성

이러한 비교 분석을 통해 회귀 테스트가 단순히 "전체 테스트"가 아니라 안정성을 보장하는 안전망 역할을 한다는 점을 명확히 했습니다.

2단계: 구체적 목적과 적용 예시 도출 스키마 변경이나 새로운 필드 추가 시에도 기존 기능이 그대로 유지되는지 확인하는 것이 회귀 테스트의 주요 목적이라고 정의했습니다. 구체적인 테스트 시나리오를 통해 개념을 명확히 했습니다:

// 예시
describe('기존 반복 계산 로직이 excludeDates 추가 후에도 동일하게 동작한다');
describe('weekday 기능 추가 이후에도 기본 주간/월간/연간 로직은 동일하게 동작한다');

3단계: 팀 차원의 핵심 가치 합의 논의를 통해 도출된 회귀 테스트의 핵심 가치는 다음과 같습니다:

• 기존 기능의 유지 보장: 새로운 기능 추가 시 기존 기능이 정상 동작하는지 확인
• 연관 기능 검증: 여러 기능이 동작할 때 기존 동작 중 연관된 기능들의 정상 동작 확인
• 안전망 역할: 새 기능 추가 시 사이드이펙트 방지 및 소프트웨어 전체 안정성 개선

최종 수립 전략

회귀 테스트 유형 결정 시각적 회귀 테스트보다는 기능 회귀 테스트에 집중하기로 결정했습니다. 이는 현재 프로젝트의 신규 기능 개발 특성상 기능적 안정성이 더 중요하다고 판단했기 때문입니다.

회귀 테스트 작성 방향 단순한 기능 재테스트가 아닌 기능 간 상호작용 검증에 중점을 두기로 했습니다. 새로운 필드나 로직 추가 시 기존 로직의 안정성을 보장하고, 통합적인 관점에서 기능을 검증하는 것을 목표로 설정했습니다.

실무적 고려사항 "단일 일정 생성 기능 검증"과 같이 이미 존재하는 테스트 코드와의 중복 문제도 함께 검토하여, 효율적인 테스트 코드 작성 방안을 모색했습니다.

---

추가로 작성된 테스트 코드는 어떤 것들이 있나요?

파일 위치 : src/__tests__/회귀테스트.spec.tsx 여진석 PR

'회귀테스트: 반복일정과 기존 단일일정 충돌 검사'

1. 반복일정 생성 시 기존 단일일정과 충돌하는 경우 경고가 표시된다

   • 목적: 반복일정 기능 추가 후 기존 충돌 검사 로직이 정상 동작하는지 검증
   • 검증: '일정 겹침 경고' 메시지와 구체적인 충돌 정보 표시 확인

2. 반복일정의 특정 날짜가 기존 일정과 충돌하지 않는 경우 정상 생성된다

   • 목적: 충돌하지 않는 반복일정이 정상적으로 생성되는지 검증
   • 검증: 충돌 경고 없이 정상 생성 및 성공 메시지 확인

'회귀테스트: 검색 기능

1. 반복일정이 검색 기능에 정상적으로 포함된다

   • 목적: 반복일정과 단일일정이 검색 기능에서 올바르게 동작하는지 검증
   • 검증: 검색 조건에 맞는 반복일정들이 모두 표시되는지 확인

2. 반복일정이 있는 상태에서 검색 결과가 없으면 적절한 메시지를 표시한다

   • 목적: 반복일정 환경에서 검색 결과가 없을 때의 UI 동작 검증
   • 검증: "검색 결과가 없습니다." 메시지 표시 확인

'회귀테스트: 알림 기능

1. 반복일정에 대한 알림이 각 일정마다 정상 동작한다
   • 목적: 반복일정의 각 인스턴스별로 알림 기능이 정상 동작하는지 검증
   • 검증: 개별 반복일정에 대한 정확한 알림 메시지 표시 확인

---

과제 셀프회고

기술적 성장

면접 준비로 인해 Full AI 바이브코딩을 진행해본 주차였습니다. TDD의 개념을 Claude Code에 적용하고 코드를 하나씩 검수하면서 실무 관리자의 입장을 이해할 수 있었습니다. 무엇보다 중요한건, 내가 얼마나 테스트 코드를 이해하고 있으며 Claude Code가 만들어준 코드를 얼만큼 증빙하고 이해할 수 있는지가 핵심이었던 것 같습니다.

이번 과제를 통해 TDD 방법론에 대한 이해가 크게 향상되었습니다. 특히 RED 단계에서 단순한 import 오류가 아닌 논리적으로 잘못된 구현으로 테스트를 실패시키는 것의 중요성을 깨달았습니다. Claude Code의 thinking 모드로 RED/GREEN/리팩토링 단계를 거쳐 진행되는 프로세스를 확인하고 적용시키면서 TDD의 본질적인 목적을 명확히 이해할 수 있었습니다.

복잡한 날짜 로직 구현에서 많은 도전을 경험했습니다. 윤년의 2월 29일 처리나 31일 매월 반복 시 해당 일이 없는 달을 건너뛰는 로직 등은 예상보다 복잡했지만, 작은 단위로 나누어 차근차근 해결해 나가는 과정이 매우 의미 있었습니다.

코드 품질

가장 만족스러웠던 구현은 isValidRecurrenceDate() 함수를 통한 날짜 유효성 검증 로직이었습니다. 복잡한 날짜 계산을 안전하게 처리할 수 있었고, 함수형 프로그래밍 스타일로 작성한 isNotTargetEvent 헬퍼 함수도 가독성과 재사용성 측면에서 좋은 결과를 보여주었습니다.

다만 아쉬운 부분이 있습니다. 반복 종료일 설정에서 캘린더 아이콘 클릭 방식을 완전히 구현하지 못했고, medium.integration.spec.tsx에 반복 유형 선택 확인 테스트도 추가해야 합니다. 또한 현재는 unit 테스트 중심으로만 구현했는데, E2E 테스트의 필요성에 대해서도 더 고민해봐야 할 것 같습니다.

AI와 함께 코딩하면서 가장 고민했던 부분은 테스트 코드 생성의 접근 방식이었습니다. "모든 요구사항을 한 번에 구현 후 테스트로 검증"보다는 "단계별 요구사항 구현 후 단계별로 테스트로 검증" 방식을 선택했는데, 이 결정이 테스트 코드 작성 과정을 더욱 안정적으로 만들어 주었습니다. 매 단계마다 pnpm test를 실행하여 기존 기능에 사이드이펙트가 없는지 확인하고, AI의 코드를 절대 신뢰할 수 없는(?) 습관도 정착되었습니다.

학습 효과 분석

가장 큰 배움은 TDD의 RED-GREEN-REFACTOR 사이클에서 각 단계의 명확한 목적을 이해하게 되었습니다. 단순히 테스트를 작성하고 통과시키는 것이 아니라, 각 단계가 왜 필요한지, 어떤 방식으로 진행해야 하는지를 고민하며 진행하였습니다. 또한 팀원들과 회귀 테스트의 개념과 실무 활용 방안에 대해 토론하면서, 테스트가 단순한 검증 도구가 아닌 개발 전략의 핵심임을 깨달았습니다.

앞으로 더 학습이 필요한 영역들도 명확해졌습니다. React Testing Library를 활용한 더 정교한 통합 테스트 작성 방법을 익히고 싶고, 캘린더 컴포넌트 같은 복잡한 UI 요소를 어떻게 효과적으로 테스트할 수 있을지도 고민해봐야겠습니다. E2E 테스트와 unit 테스트 사이의 균형잡힌 전략을 수립하는 것도 필요합니다. 또한, E2E/unit 테스트에 대한 이해는 명확하나 통합테스트에 대한 이해도가 낮은 것 같아 이 부분도 추가 공부가 필요해보입니다.

실무 적용 가능성은 매우 높다고 생각합니다. TDD를 통한 안정적인 기능 개발 프로세스는 어떤 프로젝트에서든 도움이 될 것이고, AI 도구를 활용한 코드 리뷰 및 품질 관리 방식도 실제 팀 개발에서 충분히 활용할 수 있을 것이라 생각합니다. 오프 코치님이 QnA시간에 공유해주신 BMAD를 통한 agent 방식도 적용해보려고 합니다. 특히 회귀 테스트 중심의 개발 문화는 기존 기능을 보호하면서도 새로운 기능을 안전하게 추가할 수 있는 좋은 방법론이라고 확신합니다.

과제 피드백

과제를 진행하면서 몇 가지 애매했던 부분들이 있었습니다. 반복 종료일 설정에서 처음에는 input 방식으로 시도했지만 repeatEndDate에 정확한 값이 들어가지 않아서 캘린더 아이콘 클릭 방식으로 전환해야 했는데, 어떤 방식으로 진행하는게 더 좋을지 고민하는 시간이 길었습니다. 이에 대해 발제 자료에 라이브러리를 사용할 때의 예시 코드를 들어주거나 했으면 저처럼 테스트 코드를 처음 접하는 수강생들도 이해하기 쉬웠을 것 같다는 생각이 듭니다!

하지만 전반적으로 과제의 구성은 매우 좋았습니다. 체크박스 형태로 요구사항이 명확하게 제시되어 있어서 진행 상황을 단계별로 진행할 수 있었고, TDD 방법론을 강제하여 테스트 주도 개발을 자연스럽게 경험할 수 있었습니다. 특히 팀원과의 개발 방식 논의를 통해 협업 경험을 쌓을 수 있었던 심화 가제와, Claude Code 같은 AI 도구를 활용하여 현대적인 개발 프로세스를 체험할 수 있었던 점이 가장 큰 수확이었습니다. 회귀 테스트 전략 수립을 위해 논의한 내용들이 실무에도 충분히 적용 될 수 있는 부분이라 생각되었습니다. 배움에서 끝낼 것이 아닌 실무 적용까지 고려할 수 있었던 주차였던 것 같아 현업에서 테스트 코드가 없다면 혼자서 주도적으로 진행할 수 있을거란 자신감이 생겼습니다.

리뷰 받고 싶은 내용

• RED 테스트 코드 이해도 이번 과제에서 TDD 방식을 적용하면서 RED-GREEN-REFACTOR 사이클을 거쳐 개발했는데, 특히 RED 단계에서 "논리적으로 잘못된 구현"으로 테스트를 실패시키는 방법이 올바른 TDD 접근인지 궁금합니다. 예를 들어 unit테스트 코드 작성시 실제 구현하여 테스트가 실패하도록 한 것이 적절한 RED 단계 구현이었는지 궁금합니다.

• 요청사항의 기능 테스트 코드 작업 방식에 대해 팀원과 개발 방식을 논의할 때 기본 과제 테스트 코드 작성시 "모든 요구사항을 한 번에 구현 후 검증" vs "단계별 요구사항 구현" 중에서 후자를 선택했습니다. 그 이유는 AI에게 맡기다보니 단계적으로 컨텍스트를 나눠서 작업하려고 했기 때문입니다. 하지만 실무에서는 팀원들과 작업할 때 어떤 접근 방식이 더 효과적인지, 그리고 프로젝트 규모나 팀 구성에 따라 어떤 기준으로 진행해야할지는 고민이 됩니다.

• 함수 분리 기준과 이름 복잡한 날짜 로직(윤년 처리, 31일 매월 반복 등)을 구현하면서 isValidRecurrenceDate()와 getNextRecurrenceDate() 함수로 나누어 작업했는데, 현재의 함수 분리 기준과 명명이 적절할까요? 초기에는 repeat으로 작업하였으나 AI추천해준 명명으로 변경하였습니다. 전 챕터의 클린코드 기준을 적용해서 좀 더 명확한 함수명으로 바꾸었어야했을까요? 또한 날짜 처리 로직에서 더 안전하고 가독성 좋은 구현 방법이 있는지도 궁금합니다.

// 배열 형식으로 뽑아서 사용하다보니 가독성 저하
expect(recurringEvents[0].date).toBe('2024-01-31');
expect(recurringEvents[1].date).toBe('2024-03-31');
expect(recurringEvents[2].date).toBe('2024-05-31');

• 테스트의 경계 현재 unit 테스트 위주로 구현했는데, 캘린더 애플리케이션 특성상 UI 인터랙션이 중요한 부분들(반복 유형 선택, 캘린더 아이콘 클릭 등)에 대해서는 어느 정도까지 통합 테스트나 E2E 테스트를 추가하는 것이 적절할까요? 작은 기능에 지금도 충분히 테스트가 많다고 생각하는데 unit, 통합테스트, E2E까지 추가하여 비대해지는 것이 당연한 것인지, 그만큼 시간을 들여서 작성해야 테스트로 충분한 검증을 할 수 있는 것인지 궁금합니다.