8주차 과제 체크포인트

기본 과제

필수

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

선택

• 반복 간격 설정
  • 각 반복 유형에 대해 간격을 설정할 수 있다.
  • 예: 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. 반복일정에 대한 알림이 각 일정마다 정상 동작한다
   • 목적: 반복일정의 각 인스턴스별로 알림 기능이 정상 동작하는지 검증
   • 검증: 개별 반복일정에 대한 정확한 알림 메시지 표시 확인

과제 셀프회고

기술적

Agent 만들기

이번에는 Kent beck Agent를 구성하여 코드는 직접 한줄도 안짜고 테스트코드 작성을 계속 시켜보고 싶었다.

어떻게 Agent를 만들어줄까 고민하다가 지금까지 bmad를 사용해서 과제를 계속 진행해봤었는데, bamd role의 구성처럼 Agent를 만들어주면 좋을 것 같다는 생각을 했다.

bamd 구조 분석부터 agent 작성, TDD로 개발까지 전부 시킬생각에 신이났다.

일단 핵심은 context를 잃지 않기 위해 중간단계를 계속 md파일로 생성하여 연속성을 이어가고자 했다.

Agent 생성 과정

1. bmad qa agent 구조 분석 md 파일 생성
2. 퍼플렉시티로 kent beck 프롬프트.md 구성
3. kent beck 프롬프트 md파일과 bmad qa agent 구조 분석 md 파일기반으로 kent beck agent 설계 md 파일 생성
4. 설계 md 파일에 테스트 강화 명령어, red, green 단계시에 각자 역할만 하도록 제약사항 추가
5. 설계 md파일 기반으로 agent 생성

지금까지 사용했던 노하우들이 쌓여서 그런가 너무 생각한거처럼 잘 만들어졌다. 뿌듯...

TDD 시도 일단 무지성으로 App.tsx context와 tdd start 명령을 했지만 올바르게 작업이 되지 않았다. 테스트 코드도 이상하고, app.tsx 없는 label을 가져오는 등 약간 멍청하게 작업했다.

그래서 일단 app.tsx를 분석해놓은 md파일이 필요하지 않을까 라는 생각으로 다시 md파일들을 분리하면서 작업을 진행했다.

1. bmad analyst에게 현재 프로젝트 분석 및 기본기능 구현 내용 정리 md 파일 생성
2. 분석된 md파일 기반으로 kent beck agent에게 test 코드의 흐름과 app.tsx에 구현된 내용을 분석해서 정리 및 개선하여 md파일로 생성
3. app.tsx와 tdd 관점으로 분석한 md파일을 기반으로 전체 앱 테스트코드 강화 실행
4. app.tsx와 tdd 관점으로 분석한 md파일과 추가요구사항.md 파일을 이용하여 TDD 개발 어떻게할지 설계하여 md 파일 생성
5. 지금까지 작성된 md파일들을 활용하여 요구사항을 하나씩 kent beck tdd start 명령어 실행
6. 작성 완료된 테스트 코드들을 간단한것 부터 하나씩 작업 진행

RED GREEN Refactor 단계를 명확히 구분해서 침범하지 않고 잘 작업을 해주었다. 정말 상상이상으로 너무 잘해주었다.

특히 테스트코드를 먼저 작성하고 기능을 구현하는 흐름이다보니까 기능구현을 너무 빠르고 원하는흐름대로 잘 생성해주었다.

느낀점 AI에게 Agent를 분석시키고 분석한 내용을 이용해서 또 AI가 Agent를 생성하고 생성된 Agent로 또 AI가 코드를 짠다. 솔직히 잘 안될줄 알았는데, 너무너무너무 잘돼서 놀라웠다. 이제는 context연결만 잘 지어주면 AI가 원하는 결과물을 아주 잘 내주고 있는 것 같다.

https://platform.openai.com/chat/edit?models=gpt-5&optimize=true Gpt는 Gpt Prompt를 만드는 에이전트를 만들었고, 나는 bamd 스타일의 에이전트를 만드는 에이전트를 만들었다. AI가 AI를 만들어내는 이 흐름이 되게 어색하고 낯설다.

미래에 나는 어떤 개발을 하고 있을지 더 상상이 안되는 것 같다..

TDD

TDD라는 방법론에 대해서는 잘 알고 있었지만, 어떤 장단점이 있을지 깊게 생각해본적은 없었다. 링크드인이나 블로그에서 흔하게 접했었던 내용은 TDD가 오히려 생산성을 떨어트린다! 프론트엔드에서는 사용하기 어렵다. 였다.

이번에 kent beck agent를 구성해서 RED, GREEN, REFACTOR 단계의 흐름대로 작업을 진행하였는데, 바이브 코딩할 때는 TDD는 정말 완벽한 방법론이었다.

