2021.09.23

비즈니스 로직을 DB가 아닌 앱에 넣어야 하는 이유

Lee Atchison | InfoWorld
SQL 데이터베이스에서 데이터를 꺼내야 하는데, 이 데이터를 꺼내기 위해 여러 테이블 조인과 여러 필터 조건, 세밀한 WHERE 절이 포함된 복잡한 쿼리가 필요한 상황. 개발자라면 흔하게 부닥치는 장면이다.

물론 방법은 많다. 마이SQL, 포스트그레SQL과 같은 SQL 데이터베이스는 필요한 데이터를 쿼리로 정확히 끄집어내는 복잡한 조인과 필터링, 정렬 기능이 탁월하다. 원래 데이터베이스의 용도가 그것이기도 하다. 애플리케이션 코드에 로직을 집어넣는 방법보다 '훨씬' 쉽다. 하지만 이 방법은 틀렸다.

데이터베이스 내에서 이와 같은 작업을 수행하면 사실상 애플리케이션 비즈니스 로직을 데이터베이스 안에 밀어 넣게 된다. 애플리케이션 코드에서 비즈니스 로직을 꺼내 데이터베이스 로직으로 옮기는 것이다. 그 결과는? 원하는 데이터 결과를 추출하기 위해 사용하는 데이터베이스 리소스는 많아지고 애플리케이션 서버 리소스는 적어진다.

데이터 삽입 요구사항을 구현할 때도 마찬가지다. 보통 데이터베이스에 데이터를 넣을 때는 그 데이터가 유효하고 충돌하지 않으며 정확한지를 애플리케이션이 아닌 데이터베이스에서 수행한다. 충돌 조건을 데이터베이스 스키마 요구사항에 넣고, 삽입 중인 데이터에서 오류가 탐지되면 데이터베이스가 오류를 던지도록 한다. 예를 들어 UNIQUE 한정 조건과 인덱스를 사용하는 경우가 그렇다.
 

애플리케이션 리소스가 더 확장하기 쉽다

이런 문제를 제기하면 많은 데이터베이스 엔지니어가 반문하다. “원래 그렇게 사용하라고 있는 기능이다!”라거나 “그런 방식으로 처리해야 하는 것도 있다”고 주장한다. 분명히 말하지만, 필자 역시 데이터베이스에서 이와 같은 확인 및 검증을 수행해야 하는 경우도 있다는 것은 잘 알고 있다.

그래서 필자는 데이터베이스에서 애플리케이션 로직을 완전히 배제해야 한다고 말하는 것이 아니다. 데이터베이스가 애플리케이션 비즈니스 로직을 떠맡는 경우를 최소화하고, 할 수 있는 최대한 애플리케이션 코드 자체에서 애플리케이션 비즈니스 로직을 다뤄야 한다고 말하고 싶은 것이다.

이유는? 일반적으로 애플리케이션 서버 리소스가 데이터베이스 서버 리소스보다 확장하기 훨씬 더 쉽기 때문이다. 이것은 거의 보편적 진리다. 대부분의 웹 애플리케이션에서 트래픽이 증가하면 손쉽게 애플리케이션 서버를 추가해 늘어난 부하를 처리할 수 있다. 반면 SQL 데이터베이스 확장은 애플리케이션 서버를 추가하기보다 훨씬 더 어렵다.

예를 들어 애플리케이션에서 사용 가능한 리소스를 보자. 애플리케이션 코드 계층(서비스 포함)은 즉시 사용할 수 있고 확장하기 쉬운 컴퓨팅 리소스로 구성되는 반면 데이터베이스를 구성하는 컴퓨팅 리소스는 빈약하다고 보는 것이 정확하다. 즉, 데이터베이스 리소스는 빈약하고 컴퓨팅 리소스는 풍족하다.

일단 여기까지 생각하면, 로직을 최대한 애플리케이션 계층에 넣는 것이 쉬운 확장에 유리하다는 것을 알 수 있다. 데이터베이스 티어에 비즈니스 로직을 넣으면 그 비즈니스 로직의 확장성이 크게 제한된다.
 

복잡한 필터링 처리는 데이터베이스의 일

