플머의 개발 연구소

제목에 나열되어 있는 워터풀, 애자일, 린은 프로젝트 방법론이다.

프로젝트 방법론이란 어떠한 프로젝트를 어떤 순서로 어떤 방식으로 개발할지를 정의한 것이라 보면된다.

각각 어떤 차이가 있는지 알아보도록 하겠다.

폭포수(Waterfall)

폭포수(Waterfall) 방법론은 아주 오래전부터 쓰여오던 방식이다.

기획->디자인->개발->테스트(검증)->런칭 이렇게 순서대로 다섯가지의 과정을 거치게 된다.

반드시 위의 순서대로 프로젝트가 진행되어야 한다.

어떤 서비스를 개발할 때 해당 서비스에 대한 기획이 모두 완료되면, 디자인팀에서 해당 기획에 대한 디자인을 진행하고, 디자인이 모두 완료되면 개발팀에서 해당 기획과 디자인을 가지고 개발을 진행하게 된다.

최종적으로 테스트하여 문제가 없다면 서비스를 런칭한다.

이 작업의 장점은 어떤 파트에서든 순조롭게 진행된다면 가장 이상적인 방법론이 된다.

또 현재 단계의 진행이 끝나야 다음 단계를 진행할 수 있는 특성 때문에 진행 상황을 파악하기가 더 수월하다는 것이다.

반대로 개발까지 진행을 했는데 기획이 변경된다던지, 디자인이 변경된다던지 한다면,

변경할 부분이 많아지기 때문에 다른 방법론에 비해 유연하게 대처하기 어렵다는 단점이 있다.

대기업에서는 아직도 많이 쓰이는 프로젝트 방법론이지만, 현실적으로 모든 파트가 순조롭게 진행되는 경우가 드물기 

때문에 이런 순차적인 개발 과정은 비효율적으로 보여진다.

애자일(Agile)

애자일 방법론은 워터풀의 비효율적인 부분을 개선하기 위해 등장하였다.

워터풀처럼 순차적인 과정을 거치지만, 그 과정을 짧게 거치게 된다.

'기획->디자인->개발->테스트'의 과정을 빠르게 거치며 프로토타입부터 살붙이기 형태로 개발해나가는 방식이다.

아무래도 폭포수 방법론에 비해 개발 주기가 짧기 때문에 기획이나 디자인이 변경되어도 그 부담이 훨씬 적어지게 된다.

잘못될 수 있는 부분을 미리 잡아가는 부분이 폭포수 방법론에 비해 엄청난 장점이 될 수 있다.

A,B,C 기능이 포함된 앱을 개발한다고 가정할 때, 애자일 방법론을 개발하게 되면,

A 기능에 대한 기획->디자인->개발->테스트가 이루어지고,

B 기능에 대한 기획->디자인->개발->테스트가 이루어지는 형태로 개발 진행이 된다.

즉, 어떤 문제가 발견됐을 때 비교적 덩치가 작은 상태에서 수정하기 때문에 문제 해결 시간이 줄어들 수 밖에 없다.

또한, 결과물을 일부 기능들이 완료될 때마다 프로토타입 형태로 보고 피드백을 할 수 있으므로 보다 더 효율적인 프로세스 진행이 된다고 볼 수 있다.

점점 변화가 빨라지는 세상에 살고 있기 때문에 애자일 방법론이 더 빛을 보는게 아닌가 싶다.

린(Lean)

린 방법론을 설명하기 위해서는 '린 제조'를 먼저 알아야 한다. 린 제조는 도요타가 사용한 제조 방식인데,

불필요한 설비나 인력을 줄여서 낭비를 줄이는 방식이다. 즉, 린 방법론은 어떤 낭비될 수 있는 부분을 제거하여

고객에게 더 빠르게 프로덕트를 제공할 수 있는 방법론이다.

프로덕트 기획을 하고 개발을 진행하는데 만약 고객이 원치 않는 불필요한 기획이 있다면 어떨까?

이를 개발하는 시간은 모두 낭비되는 시간이라 봐야 한다. 또 개발하고나서도 검증 과정에 시간을 또 쏟아야 하므로

불필요한 프로세스 시간이 더 늘어나게 된다. 린 방법론은 바로 이 부분을 캐치하여 불필요한 작업을 제거하는 것이다.

스타트업에서 린 방법론을 차용한 것을 린스타트업이라고 부른다.(실리콘밸리의 기업가 에릭리스가 개발하였다.)

초기 스타트업에서 폭포수 방법론을 도입하게 되면 프로덕트 도출 기간이 길어지게 되고, 출시 이후에

문제가 발생할 경우 시장 리스크가 너무 커지고 대응 또한 어렵게 된다.

린 스타트업의 기본은 개발 -> 측정 -> 배움 세가지 과정을 거치게 되는데, 실제로 빠르게 프로토타입을 개발하여,

고객과 접촉하여 문제를 발견하면 빠르게 변경하여 적합한 비즈니스를 빨리 찾아내는데 목적이 있다.

여기까지 보면 린과 애자일은 빠른 변화에 대응할 수 있다는 부분에서 공통점을 지닌다.

실제 경험에서 차이점이 있다면 린 모델의 경우 런칭 후 사용자 피드백을 통해 빠른 변화를 도모한다는 것이고,

(프로토타입 개발->런칭->피드백 과정의 반복)

애자일 모델의 경우 사용자에게 런칭하기 이전까지의 개발 사이클을 빠르게 돌리는 것이라고 볼 수 있다.

