추정: 우리가 할 수 있는 최선

Estimation: The Best We Can Do

저자: 론 제프리스 (Ron Jeffries) 출처: PragPub 날짜: 2022년 5월 18일

두 달 전 이 지면을 통해 론 제프리스는 추정(Estimation)이 '악(Evil)'이라고 말했습니다. 이제 그는 추정이 '필요악'이며, 제대로만 한다면 악조차 아니라고 말하러 돌아왔습니다.

그렇습니다. 조직 내에는 추정이라는 개념을 둘러싼 수많은 남용 사례가 존재합니다. 대부분의 개발자는 경력을 쌓는 동안 이러한 남용으로 인해 한 번 이상 상처를 입은 경험이 있을 것입니다.

안타깝게도 이는 배움의 초기 단계에 있는 예비 애자일(Agile) 실천가들 사이에 흔하고 순진한 관점을 낳습니다. 바로 추정을 완전히 폐지하고 싶어 하는 것입니다. 하지만 이는 아마 불가능할 뿐만 아니라, 확실히 이상적이지도 않습니다. 우리는 우리가 어떤 일을 얼마나 빨리 할 수 있는지 추정할 능력이 있으며, 우리가 아는 바를 공유할 때 비즈니스는 더 나은 결정을 내릴 수 있습니다.

개발은 그저 기능을 빠르게 찍어내는 매끄러운 기계가 아닙니다. 돈, 시간, 날짜와 같은 비즈니스의 관심사에 대해 우리에게 책임이 없다고 생각하면 마음은 편하겠지만, 그것은 사실이 아닙니다. 우리가 만드는 것은 우리가 무엇을 할지 결정하고 모든 위험을 감수하는 어떤 '제품의 군주(Product Overlord)'만의 영역이 아닙니다. 비즈니스 담당자가 최종 결정을 내릴 수는 있지만, 많은 결정은 팀에 의해 가장 잘 이루어질 수 있습니다. 여기에는 '어떻게' 할 것인가뿐만 아니라 '무엇'을 할 것인가도 포함됩니다. 우리는 우리의 창의성과 전문 지식을 사용하여 프로젝트를 올바른 방향으로 이끌 책임이 있습니다.

애자일 선언문(Agile Manifesto)은 "최고의 아키텍처, 요구사항, 그리고 디자인은 자기 조직화된 팀에서 나온다"라고 말하며, 이것이 바로 우리가 의도한 바입니다. 애자일 개발자들은 종종 작업이 얼마나 걸릴지에 대한 좋은 감각을 가지고 있으며, 이는 요구사항을 선택하고 정제하는 데 귀중한 요소가 됩니다. 개발자들은 요청받은 작업의 예상 비용에 대해 나서서 이야기할 필요가 있습니다.

추정에 대한 우려들

소프트웨어 작업 추정과 관련하여 심각한 문제들이 실제로 많이 존재합니다. 지난 기사 "추정은 악이다(Estimation is Evil)"에서 저는 그중 몇 가지를 설명했습니다. 다시 살펴봅시다.

미리 정의된 작업 백로그(backlog)는 창의성을 감소시키고 성공을 위한 프로젝트의 방향 전환을 방해합니다.

정해진 날짜까지 "모든 것"을 납품하라고 요구하는 것은 결코 통하지 않는 속임수입니다.

추정치를 약속으로 취급하면 팀은 보수적으로 변하고 결과는 실망스러워집니다.

추정의 "품질"을 높이려고 애쓰는 것은 제품의 품질을 높이는 데 쓰는 것이 더 나은 주의력을 낭비하는 것입니다.

기타 등등 말이죠.

해당 기사에서 저는 이러한 것에 집중한 결과가 바로 "약한 애자일(weak Agile)"이라고 주장했습니다. 본질적으로 추정에 집중하는 팀은 일반적으로 비용 대 가치라는 지렛대에서 불리한 쪽을 잡고 일하는 셈입니다. 더 나은 팀은 비용보다 가치에 더 집중합니다. 물론 그들도 비용을 고려합니다. 비용은 가치를 전달하는 데 중요한 요소 중 하나니까요. 하지만 그들의 주된 관심사는 가치입니다.

