안드로이드

아키텍처 패턴에 대한 고찰 (MVC,MVP)

강한 맷돼지 2023. 5. 27. 18:26

아키텍처 패턴을 정의할수 있는 사람이 과연 있을까?

우테코를 진행하며 아키텍처 패턴에 대해서 많은 논의를하고 학습을 진행하였지만 각 아키텍처 패턴은 무엇이며 어떠한 조건을 지켜야하는가 라는 정의에 대한 부분은 종교처럼 과연 실체가 있는건가 라는 생각이 계속 들었다.

레벨1을 진행하며 콘솔 프로그래밍 레벨에서 MVC 아키텍처 패턴을 학습하며 리뷰어 분들에게 계속된 피드백을 받았다.

이때까지만 해도 그냥 나의 학습이 부족하니까 모르는거지 하면서 비판없이 수용만 했던것같다.(특히 아키텍처 패턴에 대한것은)

하지만 리뷰어분들 끼리도 의견이 많이 다르고 아무리 구글링해보고 해도 뚜렷이 이것이 기준이다 나를 따르라 같은것이 없었다.

그래서 각 아키텍처 패턴별로 시작점(아키텍처 패턴의 시작)에 대해 뭐가 본질인가를 찾아다니게 된것같다.

분명 패턴이라함은 일정한 형태가 계속된다는 것이고 이를 정리하여 이러이러한 형태를 띄면 효율적이다 하는 정리이자 이론이다.

시작점은 분명 실무에서 적용된 하나의 형태일 뿐이였겠지만 누군가 MVP,MVC라 이름을 붙히는 순간 그것은 그 정리하고 그 용어를 집대성한팀이나 사람의 정의가 패턴의 본질이 된다고 생각한다.

그럼으로 흔들리지 않는 주관을 갖기위해 패턴의 본질에 대하여 학습해야겠다는 생각을 하였고

그래서 현재까지 학습한 패턴의 시작점, 본질, 그에대한 나의 주관을 정리해보려한다.

MVC

MVC의 시작점은 분명 시작점은 논문임이 확실하다.

trygve 라는 미중년의 아져씨가 만들었다고 하고 애초에 이름도 시작점에는 Thing-Model-View-Editor였다가 이름을 굉장히 고민을 많이해서 MVC로 변경했다는 썰이 trygve 아져씨의 웹사이트에 작성되어있다. -> 이렇게 초초초초초천재들도 이름에 대해 엄청 고민하는데 나같은 놈이 이름 고민하는게 킹받는다고 했던것에 반성한다.

https://folk.universitetetioslo.no/trygver/ trygve 아져씨의 웹사이트

-> 쭉내리다 보면 mvc에 대해서 이야기하는 페이지가 나온다)

여기보면 MVC에 대해서 추상적으로 설명한다.

솔직히 이 페이지의 글들은 고대적에 쓰인게 티가난다. 영어를 해석해도 좀 뭔가 단어 선택자체가 올드하고 어렵다고 할까 https://folk.universitetetioslo.no/trygver/1979/mvc-2/1979-12-MVC.pdf

이 글을 발 번역 + 내 생각대로 의역해보면

Model

모델은 도메인 의 상황(knowledge라고 원문에서는 나옴)을 표현하는 것으로

모델은 단일 객체일수도 있고,객체들의 구조일수도 있다.

모델은 개발자가 인식하는 도메인의 요소와 일대일 대응관계를 가진다.

( represented world as perceived by the owner를 개발자가 인식하는 도메인의 요소라고 해석함)

모델의 node(모델의 세부 구성요소라 생각됨)들은 모델의 특정측면이나 개념을 나타내어야 하고, 이 노드들은 모두 동일한 문제 수준에 있어야 한다.

멧돼지의 해석: 모델은 도메인이 나타내는것들을 추상화해서 도메인에서 필요한 부분들을 나타내야하고 같은 수준의 단계의 것들을 가지고있어야한다.

