[Basis] 내가 보려고 정리하는 개발 용어 사전 (2) - 비즈니스 로직 (Business Logic)

<내가 보려고 정리하는 개발 용어 사전>은 블로그에서 시리즈로 연재하고 있는 글이다.
정말 오랜만에 이 시리즈 글을 쓰느라 깜빡했을 수도 있지만, 아래에 1탄 글을 첨부해 뒀으니 궁금하신 분은 가서 읽어보시길 ^___^

[Basis] 내가 보려고 정리하는 개발 용어 사전 (1) - 프레임워크(Framework)와 라이브러리(Library)

"비즈니스 로직을 분리하라"

아키텍처를 공부하다가 많이 보던 문장이다.
혹시 이 문장을 보고 "그래서 비즈니스 로직이 뭔데?" "나는 사업을 하고 있지 않은데 비즈니스가 왜 나오는 거야?"라는 생각을 가져본 적이 없는가?
이번 글에서는 iOS 애플리케이션의 관점에서 바라보는 비즈니스 로직의 개념과 아래 질문들에 대한 답을 찾아보는 시간을 갖으려고 한다.

• 비즈니스, 비즈니스 로직이 무엇인지
• 비즈니스 로직인 코드와 비즈니스 로직이 아닌 코드를 어떻게 구분할 수 있는지
• 그래서 그동안 왜 아키텍처에서 비즈니스 로직을 분리하기 위해 노력해야한다고 말했던 것인지

 

1️⃣ 비즈니스? 나는 이 앱으로 사업을 하고 있는게 아닌데? 

일단 비즈니스 로직(Business Logic)이 무엇인지 알기 위해서는 비즈니스의 개념을 먼저 알아야겠다.

소프트웨어 공학에서 사용하는 비즈니스라는 단어는, 우리가 흔히 사용하는 회사에서의 비즈니스 (Business, 사업 또는 일)와는 엄연히 다른 개념이다.

소프트웨어 공학에서 사용하는 비즈니스는 "소프트웨어가 해결해야하는 현실 세상의 문제"를 의미하는 단어다.
즉, "해당 소프트웨어, 애플리케이션이 존재하는 이유"를 Business라고 이해하면 되겠다.
예를 들어 커머스 애플리케이션의 비즈니스는 상품을 판매하고, 고객은 상품을 검색해서 구매할 수 있게 하는 것이라고 정의할 수 있겠고, SNS 애플리케이션은 사진이나 동영상 시청, 댓글, 공감, 공유 등이 비즈니스의 해당한다고 볼 수 있다.

 

2️⃣ 그래서 비즈니스 로직 (Business Logic)이 뭐라고?

로직(Logic)은 소프트웨어가 특정 작업을 수행하는 과정이나 절차라고 말할 수 있다.
말이 어려워서 그렇지, 그냥 "개발자의 코드 (일련의 과정)"와 같다고 생각하면 된다. 

지금까지 나온 말을 합쳐보면, 비즈니스 로직은 "소프트웨어가 현실 세계의 문제를 해결하는 방법을 구체적으로 구현한 것"이라고 정의할 수 있다.
달리 말해, "애플리케이션의 비즈니스 요구 사항을 구현한 코드"라고 말할 수도 있다!

다시 위에서 말했던 커머스 애플리케이션에서 "고객이 상품을 구매할 수 있어야 한다"는 비지니스 예시를 들어본다고 한다면, 아래가 비즈니스 로직(Business Logic)에 해당하는 내용일 것이다.

• 사용자가 구매할 수 있는 상품 목록을 표시한다. (상품 데이터를 서버로부터 가져와서 UI에 반영하는 로직)
• 사용자가 구매하고자 하는 상품을 클릭해서 장바구니에 담는다. (선택된 상품을 장바구니 데이터 구조에 저장하는 로직)
• 사용자가 상품을 결제한다. (총 금액이 얼마인지 계산하고, 올바른 결제 수단을 선택했는지 검증하고, 사용자의 이벤트를 받아 서버로 결제 요청을 전송하는 로직 등)

조금 비즈니스 로직이 무엇인지 감이 오는가..?
나는 여기까지 봤을 때 아래와 같은 의문 한 가지가 들었는데, 혹시 이 글을 읽는 여러분도 나와 같은 마음을 갖게 되었는지 모르겠다.

"그럼 모든 코드가 다 현실 세계의 문제를 해결하기 위한 거 아니야?"

 

3️⃣ 비즈니스 로직 (Business Logic)을 구분해볼까?

지금까지 배운 내용으로는 마치 한 애플리케이션에서 사용되는 모든 코드가 비즈니스 로직이 아닌가 하는 의문점과 함께, 과연 어떤 것이 비즈니스 로직인지? 어떤 것이 비즈니스 로직이 아닌지? 혼란스러워질 것으로 보인다.

그래서 비즈니스 로직을 구분하기 전에, 비즈니스 로직을 제외하고 또 다른 로직은 어떤 것들이 있는지 설명해 보겠다.

