2.2 플로우 아이템: 기능, 결함, 위험, 부채

개요 및 동기

플로우 아이템은 플로우 프레임워크의 작업 단위이며, 모든 플로우 아이템은 정확히 네 가지 유형 중 하나에 속한다: 고객에게 전달되는 새로운 비즈니스 가치나 역량인 기능, 사용자나 테스트에 의해 발견된 버그에 대한 품질 수정인 결함, 비즈니스를 보호하는 보안, 규정 준수, 개인정보 보호, 거버넌스 작업인 위험, 그리고 미래의 속도를 가능하게 하는 기술 부채, 아키텍처 개선, 인프라 작업인 부채다. 주제 2.1은 이 네 가지 범주가 속한 프레임워크를 소개했다. 이 주제는 분류 체계 자체를 깊이 다루는데, 이 범주들은 팀이 정직하고 일관되게 자신의 작업을 그것들로 분류할 때만 가치를 전달하기 때문이다.

플로우 아이템의 결정적인 속성은 네 가지 유형에 걸친 배분이 제로섬 게임이라는 것이다: 어떤 주어진 기간에도 고정된 양의 엔지니어링 역량이 존재하며, 기능에 쓰인 모든 시간은 부채, 위험, 혹은 결함 작업에 쓰이지 않은 시간이다. 이것은 소프트웨어 전달에 대한 새로운 사실이 아니다. 모든 엔지니어링 리더는 이미 역량이 유한하다는 것을 안다. 하지만 대부분의 조직은 실제 분할을 볼 일관되고 정직한 방법이 없다. 스프린트 속도는 유형과 무관하게 스토리 포인트를 센다. 소진된 백로그는 그 뒤에 있는 작업이 새로운 결제 흐름이었든 화려하지 않은 석 달간의 보안 개선이었든 동일하게 보인다. 플로우 아이템은 특별히 그 보이지 않는 분할을 눈에 보이게 만들기 위해 존재한다.

대규모 팀에게 이 가시성은 자원 배분 대화의 본질을 바꾼다. 엔지니어링 리더가 “우리는 기술 부채를 위한 시간이 더 필요하다”는 정량화되지 않은 주장을 하는 대신, 플로우 아이템 분류는 지난 분기 역량의 30%를 부채가 소비했다는 실제 수치를 만들어 내며, 이는 비즈니스 이해관계자와 함께 논의되고, 방어되고, 의도적으로 조정될 수 있다. 여러 제품 라인을 동시에 운영하는 엔터프라이즈 조직과 새로운 시민 대면 기능을 레거시 시스템 위험과 저울질하는 정부 기관 모두 “우리는 유지보수에 너무 많은 시간을 쓰고 있다”는 사적이고 비공식적인 느낌보다 이런 종류의 방어 가능하고 정량화된 트레이드오프에 훨씬 더 많이 의존한다.

핵심 원칙

모든 플로우 아이템은 정확히 하나의 유형에 속한다. 혼합되거나 모호한 분류를 허용하는 대신 단일한 분류를 강제하는 것이야말로 이 분류 체계를 집계 보고에 사용할 수 있게 만든다.
배분은 가산적이 아니라 제로섬이다. 기능을 위한 더 많은 역량은 같은 기간 결함, 위험, 부채를 위한 필연적으로 더 적은 역량을 의미한다.
보편적으로 건강한 분포는 없다. 성장 단계에 있는 젊은 제품은 정당하게 기능 쪽으로 치우쳐야 하고, 실제 기술적 위험을 지닌 성숙한 시스템은 정당하게 부채와 위험 작업 쪽으로 치우쳐야 한다.
부채와 위험 작업은 이 규율 없이는 만성적으로 과소 보고된다. 그것은 플로우 아이템 분류가 그것을 드러내도록 강제할 때까지 일반적인 “엔지니어링 작업”에 흡수되어 조용히 일어나는 경향이 있다.
분류 품질이 분류 체계 전체의 가치를 결정한다. 일관성 없이 적용되거나 사후에 게임당한 분류 체계는 정보를 주는 대신 적극적으로 오도하는 수치를 만들어 낸다.

권장 사항

각 유형에 대한 서면 정의를 사용해 접수 시점에 모든 아이템을 분류하라

