[Kotlin Project] 초성마켓 - 클린 아키텍처 적용: 설명

오늘은 클린 아키텍처에 대해서 제가 느낀점을 포스팅해볼 생각입니다~

 

먼저 클린 아키텍처는 사실 2가지 개념이 중요하고, 개발 방법은 사람마다 다를 수도 있다고 생각합니다. 중요한 2가지 개념은, 쉽게 말하면 '의존성 줄이기', '독립성 확보' 입니다.

 

사실 이 2가지를 챙긴다면 정말 작은 프로젝트도 손이 아주아주 많이 갑니다. 번거롭고 귀찮은 노가다 작업도 있구요.

다만, 확실하게 말할 수 있는건 '유지보수'가 진짜 정말 말도안되게 좋습니다.

어떤 프로젝트던 단발성 프로젝트라고 생각하고 진행하는 경우는 거의 없습니다. 장기적으로 생각하고 개발을 해야하는데, 클린 아키텍처를 적용하는건 장기적으로 볼때 아주 좋은 선택지라고 생각합니다.

---

저는 SI 업체를 다녔기 때문에, 많은 프로젝트를 접했었는데요, 매 프로젝트마다 기획, 디자인이 나오는 시간이 있습니다. 그때 기획서 초안을 보고, 대략 예상해서 클린 아키텍처 환경을 구성하고 미리 대비해두는 편이었습니다. 안그러면 제 시간에 못맞출 정도로 작업량이 많습니다.

 

(다만, 한 번 해두면 나중에 어떤 유지보수나 기능개선 요구가 들어와도 즉각 대응이 가능합니다. 무엇보다 가장 좋은건! A프로젝트를 하다가 B프로젝트를 가더라도 구조가 같기 때문에, 물 흐르듯이 작업이 가능합니다. 머리를 리셋할 필요가 없어요!)

---

'의존성 줄이기'와 '독립성 확보'를 위해서는, 이를 도와주는 라이브러리가 필요합니다. 방법에 따라서 런타임으로 구현하는 라이브러리가 존재할 것이고, 빌드를 통해 선 구현해서 작업하는 경우가 있습니다.

2가지 장단점이 존재하는데, 런타임 방식의 경우에는 개발 속도가 빠르고 작업이 편이합니다. 다만, 디버깅이 까다로울 수 있습니다.

빌드 방식의 경우에는 개발 속도가 프로젝트 수준에 따라서 달라질 수 있고, 작업이 불편합니다. 빌드가 꼬일 수도 있고, 여러가지 복합적인 현상이 발생할 경우가 있더라고요. 다만, 디버깅이 아주아주 용이합니다.

 

프로젝트가 소규모일 때는 상관이 없지만, 대형 프로젝트의 경우에는 디버깅이 아주 중요합니다. 개발자가 프로젝트의 모든 코드, 기획 그리고 상황에 따라서 유동적으로 처리해 놓은 가라코드 등등 모두 기억할 수 가 없습니다.

그렇기에 '주석'과 '디버깅'이 정말 중요합니다. 

 

즉, 프로젝트의 규모가 작을 수록 런타임 방식이 유리하고, 규모가 커질수록 빌드 방식이 유리합니다. (실제로 해보신 분들은 아시겠지만, 실상 런타임 방식과 빌드 방식만 따지고 보면 그렇게 개발 속도가 차이나지 않습니다. 다만, 다른 의존성 역전 라이브러리와 여러가지 상황이 걸치면 2가지 방법의 개발속도가 정말 차이가 심하다는걸 아실거에요.)

---

클린 아키텍처를 더 쉽게 요약하자면, 저희가 개발을 할 때, 작게 나눈다면 'DB 개발자', 'API 개발자', '프론트 개발자' 이렇게 3명으로 나눌 수 있겠죠? 모바일 개발도 이렇게 3명이서 나뉜다고 생각하고 개발을 진행하는 겁니다.

 

 

