Database/Server

Database의 책임 - DB는 어디까지 해줘야 하는가? (+ 데이터 가공, 비즈니스 로직, 계산 등)

JaeHoney 2022. 5. 6. 08:40

Database의 책임

이전부터 비즈니스 로직이 어디에 있어야 하는지는 큰 관심사였다고 한다.

 

나는 Controller, Service, Repository, Dto 등의 책임에 대해서 자료를 많이 봤지만 "DB는 어떤 작업까지 처리하는 것이 바람직한가?" 그러한 생각을 해본적이 없었다.

 

우리 회사의 서비스들을 보면 DB에서 SELECT절에서 CONCAT()이나 IF()를 통해 가공해서 내려주는 경우가 많다.

그래서 그것을 프론트단에서 아주 손쉽게 사용할 수 있다.

 

추가적으로 복잡한 비즈니스 로직을 DB Layer에서 태우는 경우도 있다. 뭔가 Application Layer에서 로직을 태우면 선형으로 순회하면서 레코드 하나씩 가공을 해줘야 한다는 부담감 때문이었다.

 

데이터베이스(Database)의 책임에 대해 알아보자.

 

Three-Tier Architecture

3계층 구조(3 Tier Architecture)란 어떠한 플랫폼을 3 계층으로 나누어서 별도의 논/물리적 장치에 구축 및 운영하는 설계 구조를 말한다.

 

예를 들어 웹 서비스를 구축한다고 했을 때 하나의 서비스 단위가 아니라 3가지 계층으로 나누어 책임을 분리하는 것이다.

 

각 계층은 각각 표현 계층(Presentation Tier)와 애플리케이션 계층(Application Tier), 데이터 계층(Data Tier)을 말한다.

 

각 계층이 다른 공간에 저장되는 것 뿐 아니라 책임과 역할을 분리하는 것도 중요하다.

 

Presentation Layer

Presentation Layer는 흔히 뷰를 말한다.

 

사용자와의 최종 접점에 위치하며 데이터를 요청하거나 요청한 데이터를  출력하는 계층이다.

처리 결과를 사용자에게 가공해서 보여주는 역할은 Presentation Layer에서 하는 것이 적합하다.

 

가령 하나의 API를 여러 곳에서 사용하는 상황이라고 생각해보자.

 

가공을 Presentation Layer에서 하면 여러 Client에서 각각의 요구사항에 맞게 데이터를 가공할 수 있다. 이러한 원리를 깨면 Layered Architecture를 사용하는 이유가 사라진다.

 

추가적으로 하드웨어 성능이 발전함에 따라 점점 Client에게 데이터 가공을 위임하는 것도 트렌드라고 한다.

 

Application Layer

Application Layer는 Spring이나 NodeJS 등으로 동작하는 앱 서버를 말한다.

 

비즈니스 로직을 태운다거나 계산한다거나 하는 동작은 Application Layer에서 하는 것이 바람직하다.

 

데이터베이스에서 로직을 태우면 아래와 같은 문제가 생깁니다.

  • 디버깅할 수 없다.
  • SQL문이 복잡해진다.
    • 객체 지향 언어는 복잡한 SQL보다 표현력이 뛰어나서 결과를 파악하기 쉽다.
  • 분할, 결합 등 확장이 어렵다.
  • 문제가 발생했을 때 오류 추적이 어렵다.

즉, 무결성이나 일관성에 관련된 책임만 Database에 존재해야 한다. 거기서 데이터를 필터링하고 그룹핑해서 내려주는 것이면 충분하다.

 

결론

물론 Architecture에 따라 Database에서 로직을 태우고 데이터를 가공해도 괜찮다.

 

하지만 오늘날 Layered Architecture를 사용하는 현재의 Structure에는 적합하지 않다.

 

데이터베이스는 행위나 동작의 책임을 분리해서 데이터를 정리하고 저장하는 용도로 사용하고, 행위나 동작은 다른 Layer로 책임을 인가해서 App서버, DB서버, 클라이언트가 각각 독립적으로 존재하는 것이 유지보수에 좋다.

 

즉, 데이터베이스(Database)는 데이터를 필터링(Filtering)하고 그룹핑(Grouping), 솔팅(Sorting)해서 내려주고 App Layer에서 로직을 태우거나 계산하고 Presentation Layer에서 데이터를 가공해서 표시하게끔 책임을 분리하는 것이 설계와 유지보수 관점에서 바람직하다.

 


Reference