it is confusing and considered bad form to mix problem-oriented nodes (e.g. calendar appointments) with implementation details (e.g. paragraphs).

이게 진짜 뭐라는건지 모르겠는데

내가 이해한대로는 모델의 세부 구성요소들이 구현의 디테일에의해 결정되는게 안좋다는 의미같다.

View

뷰는 모델의 시각적인 표현으로 일반적으로 모델의 특정속성을 강조하고 다른속성을 억제합니다.

(모델에서 필요한 부분만 뽑아서 화면에 뿌려준다는 관점으로 보면 될듯하다.)

따라서 뷰는 presentation filter(모델을 필터링해서 사용자에게 보여주는) 역할이다.

뷰는 모델에 연결되어있으며 화면에 나타내기위해 필요한 데이터를 메시지를 보내는것을 통해 얻습니다.또한 뷰는 적절한 메시지를 보냄으로서 모델을 업데이트 할수도 있습니다.

이러한 메시지들은 모델에서 쓰이는 용어(모델에 있는 속성들)로 이루어져야 합니다.이런 측면에서 뷰는 모델의 속성이 나타내는 의미를 알고있어야합니다.

It may, for example, ask for the model's identifier and expect an instance of Text, it may not assume that the model is of class Text. -> 원문은 이러한데 좀 감이 안온다

간단하게 직역을 해보자면: 뷰는 모델이 반드시 텍스트 클래스의 인스턴스인것으로 가정하면 안된다.

이 문장을 이해한 바로는 뷰는 모델이 특정 클래스일 것이라고 가정하지않고 속성(도메인적인 특징을 나타낸것)을 기반하여 동작해야 한다고 판단했다. 즉 뷰가 모델을 알긴알지만 구현이 어떻게 되어있는지는 몰라야한다 이런 느낌인거 같은데 어렵다.

Controller

누군가가 이부분에 대해선 의견을 남겨주실거라는 생각에 원문도 첨부합니다.

A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and pass these messages on .to one or more of the views. A controller should never supplement the views, it should for example never connect the views of nodes by drawing arrows between them. Conversely, a view should never know about user input, such as mouse operations and keystrokes. It should always be possible to write a method in a controller that sends messages to views which exactly reproduce any sequence of user commands.

Chat gpt가 어느정도 매끄럽게 번역해서 바로 복붙했습니다

컨트롤러는 사용자와 시스템 간의 링크 역할을 합니다. 컨트롤러는 관련된 뷰가 적절한 위치에 나타나도록 배치함으로써 사용자에게 입력을 제공합니다. 또한 사용자에게 메뉴나 다른 명령과 데이터를 입력할 수 있는 수단을 제공함으로써 사용자 출력을 처리합니다. 컨트롤러는 이러한 사용자 출력을 받아 적절한 메시지로 변환하고 이 메시지를 한 개 이상의 뷰로 전달합니다.

컨트롤러는 뷰를 보완해서는 안 된다.

반대로, 뷰는 마우스 조작이나 키 입력과 같은 사용자 입력에 대해 알지 않아야 합니다. 사용자 명령의 모든 시퀀스를 정확히 재현하는 메서드를 컨트롤러에 작성하여 뷰로 메시지를 전송할 수 있어야 합니다.

이 부분에서 조금 의미 파악이 애매한 부분이 있는데 어떻게 해석하냐에 따라 생각이 달라질수도 있다고 생각한다. 처음 이 글을 쓸때는 이렇게 판단했다.

view는 그냥 진짜 그야말로 화면에 그려진 그림이나 다름없고

관련 사용자 상호작용 이벤트는 컨트롤러가 다 처리해야한다.(뷰애 붙어있는 set~~~Listener 가 controller 로직이라고 생각된다.)

안드로이드라면 뷰의 리스너 혹은 입력받는 로직들이 뷰가아니라 컨트롤러가 담당하는것이였다.

즉 안드로이드의 뷰 컴포넌트 들은 뷰랑 컨트롤러가 혼재되어있는 것들이였다.

