도입하지 않은 「하류 공정 개선 에이전트」를 통해 배운 점

개발의 하류 공정(Downstream Process), 즉

구현(Implementation) → 테스트(Test) → 리뷰(Review) → 수정(Fix)

에는 개인이나 팀별로 많은 암묵지(Tacit Knowledge)가 포함되어 있습니다.

이번에 팀을 대상으로 해당 하류 공정을 표준화하기 위해, Cursor의 Slash Command / Skill을 사용한 독자적인 플로우(Flow)를 시제품으로 제작했습니다.

최종적으로 이 독자적인 플로우는 도입하지 않았습니다. 이유는 다른 팀이 이미 이용하고 있는 cc-sdd (Kiro)와의 통일성을 우선시했기 때문입니다.

다만, 시제품 제작을 통해 얻은 지견(Insight)이 많았기에 기록으로 남겨둡니다.

당초의 과제는 AI에게 구현을 맡길 때 진행 방식이 개인의 역량에 의존(Personalized)하기 쉽다는 점이었습니다.

예를 들어, 다음과 같은 문제가 있습니다.

• 사양서(Specification)를 읽은 후, 어디까지 코드 조사를 해야 할지가 모호함
• 구현 전에 사람이 판단해야 할 결정 사항(Decision)이 남은 채로 진행됨
• 중단(STOP)했을 때, 다음에 무엇을 해야 할지 알기 어려움
• 리뷰의 품질이나 관점이 사람마다 다름

그래서 하류 공정을 상태 관리(State Management)가 포함된 플로우로 제어하는 메커니즘을 시제품으로 제작했습니다.

시제품에서는 다음과 같은 플로우를 구축했습니다.

/run
↓ explore-spec
↓ arch-impact
...

중심에 둔 것은 agent/shop/executor.md 입니다.

이는 AI 에이전트가 다음에 어떤 페이즈(Phase)를 실행해도 되는지를 판단하기 위한 단일 제어 사양(Control Specification)이었습니다.

상태는 다음 파일들로 관리했습니다.

agent/shop/state.json
agent/shop/context.md
agent/shop/progress.md

각각의 역할은 다음과 같습니다.

파일	역할
state.json	현재의 phase, approved 상태, 실행 이력
...

각 스킬(Skill)의 결과물은 다음과 같이 저장하도록 설계했습니다.

artifacts/<JIRA_KEY>/<skill-name>.<N>.md

예를 들어 이번 시제품에서는 다음과 같은 결과물이 생성되었습니다.

artifacts/MENUENG-374/explore-spec.1.md
artifacts/MENUENG-374/arch-impact.2.md
artifacts/MENUENG-374/plan-atomic.3.md
...

explore → plan → implement → review → done

이라는 상태 전이(State Transition)를 명문화함으로써, AI가 멋대로 다음 공정으로 진행하는 것을 방지할 수 있었습니다.

특히,

plan → /approve → implement

라는 흐름을 필수화함으로써, 사람이 계획을 확인하는 타이밍을 만들 수 있었습니다.

plan-atomic에서는 미결 사항을 결정 사항(Decision)으로 출력했습니다.

예:

d1: 병렬화 단위
d2: 임계값(Threshold) 배치 위치

이를 통해,

구현하면서 대충 결정하는

것이 아니라,

구현 전에 사람이 선택하는

형태로 만들 수 있었습니다.

나중에 /approve에 Decision 확정 게이트를 추가하여, 미결 사항이 남아 있는 경우에는 채팅상에서 질문하여 해결하는 운용 방식도 시도했습니다.

/review의 결과를 채팅만으로 끝내지 않고, review-sync의 결과물로서 저장했습니다.

리뷰 결과물에는 다음을 포함했습니다.

• security_check
• rule_proposals
• spec_diff
• code_review

이를 통해,

• 리뷰 관점
• 사양과의 차이(Diff)
• 수정 필요 여부

를 나중에 추적할 수 있게 되었습니다.

한편, 다음과 같은 학습 비용(Learning Cost)도 발생합니다.

• /run
• /approve
• /implement
• /review

의 의미를 외울 필요가 있음

나아가,

state.json context.md progress.md

의 역할도 이해해야 합니다.

또한,

• STOP 했을 때의 복구 방법
• 다른 팀과의 운용 차이

도 배워야 합니다.

이 시점에서,

우리 팀만 별도의 플로우를 갖는 것이 정말 좋은 것인가

를 재검토하게 되었습니다.

이번 시제품에서는 실행 로그를 정성스럽게 남기기 위해 많은 결과물을 생성했습니다.

이는 추적 가능성(Traceability) 측면에서는 유효합니다.

하지만 실제 이용자 관점에서는 알고 싶은 것은 훨씬 더 단순합니다.

1. 사양(Specification) 입력
2. 계획 확인
3. 구현
...

이 정도 수준의 조작감만으로 충분하다면, 그 편이 더 사용하기 쉽다고 느꼈습니다.

최종적으로는 독자적인 점포 팀용 Slash Command를 도입하지 않기로 결정했습니다.

이유는 간단합니다.

리포지토리(Repository)에는 이미 cc-sdd (Kiro)의 표준 플로우(Flow)가 존재했기 때문입니다.

Kiro에는 다음과 같은 표준 커맨드(Command)가 있습니다.

/kiro/spec-init /
kiro/spec-requirements
/kiro/spec-design
...

PM의 사양서를 requirements.md에 반영하고 이 표준 플로우에 태운다면, 다른 팀과 동일한 방식으로 진행할 수 있습니다.

즉, 점포 팀만이 독자적인

/run /approve

를 가질 필요는 없었습니다.

도입하지는 않았지만, 이번 시제품 제작에는 큰 의미가 있었습니다.

특히 다음과 같은 사고방식은 앞으로도 활용할 수 있다고 느꼈습니다.

• 구현 전에 결정 사항(Decision)을 명시할 것
• 리뷰(Review) 결과를 채팅만으로 끝내지 말 것
• 중단(STOP) 시에는 반드시 다음 정보를 남길 것
  • 이유
  • 확인 파일
  • 수정 항목
  • 다음에 실행할 커맨드
• 암묵지(Tacit Knowledge)는 독자적인 커맨드가 아니라 Kiro의 Steering / Rules에 축적할 것

독자 커맨드로 채택하지는 않았지만, 사고방식 그 자체는 Kiro 운용에 흡수할 수 있습니다.

이번에 만든 「하류 공정 개선 에이전트」는 최종적으로 도입하지 않았습니다.

하지만 시제품 제작을 통해,

AI에게 맡기는 공정에서 무엇을 고정해야 하는가

가 상당히 명확해졌습니다.

특히 중요했던 것은 커맨드 그 자체가 아니라, 다음과 같은 사고방식입니다.

• 상태(State)를 가질 것
• 페이즈(Phase)를 나눌 것
• 인간의 승인점(Approval Point)을 만들 것
• 판단을 구현 전에 확정할 것
• 팀 전체가 동일한 운용 방식으로 맞출 것

독자화함으로써 편리해지는 부분도 있지만, 팀 전체가 사용하는 메커니즘에서는

통일성과 온보딩(Onboarding)의 용이성

도 그만큼 중요합니다.