당신의 특정 맥락에서 무엇이 기능, 결함, 위험, 부채로 집계되는지에 대한 간결하고 서면화된 정의에 합의하고, 모든 새로운 작업이 완료된 후가 아니라 가치 흐름에 진입하는 순간 그 정의에 비추어 분류되도록 요구하라. 사전에 합의된 정의는 작업의 조각이 어떻게 보이게 되었는지에 근거해 소급해서 분류하고 싶은 유혹을 물리치며, 이는 바로 이 주제가 바로 아래서 직접 이름을 붙이는 게임 위험이다.

플로우 분포를 단일 스냅샷이 아니라 추세로 보고하라

단일 기간의 분포는 여러 기간에 걸친 추세보다 적게 말해 준다. 한 아이템 유형 쪽으로의 꾸준한 드리프트, 즉 부채가 분기마다 조용히 줄어드는 동안 기능이 상승하는 것은 어느 단일 기간의 수치보다 훨씬 더 강한 신호이며, 그것은 보통 위기가 된 후가 아니라 되기 전에 이해관계자와 함께 제기할 가치가 있는 패턴이다.

엔지니어링뿐 아니라 비즈니스 이해관계자와 함께 의도적인 목표 분포를 설정하라

제품 및 비즈니스 리더십과 함께, 당신의 특정 가치 흐름의 현재 단계에 무엇이 건강한 분포로 보이는지 결정하고, 기본값으로 드리프트하게 두는 대신 그 목표를 주기적으로 다시 살펴보라. 성장 단계의 젊은 제품과 안정 단계의 성숙한 시스템은 정당하게 다른 건강한 목표를 가지며, 그 목표 자체가 엔지니어링이 조용히 혼자 결정하는 것이 아니라 협상된 비즈니스 결정이어야 한다.

독립적인 증거에 비추어 플로우 아이템 분류를 교차 검증하라

자가 분류에 의존하지 않는 메트릭에 비추어 당신의 플로우 분포를 주기적으로 비교하라: 누락된 결함률(주제 5.1), 기술 부채 측정(주제 4.5), 그리고 취약점 관리 메트릭(주제 6.4). “결함”과 “위험” 플로우 아이템 몫이 정체되거나 줄어드는 동안 결함이나 취약점이 늘어나고 있다면, 그 불일치는 분류가 현실로부터 드리프트했다는 가장 명확하게 이용 가능한 신호다.

특히 기능 공장 패턴을 경계하라

플로우 분포가 부채와 위험 작업이 결코 상징적인 몫 이상으로 올라가지 못한 채 분기마다 기능이 꾸준히 거의 모든 역량을 흡수하고 있다는 것을 보여 줄 때, 그 패턴(때로는 “기능 공장”이라고 불린다)은 보통 시스템이 진정으로 유지보수가 필요 없다는 것이 아니라 부채와 위험이 역량을 굶주리고 있다는 것을 의미한다. 이 패턴은 단기적으로는 편안하고 나중에는 비싼데, 근본적인 누적이 결코 보이지 않았기 때문에 결국 플로우 분포 차트에 아무런 경고 없이 도착하는 품질 또는 보안 위기로 나타난다.

트레이드오프: 장단점

접근법	장점	단점
공식적인 분류 없음 (일반적인 백로그)	절차 오버헤드 없음	부채, 위험, 결함 작업이 보이지 않게 남음; 자원 배분 결정을 방어하기 어려움
네 유형 플로우 아이템 분류	역량 배분을 이해관계자와 함께 눈에 보이고 협상 가능하게 만듦	접수 시점 규율과 유형별 서면 합의된 정의가 필요함
더 세분화된 분류 (많은 하위 유형)	더 많은 진단 세부 사항	더 많은 분류 노력; 이해관계자에게 설명해야 할 더 많은 수치
소급 분류	적용하기 더 쉬움, 사전 절차 변경 없음	게임에 매우 노출됨; 분류가 가장 좋아 보이는 쪽으로 드리프트함