최고 수준의 팀들 중 다수가 우리가 아는 일반적인 의미의 추정을 하지 않는 것은 사실입니다. 그들은 아주 작은 스토리(story) 단위로 작업하며, 그 크기가 너무 작아서 진행 상황을 파악하려면 그저 개수를 세기만 하면 됩니다. 그들은 자신들이 가진 가치의 개념을 사용하여 가장 가치 있는 일을 먼저 처리합니다. 그들은 상황에 따라 전망을 자주 조정하고 다음에 작업할 내용을 조정합니다. 그들은 가치 있는 소프트웨어의 지속적인 흐름을 만들어내기 위해 노력하며, 가능한 한 자주, 종종 매일 배포합니다.

추정은 종종 기능 장애가 있거나 약한 팀과 연관되고, 위대한 팀은 추정 없이 일하는 것처럼 보이기 때문에, 많은 애자일 실천가들은 어떤 종류의 추정도 강력히 거부합니다. 그리고 추정 없이 일할 수 있을 만큼 강력한 팀(그리고 조직)을 만드는 것은 좋은 일입니다. 하지만 이것은 고급 작업 방식이지, 시작하는 방법은 아닙니다. 추정이 필요한 조직에서 추정을 거부하거나 심지어 분개하는 것은 좋지 않습니다. 오히려 우리는 조직에 긍정적인 영향을 미치는 방식으로 추정을 잘 수행하는 법을 배워야 합니다.

새 프로젝트 예산 책정하기

이제 프로젝트 진행 여부를 결정하는 조직을 돕는, 정당한 필요성 한 가지만 살펴봅시다.

집이나 차에 문제가 생겼는데 돈이 무한정 있는 게 아니라면, 우리는 아마 수리 견적을 받을 것입니다. 그리고 대안을 고려할 것입니다. 트렁크 뚜껑이 긁혔다면, 완벽한 색상 일치를 위해 차 전체를 도색해야 할까요? 트렁크 뚜껑만 뿌릴까요? 긁힌 자국을 광택으로 없애 볼까요? 아니면 그냥 긁힌 채로 살까요? 우리는 돈을 가장 잘 쓰는 것 같은 옵션을 선택합니다.

프로젝트 예산을 책정하는 비즈니스 담당자들도 자금 할당이라는 동일한 문제를 겪습니다. 그들은 예산 내에서 가능한 한 많은 가치를 전달하는 방법을 고려해야 합니다. 놀라운 신제품을 만들려고 노력하는 작은 조직에서는 이 문제가 더욱 절박합니다. 돈이 다 떨어지기 전에 긍정적인 현금 흐름(수익)을 창출해야 하니까요!

이런 상황에서는 정말로 약간의 추정이 필요합니다. 이 새로운 프로젝트를 수행하는 것이 현명한지 알아야 합니다. 비즈니스 담당자들은 이미 몇 가지 추정치를 염두에 두고 있습니다. 얼마나 많은 사람이 관심을 가질까? 잠재 고객 중 몇 퍼센트가 구매자로 전환될까? 구매자들은 제품에 얼마를 지불할까?

하지만 그들은 결정해야 합니다. 현금이 바닥나기 전에 생존할 수 있을 만큼 충분한 돈을 벌어들이기 시작할 수 있을까?

의사 결정권자는 이 모든 수치가 추정치라는 것을 알고 있으며, 자신의 최선의 판단을 사용하여 가치를 부여합니다. 하지만 그가 잘 모르는 핵심 영역이 있습니다. 이 제품의 어느 정도 분량을, 언제까지, 얼마의 비용으로 완성할 수 있을까? 이것은 기술적인 질문이며 기술자가 대답해야 합니다.

물론, 우리도 모릅니다. 정말로 얼마나 걸릴지 모릅니다. 하지만 인정할 건 인정합시다. 우리는 가여운 기업가보다는 일이 얼마나 걸릴지 더 잘 알고 있으며, 그는 우리의 도움이 필요합니다.