RED단계의 테스트코드만 명확하게 짤 수 있도록 명령해주면 GREEN 단계를 알아서 너무 잘 만들어주었다. refactor 단계도 완벽히 맘에들지는 않지만 컴포넌트를 나누면서 테스트코드를 바라보니까 에러나는 상황없이 너무 잘 구현해주었다. 일단 이렇게 공격적인 리팩토링을 했는데도 테스트코드가 작성되어있으니 마음이 편안했다.

즉 내가 생각하는 TDD는? 바이브 코딩에서 TDD는 그냥 필수필수필수라고 생각한다.

코드 품질

바이브 코딩

이번에는 코드 품질 관점보다는 바이브코딩의 품질에 대해서 아주 만족스럽다.

테스트코드? 잘 구현해줬잖아. 구현? 잘해줬잖아. 리팩토링? 좀 별로긴한데 에러안나고 잘 나눠줬잖아

이번에는 md파일을 중간중간 계속 생성해서 참고하라는 내용을 만들었다. 이런 부분이 Agent와 바이브코딩할 때 아주 효과적인 방법이라는 결론을 짓고싶다.

항해시작하기전 질문봇으로만 AI를 사용하던 나를 반성한다. 그냥 무지성으로 바이브 코딩은 불가능해.. 라고 생각하던 나를 반성한다.

실무에서는 분명 적용하기 어려운 부분도 있긴하지만, Context를 잘 설계해두면 회사에서도 어느정도 사용할 수 있을 것이다.

맘에 안드는 무지성의 context md 파일 더미들

바이브 코딩의 품질이 만족스럽기는 하지만 재사용성 없는 md파일도 너무 무지성으로 많이 작성한게아닌가싶다. 이것도 개발자의 관점에서 불편한걸 수도 있지만, 명확히 관심사별로 md파일을 정리했으면 어떨까 싶다. agent에게 필요할때마다 알아서 가져가서 사용하도록하여, 더 쉽고 빠르게 바이브 코딩을 할 수 있었을 것 같다.

그리고 너무 체계없는 context를 계속 건내준 것 같다. LLM은 결국 어떤 context, 어떤 prompt를 제공받았는가에 결과물이 달라진다.

이런 점에서 너무 그냥 분석해놓은 context md파일 주면서 이거 보고 해줘~ 라는 prompt를 준 것 아닌가? 싶다. (결과물이 만족스러우면 된건가..? 사실은 문제 있는건데 모르고 있을지도..?!)

학습 효과 분석

회귀 테스트

심화과제에서 테스트 전략을 어떻게 구성할까를 팀원들과 논의했었다. 준형님이 새로운 기능이 추가되었을 때 회귀테스트를 하는게 어떻냐는 제안을 해주셨고, 회귀테스트 중점으로 대화를 나누었다.

처음에 나는 회귀테스트와 전체테스트의 차이가 무엇이지? 라는 생각을 했다. A기능의 테스트가 돌고 있고, B기능이 추가되었을 때, A기능의 테스트를 다시 돌리는 것이 회귀테스트인가? 라는 생각을 한 것 같다. 그러다보니 그럼 그냥 전체테스트아니야? 라는 흐름으로 가게 되었다.

팀원들과 논의끝에, 회귀테스트는 기존기능과 추가된기능의 통합테스트이다. 라는 결론이 나왔다. 기존 A기능의 테스트를 한번 더 도는 것이 아닌, A기능에서 B기능과 엮이는 부분을 새로 추가하여 통합테스트하는 것이다.

Context 엔지니어링의 중요성

bmad methods가 대표적으로 훌륭한 context 설계를 해놓은 프레임워크이다. 사용하고 안하고의 차이는 사용해본사람은 알겠지만 엄청나다. LLM의 성능을 극대화하였고, 이번에도 kent beck 에이전트를 context 설계가 되어있으니 아주 만족스러운 코드들을 보여줬다.

과제 피드백

이번에 에이전트 구성해보는 과제가 너무 재밌었습니다 ^^7

리뷰 받고 싶은 내용

1. 프롬프트 엔지니어링과 컨텍스트 엔지니어링의 차이가 무엇일까요? context 설계를 잘 해놓은 kent beck 에이전트에게 완전 체계없는 context md파일들을 주면서 작업했는데, 이 md파일들은 context라기보다는 프롬프트라고 해야되는걸까요? 프롬프트와 context의 경계를 어떤 것으로 보면 될까요? (결국 AI에게 요청할 때는 두가지 모두 잘 작성해서 보내야되는 것이겠죠..?)

2. AI에게 Agent를 분석시키고 분석한 내용을 이용해서 또 AI가 Agent를 생성하고 생성된 Agent로 또 AI가 코드를 짜게 하는 과정이 무섭습니다. 이번 과제에서 AI가 Agent를 만들고 AI끼리 티키타카하면서 좋은 코드를 만들어냈는데, 미래에는 개발자가아니라 결국 context 엔지니어만 있으면 되는게 아닌가? 라는 걱정도 되는 것 같습니다. 개발자의 역할이 넓어지는걸까요? context 엔지니어의 직종이 생기게 되는걸까요? 테오의 의견이 궁금합니다!