핵심 긴장은 분류 규율 대 절차 오버헤드다. 네 유형 분류 체계는 의도적으로 성기며, 아이템을 분류하는 데 논쟁이 아니라 몇 초가 걸릴 만큼 성기지만, 그 성김은 접수 시점에 서면 정의에 비추어 분류하는 규율이 진정으로 유지될 때만 성립한다. 분류 체계를 정확히 이만큼, 딱 네 유형만 단순하게 유지하고, 실제 업무량 아래서 침식되는 더 정교한 분류 체계 대신 감사 단계(독립적인 증거에 비추어 교차 검증하기)에 추가적인 엄격함을 투자함으로써 이 긴장을 해결하라.

팀과 논의할 질문

지난 분기에 우리 팀이 출시한 모든 것을 분류한다면, 기능, 결함, 위험, 부채에 걸친 실제 분할은 어떻게 보일 것이며, 그것은 우리의 이해관계자를 놀라게 할까? 대부분의 팀은 이 연습을 정직하게 해 본 적이 없다. 이미 답을 안다고 가정하기 전에 실제 데이터로 시도해 보라.
우리는 우리의 특정 맥락에서 무엇이 기능 대 부채 대 위험으로 집계되는지에 대한 서면의, 합의된 정의를 가지고 있는가, 아니면 분류가 티켓에 레이블을 붙이는 사람이 누구인지에 달려 있는가? 비공식적이고 일관성 없는 정의는 정밀해 보이지만 실제로는 기간별로 비교할 수 없는 수치를 만들어 낸다.
아무도 의도적으로 그렇게 결정하지 않았는데 우리의 플로우 분포가 꾸준히 한 아이템 유형 쪽으로 드리프트한 적이 있는가? 느린 드리프트는 기간별로는 놓치기 쉽지만 추세로 그려 보면 명백하다. 데이터가 있다면 여러 기간의 데이터를 가져와 이 패턴을 정직하게 찾아보라.
우리 제품의 현재 단계에 건강한 플로우 분포는 어떻게 보일 것이며, 우리는 실제로 비즈니스 이해관계자와 그 목표에 합의했는가? 대부분의 조직은 이 목표를 명시적으로 만든 적이 없으며, 이는 실제 분포가 그로부터 드리프트할 때 알아챌 공유된 기준이 없다는 것을 의미한다.
우리의 플로우 분포는 누락된 결함률이나 미해결 취약점 개수 같은 독립적인 증거와 일치하는가, 아니면 조사할 가치가 있는 불일치가 있는가? 여기서의 불일치는 분류가 작업이 실제로 무엇인지로부터 드리프트했다는 가장 명확하게 이용 가능한 신호다.
우리 팀의 누군가가 전달 압박 아래서 부채나 위험 아이템을 조용히 기능으로 다시 표시할 수 있으며, 그렇게 한다면 우리는 현재 그것을 알아챌 수 있을까? 이것이 이 주제의 핵심 게임 위험을 직접 서술한 것이다. 당신의 현재 절차가 이것을 실제로 잡아낼 수 있을지, 단지 누군가 의도적으로 그렇게 할지 여부만이 아니라 논의하라.

분야별 관점

스타트업. 전체 팀이 이미 모두가 무엇을 작업하고 있는지 알고 있을 때 공식적인 분류는 흔히 오버헤드처럼 느껴진다. 이 규모에서 유용한 최소한은 단순히 계획하는 동안 네 가지 범주를 소리 내어 말하는 것이며, 이는 기능 마감일이 압박을 만들어 낼 때마다 부채와 위험 작업이 조용히 우선순위에서 밀려나지 않게 한다. 이 패턴은 코드베이스와 팀 모두가 성장하면 나쁘게 복합된다.

중소기업. 기존 추적 도구의 단일한 사용자 정의 필드나 레이블이면 전용 도구 투자 없이도 플로우 아이템 유형을 포착하기에 충분하다. 접수 시점에 일관되게 분류하는 규율이 어떤 도구의 정교함보다 훨씬 더 중요하다.

엔터프라이즈. 플로우 아이템 분류는 이 프레임워크가 규모에서 제 가치를 얻는 곳인데, 많은 동시적인 가치 흐름을 운영하는 대규모 조직은 역량이 기능, 결함, 위험, 부채에 걸쳐 실제로 어떻게 분할되고 있는지 볼 다른 신뢰할 수 있는 집계 방법이 없기 때문이다. 도구 통합된 분류와 독립적인 증거에 비추어 주기적인 교차 검증에 투자하라. 수동적이고 즉흥적인 분류는 실제 조직 규모와의 접촉에서 살아남지 못한다.

