[안드로이드]요즘 핫한 안드로이드 Mvvm 패턴을 공부하는 것..

 

안녕하세요. 개발자 삐질 입니다.

 

 

오늘은 요즘 구인 / 구직에 빠지지 않는 아키텍쳐 패턴 MVVM을 공부하는 것에 대한 개인적인 의견을

 

적어 보고자 합니다. (글 내용은 그렇지 않지만.. 하고싶으면 하시라고 미리 말씀 드립니다)

 

 

먼저 요즘 안드로이드 쪽에서 가장 핫한 MVVM은 Model / View / ViewModel이 합쳐진 용어입니다.

 

기존에는 MVC , MVP 등이 있었습니다. 최근엔 MVI 패턴도 또 올라오고 있죠?

 

그렇기에 요즘 신입의 시기에도 MVVM에 대한 질문을 많이 받곤 합니다.

 

 

이 글에서 MVVM의 정의나 MVVM이 뭔지에 대해서는 굳이 나열하지 않겠습니다. 왜냐면 저도 ...ㅎ......잘 사용하지 못 하고 있거든요.

 

그럼 이 글을 왜 쓰고 있냐 ? 라는 질문이 남게 되는데,

 

저도 일단은 MVVM패턴을 지향하고, 약 1년 반 정도 사용하고 있으며, 트랜디한 기술들에 관심이 많습니다. 하지만, 저와 같이 초급 개발자 수준에서 간과 하지 않아야 할 부분이 있어 꼭 다른 분들도 한번쯤 생각 해 보셨으면 해 글을 쓰게 됐습니다.

 

• MVVM을 왜 사용하고 공부하게 되었나? A: 남들이 좋다고 해서 ..

 

• MVVM을 사용하는게 잘 하고 있는 것 같나? A: 초기엔 Yes , 지금은 um.....

 

• MVVM을 앞으로도 계속 사용 할 것인가? A: Yes, 다만 사용하기만 할게 아니라 계속해서 공부 중

 

• MVVM을 초급 또는 신입 개발자가 바로 시작하는 것은 어떻게 생각하나? A: 반대합니다. 이유는 밑에서 좀더 자세히 말씀 드릴게요.

 

• MVVM을 꼭 배워야 하나? A: 네. 배워야 합니다. 언젠가는 다만, 본인이 필요성을 1 to 10 중에 3이라도 '정확히' 느낄 때

 

 

일단 앞서 말씀드린대로 저는 1년 반 정도 MVVM 패턴으로 안드로이드 코드를 작성 해 왔습니다. 하지만 최근에 들어서야 아..MVVM이 이런 느낌이긴 하구나. 그 동안 너무나 잘못 쓰고 있던 부분이 많구나 를 느낍니다.

 

저는 MVVM을 시작 할 당시 MVC도 사실 몰랐습니다. 말로는 

 

"M이 Model이고 V는 View고 C는 컨트롤러고 .. 안드로이드는 VC가 같이 있는 형국이고 M만 따로 있다. " 라던지, 

 

"비지니스 로직을 잘 만들어야 한다" 라던지..

 

 

"테스터블 하게 개발하기 위해 아키텍쳐 패턴으로 잘 설계해야 한다." 라던지 등등 

 

이런 이야기들이 굉장히 핫 했고 지금도 핫한 주제 이죠. 구직 시 채용 공고를 보면 필수 요건에 MVVM or Rx or TDD 이런 단어는 항상 들어가죠.

 

필수 요건이 아니면 우대 요건 이라도..

 

 

 

이런 추세 속에 저는 MVVM을 시작했고 나름 Github 이라던지 구글의 샘플 코드를 보면서 제가 알고 있는 지식대로 코드를 작성했습니다. TDD까지는 지식이 얕아 도입하지 못한 상태로.. 약 1년 정도 MVVM으로 개발을 하고 있을 때 어느날 문득 회사의 기능을 개발하고 있는 와중, 잦은 기획 변경에 스트레스를 받고 이런 생각이 들었습니다.

 

 

