모듈러 아키텍쳐? 아키텍쳐는 왜 계속 언급이 되는가....

취업을 준비하고 있는 요즘.... 계속 공부했던 내용을 블로그에 정리하거나, 새롭게 공부할 내용이 보이면 다시 정리의 반복

 

최근 카카오뱅크 개밸자 채용 공지를 보면서 Modular Architecture 란 것을 알게 되었다.

(이렇게 기업 채용공고를 보다 보면 현업에서 관심 있어하는 기술들이 중복되는 것이 많다... 그럼 그걸 공부해보는 것이 요즘 나의 공부 방법)

 

일단 모듈러 아키텍쳐는 무엇일까?

Modular architecture is based on the design and use of systems composed of separate repetitive elements (standard units), which are similar in size, shape and functional nature. These can be linked up to each other, be replaced or added.
출처: http://www.agi-architects.com/blog/en/modular-architecture-chosen/

항상 IT 업계는 건축과 유사성을 가지고 언급이 되어 건축과 관련된 페이지의 내용을 가지고 와봤다.

재사용성 요소들을 바꾸고 추가하고 연결하는 것 !

 

근데 사실 내가 생각했을 땐, 모든 아키텍쳐들이 추구하는 것은 다 똑같은 것 같다. 

 

그렇다면 왜 카카오뱅크에선 모듈러 아키텍쳐를 언급한 걸까?

 

당연히 현재 카카오뱅크 iOS 앱은 모듈러 아키텍쳐로 바꾸고 있기 때문이라고 생각했다. 

실제로 작년말에 if(kakao)dev2022 영상에서도 이와 관련된 내용이 올라왔었다.

 

카카오뱅크는

MVVM > RIBs > Modular Architecture 

의 과정을 지나왔다고 한다. 

출처 : https://youtu.be/9HywMpgf8Mk

2022년 8월 기준으론 11,000개 파일 104만줄 이었다고 한다.

여기서 바꾸게 된 이유는 MVVM 의 문제를 해결하고자 RIBs 로 바꿨지만 엄청난 파일 갯수와 코드라인의 문제가 있었던 것이다. 

결합도는 증가되고 그러다 보면 빌드 시간이 증가되고, 빌드 실패에 대한 문제들이 발생한다고 한다.

출처 : https://youtu.be/9HywMpgf8Mk

이러한 작업의 반복이 비효율적이라는 것이다.

 

여기서 모듈러 아키텍쳐도 똑같은 문제가 있는 것이 아닌가? 란 생각이 잠깐 든다.

그러다 보면 같이 Tuist 란 용어도 나온다. 간단하게 프로젝트 내에서 앱을 기능별로 쪼개고 거기에 임베디드 되야하는 목록을 관리를 하는 것이다. 써본 것이 아니기에 정확하게 안다고 할 순 없겠지만....카카오톡 앱 전체 프로젝트에는 채팅, 선물하기, 카카오페이 등등 다양한 기능들이 있다. 내가 카카오페이를 담당한다고 했을 때 이 전체 프로젝트를 당겨와서 작업하고 테스트 하기엔 나머지 기능들과 같이 빌드하고 테스트하고 업로드하고....쓸데없는 시간의 낭비가 너무나 크다는 것 같다.

 

출처 : https://youtu.be/9HywMpgf8Mk

어떻게 진행을 했느냐?

 

 

1. Core, UI 별로 모듈화 작업을 진행할 리스트를 계획하고 만든다.

2. 기능을 나누어 각 기능별로 필요한 요소들을 Tuist로 만든다.

3. 각 기능별로 데모앱을 만들어 테스트한다.

 

이렇게 함으로 인해서 build 하여 실제 앱 구동 테스트를 할 때 앱전체를 실행하는 것이 아닌 그 기능만을 위한 앱이 만들어져서 테스트를 하기 때문에 빌드시간이 단축된다. 사실 빌드시간이 단축된다는 것은 낭비되는 업무시간을 줄여주고, 이는 업뮤 효율 증가를 불러일으키고 결국 퇴근시간을 앞당겨주는 것이 아닌가? ㅎ

 

이로서 얻은점은 영상에서 직접 확인해보세요 

출처 : https://youtu.be/9HywMpgf8Mk

 

마무리, 그렇다면 많은 회사에선 기업 채용 공고에 계속해서 아키텍쳐를 언급하는 것일까?

 

사실 정말 간단하다. 유지, 보수, 관리, 업무효율 이러한 것들은 전부 회사의 돈이다. 개발자로서 회사에 근무를 해본 것은 아니다.

하지만 회사에서 새로 만들어진 팀을 운영해본 경험으론, 처음 시작할땐 각자가 자신의 기능만 하면 된다. 그러다 보면 업무의 비효율이 보인다. 매번 중복되는 업무가 발생할 수 있고, 이 사람 저 사람 특정 담당자가 없으니 마구잡이로 일을 처리하고, 그러다 보면 전문가가 필요할 때 처리할 수 있는 리소스가 없기에 처리에 더 많은 시간이 걸린다. 그러다 보면 파트를 나누고 운영을 한다. 하지만 일을 하고 성장을 하다보면 그러한 요소들이 계속헤서 발생한다. 대기업을 보면 부서가 정말 많다. 가끔은 너무 나누어져 있어서 협력사 입장에선 답답한 순간들이 정말 많다. 하지만 회사 내부적으론 거기서 오는 이점이 정말 크다는 것도 안다.

 

이처럼 개발하여 앱을 만드는 것도 회사를 만들어 운영하는 것과 같다고 생각한다. 사실 작은 규모의 프로젝트에선 아키텍쳐를 고민하는 것보다 그냥 만들어서 출시하고 운영하는 것이 훨씬 효율적일 수 있다. 

규모가 커진다면 그에 맞는 효율적인 개발 방법, 운영 방법 등을 생각하고, 그 규모에서 발생한 문제들을 해결하기 위한 적절한 아키텍쳐를 찾아 진행하고, 적응이 될 때 쯤 다시 반복되는 작업일 것이다. 그러다 보면 아키텍쳐들을 적절히 결합한 새로운 아키텍쳐가 나올 것이다.

 

그렇기에 회사에선 아키텍쳐에 대한 이해를 계속 언급하는 것이 아닐까?

이 하나만으로도 이 사람을 파악할 수 있을것이다. 자기 자신이 일을 하면서 효율을 생각할 수 있는 사람인가 아닌가? 정말 깊게 고민해보고 업무를 징행하는가(단순히 좋다고 따라서 하는 사람이 아닌). 수동적인 사람인지 아닌지 등등

 

그런데 참.....개인적으론 프로젝트를 진행하면서 다양하게 효율적인 아키텍쳐들을 고민해볼만한 프로젝트를 진행하는 것이 너무 힘든 것 같다.

 

(사실 2월 어느 회사 면접을 봤을 때, 프레임워크를 제작해본 경험이 있는지, 동적라이브러리, 정적라이브러리를 아는지 질문을 받은 경험이 있었다. 그 땐 이 질문이 왜 나온지도 몰랐다. 단순히 공부해야할 목록만 넣어두었지.....아마 그 회사도 아키텍쳐 때문에 그것을 물어봤구나를 지금에서야 깨달은 것 같다.....)