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

[ds92ko]

과제 체크포인트

필수 스펙

1. 반복 유형 선택

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

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

기본 과제

공통 제출

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

기본 과제(Easy)

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

기본 과제(Hard)

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

심화 과제

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

---

과제 셀프회고

이번 과제를 통해 AI에 대한 제 인식이 크게 달라졌습니다.
사실 저는 원래 AI에 대한 불신이 강한 편이었습니다.
주변에서 Claude나 Cursor를 결제해서 쓴다고 해도 “그걸 왜 돈 주고 써?”라는 회의적인 입장이었고, 회사에서 제공하는 GitHub Copilot도 단순히 인라인 코드 자동완성 도구로만 사용했습니다.
AI를 깊이 이해하지 못한 부분도 있었지만, 지금 돌아보니 편견이 훨씬 더 컸던 것 같습니다.

이번 과제를 진행하면서 AI를 단순한 코드 생성기가 아니라 함께 일할 수 있는 협업 파트너로 바라보게 되었습니다.
특히 테스트 주도 개발(TDD) 구조 안에서 AI가 테스트를 기준으로 코드를 생성하고, 실패를 감지하며, 회귀를 자동으로 추적하는 과정을 보면서 “올바른 컨텍스트를 제공한다면 AI도 신뢰할 수 있는 동료가 될 수 있구나”라고 느꼈습니다.
AI는 반복적이고 패턴화된 작업에서는 사람보다 훨씬 빠르고 일관되게 일했습니다.
하지만 문제의 ‘의도’를 해석하거나, 품질·보안·성능과 같은 판단이 필요한 순간에는 여전히 인간의 개입이 필수적이라고 느꼈습니다.

이 과정을 통해 AI를 맹신할 필요도, 완전히 배척할 이유도 없다는 생각을 하게 되었습니다.
AI가 인간보다 강점을 가진 부분은 과감히 위임하고, 인간은 그 빈틈을 메우는 방향으로 역할을 나누는 것이 바람직하다고 느꼈습니다.
AI는 속도와 확장성에 강하고, 사람은 방향 설정과 판단, 검증에 더 강하다고 생각합니다.
이 둘이 서로를 신뢰하며 협력할 때, 개발의 속도와 품질 모두에서 시너지를 낼 수 있다는 깨달음을 얻었습니다.

또한, 중요한 건 AI의 능력이 아니라 사람이 얼마나 명확하게 맥락을 설계하고 지시하느냐였습니다.
AI는 그 궤도 안에서 가속하는 엔진일 뿐, 궤도를 설계하는 것은 여전히 사람의 몫이라고 느꼈습니다.

기술적 성장

이번 과제에서는 AI를 활용한 테스트 주도 개발(TDD)을 실제로 적용하며, 기존과 완전히 다른 개발 사고방식을 경험했습니다.
그동안 테스트 코드를 “마지막 검증 절차”로만 생각했는데, 이번에는 기능 설계의 출발점으로 테스트를 먼저 작성하고 AI가 이를 통과하도록 유도하는 과정에서, 테스트가 단순 검증을 넘어 개발 방향을 제어하는 핵심 도구임을 체감했습니다.

TDD를 처음 접하는 입장에서, RED 단계에서 처음 스켈레톤 코드를 생성하지 않고 바로 테스트를 작성했더니, 실제 테스트 실패가 아닌 린트 에러가 발생해 혼란을 겪었습니다.
이 경험을 통해 TDD에서는 테스트 환경과 코드 구조를 먼저 준비하는 것이 얼마나 중요한지도 직접 체감할 수 있었습니다.

또한 멀티 에이전트 구조와 컨텍스트 엔지니어링을 적용하면서, AI의 응답 품질이 명세의 구체성과 맥락 유지력에 크게 의존한다는 사실도 확인했습니다.
이를 통해 AI 기반 개발 워크플로우를 설계할 때는 단순한 도구 사용이 아니라, 시스템 아키텍처 설계 수준의 사고가 필요함을 배웠습니다.
특히, 컨텍스트를 통해 에이전트 간 상태와 역할을 명확히 정의하면, AI가 보다 일관된 결과를 내도록 유도할 수 있음을 실감했습니다.

코드 품질

이번 과제는 TDD 중심의 AI 에이전트 설계에 초점을 맞췄습니다.

각 에이전트의 역할