뷰에서 화면을 그리는 로직을 제외한 이벤트 처리 및 사용자 입력 및 관련 처리로직이 컨트롤러 것이고 그것은 뷰에서 몰라야 한다고 한다.

이렇게 보면 이 문서의 MVC는 기존 통념과 전혀 다른건데 설마 아닐꺼라는 생각이든다. -> 이러면 애초에 안드로이드에서는 MVC가 존재할수가 없다.

근데 내가 영어를 못해서 아리까리 해서 다시읽어보니까 이런 생각 또한 들었다.

그냥 xml이 뷰이고 액티비티가 컨트롤러이며 리스너를 지정해주는 로직이 controller에 붙어있으니 그냥 우리가 통념적으로 생각하던 MVC가 이것아닌가?

근데 결론적으로 후자가 맞는것 같다.

Editors

그리고 난생처음 보는 Editors라는게 또 있다.최초의 이름이 Thing-Model-View-Editor 였다는데 아직 Editors의 잔재가 남아있나보다.

컨트롤러는 모든 뷰와 연결되어 있으며, 이들은 컨트롤러의 구성 요소로 간주됩니다. 일부 뷰는 특별한 컨트롤러인 에디터를 제공하여 사용자가 뷰에서 제시된 정보를 수정할 수 있도록 합니다. 이러한 에디터는 컨트롤러와 뷰 사이의 경로에 삽입되어 컨트롤러의 확장으로 작동할 수 있습니다. 편집 프로세스가 완료되면 에디터는 경로에서 제거되고 폐기됩니다.

그냥 사용자 입력을 하는부분은 Editors라는 이름을 붙여준것이다.

이글을 종합해보면

현재 통념적으로 사용하는 MVC와는 다른것이 컨트롤러가 지배적으로 중앙에 위치해서 뷰와 모델을 관장하지 않는 형태이다.

MVC를 설명하는그림도 우리가 일반적으로 알고있는 MVC의 삼각형 구도의 그림이 아니다.

이글을 보면 대략적인 큰 개념만 제공하고 세부 구조에 대한 세세한 구현은 논의하지 않는다.

즉 대원칙만 지킨다면 구현은 개발자에게 자유로 맡겨놓은것같다.

그래서 웹이나 앱에서 일반적으로 사용하는 MVC 또한 이런 대원칙하에서 각 플랫폼의 형태에 적절하도록 변형을 해나간 것이라는 생각이 들었다.

근데 사실 이 문서에 나온 형태만을 따라간다면 관심사 분리가 완벽하게 이루어 지지 않게 된다.

그렇다면 주로 얻을수있는 이점이 뭐지? 라는생각이 든다.

이부분을 통해서 왜 변형되었는지를 피부로 느낄수 있었다.

제이슨이 옛날에 MVC에 대해서 전파했던 슬랙

우리의 킹갓 제너럴 충무공 제이슨이 안드로이드 리뷰어 채널에 우리들을 혼내주라고 썻던 글인데 이걸 잘 파악하면 우리가 통념적으로 사용하는 MVC의 기준을 세울수 있을거라는 생각에 글에 첨가했다. 읽어보면 제이슨이 왜 제이슨인지 알게해준다.

제이슨의 글

🙂---MVC 패턴은 그 기원이 오래된 만큼 다양한 형태로 변화해 온 것 같습니다. 전통적인 MVC 패턴은 옵저버 패턴(자바의 스윙으로 프로그램을 만들 때 흔히 볼 수 있는 패턴)을 조합한 형태인데 웹 환경에서 사용하다 보니 이에 적합한 형태가 등장하게 되었죠.

https://ko.wikipedia.org/wiki/모델-뷰-컨트롤러
https://www.oracle.com/technical-resources/articles/java/java-se-app-design-with-mvc.html

Model이 변경된 경우 View와 같은 관심 있는

리스너에게 변경 사항을 알립니다.

