[5팀 오태준] Chapter 1-2. AI와 테스트를 활용한 안정적인 기능 개발 #98
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- 6개 AI 에이전트 구현 (Orchestrator, Feature Design, Test Design, Test Writing, Code Writing, Refactoring) - 테스트 작성 규칙 명세 문서 작성 - 각 에이전트별 상세 명세 문서 작성 - 종합 가이드 문서 작성 - TDD 워크플로우 자동화 구조 완성 구현된 에이전트: - orchestrator.js: 전체 TDD 워크플로우 관리 - feature-design-agent.js: 기능 명세 작성 - test-design-agent.js: 테스트 케이스 설계 - test-writing-agent.js: 테스트 코드 작성 - code-writing-agent.js: 구현 코드 작성 - refactoring-agent.js: 코드 품질 개선
- Specification Analysis Agent 개선 - 체계적인 테스트 구조 자동 생성 - MSW 모킹 및 vi.mock 자동 포함 - 정확한 메서드 매핑 로직 구현 - True TDD Agent 신규 구현 - RED → GREEN → REFACTOR 완전한 TDD 사이클 - 점진적 개발: 시나리오별 하나씩 처리 - 자동 수정 및 롤백 기능 - 리팩토링으로 코드 품질 개선 - Orchestrator 개선 - 자동 커밋 비활성화 - ES 모듈 호환성 개선 - 핵심 기능 ✅ 완전 자동화된 테스트 생성 ✅ 실패하는 테스트 → 통과하는 구현 → 리팩토링 ✅ 다양한 시나리오 처리 가능 ✅ 수동 개입 없이 모든 처리 완료
- 파일 구조 재구조화 - agents/core/: 핵심 Agent들 (True TDD, Specification Analysis) - agents/improved/: 개선된 Agent들 (Test Writing, Code Writing, Refactoring) - agents/legacy/: 기존 Agent들 (참고용) - docs/guidelines/: 공식 문서들 - Test Writing Agent 완전 재구현 - 공식 문서 기반 테스트 생성 - MSW 핸들러 자동 생성 - Given-When-Then 패턴 적용 - 완전한 테스트 코드 구조 생성 - Code Writing Agent 완전 재구현 - 테스트 코드 기반 구현 생성 - TypeScript 인터페이스 자동 생성 - React Hook 패턴 적용 - 완전한 구현 코드 생성 - Refactoring Agent 구현 - 코드 품질 분석 - 중복 코드 제거 - 성능 최적화 - 코드 검증 시스템 - 공식 테스트 작성 가이드라인 추가 - testing-guidelines.md: 완전한 테스트 작성 표준 - test-writing-rules.md: 테스트 작성 규칙
- 개선 작업 보고서 추가 (docs/improvement-report.md) - 파일 구조 개선사항 상세 기록 - Agent별 개선사항 및 성능 비교 - 핵심 개선사항 및 향후 계획 - Agent 사용 가이드 추가 (docs/agent-usage-guide.md) - 개선된 Agent 사용법 상세 설명 - 완전한 TDD 워크플로우 가이드 - 고급 사용법 및 문제 해결 방법 - README 업데이트 - 최신 업데이트 정보 추가 - 새로운 파일 구조 설명 - 빠른 시작 가이드 추가 - 문서 참조 링크 추가 이제 사용자가 Agent들을 효과적으로 활용할 수 있는 완전한 문서화가 완료되었습니다.
- Test Writing Agent: 메서드명 매핑 대폭 개선 (즐겨찾기, 알림, 검색, 이벤트, 다이얼로그, 폼 관련) - Code Writing Agent: API 엔드포인트 매핑 완전 개선 (NONE 타입 추가, 실제 엔드포인트 매핑) - Feature Design Agent: 사용자 스토리 품질 대폭 개선 (시나리오별 맞춤형 스토리 생성) - Test Design Agent: 완전 새로 구현 (Kent Beck 원칙, 테스트 피라미드, 체계적 설계) - Complete Orchestration Agent: 완전 새로 구현 (단계별 커밋, 최종 검증, 에러 처리) - ESLint 설정 수정: 테스트 전역 변수 추가 모든 Agent가 이전 문제점들을 해결하고 완벽하게 작동할 준비 완료
- 7단계 완전 자동화된 TDD 워크플로우 구현 * SpecificationQualityAgent: 명세 품질 검증 및 개선 제안 * FeatureDesignAgent: 상세한 PRD 문서 생성 * TestDesignAgent: 포괄적인 테스트 전략 및 케이스 설계 * ImprovedTestWritingAgent: MSW 핸들러 포함 테스트 코드 생성 * ImprovedCodeWritingAgent: TypeScript Hook 구현 코드 생성 * TestExecutionAgent: 테스트 실행 및 자동 수정 * ImprovedRefactoringAgent: 코드 품질 개선 - 완전한 데이터 플로우 구현 * 각 에이전트 간 명확한 입력/출력 정의 * Hook 이름 일관성 보장 (한글→영어 PascalCase 변환) * Import 경로 자동 생성 및 수정 - 테스트 검증 완료 * 116개 테스트 모두 통과 * TypeScript 컴파일 성공 * ESLint 검사 통과 * 개발 서버 정상 실행 - 실제 기능 구현 예시 * 이벤트 즐겨찾기 기능 완전 구현 * 테스트 코드와 구현 코드 자동 생성 * MSW 모킹 및 API 호출 로직 포함 - 문서화 및 템플릿 제공 * 기능 명세서 템플릿 * 테스트 조건 포함 명세 가이드 * 에이전트 사용법 문서화
- 00. [Setting] 과제 제출을 위한 초기 설정 - 01. [Foundation] AI 테스트 에이전트 구축 완료 - 02. [Breakthrough] 진짜 TDD AI Agent 구현 완료 - 03. [Restructure] Agent 구조 개선 및 완전 재구현 - 04. [Documentation] Agent 개선 작업 문서화 완료 - 05. [Optimization] Agent 개선 작업 완료 - 100% 수행 가능한 TDD 시스템 구축 - 06. [Completion] 완전한 TDD AI Agent 워크플로우 구현 완료 각 단계별로 수행한 작업, 달성 성과, 핵심 인사이트를 상세히 기록하여 개발 과정의 투명성과 학습 가치를 제공합니다.
- RED → GREEN → 완료까지 수동 개입 없이 완전 자동화 - 파일명 불일치 문제 해결 (use- prefix 및 kebab-case 변환) - API 엔드포인트 불일치 문제 해결 (test-writing-agent와 code-writing-agent 동기화) - simple-auto-tdd-agent.js로 최대 10회 재시도 메커니즘 구현 - 1번째 시도에서 성공적으로 TDD 사이클 완료 확인 주요 개선사항: - extractApiEndpoint 메서드에 메서드 이름 기반 API 매핑 로직 추가 - 구현 파일명 생성 시 use- prefix와 kebab-case 변환 로직 개선 - 테스트와 구현 간 API 엔드포인트 일치성 확보
…lete; seriesId support; lint fixes; specs runner updated
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
과제 체크포인트
필수 스펙
심화 과제
docs/process/*교차 인용으로 배경/판단 근거 정리구현 메모(핵심 결정)
seriesId로 편집/삭제 범위를 안전하게 지정과제 셀프회고
기술적 성장
이번 과제를 통해 '스펙을 코드로 자동 변환하는' 파이프라인을 구축하고 실제 작동시켰다.
스펙 중심 개발 (SSOT): 이전에는 명세서를 '읽고' 코드를 '작성'했다면, 이번에는 명세서(.txt)가 곧 실행 가능한 테스트와 코드의 '재료'가 되었다.
자동화된 TDD 사이클: 오케스트레이터를 통해 RED(스펙) → GREEN(테스트/코드 생성) → REFACTOR(UI 동기화)의 흐름을 자동화했습니다. 이는 단순히 시간을 절약하는 것을 넘어, 스펙 변경에 대한 두려움을 없애고 구현이 명세를 100% 따르고 있음을 보장해 주었다.
'추론'에서 '규칙'으로: 가장 큰 변화는 '키워드 매핑'을 제거한 것입니다. 처음에는 특정 키워드(예: '반복 아이콘')를 하드코딩해 UI를 수정하려 했으나, 이는 스펙이 조금만 바뀌어도 깨지는 불안정한 방식이었다.
이를 GWT(Given-When-Then) 구조화 입력, 파일명/훅 네이밍 컨벤션으로 대체했다.
코드 품질
코드 품질 향상을 위해 '명확한 책임 분리'와 '안정적인 실행 환경'에 했다.
관심사의 분리 (SoC):
UI (App.tsx)는 상태를 표현하고 이벤트를 전달하는 역할만 하도록 단순화하였다.
복잡한 로직(예: '단일 수정' vs '시리즈 수정')은 seriesId라는 명확한 데이터 식별자를 기반으로 훅 내부에서 처리했다.
예를 들어, 단일 수정 시 repeat.type='none'으로 변경하는 것은 UI가 신경 쓸 일이 아니라, 데이터 레벨에서 처리되어야 할 규칙이다. 이 경계를 명확히 한 것이 중요했다.
개발 환경 안정화:
ESLint, Prettier, TypeScript (noImplicitAny)를 '품질 게이트'로 활용해 AI가 생성한 코드라도 최소한의 컨벤션과 타입 안정성을 지키도록 강제하였다.
EPERM 테스트 종료 오류처럼 환경에 의존하는 문제는, 테스트 결과(JSON)를 파싱하는 로직을 분리해 파이프라인 전체가 중단되지 않도록 방어했다.
학습 효과 분석
이번 과제는 '어떻게' 구현하는지보다 '왜' 이 방식이 효과적인지 깨닫는 과정이었습니다.
빠른 피드백 루프의 힘: 스펙을 5개로 분할하고 순차 실행한 것이 핵심이었습니다. 문제가 생겨도 실패 지점이 명확히 고립되어 디버깅 시간이 거의 들지 않았습니다.
AI는 '해석'이 아닌 '실행' 도구다: AI의 '추론' 능력에 의존할수록 결과는 불안정해집니다. 반면, GWT처럼 구조화된 입력을 주고 명확한 규칙(컨벤션)을 제공하자, AI는 매우 안정적이고 강력한 '실행' 도구가 되었습니다. AI를 길들이는 법을 배운 셈입니다.
품질 게이트는 '안전망'이다: 타입/린트/테스트 자동화는 AI 활용에 필수적인 '안전망'입니다. AI가 만든 코드를 100% 신뢰할 순 없지만, 이 게이트들이 최소한의 품질과 일관성을 보장해 주어 안심하고 다음 단계로 나아갈 수 있었습니다.
과제 피드백
과제에서 제시한 자동화 파이프라인은 매우 인상적이었고, 문서(스펙)가 실제 실행 가능한 산출물로 이어지는 경험은 신선했습니다.
다만, 과제를 수행하면서 **'AI에 대한 의존성'**이 생각보다 훨씬 크다는 점이 아쉬움으로 남습니다.
높은 결합도: 현재의 파이프라인은 이 과제를 위해 AI가 없다면 사실상 동작하기 어렵습니다. 스펙(.txt)을 GWT로 파싱하고, 적절한 훅과 테스트 코드로 변환하는 로직은 그 자체로 또 하나의 복잡한 시스템입니다. 해당 과정을 일주일이 아니라,, 조금 오랜 기간동안 탐구하며 했다면 훨씬 더 좋지 않을까? 내가 정말 TDD AI 에이전트를 만들어 봤다고 말할 수 있는 수준인가? 라는 의심을 버리기 어렵습니다.
유지보수성: 이 자동화 도구(에이전트, 오케스트레이터) 자체의 유지보수 비용이, 수동으로 코드를 작성하는 비용보다 정말 낮은지에 대한 확신이 들지 않았습니다.
결국 이 과제는 'AI를 활용한 개발 자동화'의 가능성을 보여주었지만, 동시에 특정 도구와 방식에 강하게 종속될 수 있다는 위험성도 함께 느끼게 했습니다.
리뷰 받고 싶은 내용(구체)
코치님께 더 여쭙고 싶은 것은 코드에 대한 리뷰 보단 **과제의 '목적성'과 '지속가능성'**에 대한 의견입니다.
이 과제의 진짜 학습 목표가 'TDD에 대한 이해'인지, 'AI 기반 개발 파이프라인 구축 및 활용 경험'인지 궁금합니다. 저는 전자 비중이 보다 높다고 느꼈는데, 이것이 의도하신 방향이 맞을까요?
요약하자면, **"해당 과제 철학과 장기적인 비전"**에 대해 코치님 어떻게 생각하시는지, 그리고 이 방식이 미래에 보편적인 개발 패러다임이 될 수 있을지에 대한 의견을 나눠주시면 감사하겠습니다.