[안드로이드] - 클린아키텍처 - 0

클린 아키텍처에 대해서 공부하기 이전에 왜 아키텍처를 공부해야 하는지 알아보자.

 

쓴이는 안드로이드 개발을 하면서 정말 다양한 디자인 패턴과 아키텍처를 접했다.

MVC, MVP, MVVM, MVI 패턴 등등 또는 클린 아키텍처에 이르기까지 정말 다양하게 접했다.

블로그에서 트렌드라고 많이 나와있고 모르면 안된다는 생각에 그냥 사용법 익히면서 이런거구나 하고 넘어 갔었다.

 

섣부른 판단일 수 있겠지만 나와 같은 사람이 있을 것이다. 그래서 한 번 제대로 알아보려고 한다.

차근차근 정리해가며 알아가보자.

 

의문점 하나!

Design 과 Architecture 는 무엇인가?

 

설계와 아키텍처

• 설계(design) : 특정 유형의 문제를 해결하는 방법으로 아키텍처보다는 좁은 개념이다.
• 아키텍처(architecture) : 프로그램 내에서 큰 구조로 구성되어 다른 구성요소들을 관리하는 역할을 한다.

다시 말하자면, 설계와 아키텍처는 저수준 고수준 구조적 차이라고 생각하면 된다.

하지만 둘 사이를 마땅히 구분할 만한 경계는 가지고 있지 않다. 따라서 실제로 둘 사이엔 아무런 차이가 없다.

 

여기서 디자인 패턴의 개념은 개발자라면 정말 흔하게 접해봤을 것이다.

특히 MVC 패턴은 한 번씩은 접해보았을 것이다.

 

쓴이도 안드로이드 개발하기 이전에 백엔드 개발을 했었다.

그 때 Spring 프레임워크를 사용하면서 MVC 패턴을 적용하여 코드 작업을 했었다.

 

App과 Web에선 MVC 패턴이 다르다.

차이를 알고 싶다면 아래 글을 클릭해서 보면 될 것이다.

💡 웹과 앱 MVC 차이는?

Web - MVC Pattern

Web 에서는 입력은 Control 에서 발생하고, 이벤트가 발생한 Control 에 의해 모듈의 정의와 View 의 용도가 결정된다.

웹 MVC 동작 순서

App - MVC Pattern

안드로이드에서는 Activity 또는 Fragment 와 같은 View 들이 View 와 Control 를 모두 가지고 있다.

앱 MVC 동작 순서

 

 

이렇게 디자인 패턴은 소프트웨어 개발 환경에 따라 구조적으로 맞춰 사용할 수 있다.

 

아키텍처 또한 그렇다.

클린 아키텍처를 많이 들어보았을 것이다. 로버트 C. 마틴이 말한 클린아키텍처와 모바일 클린 아키텍처는 살짝 다르다.

이 부분은 이후 블로그 글로 다뤄볼 생각이다.

 

디자인 패턴과 아키텍처에 대해서 설명을 했었다.

둘 다, 좋은 구조적 설계를 하기위함을 나타낸다는 것을 알 것이다.

 

의문점 둘!

그럼 좋은 설계란 무엇인가?

 

아키텍처의 목표

소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다.

설계 품질을 재는 척도는 고객의 요구를 만족시키는 데 드는 비용을 재는 척도와 다름 없다.

이 비용이 낮을 뿐만 아니라 시스템 수명이 다할 때까지 낮게 유지 할 수 있다면 좋은 설계라고 말할 수 있다.

새로운 기능을 출시할 때마다 비용이 증가한다면 나쁜 설계이다.

좋은 설계란 이처럼 단순명료하다.

 

위와 같이 정말 아키텍처가 좋은 건 알지만 우린 왜 꾸준히 배우며 적용하는 사람이 많이 없을까?

 

의문점 셋!

실제로 적용해서 사용하는 빈도수가 적은 이유가 있는데 왜그럴까?

 

우리는 무엇이 잘못되었나?

개발자들은 현업에서 개발할 때 늘 고민에 빠진다.

"코드는 나중에 정리하면 돼."

"당장은 시장에 출시하는 게 먼저야" 라는 흔해 빠진 거짓말에 속는다.

 

우리는 안다. 나중에 작성한 코드를 다시 보는 일은 없다는 것을..

 

그냥 반복이다. 출시를 위해 빠르게 개발 후, 새로운 기능.. 또 다음 기능.. 그 다음 기능을 만드느라 정신없다.

이렇게 엉망진창인 코드가 서서히 쌓이면 개발자 생산성은 차츰 낮아지고, 코드가 엉망이 되는 추세는 절대 멈추거나 수그러들지 않는다. 이대로 간다면 생산성이 0에 수렴하게 될 것이다.

 

개발자가 속는 잘못된 거짓말

지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다는 생각.

이는 잘못된 생각이다.

 

해외 개발자 '제이슨 고먼' 이 수행한 실험이 있다.

 

위 그래프를 보면, TDD 를 적용한 개발이 생산성이 더 좋다는 결과로 나왔다.

 

위 결과를 볼 때 빠른 개발을 위해서 개발자는 처음 TDD 테스팅 적용을 위한 학습곡선이 발생하더라도, 장기적인 미래를 볼 때 테스팅에 필요한 프레임워크 스킬을 가지고 있어야 한다는 것이다.

 

앞서 말했듯, 구조적으로 생각하지 않고 지저분한 코드를 작성하면 단기간 내에 빠르게 개발한다는 생각은 

생각의 오류이다.

빨리 가는 유일한 방법은 제대로 가는 것이다.

 

 

정리

어떤 경우라도 개발 조직이 할 수 있는 최고의 선택지는 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.

 

그러기 위해선 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다.

 

비용은 최소화하고 생산성은 최대화할 수 있는 설계와 아키텍처를 가진 시스템을 만들려면 이러한 결과를 이끌어 줄 시스템 아키텍처가 지닌 속성을 알고 있어야 한다.

 

그래서 이젠 아키텍처에 대해서 제대로 알아보자.