위 사진처럼, 'data'를 담당하는 사람 1명, 'domain'을 담당하는 사람 1명, 'presenter'를 담당하는 사람 1명입니다. 개발을 해보신 분들은 아시겠지만, 원래는 위 3명이 동시에 개발을 시작할 수가 없어요. 데이터가 있어야 API를 개발하고, 위 2개가 완성되어야 프론트를 완성시킬 수 있겠죠.

하지만, 클린 아키텍처를 적용하면 3명이 동시에 개발을 시작해서 동시에 개발을 끝내는게 가능합니다.

 

또한, 클린 아키텍처의 핵심은 위 3명이 서로 무슨 일을 하는지 전혀 알지 못하는 상황에서 개발을 해야하는 상황이라는 겁니다. 3명이서 각각 독방에 넣어놓고 알아서 개발하라고 시키는겁니다.

그런데, 이렇게만 해버리면 그 어떤 사람이 개발을 하더라도 뭘 개발해야하는지 모르기 때문에 아무것도 못하겠죠?

그렇기 때문에 개발 가이드가 주어집니다. 이를 인터페이스(interface)라고 합니다.

 

그렇기에, 클린 아키텍처에서는 인터페이스(interface) 설계가 정말 중요합니다.

예를 들어, 기획서가 완성되고, 디자인도 나온 상황에서 '내 정보 보기'라는 기능을 구현한다고 가정해보겠습니다.

 

제일 먼저, 'domain' 담당자는 인터페이스(interface)를 담당하는 중요한 역할을 합니다. '기획서'와 '디자인'을 확인하고, data영역에서 어떤 값을 받아서 프론트 영역에 던져줄 것인가 고민합니다. (API 담당자와 비슷하죠?)

이를 통해서 인터페이스를 개발하면 아래와 같은 형태일 겁니다.

그다음, 'data' 담당자는, 기획서를 확인하고 DB 구축을 진행하는 상황일 겁니다. 그리고 위 인터페이스를 확인하고 내가 어떤 값을 반환해줘야하 는지 알겠죠. 'UserData'가 필요하다는걸 알 겁니다. 여기에는 '이름, 나이, 성별' 등등 존재하겠죠?

'data' 담당자는 구축한 '유저 DB'에 반환해야할 데이터가 없다면 추가하고, 있다면 DB에서 데이터를 꺼내서 반환시켜주는 작업을 해둡니다.

 

'presenter' 담당자는, 그냥 디자인 나온대로 쭉쭉 밀고 나갑니다. 내 정보 화면도 디자인을 확인하고 쭉쭉 개발하다가, 데이터가 필요한 부분이 있다면, 인터페이스(interface)를 확인하고, 위 'getUserData'를 통해 파라미터를 넘겨주고 반환값으로 받은 'UserData'를 활용해서, 화면의 값들을 채워주면 됩니다.

 

여기서, 더 심화해서 이야기 해보자면, 화면 개발자가 'userId'를 알고 있는 상황이 있을까요? 아뇨 없겠죠.

왜냐하면, 화면 개발자는 시나리오와 기획을 모르는 상황입니다. 알 필요도 없습니다. 클린 아키텍처를 적용할 때, 핵심인 부분이 여기에 있습니다.

'presenter'에는 '시나리오'가 들어가면 안됩니다. 그렇게 되면 '독립성 확보'가 무너지게 되겠죠. 즉, 'presenter'에서 넘겨줄 수 있는 파라미터는 '사용자의 액션'에 해당됩니다. 예를 들어, '푸시 알림'을 'On, Off'하는 액션을 전달할 수 있겠죠.

 

이렇게 되면, 이런 생각하시겠죠? 'presenter' 개발자는 'userId'를 모르는데 어떻게 유저 정보를 조회할 수 있냐.

그래서, 인터페이스에 하나 더 추가시켜 줍니다.

 

이렇게 되면, 'presenter'개발자는 '현재 유저 ID 조회'를 통해서 'userId'를 가져오고, 이를 가지고 '유저 정보 조회'를해서 화면에 데이터를 뿌려주면 됩니다.

 

