AI 에이전트 팀으로 개발 업무 자동화(daily-todo-workflow 설계기)

시작하기 전에: 이 글의 목적

이 글은 Claude Code의 커스텀 스킬 기능을 활용하여 개발자의 일상적인 반복 업무를 AI 에이전트 팀이 자동으로 처리하도록 설계한 daily-todo-workflow의 탄생 배경, 핵심 아키텍처, 그리고 실제 운용 과정에서 마주한 문제를 v2로 어떻게 해결했는지에 대해 기록한 글이다.

단순한 스크립트 자동화 이야기가 아니다. 이것은 AI가 기존 개발 방식의 협업 구조를 어떻게 재해석할 수 있는가에 대한 구조적 실험의 기록이다.

---

1. 왜 만들었는가

반복되는 컨텍스트 전환

개발자의 하루는 흔히 TODO 목록 작성으로 시작된다. (데일리 스프린트를 한다거나..)

그러나 그 TODO를 실제 개발로 연결하기까지의 과정은 생각보다 번거롭다. 매일 아침 다음과 같은 작업이 반복된다.

1. 오늘 처리할 작업을 머릿속에서 정리하여 TODO로 작성한다
2. 각 항목이 Jira에 이미 등록된 이슈인지 검색한다
3. 등록된 이슈는 상태를 "개발 중"으로 전환한다
4. 미등록 이슈는 새로 생성하고, 담당자를 지정하고, 상태를 전환한다
5. 우선순위를 결정하고 첫 번째 작업에 집중한다

여기서 2번부터 4번까지의 작업은 인지 자원을 소모하면서도 실제 창출하는 가치는 0에 가까운 관리 오버헤드다. 코드를 생각하려는 순간, 브라우저를 열고 Jira에 접속하고 검색창에 키워드를 입력하는 행위 자체가 집중력을 분산시킨다.

 

1인 개발의 한계

또 다른 문제는 실제 개발 단계에 있다. 기능 하나를 구현할 때 다음 질문들이 동시에 제기된다.

• 백엔드 레이어에서 어떤 파일을 수정해야 하는가?
• API 변경이 발생하면 프론트엔드 호출 코드와 어떻게 동기화할 것인가?
• 이 변경이 기존 도메인 모델에 어떤 영향을 미치는가?
• 검증은 어떤 범위까지 수행해야 하는가?

이 질문들에 순서대로 답하며 코드를 작성하는 것은 곧 아키텍처 결정, 구현, 검증을 한 사람이 모두 수행하는 상황을 의미한다. 경험이 많은 개발자라면 익숙한 작업일 수 있지만, 매일 반복되는 문맥 전환 비용은 축적된다.

 

스킬 설계의 출발점

이 두 가지 문제 의식에서 daily-todo-workflow의 설계가 시작되었다. 목표는 단순했다.

"TODO List를 전달하면 Jira 연동부터 개발, 검증, 커밋까지 AI가 처리하게 하자."

그러나 이 단순한 목표 뒤에는 하나의 중요한 아이디어가 있었다. AI를 단일 어시스턴트로 사용하는 것이 아니라, 역할이 분리된 팀으로 운영하자는 것이다.

 

2. 핵심 아키텍처: AI 에이전트 팀의 구조

2.1 조직 모델: CTO + 역할 전문가팀

daily-todo-workflow의 가장 핵심적인 설계 결정은 AI를 계층적 조직 모델로 운영한다는 것이다.

┌────────────────────────────────────────────────┐
│  CTO (Opus 모델)                                │
│  - 작업 전체를 분석하고 실행 계획을 수립한다             │
│  - 역할별 작업 지시서를 작성한다                      │
│  - QA 실패 시 원인을 분석하고 재지시한다               │
└───────────────────────┬────────────────────────┘
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
    Backend Agent  Frontend Agent  QA Agent
    (Sonnet)       (Sonnet)        (Sonnet)

이 구조를 선택한 이유는 전략적 판단과 실행을 분리하면 각 모델의 강점을 최대한 활용할 수 있기 때문이다.

