애자일 방법론에서 개발은 MVVM 구조로 개발하는 것이 적절한가?

이 글은 제가 그간 개발하면서 경험한 애자일과 MVVM 구조 패턴에 대한 내용을 정리 글입니다.

 

애자일을 처음 접했을 때 서비스를 기준으로 팀을 구성하고 하나의 공통된 목표를 가지고 일하는 방법이 생소하지만 너무 마음에 들었습니다.  하지만 3~4개월이 지났을 때는 앱의 기능을 변경하는 것도 추가하는 것도 두려웠습니다.

전체 서비스에 대한 기획이 존재하는 것도 아니었고 처음 개발할 때부터 모든 기능을 염두해두고 개발한 것이 아니었기에 코드 복잡도는 계속 증가하고 있었고 그에 따라 기능 하나 변경할때도 다른 곳에서 사이드 이펙트가 발생할까 걱정이 되어 마음이 조마조마했습니다.

 

코드 복잡도가 한순간에 올라간 것이 아닌 차근 차근 올라간 것이라 처음에는 무슨 문제인지 인지를 못하고... 

왜 이렇게 힘들지? 애자일이 이렇게 힘든건가? 라며 되도 않는 생각을 하다가,

그것이 애자일의 문제가 아닌 저의 개발 방식의 문제라는 것들 깨닫고 이를 해결 하기 위해 많은 고민을 했습니다.

 

제가 느낀 문제는 두 가지 였습니다.

• 시간이 갈 수록 늘어가는 코드 복잡도 증가 최소화
• 빠르고 안정적인 배포를 위한 테스트 자동화

"코드 복잡도가 증가 최소화" 해결 방안

2주 단위로 배포하던 앱을 3주나 4주 단위 배포로 변경하는 방안은 바로 기각하고...

고민하던 도 중 기능을 변경할 때 크게 세가지로 나뉘는 것을 깨달았습니다.

• 기능 변경 없이 화면 구성 요소만 변경되는 경우,
• 기능과 화면 모두 변경되지만 굳이 서버 API 변경이 필요 없는 경우,
• 기능과 화면 모두 변경되고 서버 API 변경까지 필요한 경우,

 

이부분은 화면만 변경되느냐? 비지니스 로직까지 변경되느냐?의 문제란 것을 앍고 나니 

코드 복잡도 증가의 원인이 무엇인지 파악되었습니다.

원인은 급하다고 마구 개발한 코드의 문제였습니다.

최초 애자일을 대할 때 기획서나 전체적인 기능 정의가 없어 설계가 어려워 구조 설계를 무시하고 개발을 시작하고 나중에 어느정도 윤곽이 잡히면 구조도 다시 설계하자! 라고 생각했는데... 개발 시작한지 얼마 되지도 않은 앱의 구조를 뒤엎으려는 시도는 시간 부족과 주위의 따가운 눈총으로 인해 무산되었습니다. ㅠ_ㅠ

 

이때 애자일에서 꾸준하게 앱을 유지 관리하기 위해서는 앱의 구조가 매우 중요하다는 것을 깨달았습니다.

 

"코드 복잡도 증가를 최소화"하기 위해서는 비지니스로직과 화면이 서로 독립적으로 유지될 수 있는 구조가 필요했고 이에 도입한 것이 MVVM 패턴 입니다.

 

"빠르고 안정적인 배포를 위한 테스트 자동화"

테스트 자동화는 MVVM 패턴을 도입함으로써 자연스레 해결 되었습니다.

MVVM 패턴은 제대로만 구현한다면 UI Test 뿐만 아니라 UNIT Test도 가능하기 때문에 수정되거나 추가된 모든 기능에 대한 테스트 자동화가 가능해졌기 때문 입니다.

 

이런 서론을 쓰다가 결론을 내어버렸네요.

그래도 잘 모르시는 분들을 위해 제가 경험한 "애자일"과 "MVVM"을 정리해보겠습니다.

 

"애자일"

이전에 회사들은 새로운 서비스를 만들기 위해 수개월동안 시간을 들여 철저히 시장조사를 하고 시장조사한 내용을 기반으로 다시 수개월의 기획을 하고 승인이 난 후에 디자인하고 개발을 진행하였는데 이러한 방식을 전통적인 워터폴 개발 방법론이라고 합니다.

하지만 시장이 빠르게 변화하면서 회사는 더이상 수개월동안의 시간을 시장조사에 기획에 사용할 수 없게 되었습니다.

왜냐하면 시장조사를 하고 기획을 수개월동안 하게 되면 그 사이에 시장은 저만치 앞서가 있기 때문에 구식 기능을 만들게 되어 시장에 뒤쳐지기 때문 입니다. 