물론 모든 비즈니스 로직을 항상 애플리케이션 계층에 둘 수 있는 것은 아니다. 특정 쿼리를 데이터베이스 티어에 넣어야 하는 경우도 가끔 있다. 예를 들어 반환되는 결과의 양을 통제하려면 데이터베이스 티어에 넣는 것이 타당하다. 매우 큰 데이터베이스 테이블에 대한 복잡한 필터 조건을 가진 쿼리를 생각해 보자.

select * from mytable where 

대규모 데이터 집합을 대상으로 복잡한 필터 쿼리를 실행한 후 기대되는 결과는 이 테이블 중에서 몇 개의 행에 불과할 수 있다. *는 이 소수의 행의 모든 데이터를 반환한다. 그러나 데이터베이스 대신 애플리케이션 계층에서 이 복잡한 필터 쿼리를 실행하려면 일반적으로 먼저 데이터베이스에서 모든 데이터를 불러와야 한다. 대체로 다음과 같은 형태가 된다.

select * from mytable

이 경우 mytable의 모든 데이터가 애플리케이션 계층에 반환된다. 이후 애플리케이션 계층은 이 데이터를 대상으로 적용한 필터 조건에 맞지 않는 모든 행을 버린다. 문제는 이 요청을 처리하려면 mytable의 모든 내용을 애플리케이션 계층으로 전송해야 한다는 것이다. 대용량 데이터 집합의 경우 현실적으로 불가능한 일이다.

그러나 많은 경우 쿼리 또는 일련의 쿼리를 리팩토링하는 것만으로 이와 같은 문제를 피하고 과도한 데이터 트래픽 없이 애플리케이션에서 더 많은 로직을 실행할 수 있다. 한 가지 방법은 데이터 필터링을 데이터 추출과 분리하는 것이다.
 

추출과 필터링 분리하기

우리는 흔히 결과 필터링과 결과 추출의 개념을 하나의 쿼리로 결합한다. 특히 대량의 데이터가 포함된 큰 테이블을 다룰 때는 필요한 행을 선택하기 위한 모든 필터링과 사양을 수행하는 쿼리를 작성한 다음 이 쿼리를 통해 선택된 행에서 필요한 모든 데이터를 반환한다. 보통 다음과 같다.

select * from mytable where 

얼핏 괜찮아 보인다. 그러나 쿼리에 복잡한 조인이나 다른 작업이 포함되는 경우 데이터베이스에 큰 부담이 되고 데이터베이스 리소스가 소진될 수 있다.

이 문제를 피하는 방법의 하나는 모든 행에서 필터 쿼리에 필요한 필드만 반환하는 첫 쿼리를 수행한 다음 애플리케이션에서 필터링 로직을 수행하는 것이다. field1과 field2가 위의 에서 실제로 관여하는 필드라고 가정해 보자. 첫 쿼리에서 그 데이터만 가져온다.

select id,field1,field2 from my_table

그런 다음 애플리케이션 코드에서 field1과 field2에 대해 복잡한 필터 쿼리 로직을 수행할 수 있다. 결과는 복잡한 쿼리에 일치하는 mytable의 행 ID 목록이다. 일치하는 ID 목록을 구하고 나면 사전에 필터링된 행에서 실제 데이터를 가져오는 후속 쿼리를 수행한다.

select * from my_table where id in (3,5,123,392,...)

두 쿼리 모두 매우 간단하게 실행할 수 있다. 데이터베이스에서 해야 하는 복잡한 작업은 없다. 반환할 데이터를 선택하는 데 필요한 비즈니스 로직이 애플리케이션 계층에서 실행되지만 데이터베이스에서 애플리케이션으로 전송해야 하는 부가적인 데이터는 극히 미미하다. 별도의 필터링 쿼리와 데이터 추출 쿼리로 쿼리를 분할함으로써 요청을 리팩토링해서 복잡하고 리소스 소비량이 큰 비즈니스 로직을 데이터베이스가 아닌 애플리케이션에서 실행했다.
 

반환되는 결과를 대상으로 하는 작업 피하기

비즈니스 로직을 데이터베이스에서 꺼내 애플리케이션 계층으로 옮기는 또 다른 쉬운 방법은 반환된 결과에 대한 계산을 데이터베이스에서 수행하지 말고 애플리케이션에서 수행하는 것이다. 즉, 다음과 같은 쿼리를 지양한다.