"아..왜 이렇게 자주 기획이 바뀌는거지? 또 MVVM이런거 쓰면 뭐 기획 자주 바뀌거나 컴포넌트 바뀔 일 있어도 바꾸기 쉽다매?? 근데 난 왜이래? " .. ->회사의 사수가 제 프로젝트를 볼 일이 있었는데  mvvm을 쓴다고 쓴것 같은데 게 짜면 디펜던시 줄줄 달고 다니는 거라는 이야기를 듣기도 했죠 ..

 

 

 

굉장히 어리석은 생각이죠. 늘 다른 MVVM의 소스를 보고 나름대로의 공부를 계속 하면서 "겉핥기"를 열심히 하고 있었으므로 제 스스로 잘못 짜고 있단 생각이 한 20% 정도 밖에 없었습니다. Databinding도 쓰고 뭐 Room도 쓰고 착착 신기술 써 가면서 확실히 MVC와 비슷한 형태로 짤때는 일일이 뷰 속성을 코드 하나하나 잡아서 수정할 때와 다르게 MVVM속에서 databinding으로 Livedata 써 가면서 편하게 잘 작성하고 있는 줄만 알았습니다.. 나름의 "편의"가 왕창 증폭이 된 것 이었죠.

 

 

귀찮은 Callback Interface도 안 쓰고, 알아서 Observe 가능하고 , LifeCycle 안에서 Observer가 보장이 되고 적당하게 프로그램은 돌아가고..

 

 

그런데 위 처럼 스트레스를 받는 시기에 문득 또 다르게 "그래.. 아키텍쳐 패턴으로 나눠서 잘 짜면 각 모듈간에 종속성이 약화된다는데 왜 난 아직까지 코드 하나 고치면 다른 거 연달아 고쳐야 하고, 또 이곳 저곳에서 사이드 이팩트가 나고, 수정은 또 왜 이렇게 어려운 거지?? 아... 내가 정말 크게 잘못 공부하고 있었구나 자만 했구나"를 드디어 깨닫게 됐습니다.

 

 

돌이켜 코드를 보니 저는 겉모양만 MVVM인 MVC(이 마저도..)를 짜고 있고, 아키텍쳐 패턴을 차치 하고 나서라도 펑션간의 종속성도 제대로 해결하지 못한 채 M / ViewModel / VIew 클래스만 나눠서 Mvvm이다~!!

 

그렇게 쓰고 있는 걸 발견하게 됩니다.

 

 

기본적인 규칙은 지켰죠 .ViewModel이 View를 몰라도 된다. Context가 viewmodel에 있으면 안된다. 등등

 

그러나 이런 제가 지키고 있던 규칙들은 제가 원해서 지킨 규칙이 아니라, 남이 지켜야 한다기에 따라 지킨 규칙입니다. 한 마디로 "왜?"는 모르고, "그렇게 하라니까" 하고 있었던 거죠.

 

 

또한 Github에 많은 Mvvm 예제 들을 보며, Mvvm이라고 올려놓은 프로젝트들이 각자 개발자 마다도 다른 스타일로써 사용하는 구나. 나도 '대충' 비슷하게 쓰면 내가 Mvvm을 쓰고 있는 거 구나 생각해 왔습니다.

 

요즘에야 그나마 각 레이어별로 성격을 지키려고 노력하면서 상호간 의존성을 약화 시키려고 하면서, 필요한 펑션 필요한 부분만 싹 고치면 알아서 돌아가게끔 최대한 신경 쓰면서 작성하는데 이걸 잘 모르고 쓰면 저와 같이 그냥 쓰고는 있는데 엉망인 상태가 됩니다. 

잘 지키면 Viewmodel 테스트 코드 작성하는데도 수월하고, Model UnitTest코드 작성 하는데도 수월하죠. 다른데 종속성이 약하니까.. 이 유닛을 테스트하는데 이 유닛 외에 다른 어떤 게 필요하지 않은 상태가 되니까..

 

 

물론 테스트 코드를 가끔 작성하긴 하지만 시간적인 여유나, 아직 게으른 부분 떄문에 정말 열심히 쓰진 못하고 있습니다. ( 또 회사에선.. 사실 테스트 코드 작성할 여유는 없습니다.) 해 봐야 증말 간단한 케이스??

 

 

