[Tool] Kiro Pipeline - Subagent DAG로 코드 품질 개선 자동화
Kiro의 pipeline.yaml로 evaluate → improve → review 단계를 DAG로 구성하여 코드 품질 개선을 자동화한 경험
배경
코드 리뷰를 AI에게 맡기면 한 번에 “분석 + 수정 + 검증”을 다 하려고 함. 문제는 이게 한 컨텍스트에서 일어나면 자기가 수정한 코드를 자기가 리뷰하는 꼴이 됨. 객관성이 없음.
사람 조직에서도 “작성자 ≠ 리뷰어”가 기본인데, AI도 마찬가지로 단계를 분리해야 품질이 올라감.
Pipeline: Subagent DAG
Kiro의 pipeline.yaml은 여러 subagent를 DAG(Directed Acyclic Graph)로 연결하여 순차/병렬 실행할 수 있는 기능임.
내가 구성한 5단계 파이프라인:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# .kiro/pipeline.yaml
task: "{target} 코드를 분석하고 품질을 개선한다."
mode: blocking
stages:
- name: evaluate
role: kiro_default
prompt_template: |
다음 코드를 분석하고 품질 평가를 수행하라.
평가 항목: 가독성, 버그 가능성, 성능, 보안
결과를 JSON으로 출력: { "score": 0-100, "issues": [...] }
대상: {task}
- name: pre_improve
depends_on: [evaluate]
role: kiro_default
prompt_template: |
improve 전 사전 점검을 수행하라.
- 현재 상태 스냅샷 기록
- 개선 대상 범위 확정
- 진행 가능 여부 판단: { "ready": true/false, "snapshot": "..." }
대상: {task}
- name: improve
depends_on: [pre_improve]
role: kiro_default
prompt_template: |
evaluate 단계의 평가 결과를 기반으로 코드를 개선하라.
- 발견된 이슈를 모두 수정
- 최소한의 변경으로 최대 효과
- 변경 사항을 diff 형태로 출력
대상: {task}
- name: post_improve
depends_on: [improve]
role: kiro_default
prompt_template: |
improve 완료 후 후처리를 수행하라.
- 변경 사항 요약
- 부작용 여부 점검
- 결과: { "changes_summary": "...", "side_effects": [] }
대상: {task}
- name: review
depends_on: [post_improve]
role: kiro_default
prompt_template: |
improve 단계에서 개선된 코드를 리뷰하라.
- 원래 이슈가 해결되었는지 확인
- 새로운 문제가 도입되지 않았는지 검증
- approved: true/false 와 feedback 출력
대상: {task}
각 단계의 역할
1
2
evaluate → pre_improve → improve → post_improve → review
분석 사전점검 수정 후처리 검증
evaluate (분석)
코드를 읽고 점수와 이슈 목록을 JSON으로 출력. 이 단계에서는 절대 수정하지 않음. 순수 분석만.
pre_improve (사전 점검)
수정 전 현재 상태를 스냅샷으로 기록. “이 범위만 건드린다”를 확정. 무분별한 리팩토링 방지.
improve (수정)
evaluate에서 발견된 이슈만 수정. “최소 변경, 최대 효과” 원칙. diff 형태로 출력하여 뭘 바꿨는지 명확히 함.
post_improve (후처리)
변경 사항 요약 + 부작용 점검. “이거 바꿨는데 다른 데 영향 없나?” 확인.
review (검증)
improve 결과를 별도 컨텍스트에서 리뷰. 원래 이슈가 해결됐는지, 새 문제가 생기지 않았는지 판단. approved: false면 피드백과 함께 반려.
왜 5단계인가
3단계(분석→수정→검증)로도 충분할 수 있지만, 실무에서 겪은 문제:
- 수정 범위 폭주: pre_improve 없이 바로 수정하면 “이것도 고치고 저것도 고치고” 하다가 원래 의도와 다른 결과물이 나옴
- 부작용 미감지: post_improve 없이 바로 리뷰하면 “코드 자체는 맞는데 다른 모듈에서 깨짐” 같은 걸 놓침
pre_improve와 post_improve는 가드레일 역할임.
실행
1
kiro pipeline run --target "src/api/routes/pnl.js"
파이프라인이 순차적으로 실행되면서 각 단계의 결과가 다음 단계로 전달됨. mode: blocking이라 모든 단계가 완료될 때까지 대기.
정리
- AI 코드 개선도 “분석 → 수정 → 검증”을 분리해야 품질이 올라감
depends_on으로 실행 순서를 강제하면 단계를 건너뛰는 일이 없음- 각 단계의 출력 형식을 JSON으로 고정하면 다음 단계에서 파싱하기 쉬움
- 사람 조직의 코드 리뷰 프로세스를 AI에게도 동일하게 적용한 것뿐임