이에 회사들은 빠르게 시장에 대응할 수 있는 새로운 개발 방법론을 찾았고 이에 탄생한 것이 애자일 개발 방법론 입니다.

애자일 개발방법론은 전통적인 워터폴 방법론과는 다르게 단계적으로 모든 것을 기획하고 개발하지 않습니다.

진입하고자하는 시장의 핵심 요소를 파악하고 사용자를 구분해 구분한 사용자에 맞는 핵심 요소(MVP) 기능을 우선 기획하고 개발합니다.

이렇게 개발한 MVP를 시장에 내놓고 사용자의 반응을 보면서 기능을 수정하거나 추가하는 방식입니다.

단순히 말해 애자일 방법론은 무수히 많은 "기획->디자인->개발"을 반복하는 방법론이라고 할 수 있습니다.

 

(여담: 이건 책이나 인터넷에 나오는 이야기이고 제가 경험하기로는 소규모 회사들이 인력 구하기 힘든 상황에서 개발자에게 그냥 다 떠넘기면서 애자일 이라고 하는 경우도 있는 것 같아요... ㅠ_ㅠ)

 

하지만 서비스도 그렇고 조직도 그렇고 아무리 쉬운 것이라도 단순하게 돌아가지 않습니다.

조금 더 세부적으로 이야기해보면 시장에 빠르게 대응한 다는 것은 서비스를 주기적으로 업데이트 한다는 이야기 입니다.

이를 수행하는 조직은 서비스를 주기적으로 업데이트하기 위해 빠르게 의사소통을하고 기획하고 개발하여야 합니다.

기획자와 디자이너 그리고 개발자가 속한 조직이 서로 다르다면 의사소통을 하는데에만 며칠의 시간을 버려야 합니다.

 

이런 의사소통 시간을 최소화 하려면 서비스를 구성하는 모든 구성원이 수평한 관계에서 한개의 조직으로 구성되어야 합니다.

* 이러한 조직 구조는 기존 회사에서 중요한 프로젝트를 수행하기 위해 회사의 역량을 한 곳에 집중할 필요가 있을 때 자주 사용하던 TF(Task Force)팀과 유사하다고 볼 수 있습니다.

 

* TF팀과 애자일팀의 차이점은 TF팀은 개발할 것과 기한이 명확히 정해진데 비해 애자일팀은 개발할 것 보다는 목표가 명확하고 기한이 없다는 것이 차이점이라고 볼 수 있습니다.

 

그리고 이렇게 꾸려진 애자일팀은 그 서비스에만 온전히 집중할 수 있어야 합니다.

그렇지 않다면 서로 다른 업무를 하느라 시간이 지체 될 수 있으니까요.

 

그리고 서로 다른 직군을 한개의 조직으로 묶는 것도 쉬운 일은 아닙니다.

기획자는 기획자끼리, 디자이너는 디자이너끼리, 개발자는 개발자끼리 뭉쳐있고 싶어하니까요.

이는 본능적인 것으로 누구를 비난할 것이 아닙니다.

 

서로 다른 직군의 인원을 하나의 조직으로 묶고 주기적으로 서비스를 업데이트하는 것은 절대 쉬운 것이 아닙니다.

그림에는 없지만 여기서 중요한 것이 리더의 역할 입니다.

리더는 조직이 서로 다른 직군의 구성원들이 모여서 생기는 갈등을 최소화하고 이를 해소하면서 프로젝트 오너가 원하는 방향으로 프로젝트를 이끌어나가야 합니다. 이를 위해 리더는 여러가지 방법(플레잉 포커, 칸반, 스프린트, 회고, ...)을 사용하여 조직을 유지 관리해야 합니다.

 

 

애자일을 설명하기 위해 항상 나오는 것이 워터폴 방법론인데 두 방법론은 다음과 같은 차이를 보입니다.

워터폴은 기획과 디자인 그리고 개발의 책임 범위가 명확한 반면 애자일 방법론은 모호합니다.

워터폴은 프로젝트의 시작부터 끝까지 해야할 일이 명확한 반면  애자일 방법론은 모호하고 중간에 바뀔 수도 있습니다.

 

워터폴이 정해진 서비스를 만드는데 비해 애자일은 빠르게 변화하는 시장에 대응하기위해 만들어진 임무 조직입니다.

즉, 애자일은 정해진 서비스가 아닌 임무를 완수하기 위해 만들어진 조직이므로 중간에 임무 완수 조건이 바뀌면 얼마든지 서비스가 바뀔 수 있습니다.

 

