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

[totter15]

과제 체크포인트

필수 스펙

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

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

기본 과제

공통 제출

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

기본 과제(Hard)

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

에이전트들

1. pm - 이슈 생성
2. test-designer - pm이 생성한 issue를 기반으로 테스트 설계
3. test-code-developer - test-disigner가 설계한 테스트를 코드로 작성(RED)
4. implementaion-developer - test-code-developer가 작성한 테스트를 통과할 코드 작성(GREEN)
5. refactoring-developer - implementaion-developer가 작성한 코드를 리팩토링(REFACTOR)
6. orchastration - 위의 5개의 에이전트들을 총괄

• 모든 에이전트는 pm이 만든 issue문서를 기준으로 작업내용을 확인하고 작업한 내용에 대해 남깁니다.
• 각 에이전트들은 단계별 checklist를 검토후 작업내용을 요약해서 사용자에게 다음 단계로 넘어갈지 확인을 받고 넘어갑니다.

이렇게 총 6개의 에이전트를 개발했습니다.

1. 요구사항을 입력받는다
2. `@pm.md` 를 이용해서 issue 문서를 만든다.  
   2-1. `@pm.md` 가 작업한내용은 `@pm-checklist.md` 로 검토후 정리해서 알려준다.  
   2-2. 다음 단계로 넘어가도 되는지 허락받는다.
3. `@test-designer.md` 를 이용해서 `@pm.md` 가 작성한 issue문서를 보고 테스트코드 설계를 한다.  
   3-1. `@test-designer.md` 가 작업한 내용은 `@test-plan-checklist.md` 로 검토후 정리해서 알려준다.  
   3-2. 다음 단계로 넘어가도 되는지 허락받는다.
4. `@test-code-developer.md` 를 이용해서 `@test-designer.md` 가 작성한 issue의 테스트 시나리오, 테스트 케이스를 보고 TDD과정중 RED에 해당하는 테스트 코드를 작성한다.(RED)  
   4-1. `@test-code-developer.md` 가 작업한 내용은 `@test-code-checklist.md` 로 검토후 정리해서 알려준다.  
   4-2. 다음 단계로 넘어가도 되는지 허락받는다.  
   4-3. 다음 단계로 넘어가도 되면 커밋을 남긴다.

5. `@implementaion-developer.md` 를 이용해서 `@test-code-developer.md` 가 작성한 테스트를 통과할 최소한의 코드를 작성한다.(GREEN)
   5-1. `@implementaion-developer.md` 가 작업한 내용은 `@implementation-checklist.md` 로 검토후 정리해서 알려준다.  
   5-2. 다음 단계로 넘어가도 되는지 허락받는다.  
   5-3. 다음 단계로 넘어가도 되면 커밋을 남긴다.

6. `@refactoring-developer.md` 를 이용해서 `@implementaion-developer.md` 가 작성한 코드를 리팩토링한다.(REFACTOR)
   6-1. @refactoring-developer.md 가 작업한 내용은 @refactoring-checklist.md 로 검토후 정리해서 알려준다.  
   6-2. 다음 단계로 넘어가도 되는지 허락받는다.  
   6-3. 다음 단계로 넘어가도 되면 커밋을 남긴다.
7. 모든 프로세스가 완료됨을 알린다.

위는 제가 orchastration 에이전트를 만들때 AI에게 워크플로우에 대해 지시한 부분입니다.

심화 과제

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

---

AI와 테스트를 활용한 안정적인 기능 개발 리포트

사용하는 도구를 선택한 이유가 있을까요? 각 도구의 특징에 대해 조사해본적이 있나요?

작업 도구로는 Cursor와 ChatGPT를 사용했습니다. CLI 기반 도구보다 접근성이 높고, 실제 코드 작성 환경과의 통합이 용이하다는 점에서 Cursor를 선택했습니다.

ChatGPT는 프롬프트 설계와 학습에 활용했습니다. 대화를 통해 효과적인 지시문을 구성하는 방법을 익히고, 제가 작성한 프롬프트의 품질을 평가받는 데 도움을 받았습니다.

코드 작성 측면에서는 Claude가 가장 많이 추천을 받았는데, 실제로 Cursor 내에서 Sonnet 모델을 사용했을 때,
전체적인 문맥을 이해하고 일관된 솔루션을 제시하는 능력이 뛰어나다는 인상을 받았습니다.