제가 MVVM을 사용하고 있는 배경에는 이런 내용이 있고, 각설 하고 하고 싶은 말이 무엇이냐면,

 

 

"남들이 해라 해라 , 해야한다~ 필요하다 카더라~~" 라는 말 때문에 근본적으로 해야 할 공부를 놔 두고 엄한 데 시간 쓰는 건 아닌지 곱씹어 보셨으면 합니다.

 

 

저도 MVVM을 먼저 시작해 놓고 이제서야 느껴서 이런말을 할 상태가 되는지는 모르겠습니다만, 저와 같은 실수를 하는 분들이 없길 바라며..( 저는 회사의 팀장님께 개발적인 자세나, 이런 가치관들을 많이 배웁니다- <사수의 중요성>. 물론 그대로 수용하진 않지만 제가 겪고, 느끼는 바와 조언과 더불어 스스로 판단하는 편 입니다.)

 

• MVVM을 공부하기 전에 MVC는 제대로 지켜가면 짤수 있나? 한번 보세요. Model이 View가 Controller 가 각자의 역할을 지켜 가며, View의 속성을 Model에 집어넣고 이리저리 거미줄 처럼 엮어가면서 짜고 있진 않은가? 패턴에 구애 받지 않고 , 내 코드 짜는 스타일 자체가 단위별로 펑션이면 그 펑션이 해야할 일만 하는지, 한 펑션안에 이 일도 하고, 저 일도 하고 이 속성 수정하고 저 속성 수정하고 이런 상태로 작성하고 있진 않은지, 클래스는 그 클래스가 가지고 있어야할 속성들만 잘 다루고 있는지.. 결국엔 사실 이게 객체지향과 OOP개념인데 이것 조차 들어보지도 못한 상태로 MVVM을 하는 분들이 많습니다. 내가 각 레이어별로 역할이나 OOP Solid개념만 잘 알아도 사실 MVVM을 공부하는데 이해가 수월 할 거에요. 모르면 증말 외계어 써놓은 프로젝트들이 도사리고 있을 겁니다.

 

• MVVM을 왜 쓰는가? 를 생각 해 보세요. 단순히 구직에 이점을 얻기 위해?? ......... 제가 보기엔 구인 구직란에 요강 속 내용중 MVVM필수요건 또는 MVVM 우대요건 써놓은 공고 중 그 팀에 그 패턴 , 그 기술 기깔나게 잘 지키고 있는 조직 보다 , 저와 같은 경우로 프로젝트를 이어가고 있느 케이스가 더 많을 것 같습니다. 왜냐면 옆 회사 MVVM쓰고 Dagger쓰고 하는데 우리 회사 사람들은 레거시 쓸 순 없거든요. 너도 나도 MVVM하거든요. 단, 내가 MVVM을 기가막히게 쓰고 있어야만 그런 요건을 내세울 수 있다는 것은 아닙니다. 아직 기존 단체원도 미숙하지만 비슷하게 아는 사람들을 영입해 같이 배워나가며 성장하고자 할 수도 있으니까요. 다만, 요지는 내가 기본적으로 코딩 클래스 하나 만드는게 어렵고, 안드로이드 컴포넌트가 뭐가 있는지도 모르고, 내 코드가 잘 짜고있는건지 아닌건지 내 코드작성의 스타일은 확고한지, 신념은 있는지 이런 자기 판단도 없는 상태에서 MVVM을 해봤자 그 회사가 정말 MVVM을 잘 쓰거나, 또 쓰고 있지 않다 한들 나를 면접 보는 분이 진성 실력이 좋으신 개발자면 내가 어설픈 MVVM프로젝트를 들이 민다고 해도 밑천이 훤히 드러나 보이기 마련입니다. MVVM을 도입하려고 할땐, 그 근본 목적에 작은 단위의 모듈화 , 테스트의 이점 , 내가 가진 상황에서 MVVM을 마냥 맹목적으로 지향하는게 맞는가. 이런 부분들을 반드시 생각 해 보고 작성을 하셔야합니다. ( 실제로 본인 회사에서 MVVM을 써서 본인도 MVVM을 쓰는데 질문을 들어보면 ...??????싶은 분들이 많이 보입니다)

 

