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

[jinseoIT]

과제 체크포인트

필수 스펙

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

심화 과제

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

---

과제 셀프회고

이번 과제를 통해 AI와 Agent 개념의 본질을 체험적으로 이해할 수 있었습니다.
특히 기존의 일반적인 워크플로우처럼 명령형으로 동작하는 것이 아니라,
AI가 스스로 추론하고 상호작용을 통해 목표를 달성한다는 점이 가장 큰 특징이자 흥미로운 부분이었습니다.

AI를 활용는 과정에서 가장 크게 느낀 점

“모든 것은 비용이다”라는 개념이었습니다.
AI에서의 비용은 단순히 금전적인 개념이 아니라,
context(토큰)을 얼마나 효율적으로 활용하느냐의 문제였습니다.
즉, context를 전략적으로 설계함으로써
사람이 투자해야 할 물리적인 시간(비용)을 줄일 수 있다는 것을 직접 체감하였습니다.

이번 과제의 주제인 AI를 활용한 TDD(Test Driven Development)에서는
“최소한의 context로 원하는 Output을 얻는 것”을 목표로 삼았었습니다.
하지만 원하는 결과를 얻기위해 agent들의 역할을 분담을 하여야 했고, 결론적으로는 3명의 agent가 6명으로 늘고나서야
원하는 결과를 얻을 수 있었습니다.

초기 3개의 Agent(po, dev, refactor)로 시작하였습니다.
하지만 과제를 진행하면서, AI가 한 번에 여러 가지 일을 수행할 때보다
하나의 일을 단위별로 나누었을 때 훨씬 더 좋은 결과를 낸다는 사실을 발견하였습니다.

이에 따라 Agent 구조를 점진적으로 확장하게 되었습니다.

SM → PO → ANALYST → DEV → (loop by Story)
              ↓
      모든 Story 완료 시
              ↓
INTEGRATION-ARCHITECT → INTEGRATION-DEVELOPER
              ↓
Epic Done (SM)

이렇게 총 7개의 Agent로 세분화하였을 때
각 역할의 책임이 명확해지고 Output의 품질도 안정화되었습니다.

물론 단위를 더 세분화한다면 퀄리티는 향상되겠지만,
그만큼 **비용(context 소비량)**이 커지고,
오버엔지니어링으로 이어질 가능성이 있다고 판단하였습니다.

결국 핵심은 비용 대비 효율 이었습니다.

---

프롬프트 설계의 핵심 4요소

개인적으로 과제를 진행하며 프롬프트를 설계할때 꼭 필요하는 부분은 아래 4가지 요소라고 생각하였습니다.

구성 요소	목적
페르소나(Persona)	Agent의 정체성과 역할을 명확히 정의하며, 어떤 시각으로 사고할지 결정하는 기준이 됩니다.
사전 학습(Prior Context)	전문성을 강화하고, 테스트 실패나 불필요한 반복 루프를 방지합니다.
행동 규칙(Rules)	금지사항이나 주의 포인트를 명시하여 결과의 일관성을 확보합니다.
행동 절차(Procedure)	단계별 흐름을 정의하여 AI가 목표에서 벗어나지 않도록 안내하는 나침반 역할을 합니다.

이 네 가지는 단순화 구조가 아니라,
AI가 사람처럼 논리적으로 사고하도록 설계하는 핵심 원리임을 직접 체험하였습니다.

---

TDD에 대한 개인적인 생각

이번 과제를 진행하면서, 저는 테스트 주도 개발(TDD)의 원리를 AI와 결합하여 실험해보는 뜻깊은 경험을 할 수 있었습니다.
처음에는 TDD라는 개념 자체보다, AI Agent가 이 과정을 얼마나 효율적으로 자동화할 수 있을까에 초점을 맞췄습니다.
그러나 과제를 진행할수록, 단순한 자동화가 아닌 TDD의 본질적 가치 — 즉, 명확한 요구사항 정의와 작은 단위의 피드백 루프 — 가 얼마나 중요한지를 깨닫게 되었습니다.

TDD를 작성하며 느꼈던 장점들
TDD의 가장 큰 장점은 코드 품질이 자연스럽게 향상된다는 점입니다.  
테스트를 먼저 작성하면서, 구현 이전에 요구사항을 명확히 정의할 수 있었고,  
불필요한 코드 작성을 줄이며 설계 의도를 보다 명확히 표현할 수 있었습니다.  
 
또한 리팩터링이 훨씬 수월해졌습니다.  
테스트 케이스가 일종의 안전망 역할을 하여, 코드 구조를 변경하더라도  
기존 기능이 깨지지 않았는지를 즉시 검증할 수 있었습니다.  
 