Opus는 비용이 높지만 복잡한 맥락을 이해하고 전체 시스템에 걸친 의사결정을 내리는 데 탁월하다. 반면, Sonnet은 빠르고 경제적이며 명확한 지시서가 주어진 구체적 구현 작업에서 충분한 성능을 발휘한다. CTO(Opus)가 무엇을 어떻게 할지를 설계하고, 역할 에이전트(Sonnet)가 실제 코드를 작성하는 구조는 비용 대비 품질을 최적화하는 자연스러운 선택이다.

 

2.2 전체 실행 흐름: 6개 Phase

스킬의 전체 흐름은 6개의 Phase로 구성된다.

[Phase 1] TODO 파싱 & Jira 일괄 매핑
    ↓
[Phase 2] 복잡도 자동 분류 & 사용자 확인
    ↓
[Phase 3] CTO 일괄 분석 (Explore + 작업 지시서)
    ↓
    ├─ Simple 경로 → [Solo Agent] ─────────────────┐
    │                                              ↓
    └─ Complex 경로 → [Backend] → [Frontend] → [Docs]
                          (API 계약서 핸드오프)
                                                  ↓
[Phase 4] QA 검증 (최대 3회 피드백 루프)
    ↓
[Phase 5] 커밋 & Jira 완료 & 다음 TODO
    ↓
[Phase 6] 일일 리포트

Phase 1 (Jira 매핑): 개발자가 자연어로 "feat: 라우팅 목록에 필터 추가"라고 쓰면 스킬이 자동으로 Jira를 검색하여 기존 이슈와 매핑하거나, 없으면 새로 생성하고 담당자와 상태를 설정한다.

Phase 2 (복잡도 분류): 4가지 수치 규칙(S1~S4)으로 Simple/Complex를 자동 분류하여 처리 경로를 달리한다.

Phase 3 (CTO 분석): CTO가 전체 코드베이스를 탐색하고 각 작업의 영향 범위를 분석하여 역할별 작업 지시서를 작성한다.

Phase 4 (QA 루프): 실패 원인을 분석하여 담당 에이전트에게 재작업을 지시하는 피드백 루프. 최대 3회 자동 반복.

 

2.3 핵심 메커니즘: API 계약서 핸드오프

가장 정교한 설계 중 하나는 Backend → Frontend 에이전트 간 API 계약서 핸드오프다.

AI 에이전트의 가장 큰 약점 중 하나는 병렬 실행 시 에이전트 간 컨텍스트 단절이다. Backend 에이전트가 API의 파라미터 타입을 String에서 Enum으로 변경했다면, 이 사실을 모르는 Frontend 에이전트는 여전히 문자열로 API를 호출하는 코드를 작성한다. 결과는 QA 실패다.

이를 해결하기 위해 Backend 에이전트는 작업 완료 시 반드시 다음 형식의 API 계약서를 출력하도록 설계되었다.

---API_CONTRACT_START---
endpoints:
- GET /api/routing?status={ENUM:DRAFT|EFFECTIVE}&page={int}
dtoChanges:
- RoutingListResponse: status 필드 String → RoutingStatus Enum
notes: status 값은 반드시 대문자 ENUM 값 사용
---API_CONTRACT_END---

Frontend 에이전트는 이 계약서를 프롬프트 상단에서 필독 섹션으로 받아 시작한다. 계약서 없이는 Frontend 에이전트가 시작될 수 없다. 이것은 소프트웨어 팀에서 백엔드 개발자가 API 명세를 공유한 후 프론트엔드 개발자가 작업을 시작하는 실제 협업 프로세스를 AI 에이전트 간에 그대로 구현한 것이다.

 

3. v1의 문제: 운용하면서 발견한 구조적 비효율

스킬을 실제로 사용하면서 v1의 구조적 문제들을 파악하고 개선하였다.

문제 1: 모든 TODO를 동일하게 처리하는 비효율

v1은 1줄짜리 버튼 색상 수정에도 다음 과정을 강제했다.

Explore Agent 실행 → CTO 분석 → Backend Agent → Frontend Agent → QA Agent

단순한 CSS 토큰 적용이 필요한 작업에 4~5개의 에이전트 실행이 소요되는 것이다. 토큰 소비와 실행 시간 모두 낭비였다.

문제 2: TODO 개별 분석의 반복 오버헤드

