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

[Jihoon-Yoon96]

과제 체크포인트

필수 스펙

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

심화 과제

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

---

과제 셀프회고

1주차 과제는 어렵다 느껴졌지만 도전할수록 테스트 개념에 대한 확신이 점점 커졌다면,
2주차 과제는 감 잡았다! 싶은 순간마다 좌절감을 안겨주는 느낌이었다.
하지만, 퀄리티야 어찌됐든 완주를 해냈고 그 과정에서 4년간 경험해본적 없는 것들을 얻어갔다고 생각한다.
(내가 언제 또 TDD 싸이클을 이렇게나 많이 돌려볼까 + 나에게 AI를 가장 개발자 답게 사용하도록 알려주고 시키는 사람이 또 있을까)

먼저, 과제의 방향성 자체는 정말 잘 잡았다는 느낌이 든다.
여러 명(?)의 AI 에이전트들과 그들을 총괄하는 오케스트레이션을 구성해야 했는데,
비용적 부담을 줄이고 최소한의 AI 모델을 사용하기 위해서 하나의 AI모델에 여러 개의 역할군을 부여하는 방식으로 진행하면 된다고 판단했다.
(마치, 백종원은 한 명이지만, 사업하는 백종원 / 예능하는 백종원 / 육아하는 백종원 등 여러 역할이 있듯이..)
그리고 각각의 에이전트들은 각자의 규칙과 목표를 가지고 임무를 수행하며, 임무 수행이 완료된 시점에는 특정한 산출물을 생산해야하고,
다른 에이전트들이 그 산출물을 활용하여 본인의 업무를 수행하게 되는 구조를 만들어야 했다.
(필요하다면 특정 단계에서 활용될 규칙에 대한 문서를 따로 모아서 해당 단계에 에이전트가 참고하게 한다.)

이렇게 명확하게 나눠졌지만 '콘텍스트'로 연결된 에이전트들이 TDD전략을 사용하여 달력의 '반복 일정' 기능을 구현해내도록 이끄는 것이 주 방향성인 것 같다.
이렇게 방향이 잡혔을 무렵, 내가 세운 과제 전략은 아래와 같다.

1. 에이전트 명세서는 시작부터 꼼꼼하게 작성하자. 그래야 나중가서 편할 것이다.
2. 규칙 문서는 만들어는 두지만 최소한으로 운영하자. 참고 자료가 너무 많으면 과부화가 걸릴 것이다.
3. AI 활용에만 매몰되지 말자. 이번 주차는 TDD를 이해하는 것도 중요할 것이다.
4. AI는 무료버전 위주로 사용하자. 제대로 사용해본 적도 없는데 과금 모델은 사치다.

이 것들과 함께 과제 결과물에 대해 신경쓴 부분도 많다.

1. 에이전트들의 output에 대한 일관성을 어떻게 유지시킬 수 있는지
   --> 에이전트 명세 문서에서 좋은 output에 대한 양식을 작성 (평일 Q&A 참고함)
2. TDD 방식의 장점 살려보기 (작은 단위의 기능들을 빠르게 쌓아 올리는 것)
   --> 여러 번의 기능 개발 + 최소한의 통합 과정 (에이전트가 생성한 PRD문서 내용을 기준으로, UI 통합이 필요한 시점에만 통합테스트 진행)
   --> TDD의 싸이클을 빠르게 자주 돌림으로써 얻는 코드의 견고함과 개발자의 성취감을 느껴보고자 함 (발제자료 참고)
3. 절대! 엔터만 무작정 누르지 말것
   --> 나 스스로가 오케스트레이션이 역할을 하여 각 워크플로우에서 나오는 산출물들이 어떤지 최대한 파악해보고자 함

지금 돌이켜 보면, 2번의 싸이클을 너무 자주 하기도 했고, PRD문서 상 UI 통합 구간이 생각보다 많이 등장하는 바람에 시간 부족 현상으로 이어졌다...
결국 마지막에 가서는 일관성도 틀어져버린 것 같고, 결과물도 초반에 비해 꼼꼼하게 살피질 못햇지만,
TDD 전략이 어떤 흐름/패턴으로 진행되고, 또 왜 켄트백 아저씨가 AI를 활용한 TDD 전략은 최고다 라고 평가한 이유를 좀 느끼게 되었다.
(잦은 싸이클 때문에 AI가 없었다면 과제의 1/4도 제출하지 못했을 것이다..)

+ 깜빡하고 못적은 사항들