일부 아키텍처에서는 Controller가 View 업데이트

현재 크루들이 사용하는 패턴은 웹 환경에서 볼 수 있는 MVC 패턴입니다. 하지만 실제 웹처럼 물리적으로 분리되어 있지 않기 때문에 View에서 Model을 생성하는 등의 작업을 할 수 있습니다. 이것이 트레이드 오프의 영역이라고 생각합니다. View가 유효성을 검사하면 Controller는 굳이 유효성을 검사하지 않아야 한다는 것과 비슷합니다. 한 명의 개발자가 전지전능한 관점에서 개발하기 때문에 고민할 수 있는 문제라고 생각합니다.그럼 이제부터는 제 개인적인 생각입니다. 리뷰할 때 View에서 Model을 만들든 Controller에서 Model을 만들든 별로 신경쓰지 않습니다. 유효성 검사와 같은 목적으로 InputView에서 Model을 빌려 쓸 수 있고, 이왕 만든 Model을 OutputView에도 전달할 수 있다고 생각합니다. 굳이 따지자면

View는 비즈니스 로직(수익률 계산 등)을 수행하지 않게 하고
일관된 코드 작성을 강조합니다.
물론 Model이 View를 알게 하지 않습니다. 이건 패턴을 떠나 의존성 방향의 문제이니깐요.

현재 테스트 코드를 작성할 때 UI, 컨트롤러 등에 대한 테스트 코드를 작성하는 것보다 도메인에 대한 테스트 코드 작성을 강조하듯이 도메인이 잘 작성되도록 도메인을 먼저 리뷰하고 리뷰할 사항이 없으면 나중에 봐주셔도 됩니다. 🙂여담으로 InputView와 OutputView를 독립된 화면(=Activity)으로 보면 좋겠는데 이상하게도 입력과 출력을 분리해 담당하는 경우도 있더라고요. PurchaseView와 ResultView로 명명하게 유도할 걸 그랬나요?

객체 생성이 복잡하다면 생성자에 로직이 있다고 의심할 수 있겠네요. 생성자는 생성자답게 사용하려고 하면 자연스럽게 일관된 코드가 나오지 않을까 싶습니다.
DTO와 값 객체 혼동은 값 객체의 특성 때문일 거고요.
웹 쪽도 Pure Domain Model과 Domain Model Everywhere 사이에서 항상 고민하고 있습니다. 처음 개발할 때는 Domain Model Everywhere가 유리하지만 점진적으로 Pure Domain Model으로 리팩터링해야 한다고 하죠.

아래 예시는 혼내 주세요…

class InputView {
   fun input(): String? = readLine()
}

도메인 로직을 리팩터링한다고 View의 로직은 잘 바뀌지 않겠지만 도메인의 생성자를 변경하면 View는 영향을 받겠죠. 원칙을 따지게 되면 View, Controller, Model 모두 유효성 검사를 해야 합니다. 왜냐하면 서로는 독립적인 개체면서 서로를 신뢰할 수 없는 관계이기 때문입니다. 그렇지만 ‘전지적 작가 시점‘이라는 말과 ‘트레이드 오프’라는 말을 했듯이 유효성 검사 로직의 중복 제거를 위해 View에서 Model을 쓸 수도 있죠. 그래도 View가 Model에 의존하지 않게 만들겠다면 OutputView도 Model에 의존하지 않는 것이(파라미터로도 받지 않는 것이) 일관된 코드 작성이라고 여길 수 있습니다.

자 이제 멧돼지의 해석이 들어갑니다.

https://www.oracle.com/technical-resources/articles/java/java-se-app-design-with-mvc.html

첨부해주신 이 글에 이제 우리가 통념적으로 사용하는 MVC의 정의가 나와있다 -> trygve 아져씨로부터 변형됐겠죠?

그 일반적인 삼각형그림이 적용되는 정의가 적혀있다.

들어가자 마자있는 목차 두개인

What Is Model-View-Controller (MVC)?

