Layered architecture - 1/2

호돌맨과 향로

유튜브 영상을 보다가 layered architecture라는 말이 나와서 이에 대한 글을 적어보기로 했다.

참고로 이 글은 ReactJS 관점에서 작성된 글이다. 하지만 프론트엔드, 백엔드, 옵스, 게임 개발 어느쪽에서 생각해도 비슷할 것이라고 본다.

 

이 글은 뭘 적을지에 대한 정리없이 그냥 막 적은 글이다. 읽기 불편할 수 있다. 읽기 힘들다면, 키워드만 쏙쏙 뽑아가길 바란다.

(티스토리 기본 에디터는 뭔가 내 맘에 들지 않는다. 별도의 에디터를 찾아봐야겠다.)

 

글을 쓰다가 너무 길어져서 2개로 나눠 적었다. 이 글은 Layered architecture가 무엇인지에 대해 다룬다.

 

TL;DR

Layered architecture = 다층 구조 = 목적에 따라 모듈을 나눈 것

 

신입에게 주어지는 첫 과제, React 프로젝트 이야기

다층 구조 (계층화 아키텍쳐)

여러가지 표현으로 불리는 것 같다. 위키에는 Multi-tier Architecture라고 나와있기도 하고, n-tier Architecture라고 나와있기도 하다.

내 생각엔 Layered Architecture라고 하니까 Hierachy Architecture나 Depth Architecture같은거라고 생각했다.

 

뭐라고 부를지도 중요한 일이긴 하지만, 이 글에서 다룰 것은 이것이 무엇인가이다.

나는 이 영상을 통해 Layered Architecture라는 표현을 처음 들어봤다. 왜냐하면 OOP에서 역할에 따라서 분리된 코드를 만드는건 당연한 일이니까. 그냥 그러려니 한거다. 근데 이게 OOP보다는 조금 더 좁은 관점인 것 같다.

 

3 Tier

갑자기 Tier라는 단어가 나왔다. 이제 아래에서 Tier와 Layer를 무분별하게 섞어 쓸것이다. 같은 단어라고 생각하고 봐달라.

 

위키 백과에서 보면 3층 구조라는 말이 나온다. 아마 이 "3층 구조"라는 말을 들으면 어디서 들어본 것 같다.

OSI 모형이라는 (네트워크 5계층, 7계층) 말에서 들어본 적 있을 것이다. 아래의 사진은 위키백과의 예시이다:

 

OSI 모형의 통신(3~5계층 예시)

위의 사진에서 생략되었지만, 7계층 기준으로 각 계층은 계층3:네트워크, 계층4:전송, 계층5:세션 계층이다.

이 글에서 이야기하는 다층 구조도 이것과 비슷하다. 아래의 사진은 NodeJS Layered Architecture라는 글에서 가져왔다:

NodeJS Layered Architecture diagram

이 곳은 굳이 이름을 짓지면, 4계층이 될 것이다. 네트워크에서 사용된 계층구조처럼 각 계층의 역할이 있다.

Service Layer가 Backend application(Server application, Spring이나 ExpressJS, Django같은거) 역할을 해줄 수 있고, Frontend는 API를 통해 Backend에 접근하는 것을 볼 수 있다.

 

다시 3층 구조(3 Tier)라는 이름으로 돌아가보자. 3개의 계층이 있는데 각각 아래 사진처럼 구성되어 있다. 

아래의 사진은 위키백과의 예시이다. 한국어 위키에 깨진 사진이 등록되어 있어서 영어 위키에서 가져옴:

3 Tier application overview

각각 Presentation Tier, Logic Tier, Data Tier로 되어있다.

단어를 보면 알겠지만 프로그램에서 보여지는 것, 알고리즘(우리가 짜는 로직), 그리고 파일(DB일수도)에 대한 내용을 계층으로 구분한 것이다. (그렇다. 별거 없다. 굳이 이렇게까지 글을 쓸 것까지인가라는 생각이 들었다면 당신의 생각이 맞다.)

 

여기는 넘기자

이해를 돕기 위해서 예시를 들었는데, 보면 더 이해가 안갈것 같다. 안보고 넘겨도 괜찮을거 같다.

보고 싶다면 봐도 된다. 보고 더 이해가 가지 않는다고 나를 탓하지 않는다면야.

 

하지만 위에서 얘기한거처럼 OOP와 비슷한 느낌이 있지만, 같지는 않다. 장고 프로젝트의 예시를 보자.

아래 사진은 studygyaan.com라는 곳에서 가져옴:

django project file architecture

장고는 app이라는 것을 기준으로 기능을 분리하는데, 예를 들어 메일, 게시판 등의 앱이 존재할 수 있다.

사진을 보면 apps라는 폴더 아래에 app_1, app_2가 있는데 이것들이 각각 메일, 게시판 등이 되는 것이다.

(앱을 나누는 기준을 명시적으로 정해진 것이 없는 것으로 알고있다. 장고 프로젝트를 메일 프로젝트로 보고 그 안에 세부 기능을 앱으로 분리할 수도 있다. 여기에서는 대충 큼직큼직하게 "앱"스러운 것으로 예시를 적었다.)

 

그런데 장고는 하나의 app안에 view(logic)와 models(data)가 존재한다. (적고나니까 좋은 예시가 아닌 것 같다. 사과하겠다.)

하지만 같은 폴더 안에 있다. 그러면 각각의 app은 작은 단위의 3층 구조 비슷한 구조를 갖고, 그들의 모임이 project가 되는 것인가?

내 생각엔 그렇게 보면 될 것 같다.

 

사실 여기에서 utility나 serializer같은 내용을 포함한 모듈을 app이나 app 외부에서 포함하면 좋겠지만 그런 예시사진을 구하지 못했다.

어쨌든 저 구조는 객체지향적으로 괜찮은 구조다. 그렇지만 django_project 폴더 기준에서 보았을 때는, 우리가 생각하는 다층 구조는 아닌 것 같다고 생각하지 않는가? (반박시 당신의 말이 맞다.)

 

React case

그러면 이제 ReactJS의 예시 아키텍쳐를 보자. dev.to에서 가져온 사진. almin.js architecture이다:

ReactJS layer architecture

Almin은 다층 구조를 지향하기 위해 사용되는 라이브러리인 것 같다.

그래서 그런지, 이 사진을 보면 각 기능별로 모듈이 나뉘어져 있다는 것을 알 수 있다.

 

DB에 접근하는 모듈과 어플리케이션에서 사용되는 모듈, state 관리하는 모듈이 명확히 분리되어 있는 것을 볼 수 있다.

 

여기까지가 다층 구조가 무엇인지에 대한 내용이었다. 그렇다면 왜 다층 구조를 쓰는걸까?

조회수를 위해서 다른 글로 이어가겠다.