[ Eassy - Technology, IT, Web ] 비지니스 로직(규칙, 층) 과 프레젠테이션 로직(규칙, 층) 이란 무엇인가?

Web 개발을 하다 보면

쉽게 볼 수 있는 개념들을 꼽으라면

비지니스 로직과 

프레젠테이션 로직 이 둘이 아닐까 한다.

물론 Web 뿐만 아니라 

다른 분야에서도 사용할 수 있는 개념들이다.

이러한 개념을 Web쪽에서 자주 사용하다보니

그렇게 느끼는 것 뿐이다.

어쨋든

이러한 비지니스 로직과 프레젠테이션 로직에 대해

그리고 정의에 대해 이야기하는 사람은 매우 드문 것 같다.

왜냐하면 

사실 몰라도 되기 때문이다.

개발자로서 

그리고 프로그래머 로서 몰라도 

코딩을 하는데에는 지장이 없다.

하지만 단순히 코딩이아닌 

더 위를 목표로 하고 있다면

즉, 엔지니어를 목표로 하고 있다면

당연히 이러한 개념에 대해 알고 있을 뿐만 아니라

비지니스 로직과 프레젠테이션 로직이 무엇이며,

자신의 생각을 이야기 할 수 있어야 하며,

더 나아가 어떤 개념이 좀 더 정확한지에 대해 

이야기 해봐야 한다.

그래야 서로 원활한 

커뮤니케이션이 가능해져서

생산성이 향상될 수 있을 것이다.

이전에도 말했다시피

IT 용어는 필요에 의해 만들어지고

나중에 개념화되기 때문이다.

그렇기 때문에 

아무리 검색을 해봐도 누군가가 명확하게 

정의를 알려주는 사람은 사실상 없다고 보는 것이 옳을 것이다.

하지만

개발자들은 코딩을 하느라 바쁘기 때문에,

그리고 모여서 이러한 정의를 내리고 

하는데에는 익숙하지 않기 때문에 

즉 커뮤니케이션 능력이 비교적 떨어지기 때문에

개념에 대해 확실하게 정의가 내려지기 힘들다.

모인다고 하더라도 소수 일부의 사람들이 모여서 

이야기를 하기 때문에 그런 자리에서 내려진 결론에

큰 힘을 받기는 힘들다.

그렇게 애매모호한 상태로 개념을 냅두게 된 결과가

지금의 상태라고 생각한다.

그런 상황에서 내가 할 수 있는 것은 

글을 쓰는 것, 단 하나 뿐이 아니겠는가?

글을 씀으로써

나의 의견을 표출하는 것 뿐이다.

그렇기 때문에 오늘의 에세이 주제는 

비지니스 로직과 프레젠테이션 로직에 대해 이야기 해보고자 한다.

비지니스 로직(규칙, 층)에 대해

먼저 비지니스 로직에 대해 

그리고 그에 관련된 규칙과 층에 대해 이야기 해보자.

우선 우리들 모두의 위키 영문판을 참고 해보자.

위키피디아에서는 비지니스 로직에 대해 아래와 같이 이야기한다.

비지니스 로직(Business Logic) 또는 도메인 로직(Domain Logic)은
현실 세계에서 어떻게 데이터를 만들고 저장하고 바꿀 것인지에 대한
비지니스 규칙(Business Rules)을 인코드(Encodes) 한,
소프트 웨어 안의 프로그램의 한 부분이다.

—위키피디아(영문판), Business Logic

즉, 비니지스 규칙을 실제 코딩화 한 것이고,

그 안의 로직이나 알고리즘으로서 표현 한 것이

비지니스 로직 또는 [1]도메인 로직 이라고 하는 것 같다.

그렇다면 여기서 좀 더 들어가서 

비지니스 규칙(Business Rules)에 대해서도 

이야기 해볼 필요가 있을 것이다.

역시 IT 용어 답게

인용이나 출처를 요구하는 내용이 많다.

그렇기 때문에 앞 부분만 보기로 하겠다.

비지니스 규칙은 비지니스의 일부 정의 또는 제한하여,
항상 True 또는 false으로 해석되는 것을 말하며,
특히 이 규칙은 용어(terms),
사실(facts) 또는 규칙(rules)이 포함 된다.

비지니스 규칙은
비지니스 구조를 선언(assert)하거나
제어 또는 영향을 주기 위한 것이다.

—위키피디아(영문판), Business Rule

즉,

비지니스 로직을 프로그래밍으로 본다면

비지니스 규칙은 프로그래밍을 위한 

클래스 또는 함수의 이름 부터 시작해 

변수 이름, 알고리즘의 전반적인 틀을 문서화한

설계라고 보면 얼추 비슷할 것 같다.

그렇다면 우리는 좀 더 깊게 들어갈 필요가 있다.

왜냐하면 이 비지니스(Business)라는 말이 

매우 거슬리기 때문이다.

대충은 직감적으로는 느낄 수  있지만

정확히 여기서 비지니스가 무엇인지에 대해서는 