테스트를 기반으로 하는 AI를 통한 기능 개발과 없을 때의 기능개발은 차이가 있었나요?

일단 AI를 통한 개발을 할 경우 개발 속도에서는 확실히 빨라짐을 느꼈습니다. 개발 효율이 높아졌지만 그만큼 정확도에 대해서는 사용자가 과정 중간중간에 제대로 확인하지 않으면 떨어지게 되는 경우가 발생하는 것 같습니다.

AI의 응답을 개선하기 위해 추가했던 여러 정보(context)는 무엇인가요?

각 에이전트의 역할과 페르소나를 프롬프트 상단에 명시하여, AI가 수행해야 할 책임과 관점을 명확히 구분했습니다.

프로젝트의 전반적인 PRD와 아키텍처 구조를 사전에 제공해 모든 에이전트가 동일한 맥락에서 프로젝트를 이해하도록 했습니다. 또한 일관된 코드 품질을 유지하기 위해, 현재 프로젝트의 코드 스타일과 테스트 코드 작성 기준을 문서화하여 코드 작성 시 이를 반드시 참고하도록 지시했습니다. 이때 리팩토링 원칙과 클린 코드 개념도 함께 반영했습니다.

워크플로우 측면에서는, 요구사항이 들어오면 PM 에이전트가 Issue 문서를 생성하고 다른 에이전트들이 이를 기반으로 다음 단계를 수행하도록 설계했습니다. Issue의 일관성을 위해 Issue Template을 활용했으며, 커밋 단계에서는 Commit Template을 적용해 프로젝트 전반에 걸쳐 일관된 관리 체계를 유지했습니다.

이 context를 잘 활용하게 하기 위해 했던 노력이 있나요?

각 에이전트는 작업 시작 시 체크리스트를 참고하고, 작업 완료 후에는 동일한 체크리스트를 기준으로 결과물을 검증하도록 했습니다. 이를 통해 수행 과정과 산출물 평가 기준을 일치시켰습니다.

또한 하나의 Issue 파일을 모든 에이전트가 공유하도록 구성해, 각 에이전트가 개발해야 하는 기능의 맥락과 상호 의존성을 명확히 이해할 수 있게 했습니다.

생성된 여러 결과는 만족스러웠나요? AI의 응답을 어떤 기준을 갖고 '평가(evaluation)'했나요?

기준점을 잡는게 어려웠는데 일단 각 단계의 체크리스트가 제대로 이행되었는지를 1차로 요약해서 확인을 받았고, 2차로는 사람이 제대로 작성되었는지를 확인하면서 평가를 진행했습니다.

pm에이전트가 작업후 요약내용 제출

테스트 설계 에이전트가 작업후 요약내용 제출

테스트 코드 작성 에이전트가 작업후 요약내용 제출

코드 작성 에이전트가 작업후 요약내용 제출

리팩토링 에이전트가 작업후 요약내용 제출

AI에게 어떻게 질문하는것이 더 나은 결과를 얻을 수 있었나요? 시도했던 여러 경험을 알려주세요.

페르소나를 통해 범위를 좁히고 질문을 했을때 좀더 원하는 결과를 얻었던 것 같습니다.
이번 프롬프트를 작성하면서 GPT에게 의견을 얻기위해서 AI프롬프트 설계를 과제로 내준 교수를 페르소나로 설정해서 제가 만든 프로세스나 프롬프트에 대해 질문을 하면서 과제를 진행했습니다. 최대한 자세한 설명을 줄수록 명확한 답을 얻을 수 있었던 것 같습니다.

AI에게 지시하는 작업의 범위를 어떻게 잡았나요? 범위를 좁게, 넓게 해보고 결과를 적어주세요. 그리고 내가 생각하는 적절한 단위를 말해보세요.

큰 단위의 결과물을 한 번에 요청해 정리하는 것보다,
작은 단위를 만들고 점진적으로 개선하는 방식이 더 효과적이었습니다.

초기에는 프롬프트 설계에 익숙하지 않아, BMAD-METHOD 링크를 직접 전달하고 “이 방법을 참고해 PM을 만들어 달라”고만 요청했습니다. 그 결과, AI는 BMAD-METHOD 기반의 대형 프로젝트용 구조를 생성했고, template 파일은 약 800줄, agent 파일은 약 400줄에 달하는 수준으로 만들어졌습니다.