저는 우리가 얼마나 빨리 진행할 수 있을지 감을 잡기까지 일주일이 걸릴지, 한 달, 분기, 혹은 1년이 걸릴지 꽤 괜찮은 추측을 할 수 있다고 믿습니다. 그리고 그 추측이 비록 거칠지라도 비즈니스 담당자가 할 수 있는 추측보다는 낫습니다.

그냥 "한번 해보죠(Try it)"라고 말할 순 없을까요? 아마 이렇게 말할 수 있을 것 같습니다.

"우리 팀 비용은 주당 1만 달러입니다. 제품에서 가장 중요하고, 가장 위험하고, 가장 많은 정보를 얻을 수 있는 부분부터 작업을 시작해서, 이 일이 얼마나 어렵고 얼마나 걸리는지 감을 잡아봅시다. 당신은 우리가 당신이 요청한 것을 만드는 걸 보게 될 겁니다. 작동하는 걸 보게 될 거고요. 계속 투자할지 멈출지 결정할 수 있을 겁니다."

이렇게 말하는 게 합리적으로 보입니다. 매주 1만 달러라는 거금을 쏟아붓는 당사자가 당신이 아니라면 말이죠. 투자자라면 더 많은 질문이 생깁니다. "일주일 안에 알 수 있나요? 한 달을 기다려야 아나요? 6월이면 알게 되나요? 세상에, 이봐요, 지금부터 6월까지면 10만 달러가 넘어요. 큰돈이라고요! 좀 봐주세요, 네? 이거 만드는 데 대체 얼마가 드는 겁니까?"

우리는 이런 도전에 나서야 합니다. 비록 절대적으로 구체적인 답은 없을지라도, 할 수 있는 한 가장 확실한 답을 줘야 합니다.

우리는 모래 위에 서 있습니다. 어떻게 콘크리트처럼 단단해질 수 있을까요?

질문은 "사람들이 살 만한 제품을 만드는 데 얼마나 걸리고, 돈이 얼마나 드느냐"입니다.

우리는 "일단 우리한테 돈을 쓰기 시작하시고, 지루해지면 그만두세요"라고 말하고 싶겠지만, 그건 도움이 안 됩니다. 이 생각을 조금 뒤집어 볼까요? 우리가 어디쯤 있는지 감을 잡기 위해 아주 넓은 범위의 추정부터 시작해 봅시다.

우리는 사람들이 사용할 수 있는 무언가를 만드는 데 일주일이 걸릴지, 한 달이 걸릴지, 6개월이 걸릴지 어느 정도 감이 있을 겁니다. 그렇다면 그것에 대해 이야기해 봅시다. 투자자는 지출 가능한 금액을 염두에 두고 있습니다. 대화를 통해 그 금액이 얼마인지, 또는 어느 정도인지 알아내 봅시다.

우리가 6개월 정도면 기초적이지만 사용할 수 있는 제품을 만들 수 있을 것 같다고 생각하고, 투자자는 긍정적인 현금 흐름에 도달하기 위해 최대 100만 달러까지 투자할 의향이 있다고 가정해 봅시다. 100만 달러는 우리 팀의 약 1년치 비용입니다. 만약 6개월이 아니라 9개월이 걸린다면, 흑자로 전환하기 위해 남은 3개월 동안 100만 달러를 벌어들여야 합니다. 이것에 대해 이야기해 봅시다. 그는 첫 출시 후 수익이 얼마나 빠르게 증가할 것으로 예상합니까? 만약 9개월이 걸리더라도 괜찮을 만큼 수익이 빠르게 성장할 것이라고 생각한다고 칩시다. 제게는 위험해 보이지만, 적어도 이 프로젝트는 탐구해 볼 가치가 있는 것처럼 들립니다.

애자일이 어떻게 작동하는지 기억하세요. 우리는 비즈니스 담당자들이 눈앞에 보이는 것을 바탕으로 돈을 쓸지 말지 실시간으로(live) 결정하는 과정에 완전히 참여하기를 원합니다. 그러니 날짜뿐만 아니라 기능 선택에 대해서도 생각하게 만듭시다.

감당할 수 있는 추정 (Estimation You Can Live With)

