'반복적 개발 방법론'의 의미 제대로 이해하기

우리는 대부분 처음 무언가를 만들어 보게 됩니다. 이전에 만들어 봤던 것과 완전히 다른 경우도 많고 꽤 다른 경우가 대부분이죠. 이런 경우에 가장 안전한 개발 방법은 무엇일까요? 저의 경험 상 가장 좋은 답은 반복적 개발 방법론을 적용하는 것이었습니다.

(전문 SI 업체는 비슷한 전문 소프트웨어를 용역 개발하기 때문에 본 글과는 큰 상관이 없을 것 같습니다.)

 

여기서 반복이 무엇일까요?

매일 아침에 모여서 스크럼을 진행하고, 3주 간격으로 스프린트를 반복하는 것이 '반복'일까요? 특정한 기능 구현 시 업무를 1/4씩 나누어서 4번에 걸쳐서 나누어서 기능을 개발하는 것이 여기서 말하는 반복일까요?

 

제가 생각하는 올바른 반복이란?

한 번의 반복 후에 고객이 사용 가능한 산출물을 만들어 내고, 해당 산출물을 고객에게 전달하여 반응을 확인하고, 다음 반복에서는 기존 산출물 대비 완성도를 높인 산출물을 만들어 내어서, 여러 번의 반복을 거쳐서 이상적인 모습에 점점 가까운 산출물을 만들어 내는 것을 말합니다.

 

여기서 주의 깊게 보셔야 하는 문장은 '고객이 사용 가능한 산출물을 만들어 내고' 입니다. 

 

이해를 돕기 위해 풍경 수채화 그리기와, 스크래치 페이퍼 그리기의 사례를 활용해서 조금 풀어 보도록 할게요.

 

다음은 풍경 수채화를 그리는 과정입니다.

1번 그림처럼 대충 연필로 스케치를 하고, 2번 그림처럼 옅은 색부터, 큰 부분부터 색을 칠하기 시작하고, 3번 그림처럼 짙은 색을 칠하고, 4번 그림처럼 작고 세세한 부분까지 색을 입히고 디테일을 잡으면서 작품을 완성합니다. 

출처 : https://artparks.wordpress.com/category/풍경수채화-단계별-과정/

 

 

그리고, 다음은 스크래치 페인팅을 하는 과정입니다.

1번 그림처럼 흐릿하게 대략의 스케치를 진행한 이후에는 앞서 보여드린 풍경 수채화의 방식과는 사뭇 다르게 부분 부분의 디테일까지 한 번에 그려내고 있습니다. 태양부터 해왕성까지 하나씩 차례로 그려나가고 있습니다.

 

 

이 두가지 그림 그리기 예시에서 가장 큰 차이는 중간 산출물의 특징입니다. 

풍경 수채화 그리기 방식은 첫 단계 산출물부터 전체적인 모양새가 보이기 때문에 작가가 무엇을 그리고 있는 지 확실히 알 수 있습니다. 그림을 감상하는 입장에서 작가가 무엇을 그리고 있는 지를 이해하기 쉽습니다. 그렇기 때문에 작가와 감상자가 의견을 나누기도 수월합니다. 반면에 스크래치 페인팅 예시의 방식은 최종 산출물의 모습을 중간 단계에서 예측하기가 상대적으로 어렵습니다. 1번 단계에서 밑그림이 있기는 하지만 작가 본인이 사용하기 위한 목적이기 때문에 감상자 입장에서는 이 그림의 완성본이 어떻게 될 것이다라는 예측을 하기가 어렵습니다. 이에 따라 앞선 사례와는 다르게 관련한 대화를 나누기도 어려운 편입니다.풍경 수채화 그리기 방식, 중간 산출물이 사용자가 보고 이해할 수 있고 심지어 사용할 수 있는 방식이고 이것이 말하고자 하는 방식과 가깝다고 생각되네요. 

 

당신의 팀이나 소프트웨어 개발 방식은 충분히 고객 지향적인가요?

이 질문에 답하기 좋은 방법으로 우리 팀의 중간 산출물의 상태는 어떠한지를 점검해보면 좋습니다. 산출물의 모습이 스크래치 페인팅처럼 고객이나 경영진이 전체적인 모습이나 방향을 이해하기 어려운 형태라면 아직은 충분히 고객지향적이라고 보기는 어려울 것 같네요.

 

반복적인 개발 방식은 고객의 요구사항을 가장 정확하게 만들어 낼 수 있는 방법입니다.

아래 그림 많이 보셨을 겁니다. 많은 IT 프로젝트들이 망하는 이유를 설명한 웃픈 그림이지요. 이런 문제를 해결하는 방법이 과연 많은 설계 문서일까요? 고객에게 자주 상황을 설명해 주는 것일까요? 저는 아니라고 생각합니다. 아무리 기획서를 잘 만들어서 들이대도 고객은 당신만큼 완벽하게 이해하지 못하거든요. 당신의 팀조차도 이해를 못하는 데 고객이 무슨 수로 이해하겠어요? :) 

 

그래서, 제품을 만드는 방식에 있어 생각의 전환이 필요합니다.

아래 그림을 볼까요? 이 그림은 아시는 것처럼 애자일을 설명하는 유명한 그림이고 다음과 같은 메시지를 전달하고 있습니다.

- 부속품을 따로 만들어서 한 번에 조립하지 말아라

