로직
흔히 코드 아키텍처를 공부하면서 어플리케이션 로직, 비즈니스 로직 등 개발에서 로직이 나타내는 내용과 뜻을 상기해보곤 한다.
머리로는 대강 이해했다 하면서도, 막상 실전에 들어가면 시간과 일에 쫓겨 로직 따위는 에라 모르겠다! 하고 막연하게 하드 코딩하는 순간을 되풀이하게 된다. 이런 일이 더는 발생하지 않도록 먼저 이론적인 정의부터 시작하자.
어플리케이션 로직
어플리케이션 로직은, 일반적으로 사용자 인터페이스와의 데이터 자원 간의 연결을 담당하며, 사용자 입력 혹은 요청을 처리하고 데이터를 다루어 업무 작업을 반환하는 작업들을 포함한다.
보통 서비스의 전체적인 흐름을 다루는 영역을 이야기하는 경우가 많다. 일련의 예로는 Controller 가 있다. (사용자의 요청을 받고, 그에 해당하는 응답 결과를 다시 이어주는 흐름을 담당한다.)
비즈니스 로직
어플리케이션 로직이 서비스 전체의 흐름을 다루는 영역이라 한다면, 보다 비즈니스 로직은 보다 코어적인 요소에 집중한 로직이다.
흔히 Back-end 설계를 진행하다보면, Controller 와 Service 단을 구분지어 코드를 작성한다. 이러한 이유는 Controller 에서 한번에 다 처리하기 보다는, Controller 는 요청과 응답에 집중하고, 중간과정에서 처리해야할 코어적인 작업은 Service 에게 위임하는 방식을 통해, 코드의 이해나 유지 보수에 도움이 되기 때문이다.
즉 비즈니스 로직은 어플리케이션 로직에 속하는 개념이면서도, 전체 흐름보다는 구체적인 작업을 강조하는 영역이라 할 수 있다.
프레젠테이션 로직
사용자 인터페이스 (UI) 을 담당하는 영역으로써, 기능 수행의 결과를 기반으로 사용자가 이를 확인할 수 있게 페이지를 렌더링하는 영역에 해당한다. 더불어 사용자의 이벤트를 통해 기능 수행 요청을 보내는 작업도 프레젠테이션 로직에 포함된다. 일련의 예로는 HTML, CSS, Javascript 나, MVC 패턴에서 View 역할을 담당하는 코드들이 이에 해당할 수 있다.
유사하면서도 헷갈리는 개발 로직 사례
실제 사례나 개발 경험에서는 상황에 따라 위의 정의한 로직의 의미가 조금씩 다른 경우가 많다. 또한 도메인 로직이나 데이터 로직 등 다양한 영역이 존재하여, 이미 머릿속이 복잡한 나를 더 애처롭게 만든다.
다음은 나름대로 추측한 결과를 바탕으로 자주 만나게 되는 아키텍처의 로직 영역을 작성했다. 개인적인 이해한 내용을 명확히 구분하기 위해 작성한 것이므로, 실제 알고있는 정의와는 많이 다를 수 있다.
"로직" 이란 결국 작업 영역을 분리하기 위한 추상적인 설계이기 때문에, 서비스의 상황이나 환경에 따라 조금씩 해석이 다를 수 있다. 다른 이견이 있다면 무조건 님 말이 다맞음.
Back-end MVC
이미 많이 사용하고 있고, 앞으로도 널리 사용하는 MVC 패턴의 Model, View, Controller의 로직을 나는 다음과 같이 정의했다.
-
Model: 비즈니스/도메인 로직에 해당한다. 일반적으로Back-end MVC의Model영역은DTO (Data Transfer Object)에 해당하는데 이름 그대로 데이터베이스의 결과를 객체화하는 작업이므로, 데이터 로직에 포함될 수 있다고 볼 수도 있다.그러나 그간 내가 경험했던
Back-end영역은MyBatis, JPA, prisma, Mongoose등Model을 대신하여 데이터베이스와 통신하며 데이터 로직을 책임질 수 있는 요소들이 존재했기 때문에, 비즈니스/도메인 로직이 더욱 가깝다고 판단했다. -
Controller: 어플리케이션 로직에 해당한다.controller의 가장 중요한 역할은model과view를 연결하는 작업이기 때문이다.흔히 초기
MVC패턴의 단점 중 하나가,controller의 작업이 다른 두 영역에 비해 너무 많다는 것이었다. 그때는 비즈니스 로직/도메인 혹은 데이터 로직도controller에 포함할 수 있는 개념이라 할 수 있겠지만, 지금에는Domain, Service, Repository등 이를 위임할 수 있는 사례들이 많아졌다.
-
View: 페이지 렌더링을 담당하는 영역인 만큼 프레젠테이션 로직에 해당한다.
Front-end MVC
생소하겠으나, Front-end도 MVC 아키텍처를 반영하려는 시도가 있었다. Back-end MVC와 동일하게 Model, View, Controller 를 통해, 작업 영역을 명확히 구분하여 코드의 이해와 유지 보수를 편하게 하기 위해 사용되었다.
단, 직무 자체가 다른 만큼, Back-end MVC와 차이도 존재한다. 예를들어 Back-end MVC 의 입장에서 보자면 Front-end 는 모두 Back-end MVC의 View의 영역에 해당하기 때문에 Front-end 전체를 프레젠테이션 로직이라 볼 수 있다. 그러나 Front-end MVC 설계 관점에서는, Model, Controller, View 가 명확히 구분되어 있기에 프레젠테이션 로직 외에 다른 로직 영역으로 해석할 수도 있는 것이다.
-
Model: 비즈니스 로직/도메인 로직에 해당한다.Back-end MVC의 경우에는Model이 상황에 따라, 데이터 로직에 포함될 수도 있다고 했으나,API를 담당하는Back-end체계가 명확히 존재하는 서비스라면Front-end MVC의Model은Back-end MVC의Model보다 데이터 로직과의 관련성이 거의 없다.현재
SPA생태계를 보았을 때,Front-end MVC의 기존Model의 역할은 대부분Typescript가 대체했다고 보았다. 서버가 보내는 응답에 대한 객체 구조를 설계하거나, 컴포넌트의props,state,style에 대한 데이터 구조를Typescript를 통해 설계하기 때문이다. -
Controller: 어플리케이션 로직 및 비즈니스 로직에 해당한다. 기존Back-end MVC의Controller의 역할과 유사하게,Front-end MVC의Controller역시 서버의 응답을 통해 얻은 결과를Model을 통해 정의하고, 이를View로 연결하는 과정이, 어플리케이션 로직으로 나누는 것이 적절하다고 보았다.단,
Front-end MVC의Controller는 브라우저나 사용자 환경에 따라서Back-end에서 보낸 응답 결과를 일정부분 가공할 가능성이 크기에, 비즈니스 로직과도 어느정도 관련성이 있다.
-
View: 역시 페이지 렌더링을 담당하는 영역인 만큼 프레젠테이션 로직에 해당한다.Back-end MVC와의 차이를 살펴보자면,back-end에서 템플릿 엔진을 사용하는 경우에는 서버에서 직접 생성한 페이지 결과를 클라이언트에게 반환하는 서버 사이드 렌더링에 가깝다고 할 수 있으나,Front-end MVC의View는 서버의 응답 결과를 기반으로 자바스크립트 코드를 실행하여 브라우저 렌더링을 통해 페이지를 생성하는 클라이언트 사이드 렌더링에 가깝다.
3-tier
현대 소프트웨어 아키텍처의 주요 접근 방식이면서, 서비스 플랫폼 설계 시 가장 많이 사용되는 형태이다.
각 tier 별 적용되는 로직은 다음과 같이 정의했다.
-
Client Tier: 프레젠테이션 로직에 해당한다. 서비스 사용자가 직접 마주하는 계층으로써, 대부분의 작업을 사용자 인터페이스를 지원 설계하는데 사용되는 계층이다.Client Tier를 흔히Presentation Tier혹은Front-end라고 부른다. -
Web Application Server Tier: 어플리케이션 로직 및 비즈니스/도메인 로직에 해당한다.Clienrt Tier를 통해 요청되는 작업이나 이벤트를 수행하고 이에 대한 결과를 가공하여 반환한다. 흔히 해당 계층을Application Tier혹은Business Tier라고 부르기도 하며, 담당하는 작업에 따라서Back-end혹은Middle-ware라 부른다. -
Data Tier: 데이터 로직에 해당하며, 데이터베이스를 통해 데이터를 저장, 조회, 수정, 삭제 등이 이루어지는 계층이다.Data Tier의 관점에서 보았을 때,Web Application Server Tier는Data Tier에 통신 요청을 보내는 클라이언트가 되며,Client Tier입장에서 보았을 때는Web Application Server Tier는 서버가 된다. 흔히Web Application Server Tier와Data Tier를 모두 아울러Back-end라고 부른다.
참고
3-tier 구조
