빠르게만 하는 작업은 의미 없습니다.

가치를 중요시해야 합니다. 

 프로젝트를 진행하다 보면 기획과 개발이 합의를 이뤄야 하는 구간이 있습니다. 그건 바로 프로젝트를 내보내는 기준에 대한 부분입니다. 생각하고 있는 가설을 검증하기 위해서 이 기능을 추가하거나 개선해서 확인하자고 기획에서 말을 하면 개발은 추가 또는 변경되는 기능에 대한 수정 및 검증 양을 확인하고 어느 정도의 기한 내에 할 수 있는지를 설명하게 됩니다. 개발부서는 여러 개발 건들을 맞이하기 때문에 기한 내에 이 기능을 배포할 수 있게 하기 위해 기능에 대한 요구사항을 줄여서 내보내자고 의견을 내게 됩니다. 기획은 자신의 가설을 확인할 수 있는 기능의 최소 형태에서 점점 확장해 가는 형태를 준비고 이때, 최소한의 가치를 가진 제품(또는 개선사항)을 MVP라 칭하게 됩니다. 이렇게 MVP를 먼저 개발하며 일정에 따라 추가 기능을 더 넣어서 배포할지, 아니면 MVP 이후의 다음 단계로 계획을 잡아갈지를 서로 논의하게 됩니다. 물론 이렇게 진행되는 것은 이상적으로 진행되는 형태입니다. 

 이상적이라고 말하는 이유는 현실의 우리는 그렇지 않기 때문입니다. 현실에서는 사용자에게 제공되는 범위를 합의하기까지 참 오랜 시간이 걸립니다. 개발이라는 자원은 한정적이고 시간은 오래갈수록 전해주려 했던 가치는 시기를 놓칠 수 있습니다. 그래서 시기를 맞추기 위해 작업의 크기를 조정하고 작은 형태로 만들어 내보내곤 합니다.  

 저는 가치가 전달되지 않은 형태의 빠르게 내보내는 제품은 오히려 내보내지 않느니만 못하다고 생각합니다. 그래서 일을 작은 형태로 나누기 위해 빼는 것이 아닌 일을 점점 확장하는 형태로 기준을 잡아 바라봐야 한다고 생각합니다. 

빨리한다고 무리하면 쓰러집니다.

 실제로 이미 완성된 형태의 전체 기획을 쪼개서 진행해야 한다고 할 때, 그 모습은 상당히 어색하게 보일 것입니다. 단계 별로 보이는 결과물이 뭔가 부족한 형태로 보이고 오히려 내놓아도 사용자에게는 좋지 못한 모양이라고 생각할 수 있습니다.

 그 생각은 맞을지도 모릅니다. 형태가 완성된 부분이 아님을 일반 사용자도 알아챌 수 있기 때문입니다. 완성품의 모습을 구상해 놓고 그 부분을 만들어 가다 보니 당연히 어색하게 느껴질 것이고 누군가에게는 제품이 미숙하게 느껴질 수도 있을 것입니다. 내가 생각한 완성품이 전달하는 가치는 부분의 완성으로는 전달할 수 없기 때문입니다. 그래서 사용자는 기획자가 주고자 했던 가치를 전혀 인식하지 못할 수도 있습니다.

 그래서 관점을 반대로 갖는 형태가 더 완결성을 부여하며 가치를 잘 전달할 수 있다고 생각합니다. 하나의 기능이 완결된 형태에서 점점 요구사항을 확장하는 형태로 작업을 진행하게 되면 각 단계에서 전달하고자 하는 가치가 확실해집니다. 그래서 제품이 더 좋아지는 형태를 보여줄 수 있습니다. 또, 그 기획을 각각 이해하고 설계, 개발, 그리고 검증을 진행할 때도 가치가 확실하다 보니 제품의 무결성도 높아져 사용자가 제품에 대해 느끼는 신뢰도도 올라가게 됩니다. 

 이런 생각의 방식은 개발도 마찬가지입니다. 이는 하나의 Commit 단위에도 마찬가지입니다. 개발자는 자신이 바라보는 시야에서 놓치는 문제가 있는지 여부를 확인하기 위해 동료 개발자에게 코드 리뷰(Code Review)를 요청합니다. 이때, 시니어 개발자 분들은 그 요청의 단위를 작게 하는 것을 선호합니다.

 개발을 진행할 때 수정된 양이 많을 경우, 수정 부분에 대한 영향도가 넓어지고 확인해야 하는 구간도 많아지게 됩니다. 또, 고객들이 사용하는 실제 환경에서 문제가 발생했을 때도 문제를 분석하고 추적하는데 많은 시간이 발생할 수 있습니다.

 그래서 제품의 완결성을 높이기 위해 작게 수정하여 확인하는 방법을 가져야 한다고 말합니다. 그래야 나의 코드를 리뷰해 주는 사람들도 확인해야 하는 양이 많지 않아 서로 놓치는 게 없는지를 확인해 줄 수 있기 때문입니다. 이에 대한 전제 조건은 매 작업 코드의 Commit 기준이 동작되는 소프트웨어를 만드는 것이라는데 있습니다. 이 부분이 바로 작업을 안정성 있게 확장하는 부분이라고 생각합니다.

 개발을 제외한 다른 여러 작업들은 과거에도 있던 작업들입니다. 그러나 프로그래밍은 과거에는 없던 학문입니다. 그래서 바라보는 관점을 다르게 바라보는 것이 오히려 쉬웠고 이 형태로 진행되어야 더 좋게 작업이 진행된다는 것이 쉽게 전파되었습니다.

 그런데 다른 학문들은 아직 그런 방식으로의 생각에 익숙하지 않습니다. 완결성을 갖추기 위해서는 각각이 모두 있어야 하는 형태라고 배우며 자랐고 그래서 완성된 상태를 만들어 놓고 하나 둘씩을 분리해 가는 작업을 수행하며 서로 간의 속도를 맞추려 합니다. 그래서 기획은 만족하지 못한 상태의 제품을 바라보는 형태가 많았고 개발은 자신의 작업에 만족하지 못해 하는 모습에 서로 마음이 상하는 경우도 본 적이 있었습니다. 

 그래서 서로 간의 생각을 맞추는 과정이 있어야 하고 요구사항을 빼는 것이 아닌 더해가는 형태로 생각을 전환해 맞춰가는 것이 필요하다고 생각합니다. 그래야 사용자에게 전달하는 가치가 명확하게 전달되는 형태인지를 확인할 수 있습니다. 

 

  애자일 선언 이면의 원칙 12가지 중에는 이런 내용이 있습니다. 

작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.

 위의 원칙의 전제가 되는 원칙은 아래와 같다고 생각합니다. 

우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. 

 우리 모두는 고객을 만족시키기 위해 제품을 전달하는 것이 목적입니다. 그리고 그 제품은 가치가 있는 형태여야 합니다. 최종적인 기능 형태가 아니면 가치를 전달하지 않을 수 있다는 생각이 들어있다면 오히려 완성되기까지 기능을 내지 않는 것이 낫습니다.

 우리는 고객에게 가치를 더 빠르게 전달하기 위해 작업을 조정하는 것일 뿐, 빨리 내보내기만을 위해 작업을 조정하는 것은 아니기 때문입니다.