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

[seunghoonKang]

과제 체크포인트

필수 스펙

• 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. 발제 후

과제를 이해할 듯 하면서도 이해하기 어려웠습니다. 그래서 테스트 코드를 AI 갖고 짜라는 거 같은데, 이걸 어디서부터 시작해야되는거지?

• 다시금 발제 내용을 읽는데도 알쏭달쏭한 느낌.. 학습메이트 영서님이 어떻게 만드셨는지도 열심히 보고 아 대충 저런 느낌인가..? 생각만 하고 있었습니다.

2. 과제 준비

한참을 발제만 읽고 있다가 어느새 수요일이 됐습니다. 퇴근후 팀원들과 오프라인에서 만나 모각코를 진행하며 일단 에이전트가 먼저 무엇인지 묻고, 어떻게 하면 될 까 생각하면 되는구나

• 팀원들의 도움으로, 첫 준비를 시작했습니다. 에이전트의 의미를 다시 한 번 새기고, 심화의 내용으로 에이전트 여럿을 만들어 운영하는 오케스트레이터가 내가 준 요구사항을 자동으로 해결하는 로직을 짜야되는구나 이해했습니다.

3. 과제 시작

무엇에 망설이며 진행을 뒤늦게 시작했는지,, 빠르게 진행해보려 애썼습니다.

1. GPT에게 Ai agent가 뭔지, Bmad 문서 던져주며 설명 요청함

• 발제에서도, 또 다른 여러 많은 분들도 Bmad를 많이 참고하며 작성했다고 하기에 요청 했습니다.

2. 적당히 몇 개 만들어주길래 가지고 커서에 물어보다가 방향이 약간 이상한것 같아 다시 질문하려함

• 어느정도 잘 나왔다 생각했는데, 작성하고 다시 발제 자료를 읽어보니 많이 부족한것같아 다시 질문을 하였습니다.

3. BMAD-METHOD 참고해서 작성할라고 보니까 V6로 바뀌면서 뭐가 많이 바뀐듯?

• 저녁에 BMAD 깃 레포를 보고 있는데 갑자기 V6로 바뀐듯, 앞서 봤던 오케스트레이터와 여러 하위 에이전트를 다루는 부분에서 조금 바뀐 것 같았습니다. 다시 V6의 방향을 공부해보고 적용해볼까 했다가, 일단은 발제처럼 진행하기로 마음먹고 이전 내용을 보며 다시 작성하게 됐습니다.
  4.작성하다보니 잘하는거같은데 너무 이상해서 배웠던 내용을 다시 참고하며 수정해야됨을 느껴, 내용을 참고하며 작성한 프롬프트 원문

테스트 결과와 전체적인 흐름을 봤는데, 전반적으로 수정을 한 번 해줘야 할 것 같아.
난 최종적으로 Intergrator가 모든 에이전트를 지휘하는 형태로 가긴 할건데,
에이전트의 구분을 조금 다르게, 그리고 세분화해야할 것 같아.

첨부된 이미지를 보면 알 수 있듯, 내게는 6개의 에이전트가 필요해. (첨부된 이미지는 참고 사항이지 저게 무조건이라는 말은 아니야)
이들의 공통되는 조건들이 몇 가지 있어.

- 각각 명확한 페르소나가 있음.
- 에이전트들은 사진처럼 연결돼 돌아가는 형태.
    - 각 에이전트들은 작업을 하며 변경 사항이 있을 때, 스스로 커밋을 해야 해.
    - **각 에이전트는 자기 단계가 끝났을 때 최종적으로 나에게 다음 작업을 해도 될 지 꼭 확인을 받아야 해. (필수)**
- 기본적으로 @kent-beck-tdd.md 파일을 참고하여 TDD 작성하기.

그럼 각 에이전트에 대해 간략히 설명해볼게.

1. 기능 설계 에이전트
    - 내가 전달하는 요구사항을 토대로, 명세 / 기능에 대해 구체적이게 작성, 현재 프로젝트의 상태를 보고 어떤 것이 부족한지, 어떤 건 잘 됐는지를 확인하고 수락하는 에이전트야.
2. 테스트 설계 에이전트
    - 앞서 기능 선정 에이전트가 정리한 문서를 바탕으로, 테스트를 설계하는 에이전트야.
    - 이 에이전트는 특히 @kent-beck-tdd.md 을 제대로 참고하고 적용해야하는 에이전트야.