Interaction Between MVC Components

일반적으로 이야기하는 MVC중 좀 더 올드한 MVC 이야기를 하는데

이런식으로 구현하면 살짝 MVVM 의 향기가 살짝 스쳐가는것도 같지만 결론적으로 MVVM과는 다르다는것을 깨달았다.

요약해보자면 뷰가 모델의 변경에대한 옵저빙이 되어있는것을 기본적으로 전제하고 옵저빙을 안하고 컨트롤러가 직접 바꿔줄수도 있다 라고 한다.

MVC가 옵저빙을 달면 굉장히 MVVM스러워지는것 같다.

이 부분에 대해 처음에는 MVC에 뷰가 모델을 옵저빙한다면 이게 MVVM 아니야?했는데 생각해보니 구별이 간다.

이 글을 잘 읽어보고 곱씹어보면 컨트롤러와 뷰모델의 차이가 느껴진다. 그리고 액티비티가 컨트롤러라는것도 느껴지고 뷰모델은 분명 다른이야기다 -> MVVM에서는 모델을 직접 옵저빙하는것이 아닌 중간 단계인 뷰모델에 뷰전용 모델을 성형해놓고 그것을 옵저빙한다.(뷰관련 로직들을 마음대로 추가가능 -> 테스트도 좋아짐)

다음항목인

Modifying the MVC Design

에서 이제 우리가 생각하던 MVC가 apple Cocoa 프레임워크에서 사용되었다는 이야기가 나온다. (크으으으으👍)

MVC 디자인의 더 최근 구현 방식 중 하나는 컨트롤러를 모델과 뷰 사이에 배치하는 것입니다. 이러한 디자인은 Apple의 Cocoa 프레임워크와 같은 곳에서 일반적으로 사용됩니다.

이 디자인에서 전통적인 MVC와의 주요 차이점은 모델 객체의 상태 변경 알림이 컨트롤러를 통해 뷰에 전달된다는 것입니다. 따라서 컨트롤러는 모델과 뷰 객체 간의 데이터 흐름을 양방향으로 조정합니다. 뷰 객체는 여전히 사용자 동작을 모델의 속성 업데이트로 변환하기 위해 컨트롤러를 사용합니다. 추가적으로, 모델의 상태 변경은 응용 프로그램의 컨트롤러 객체를 통해 뷰 객체에 전달됩니다.

따라서 세 가지 컴포넌트가 모두 인스턴스화되면, 뷰와 모델은 모두 컨트롤러에 등록됩니다. 사용자가 뷰와 상호작용하면 이벤트는 거의 동일한 방식으로 발생합니다:

뷰는 GUI 동작(예: 버튼을 누르거나 스크롤 바를 드래그하는 등)이 발생했음을 인식하고, 해당 동작이 발생할 때 호출되도록 등록된 리스너 메서드를 호출합니다.

뷰는 컨트롤러의 적절한 메서드를 호출합니다.

컨트롤러는 모델에 접근하여 사용자의 동작에 적합한 방식으로 모델을 업데이트할 수 있습니다.

모델이 변경되면 관련된 리스너에게 변경 알림을 보냅니다. 그러나 이 경우 변경 내용은 컨트롤러로 전송됩니다.

이러한 디자인을 채택하는 이유는 무엇일까요? 이 수정된 MVC를 사용하면 모델과 뷰를 보다 완전하게 분리할 수 있습니다. 이 경우 컨트롤러는 컨트롤러에 등록된 하나 이상의 모델에서 찾을 것으로 예상되는 모델 속성을 지정할 수 있습니다. 또한, 하나 이상의 뷰에 대해 모델의 속성 변경을 수행하는 메서드를 제공할 수도 있습니다. 이를 통해 모델과 뷰의 결합도를 낮추고 유연성을 향상시킬 수 있습니다.

이거 보면 피가돈다 드디어 찾던것도 나왔고 이유도 잘 설명되어있다.