select POWER(SQRT(field1)*SIN(field2),5) from my_table where ...

대신 다음과 같이 한다.

select field1,field2 from my_table where ...

그런 다음 반환된 결과로 애플리케이션에서 POWER(SQRT(field1)*SIN(field2),5) 등의 작업을 수행한다. 결과적으로, 계산을 수행하는 데 필요한 모든 컴퓨팅이 희소한 데이터베이스 리소스가 아닌 풍부한 애플리케이션 리소스를 활용하게 된다.
 

조인을 애플리케이션 계층으로 옮기기

복잡한 조인은 데이터베이스 리소스가 필요한 또 다른 영역이다. 데이터베이스에서 데이터를 조인하지 말고, 조인 로직을 최대한 애플리케이션 계층으로 옮긴다. 이렇게 코드를 리팩토링하면 확장성을 늘리면서 데이터베이스에 대한 부하를 대폭 줄일 수 있다.
 

고리 끊기

물론 항상 이런 방식으로 쿼리를 리팩토링할 수 있는 것은 아니다. 데이터베이스 자체 내에서 복잡한 쿼리를 수행해야 할 때도 있다. 그러나 복잡한 쿼리를 할 수 있는 최대한 제거하면 빈약한 데이터베이스 리소스에 대한 의존을 줄이고 풍족한 애플리케이션 수준 리소스에 대한 의존을 늘릴 수 있다.

정리하면, 다음부터는 여러 조인과 다양한 필터링 로직을 사용하는 크고 길고 복잡한 쿼리를 보며 자랑스럽게 생각하지 말자. 복잡한 쿼리를 더 간단한 쿼리, 필요하다면 여러 개의 쿼리와 애플리케이션 계층에서 실행되는 비즈니스 로직으로 대체하는 방법을 고민하자. 이렇게 하고 나면 애플리케이션이 확장됨에 따라 개선된 유연함의 가치를 체감하게 될 것이다. editor@itworld.co.kr


2021.09.23

비즈니스 로직을 DB가 아닌 앱에 넣어야 하는 이유

Lee Atchison | InfoWorld
SQL 데이터베이스에서 데이터를 꺼내야 하는데, 이 데이터를 꺼내기 위해 여러 테이블 조인과 여러 필터 조건, 세밀한 WHERE 절이 포함된 복잡한 쿼리가 필요한 상황. 개발자라면 흔하게 부닥치는 장면이다.

물론 방법은 많다. 마이SQL, 포스트그레SQL과 같은 SQL 데이터베이스는 필요한 데이터를 쿼리로 정확히 끄집어내는 복잡한 조인과 필터링, 정렬 기능이 탁월하다. 원래 데이터베이스의 용도가 그것이기도 하다. 애플리케이션 코드에 로직을 집어넣는 방법보다 '훨씬' 쉽다. 하지만 이 방법은 틀렸다.

데이터베이스 내에서 이와 같은 작업을 수행하면 사실상 애플리케이션 비즈니스 로직을 데이터베이스 안에 밀어 넣게 된다. 애플리케이션 코드에서 비즈니스 로직을 꺼내 데이터베이스 로직으로 옮기는 것이다. 그 결과는? 원하는 데이터 결과를 추출하기 위해 사용하는 데이터베이스 리소스는 많아지고 애플리케이션 서버 리소스는 적어진다.

데이터 삽입 요구사항을 구현할 때도 마찬가지다. 보통 데이터베이스에 데이터를 넣을 때는 그 데이터가 유효하고 충돌하지 않으며 정확한지를 애플리케이션이 아닌 데이터베이스에서 수행한다. 충돌 조건을 데이터베이스 스키마 요구사항에 넣고, 삽입 중인 데이터에서 오류가 탐지되면 데이터베이스가 오류를 던지도록 한다. 예를 들어 UNIQUE 한정 조건과 인덱스를 사용하는 경우가 그렇다.
 

애플리케이션 리소스가 더 확장하기 쉽다