나는 prd생성및 이슈를 관리하는 pm을 만들고 있어. 이 에이전트의 역할은 전반적인 레포지토리를 분석하고 prd 생성 및 개발자를 위한 이슈를 관리하는 역할이야. @https://github.com/bmad-code-org/BMAD-METHOD 를 참고해해줘. 이 pm 에이전트를 보완해줘.

// 질문 나는 prd생성및 이슈를 관리하는 pm을 만들고 있어. 이 에이전트의 역할은 전반적인 레포지토리를 분석하고 prd 생성 및 개발자를 위한 이슈를 관리하는 역할이야. @https://github.com/bmad-code-org/BMAD-METHOD 를 참고해해줘. 이 pm 에이전트를 보완해줘.

// AI 결과물
## ✅ 완료 요약

### 🎯 주요 개선사항

**BMAD-METHOD™를 참고하여 PM 에이전트를 대폭 보완했습니다:**

#### 1. **PM Agent 정의 대폭 확장** (`agents/pm.md`)
   - **97줄 → 443줄** (356% 증가)
   - 레포지토리 전반 분석 기능 추가
   - PRD 생성 기능 추가
   - 개발 스토리/이슈 생성 기능 추가
   - Agentic Planning 워크플로우 통합
   - BMAD-METHOD™ 핵심 원칙 통합
   - 다른 에이전트(Analyst, Architect, Dev, QA)와 협업 프로세스

#### 2. **새로운 템플릿 생성**
   - ✅ `prd-template.md` - 완전한 PRD 구조
   - ✅ `story-template.md` - Context-Rich Development Story
   - ✅ `spec-template.md` - 기존 유지

#### 3. **품질 보증 시스템**
   - ✅ `story-checklist.md` - Story 품질 검증 체크리스트 (신규)
   - ✅ `spec-checklist.md` - 기존 유지

#### 4. **문서 관리 시스템**
   - ✅ `.cursor/README.md` - 전체 시스템 가이드
   - ✅ `context/README.md` - PRD & Architecture 관리
   - ✅ `stories/README.md` - Development Story 관리
   - ✅ `AGENT_SUMMARY.md` - 시스템 요약

---

### 📂 완성된 구조

```
.cursor/
├── AGENT_SUMMARY.md          ✅ 시스템 요약
├── README.md                 ✅ 전체 가이드
├── agents/
│   └── pm.md                 ✅ PM Agent (대폭 보완)
├── checklists/
│   ├── spec-checklist.md     ✅ 기존 유지
│   └── story-checklist.md    ✅ 신규 생성
├── context/
│   └── README.md             ✅ PRD 관리
├── specs/
│   └── spec-repeat-type-selection.md  ✅ 기존 유지
├── stories/
│   ├── README.md             ✅ Story 관리
│   └── archive/              ✅ 완료 스토리 보관
└── templates/
    ├── prd-template.md       ✅ 신규 생성
    ├── spec-template.md      ✅ 기존 유지
    └── story-template.md     ✅ 신규 생성

7 directories, 11 files
```

---

### 🚀 새로운 기능

#### PM Agent Commands

```bash
*analyze-repo              # 레포지토리 전체 분석
*create-prd [feature]      # PRD 문서 생성
*create-spec [feature]     # Tech Spec 생성
*create-stories [spec]     # 개발 스토리 생성
*create-all [feature]      # PRD → Spec → Stories 전체 생성
*validate-docs             # 문서 체인 검증
*update-story-status       # 스토리 상태 업데이트
*help                      # 명령어 목록
```

gpt에게 물어보니 저희 프로젝트에 비해 너무 오버스펙의 기능이라고 해서 다음엔 우리 프로젝트의 스펙을 알려주고 좀 더 라이트하게 변경하는걸 요청했습니다.

지금 우리 프로젝트는 기본적인 CRUD프로젝트인데 pm의 역할이 너무 오버스펙인것 같아.

// 질문 지금 우리 프로젝트는 기본적인 CRUD프로젝트인데 pm의 역할이 너무 오버스펙인것 같아.

