[1팀 박용태] Chapter 1-2. AI와 테스트를 활용한 안정적인 기능 개발 #97
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
…re (to MCP Server)
…utput data path interface
Improve code clarity and maintainability by: - Extract default values (category, notification time, repeat settings) to named constants - Replace hardcoded validation value (1) with MIN_REPEAT_INTERVAL - Remove TDD phase comments (implementation complete) - Simplify isRepeating initialization logic All tests remain GREEN (12/12 passing) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Enhance readability and maintainability by: - Extract isRecurringEvent helper function to reduce duplication - Group related state declarations (basic fields, recurring fields, edit state, validation state) - Add organizational comments to separate concerns - Reorder code for better logical flow Benefits: - Clearer separation of concerns - Self-documenting code structure - Easier to locate related functionality - DRY principle applied to recurring event checks All tests remain GREEN (12/12 passing) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
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.
과제 체크포인트
필수 스펙
기본 과제
공통 제출
기본 과제(Easy)
기본 과제(Hard)
심화 과제
Easy 과제 응답
1. AI 코드를 잘 작성하기 위해 추가로 작성했던 지침
기본적으로 좋은 테스트 코드에 대한 문서를 참조하도록 agent를 구성했습니다. 하지만 이 많은 내용을 항상 주입할 수는 없어, 테스트코드, 서비스 코드를 직접 작성하는 역할을 지닌 agent들에게만 주입을 했고, 또 항상 이 문서를 참고하는 것이 아닌 필요에 의해서만 참조하도록 구성했습니다.
2. 커밋별 올바르게 단계에 대한 작업
TDD workflow는 3가지로 구성했습니다.
tdd_setup.yaml(Red)tdd_implement.yaml(Green)tdd_refactor.yaml(Refactor)그리고 이 작업을 수행한 커밋에 해당 표시를 해두었습니다.
Hard 과제 응답
1. 결과를 올바로 얻기 위한 history 또는 log
실제로 Claude Code와 나눴던 대화의 history 파일을 가지고, "결과를 올바로 얻기 위한..."의 맥락에서 요약을 요청해 받은 요청 목록입니다.
[ { "category": "맥락 관리 (Context Management)", "patterns": [ { "pattern": "맥락 확인 요청", "example": "좋아 앞으로 맥락을 꼼꼼히 확인 부탁해! 다음으로 넘어가자!", "reason": "AI가 이전 단계를 제대로 이행했는지 확인하고 다음 단계로 넘어가도록 유도" }, { "pattern": "다음 단계 예상 확인", "example": "다음스텝으로 넘어가자. 추가로 점검차 물어볼게 네가 예상하는 다음 스텝은 뭐야?", "reason": "AI가 전체 흐름을 이해하고 있는지 확인하고 방향성 점검" } ] }, { "category": "점진적 검증 (Incremental Validation)", "patterns": [ { "pattern": "단계별 확인", "example": "일단 내가 방금 보면서 발견한 우려사항들을 전달해줄게. ...", "reason": "긴 작업 중간에 문제를 조기 발견하여 방향 수정" } ] }, { "category": "비판적 피드백 (Critical Feedback)", "patterns": [ { "pattern": "구조적 의문 제기", "example": "아니 내 생각엔 이게 좀 어색한게... 구조적, 프로그래밍적 사고로 비판적으로 분석해줘", "reason": "AI의 제안을 무조건 수용하지 않고 구조적 타당성 검증" }, { "pattern": "다른 접근 요구", "example": "다른 접근은 없을까? 지나치게 보고서가 길고, 산출물 문서가 너무 무거워서 이를 개선하고 싶어", "reason": "첫 제안이 최선이 아닐 수 있음을 인지하고 대안 탐색" }, { "pattern": "철학적 정렬 확인", "example": "이게 가능한 방향이야? 우리의 그라운드 철학에 위배되는 방향이야?", "reason": "솔루션이 프로젝트 철학과 일치하는지 확인" } ] }, { "category": "다중 관점 활용 (Multiple Perspectives)", "patterns": [ { "pattern": "토론 형식 요청", "example": "총 4명이서 토론하는 구조로 비판적으로 분석해줘 (A - 기존방식 강력 주장, B - 기존방식 상대적 선호, C - 새로운 방식 상대적 선호, D - 새로운 방식 절대 선호)", "reason": "다양한 시각으로 솔루션의 장단점을 입체적으로 파악" }, { "pattern": "전문 Agent 활용", "example": "@agent-agent-coach ... 비판적으로 검토해줘", "reason": "특정 도메인 전문 Agent로 품질 높은 피드백 확보" } ] }, { "category": "컨텍스트 제공 (Context Provision)", "patterns": [ { "pattern": "참고 파일 첨부", "example": "@packages/agent-orchestrator-v2/.ai/personas/analyst.md 이거 고도화해줘. analyst 페르소나 에이전트를 구축할 때 참고할만한 자료들이 있다면 서치도 해줘", "reason": "AI에게 기존 컨텍스트와 표준을 명확히 제공" }, { "pattern": "이전 대화 참조", "example": "네가 전에 분석해준바로는... 이것은 잘못된거야. 다시 제대로 구현 부탁해", "reason": "AI의 이전 분석을 기억시키고 수정 요청" } ] }, { "category": "진행 속도 조절 (Pace Control)", "patterns": [ { "pattern": "중간 점검", "example": "일단 네가 제안한 방향으로 가보자 (부분 진행 후) → 추가로 개선할점이 있는지?", "reason": "부분 진행 후 피드백으로 방향 조정" } ] }, { "category": "문제 해결 패턴 (Problem Solving)", "patterns": [ { "pattern": "원인 분석 요청", "example": "1) 왜 이런 문제가 발생했는지? 2) workflow 문제인지? 3) agent persona 문제인지? 제대로 분석해줘", "reason": "근본 원인 파악 후 해결책 도출" }, { "pattern": "핵심 솔루션 요구", "example": "이 문제를 해결하는데 많은 변경이 일어나지 않았으면 해. ... 핵심을 찌르는 해결책을 찾자", "reason": "과도한 리팩토링 방지, 최소 변경으로 문제 해결" }, { "pattern": "시스템 개선 우선", "example": "단순 테스트 커버리지를 높히는 것이 목적이 아니라, 잘 돌아가는 시스템/프로세스를 만드는 것이 Core Objective", "reason": "근본적 시스템 개선에 집중" } ] }, { "category": "책임감 부여 (Accountability)", "patterns": [ { "pattern": "역할 명확화", "example": "너는 우리 조직의 코파운더로서 책임감을 가지고 문제를 분석해주면 좋겠어. 회사의 존망이 너의 손에 달려있다", "reason": "AI에게 책임감을 부여하여 더 신중한 분석 유도" }, { "pattern": "자기 검증 요구", "example": "왜 네가 또 workflow를 실행만하지 않고 subagent의 역할까지 수행했니? 너는 뭐가 문제인지 스스로 검증해볼래?", "reason": "AI가 자신의 행동을 반성하고 개선하도록 유도" } ] }, { "category": "작업 위임 (Delegation)", "patterns": [ { "pattern": "막힌 작업 우회", "example": "작성이 안되는 거면, 해당 분석과 수정 사항을 다른 agent나 master claude llm에게 위임해", "reason": "하나의 Agent가 막혔을 때 다른 경로 활용" }, { "pattern": "전문 Agent 호출", "example": "@agent-workflow-designer ... 부탁해", "reason": "특화된 Agent에게 작업 위임으로 품질 향상" } ] } ]2. AI 도구 활용을 개선하기 위해 노력한 점 (Hard 과제)
아주 고생을 많이 했습니다… 방향을 잘 못 잡아 심연으로 몇번을 갔다오기도 하고, Agent를 돌려깍는 것도 수십번을 한 것 같습니다.
일단 초반에 BMad Method의
이런 철학에 매료되어,, BMade Method보다는 가볍지만 나에게 핏하게 워킹하는 multi agent workflow 프레임워크를 만들기 위해 삽질을 많이 했습니다. 게다가 일주일간 밀도있는 경험 후 회사의 팀 내에 도입까지 하겠다는 포부로 잘못된 접근(MCP로 구현)까지 했다가 갈아엎기도 했습니다. (그 과정에서, MCP는 고맥락의 시스템을 활용해 특정 기능을 추상화하기 위한 방식이고, 그 안에서 AI가 직접 추론을 수행하지는 못한다는 점을 깨우치기도 했습니다.)
무튼 시행착오 후, Claude Code의 Subagent로 BMad Method 철학을 기반으로 구성한 workflow를 multi subagent가 협업을 통해 수행하는 구조로 컨셉을 잡았습니다. 이는 실제로 개별 ai agent 인스턴스가 workflow내의 여러 phase를 역할게 맞게 나눠 수행하므로, 하나의 AI가 여러 페르소나로 역할극을 하는 구조보다 맥락관리, 산출물의 일관성과 품질 측면에서 효율적이고 준수하다고 생각했습니다.
실제로 각 subagent는 workflow 전체의 맥락을 갖지 않고, 각자의 역할에 대한 맥락만 가지고 작업을 수행했습니다. 그리고 workflow를 집행하는 orchestrator agent는 각 phase의 품질 검증과 subagent들의 handoff를 관리하는 구조로 설계했습니다. 실제로 이 과정에 제대로 이행되었을 때, 단일 AI의 다중 페르소나 역할극 보다는 퀄리티 높은 결과물이 만들어졌습니다.
또 이 과정에서, Meta Agent의 활용을 발견하고 적극적으로 도입했습니다. Agent Designer라는 첫 메타 agent 도입을 통해, 효율적인 persona 컨텍스트 구조와 Few Shot 같은 컨텍스트 엔지니어링을 잘 활용하는 agent 명세를 만들었고, 다음으로 Workflow Designer라는 Multi Agent 기반 자동화 workflow 설계 전문가를 만들어, workflow 설계와 개선의 역할을 부여했습니다. 그리고 Agent Coach라는 AI Architect / Context Engineering 등에 전문성있고 코파운더로서 오너십을 가지고 역할을 충실하게 실행해주는 Agent를 만들어 아주 유용한 도움을 많이 받았습니다. 이런 Agent의 활용에 흥미를 느껴 앞으로도 적극 활용해볼 예정입니다.
심화과제 응답 (
report.md)파일 링크
Architecture 및 앞으로의 Roadmap
0. Diretory 구조
1. Multi-Agent 구조 특징
6개 전문 Agent: (오버 엔지니어링이라고 생각하긴 합니다...)
4-Tier Adaptive Routing (복잡도 기반):
2. Orchestrator Agent
Workflow executor, Agent들을 협업시키기 위한 Agent
역할:
할 수 없는 것 (권한 침범을 위한 제약 사항):
-> Agent가 자체 검증 후 보고 -> Orchestrator는 기록만
3. Workflow
Workflow 목록 (TDD)
tdd_setup,yaml(RED)tdd_implement.yaml(GREEN)tdd_refactor.yaml(REFACTOR)Workflow 실행 흐름 (
tdd_setup.yaml(RED) 기준으로..)Context File 방식:
4. Mermaid 시각화
a. Multi-Agent 협업 구조
graph TB subgraph "User Layer" USER[User] end subgraph "Orchestration Layer" ORCH[Orchestrator<br/>Coordinator ONLY<br/>v4.0-TRUST] STATE[(State JSON<br/>.ai-output/workflows/state/)] CONTEXT[(Context Files<br/>.ai-output/workflows/context/)] end subgraph "Agent Layer" ANALYST[Analyst<br/>Problem Definition] PM[PM<br/>Requirements] ARCH[Architect<br/>Design + Skeleton] QA[QA<br/>Tests RED] DEV[Dev<br/>Implementation GREEN] REFACTOR[Refactor<br/>Code Quality] end subgraph "Workflow Layer" WF1[tdd-setup<br/>RED Phase] WF2[tdd-implement<br/>GREEN Phase] WF3[tdd-refactor<br/>REFACTOR Phase] end subgraph "Output Layer" DOCS[Documentation<br/>.ai-output/features/] CODE[Source Code<br/>src/] TESTS[Test Files<br/>src/__tests__/] end USER -->|"Execute workflow"| ORCH ORCH -->|"Task tool"| ANALYST ORCH -->|"Task tool"| PM ORCH -->|"Task tool"| ARCH ORCH -->|"Task tool"| QA ORCH -->|"Task tool"| DEV ORCH -->|"Task tool"| REFACTOR ORCH <-->|"Read/Write"| STATE ORCH -->|"Create"| CONTEXT ANALYST -->|"Report status"| ORCH PM -->|"Report status"| ORCH ARCH -->|"Report status"| ORCH QA -->|"Report status"| ORCH DEV -->|"Report status"| ORCH REFACTOR -->|"Report status"| ORCH WF1 -->|"Orchestrates"| ANALYST WF1 -->|"Orchestrates"| PM WF1 -->|"Orchestrates"| ARCH WF1 -->|"Orchestrates"| QA WF2 -->|"Orchestrates"| DEV WF2 -->|"Orchestrates"| QA WF3 -->|"Orchestrates"| REFACTOR ANALYST -->|"Create"| DOCS PM -->|"Create"| DOCS ARCH -->|"Create"| DOCS ARCH -->|"Generate"| CODE QA -->|"Create"| DOCS QA -->|"Write"| TESTS DEV -->|"Implement"| CODE REFACTOR -->|"Improve"| CODE style ORCH fill:#e1f5ff,stroke:#01579b,stroke-width:3px style WF1 fill:#fff9c4,stroke:#f57f17,stroke-width:2px style WF2 fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px style WF3 fill:#f8bbd0,stroke:#c2185b,stroke-width:2pxb. TDD Cycle (RED -> GREEN -> REFACTOR)
graph LR subgraph "tdd-setup RED" A1[Analyst<br/>Problem Analysis] A2[PM<br/>Requirements] A3[Architect<br/>Design + Skeleton] A4[QA<br/>Failing Tests] end subgraph "tdd-implement GREEN" B1[Dev<br/>Make Tests Pass] B2[QA<br/>Verify Quality] end subgraph "tdd-refactor REFACTOR" C1[Refactor<br/>Analyze Code] C2[Refactor<br/>Improve Code] C3[Refactor<br/>Optimize Optional] end A1 -->|"01_analysis.md"| A2 A2 -->|"02_requirements.md"| A3 A3 -->|"03_design.md<br/>skeleton code"| A4 A4 -->|"04_test-plan.md<br/>RED tests"| B1 B1 -->|"05_implementation.md<br/>working code"| B2 B2 -->|"06_verification.md"| C1 C1 -->|"07_refactor-analysis.md"| C2 C2 -->|"08_refactor-changes.md"| C3 C3 -->|"09_optimization.md"| DONE[Production Ready] style A4 fill:#ffcdd2,stroke:#c62828 style B1 fill:#c8e6c9,stroke:#2e7d32 style C2 fill:#b39ddb,stroke:#5e35b15. Roadmap
과제 셀프회고
기술적 성장
AI 도구, 평소에도 많이 활용했습니다. 개발 도구, 학습 도구 그리고 일상에서도 LLM과 항상 함께 해왔읍니다. 하지만 Agent로써의 활용은 전무했던 것 같습니다. 그래서 이번주차의 경험은 정말 신선하고 제 AI 활용 방식에 새로운 지평을 열었다고 느낍니다. 그리고 빠르게 변해가는 AI 생태계에 조금 더 발맞추어 갈 수 있는 계기가 되었던 것 같습니다.
추가로 평소에도 구조적인 관점으로 문제를 마주하고 해결하기를 좋아하는 제게, 이번의 Agent를 활용한 Workflow 구조 설계는 아주 재미있는 경험이었습니다. 발제부터 이를 잘 구조화해 회사의 팀 내에 도입해야겠다는 작은 목표를 가지고 시작하다보니, 욕심이 불어나 고생도 꽤나 했습니다만, '다수의 Agent를 부리기 위한 효과적인 구조는 무엇일까?' -> '왜 이게 효과적인 방향일까?' -> 'Agent의 특성은 뭘까?'의 흐름으로 자연스럽게 LLM으로 구성된 Agent의 특성들에 대해 고민하게 되고, 결국 구조적/맥락적 접근을 위해서는 기술의 디테일에 대한 이해도 중요하다는 인사이트를 환기하기도 했습니다.
Before
After
인사이트
코드 품질
이번주차의 코드 품질이라함은, 아무래도
등 이지 않을까 싶습니다.
이를 인지하고 작성하기 위해 노력하고, Agent간의 협업을 위해서 Agent가 작성한 코드도 이를 명시하기 위해 신경을 썼습니다. 하지만 아직 익숙하지 않다보니, 그 외의 컨텍스트 관리, 구조 관리 등에 많이 신경쓰지는 못한 것 같습니다.
실제 적용
.ai-output/workflow/state/,.ai-output/workflow/context/)학습 효과 분석
AI 학습도 박차를 가하는 계기였습니다. "효과적인 컨텍스트/프롬프트 엔지니어링이란?"을 고민하게되어, 관련된 아티클 읽기와 공부에 시간을 많이 사용했고, 단순히 '학'의 수준에 머물러 있지 않고, '습'의 단계까지 경험해볼 수 있는 아주 좋은 시간이었습니다.
그 과정에서 다중 두뇌를 효과적으로 활용한 학습에 대해서 고민하기도 했습니다. 단기간에 너무 많은 학습이 이루어지고 그만 큼 밀도가 낮거나 휘발성이 강한 정보들이 많이 들어올텐데, 이를 대응하기 위해서 나는 어떤 방식으로 사고를 해야할까, 이런 저런 시도를 해보기도 했습니다.
과제 피드백
자유도가 높았다고 생각합니다. 그덕에 다른 동료들의 다양한 접근을 엿볼 수 있어 좋았습니다. 결국은 비슷한 생각을 하게되기도 하고, 전혀 새로운 접근을 하신 분들, 비슷한 문제를 해결하기 위해 어떤 접근을 했는지 의견을 나누고, 어떻게 하는게 더 효율적인 접근일지 고민해보는 시간들이 아주 좋았습니다. 모호하고 애매했기 때문에 더 고생했고, 더 풍성한 경험을 할 수 있었습니다.
리뷰 받고 싶은 내용
제가 이번에 노력을 들인 부분은
./claude폴더입니다. 하지만 이 부분에 대한 상세한 코드 리뷰 보다는, 구조에 대한 코치님의 의견이 궁금합니다.제가 이번 과제를 수행하며 했던 접근의 흐름은,
Multi Agent의 활용->BMad Method 방법론 탐구->Claude Code의 Subagent의 활용여기서 고민되는 부분은,