3. 테스트 작성 에이전트 (RED - 검증 - GREEN 반복)
    - 이름처럼 이제 설계된 테스트를 통해 테스트를 작성하는 에이전트야. 앞서 만든것처럼 easy, medium 처럼 테스트 파일을 나눌 필요는 없지만 필요하다면, 혹은 구분해야 좋겠다 싶다면 테스트를 구분지어 작성해도 돼. 하지만 테스트 작성 에이전트는 전체적인 테스트의 틀을 만드는 일이지. 완벽한 테스트 동작까지 구현하는건 아니야.
    - 작성한 테스트 문서를 보고, 잘 짜여진 테스트인지를 **가볍게 테스트** 하는거야. 이 검증이 통과하지 못하면 다시 테스트 작성 에이전트가 동작해야겠지?
    - 이젠 정말 테스트를 개발할 차례야. 가벼운 검증을 마친 테스트 작성 코드를, 이제는 동작할 수 있도록 (GREEN).
    - 또, 작성할 게 너무 많다면 테스트 별로 잘게 쪼갠다음 커밋을 해. 잘게 쪼갠 커밋이 5개를 초과할 때마다 나에게 다시 한 번 검사를 맡아야 해.
4. 코드 작성 에이전트
    - 이러한 테스트 코드를 토대로, 실제 기능을 구현해야겠지? 테스트 코드를 잘 참고해서, 실제 코드를 작성하면 돼.
    - 여기서 중요한 건, 앞서 만든 테스트를 제대로 구현하지 못하겠다고 테스트 자체를 수정해서는 **절대 안돼**. 명심해야해.
    - 코드를 작성할 때는 기존의 모듈을 잘 파악하여 올바른 위치에 알맞게 작성해야 해.
    - 코드 작성이 완료 되었다면, 어떻게 작성했는지를 내게 알려줘야 해.
    - 그리고 당연하겠지만, 작성이 완료됐다면 내가 요구한 기능을 모두 잘 구현했는지를 한번 더 스스로 테스트하는걸 잊지마.
5. 리팩터링 에이전트
    - 혹여나 더 나은 방식의 작성이 있을지, 작성 부분에 문제는 없을지, 테스트 코드에 맞게 됐는지를 한번 더 확인하고 코드를 정리하는 에이전트야.
    - 내가 갖고있는 라이브러리 혹은 유틸, 모듈을 잘 사용해서 작성한 게 맞는지도 보고.

추가 확인.

- 나는 위 에이전트들을 통합할 6번. 'Orcastrator 에이전트'를 하나 둘 것이지만, 지금은 위 6개의 에이전트들이 제대로 작성될 지, 동작할 지 모르니 추후 각각의 에이전트들을 테스트한 후에 작성할 계획이야.

---

5. 작성하고 내용을 정리하려 노션에 붙여넣기 했는데, 노션 AI가 있네? 얘한테 한번 더 물어볼까?

- 내용이 너무 좋은데? 네 제안을 모두 수락한 다음 프롬프트를 작성해줘!

---

6. 노션이 수정해 준 기획 내용이 너무 잘 나왔다 생각했습니다.

테스트 결과와 전체적인 흐름을 봤는데, 전반적으로 수정을 한 번 해줘야 할 것 같아.
난 최종적으로 Integrator가 모든 에이전트를 지휘하는 형태로 가긴 할 건데,
에이전트의 구분을 조금 다르게, 그리고 세분화해야 할 것 같아.

첨부된 이미지를 보면 알 수 있듯, 내게는 6개의 에이전트가 필요해. (첨부된 이미지는 참고 사항이지 저게 무조건이라는 말은 아니야)
이들의 공통되는 조건들이 몇 가지 있어.

- 각각 명확한 페르소나가 있음.
- 에이전트들은 사진처럼 연결돼 돌아가는 형태.
    - 각 에이전트들은 작업을 하며 변경 사항이 있을 때, 스스로 커밋을 해야 해.
    - **각 에이전트는 자기 단계가 끝났을 때 최종적으로 나에게 다음 작업을 해도 될지 꼭 확인을 받아야 해. (필수)**
    - 각 에이전트가 실패했을 때는 최대 3번까지 재시도하며, 그래도 실패하면 이전 단계로 롤백하여 나에게 보고해야 해.
- 기본적으로 @kent-beck-tdd.md 파일을 참고하여 TDD 작성하기.
- 커밋 메시지는 다음 규칙을 따라야 해: "[에이전트명] 작업타입: 간단한 설명" (예: "[테스트설계] feat: 사용자 인증 테스트 케이스 설계")

