KAIzen — AI 시대에 애자일이 필요로 하는 것

Source: Dev.to

How a small team at a gaming company went from 32 % flow efficiency to 85 % — by changing what we gave the AI

우리 팀은 Scrum을 교과서대로 진행하고 있었습니다: 2주 스프린트, 그루밍, 플래닝 포커, 회고. 모든 전통적인 기준에 따르면 우리는 애자일을 제대로 수행하고 있었습니다.

그런데 플로우 효율성—활동 작업 시간과 전체 경과 시간의 비율—을 측정해 보니 **32 %**에 불과했습니다. 시계가 1시간 흐를 때 실제로 작업에 투입되는 시간은 약 19분에 불과했고, 나머지는 그루밍, 명확화, 리뷰, 스토리 의미에 대한 정렬 등을 기다리는 시간이었습니다.

소프트웨어 팀의 업계 평균은 15‑25 %.
우리는 평균보다 높았지만, “시간 낭비가 평균보다 높다”는 지표는 누구도 슬라이드에 올리지 않습니다.

상황을 더욱 악화시킨 것은 우리가 AI 코딩 어시스턴트를 사용하기 시작했기 때문입니다. 약속은 더 빠른 납품이었지만, 실제로는 코드 생성이 빨라졌을 뿐이었습니다—입력이 모호하면 코드가 자주 틀렸습니다. “사용자로서 보상을 받아 가치를 느끼고 싶다”라는 사용자 스토리는 사람에게는 충분한 맥락을 제공해 똑똑한 질문을 할 수 있게 하지만, AI에게는 자신 있게 환상을 만들어낼 충분한 맥락을 제공합니다.

AI는 단순히 코딩 속도를 높인 것이 아니라 병목 현상을 옮겼습니다.
이전 병목은 *“우리가 코드를 얼마나 빨리 작성할 수 있느냐?”*였지만, 이제는 *“우리가 원하는 것을 얼마나 정확히 정의할 수 있느냐?”*가 되었습니다. 우리의 전체 프로세스는 인간이 병목인 세상에 맞춰 최적화돼 있었는데, 그 세상은 사라졌습니다.

솔직히 말하자면, 그때 나는 KAIzen이라고 부르지는 않았습니다. 아직 이름이 없었고, 단지 작업 방식을 바꾸기 시작했을 뿐이었습니다. 이 글에서 사용하는 Blueprint, Runbook 같은 용어는 나중에 패턴을 공유하기 위해 만든 것입니다. 작업 자체는 실제였고, 이름 붙이는 것은 사후 생각에 불과합니다.

영감 — 그리고 왜 나는 다른 것이 필요했는가

나는 제로에서 시작한 것이 아니다. Amazon의 AI‑DLC(AI‑Driven Development Lifecycle)는 큰 영감이었다. AWS는 사양‑주도, AI‑보강 개발이 규모에 맞게 작동할 수 있음을 보여주었다. 하지만 이를 우리 팀에 적용해 보니 비용이 높았다: AI‑DLC는 전체 개발 프로세스를 대체한다 – 새로운 단계, 새로운 역할, 새로운 산출물, 근본부터 완전히 새로운 작업 방식이 필요하다.

우리는 그런 사치를 누릴 수 없었다. 우리는 스프린트 중간, 분기 중간, 전달 중간에 있었다. 나는 기존 프로세스에 끼워 넣을 수 있는 무언가가 필요했다 – 대체가 아니라. AI‑DLC가 모든 것을 바꾸라고 요구하는 반면, 나는 한 가지만 바꾸고 싶었다: AI에 제공하는 입력의 품질을. 스프린트를 유지하고, 보드를 유지하고, 그 위에 한 층을 추가하는 것이다.

나는 이제 이 접근 방식을 KAIzen이라고 부른다. 카이젠(改善)이라는 지속적 개선의 일본 철학에서 따온 이름이다. 작은 변화를, 일을 수행하는 사람들이 주도하도록 한다. KAIzen은 AI를 지렛대로 삼아 그 원칙을 적용한다. 새로운 방법론이 아니다. 프로세스 전면 개편도 아니다. 이미 운영 중인 애자일 프로세스 위에 추가하는 한 층이다.

주요 레버로서의 사양

전환점은 작았습니다. 사용자 스토리를 작성하는 대신, 기능에 대한 상세 엔지니어링 사양(입력, 출력, 엣지 케이스, 제약 조건, 수용 기준)을 작성했습니다. 이를 AI 어시스턴트에 입력했더니, 생성된 코드는 첫 번째 시도부터 리뷰 준비가 된 상태였습니다.

이전 기능—비슷한 복잡도에 사용자 스토리로 설명된—은 리뷰 3라운드, Slack 스레드 2개, 동기화 회의 1회를 거쳐야 했습니다. 같은 AI, 같은 팀. 차이는 전적으로 입력에 있었습니다.

사양이 바로 제품이다. 코드가 아니다. 사양의 품질이 뒤따르는 모든 것의 품질을 결정한다.

저는 이를 Blueprint라 부릅니다—AI가 기반으로 작업할 수 있을 만큼 정밀한 구조화된 사양. 복잡한 작업의 경우 Runbook도 필요합니다—Blueprint에서 파생된 순차적인 구현 계획. 작은 수정이라면 가벼운 Blueprint만으로 충분합니다.