이런 문제를 제기하면 많은 데이터베이스 엔지니어가 반문하다. “원래 그렇게 사용하라고 있는 기능이다!”라거나 “그런 방식으로 처리해야 하는 것도 있다”고 주장한다. 분명히 말하지만, 필자 역시 데이터베이스에서 이와 같은 확인 및 검증을 수행해야 하는 경우도 있다는 것은 잘 알고 있다.

그래서 필자는 데이터베이스에서 애플리케이션 로직을 완전히 배제해야 한다고 말하는 것이 아니다. 데이터베이스가 애플리케이션 비즈니스 로직을 떠맡는 경우를 최소화하고, 할 수 있는 최대한 애플리케이션 코드 자체에서 애플리케이션 비즈니스 로직을 다뤄야 한다고 말하고 싶은 것이다.

이유는? 일반적으로 애플리케이션 서버 리소스가 데이터베이스 서버 리소스보다 확장하기 훨씬 더 쉽기 때문이다. 이것은 거의 보편적 진리다. 대부분의 웹 애플리케이션에서 트래픽이 증가하면 손쉽게 애플리케이션 서버를 추가해 늘어난 부하를 처리할 수 있다. 반면 SQL 데이터베이스 확장은 애플리케이션 서버를 추가하기보다 훨씬 더 어렵다.

예를 들어 애플리케이션에서 사용 가능한 리소스를 보자. 애플리케이션 코드 계층(서비스 포함)은 즉시 사용할 수 있고 확장하기 쉬운 컴퓨팅 리소스로 구성되는 반면 데이터베이스를 구성하는 컴퓨팅 리소스는 빈약하다고 보는 것이 정확하다. 즉, 데이터베이스 리소스는 빈약하고 컴퓨팅 리소스는 풍족하다.

일단 여기까지 생각하면, 로직을 최대한 애플리케이션 계층에 넣는 것이 쉬운 확장에 유리하다는 것을 알 수 있다. 데이터베이스 티어에 비즈니스 로직을 넣으면 그 비즈니스 로직의 확장성이 크게 제한된다.
 

복잡한 필터링 처리는 데이터베이스의 일

물론 모든 비즈니스 로직을 항상 애플리케이션 계층에 둘 수 있는 것은 아니다. 특정 쿼리를 데이터베이스 티어에 넣어야 하는 경우도 가끔 있다. 예를 들어 반환되는 결과의 양을 통제하려면 데이터베이스 티어에 넣는 것이 타당하다. 매우 큰 데이터베이스 테이블에 대한 복잡한 필터 조건을 가진 쿼리를 생각해 보자.

select * from mytable where 

대규모 데이터 집합을 대상으로 복잡한 필터 쿼리를 실행한 후 기대되는 결과는 이 테이블 중에서 몇 개의 행에 불과할 수 있다. *는 이 소수의 행의 모든 데이터를 반환한다. 그러나 데이터베이스 대신 애플리케이션 계층에서 이 복잡한 필터 쿼리를 실행하려면 일반적으로 먼저 데이터베이스에서 모든 데이터를 불러와야 한다. 대체로 다음과 같은 형태가 된다.

select * from mytable

이 경우 mytable의 모든 데이터가 애플리케이션 계층에 반환된다. 이후 애플리케이션 계층은 이 데이터를 대상으로 적용한 필터 조건에 맞지 않는 모든 행을 버린다. 문제는 이 요청을 처리하려면 mytable의 모든 내용을 애플리케이션 계층으로 전송해야 한다는 것이다. 대용량 데이터 집합의 경우 현실적으로 불가능한 일이다.

그러나 많은 경우 쿼리 또는 일련의 쿼리를 리팩토링하는 것만으로 이와 같은 문제를 피하고 과도한 데이터 트래픽 없이 애플리케이션에서 더 많은 로직을 실행할 수 있다. 한 가지 방법은 데이터 필터링을 데이터 추출과 분리하는 것이다.
 

추출과 필터링 분리하기

우리는 흔히 결과 필터링과 결과 추출의 개념을 하나의 쿼리로 결합한다. 특히 대량의 데이터가 포함된 큰 테이블을 다룰 때는 필요한 행을 선택하기 위한 모든 필터링과 사양을 수행하는 쿼리를 작성한 다음 이 쿼리를 통해 선택된 행에서 필요한 모든 데이터를 반환한다. 보통 다음과 같다.