// AI 결과물
맞아요. 그래서 PM 에이전트를 과하지 않게 쓰도록 Lite 모드를 기본값으로 추가했고, CRUD에 최적화된 얇은 템플릿과 체크리스트를 넣었습니다.

  변경사항
  - PM 에이전트에 모드 추가: Lite(기본), Standard, Advanced
  - Lite 모드 기본 동작: PRD 생략 가능, 간단 스펙/체크리스트만 생성
  - 새 파일
    - `.cursor/templates/spec-template.lite.md`
    - `.cursor/checklists/spec-checklist.lite.md`
  - 문서 업데이트
    - `pm.md`: 모드 설명, 명령 플래그 추가, 워크플로우 모드별 적용
    - `.cursor/README.md`: Modes 섹션, 명령 사용법 업데이트
  
  Lite 사용법
  - 빠른 스펙 생성:
    - `*create-spec user-crud --mode lite`
  - 일괄(필요 최소만):
    - `*create-all user --mode lite`
  - Lite 스펙은 Summary, Goals, Plan(수정/생성 파일), Data Model, API, UI, Acceptance Criteria, Implementation Tasks만 담습니다.
  
  참고
  - 방법론은 유지하되, 기본값을 Lite로 낮춰서 CRUD에 과하지 않게 적용했습니다. 필요할 때만 `--mode standard` 또는 `--mode advanced`로 확장하세요.
  - 참고: BMAD-METHOD 원칙은 유지하되, 문서의 깊이만 모드에 따라 조절했습니다. [BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)
  
  Done:
  - `pm.md`에 모드와 플래그 반영
  - CRUD용 `spec-template.lite.md`, `spec-checklist.lite.md` 추가
  - `.cursor/README.md`에 모드 설명과 예시 추가
  
  요약
  - 기본 CRUD에는 Lite 모드만으로 충분합니다.
  - 필요 시 플래그로 언제든 상세 문서화로 확장 가능합니다.

그랬더니 기본 모드에 라이트 모드를 추가해 줬습니다...

라이트 모드를 따로 두지 말고 지금 스펙 전체를 라이트하게 바꿔줘.

// 질문 라이트 모드를 따로 두지 말고 지금 스펙 전체를 라이트하게 바꿔줘.

// AI 결과물
좋아요. 별도의 라이트 모드 없이 전체 스펙 시스템을 경량화했습니다.

  What I changed
  - `spec-template.md`: 라이트 버전으로 완전히 교체. 핵심만 유지(요약, 목표, 간단 플랜, 데이터 모델, API 표, UI 개요, AC, 구현 태스크, 노트).
  - `spec-checklist.md`: 라이트 체크리스트로 완전히 교체. CRUD 필수 항목만 빠르게 점검.
  - `pm.md`: 모드 관련 섹션/플래그 제거. PRD는 선택, 간결한 스펙/체크리스트만 사용하도록 명문화. 커맨드도 단순화.
  - `.cursor/README.md`: 모드 섹션 제거, 템플릿/체크리스트 라이트 기준으로 설명 및 커맨드 표기 단순화.
  - 정리: `spec-template.lite.md`, `spec-checklist.lite.md` 파일 삭제.
  
  How to use now
  - 스펙 생성: `*create-spec user-crud`
  - 검증: `*validate-docs`
  - 필요하면 PRD는 선택적으로 생성: `*create-prd users`
  
  Impact
  - 문서 작성/검증 시간이 크게 줄어듭니다.
  - CRUD 중심 과제에 필요한 최소 정보만 유지합니다.
  - 필요 시 언제든 확장 가능하지만 기본은 심플하게 갑니다.

이렇게 이전 버전에서 라이트하게 수정했음에도 여전히 불필요한 기능이 많다고 느꼈습니다.
그래서 프로젝트의 실제 스펙을 먼저 명확히 제시하고, 그에 맞게 프롬프트를 새로 설계해 달라고 요청했습니다.
PM의 역할도 초반 PRD생성, Architecture 문서 생서, 이슈 생성 -> 요구사항을 입력받아 이슈문서만 생성하게 수정했습니다.

이 경험을 통해, AI에게 광범위한 결과물을 요청하기보다 범위를 좁혀 명확히 지시할수록 결과의 품질이 높아진다는 점을 확인했습니다. 즉, “전체 PM을 만들어줘”보다는 “프로젝트 범위는 CRUD 수준이며, TDD 프로세스를 지원하는 PM 프롬프트를 최소 기능으로 설계해줘”처럼 작고 구체적인 단위로 요청하는 방식이 더 효과적이었던 것 같습니다.

