안녕하세요 LONER입니다. 이미 머릿속에 코딩이 가득찬 사람이 되어버렸습니다. 저번에 포스팅 했었던 구글링 하는법에 이어서 본격적인 개발 이야기를 남겨볼려고 합니다. 기초적인 개발이야기부터 차근히 적으며, 블로그는 기초를 다져가는 용도를 사용해볼 생각입니다.
오늘은 소프트웨어 설계가 왜 필요한지에 대한 생각을 정리해서 남겨보려고 합니다. 차근히 지식을 밞아가며 소프트웨어 장인이 될때 까지 끊임없이 전진하고자 합니다. 앞으로 어떤 주제로 포스팅을 남길지는 제 임의대로 고를 생각입니다. 매번 포스팅 주제는 다르지만, 글의 지식 수준을 차근히 높혀가며 하나하나 정리를 해서 올린다는 기분으로 작성해보려 합니다.
설계가 필요한 이유?
"나는 수 많은 앱을 만들었다. 수 많은 시스템을 구축했다. 그리고 이 모두를 경험하고 고민한 끝에 놀라운 무언가를 깨달았다. 아키텍쳐 규칙은 동일하다!"
"1966년에 살던 컴퓨터 프로그래머를 2016년으로 데리고 와서 그를 인텔리제이가 실행되는 내 맥북앞에 앉힌 후 자바를 보여주면 충격에서 벗어나는데 아마 24시간이면 충분할 것이다. 그리고는 곧바로 코드를 작성할 수 있게 될 것이다. 자바와 C와 그다지 다르지않고 심지어 포트란과도 큰 차이가 없다."
"코드는 여전히 순차 분기 반복의 집합체 일뿐이다." - 클린아키텍쳐 By.로버트 C 마틴
일단 저의 부족한 지식보다는 소프트웨어 설계 관련책인 클린 아키텍쳐에서 정리한 내용을 위주로 살펴보도록 하겠습니다.
어떤 실제 과거 회사에서 IT 직원수가 10명 미만으로 시작해 세월이지나 it 직원이 1200명 까지 늘어났습니다. 반면 같은 코드의 줄수로 회사의 생산성을 계산했을때 처음 직원이 급증할때 코드 수가 증가했지만 시간이 지날수록 아무리 직원수가 늘어도 생산성이 늘지 않고 일정한 현상이 일어납니다.
"무언가가 명백히 잘못되었다. 매번 새로운 기능을 출시할 때마다 개발자의 수는 지속적으로 증가했지만, 코드 생산성은 마치 한 곳으로 수렴하는 것처럼 보인다." - 클린아키텍쳐 목차_설계와 아키텍쳐란?
그 다음 무서운 상황을 이야기합니다. 회사 운영 초반에 코드 한라인당 30달러 미만 이었지만 직원수가 1200명이 되었을 때 코드 라인당 비용이 370 달러 가까이 치솟습니다. 하지만 앞서 말했다시피 생산성은 아무리 직원을 채용해도 꾸준히 일정한 상황이 이어집니다.
"이처럼 생산성을 현저하게 변화시킨 요인은 대체 무엇인가? 여덟 번째에 출시한 제품의 코드는 처음 제품보다 왜 40배나 더 많은 비용이 드는가?" - 클린아키텍쳐 목차_설계와 아키텍쳐란?
시간이 지나도 인력은 늘어나지만 생산성이 현저하게 떨어지는 상황이 진행되는 상황은 계속 진행됩니다. 여기서 개발자 입장에서 보자면 지독한 절망감을 안겨줍니다. 왜냐하면 모두가 열심히 일을 하고 있는 상황임에도 잔업을 하며, 개발자의 노력은 기능 개발보다는 엉망이 된 상황에 대처하는 데 모든 에너지를 쏟기 시작합니다.
심지어 사소한 기능을 추가하는 일도 그저 엉망이 된 코드를 이곳에서 저곳으로, 다시 다음 곳으로 이동하는 반복작업으로 변질되게 됩니다.
경영자 입장에서 본다면 첫 번째 출시에는 수십만 달러의 인건비만으로 제품을 전달 했었습니다. 두번째 출시 때는 첫번째보다 수십만 달러가 더 들었고 여덞 번째 제품 출시에 들어섰을 때 월 인건비는 2천만 달러가 지출되는 상황이 옵니다. 심지어 이전 보다 훨씬더 많은 금액이 지출됬음에도 많은 기능을 탑재할 수 없는 상황이 되었다고 합니다.
"무엇이 잘못 되었을 까? 생산성이 믿기 힘들 정도로 낮아진 원인은 무엇인가? 그저 발을 동동 구르며 개발자를 향해 고함치는 일 외에, 경영자는 무슨 일을 할 수 있는가?" - 클린아키텍쳐 목차_설계와 아키텍쳐란?
이 책에서 많은 개발자는 "코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!" 라는 흔해빠진 거짓말에 속는다고 합니다. 이렇게 속아 넘어간 개발자는 나중에 코드를 정리하는 경우는 한 번도 없다고 합니다. 그 이유는 시장의 압박은 절대로 수그러들지 않기 때문입니다.
개발자의 상황을 보면 만들어야 할 기능을 만들면 다음 기능을 만들어야 되고 또 그 다음 기능, 다시 다음 기능 계속 만들어야할 기능들이 기다리고 있기 때문입니다. 이렇게 쌓이고 쌓이다 보면 생산성은 0을 향해 달려가기 시작합니다.
"토끼가 자신의 빠르기를 과신한 것과 마찬가지로, 개발자도 생산성을 유지할 수 있다고 자신의 능력을 과시한다. 하지만 엉망진창인 코드가 서서히 쌓이면 개발자 생산성은 차츰 낮아지고, 코드가 엉망이 되는 추세는 절대 멈추거나 수그러들지 않는다."
또한 이책에서 언급하길, 개발자가 속는 더 잘못된 거짓말은 "지저분한 코드를 작성하면 단기간에 빠르게 할 수 있고, 장기적으로 볼 떄만 생산성이 낮아진다" 는 견해라고 언급합니다.
그 다음 제이슨 고먼이라는 사람이 진행한 실험을 얘기합니다. 제이슨은 6일 동안 하루마다 같은 프로그램을 만드는 테스트를 진행했는데 처음 3일은 TDD (테스트 주도 개발)를 이용해 개발을 했고 나머지 3일은 사용하지 않는 개발과 비교해 테스트를 진행했습니다.
그리고 뚜렷한 차이를 보이는 결과가 나타나게 됩니다. TDD를 적용한 3일에는 작업시간이 24분 ~26분 사이로 측정이 되었고, TDD를 적용하지 않는 3일은 28분~30분 사이로 측정이 되었습니다. 이 사실을 통해 저자는 이렇게 이야기 합니다.
"생산성이 감소 되고 비용이 증가하는 현상을 되돌릴 수 있는 유일한 방법은 개발자로 하여금 토끼처럼 과신하려는 믿음을 버리고, 만들어 낸 엉망진창 인 코드를 개발자가 책임지도록 하는 것 뿐이다." - 클린아키텍쳐
이 책에선 설계를 고려하여 제품을 만들어 운영하지 않을 경우 일어난 실제 회사의 사례와 실제 진행된 테스트로 설계의 중요성을 매우 강조합니다. 그리고 앞서 얘기했던 생산성의 문제를 해결할 유일한 방법은 개발자의 과신과 고집을 버리고 소프트웨어 아키텍처의 품질을 심각하게 고민하고 시작하는 일이라고 합니다.
이제부터 제 경험 에 대해 이야기 해보도록 하겠습니다. 맨 처음 이책을 접했고, 제 스승님을 통해 아키텍쳐에 관해 이야기를 들었을 때, 기능과 상관없어 보이는 설계의 중요성을 머리로만 수긍하고, 마음 깊이 이해는 되지 않았습니다. 하지만 소프트웨어를 제작하는 경험이 쌓이면 쌓일수록 소프트웨어의 유지보수나 새 기능추가가 들어가는 순간 설계가 얼마나 중요한 것 임을 깨달았습니다.
제가 경험한 일을 이야기하자면 예전에 안드로이드 앱 개발로 2개의 앱이 외주 의뢰가 들어왔습니다. 하나는 jatpack이나 데이터바인딩을 쓰지 않고 뷰 바인딩 사용과 액티비티를 뷰와 컨트롤러로 사용하는 기본 mvc 구조로 진행 했었습니다. 이 앱을 MV라 하겠습니다.
(혹시 이글을 읽는 사람이 안드로이드와 관련이 없거나, 코딩 아직 설계에 대해 익숙치 않으실 경우 현재 2021년 안드로이드 개발에서 권장해준 아키텍쳐 방식을 고려하지 않고 만들었다 생각하시면 됩니다. )
다른 하나는 데이터바인딩과 싱글액티비티 체제로 잿팩 라이브러리를 사용하여 aac가 권장하는 아키텍쳐로 최대한 맞춰 만들어 진행했습니다. 관심사 분리로 뷰, 뷰모델, 레포지토리, 모델로 각각의 책임을 나누었고 liveData로 뷰의 변화를 관찰하여 옵저버 패턴으로 진행하는 mvvm 개념을 최대한 적용하면서 최대한 액티비티와 프레그먼트를 가볍게 하려고 노력했습니다. 이 앱을 MVVM 이라 하겠습니다.
(안드로이드와 관련이 없으실 경우 2021년 안드로이드에서 권장하는 아키텍쳐 가이드를 최대한 지킬려고 노력했다고 이해하시면 될겁니다.)
두개 다 물론 다른 앱이었지만 구조는 비슷 했습니다. (흔히 자주 볼 수 있는 구조인 바텀 네비게이션을 두고 각각 프레그먼트로 이동하는 구조) 상황에 따라 맞는 아키텍쳐는 다르겠지만 확실한건 두개 다 크게 기능이 추가될 앱들이었고, 앞으로의 유지보수를 생각 했을 때 AAC를 최대한 활용 하는것이 최적인 앱이었을겁니다.
(공식문서 안드로이드 아키텍쳐 가이드에 나온 권장사항을 적용하는것이 최적이란 얘기입니다.)
1. MV 이름의 명칭을 가진 앱
MV는 확실히 초반 작업속도가 매우 빨랐습니다. AAC를 지키기 위한 셋팅 시간은 필요 없었으며, 프레임워크에서 기본 제공해주는 형식을 별다른 라이브러리 셋팅 없이 이용해서 편하고 로직 구현하기에 신경 써야할게 적었습니다. 하지만 어느정도 앱의 코드가 많이 쌓이기 시작했을 때 View와 로직들이 한곳에 많이 엉켜서 새로운 기능 넣을 때 예상치 못한 버그가 발생하고, 그 버그를 수습하느라 더 많은 시간이 소요가 되었습니다.
그래서 작은 기능을 추가 할때마다 상당히 고민 하는 시간이 늘기도 하며, 버그가 발생했을 때 해결속도가 매우 느렸습니다. 예시로 A라는 기능 구현을 할 때 맨 처음에는 30분이라는 시간이 걸렸다면 나중에 가서 A와 비슷한 기능을 넣을 때 1시간~2시간 소요됬습니다. 혹은 예상치 못한 버그 발생으로 삽질을 진행해 그 날 하루를 아예 소비한 기억도 있습니다.
2. MVVM 이름의 명칭을 가진 앱
반면, MVVM은 처음에 신경써야할 부분이 너무 많았습니다. 베이스 액티비티, 베이스 프레그먼트, 네비게이션 셋팅, 뷰모델 셋팅, 역활에 맞는 분리 고려, 데이터바인딩으로 인한 잔 버그와 레포지토리 셋팅 등등 신경써야 할게 많았습니다. (안드로이드 스튜디오 라이브 템플릿을 쓰고도 할일이 많았네요)
그래서 초반에 A라는 기능을 구현 할때 40~50분 사이로 시간이 소요가 되었던걸로 기억합니다. 하지만 MVVM의 놀라운 점은 시간이 흐르면서 발견됩니다. 시간이 흘러도 A와 비슷한 기능을 추가 구현할 때 처음 개발했을때와 비슷한 시간만 소요가 되었습니다. 그리고 버그가 발견이 되었어도, ViewModel의 LiveData만 체크하면 되거나 비즈니스 로직 문제면 해당 책임에 맞는 레이아웃을 보면 하루를 소비하지 않아도 금방 원인이 분석이 되었습니다.
그리고 머릿속으로 관심사를 분리한 구조가 잘 그려지기 때문에 고객이 내가 예상못한 기능을 추가로 요구해도 어떤 부분을 건드려서 만들어야할지 쉽게 상상이 가고 유지보수에 대한 자신감이 생겼습니다. 전 위 같은 경험을 통해 설계의 중요성을 알았습니다.
MV앱 과 MVVM앱의 차이는 명확했습니다. MV는 규모가 작고 개발 기간이 오래걸리지 않는 앱을 만들기 위한 아키텍쳐를 적용했기 때문에 원래의 앱 기획과 맞지 않았고 MVVM은 만들어질 앱의 목적과 잘 맞아 떨어졌습니다. 만약 설계를 조금이나마 공부하지 않았다면 무턱대고 한 클래스에 스파게티 처럼 코드가 섞인 채로 코딩을 했을거라 생각하면 훗날 어떻게 고생할지 상상을 안해도 뻔한 일이었습니다.
과거에 스승님이 저에게 소프트웨어는 레고와 같이 각각 부품이 결합되어 있는 상태로 만들어져야 하며, 언제든 빼고 새로운것을 낄수 있도록 만들어져야 된다라고 말씀 해주셨습니다. 그렇게 소프트웨어는 언제든 변할 수 있어야 한다고 하셨습니다. 저도 항상 쉽게 변할 수 있고 안정적이고 탄탄한 소프트웨어를 만드는것을 목표로 하고 있습니다.
이상 소프트웨어 설계 필요성에 대한 생각을 정리해봤습니다.
'안드로이드 Android' 카테고리의 다른 글
| 피어레스 앱 (브레이브걸스) (0) | 2021.06.19 |
|---|---|
| 프로세스와 스레드 (0) | 2021.03.10 |
| 코틀린 알고리즘 (자료구조) 1. 재귀 (0) | 2021.03.09 |
| Accessibility Service 정리 (0) | 2021.03.05 |
| 안드로이드 앱개발 (구글링 방법 정리) (2) | 2021.03.04 |