그리고 우리가 애자일에 대해 잘 못 알고 있는 것 몇가지!!!

1. 애자일 조직이 시장변화에 반드시 빠르게 대응하는 것은 아닙니다.

가끔 아니 심지어는 자주 워터폴 조직보다 더 못한 대응을 보일 때도 있습니다.

 

2. 애자일 조직이 지속적으로 대응하는 시장변화가 항상 긍정적인 것만은 아닙니다.

가끔이 아닌 자주 시장변화를 제대로 읽지 못하는 실수를 합니다.

 

3. 조직에 모인 사람들이 공통의 목표를 가지고 하하호호 웃으면서 일을 하지는 않습니다.

서로 다른 조직에 있을 때에도 의견 충돌이 있었는데 한 조직에 있다고 의견 총돌이 사라지지는 않습니다.

 

애자일의 문제점

애자일 조직은 변화하는 빠르게 시장에 대응하기 위해 지속적으로 대응하는 임무형 조직입니다.

이러한 임무형 조직은 기존에 TF로 꾸려졌고 한시적으로만 운영했습니다.

왜 한시적으로 운영했을까요? 이유는 아래와 같은 문제들 때문 입니다.

• 기존 회사 조직구조와 맞지 않는 문제
• 임무형 조직의 피로도 증가

이러한 문제가 애자일을 한다고 해서 사라지는 것은 아닙니다.

기존 업무형 조직으로 운영하는 회사가 애자일을 도입한다고 하면 엄청난 반대에 부딫치게 됩니다.

또한 그러한 반대를 무릅쓰고 애자일 조직으로 개편했다고 해도 임무형 조직의 높은 피로도로 인해 더 큰 문제에 봉착하게 됩니다.

 

이렇게 써 놓고 보니 애자일이 안좋은 것 같은데 애자일은 적어도 워터폴 보다는 좋은 방법론 입니다.

그러기 위해서는 우선 회사가 그리고 각 구성원이 애자일 방법론에 대한 이해가 있어야 하며 반드시 애자일 조직을 이끌어갈 리더가 있어야 합니다.

 

기존 PL이나 PM이 애자일 리더가 되면 되겠다라고 생각하는 분들은 절대 애자일 조직에 찬성하시면 안됩니다.

제가 언급하는 애자일 리더는 애자일 조직의 비젼 제시, 구성원들간의 갈등 그리고 회사와 조직간의 갈등을 이해하고 조율할 수 있는 지식을 가지고 있는 사람입니다.

 

애자일이 만능은 아닙니다.

하지만 워터폴 보다는 나은 방법론입니다.

제대로된 리더만 있다면...

 

 

MVVM이 뭐지? 그리고 그게 애자일과 무슨 상관이지?

MVVM은 아주 좋은 개발 구조 패턴 입니다.

만들려는 서비스를 화면이나 기능 위주의 구분에서 그치는게 아니라 레이어 단위(Model, ViewModel, View)로 구분하여 독립적으로 개발할 수 있도록 해주는 패턴이기 때문 입니다.

간단히 설명하자면,  MVVM 패턴의 가장 큰 장점은 View와 Model 사이의 의존성을 없애 서로 독립적으로 존재할 수 있도록 한다는 것이며, 이것을 다른말로 바꾸어 말하면 서로 독립적으로 존재하므로 TDD 가 가능하다는 장점이 있다는 것 입니다.

MVVM의 장점은 각 기능을 독립적인 레이어 단위로 구획화하고 이를 테스트 가능하게 한다는 점입니다.

 

개발자라면 흔히 겪었을 문제 중 하나가 별거 아닌 줄 알고 코드 몇줄 고치고 고친 부분만 확인하고 배포했더니 상용 서버에서 난리가 나는 상황입니다. ㅠ_ㅠ

 

기능이 추가되고 서비스가 오래되고 개발자가 바뀌고, ... 이러한 변화의 과정속에서 어느 누구도 해당 서비스의 코드에 100% 장악력을 가질 수는 없습니다.

설령, 100% 장악력을 가지고 있다고해도 매번 수정 시마다 모든 기능을 확인할 수는 없습니다.

그게 두려워 아무런 것도 하지 않을 수도 너무 방어적으로 나갈 수도 없습니다.

 

"그련건 개발자가 꼼꼼히 확인해야지!"라는 개소리는 잠시 접어두고...

 

서비스가 커지고 기능이 추가되고 개발자가 변경될때마다 레거시 코드에 대한 기술부채가 증가합니다.

증가한 기술부채는 더 많은 개발 기간을 필요로 합니다.

 

