[2팀 이정민] Chapter 1-2. AI와 테스트를 활용한 안정적인 기능 개발

[LEE-jm96]

과제 체크포인트

필수 스펙

• 1. 반복 유형 선택
  • 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
  • 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
    • 31일에 매월을 선택한다면 → 매월 마지막이 아닌, 31일에만 생성하세요.
    • 윤년 29일에 매년을 선택한다면 → 29일에만 생성하세요!
  • 반복일정은 일정 겹침을 고려하지 않는다.

2. 반복 일정 표시
   • 캘린더 뷰에서 반복 일정을 아이콘을 넣어 구분하여 표시한다.
3. 반복 종료
   • 반복 종료 조건을 지정할 수 있다.
   • 옵션: 특정 날짜까지
     • 예제 특성상, 2025-12-31까지 최대 일자를 만들어 주세요.
4. 반복 일정 수정
   1. ‘해당 일정만 수정하시겠어요?’ 라는 텍스트에서 ‘예’라고 누르는 경우 단일 수정
      • 반복일정을 수정하면 단일 일정으로 변경됩니다.
      • 반복일정 아이콘도 사라집니다.
   2. ‘해당 일정만 수정하시겠어요?’ 라는 텍스트에서 ‘아니오’라고 누르는 경우 전체 수정
      • 이 경우 반복 일정은 유지됩니다.
      • 반복일정 아이콘도 유지됩니다.
5. 반복 일정 삭제
   1. ‘해당 일정만 삭제하시겠어요?’ 라는 텍스트에서 ‘예’라고 누르는 경우 단일 수정
      1. 해당 일정만 삭제합니다.
   2. ‘해당 일정만 삭제하시겠어요?’ 라는 텍스트에서 ‘아니오’라고 누르는 경우 전체 수정
      1. 반복 일정의 모든 일정을 삭제할 수 있다.

기본 과제

공통 제출

• 테스트를 잘 작성할 수 있는 규칙 명세
• 명세에 있는 기능을 구현하기 위한 테스트를 모두 작성하고 올바르게 구현했는지
• 명세에 있는 기능을 모두 올바르게 구현하고 잘 동작하는지

기본 과제(Easy)

• AI 코드를 잘 작성하기 위해 추가로 작성했던 지침
• 커밋별 올바르게 단계에 대한 작업
• AI 도구 활용을 개선하기 위해 노력한 점 PR에 작성

기본 과제(Hard)

• Agent 구현 명세 문서 또는 코드
• 커밋별 올바르게 단계에 대한 작업
• 결과를 올바로 얻기위한 history 또는 log
• AI 도구 활용을 개선하기 위해 노력한 점 PR에 작성

단일 agent 3개를 생성하였습니다.

진성 (테스트 코드 설계 에이전트)
희재 (테스트 코드 작성 에이전트)
---------Red Case---------
다솜 (코드 작성 에이전트)
---------Green Case-------

심화 과제

• 모든 질문에 대해 꼼꼼하게 정리했는지

1️⃣ 사용 도구 선택 이유와 특징

테스트 기반 개발 환경을 위해
React + TypeScript + vitest + MSW + Cursor 조합을 사용했습니다.

도구	선택 이유 및 특징
React	컴포넌트 단위 개발과 테스트가 명확해 TDD 접근에 유리합니다.
TypeScript	타입 안정성을 보장해 테스트 작성 시 런타임 오류를 예방하고, 실수를 줄여줍니다.
vitest	Jest와 유사한 API를 제공하면서 훨씬 빠른 속도와 Vite 통합 지원합니다.
MSW (Mock Service Worker)	네트워크 요청을 실제 API처럼 가짜로 흉내내, 프론트엔드 단에서 완성도 높은 통합 테스트를 수행할 수 있습니다.
Cursor	AI 기반 코드 작성·리팩토링·테스트 자동화에 유용합니다. 특히 cursor/rules와 context 기능을 통해 AI가 프로젝트 규칙을 이해한 상태에서 테스트를 생성할 수 있습니다.