결국 수정된 MVC에서의 중점은 관심사 분리이다 뷰와 모델을 완전히 독립시켜 결합도를 낮출수있고 유연하게 할수있다.

크게보면 덩어리가 큰 객체지향 느낌이다.

어찌됐건 간에 우리가 생각하는 MVC가 여기있었다. 만약 진지하게 MVC 패턴에 대해서 고민하고싶은데 공신력있는 자료를 원한다면 이 자료를 보고 공부해보자

(이자료 읽고 쓰고싶은말이 너무 많은데 이거 다 쓰면 글이 터져버릴것 같으니 나중에 MVC에대해서 한번 글을 더써야겠다.)

서버 크루원 준팍의 생각(인터뷰 느낌 실제와 다를수 있음 멧돼지의 해석본)

준팍은 나와 비슷한 아키텍처 패턴에 대한 의문? 사실 모든패턴에 대한 의문같긴 한데 어쨋든 괴리감을 느꼈다고 한다.

하지만 MVC를 사용하고 느끼는 이점에 대해서는 실제로 관심사가 분리가 되는것을 느꼈다고 한다.

MVC는 뷰 모델 컨트롤러중 하나니까 의식적으로 하나의 파일, 하나의 패키지, 하나의 로직 안에서 각각 컨트롤러인지 뷰인지 모델인지를 구분하게되어 로직들이 혼재되는 일이 없어졌다고 한다.

그리고 열심히 듣는 강의에 스프링이 어떻게 발전했고 혼재되어있던 로직들을 MVC형태로 어떻게 분리되었는지 설명을 들으며 그것에서 와닿는 부분을 찾을수 있었다고 한다.

그래서 실제적으로 얻는 이득은 개발시 변경이 다른 요소로 전파되지 않는다는 장점을 느꼈다고한다.

(지금 이글을 쓰면서 느낀점인데 준팍은 본능적으로 본질을 다 따라가고 있었다.)

멧돼지의 MVC 결론

이 글을 쓰기 시작할때는 세부적인 구현 또한 공식문서나 공인된 기관에서 정해준것을 좀비처럼 찾아 다닌것이였다.

근데 애초에 그런건 없었다. 제이슨이 수업시간에 내가 보고있는건 아키텍처가 아니라 아키텍처 패턴이라고 정정해준게 이해가 되었다.

(제이슨 그는 어디까지 본건가 처음에는 이해가 안되었지만 결국 제이슨의 아키텍처 패턴이라는 말에 이해가 되었다.)

패턴은 애초에 구현의 추상적인 개념만 정리해서(gof패턴책 보면 인터페이스만 널려있는것 처럼) 구현은 개발자 맘대로 하는건데

왜 자꾸 구현까지 해달라고 떼를 썻는지 모르겠다. 여기서 이름의 중요성이 나타난다. 패턴이라는 항목하나가 이름에 붙었다고 한방에 이해가된다.

어쨋든 결론적으로 이제 누군가 나에게 코드가 MVC스럽지 않다고 할때 나의 코드에서 관심사 분리가 잘되어있고 그것에 대한 근거가 있다면 누가 뭐라하든 난 MVC를 적용한거다.(그 사람과는 MVC에 대한 견해가 다른것이다.)

그래서 MVC 패턴에 대해서 중점적으로 가져가야하는 제일중요한 부분을 살펴보자.

사실 MVC를 사용하면서 얻는 이득은 모든 아키텍처 패턴에 있는건데 이게 MVC만의 것이 맞아? 라는 생각을 했다가 조금더 생각해보니 MVC가 애초에 아키텍처 패턴의 시초격이고 이걸 다 본받아서 만들었으니 당연한거였다. 나 바보인가?

그래서 아키텍처 패턴의 기본적으로 갖춰야할 덕목이자 MVC의 주요 핵심은 관심사 분리라고 생각한다.