select * from mytable where 

얼핏 괜찮아 보인다. 그러나 쿼리에 복잡한 조인이나 다른 작업이 포함되는 경우 데이터베이스에 큰 부담이 되고 데이터베이스 리소스가 소진될 수 있다.

이 문제를 피하는 방법의 하나는 모든 행에서 필터 쿼리에 필요한 필드만 반환하는 첫 쿼리를 수행한 다음 애플리케이션에서 필터링 로직을 수행하는 것이다. field1과 field2가 위의 에서 실제로 관여하는 필드라고 가정해 보자. 첫 쿼리에서 그 데이터만 가져온다.

select id,field1,field2 from my_table

그런 다음 애플리케이션 코드에서 field1과 field2에 대해 복잡한 필터 쿼리 로직을 수행할 수 있다. 결과는 복잡한 쿼리에 일치하는 mytable의 행 ID 목록이다. 일치하는 ID 목록을 구하고 나면 사전에 필터링된 행에서 실제 데이터를 가져오는 후속 쿼리를 수행한다.

select * from my_table where id in (3,5,123,392,...)

두 쿼리 모두 매우 간단하게 실행할 수 있다. 데이터베이스에서 해야 하는 복잡한 작업은 없다. 반환할 데이터를 선택하는 데 필요한 비즈니스 로직이 애플리케이션 계층에서 실행되지만 데이터베이스에서 애플리케이션으로 전송해야 하는 부가적인 데이터는 극히 미미하다. 별도의 필터링 쿼리와 데이터 추출 쿼리로 쿼리를 분할함으로써 요청을 리팩토링해서 복잡하고 리소스 소비량이 큰 비즈니스 로직을 데이터베이스가 아닌 애플리케이션에서 실행했다.
 

반환되는 결과를 대상으로 하는 작업 피하기

비즈니스 로직을 데이터베이스에서 꺼내 애플리케이션 계층으로 옮기는 또 다른 쉬운 방법은 반환된 결과에 대한 계산을 데이터베이스에서 수행하지 말고 애플리케이션에서 수행하는 것이다. 즉, 다음과 같은 쿼리를 지양한다.

select POWER(SQRT(field1)*SIN(field2),5) from my_table where ...

대신 다음과 같이 한다.

select field1,field2 from my_table where ...

그런 다음 반환된 결과로 애플리케이션에서 POWER(SQRT(field1)*SIN(field2),5) 등의 작업을 수행한다. 결과적으로, 계산을 수행하는 데 필요한 모든 컴퓨팅이 희소한 데이터베이스 리소스가 아닌 풍부한 애플리케이션 리소스를 활용하게 된다.
 

조인을 애플리케이션 계층으로 옮기기

복잡한 조인은 데이터베이스 리소스가 필요한 또 다른 영역이다. 데이터베이스에서 데이터를 조인하지 말고, 조인 로직을 최대한 애플리케이션 계층으로 옮긴다. 이렇게 코드를 리팩토링하면 확장성을 늘리면서 데이터베이스에 대한 부하를 대폭 줄일 수 있다.
 

고리 끊기

물론 항상 이런 방식으로 쿼리를 리팩토링할 수 있는 것은 아니다. 데이터베이스 자체 내에서 복잡한 쿼리를 수행해야 할 때도 있다. 그러나 복잡한 쿼리를 할 수 있는 최대한 제거하면 빈약한 데이터베이스 리소스에 대한 의존을 줄이고 풍족한 애플리케이션 수준 리소스에 대한 의존을 늘릴 수 있다.

정리하면, 다음부터는 여러 조인과 다양한 필터링 로직을 사용하는 크고 길고 복잡한 쿼리를 보며 자랑스럽게 생각하지 말자. 복잡한 쿼리를 더 간단한 쿼리, 필요하다면 여러 개의 쿼리와 애플리케이션 계층에서 실행되는 비즈니스 로직으로 대체하는 방법을 고민하자. 이렇게 하고 나면 애플리케이션이 확장됨에 따라 개선된 유연함의 가치를 체감하게 될 것이다. editor@itworld.co.kr


X