---

2️⃣ 테스트를 기반으로 하는 AI를 통한 기능 개발과 없을 때의 기능개발은 차이가 있었나요?

AI를 활용한 개발은 코드 중심 사고에서 의도 중심 사고로의 전환을 이끌었습니다.
기존에는 “코드를 작성하고 테스트한다”였다면, AI 기반 개발에서는 “사용자 동작과 기대 결과를 정의한 후 구현한다”로 접근이 바뀌었습니다.
TDD에 대해서도 자세하게 알 수 있었습니다.

3️⃣ 이 context를 잘 활용하게 하기 위해 했던 노력이 있나요?

• 테스트 철학 및 규칙 (예: TDD GREEN 단계, MUI 확장 규칙)
• 테스트 생성 원칙 (예: 명시된 테스트만 생성, 확장 금지)

4️⃣ 생성된 여러 결과는 만족스러웠나요? AI의 응답을 어떤 기준을 갖고 '평가(evaluation)'했나요?

• 요구사항 외에 다른 것들을 생성해서 계속 요구사항만 생성하도록 주입시키기는 했지만 어떤 기준을 갖고 평가까지는 하지 못하였습니다.

5️⃣ AI에게 어떻게 질문하는것이 더 나은 결과를 얻을 수 있었나요? 시도했던 여러 경험을 알려주세요.

• 전제조건을 생략하지 않기
  → 환경, 라이브러리, 오류 상황까지 함께 설명할수록 실무적인 답변을 얻을 수 있었습니다.

6️⃣ AI에게 지시하는 작업의 범위를 어떻게 잡았나요? 범위를 좁게, 넓게 해보고 결과를 적어주세요. 그리고 내가 생각하는 적절한 단위를 말해보세요.

처음에는 “기능 전체 테스트 작성”처럼 넓은 범위로 요청했지만, 불필요한 가정이 섞인 결과가 자주 나왔습니다.
이후 작업 단위를 좁혀 하나의 컴포넌트, 하나의 동작 단위로 요청하자 결과의 정확도와 품질이 크게 향상되었습니다.

적절한 단위
“하나의 사용자 액션 또는 상태 변화 단위”
(예: Select 열기 → 옵션 선택 → label 변경 확인)

7️⃣ 동기들에게 공유하고 싶은 좋은 참고자료나 문구가 있었나요? 마음껏 자랑해주세요.

테스트는 버그를 찾는 도구가 아니라, 개발 의도를 명문화하는 언어다.

8️⃣ AI가 잘하는 것과 못하는 것에 대해 고민한 적이 있나요? 내가 생각하는 지점에 대해 작성해주세요.

잘하는 점	아쉬운 점
맥락 일관성 유지	암묵적 로직 해석 (MUI 비동기 state 등)
테스트 케이스 구조화 (Given-When-Then)	act, await 타이밍 판단
문서화 및 서술형 테스트 작성	불완전한 정보일 때 추측성 응답

9️⃣ 마지막으로 느낀점에 대해 적어주세요!

ai 에이전트 개발 자체가 처음이라 “오케스트레이션 에이전트(Orchestration Agent)”를 만들고 그 아래 모든 에이전트를 구현하려고
하지 않았다. 단일 에이전트 개발에 집중했고 이렇게 만드는 것이 맞는지 피드백을 받고 싶습니다!

---

과제 셀프회고

기술적 성장

테스트 주도 개발(TDD) 사이클을 AI와 함께 반복하면서 “기능을 작성하기 전에 테스트를 먼저 설계하는 사고방식”에 대하여 알게 됐습니다.
AI를 통한 테스트 코드 자동화 덕분에 테스트 커버리지 향상과 개발 속도 균형을 함께 달성할 수 있었습니다.