AI가 잘하는 것과 못하는 것에 대해 고민한 적이 있나요? 내가 생각하는 지점에 대해 작성해주세요.

AI는 주어진 정보와 명령을 기반으로 결과를 생성하기 때문에, 인간만큼의 맥락과 경험을 반영한 결과물을 내기는 어렵습니다. 이로 인해 문제 해결 시 전체적인 범위를 고려하지 못한 솔루션을 제시하기도 합니다.

AI의 정확도는 사람이 얼마나 명확하고 일관된 정보를 제공하느냐에 따라 달라지는 것 같습니다. 그러나 인간 수준의 맥락 이해를 위해서는 매우 정교한 정보와 지시가 필요하므로, AI가 그 수준에 도달하기는 아직 어려운 영역이라고 생각합니다.

하지만 이렇게 큰 맥락을 이해하지 않아도 되는 부분에서는 AI사용의 이점이 크다 느낍니다. 단순작업이라던가 제가 잘 모르는 분야에서 어떤일을 해야할때와 같이 좁은 범위의 업무(문서 작업, 기본 틀을 만드는 작업 등)에는 확실히 AI를 사용하는게 좋은 것 같습니다.

마지막으로 느낀점에 대해 적어주세요!

AI를 한주동안 꽤 딥하게 사용해 볼 수 있었습니다. AI를 활용하는 방법에 대해 나름의 기준이 생길 수 있었던 시간이었습니다.

---

과제 셀프회고

AI를 적극적으로 쓰지 못했는데 이번 과제를 통해서 AI를 꽤나 딥하게 써볼 수 있어서 좋았습니다. 프롬프트를 만든경험도 없었고, 결제하고 있는 AI도 없었는데 이번 기회에 AI에 대한 허들을 낮출수 있었습니다. 이번 과제에서는 cursor를 사용했는데 다음엔 claud를 결제해서 이용해볼까 싶기도 합니다. 프롬프트를 설계하는게 꽤 재미있었는데 추후에는 회사에서도 사용할수 있는 프롬프트도 설계를 해보고 싶습니다. 이번한주 동안 AI를 계속 사용해보면서 AI가 완전 만능은 아니지만 작업에 효율에는 확실히 도움이 됨을 느꼈습니다. AI에 대한 이점과 한계를 체감할 수 있던 시간이었던 것 같습니다.

기술적 성장

새로 학습한 개념
프롬프트를 작성하는 방법에 대해 여러 방법을 시도해보면서 프롬프트 작성법, 어떻게 해야 말을 듣는 프롬프트를 작성할 수 있는지에 대해 체득할 수 있었습니다. 프롬프트 작성시 초반에 설계를 잘하면 그걸 기반으로 다른 에이전트들을 나름 일관되게 만들수 있는것 같습니다.

(1)프롬프트 작성시엔 명확한 기준을 가지고 input, output 정의가 필요하다
초반 과정에서 학습자료를 제대로 확인을 못하고 진행했는데 학습자료에 명확한 input과 output을 먼저 정의하고 프롬프트를 개발하라도 되어있었던걸 뒤늦게 확인했습니다... 그냥 AI한테 pm프롬프트를 만들어줘!라 해서 나온 결과물들을 제 기준으로 어떻게 판단해야 할지 고민이었는데 애초에 설계시부터 명확한 결과를 예상하고 계획을 짜야 했다는걸 알게 되었습니다.

(2)AI의 결과물은 내가 제대로 파악할 수 있어야 한다. 너무 많은 결과물을 확인해야한다면 좀더 단순화하는게 좋을것 같다
AI의 결과물중 제대로 관리되지 않는게 있다면 이게 추후에 어떤 사이드이펙트를 일으킬지 모르기 때문에 큰 단위의 결과물을 일단 도출해내고 추후에 정리하는 것보다는 작은 단위의 결과물을 계속해서 디벨롭해 나가는데 정확도를 올릴수 있는것 같습니다. 제가 만든 워크플로우에서 이전 단계에서 나온 AI 결과물들을 다음 단계 AI가 참고하다보니 AI 가 도출해낸 문서들을 사람이 제대로 파악할 수 있어야 중간에 문제가 생긴다고 해도 문제를 빠르게 발견할 수 있는것 같습니다. 그래서 제 작업에서는 AI가 하나의 문서를 계속 참고하게 했는데, 이건 AI가 만든 결과물을 확인해야할 사람을 위한것이기도 했습니다.