• 전체 오케스트레이션 에이전트: 작업 단계 관리, 테스트 실행, 커밋
• 기능 설계 에이전트: 기능 명세 작성
• 테스트 설계 에이전트: 테스트 케이스 및 시나리오 설계
• 테스트 작성 에이전트: 테스트 코드 구현
• 코드 작성 에이전트: 기능 코드 작성
• 리팩토링 에이전트: 코드 리팩토링 및 개선

디렉토리 구조

/agents/                        # 에이전트 카드
├── zeus.md       # 전체 오케스트레이션 에이전트
├── athena.md     # 기능 설계 에이전트
├── artemis.md    # 테스트 설계 에이전트
├── poseidon.md   # 테스트 작성 에이전트
├── hermes.md     # 코드 작성 에이전트
└── apollo.md     # 리팩토링 에이전트

/docs
│
├── checklists/                   # 각 에이전트 작업 후 체크리스트
│   ├── zeus_checklist.md      # Zeus 체크리스트
│   ├── athena_checklist.md    # Athena 체크리스트
│   ├── artemis_checklist.md   # Artemis 체크리스트
│   ├── poseidon_checklist.md  # Poseidon 체크리스트
│   ├── hermes_checklist.md    # Hermes 체크리스트
│   └── apollo_checklist.md    # Apollo 체크리스트
│
├── guides/                       # 각 에이전트별 작업 가이드
│   ├── zeus_guide.md           # Zeus 가이드
│   ├── athena_guide.md         # Athena 가이드
│   ├── artemis_guide.md        # Artemis 가이드
│   ├── poseidon_guide.md       # Poseidon 가이드
│   ├── hermes_guide.md         # Hermes 가이드
│   └── apollo_guide.md         # Apollo 가이드
│
├── templates/                   # 템플릿 문서
│   ├── agent_card_template.md      # 에이전트 카드 템플릿
│   ├── checklist_template.md       # 체크리스트 템플릿
│   ├── guide_template.md           # 가이드 템플릿
│   ├── context_template.md         # 컨텍스트 문서 템플릿
│   ├── feature_spec_template.md    # 기능 명세 템플릿
│   ├── test_spec_template.md       # 테스트 명세 템플릿
│   ├── test_code_template.md       # 테스트 코드 템플릿
│   ├── impl_code_template.md       # 구현 코드 템플릿
│   └── refactor_report_template.md # 리팩토링 보고서 템플릿
│
├── system/                        # 시스템 전반 명세 및 가이드
│   └── agents_spec.md           # 에이전트 명세 (협업 문서)
│
└── sessions/                      # 세션 단위 실행 폴더
    ├── tdd_2025-10-30_001/      # 세션별 ID 폴더
    │   ├── context.md           # 컨텍스트 문서
    │   ├── feature_spec.md      # 기능 명세서
    │   ├── test_spec.md         # 테스트 명세서
    │   ├── test_code.md         # 테스트 코드
    │   ├── impl_code.md         # 구현 코드
    │   └── refactor_report.md   # 리팩토링 보고서
    │
    └── tdd_2025-10-30_002/      # 두 번째 세션
        └── ...

초기에는 바로 에이전트 카드를 작성했는데, 에이전트마다 형식과 포함 정보가 달라져 카드 간 일관성이 깨졌습니다.
이 과정에서 단순히 각 에이전트가 자신의 역할만 수행하는 것이 아니라 TDD 사이클을 함께 완성하는 협업 체계가 필요하다는 점을 인식했습니다.
그래서 다음과 같은 정비를 진행했습니다.

공통 협업 스펙 수립
모든 에이전트가 공유하는 통합 스펙 문서(협업 가이드)를 작성하여 역할 경계, 상호 의존 정보, 산출물 흐름을 명확히 했습니다.
각 에이전트는 자신이 담당하는 TDD 단계뿐 아니라 앞뒤 단계 에이전트의 기본 책임과 기대 산출물을 확인하도록 했습니다.

템플릿 체계 정립
에이전트 카드, 작업 사전 가이드라인, 작업 후 셀프 체크용 체크리스트, 세션 산출물(기능 명세, 테스트 명세, 테스트 코드, 구현 코드, 리팩토링 보고서) 등에 대해 표준 템플릿을 제작했습니다.
공통적으로 지켜야 하는 품질/협업 규칙 + 에이전트별 특화 규칙을 분리해 템플릿에 반영했습니다.

문서 전개 및 규격화
템플릿을 활용해 모든 에이전트 카드 / 가이드라인 / 체크리스트 문서를 재생성하여 형식과 포함 정보(목표, 입력/출력, 검증 기준 등)를 통일했습니다.
이후 TDD 세션마다 산출물 문서가 동일 구조로 누적되도록 세션 디렉토리(sessions/…)에 규격화된 파일을 생성·관리했습니다.