내가 실제적으로 코딩하면서 느낀부분은 모델과 뷰로직은 완전히 분리되어야하고 그 중간에 방파제 역할로 두 로직이 어느정도 혼재될 수 있는 부분이 컨트롤러이다.(정확히 말하자면 혼재가 아니라 호출되는곳)

어쨋든 관심사 분리를 제1 덕목으로 삼고 그것을 이루기위해 각 로직을 model,view,controller로 프로그램이 유연하게 동작할수 있도록 분리해 나간다면 그것이 곧 MVC 인것 같다.

또한 MVC에서 관심사 분리가 주요한 핵심이라 MVP에서는 막상 관심사분리에 대해서 막 강조하지는 않는데 MVC에서 파생된 모든 아키텍처 패턴의 기본소양은 관심사 분리라는것을 깨달았다. MVP에서 또한 관심사 분리는 무조건 가져가야하는 제1덕목중 하나이다.

안드로이드에서 MVC

안드로이드는 애초에 MVC 를 기본으로 설계되었다고 한다. 사실 모델부분만 잘 나눠준다면 액티비티에 그냥 코드를 갈기면 MVC 비스무리하게 나온다고 생각한다.

하지만 액티비티와 뷰가 세트로 움직여야하는 운명이 오히려 안드로이드에서 MVC가 멀어지게 만드는 주요인 아닌가 싶다. 애초에 컨트롤러를 안드로이드 프레임 워크에서 제공하는 클래스에서 작성해야하므로 컨트롤러의 재활용은 이미 저승으로 가버렸고 그렇다면 남은건 모델뿐인데 이게 의미가 있나? 라는 생각이 든다. 아키텍처 패턴 회원권 박탈해야한다.

관심사 분리의 가장큰 장점은 유연하게 부품들을 갈아 끼울 수 있는것인데 컨트롤러가 안드로이드 의존성을 강하게 가짐으로써 이렇게 관심사 분리가 가지는 이점을 이미 포기한것이나 다름없는데 안드로이드에서 MVC 자체가 모순이 아닌가 생각이 든다. (컨트롤러를 재활용하며 다른 플렛폼의 뷰를 끼워넣을수가 없다. -> 왜냐? 컨트롤러가 액티비티니까)

MVP를 적용하게되면 프리젠터에서는 안드로이드 의존성이 없어짐으로 의미론적으론 MVC에 가까워지는것 아닌가 싶다.

(출처가 확실치 않지만 리뷰어 분들이 "안드로이드에서는 MVP가 사실상 MVC이다" 라는 말을 해주셨다고 크루원들 사이에 유행처럼 돌았는데 그 이유를 알것같다.)

어쨋든 앞으로 MVC를 구현할 때 여태까지 학습한 대로 좀 더 좋은 방법을 찾아본다면

contract를 만들고 MVC를 구현할것같다. MVP 패턴에서 많이들쓰이는(물론 contract가 강제는 아니라고 한다.) contract 쓴다면 그래도 추상화가 한번되니까 다른 플렛폼이나 어떠한 환경으로 옮겨가도 조금 더 유연하게 대처할수있다고 생각해서(책임주도 개발이 좀 더 다가오는건 보너스) 적용 해볼것같다.

// 2023/09/24 수정

정말 좋은글을 많이 써주시는 태환님을 뵙고 대화할 수 있는 기회가 생겨 궁금한것을 여쭤보기도 조언을 받기도 했는데

이 글을 보시고 조언을 해주신 부분에 대해서 이해한 바를 다시 재해석 해보려한다.(전적으로 내 해석이 들어가서 부 정확할 가능성이 크다.)

기본적으로 안드로이드는 아키텍처 패턴을 정의해서 만들어진 형태가 아니다.

예를들어 IOS 진형의 경우 정말 Basic하게 개발하는 방법만 따라가도 MVC가 지켜지게 만들어져 있고 서버에서 많이 사용하는 Spring 또한 MVC 패턴을 잘지킬수 있도록 만들어져있다.

하지만 안드로이드는 애초에 액티비티에서 모든일을 하도록 설계되었고 아주 옛날에는 그렇게 행해왔다.