• 보시다시피 커밋 수가 상당합니다.. 나름 의도된 내용이라.. 엄청 잦은 개발 단계를 AI에 돌려보게 하여, 발제자료에 적힌 "TDD의 잦은 싸이클(?)"을 경험해보고자..
• 커밋 양식을 구분해봤는데, AI가 작성한 커밋은 "COMMIT - ~~~" 이런 형식이고, 그 외의 것들은 중간중간 결과물이 맘이들지 않아 직접 수정 작업을 해보았습니다.
• 그 중, (중요!!) 적힌 부분은 나름 큰(?) 깨달음을 겪은 포인트들입니다. (일관성을 유지하기위해, 더 나은 코드를 위해 싸이클을 돌리다가 느낀 점들을 반영함. - ex. 인풋/이웃풋 양식 추가 / TDD 전략 보완 / 기능적 결함 수정 등등)
• ./gemini/PROJECT_WORKFLOW.md 파일을 만들어서, 세션을 새로 열 때마다 프로젝트 구조를 이해시키는 과정을 간소화 해보고자 함

용두사미처럼 끝나버린 2주차 과제이지만, 지금 이렇게 글을 쓰며 생각을 정리하다보니 "회사에선 쉽게 해볼 수 없는" 값진 경험을 해봄을 느끼고 있다.

기술적 성장

1. AI관련 지식들
   --> 에이전트들의 산출물 퀄리티를 올리기 위해 8학군 학부모에 빙의하여 좋다고 유명한 글들을 많이 보게 된 것 같다.
   (프롬프팅 체이닝, CoT, 좋은 프롬프팅 기법, 에이전트 템플릿 양식 등등)

2. 나만의 TDD 활용법
   --> 위에서도 언급했듯이, TDD 전략을 최대한 활용해보고 싶었다.
   그래서, 실제로 쓰이는 기법일수도 있겠지만 빠른 싸이클 회전을 위해 단위 테스트 중점적으로 진행하면서 빠른 기능 구현에 집중해보았고,
   기능 통합 과정은 최소한으로 해보고자 했다. 마지막엔 기능 통합 과정이 좀 잦았지만, 오히려 그 덕에 "너무 잦은 기능 통합 과정은 사이드 이펙트 점검을 더 자주하게 만들어 개발 속도를 더디게 만듦"을 느낄 수 있었다.

코드 품질

• 유명 개발자의 정리 문서, 공식문서 등을 많이 찾아보고 종합시켜 에이전트들한테 주입시켜보았다. 그 파생효과로 코드 퀄리티를 높여보고자 했지만,
  처음이라 미숙했던 것인지 내가 중간중간 코드도 고치고, 명세서 내용도 수정하는 과정이 잦았던 것 같다. (나중가서는 시간이 부족해 웬만한건 넘어갔..)
• 그래도 에이전트가 실제 테스트에서 에러가 자주나는 코딩방식을 캐치해보기도 했다. 실제로 (내가 어떤 자료를 주입시켰는지 모르겟지만..) findBy~를 자주 쓰는 걸 목격했는데, 결국엔 에러 내용을 고치다 보면 공통적으로 getBy를 쓸 때 통과가 잘 됨을 느꼈다. 그래서 해당 내용을 명세서에 기재하여 안정성을 높였다고 생각한다.

학습 효과 분석

• 처음엔 에이전트 명세서가 좋아야, PRD문서가 체계적이어야, 템플릿 규격이 정교해야 산출물의 퀄리티가 좋다고 느꼈지만,
  내가 오케스트레이션의 역할을 수행하면서 "결국엔 내가 잘 이해하고 잘 판단할 수 있어야" 최적의 결과물을 낼 수 있음을 느꼈다.

과제 피드백

• AI를 이렇게나 깊게 활용해볼 기회가 또 있을까? 만약 이번 기회에 경험 못했더라면 앞으로 평생 챗지피티에서 가벼운 고민만 늘어놓고 있었을 것 같다..!
• 취업 시장에서 가장 많이 요구하는 TDD에 대한 귀중한 경험을 해봐서 좋았다.
• 과제를 하면서 AI 학습과 TDD 학습을 병행하기 힘들 줄 알았지만, TDD 사이클을 돌릴 수록 어떻게 해야 AI가 말을 더 잘 듣는 지, 지금 내가 TDD 싸이클을 잘 준수하고 있는 지 등을 깨닫게 되면서 많은걸 배웠다 생각한다.

리뷰 받고 싶은 내용

궁금한 사항

• MUI 라이브러리가 쓰인 부분을 쿼링하는게 쉽지 않았던 것 같아요..! data-testid 위주로 쿼링해야 했는데, screen.debug를 통해 DOM구조를 보면 내가 타겟팅하려는 대상이 엄청 깊숙하게 숨겨져있는.. data-testId="event-list"를 기준으로 within 써서 잡을때 뭔가 의도대로 잘 안됐던 것 같은데(AI도 잘 못잡아서 3번/4번씩 소스를 수정함), 저런 UI 라이브러리를 썼을 때 쿼링 잘하는 팁? 같은게 궁금합니다!