좋습니다. 직관적으로 우리는 6개월 안에 초기 릴리스를 할 수 있을 것 같고, 투자자는 9개월이 걸려도 프로젝트가 생존 가능하다고 생각합니다. 좋아 보이지만 여전히 위험해 보입니다. 우리는 투자자가 그렇게 많은 돈을 쓰고도 아무것도 얻지 못하는 것을 보고 싶지 않습니다. 그리고 이것들은 여전히 거친 추측일 뿐입니다.

그러니 이렇게 합시다. 더 구체적인 답을 내놓기 위해 2주를 잡읍시다. 2주는 2만 달러밖에 들지 않습니다. 100만 달러보다 훨씬 적죠. 그 2주 동안 투자자는 제품의 가장 중요한 측면에 대해 우리와 적극적으로 협력합니다. 일부는 룩앤필(look and feel) 같은 것일 수도 있고, 일부는 지금 예측할 수 있는 다른 비즈니스적 또는 기술적 위험에 의해 주도될 수도 있습니다. 2주가 끝날 때 우리는 계속 진행할지 결정합니다. 우리의 일은, 구체적으로 우리가 무엇을 만들 수 있는지 보여주어 우리 모두가 진행 여부를 확신할 수 있게 하는 것입니다. 투자자의 일은 원하는 것을 설명하여 우리를 안내하고 위험과 우려 사항을 식별하기 위해 우리와 협력하는 것입니다.

2주 후에 상황이 나빠 보인다면, 우리는 그걸 알게 될 것이고 중단을 권할 것입니다. 상황이 좋아 보인다면, 다음 주요 결정 시점이 언제가 될지 함께 결정합니다. 한 달 뒤일 수도 있고, 3개월 뒤일 수도 있습니다. 솔직히 우리는 이 과정을 2주마다 하는 것도 아주 좋습니다.

네, 맞습니다. 2주마다 우리는 다음에 무엇을 할지 당신과 이야기할 것입니다. 우리는 그것을 만들고 당신에게 보여줄 것입니다. 충분히 좋다면 계속할 것이고, 그렇지 않다면 멈출 것입니다.

그렇게 하면 당신의 위험 부담은 2만 달러를 넘지 않습니다. 당신은 그 돈을 더 많은 정보를 얻는 데 쓸지, 우리의 노력을 다른 방향으로 돌릴지, 아니면 다른 곳에 쓰는 게 더 나을지 결정할 수 있습니다.

이렇게 일할 수 있을까요?

그가 '예'라고 한다면 시작합시다. '아니오'라고 한다면 이유가 무엇인지, 이 프로젝트가 우리에게 맞는지 파악해야 합니다.

이것은 분명히 추정입니다. 그리고 이것은 비즈니스 측 사람들과 대립하는 것이 아니라 협력하여 수행할 수 있는 종류의 추정입니다.

우리는 2주 안에 유용한 정보를 생산할 수 있다고 어느 정도 확실하게 추정합니다. 만약 못 할 것 같다면 4주나 6주, 8주를 제안하는 게 낫습니다.

더 나아가, 우리는 생존 가능한 제품이 6~9개월 안에 가능할 것이라고 추정합니다. 만약 전혀 모르겠거나, 더 나쁘게는 진심으로 의심스럽다면, 위와 같은 조건으로 그에게 알아보자고 제안해서는 안 됩니다. 우리는 그에게 솔직히 말해야 할 의무가 있습니다. "솔직히 말씀드리면, 저희에게는 이건 2~3년짜리 프로젝트 같습니다. 우리가 틀릴 수도 있습니다. 그걸 알아내기 위해 배워야 할 것은 이것들이고, 알아내는 데 드는 비용은 이 정도입니다. 그리고 지금 우리의 최선의 추측으로는 그 결과가 나쁜 소식일 것 같습니다."

때로는 우리가 무엇을 할 수 있는지 잘 알 때도 있고, 덜 알 때도 있습니다. 어느 쪽이든 우리가 아는 것을 추정함으로써, 우리는 무엇을 할지 결정하는 능력을 향상시키는 실험(투자)을 설계할 수 있습니다.

남의 돈을 쓰는 일에 있어서, 저는 우리가 그렇게 할 의무가 있다고 생각합니다.

이것은 추정이지, 협상이 아닙니다!