• 그렇다고 내가 아예 못 짠다고 MVVM을 공부하지 말란 소리냐? 는 절대 아닙니다. 해야합니다. 위 말처럼 대세는 MVVM이니까요. 그렇지만 MVVM을 공부 할 거면, 그 이전 MVC MVP 더 이전, 내가 코드 짜는 개념, 신념, 가치관등 부터 내가 개발하고 있는 플랫폼의 근본적인 기초 부터 주목 하셔야 할 부분 입니다.

 

이런 질문들을 받습니다.

 

 

a. MVVM하는데 Viewmodel1이 Viewmodel 2를 가지고있고 Adapter에 그 Viewmodel들을 다 집어넣고 하고있는데 뭐가 안돼요.

 

 

a. ViewModel에 컨텍스트를 넣어서 쓰고싶은데 어떻게 하나요

 

 

a. Livedata를 왜 쓰나요?

 

 

a. Viewmodel에서 액티비티를 생성 했어요.

 

 

등등 사실 이거는 MVVM을 왜 쓰는 지 조차도 모르는 상태에서 코드만 짜고 있는 상태 거든요.

 

시간 아까워요 이 상태에서 MVVM을 하는 건. 이런 질문을 하시는 분들은 MVC형태로도 못 짤 확률이 커요.

 

보통 VC만 있죠. M은 없는 코드..

 

MVC로 코드를 짜다 보면, 아.. 좀 특성별로 분리하고, 이거 좀 재사용하고 싶고, 이거 재사용 하려는데 저거랑 연관 있으니까 좀 .. 연관 없게 짜면 좋지 않을까? .. 세분화 해서 , 각 컴포넌트 별로 나누고, View를 조작하는 놈 , 실제 필요한 데이터만 다루는놈 쪼개면 분리가 쉽지 않을까? 뭐 이런 의문점들이 생길 때 그떄 MVVM이나 MVP나 MVI나 다른 것들에 눈돌릴 필요성이 생깁니다.

 

 

거미줄같은 MVVM 칠해놓은 프로젝트보다 나름의 스타일로 MVC라도 잘 지켜서 제출한 과제, 그런 걸 기반으로 본 면접이 오히려 같이 일할 사람으로 더 반갑습니다.

 

 

그리고 가장 중요하게.. 아키텍쳐 패턴을 나누고, 종속성을 약화시키고 하는 주요 원인은 테스트를 원활하게 하기 위해서에요.. 테스트를 하기 쉽게 만들려면 뭐 하나 실행하는데 이것저것 다른게 영향이 있으면 안 되니까 종속성을 약화시키는거고.. 종속성이 약하면 어떤 부분을 고쳐야 했을 때 다른 부분이 영향을 받아서 내가 모르는 또 빈번한 사이드 이팩트를 줄이고자 함 입니다.

 

 

물론 아키텍쳐 패턴이라던지 이런 것들이 단점도 있지만 규모가 크거나 프로젝트의 복잡도가 클때 잘 지킨 구조의 프로젝트라면 어디 대충 어떤 부분 보면 뭐가 있겠고, 이런 부분 수정하면 괜찮겠고. 영향도 없겠고 이런 결과들이 나오겠죠.

 

 

디자인 패턴이라는 것에 대해서 무조건 좋다, 무조건 나쁘다, 적당히 지키자 여러 의견이 있습니다. 개발자 마다도..

 

그치만 내 상황과 비용이 허락된다면 구조를 잘 지키고 잘 나누고 서로 모듈간의 종속성을 약화시키고.. 이런 부분에 대해서 나쁘다고 하는 개발자는 많지 않을 거라 생각합니다.

 

 

"필요한 지도 모르는 데 남들이 좋다 카더라 하는 말만 듣고 정작 중요한 것을 놓치지 말자."

 

 

 

초급 안드로이드 개발자를 위한 카카오톡 오픈 채팅방을 운영 중 입니다.

 

(저는 마냥 친절한 방장은 아닙니다. 다만, 다 같이 성장하고 싶은 방장이며 개발자 입니다)

 

https:open.kakao.com/o/gH0XvThc//open.kakao.com/o/gn4xqQ6