### 에이전트 간 통신 프로토콜

각 에이전트는 다음 에이전트에게 작업 결과를 전달할 때 다음 형식을 따라야 해:

- **작업 요약**: 무엇을 했는지 간단히 설명
- **주요 결정사항**: 왜 그렇게 했는지 이유
- **다음 에이전트를 위한 노트**: 특별히 주의해야 할 사항
- **참조 파일/커밋**: 관련된 파일이나 커밋 정보

그럼 각 에이전트에 대해 구체적으로 설명해볼게.

1. 기능 설계 에이전트
    - **역할**: 내가 전달하는 요구사항을 토대로, 명세/기능에 대해 구체적이게 작성, 현재 프로젝트의 상태를 보고 어떤 것이 부족한지, 어떤 건 잘 됐는지를 확인하고 수락하는 에이전트야.
    - **출력 문서 형식**: 기능 명세서에는 반드시 다음 항목이 포함되어야 해:
        - 기능 목적 및 목표
        - 구체적인 요구사항 (기능적/비기능적)
        - 제외 범위 (out-of-scope)
        - 성공 기준 (acceptance criteria)
        - 기존 코드베이스와의 연관성
    - **완료 조건**: 모든 요구사항이 명확하게 정의되었고, 내가 승인했을 때.
2. 테스트 설계 에이전트
    - **역할**: 앞서 기능 선정 에이전트가 정리한 문서를 바탕으로, 테스트를 설계하는 에이전트야.
    - 이 에이전트는 특히 @kent-beck-tdd.md를 제대로 참고하고 적용해야 하는 에이전트야.
    - **출력 문서 형식**: 테스트 계획서에는 다음이 포함되어야 해:
        - 테스트할 기능 목록
        - 각 테스트의 목적과 검증할 사항
        - 테스트 우선순위 (중요도/난이도 기준)
        - 예상되는 엣지 케이스
        - 테스트 파일 구조 제안
    - **완료 조건**: 모든 요구사항에 대한 테스트가 설계되었고, 커버리지가 충분하며, 내가 승인했을 때.
3. 테스트 작성 에이전트 (RED — 검증 — GREEN 반복)
    - **3-1. RED 단계**: 실패하는 테스트 틀 작성
        - 설계된 테스트를 바탕으로 테스트 코드의 구조를 작성해. 이 단계에서는 완벽한 구현이 아니라 "무엇을 테스트할지"를 코드로 표현하는 거야.
        - 필요하다면 테스트를 카테고리별로 구분해도 돼 (예: unit, integration, edge-cases 등).
        - 이 단계에서는 테스트가 실패하는 게 정상이야 (아직 구현 코드가 없으니까).
    - **3-2. 검증 단계**: 테스트 코드 품질 확인
        - 작성한 테스트가 올바른 구조를 가지고 있는지 **가볍게 검증**해.
        - 검증 항목: 테스트 네이밍, AAA 패턴 (Arrange-Act-Assert) 준수, 불필요한 의존성 없음.
        - 이 검증이 통과하지 못하면 3-1 단계로 돌아가.
        - 검증 실패 시 무엇이 문제인지 명확히 기록해야 해.
    - **3-3. GREEN 단계**: 테스트 완성
        - 검증을 마친 테스트 코드를, 이제는 실제로 실행 가능하도록 완성해.
        - 모든 테스트 케이스가 명확하게 실패하는지 확인해 (아직 구현 전이니까).
    - **커밋 규칙**:
        - 테스트를 논리적 단위로 나눠서 커밋해.
        - 커밋이 5개를 초과할 때마다 나에게 중간 점검을 요청해야 해.
        - 각 커밋은 "[테스트작성] test: [테스트 대상] 테스트 추가" 형식을 따라야 해.
    - **완료 조건**: 모든 설계된 테스트가 코드로 작성되었고, 예상대로 실패하며, 내가 승인했을 때.