✔️ 프레젠테이션 (UI) 로직
사용자 인터페이스 (User Interface)를 담당하는 로직
여러 기기에 대응할 수 있는 레이아웃을 잡거나, 데이터를 사용자에게 보이도록 만드는 과정, 사용자로부터 이벤트(버튼 클릭이나 스크롤)를 받아 기능 요청을 보내는 것 등이 모두 이 프레젠테이션 로직에 속한다.

✔️ 애플리케이션 (Application) 로직 
애플리케이션 전체의 큰 흐름을 제어하거나 상태를 관리하는 로직
대표적으로 사용자 인터페이스와 데이터 자원 간 연결하는 작업, 화면이 전환되고 각 화면 간 데이터가 전달되는 흐름, 사용자의 인증 상태 관리, 앱 생명주기(App Lifecycle) 등이 애플리케이션 로직으로 볼 수 있다.

아주 크게 본다면, "화면 구현도, 애플리케이션의 흐름을 제어하는 것도, 결국은 모두 현실 세계의 문제를 해결하기 위함이잖아."라고 우길 수도 있겠지만,
이 부분에서는 "근본적인 이 애플리케이션의 비즈니스와 관련된 로직인가" 정도로 구분하는 것이 맞다고 봐야겠다.

*실제 개발 환경에서는 로직의 의미가 매우 다양하게 사용될 수 있기 때문에 사실 명확하게 규정하는 것이 더 어렵다고 보인다.

**프론트에서 느끼는 비즈니스 로직과 백엔드에서 느끼는 비즈니스 로직의 의미가 다를 수 있으며, 애플리케이션 로직과 비즈니스 로직을 구분하지 않는 경우도 있고, 이 외에도 다른 로직(도메인 로직이나 서비스 로직 등)을 정의하는 경우도 있기에, 사실 위에서 말한 이 로직의 개념이나 범위가 절대적이라고 말할 수 없다.
오히려 이를 명확하게 구분하는 것 자체가 불가능한 일이기 때문에, 여기서는 '그저 비즈니스 로직이 이런 느낌이구나' 정도로만 받아들이는 것을 권장한다.

***애초에 로직(Logic)이 작업 영역을 분리하기 위한 추상적인 설계이기 때문에 정확한 기준이 없다고 봐도 되겠다.

 

4️⃣ 그럼에도 불구하고, 아키텍처에서 비즈니스 로직 (Business Logic)을 분리하기 위해 노력하는 이유는?

다시, 커머스 애플리케이션의 예시로 든 비즈니스 로직 하나를 살펴보자.

"사용자가 구매할 수 있는 상품 목록을 표시한다. (상품 데이터를 서버로부터 가져와서 UI에 반영하는 로직)"
-> "어? 비즈니스 로직이라고 말하는 예시에 프레젠테이션 로직이 섞여있는 것 같은데?"라는 의구심이 들었다면 정상.

위에서 보이는 것처럼 비즈니스 로직은 프레젠테이션 로직 또는 애플리케이션 로직으로 구분하지 않으면, 하나의 비즈니스 로직으로 묶일 수 있는 여지(?)가 되게 많다.
그리고 사실, 저 모든 것을 비즈니스 로직이라 묶어도 된다. (잘못된 비즈니스 로직의 정의가 아니라는 말씀!)
앞에서 말한 것처럼 절대적인 구분이 있는 것이 아니라, 개발자의 의도대로 작업 영역을 분리한 정도에 해당하기 때문이다.

하지만, 만약 저 모든 것을 비즈니스 로직으로 묶어서 처리하고 있다면? 굉장히 애플리케이션을 관리하거나 수정, 추가하기가 버거울 것이다.
(MVC의 ViewController가 화면 로직도 담당하고, 네트워크 처리도 담당하고, 생명주기와 화면 전환을 모두 담당하고 있던 Massive VC 문제를 상기시켜봐라.)

💡 즉, MVVM이고 VIPER고 Business Logic을 (대표적으로) Presentation Logic이랑 분리하는 이유는
애플리케이션 개발의 관점에서 관리를 하거나 유지보수를 하는 데 있어, 더 효율적이고 더 명확한 책임을 체계적인 구조 속에서 갖게 하기 위해 필요하다고 정리할 수 있겠다. 

결국 이 글을 마무리하면서 내가 느낀 핵심은,

목표가 비즈니스 로직(Business Logic)을 명확하게 구분해서 "이건 비즈니스 로직이고 이건 아니야!"에 있는 것이 아니라,

"개발자인 내가 얼마큼 각각의 책임을 부여할 것인가, 또는 한 로직을 어떻게 가져갈 것인가"와 같은 아키텍처적 고민에서 비즈니스 로직이 등장한 것이다. "그리고 나는 이 부분을 앞으로 더 잘게 쪼개기 위해 많은 아키텍처를 배워야 한다"에 있다는 것이었다.

누군가에는 정말 별 내용 아닌 글일 수도 있지만, 또 다른 누구에게는 새로운 지식을 전해주는 좋은 글이었길 바라며, 비즈니스 로직 글은 여기서 마무리해보겠다! 끝!