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

[kimfriendship]

과제 체크포인트

필수 스펙

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에 작성

챗 히스토리

심화 과제

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

---

과제 셀프회고

기술적 성장

BMAD 형식을 참고해 테스트 작성용 에이전트, 설계용 에이전트, 오케스트레이터 등 역할이 분리된 에이전트를 직접 설계 해보았습니다.
에이전트들을 통해 자동화된 단계별 커밋과 리뷰, 피드백 루프를 거치며 테스트 주도 개발(TDD) 사이클을 경험했습니다.

코드 품질

학습 효과 분석

AI와 협업하면서 그 장단점을 명확히 체감할 수 있었습니다. 반복적인 작업에는 강점을 보였고, TDD 사이클의 흐름을 일정하게 유지하는 데 도움을 주었습니다. 반면, 맥락을 잘못 이해하거나 중복된 코드를 생성하고, 불필요하게 과도한 리팩토링을 수행하는 경우도 있었습니다.

또한 AI에게 ‘좋은 입력’을 제공하는 법을 학습했다. 원하는 결과가 나오지 않을 때는 프롬프트의 규칙이나 역할을 수정하거나, 이전 출력물을 참고하도록 제한했습니다. 그 과정에서 “칭찬 피드백”이나 “명시적인 단계 지시”를 주면 응답 품질이 향상되는 경향을 발견했고, 작업 범위를 좁게 쪼갤수록 정확하고 일관된 결과를 얻을 수 있었습니다. 특히 테스트 단위별로 명확한 목표를 제시하는 방식이 효과적이었던 것 같습니다.

한편, AI 개발 과정에서는 몰입의 어려움도 있었는데요. AI의 응답을 기다리는 동안 흐름이 끊기며 집중력이 떨어지는 경우가 있었고, 반대로 작은 성공 루프를 자주 경험할 수록 재미를 느꼈던 것 같습니다.

과제 피드백

• 반복일정을 단일 수정할 때, 반복 주기를 바꾸었어도 단일 수정이 되는 게 맞는지 헷갈렸습니다. 위 명세에서는 그렇게 이해해서 단일 수정이 되게 만들었는데, 명세를 더 구체적으로 개선할 여지를 남겨두셨던 건지 궁금합니다.

• 테스트 설계 에이전트는 description 부분을 작성하고, 테스트 코드 에이전트는 그 description 스켈레톤 안을 채우는 게 더 좋은 방식일까요? 저는 테스트 설계 에이전트는 전반적인 테스트 플랜을 md로 작성하게 하고, 테스트 코드 에이전트가 description부터 내부 코드까지 짜게 했는데 크게 상관없는지 궁금합니다.

리뷰 받고 싶은 내용

• 만약 에이전트가 짜준 코드에 마음에 안드는 부분이 있으면 제가 직접 고치는 게 좋을까요 아니면 프롬프트로 디렉만 해주고 직접 수정하게 하는 게 나을까요? 만약에 목표가 완전한 자동화라면 디렉을 하면서 계속 에이전트 룰을 업데이트를 하는 방식으로 가야할까요? (예를 들어, ‘테스트 케이스가 중복 되는 거 같아’, ‘루프를 최소한으로 만들어줘’ 라는 식으로 피드백을 주었습니다.)

• 코치님은 에이전트들로 얼마나 자동화를 의지하시는지 궁금합니다. 테스트 코드를 통과하고, 룰과 컨벤션에 따라 코드를 짜는 게 안정적이라고 해도 항상 제가 원하는 방식으로 되지는 않을 것 같아서요. 제가 먼저 직접 방향성을 고민하고 에이전트를 돌리는 게 아니면, 단순히 에이전트의 답변과 같은 방법으로만 사고하게 될 것 같다는 생각을 했습니다. 그래서 점점 생각을 안하고, 생각하려는 노력도 안하는 것 같아서 이게 맞나라는 기분이 들기도 했습니다. 실제로 업무를 하면서 그런 경우가 있었는데, 급하게 추가되어야 할 기능이 있어서 변경을 최소화하면서 임시로 수정되어야 할 코드가 있었습니다. 커서의 코드 응답은 기능 동작은 정상적으로 되었지만, 수정한 코드의 용도를 훼손시키는 단점이 있었습니다. 나중에 보니 비슷한 케이스로 추가된 코드가 있었는데 그 패턴을 그대로 사용하면 더 좋을 코드였습니다. TDD를 자동화 할 때는 최선의 방법으로 코드를 짜지 못할 것을 염두에 두고 자동화의 장점을 필요로 해서 AI를 활용하는 걸까요?