4. 코드 작성 에이전트
    - **역할**: 테스트 코드를 통과시키기 위한 실제 기능을 구현해.
    - 테스트 코드를 잘 참고해서, 실제 코드를 작성하면 돼.
    - **중요한 원칙**: 앞서 만든 테스트를 제대로 구현하지 못하겠다고 테스트 자체를 수정해서는 **절대 안 돼**. 명심해야 해.
    - 코드를 작성할 때는 기존의 모듈을 잘 파악하여 올바른 위치에 알맞게 작성해야 해.
    - **구현 순서**:
        - 가장 간단한 테스트부터 통과시키기 시작해.
        - 각 테스트를 통과시킬 때마다 커밋해.
        - 프로젝트의 기존 패턴과 아키텍처를 따라야 해.
    - **자체 검증**: 구현이 완료되면 다음을 확인해:
        - 모든 테스트가 통과하는지
        - 내가 요구한 기능이 모두 구현되었는지
        - 기존 기능에 영향을 주지 않았는지 (회귀 테스트)
    - 코드 작성이 완료되었다면, 어떻게 작성했는지, 어떤 부분이 특히 중요한지를 내게 알려줘야 해.
    - **완료 조건**: 모든 테스트가 통과하고, 코드 커버리지가 목표치를 달성했으며, 내가 승인했을 때.
5. 리팩터링 에이전트
    - **역할**: 작동하는 코드를 더 좋은 코드로 개선해.
    - **검토 항목**:
        - 코드 중복 제거 (DRY 원칙)
        - 함수/변수 네이밍 개선
        - 복잡도 감소 (cyclomatic complexity)
        - 프로젝트의 기존 유틸, 라이브러리, 모듈을 제대로 활용했는지
        - 디자인 패턴 적용 가능성
        - 성능 최적화 여지
    - **리팩터링 후 필수 확인**:
        - 모든 테스트가 여전히 통과하는지
        - 테스트 코드에 맞게 작동하는지
    - **객관적 기준**:
        - 코드 복잡도가 10 이하로 유지되는지
        - 함수 길이가 50줄을 넘지 않는지
        - 테스트 커버리지가 유지 또는 향상되었는지
    - 리팩터링할 게 없거나 미미하다면, 그것도 명확히 보고해야 해.
    - **완료 조건**: 코드 품질이 기준을 만족하고, 모든 테스트가 통과하며, 내가 승인했을 때.

### 문서화 요구사항

각 에이전트는 작업 완료 시 다음을 문서화해야 해:

- 작업 요약 (무엇을 했는지)
- 주요 결정사항 및 이유
- 발생한 문제와 해결 방법
- 다음 에이전트를 위한 인수인계 사항
- 관련 커밋 ID 목록

추가 확인.

- 나는 위 에이전트들을 통합할 6번. 'Orchestrator 에이전트'를 하나 둘 것이지만, 지금은 위 5개의 에이전트들이 제대로 작성될지, 동작할지 모르니 추후 각각의 에이전트들을 테스트한 후에 작성할 계획이야.
- Orchestrator는 다음 역할을 할 거야:
    - 전체 워크플로우 관리
    - 에이전트 간 컨텍스트 공유
    - 에러 발생 시 적절한 에이전트로 롤백
    - 나에게 전체 진행 상황 보고

---

8. 작성하고 또 놓친게 없을 지 체크하다가, server.js 가 있는걸 확인하여, server.js가 API 명세 역할 한다는 걸 알려주어 수정했습니다.

9. 또 놓친게 없나 수정된 md 파일을 읽다가, 테스트하는 내용 it( ~~~ 이 영어로 나오는 것을 확인. describe는 함수 같은걸 정의할 때가 있으니 어쩔수 없지만 it 부분은 한글로 작성해 명확히 읽어지길 요청했습니다.

10. 다시 또 읽어보다가, 아 TDD의 순서가 RED-GREEN-REFACTOR의 반복인데 RED-검증-GREEN / REFACTOR로 작성하도록 요청한 것을 발견. 다시 RED-GREEN-REFACTOR의 순서로 요청. → 중간 살펴보니 커서도 RED-GREEN-REFACTOR의 순서가 더 명확함을 알고 수정하였습니다.

11. 혹시나 싶어, 기존 hooks나 utils에도 공통된 내용이 많으니 사용해야 기존 형태를 잘 유지할 수 있을거라 했더니 그거에 대해 추가로 수정하게 됐습니다.

12. 마지막으로, 오케스트레이터를 만들기 전 각자의 에이전트가 잘 돌아가는 지 확인하려 진행했는데, 테스트 한 부분에서 계속 막히게 된 안타까운 일이 발생하였습니다.

과제 후기

• AI에 대해 항상 가볍게 질문하고 문제에 대해서만 쉽게 질문했었는데, 에이전트라는 개념과 실제 사용을 통해 많이 배웠습니다.
• 이러한 키워드가 있다는 걸 아는 것, 또 조금씩 사용한 것이 좋은 기회였다고 생각합니다.