커서(Cursor)의 규칙(cursor/rules)을 정의하고, 켄트 벡(Kent Beck)의 TDD 철학을 에이전트에게 주입시키면서 에이전트 개발 방법과 문맥(context) 관리 중요성을 배웠습니다.

코드 품질

모든 주요 로직(예: 반복 일정, MUI 폼 입력, 상태 전이 등)에 대해 테스트 기반으로 개발했습니다.
테스트가 곧 명세서(Spec) 역할을 하여, 코드가 무엇을 해야 하는지 항상 명확했습니다.
MSW를 활용해 API 통신도 가짜 서버로 시뮬레이션하여 “통합 수준”의 테스트 코드를 작성하였습니다.
커서(Cursor)에서 생성한 테스트를 그대로 쓰지 않고, 테스트의 의도를 검증하는 습관을 들였습니다.
이는 켄트 벡이 말한 “Feedback is the foundation of improvement”을 실천한 과정이었습니다.

학습 효과 분석

켄트 벡이 말한 “Courage to Refactor”는 AI 환경에서도 중요한 가치라고 생각합니다.

AI가 만들어준 코드를 그대로 수용하지 않고,
‘왜 이렇게 했는가’를 분석하며 테스트 설계력을 키웠습니다.

테스트 실패(RED) 상태를 두려워하지 않고,
문제를 정의하고 가설을 세우는 사고력이 향상되었습니다.

반복적인 GREEN 사이클 속에서
기능보다 코드의 명료성과 의도 전달력을 더 중시하게 되었습니다.

과제 피드백

AI의 출력은 빠르지만, 명확한 문맥(context)이 없을 때 테스트가 엉뚱한 방향으로 생성되는 경우가 있었습니다.
이를 보완하기 위해 에이전트.md 파일과 프로젝트 컨텍스트를 설계하여 “AI도 규칙 안에서 생각하도록” 수정했습니다.

리뷰 받고 싶은 내용

1. ai 에이전트 개발 자체가 처음이라 오케스트레이션 에이전트와 그 아래 모든 에이전트를 구현하려고 하지 않았습니다. 저는 단일 에이전트 하나라도 완벽하게 만들어 보는것에 집중했고 TDD 사이클을 준수하기 위해 테스트 설계 에이전트, 테스트 코드 작성 에이전트, 개발 에이전트 총 3개를 개발하였습니다. 멘토님의 강의에 따라 prd는 간결하게 적으려고 노력했고, 각 에이전트한테 최대한 역할을 주입하고, 해서는 안되는 것들을 md파일에 명시하는 방향으로 개발했습니다. 이렇게 하는 것이 맞는지 궁금합니다.

2. .cursor 내 폴더 구조 잡는법도 이렇게 하는 것이 맞는지 궁금합니다.

모호한 요청의 예시)

• 코드 스타일에 대한 피드백 부탁드립니다.
• 코드 구조에 대한 피드백 부탁드립니다.
• 개념적인 오류에 대한 피드백 부탁드립니다.
• 추가 구현이 필요한 부분에 대한 피드백 부탁드립니다.

구체적인 요청의 예시)

• 현재 함수와 변수명을 보면 직관성이 떨어지는 것 같습니다. 함수와 변수를 더 명확하게 이름 지을 수 있는 방법에 대해 조언해주실 수 있나요?
• 현재 파일 단위로 코드가 분리되어 있지만, 모듈화나 계층화가 부족한 것 같습니다. 어떤 기준으로 클래스를 분리하거나 모듈화를 진행하면 유지보수에 도움이 될까요?
• MVC 패턴을 따르려고 했는데, 제가 구현한 구조가 MVC 원칙에 맞게 잘 구성되었는지 검토해주시고, 보완할 부분을 제안해주실 수 있을까요?
• 컴포넌트 간의 의존성이 높아져서 테스트하기 어려운 상황입니다. 의존성을 낮추고 테스트 가능성을 높이는 구조 개선 방안이 있을까요?
  -->