위 처럼 구현하기 위해서는, 내부 DB를 사용해야겠죠. (물론 개인정보와 관련된 부분이기 때문에 휘발성 DB를 사용하셔야 합니다.)

 

자, 유저 ID를 알 수 있는 방법은 무엇이 있을까요? 바로 '로그인'입니다.

 

위 로그인 과정에서 받은 'userId'를 휘발성 DB에 저장해서 활용하면 됩니다.

자! 여기서 또 핵심이 있습니다. 그렇다면 이 부분은 누가 담당해야 할까요? 휘발성 'DB'에 저장해야 하니, 'data' 담당자가 이를 처리해놔야할까요? 아닙니다.

 

클린 아키텍처의 중요한 핵심 중 하나가 여기있습니다. 바로 '시나리오'는 'domain' 담당자만 알고 있다는 컨셉입니다.

'data' 담당자의 역할은, 기획서와 인터페이스를 확인하고 그에 맞게 필요한 데이터를 뿌려주기만 하는 역할을 합니다.

'domain' 담당자는 '시나리오'에 맞게 데이터를 가공하고 활용하는 역할을 맡게됩니다.

 

그렇다면, 여기서 또 중요한 부분이 있습니다. 그렇다면 'domain' 담당자가 직접 '휘발성 DB'에 접근해서 데이터를 가지고 활용할 수 있는가? 이것도 아닙니다.

이렇게 되면 '독립성 확보'가 무너지게 되겠죠. 'domain' 담당자가 'data'영역에 침범한 것이니까요.

 

그렇기 때문에, 아래처럼 인터페이스(interface)가 추가로 더 필요합니다.

 

자! 그럼 처음으로 돌아와서, '유저 정보 조회'를 하는 상황이라고 했을 때!

 

'presenter' 담당자는 'getUserData'를 통해 'UserData'를 가지고와서 화면에 뿌려줍니다.

 

'data' 담당자는 'getUserData', 'login', 'setUserId', 'getUserId' 인터페이스를 확인하고 이에 맞게 DB를 구축하고 연결시켜 둡니다.

 

'domain' 담당자는 시나리오에 맞게 'setUserId', 'getUserId'를 활용해서 적재적소에 데이터를 활용해서 시나리오를 구현시켜줍니다.

---

어떠신가요? 딱 봐도 작업량이 많아 보이지 않나요?

그냥 편하게 개발한다면 함수 몇개만 만들어서 활용하면 끝입니다.

그러나, 클린 아키텍처를 적용한다면 단순한 '유저 정보 조회' 기능 1개를 위해서 여러가지를 따져야하고 복잡해집니다.

그렇기 때문에, 모든 프로젝트에 '클린 아키텍처'를 적용한다는 것은 사실 어려운 일에 가깝습니다. '코스트 낭비'가 있기 때문이죠.

 

작은 프로젝트라면 애자일 방법을 사용해서 주먹구구식으로 개발하는게 더 좋을수도 있습니다. 빨리빨리 개발해야하니까요.

 

중간 규모라면 클린 아키텍처 도입을 고민해볼 필요는 있습니다. 그래도, 클린이 아니더라도 다양한 아키텍처는 많으니까요 여러개 차용해서 필요한 부분만 섞어서 사용해도 좋습니다.

 

대형 규모라면 클린 아키텍처의 도입이 거의 필수라고 봅니다. 예를 들어, API가 1개 터졌는데, 이로 인해서 앱이 그냥 먹통이 되는 상황이 있을 수 있는데, 그게 다 주먹구구식으로 개발해서 그런겁니다.

대형 프로젝트를 보면, 기능이 몇개가 동작을 안해도 실상 이용에는 크게 불편한게 없게끔 만드는 경우가 많습니다. 그렇게 하기 위해서는 위처럼 '구조&설계'를 담당하시는 분들이 스트레스받아가며 만들어놨기 때문일겁니다.

---