(3)프롬프트 관리를 잘 하자
AI 프롬프트를 작업하면서 pm 기능에 테스트 시나리오를 넣었다가 좀더 명확한 역할을 분리하고 싶어서 pm은 Issue문서에서 목적, 요구사항, 맥락&범위만 수정할수 있게 프롬프트를 수정했었습니다. 그런데 orchastration 에서는 pm이 AC및 테스트 시나리오를 생성하는걸로 작성되어있었어서 결과가 일정하게 나오지 않는 경험을 했었습니다. 이때 프롬프트 요구사항에 대해 일관되게 관리되는게 정말 중요하구나 싶었던 것 같습니다.

코드 품질

리팩토링이 필요한 부분
이번 과제에서 프롬프트 설계에 시간을 많이 쓰면서 ai가 작성한 코드 퀄리티에 대해선 많이 신경을 못쓴것 같아 아쉬움이 있습니다. 더 나은 코드를 작성하게 위해 지시해야할 프롬프트가 어떤것들이 있을지에 대해 더 고민이 필요한것 같습니다.

지금 AI가 작성한 코드를 보면 좀더 효율적인 방식이 있어서 수정을 요청했어야 하는데, 일단 시간이 부족해서 넘어간 순간들이 많았습니다. 이 부분들을 다시 개선시켜보면 좋을 것 같습니다.

학습 효과 분석

가장 큰 배움이 있었던 부분
AI 사용에 대한 제 생각이 바뀐게 큰 배움이었습니다. 실무에서 AI를 많이 사용하지 않고 작업을 했었는데 AI를 이용한 개발의 한계, 이점등에 대해 체감해볼 수 있는 시간이었던 것 같습니다.

추가 학습이 필요한 영역
좀더 정교한 프롬프트 기법들에 대해 학습이 필요할 것 같습니다. 프롬프트에 동일한 input을 넣으면 항상 동일한 output을 내는것이 안정성이 높은 AI프롬프트라 생각이 되는데, 제가 작성한 프롬프트에서는 같은 input을 넣어도 조금씩 다르게 결과가 나오는 것 같습니다...

다른 기업들에서 AI들을 업무에 어떻게 이용하고 있는지 저희 회사에서도 적용할 수 있는 방법이 있는지에 대해 공부하고 싶습니다.

실무 적용 가능성
저희 회사에서는 아직 AI를 공격적으로 사용하고 있지는 않습니다. 이번 과제를 하면서 일관되게 잘 정리된 문서의 중요성을 깊게 느꼈던 것 같습니다. 추후에 AI 사용을 생각한다면 지금 일관적이게 관리되지 않는 문서를 어떻게 잘 정리해둘까라는 생각이 많이 들었습니다. 이것또한 AI를 이용해서 일관된 포맷으로 정리를 할수 있지 않을까 싶습니다.

저희 회사에서 업무를 할때 기획자는 있는데 pm이 부재한 느낌을 많이 받습니다. 어쩌면 이걸 AI를 이용해서 어쩌면 해결할 수도 있지 않을까라는 생각이 듭니다. (요구사항을 정리해서 기입하면 지라의 이슈를 생성해주는(?))

과제 피드백

과제에서 좋았던 부분
프롬프트 설계를 경험할 수 있었다는 점이 좋았습니다. 일주일이라는 짧은 시간 꽤 딥하게 AI를 써볼 수 있었습니다. 이번 과제를 통해서 AI에 대한 시각이 좀더 달라졌음을 느낍니다.

리뷰 받고 싶은 내용

1. 오케스트레이션 에이전트 문서에 꼭 해야한다고 명시해둔 일들도 기능 4개를 만들때쯤 되면 스스로 스킵하고 넘어가는 일이 많은 것 같습니다.
   (커밋을 할때는 허락받고 하기, 체크리스트를 검토하고 검토내용 알려주기등...) 제가 작성한 프롬프트에서 어떤 부분이 잘못되어있는지 AI에게 질문을 해서 알수 있는 방법이 있을까요?

2. 저는 체크리스트 방식으로 각 단계별 검토를 하게 만들었는데, 혹시 AI 결과물에 대해 검토를 하는 더 좋은 방식이 있을까요? 검토를 위해서는 좋은 결과물에 대한 명확한 기준을 잡는게 중요한거겠죠..?