추정이 반드시 "이 프로젝트는 5월 14일 화요일 오후 2시 35분에 완료될 것입니다"일 필요는 없습니다. 추정은 가능성의 범위를 표현해야 합니다. "4월 안에 끝낼 방법은 없어 보입니다. 모든 게 완벽하게 진행된다면 5월 중순쯤 준비될 수도 있겠네요. 우리 경험상 6월, 어쩌면 7월을 생각하고 있습니다"라고 말하는 것은 완벽하게 괜찮습니다.

우리가 그렇게 말하든 안 하든, 우리는 그렇게 알거나 의심하고 있을 가능성이 큽니다. 그리고 우리가 그렇게 생각한다면 프로젝트에는 그 정보가 필요합니다. 하지만 그렇게 말하면 반발을 살 것입니다. 누군가는 우리에게 4월 30일까지 끝낼 수 없다는 것을 의심의 여지 없이 증명하라고 도전할 것이고, 어찌어찌 증명한다 해도 그들은 "그럼 5월 5일은?"이라고 말할 것입니다. 아, 우리는 그들이 이러는 걸 정말 싫어하죠. 그렇다면 이 게임을 하지 않고 어떻게 프로젝트에 필요한 정보를 줄 수 있을까요?

날짜 추정에서 속도(Velocity) 추정으로 이동하십시오

이전 기사의 '파이브 카드(Five Card)' 방식을 날짜를 추정하는 데 쓰지 말고, 전체 프로젝트를 우리 팀이 2주에 5개 정도 할 수 있을 만큼 작은 하위 스토리로 나누는 데 사용합시다. 물론 3개만 끝낼 수도 있습니다. 6개를 할 수도 있지만 그건 장담 못 하죠. 그래서 우리는 속도(velocity)의 관점에서 추정치를 가지고 돌아갑니다.

"우리는 이 프로젝트를 작은 스토리들로 나누었습니다. 이 정도 크기의 스토리라면 2주에 3개에서 5개 정도 할 수 있을 것으로 믿습니다. 그리고 2주 단위의 기간이 끝날 때마다 우리가 한 모든 것은 눈에 보이고, 테스트 되고, 통합되고, 작동할 것입니다. 그러니 5개든 6개든 2개든, 우리도 알게 되고 당신도 알게 될 것입니다.

이 스토리 중 일부를 제거하거나 연기하고도 여전히 생존 가능한 제품을 만들 수 있다면, 제품을 더 일찍 출시할 수 있습니다. 스토리를 단순화한다면 더 일찍 출시할 수 있습니다. 스토리를 추가하거나 더 어렵게 만든다면 제품 출시는 늦어질 것입니다.

당신에게 달렸습니다. 우리는 작업을 이 크기로 쪼갤 수 있고, 지금 우리의 속도를 2주당 약 3개 정도로 추측할 수 있으며, 당신은 2주마다 실제로 무슨 일이 일어나는지 알게 될 것입니다. 당신은 그 정보를 사용하여 무엇을 하고 무엇을 미룰지 결정함으로써, 당신이 선택한 날짜에 최상의 제품을 얻을 수 있습니다."

경영진이 속도를 활용하도록 도우십시오

이제 경영진은 여전히 우리와 협상하고 싶어 할지도 모릅니다. 그들이 수치를 더해 날짜를 산출한 다음 날짜를 조정하려고 든다면, 협상하지 마세요. 대화를 다시 진행 속도(rate of progress)로 돌리십시오. "날짜는 당신에게 달렸습니다. 더 많은 일을 선택하면 늦어질 것입니다. 적게 선택하면 빨라질 것입니다. 우리는 2주에 3~5개를 할 것으로 생각합니다. 우리가 틀릴 수도 있습니다. 만약 그렇다면, 우리만큼이나 빨리 당신도 알게 될 것입니다."

누군가는 속도를 높이려고 압박할 수도 있습니다. "2주에 7개는 못 해요? 그래야 제시간에 끝나는데."

애자일이 어떻게 작동하는지 기억하세요. 개발자는 최적의 지속 가능한 속도로 일합니다. 개발자는 날짜를 책임지지 않습니다. 비즈니스 측이 날짜를 소유하고, 날짜를 맞출 책임을 집니다.