명확하지 않다.

우리들 모두의 위키피디아에서는

아래와 같이 정의내리고 있다.

간단히 말해서
"이익을 얻기 위해 시작된 모든 활동이나
기업을 말한다.
그것이 한 회사나 복수의 회사, 파트너쉽, 또는
공직적인 조직을 의미하는 것은 아니지만
거리 행상인부터 일반 자동차에 이르기 까지 다양할 수 있다."

—위키피디아(영문판), Business

애초에 비지니스 단어라는 것이

명확하게 이거다라고 이야기하기는 힘들 것 같다.

그렇기 때문에 

위의 정의를 기반으로 

위에서 말하는 비지니스 대해 나는

"상품화되어진 소프트웨어 및 하드웨어"라고 

일단은 제안하고,

이를 기반으로 이야기를 진행하겠다.

다음으로 비지니스 로직 층(Business Logic Layer)는

당연히 이러한 비지니스 로직들이 모여 있는 계층 일 것이다.

좀 더 정확히는 비지니스 규칙을 기반으로 

코딩화(Encodes)된 비지니스 로직들이 모여 있는 

계층(Layer)이라고 정의 내릴 수 있을 것이다.

프레젠테이션 로직(규칙, 층)에 대해

비지니스 로직에 대해 이야기 했다면 

그 다음에는 프레젠테이션 로직(Presentation Logic)에 대해서도 

이야기 해볼 필요가 있을 것이다.

비지니스 로직에 대해 이해가 됐다면

프레젠테이션 로직에 대한 이해가 다소 쉬울 수 있다.

왜냐하면 이 비지니스 로직을 

실제 인터페이스화 하기 위한 로직이

프레젠테이션 로직이기 때문이다.

그렇다면 이제 다시 

우리들의 위키피디아를 살펴보자.

프레젠테이션 로직은 비지니스 오브젝트(비지니스 로직)가
팝업 화면과 드롭 다운 매뉴 중
어떤 것을 선택할 것인지와 같이
소프트웨어 사용자에게 표시되는 로직을 말한다.

프레젠테이션 로직에서 비지니스 로직을 분리하는 것은
소프트웨어 개발 및 프레젠테이션과 컨텐츠를
분리하려하는 사례의(an instance of) 중요한 관심사이다.

—위키피디아(영문판), Presentation Logic

즉, 비지니스 로직 층에 있는 수 많은 

비지니스 로직들을 어떻게 사용자에게 보여줄지에 대한 로직이

프레젠테이션 로직(Presentation Logic)이라 말 할 수 있을 것이다.

다시 말해서 사용자 인터페이스(UI)를 어떻게 표시할까에 대한

로직이 이 프레젠테이션 로직이라는 것이다.

이어서 프레젠테이션 규칙과 층에 대해서는

사실상 프레젠테이션 규칙과 층도

비지니스 로직 때와 동일하기 때문에 

따로 언급하지는 않겠다.

IT업계에서는 흔히 

프론트 엔드 단에서 어떻게 표시할 것인가

라고 이야기 할때가 있는데

여기서 말하는 프론트 엔드(Front-End)가 

프레젠테이션 로직이 같은 의미를 지니고 있다고 봐도 무방할 것 같다.

그렇다면 동일하게 

위에서 말한 비지니스 로직은 

IT 업계에서 특히 Web관련 업계에서 자주 말하는

백 엔드(Back-End)와 같은 의미를 

지니고 있다고 생각하면 편할 것이라 생각 된다.

다른 사람들은 어떻게 생각할까?

우리는 위에서 

이 두 가지 개념에 대해 추상화 한 것에 불과하다.

좀 더 현실 세계에서 와닿을 수 있을 정도로

세부적으로 정의를 내릴 필요가 있을 것이다.

여기서는 다른 사람들의 이야기를 조금 들어보자.

나는 이에 대해 결론을 내리기 위해

구글링을 하다가 납득할만한 의견을 몇 가지 찾았다.

2014년에 스레드가 시작된 글인데

내용은 아래와 같다.

질문자는 2009년 부터 웹 개발 관련 일을 하고 있는데,
PHP로 시작해 ASP.NET으로 옮길 때,
비지니스 로직과 비지니스 규칙에 중점을 둔
DDD와 OOAD에 대해 많이 들었다.

하지만 지금까지 개발한 모든 앱은
CRUD 작업에 관한 것이 였지
비지니스 로직과 비지니스 규칙에 관해 본적이 없다.

나는 그것이 실제로 무엇을 할 수 있는지 모르겠다.
이 비지니스 로직은 무엇이며,이것이 앱에 어떻게 적용됩니까?

—StackExchange, What really is the “business logic”?

라는 것이 스레드의 질문 내용이다.

그 스레드에 대한 답변 중 

가장 많은 추천을 받았던 의견과 

개인적으로 끌리는 의견을 몇 가지 소개하려고 한다.

CRUD는 Create, Read, Update 및 Delete의 약자로서
이것들은 DB에서 수행할 수 있는 기본적인 네가지 작업 입니다.