3. 프롬프트를 돌릴때 동일한 input에 일관된 output을 내게하기 위해서는 어떤부분을 주의해서 짜면 좋을까요? 현재는 template을 제공해도 template의 하위부분을 갑자기 다른 방식으로 작성하기도 하더라고요...

이슈 1,2,3에서 테스트 코드 작성 에이전트가 작업한 방식

### 💻 코드 작성 에이전트 (Implementation)

• Inputs: 실패 테스트
• Actions: 최소 구현(Green)
• Outputs: 변경 파일/주요 변경 요약
• Artifacts: 소스 코드 경로
  • Inputs:
    • 실패 테스트: TC-01, TC-02, TC-03 실패 (반복 종료일 필드가 반복 유형 선택 시에만 표시되어야 함)
    • 기존 코드: App.tsx의 반복 종료일 필드가 isRepeating만 체크하고 있음
  • Actions:
    • 반복 종료일 필드 조건 수정: repeatType !== 'none' 조건 추가
    • FormLabel과 TextField 연결: htmlFor와 id 속성 추가
    • aria-label 제거: 중복 라벨 문제 해결
    • 테스트 실행 및 검증: 모든 테스트 통과 확인
  • Outputs:
    • 변경 파일: src/App.tsx (470-481줄)
    • 주요 변경사항:
      • 반복 종료일 필드를 repeatType !== 'none' 조건으로 감싸서 반복 유형 선택 시에만 표시
      • FormLabel과 TextField 연결을 위한 htmlFor/id 속성 추가
      • aria-label 제거하여 중복 라벨 문제 해결
    • 테스트 실행 결과: 4개 테스트 모두 통과 (TC-01 ~ TC-04)
  • Artifacts: src/App.tsx

이슈4에서 코드 작성 에이전트가 작업 요약을 작성한 방식

### 💻 코드 작성 에이전트 (Implementation)

• Inputs: 실패 테스트

• Actions: 최소 구현(Green)

• Outputs: 변경 파일/주요 변경 요약

• Artifacts: 소스 코드 경로

  작업 일시: 2025-01-XX

  Inputs:

  • 실패 테스트: Unit 테스트 5개, Integration 테스트 1개 (총 6개 실패)
  • 테스트 파일: src/__tests__/unit/easy.generateRecurringEvents.spec.ts, src/__tests__/medium.integration.spec.tsx

  Actions:

  1. src/utils/eventUtils.ts에 generateRecurringEvents 함수 구현
     • 반복 유형(daily/weekly/monthly/yearly)에 따라 종료일까지 일정 생성
     • formatDate 유틸 함수 활용
  2. src/hooks/useEventOperations.ts 수정
     • 반복 일정인 경우 generateRecurringEvents 호출하여 여러 일정 생성
     • 생성된 일정들을 /api/events-list 엔드포인트로 전송
  3. src/__mocks__/handlersUtils.ts 수정
     • setupMockHandlerCreation에 /api/events-list 핸들러 추가
  4. src/__tests__/medium.integration.spec.tsx 수정
     • TC-03 테스트 수정 (반복 일정이 여러 개 생성되는 경우 처리)

  Outputs:

  • 변경 파일:
    • src/utils/eventUtils.ts (+46 lines)
    • src/hooks/useEventOperations.ts (+20 lines)
    • src/__mocks__/handlersUtils.ts (+12 lines)
    • src/__tests__/medium.integration.spec.tsx (+5 lines, -2 lines)

  주요 변경 요약:

  • generateRecurringEvents: 반복 일정 생성 로직 구현 (매일/매주/매월/매년 지원)
  • useEventOperations.saveEvent: 반복 일정인 경우 여러 일정 생성 후 /api/events-list 호출
  • Mock 핸들러에 /api/events-list 지원 추가
  • TC-03 테스트: getAllByText 사용하여 여러 일정 처리

  Artifacts:

  • src/utils/eventUtils.ts (generateRecurringEvents 함수)
  • src/hooks/useEventOperations.ts (saveEvent 함수)
  • src/__mocks__/handlersUtils.ts (setupMockHandlerCreation 함수)

  테스트 결과: ✅ 모든 테스트 통과 (137개)

[totter15]

#6