하지만 이에대한 불편함이 따랐을 것이고 그래서 구글에서 as 차원으로 기존형태에 얹을수 있는 패턴들을 제시하는 것인데

이에 대한 정확한 가이드를 제공하지는 않아서 개발자간의 혼동이 올 수 있고 의견이 분분하다.

예를들어 View를 어느것 까지로 볼것인가? 구글에서 정확히 선을그어 액티비티까지야 이렇게 정해줬다면 모르겠지만 이런것들에 있어서 각각의 개발자의 해석이 들어갈 수 밖에 없고 이로 인해서 혼동도 오고 각각의 의견이 분분한 것이다.

그래서 여기서 내가 얻을 수 있는 의의는 무엇인가? 원래 구글에서 아키텍처 패턴을 의도하고 내놓은것이 아니니 여러 아키텍처 패턴을 접해보고 아키텍처 패턴에서 중점적으로 얻을 수 있는 이점에 대해 생각하며 취할것들을 취하면 되는것이다.

결론적으로는 어짜피 모든것은 편리하기 위하려 도입하는것 뿐 팀원들과 코드에 대한 통일성을 맞춰 인지부하를 줄이고 관련된 코드가 테스트, 변화에 강해지는 구조라면 어떤것이든 ok가 아닌가 싶다.

원래 여기서 MVP도 다룰려고 했는데 글이 너무 길어서 답이없음을 느껴서 일단 여기서 끊는다. MVP는 바로 속편으로 다뤄볼 예정이다.그리고 MVVM은 우테코에서 좀더 확실히 다뤄보고 기준이 생긴후에 또 한번 써볼까한다.

추가 자료

제이슨한테 오라클 문서 짱짱맨이라고 자랑했다가 제이슨이 새로운 키워드로 검색해보라고해서 검색해봤는데 또 논문이 긴게 쭈루루룩 나와서 읽어봐야한다.

근데 지금 읽을 힘도없고 아마도 비슷한 이야기가 되풀이 될것같아 일단은 이런게 있다 정도만 글에 작성해놓고 나중에 여력이 있을때 읽어보려고한다.

http://www.dgp.toronto.edu/~dwigdor/teaching/csc2524/2012_F/papers/mvc.pdf

결론

정답을 냅두고 겁나 멀리 갔다왔다.(코치님들이 얼마나 답답했을까? 나 같았으면 딱밤 떄렸다.)

어쨋든 이글을 쓰면서 생각도 정리되고 뭔가 패턴에 대한 의미를 찾은것 같아 이제 MVC가 뭐냐고 하면 가서 한시간이고 두시간이고 떠들수도 있고 MVC 패턴을 사용할 일이 생긴다면 기준을 잡고 나머지 세부 사항들은 내가 예쁘게 구성해 나갈 수 있을것 같다.

그리고 아키텍처 패턴에대한 시야가 넓어졌다. 뭔가 MVC를 깊게 공부하고 고민해봤는데 MVP랑 MVVM 까지 감이오는거지? 신기하다.

MVC는 이미 추상화되어있어 세부구현은 내가 알잘딱하게 해야했는데 자꾸 구현까지 해달라고 떼를 썼던것 같다.

이제 뭐가 중요한지 알것같아 속이 시원하다.

감사인사

이 글은 주변의 많은 사람들을 도움을받아 만들어낸 결과물이다.

이 글을 위해서 거지같은 질문을 다 받아준 레아,제임스

바쁘실텐데 DM에 모두 친절하게 답변해주신 페로로 리뷰어님

제이슨이 백엔드 크루원과도 한번 대화해보라고 해서 찾아갔을때 본인의 생각 및 서버의 상황을 전해준 준팍

그리고 무엇보다 진지하게 내가 하는 이상한짓에 귀 귀울여주시고 항상 고민을 깰수있을만한 조언을 해주신 제이슨께 감사하다는 인사를 드리고싶습니다.