・・・

그러나 비지니스 로직은
데이터베이스 레코드 작성, 읽기, 업데이트 및 삭제(CRUD)보다
애플리케이션에 더 많은 영향을 끼칩니다.

비지니스 로직 또는 도메인 로직은
데이터를 작성(create), 저장 및 변경(update) 방법을 결정하는
실제 세계의 비지니스 규칙을
인코딩(encodes)하는 프로그램의 일부입니다.

비지니스 객체가 서로 상호 작용하는 방법을 규정하고
비지니스 객체에 엑세스하고
업데이트하는 방법과 경로를 적용합니다.

・・・

비지니스 규칙은 조직(Organization)에 적용되는
작업(Operations), 정의(Define) 및
제약 조건(Constraints)을 설명합니다.

작업은 집합적으로 프로세스를 형성하며,
모든 비지니스는 이러한 프로세스를 사용하여
작업을 수행하는 시스템을 구성합니다.

—StackExchange, What really is the “business logic”? (Answer)

위에서 위키피디아를 기반으로한 정의와 큰 차이는 없어 보이지만

좀 더 현실 세계에 근접한 정의이기 때문에 

다소 이쪽이 이해하기는 편한 것 같다.

그 밑 쪽에 현실에서의 애플리케이션의 예도 있으니

관심이 있다면 직접 보길 바란다.

많은 추천은 얻지 못했지만 

좋은 예라고 생각하는 답변을 또 한 가지 소개 하겠다.

비지니스 로직은 기본적으로
유효성(Validation)과 흐름(Flow)로 구성됩니다.

어떤 비지니스 로직에 따르면
수량 1(qty1)은 수량 2(qty2)보다 커야한다고 가정해 봅시다.

그럴 경우 구매할 품목 수는
재고 품목 보다 적거나 같아야 합니다.

어떤 한 애플리케이션에서
비지니스를 하는 사람들은 위의 예를
비지니스 규칙이라고 말하므로
이 비지니스 논리(유효성)을 시행하기 위해 코드를 작성합니다.

다른 애플리케이션에서는
주문한 수가 재고 수 보다 많으면 주문을 수락한 다음
그 차이에 20%를 더 한 주문을 이용자가 하기 위해
비지니스 로직을 작성한다고 말한다(흐름).

CRUD는 단순히 스토리지에서
데이터를 가져오고, 내보낸 것을 말하지만,

비지니스 로직은
해당 데이터로 수행 할 작업과
그 데이터를 어떻게 변형 시킬지를 결정 합니다.
(what transformations you are allowed to make to it. )

—StackExchange, What really is the “business logic”? (Answer)

내 생각에는 이쪽의 설명이 

많은 추천을 받은 쪽 보다 더 좋은 예시 인것 같다.

결론

그렇다면 드디어 결론을 내릴 수 있을 것이다.

비지니스 로직과 프레젠테이션 로직은 각각 

흔히 말하는 백 엔드와 프론트 엔드 내의 로직으로 

CRUD(Crate, Read, Update, Delete)를 포함한

명확하게 추상화 된 개념이라고 할 수 있을 것 같다.

예컨데, 은행의 예금, 출금 시스템을 로직화 한다면

정확하게 비지니스 로직에 가까울 것이다.

왜냐하면 예금, 출금은 은행에서 하고 있는 

은행이라는 기업에서 이익을 얻기 위한 

가장 대표적인 비지니스이기 때문이다.

이것을 로직으로 구현한다면 비지니스 로직이 될 것이고, 

이 비지니스 로직 안에 

예금, 출금에서 현실의 제약 조건

(잔고 이상으로는 출금 할 수 없는 등의) 비지니스 규칙이 설정될 것이다.

그리고 이를 어떤 순서로, 

사용자에게 어떤 것을 보여주고 숨길 것인지에 대한 등의 여부는 

프레젠테이션 로직에서 결정하게 될 것이다.

어떻게 본다면 프레젠테이션 로직은 

비지니스 로직에 강력하게 종속되어 있다고 볼 수도 있을 것 같다.

이렇게 해서 

나의 결론은 마무리 하고자 한다.

물론

나의 결론이 결코 진리는 아니다.

내가 다듬은 부분적 진리일 뿐이며

이 이상은 좀 더 많은 IT업계의 사람들과 

논의가 있어야 할 것이다.

---

[1] 도메인 로직 :

Business logic is teleological (concerned with how to achieve an objective) while domain logic is ontological (what exists, or the object model that's used to reason with)

---

참고 :

https://en.wikipedia.org/wiki/Business_logic

https://en.wikipedia.org/wiki/Business_rule

https://en.wikipedia.org/wiki/Business

https://en.wikipedia.org/wiki/Presentation_logic

https://systems-analysis.net/architecture/introduction.html

https://softwareengineering.stackexchange.com/questions/234251/what-really-is-the-business-logic

https://stackoverflow.com/questions/360860/what-is-domain-logic