TODO가 5개라면 Explore Agent도 5회, CTO 분석도 5회 실행되었다. 이 5개의 작업이 동일한 코드베이스의 연관된 도메인에 있다면, 탐색 결과의 대부분은 중복이다.

문제 3: 에이전트 프롬프트의 컨텍스트 중복 주입

각 서브에이전트의 프롬프트에 50줄짜리 프로젝트 컨텍스트가 반복 삽입되었다. 그러나 Claude Code의 서브에이전트는 이미 CLAUDE.md를 자동으로 로드한다. 에이전트당 수천 토큰의 낭비였다.

문제 4: 중단 후 재시작의 비효율

작업 도중 세션이 끊기거나 오류가 발생하면 처음부터 다시 시작해야 했다. 상태가 저장되지 않아 모든 작업을 재실행해야 하는 상황이 발생했다.

문제 5: 에픽 테이블 하드코딩

Jira 에픽 매핑이 SKILL.md에 하드코딩되어 있어 프로젝트 변경 시 파일을 직접 수정해야 했다.

---

4. v2로의 진화: 핵심 개선 원칙과 구현

이러한 문제들을 분석하면서 v2의 설계 원칙이 도출되었다.

• 적절한 모델을 적절한 작업에

• CLAUDE.md가 이미 존재한다면 재주입하지 말라

• 에이전트 간 상태를 명시적으로 전달하라

• 한 번 한 일은 두 번 하지 말라

 

개선 1: Simple/Complex 경로 자동 분기

v2는 TODO 항목을 4가지 수치 규칙(S1~S4)으로 자동 분류한다.

Simple 조건 (4가지 모두 충족 시):
  S1. 예상 변경 파일 ≤ 3개
  S2. 기존 패턴의 반복 수정 (CSS, 텍스트, CRUD 패턴)
  S3. 엔티티/서비스 신규 메서드 없음
  S4. 다른 TODO와 파일 의존관계 없음

자동 판정 키워드:
  → 항상 Simple: "style:", "chore:", "fix: + UI/CSS/텍스트 관련"
  → 항상 Complex: "feat:", "refactor:", 새 API, 엔티티 변경

Simple로 분류된 작업은 CTO 분석 단계를 거치지 않고 Sonnet 단일 에이전트가 직접 처리한다. 프롬프트도 15줄 이내로 최소화된다.

 

개선 2: TODO 일괄 분석 (Phase 3 재구성)