개발자의 일은 가능한 최고의 속도로 납품하는 것입니다.

"우리는 3개에서 5개를 할 수 있다고 생각합니다. 만약 더 빨리 가게 된다면 알게 될 겁니다. 더 느리다면 그것도 알게 되겠죠. 언제 끝날지는 그것에 달려 있지만, 당신이 우리에게 할 일을 얼마나 많이 주느냐, 혹은 얼마나 적게 주느냐에 더 크게 달려 있습니다. 그 날짜까지 무엇을 넣을지는 당신에게 달렸습니다. 2주당 3~5개 항목으로 계획을 세우고, 실제로 무슨 일이 일어나는지 지켜보셔야 합니다."

그들은 한 번 이상 더 빨리하라고 압박할 수도 있습니다. 하지만 우리에게는 사실(그것이 비록 현재의 추정일지라도)이 있습니다.

"우리 경험에 비추어 볼 때 3개에서 5개를 완료할 것입니다. 그보다 높은 수치를 가정하는 것은 현명하지 않습니다. 그럴 가능성이 없기 때문입니다. 더 빨리 갈 수 있는 상황이 생긴다면 우리 모두 알게 될 것이고, 당신은 릴리스에 더 많은 항목을 선택해 넣을 수 있습니다."

물론 이 모든 것은 커뮤니케이션에 관한 것이지, 추정에 관한 것은 별로 없으며, 단호하게 말하지만 협상에 관한 것은 아닙니다. 추정은 사소했습니다. 우리가 카드를 쪼갤 때 이미 다 했습니다. 이제 우리는 우리가 아는 것, 추측하는 것, 믿는 것을 소통하고 있습니다.

우리는 경영진에게 우리의 생산 속도에 대한 최선의 추정치를 제공하고, 배우면서 개선해 나가는 것 외에는 그 추정치를 고수합니다. 우리는 비즈니스 담당자들이 작업량을 선택함으로써 날짜를 통제한다는 점을 계속해서 명확히 합니다.

제품 최적화

당신이 추정에 찬성하든 반대하든, 애자일은 첫날부터 마지막까지 좋은 상태로 제품을 점진적으로 구축하고 가능한 한 빨리 가치를 얻는 것임을 알아야 합니다. 이를 위해서는 훌륭한 기술적 역량이 필요하지만, 기술만으로는 충분하지 않습니다. 우리의 작업에 돈을 지불하는 사람들은 자원을 할당해야 합니다. 그들은 현금을 관리해야 하고, 우리 팀 외부의 활동 및 이해관계자들과 우리의 작업을 조정해야 합니다.

이를 효과적으로 수행하기 위해 그들은 일이 얼마나 걸리는지에 대한 정보가 필요합니다. 이는 일이 얼마나 비용이 드는지, 그리고 우리가 돈을 회수하기 시작할 때까지 얼마나 걸리는지로 번역됩니다. 그들이 이 일을 잘 수행하려면 우리가 가진 정보가 필요합니다. 우리의 정보가 모호하고, 결함이 있고, 불확실하다는 사실이 정보를 숨길 이유가 되지는 않습니다. 우리는 그들의 손에 정보를 쥐여주어야 하며, 그들이 그것을 잘 활용할 수 있도록 돕는 방식으로 제공해야 합니다.

추정을 거부하는 것은 올바른 방법이 아닙니다. 추정은 필요하며, 추정의 효과적인 의사소통 또한 필요합니다.

가장 좋은 방법은 작은 기능들을 가능한 최상의 지속 가능한 속도로 개발하고, 그 과정에서 생성된 정보를 사용하여 비즈니스 담당자들이 무엇을 요청하고 무엇을 미룰지 결정하도록 돕는 것입니다. 이를 위해 우리는 추정을 해야 합니다. 스토리를 추정 가능한 작은 크기로 자르고, 그것들을 전달하는 속도를 추정합니다. 이런 종류의 추정은 전혀 나쁘지 않습니다. 이것은 믿을 수 없을 정도로 유용하며, 최고의 애자일 팀들이 하는 일입니다.