어떻게 해서든 이렇게 증가하는 부채를 줄여야 합니다.

 

애자일 조직의 피로도가 증가하는 가장 큰 이유 중 하나가 기술부채(너무 잦은 서비스 업데이트로 인해...) 증가에 따른 문제 입니다.

초창기 개발할 때는 고려할 사항이 별로 없으니 기획이던 개발이던 빠르게 개발하면 되지만 어느정도 시간이 지난 시점에는 각 기능들이 서로 맞물려 뭐하나 고치기 쉽지 않은 상황이 됩니다.

하지만 이를 모르는 리더는 왜? 이렇게 개발이 늦어져요? 이게 그렇게 오래 걸리는 기능이예요? 라며 개발자를 채근하고 

그동안 서로 감정이 쌓여 있던 구성원들도 이때다 하면서 묵은 감정을 털어내는 최악의 상황이 발생할 수 있습니다.

 

개발자는 영리하게 기술부채가 증가하는 것을 막아야 합니다.

(제발 본인이 코드 장악력을 100%로 유지해 기술부채를 막겠다는 되도 않는 생각은 하지도 말고...) 

 

기술부채의 증가를 막아주는 방법 중 하나가 테스트 자동화 입니다.

테스트 자동화와 MVVM 패턴이 기가막히게 궁합이 좋습니다.

View와 Model이 분리되어 있기 때문에 UI Test 뿐만 아니라 UNIT Test 까지 가능해 테스트 자동화로 서비스의 거의 모든 부분을 꼼꼼하게 확인 할 수 있습니다.

  - View 부분은 UI Test로 

  - ViewModel과 Model은 UNIT Test

 

 

애자일 조직에서 MVVM 패턴을 사용해 서비스를 개발한다면 서비스의 잦은 업데이트에 따른 피로드 증가와 기술부채 증가를 상당부분 막을 수 있습니다.

 

설명하는 김에 마지막으로 조그만 더...

 

개발자가 2명 이상일 경우 MVVM 패턴에서 역할 분담은 어떻게 하는 것이 좋을까요?

A 너는 게시판이랑 방명록 기능 개발하고 B 너는 대시보드랑 통계 기능 개발해... 로 역할 분담하면 안됩니다.

애자일의 특수성상 서비스에 대해 완벽하게 설계하고 시작할 수 없기 때문에 각자 기능별로 영역을 구분하고 개발하게 되면 

한개의 서비스에서 서로 다른 두 개의 MVVM 패턴을 볼 수 있습니다. ㅠ_ㅠ

 

가급적이면 View와 ViewModel, Model로 구분해서 역할 분담을 하는것이 좋습니다.

A가 서비스의 ViewModel과 Model을 담당하여 개발하고 이를 UNIT Test로 검증한 후 View 개발자인 B에게 전달하고

B는 자신이 개발하는 View에 ViewModel을 연결하는 식으로 개발한다면 독립적인 개발이 가능합니다.

 

이부분이 익숙해지고 안정화되면 그때 A와 B가 역할을 바꾸어서 하면 됩니다.

 

다시 주제로 돌아가 "애자일 방법론에서 개발은 MVVM 구조로 개발하는 것이 적절한가?"라는 질문에 제 답은 "완전히 맞습니다." 입니다.

 

 

정리

현재 우리는 알게 모르게 많은 서비스를 애자일 방법론으로 개발하고 있습니다.

많은 회사들이 개발자를 채용할 때 애자일을 이야기하고 스프린트와 칸반을 이야기합니다.

그리고 많은 회사들이 서비스를 개발 할 때 애자일을 적용하고자 합니다.

 

몇번 경험해보았지만... 애자일 절대 쉽지 않습니다. 

 

애자일은 기획자가 없는 것이 아닙니다. 

애자일을 제대로 하고자 한다면 정말 시장을 보고 GA등으로 서비스를 분석하고 구글 드랜드 분석 등으로 사용자를 분석해 구분하고

원하는 서비스의 MVP를 빠르게 도출할 수 있는 역할을 하는 담당자는 필요합니다.

기획자를 뽑거나 이 업무를 구성원들이 분담해야 합니다.

 

애자일은 절대로 빠른 개발 방법론이 아닙니다.

애자일은 정말 필요한 기능을 최소한의 시간을 사용해 만든 후 시장에 선보이고 시장의 반응을 보면서 개선해 나아가는 방법론 입니다.

즉, 필요한 기능을 정해진 기한까지 예쁘게 잘 만들어서 시장에 선보이는 것 입니다.

급하게 만들어 빨리 출시하는 것이 절대 아닙니다.