- 핵심 목적을 달성하는 MVP를 먼저 만들고, 핵심 기능을 개선하고 부가 기능을 추가하여 제품을 개선하여 나가라

- 계획이 없는 것도, 계획이 너무 자세한 것도 애자일이 아니다. 좋은 애자일은 러프하고 유연한 계획과 구조를 가지고 지속적으로 개선해 나가는 것이다.

 

 

여기서도 우리가 관심있게 보면 좋은 부분은 고객에게 전달할 수 있는 중간 산출물을 만들어내는 생각의 차이입니다.

처음 도전하는 제품을 만드는 경우에도 대부분은 개발팀은 Not like this를 선택합니다. 꽤나 그럴듯한 빅빅쳐를 그려낸 후 빅빅쳐를 향해 Divide and Conquer를 하면서 목표를 향해 WBS를 그려가면서 돌진합니다. 굳이 왜 돌아서 가야 하는 지 모르겠는 잘난 분들이 있기 때문입니다. 이런 전통적인 방식을 통해 개발된 중간 산출물(바퀴), 프레임의 경우 개발자 입장에서 바퀴 자체는 완벽하겠지만 고객 입장에서는 중간에 사용해보기가 매우 어렵습니다. 고객이 사용하면서 피드백을 줄 수 있는 시점은 기능 구현이 완료되어서 전문 검증이 시작되기 직전 즈음이 되어야 할 것입니다. 위에서 보셨죠? 짜잔 하고 나온 제품이 맞이하게 되는 비극적인 운명을...

Like this! 에서는 총 5회에 걸쳐서 반복 개발을 수행한 것이고, 각 단계의 산출물은 매번 고객에게 전달할 수 있는 사용 가능한 제품이었습니다. '엉성하지만 핵심적인 기능을 담고 있는 MVP 제품'의 경우 시장에 출시해서 고객의 반응을 확인하기 쉽습니다. 비록 완벽하지는 않지만 충분히 사용해 볼 수 있으며 다음 산출물은 이랬으면 좋겠다는 기대를 확인할 수 있습니다. 고객의 생각을 확인하여서 고객과 제품의 차이를 최소화 시키는 가장 좋은 방법은 중간 산출물을 써보게 하는 것이며 이에 가장 적합한 방법이 반복적 개발을 적용한 애자일 개발 방법론입니다.

 

반복적 개발 방식은 요구사항을 정확하게 개발해 내기에 좋은 방법이기도 하지만 놀랍게도 최종 목표에 도달하는 시간 역시 효과적으로 줄일 수 있는 방법이기도 합니다.

어떤 제품의 이상적인 산출물을 만들어 내기 위해서는 점선을 따라서 개발이 이루어져야 한다고 가정해 볼게요. 하지만, 실전에서는 여러가지 이유로 점선을 따라서 개발하기는 쉽지 않습니다. 조금씩 방향이 어긋나게 됩니다. 처음에는 약간 방향이 어긋나겠지만 진짜 문제는 그림처럼 최종 산출물이 나오는 시점에는 그 차이가 꽤 클 수 있다는 것입니다. 한 번에계획하고 그 계획을 오랜 기간 밀고 나가는 waterfall 내지는 이와 유사한 방식의 경우에 발생 가능한 극단적인 문제 상황입니다. 에이 설마 이러겠어? 라는 생각이 들겠지만 기획 조직, 개발 조직의 커뮤니케이션이 부족한 경우, 또는 SI 과제처럼 요청자와 개발자가 완전히 다른 사업 주체인 경우에는 의외로 자주 일어나는 일입니다.

 

 

이에 반해 반복적인 개발 방법론은 중간 산출물의 확인을 통해 현재의 진행 방향이 어긋나 있음을 쉽게 파악할 수 있기 때문에 경로의 수정이 매우 용이합니다. 고객이 첫번째 산출물 부터 직접 써볼 수 있기 때문입니다. 중간 산출물에 대한 피드백을 직접 받아내면서 다음 단계 산출물에 요청 사항을 반영하는 방식으로 고객의 요청 사항과 실제 산출물 간의 차이를 최소화하면서 개발을 구체화해 나아갈 수 있게 됩니다. 위 그림과 비교해 봤을 때 회색과 적색의 궤적이 훨씬 유사할 뿐 아니라 이상적인 산출물까지 재수정해야 하는 시간을 감안하면 반복적인 개발 방법론이 더 빠르고 정확하게 목표 지점에 도달하게 될 것이라는 것을 예상할 수 있을 것입니다.

 

반복적인 개발 방법론은 다소 생소한 제품을 처음부터 개발하는 경우에 적합하다고 서두에 말씀 드렸습니다. 이런 경우에 막막한 마음을 다스리는 방법 중 하나는 반복적인 개발 계획을 수립하여 진행하는 것이고 이를 실행에 옮기는 좋은 방법은 중간 산출물의 모습을 잘 설계하는 것에 있습니다. 지금 본인이 담당하고 있는 과제에서 풍경 수채화 그리기 방식 처럼 단계적으로 중간 산출물을 만들 수는 없을까를 상상해 보세요. 그려지는 중간 산출물이 있다면 그 생각을 팀과 공유하고 그 산출물을 만들기 위한 task를 분리한 후 해당 task들을 우선적으로 진행하여 고객에게 전달 가능한 중간 산출물을 만들어 보세요.

 

우리 팀과 당신의 팀 모두 적은 시간에 훌륭한 결과물을 만들어 내는 팀이 되길 기원합니다.