실행 절차 준수
각 에이전트는 작업 시작 전에 협업 스펙 문서와 자신의 가이드라인을 확인하고, 작업 종료 후 체크리스트로 셀프 검증을 수행했습니다.
산출물은 지정된 템플릿을 반드시 사용하여 정보 누락 및 형식 편차를 제거했습니다.

오케스트레이션 품질 관리
오케스트레이션 에이전트는 세션별 상태 추적 문서를 유지하며 워크플로우 단계 종료 시마다 문서 업데이트를 수행했습니다.
각 단계 종료 시 Git 커밋을 진행했으며, TDD(RED, GREEN, REFFACTOR) 단계일 경우 Git 커밋 전에 테스트를 실행해 해당 단계의 기대 결과(RED 때 실패, GREEN/REFACTOR 때 성공)를 검증한 후에만 Git 커밋을 진행했습니다.

효과

• 형식 통일로 에이전트 간 인수·출력의 호환성과 추적성이 향상되었습니다.
• 셀프 체크 내재화로 리뷰 이전 단계에서 결함/누락을 조기 제거했습니다.
• 협업 스펙 기반 산출물 커스터마이징(다른 에이전트가 필요로 하는 정보 명시)으로 재작업을 줄이고 흐름을 가속했습니다.
• 오케스트레이션 단계 검증 + 커밋 정책으로 히스토리가 TDD 진행 맥락을 충실히 반영하게 되었습니다.

학습 효과 분석

가장 큰 배움은 AI를 단순 코드 생성기가 아니라, 테스트 기반 협업 파트너로 활용할 수 있다는 점이었습니다.

• AI는 반복 작업, 대규모 코드 변경, 테스트 기반 회귀 추적에 강점
• 사람은 방향 설정, 의도 해석, 트레이드오프 판단, 최종 검증에 강점

AI와 사람의 역할을 명확히 구분하고 보완하면 개발 효율과 안정성이 모두 향상됩니다.
이번 과제를 통해 TDD가 AI 협업에서 갖는 본질적인 역할과, 테스트가 곧 안전망이라는 점을 체감했습니다.

과제 피드백

좋았던 점은 AI를 단순 도구가 아닌 협업 체계로 활용하도록 설계된 과제 구조였습니다.
테스트 기반의 기능 개발이라는 주제가 AI의 한계와 강점을 동시에 드러내서 학습 효과가 컸습니다.

특히 이 과제를 통해 AI를 어떻게 ‘활용’해야 하는가에 대한 이해가 크게 달라졌습니다.
처음에는 AI가 신뢰하기 어려운 존재라고 생각했지만, 직접 테스트 주도 흐름 속에서 함께 일해보니 “AI에게 무엇을, 어떻게 명확히 지시해야 하는가”가 핵심이라는 걸 깨달았습니다.
결국 중요한 건 AI의 능력이 아니라 사람이 컨텍스트를 얼마나 잘 설계하느냐였다는 점이 가장 인상 깊었습니다.

리뷰 받고 싶은 내용

• 멀티에이전트 시스템을 설계할 때, 에이전트 간 워크플로우를 정의한 협업 문서를 먼저 작성하고 그 내용을 기반으로 각 에이전트를 구성한 방식이 적절했는지 피드백 받고 싶습니다.
  이 접근의 의도는 각 에이전트가 자신의 역할과 목표를 명확히 이해해야 협업 과정에서 일관성과 품질을 유지할 수 있다고 판단했기 때문입니다.
  이러한 ‘역할 기반 워크플로우 설계’가 실제로 효율적인 구조인지, 더 나은 방법이 있을지 조언을 받고 싶습니다.
• AI에게 지시를 내리는 단위를 과제의 진행 단계(1~5단계 구조)에 맞춰 각 단계별(1, 2, 3...) 단위로 작업을 분리해 전달하는 방식으로 진행했는데, 이 단위 구성이 TDD 워크플로우나 멀티에이전트 운영 관점에서 적절한 설계인지 궁금합니다.
• 각 에이전트들이 상태를 공유하는 방식을 전체 오케스트레이션이 관리하는 컨텍스트 문서로 일원화했는데, 이 접근이 멀티에이전트 구조에서의 상태 관리 전략으로 적절한지 피드백을 받고 싶습니다.