v1: [TODO#1 Explore] → [TODO#1 CTO] → [TODO#2 Explore] → [TODO#2 CTO] → ...

v2: [TODO 전체 Explore 1회] → [CTO 전체 분석 1회 + 지시서 일괄 작성]
                                          ↓
                               병렬 실행 가능 그룹 결정
                               → 독립적 TODO는 동시 실행

CTO는 전체 TODO의 의존관계를 파악한 뒤, 어떤 TODO를 병렬로 실행할 수 있고 어떤 TODO가 순차적이어야 하는지를 한 번에 결정한다.

 

개선 3: 에이전트 프롬프트 최소화

v2의 에이전트 프롬프트는 오직 세 가지만 포함한다.

1. 역할 선언 (1줄)
2. 작업 지시 (CTO 지시서에서 해당 역할 부분만)
3. 완료 조건 (3-5줄)

50줄짜리 프로젝트 컨텍스트 블록은 사라졌다. CLAUDE.md가 자동 로드되므로 불필요하다. 프롬프트 길이가 v1 대비 에이전트당 60~70% 감소했다.

 

개선 4: 타겟 테스트 실행

v1의 QA Agent는 ./gradlew test로 전체 테스트 스위트를 실행했다. v2는 변경 파일 목록에서 도메인 패키지를 추출하여 해당 범위만 테스트한다.

# 변경된 파일
biz.page1.ebr.domain.masterdata.service.RoutingService.java

# 추출된 테스트 범위
./gradlew test --tests "biz.page1.ebr.domain.masterdata.*"

 

개선 5: 세션 재개 가능한 상태 저장

v2는 모든 작업의 진행 상태를 .bkit/state/daily-todo-state.json에 저장한다.

{
  "date": "2026-03-18",
  "todos": [
    { "jira": "EBR-250", "phase": "DONE", "commit": "abc1234" },
    { "jira": "EBR-251", "phase": "BACKEND_DONE", "apiContract": {} },
    { "jira": "EBR-245", "phase": "PENDING" }
  ]
}

세션이 중단된 후 재시작하면 완료된 작업은 건너뛰고 마지막으로 진행 중이던 단계부터 정확히 이어서 실행된다.

 

5. 설계에서 얻은 인사이트

AI 에이전트도 "분업"이 필요하다

단일 AI에게 모든 것을 맡기는 방식과 역할을 분리하는 방식의 차이는 생각보다 크다. 단일 에이전트는 맥락이 길어질수록 앞서 결정한 사항을 잊거나 일관성이 무너지는 경향이 있다. 반면 역할이 명확히 분리된 에이전트들은 각자의 범위에 집중하므로 더 예측 가능한 출력을 만들어낸다.

이것은 소프트웨어 공학의 단일 책임 원칙(Single Responsibility Principle)이 AI 에이전트 설계에도 그대로 적용된다는 것을 보여준다.

에이전트 간 인터페이스를 명시적으로 설계하라

API 계약서 핸드오프 메커니즘에서 얻은 핵심 교훈은 다음과 같다. 에이전트 간 데이터 흐름은 암묵적으로 기대하면 반드시 실패한다. 에이전트는 독립적인 새 세션(컨텍스트 윈도우)에서 실행된다. 이전 에이전트가 무엇을 했는지 알 수 없다.

이것은 마이크로서비스 아키텍처에서 서비스 간 통신을 명시적인 API로 정의하는 것과 동일한 원리다. AI 에이전트 간 '인터페이스'를 명시적으로 설계하는 것은 에이전트 시스템 안정성의 핵심이다.

결정 기준을 수치로 명시화하라

맨처음 적용했던 내용중 v1에서 CTO가 "단독 작업 모드를 선택할 수 있다"는 표현은 비결정적 행동을 만들었다. v2에서는 Simple 분류 조건을 S1~S4라는 체크리스트로 수치화했다. AI 모델의 판단은 확률적이지만, 규칙 체크리스트는 결정적이다. AI의 비결정성을 구조적 규칙으로 제어하는 것이 안정적인 워크플로우의 핵심이다.

AI에게 전달하는 컨텍스트의 질이 양보다 중요하다

프롬프트 설계에서 가장 흔한 실수 중 하나는 "더 많이 알려줄수록 더 잘할 것"이라는 가정이다. 실제로는 관련 없는 정보가 많을수록 AI는 무엇에 집중해야 할지 판단하는 데 자원을 소모한다. v2에서 에이전트 프롬프트를 60% 줄이면서도 출력 품질이 향상된 것은 이 원칙을 실증한 결과다.

 

6. 현재와 앞으로

daily-todo-workflow v2는 현재 실제 프로젝트 개발에 매일 사용되고 있다. TODO 목록을 전달하면 Jira 등록부터 코드 구현, 테스트, 커밋까지 AI 에이전트 팀이 처리하고 일일 리포트를 출력한다.

물론 여전히 해결해야 할 과제가 있다. Simple/Complex 분류의 오분류 케이스, Worktree merge 충돌 시 수동 개입, 복잡한 비즈니스 로직에서의 에이전트 간 컨텍스트 불일치 등은 지속적으로 개선이 필요하다. 

그러나 이 스킬을 만들면서 얻은 가장 중요한 통찰은 기술적인 것이 아니다. 그것은 AI를 사용한다는 것이 어시스턴트를 고용하는 것이 아니라 팀을 조직하는 것과 같다는 인식이다.

팀원에게 일을 맡길 때처럼 역할을 정의하고, 인터페이스를 명확히 하고, 결정 기준을 세우고, 실패 시 재시도 프로세스를 구축하는 것. 그것이 AI 에이전트 시스템을 신뢰할 수 있게 만드는 핵심이다.

 

 

이 스킬은 Claude Code의 커스텀 스킬 기능과 bkit PDCA 프레임워크를 기반으로 구현되었으며, SKILL.md 파일 하나로 전체 워크플로우가 정의된다.