정부. 정직한 답이 레거시 시스템의 위험과 부채 부담이 역량의 진정하고 정당화 가능한 몫을 소비하고 있다는 것일 때, 플로우 분포는 공공 부문 기술 리더에게 왜 더 많은 새로운 시민 대면 기능이 출시되지 않는지에 대한 방어 가능하고 정량화된 답을 준다. 그 트레이드오프를 조용히 흡수하는 대신 명시적이고 협상된 것으로 만드는 것은 정량화되지 않은 “기술적 필요성”에 대한 호소보다 감독 기구와 더 많은 신뢰를 쌓는 경향이 있다.

사례

엔터프라이즈. 한 대형 소매 회사의 이커머스 플랫폼 팀은 스프린트 속도에 근거해 자신들이 꾸준한 기능 산출을 전달하고 있다고 믿었다. 첫 번째 정직한 플로우 아이템 분류 연습은 “기능”이 실제로 완료된 작업의 40%에 불과했으며, 상당 부분이 노후화된 결제 시스템과 연결된 부채가 이전의 어떤 보고서에서도 그렇게 이름 붙여진 적 없이 역량의 거의 3분의 1을 소비하고 있다는 것을 발견했다. 부채 부담을 뒷받침하는 상승하는 누락 결함률과 함께 이 분할을 제품 리더십에 제시한 것은 팀이 오직 정성적인 주장만으로 2년 동안 성공하지 못하고 요청해 왔던 전용 현대화 예산을 확보했다.

정부. 한 주 차량국의 디지털 면허 팀은 공개적인 정전이 근본 시스템의 안정성에 정밀 조사를 불러온 후 처음으로 자신의 백로그를 분류했다. 그 연습은 눈에 보이는 시민 대면 기능을 위해 반복적으로 우선순위에서 밀려났던 주로 보안 패치인 “위험” 작업이 이전 해 동안 역량의 5% 미만으로 줄어들었다는 것을 드러냈으며, 이는 팀의 표준 보고에서 결코 보인 적 없는 패턴이었다. 그 기관의 리더십은 일반적인 정책 성명서만이 아니라 플로우 분포 데이터에 의해 뒷받침되는 향후 최소 위험 작업 배분을 의무화하기 위해 그 발견을 사용했다.

비즈니스 사례: 동기, ROI, TCO

플로우 아이템 분류의 수익은 이전에 정성적으로 주장되었고 흔히 이해관계자에게 가장 눈에 띄는 작업에 밀려 패배했던 자원 배분 결정에 대한 방어 가능하고 정량화된 근거다. 위의 소매 사례, 즉 일반적인 호소가 아니라 실제 역량 데이터로 현대화 예산을 확보한 것은 이 규율이 신뢰성 있게 만들어 내는 패턴이다: 구체적인 수치는 “우리는 유지보수를 위한 시간이 더 필요하다”는 일반적인 인상보다 무시하기 훨씬 더 어렵다.

분류 체계와 그 정의가 합의되고 나면 총 소유 비용은 낮다: 분류는 접수에 의미 있는 절차 부담이 아니라 몇 초를 더할 뿐이며, 그것을 추적하는 데 필요한 도구 통합은 보통 단일한 사용자 정의 필드나 레이블이다. 실제로 지속되는 비용은 전달 압박 아래서 정직한 분류를 유지하는 규율이며, 이것이 독립적인 증거에 비추어 주기적인 교차 검증이 초기 도입만큼이나 중요한 이유다.

안티패턴과 함정