Blueprint를 만드는 방법

1. Feature brief – 제품 소유자가 목표, 컨텍스트, 사용자 요구를 제공한다.
2. SpecKit – 우리 맞춤형 GitHub Copilot 에이전트가 Blueprint(입력, 출력, 엣지 케이스, 제약 조건, 수용 기준)를 초안한다.
3. Review & refine – 개발자가 실제 시간을 들여(복잡한 기능의 경우 종종 2시간까지) 초안을 다듬는다.

초안 자체가 최종 산출물이 아니라 검토된 Blueprint가 산출물입니다. 이 투자가 핵심입니다. 정밀한 Blueprint는 Runbook을 일관되게 만들고, AI가 생성한 코드를 바로 리뷰할 수 있게 합니다. 에이전트는 빈 페이지 문제를 해결하고 전체 작업의 ~70 %를 수행해 주며, 개발자의 판단이 나머지 30 %를 완성합니다—그곳에 품질이 자리합니다.

시간이 지나면서 예상치 못한 일이 일어났습니다: 우리 제품 소유자가 동일한 에이전트를 사용해 Feature brief 자체를 작성하기 시작했고, 이를 구조화해 하위 Blueprint가 더 깔끔해지도록 했습니다. 전체 흐름이 더욱 견고해졌습니다:

더 나은 brief → 더 나은 Blueprint → 더 나은 Runbook → 더 나은 AI‑생성 코드 → 리뷰 사이클 감소.

에이전트는 개발자를 도와줄 뿐만 아니라, 팀 전체를 정밀함을 향해 끌어당겼습니다.

사라진 것들

AI‑DLC 접근법과의 핵심 차이점은 우리가 시작하기 위해 누구의 허가도 필요하지 않았다는 것이다. 프로세스 전면 개편도, 새로운 역할도, 조직 전체의 동의도 없었다. 한 팀, 하나의 Blueprint, 하나의 스프린트. 이 레이어는 제안서가 아니라 결과를 통해 스스로 입증했다.

The Numbers

세 개의 에픽, 동일한 영역, 비슷한 복잡도 – 그리고 개선 효과는 스스로 말해줍니다.

활동 작업 시간은 거의 변하지 않았습니다. 사라진 것은 대기 시간—그루밍, 명확화, 정렬 오버헤드로, 스프린트 속도 안에서는 보이지 않았던 부분입니다.

주의 사항: 세 개의 에픽은 증거가 아니라 신호입니다. 범위가 동일하지 않았습니다. 팀은 작았고 저는 직접 코칭했습니다. 제가 직접 이 주의 사항을 말씀드리는 것이 좋겠습니다. 세 개의 데이터 포인트는 증거가 아니라, 조사할 가치가 있는 신호입니다.

내가 배운 것

• Blueprint는 새로운 병목 현상이지만, 더 나은 병목 현상이다.
  SpecKit이 첫 번째 초안을 작성하면서 빈 페이지 문제는 사라졌습니다. 검토에는 여전히 실제 시간이 필요하고, 그래야 합니다—그곳이 엔지니어링 판단이 살아 있는 자리이기 때문입니다. 개발자의 업무는 “스펙을 처음부터 작성한다” 에서 “스펙을 검증하고 다듬는다” 로 바뀌며, 이는 그들의 전문성을 더 잘 활용하는 방식입니다.

• 모두가 스펙을 작성하고 싶어 하는 것은 아니다.
  한 번의 시연만으로 저항은 사라집니다. 모호한 스토리에서 나온 AI 출력과 좋은 Blueprint에서 나온 AI 출력을 나란히 보여 주세요. 그 후 대부분의 사람들은 프로세스 논쟁 때문이 아니라, 오후 업무가 더 쉬워지기 때문에 스펙을 작성합니다.

• 이것이 카이젠—지속적인 개선, 근본부터.
  우리는 한 가지를 바꾸고, 발생한 일을 측정하고, 계속해서 개선했습니다.

• 단일 팀의 한계.
  우리 영역 내에서 흐름 효율성이 **85 %**에 도달했습니다. 그때 Gaming, Rewards, Sportsbook을 아우르는 이니셔티브가 등장했고, 갑자기 우리의 속도는 의미가 없어졌습니다. 우리는 다른 팀의 API에 막히고, Slack에서 이벤트 스키마를 두고 논쟁하며, 여섯 명이 DM으로 두 사람이 결정할 수 있었던 일을 논의하는 정렬 회의에 앉아 있었습니다.

한 팀이 개선한다 해도 기능이 경계에서 멈춘다면 아무 의미가 없습니다. 이것이 Part 2입니다.

Part 2: “KAIzen Across Boundaries” — 다음 주에 공개.

오늘 바로 시도해 보고 싶나요?

1. 다음 기능을 선택합니다.
2. 제품 브리프를 AI 어시스턴트에 입력하고, 스펙(입력, 출력, 엣지 케이스, 제약 조건, 수용 기준)을 생성하도록 요청합니다.
3. 스펙을 다듬습니다.
4. 그 스펙을 기준으로 개발합니다.
5. 전후의 흐름 효율성을 측정합니다.

한 개의 스펙. 어떤 일이 일어나는지 확인해 보세요.

#ai #agile #softwareengineering #productivity