(프로토타입 개발 과정이 빠르게 반복되고, 살붙이기가 모두 완료되면 런칭 후 피드백)

위 세가지 모델에 대해 정리해보았는데 폭포수 모델과 다른 모델과의 차이는 뚜렷한 편이지만,

애자일과 린의 경계는 그리 뚜렷하지 않은 것 같다.

어쨌든 린과 애자일이 변화에 빠르게 대응할 수 있고 리스크를 줄이기 위한 효율적인 모델이라는 것에 대해 동의하며,

앞으로 진행하는 프로젝트에 대해서도 이 두가지 모델을 애용할 것 같다.

ICT 분야의 스타트업을 팀빌딩할 때 빠질 수 없는 팀원이 개발자 팀원이다.

물론 기획자, 디자이너, 마케터 등 다른 파트의 팀원 또한 매우 중요한 역할을 담당하지만,

서비스를 개발하기에 앞서 초기에 비용이 가장 많이 투입되는 부분이 개발쪽이기에 부담이 큰 파트라는 부분은

어느정도 동의할 것이다.

여기서 내가 얘기하고자 하는 것은 단순한 개발자 팀원 뽑는 것보다 더 중요한 것은 CTO의 영입이라는 것이다.

심지어 개발 팀원을 두지 않고 외주 개발로만 진행한다하더라도 CTO를 영입하는 것을 권장한다.

단, 팀의 대표가 개발에 대한 역량이 없고, 개발에 대한 커뮤니케이션 능력이 없다는 가정이다.

여기서 CTO라는 것은 원론적인 의미의 CTO라기보다는 어느정도 중간 관리자 수준 급(개발자 컨트롤이 가능한)의 개발자를 의미하는 것으로 보면 될 것 같다.

초기 스타트업의 경우 당연히 각 분야 인재를 영입하는게 쉽지 않지만, 개발자 자체도 영입하는게 쉽지 않아서

그냥 개발자라면 무턱대고 뽑거나, 뽑는 것을 포기하고 바로 외주 업체를 찾아나선 후 개발을 시작하는 경우가 많다.

이것이 무조건 잘못됐다고 하는 것은 아니며 리스크가 있을 수 있는 부분을 설명하고자 한다.

이유는 여러가지가 있지만 여기서 살펴볼 이유는 '구현된 제품의 수준'이다.

어떤 고도화된 서비스 개발을 경험해보지 않은 개발자의 경우 아무리 초기 제품으로 MVP 모델을 만든다하더라도 이를 확장 모델로 고도화시키기가 매우 어렵게 만들곤 한다.

조금 더 쉽게 예를 들면, MVP 모델을 완성한 후 런칭을 하였는데 사용자가 급격히 늘어나며 데이타베이스에 데이타가 쌓이게 되면서 앱 속도가 점점 느려지고, 사용하기 어려울 정도가 되버리는 경우가 발생할 수 있다.(하나의 예이다.)

이 때 간단한 수정으로 해결될 수도 있지만 상황에 따라 설계의 문제라면, 다시 엎고 새로 만들어야 하는 경우까지 발생하게 된다.

나는 주변 스타트업에서 이런 상황을 직접 보기도 했고, 간접적으로 들은 것까지 포함하면 꽤나 흔한 상황이라 느꼈다.

이런 일이 발생하는 이유는 개발자가 이를 고려하지 않거나(혹은 역량 문제로 고려하지 못하거나),

외주에 의뢰하는 경우라면 이러한 디테일한 부분까지는 언급하지 않기 때문이다.

개발자의 역량이 높을 수록 당장의 구현에 급급하지 않고 앞으로를 고려한 설계를 신경쓰게 된다.

(귀차니즘의 문제로 그렇지 않은 경우도 있기는 하다.)

반대로 개발 역량이 낮을 수록 당장 구현에 급급할 뿐, 설계에 대한 노하우가 부족하므로 위와 같은 문제를

초래하게 된다. 

외주업체의 경우 당연히 외주 업체마다 case by case인 부분인데, 의뢰하는 경우 외주업체 입장에서는

단발성 프로젝트로 치부되는 경향이 있기 때문에, 고도화된 설계보다 프로젝트를 빨리 마무리하는데 중점을 두게 된다.

그래서 초기 스타트업이 외주 업체에 맡겨 개발한 초도 제품을 고도화시킬 때 쯤에는 새롭게 팀빌딩한 멤버들과 함께

처음부터 온전한 설계를 통해 새로 만드는 경우가 꽤 흔하다.

초기 스타트업은 개발 단가에도 민감할 수밖에 없는데, 무조건 싸게 진행하려는 것도 문제가 될 수 있다.

외주 업체는 특히 진행 비용에 맞추어 개발하는 경향이 있기 때문에 개발 단가는 제품 퀄리티에 영향을 크게 미친다.

만약 CTO에 버금가는 인력이 있었다면 단가 문제를 떠나서 외주를 주던, 개발자 팀원을 뽑던 위와 같이 발생할 수 있는 문제를 최소한으로 줄일 수 있었을 것이다.

물론 개발하려는 제품에 따라, 혹은 개발하는 개발자에 따라 위와 같은 문제가 없을 수 있고 의외로 순조로울 수도 있다.

하지만 많은 스타트업에서 이런 문제가 발생하고, 또 스타트업이 아니더라도 일반 기업에서 위시캣, 프리모아 등과 같은 개발 중개 사이트를 통해 진행하는 경우에도 개발에 대한 트러블이 꽤나 많이 발생하므로 위 내용을 어느정도 주의하는 것은 좋을 것 같다.