무엇보다도 테스트 자체가 **명세(spec)** 로서의 역할을 하기 때문에,  
코드를 작성하기전 테스트코드를 먼저 확인하니 테스트가 곧 문서가 되어 개발자 간의 소통이 훨씬 명확해질 것을 기대할 수 있었습니다. 
결과적으로 버그를 조기에 발견하고, 지속적인 통합(CI/CD) 환경에서도 더 안정적인 품질을 유지할 것 같았습니다.

TDD를 작성하며 느꼇던 단점들
물론 단점도 분명히 존재했습니다. 테스트를 먼저 작성하다 보니, 초기 개발 속도가 확실히 느려질 것 같았습니다.
만약 AI를 사용하지 않는 상황이라면 공수시간의 대부분을 TDD작성하는데 할애(?)하지 않을까 생각이 들었습니다.
또한 코드 구조를 변경할 때마다 테스트 코드 역시 수정해야 해서 유지보수 비용이 적지 않게 들었습니다. 

UI나 비동기 로직, 외부 API 통신처럼 및 라이브러리 사용시 테스트 작성이 복잡한 부분에서는  
테스트 코드가 오히려 개발보다 더 어려운 경우도 있었습니다.  결국 TDD는 단순한 개발 방법론이 아니라, **좋은 테스트를 설계할 수 있는 역량**이  함께 요구되는 방식이라는 점을 느꼈던 것 같습니다.

---

기술적 성장

• TDD의 RED-GREEN-REFACTOR 사이클을 이론이 아닌 실전으로 경험했습니다. 처음에는 테스트를 먼저 작성하는 게 비효율적이라고 생각했는데, 막상 해보니 오히려 구현 방향이 명확해져서 시행착오가 줄었습니다. 특히 generateYearlyInstances 함수를 구현할 때, 윤년 규칙에 대한 테스트를 먼저 작성해두니 구현 중에 놓칠 수 있는 edge case를 미리 잡을 수 있었습니다.
• React Testing Library의 쿼리 우선순위도 새롭게 배웠습니다. getByRole이 왜 가장 우선시되는지, 그리고 이것이 접근성과 어떻게 연결되는지 이해했습니다. Kent C. Dodds의 글을 읽으면서 "사용자가 보고 상호작용하는 방식으로 테스트하라"는 철학을 배웠고, 이게 실제로 유지보수하기 쉬운 테스트 코드를 만든다는 걸 체감했습니다.
• MUI(Material-UI) 컴포넌트의 내부 구조에 대해서도 더 깊이 이해하게 되었습니다. 단순히 가져다 쓰는 것을 넘어서, Select가 role="combobox"를 사용한다는 것, TextField의 inputProps와 InputProps가 다르다는 것, Dialog가 Portal을 사용한다는 것 등을 배웠습니다.
• AI에게 edge케이스 처리를 위해 사전 학습의 중요성을 깨달았습니다. 통합 테스트에서 이벤트 중복 문제로 "Found multiple elements with the text: 주간 회의" 같은 에러가 발생했습니다. 이벤트 제목이 form에도 있고 event list에도 있어서 생긴 문제였습니다. within(screen.getByTestId('event-list')).getByText()처럼 범위를 좁혀서 쿼리하는 방법으로 해결하여야 하였습니다. 사전에 이런 edge케이스들을 참고할 수 있는 자료를 주었다면 토큰비용(context)을 아끼고 시간비용도 더 감소 시켰을 것 같습니다.

코드 품질

테스트코드와 친해지고 있는 저보다 AI가 테스트코드를 더 잘 작성하는 것 같아 놀랐습니다..

• 명세서를 epic -> story로 나뉘고 단위테스트를 story기준으로 진행하니 테스트 품질이 높아서 만족하였습니다.
• 통합 테스트의 시나리오 설계도 만족스럽습니다. 단순히 기능이 동작하는지만 확인하는 게 아니라, 실제 사용자가 하는 행동 순서대로 테스트를 작성했습니다. "반복 일정 체크박스 클릭 → 반복 유형 선택 → 간격 입력 → 종료일 설정 → 저장 버튼 클릭 → 이벤트 목록 확인" 이런 식으로요. 이렇게 하니 나중에 테스트를 읽을 때도 "아, 이 테스트는 이런 걸 검증하는구나" 하고 바로 이해할 수 있었습니다.
• 실제 작성된 코드는 react에 관한 클린코드 프로픔프트 적용이 안되어서 그런지 품질이 낮아 아쉽습니다..

과제 피드백

• App.tsx에 8주차 관련 주석이 있어 혼란이 있었습니다ㅜ
• App.tsx의 컴포넌트들이 분리어있지 않아 AI가 추가적인 코드를 작성할때 점점 코드에서 악취의 농도가 짙어진 것 같습니다.

리뷰 받고 싶은 내용

agents들을 작성하는 부분에 의문이 있었는데 off코치님이 올려주신 솔루션을 보고 해답을 찾았습니다.