결과가 알려진 후 소급해서 작업을 분류하기: 이 주제의 핵심에 있는 게임 벡터다. 전달 압박 아래서, 팀은 어떤 단일 결정도 그 자체로 부정직해 보이지 않게, 사후에 부채나 위험 작업을 조용히 기능으로 표시하거나 모호한 아이템을 분포 차트에서 더 좋아 보이는 쪽으로 반올림할 수 있다. 가드레일은 서면 정의에 비추어 접수 시점에 분류하는 것과, 누락된 결함률(주제 5.1)과 취약점 메트릭(주제 6.4) 같은 독립적인 증거에 비추어 플로우 분포를 비교하는 주기적인 감사를 결합하는 것이며, 이는 이 책의 모든 메트릭에 대해 주제 1.2가 요구하는 것과 동일한 독립적-증거-대비-감사 규율이다.
기능이 거의 모든 역량을 꾸준히 흡수하게 두기(기능 공장 패턴): 부채와 위험 작업을 위기로 나타날 때까지 조용히 굶주리게 한다.
단일 기간의 분포를 전체 그림으로 취급하기: 추세 관점이 명확하게 드러내는 느리고 누적되는 드리프트를 놓친다.
비즈니스 이해관계자 없이 목표 분포를 설정하기: 프레임워크의 주된 가치, 즉 트레이드오프에 대한 공유되고 협상된 이해를 포기한다.
유형별로 일관성 없거나 문서화되지 않은 정의 사용하기: 정밀해 보이지만 시간이 지나도 실제로는 비교할 수 없는 수치를 만들어 낸다.
많은 하위 유형으로 분류 체계를 과도하게 설계하기: 비례하는 통찰을 더하지 않으면서 규율을 침식하는 분류 오버헤드를 더한다.

성숙도 모델

1단계, 시작: 작업이 플로우 아이템 분류 없이 일반적으로 추적된다. 부채와 위험 작업은 보고에서 보이지 않는다.
2단계, 개발: 일부 팀이 비공식적으로 플로우 아이템을 분류하지만, 정의가 일관성 없고 분류가 흔히 소급해서 일어난다.
3단계, 표준화: 모든 팀이 공유된 서면 정의에 비추어 접수 시점에 분류하고, 플로우 분포가 추세로 추적된다.
4단계, 관리: 플로우 분포가 독립적인 증거에 비추어 주기적으로 교차 검증되고, 목표 분포가 비즈니스 이해관계자와 의도적으로 설정된다.
5단계, 조율: 플로우 아이템 데이터가 조직 전반의 자원 배분 및 투자 결정을 직접 알려 주며, 리더십은 분류가 이전에 보이지 않던 트레이드오프를 명시적으로 만들었기 때문에 내려진 구체적인 결정을 제시할 수 있다.

논의를 위한 아이디어

지난 분기 작업을 정직하게 플로우 아이템으로 분할하면 무엇을 보여 줄 것이며, 그것은 누군가를 놀라게 할까?
우리는 네 가지 플로우 아이템 유형 각각에 대한 서면 정의를 가지고 있는가, 아니면 분류가 누가 작업에 레이블을 붙이는지에 달려 있는가?
우리의 플로우 분포가 뒤에 의도적인 결정 없이 한 아이템 유형 쪽으로 드리프트한 적이 있는가?
오늘 우리의 플로우 분포를 어떤 독립적인 증거에 비추어 교차 검증할 수 있을까?

핵심 요약

플로우 아이템은 기능, 결함, 위험, 부채라는 네 가지 유형 중 정확히 하나에 속하며, 그것들에 걸친 역량 배분은 제로섬이다.
보편적으로 건강한 분포는 없다. 올바른 혼합은 제품의 단계에 달려 있으며, 비즈니스 이해관계자와 함께하는 의도적이고 협상된 목표여야 한다.
이 주제의 핵심 게임 벡터는 소급 분류, 즉 사후에 부채나 위험 작업을 조용히 기능으로 다시 표시하는 것이다. 가드레일은 접수 시점 분류에 더해 독립적인 증거에 비추어 주기적인 감사다.
특히 거의 모든 역량을 꾸준히 흡수하는 기능인 기능 공장 패턴을 경계하라. 이는 위기로 나타날 때까지 부채와 위험 작업을 굶주리게 한다.
플로우 분포는 추세로서 가장 가치가 있으며, 그것의 가장 큰 보상은 비즈니스 이해관계자와 직접 공유하는 데서 온다.

참고 문헌 및 추가 자료

Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.
Kim, Gene, Kevin Behr, and George Spafford. The Phoenix Project. IT Revolution Press, 2013.
Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.