레이어간 의존 관계 문제

아래 사진은 레이어드 아키텍처다

출처 : https://www.baeldung.com/cs/layered-architecture

 

의존하는 방향을 주목해보자. 항상 상위 레이어가 하위 레이어를 의존하는 형태를 가져간다.
근데 인프라 레이어의 코드가 도메인에도 있고 애플리케이션 레이어에도 존재한다면 어떻게 될까?

DB를 바꿔야 하는 상황에 닥쳤다고 생각해보자.
운영상 RDBMS에서 NoSQL로 바꿔야한다는 니즈가 생겨버렸다.

그럼 인프라의 변경으로 인해 도메인 레이어의 코드도 수정해야하고, 애플리케이션 레이어의 코드도 수정을 해야한다.
수정만이 문제가 아니다. 이전과 동일하게 동작하는지 테스트 코드도 수정해야하고 엄청나게 많은 리소스를 쏟아 부어야한다. 바꿀 수가 없을 정도의 리소스와 리스크를 안고 가야할 수도 있다.

그럼 누군가가 이렇게 말할 수도 있다.

"DB를 바꿔야 하는 건 소프트웨어 설계부터 잘못된거 아니야? 그 정도면 새로 만들어야지"

 

 

모든 서비스는 비즈니스로직이 중심이 되어야지, 비즈니스가 DB와 같은 다른 인프라에 의존해서는 안된다고 생각한다.

 

서비스를 운영하면서 인프라가 바뀔 가능성은 충분히 많다.
예시로 디스코드의 DB 변화를 들 수 있다. 디스코드의 DB 변천사는 링크를 참조해주길 바란다.

디스코드 처럼 유명한 회사를 생각할 것 없이 우리 회사도 아래와 같은 문제를 겪고 있다.

우리 서비스는 매일 몇 만개의 문서의 표절 여부를 판단하고, 각 문서의 모든 문장들과 표절 문장들에 대한 어디서 표절했는지의 정보를 저장한다.

대충 문서 1개의 100문장 정도 있다고 가정해보자.
그럼 매일 1만개의 문서 유입이 있다고 가정했을 때 아래와 같은 공식이 성립한다.
10000(문서) 100(문장) + 표절 문장의 수 표절 출처 문장의 수 = 하루 동안 insert되는 DB row의 수
대충잡아도 100만 ~ 150만의 row가 insert된다.

위 데이터들은 저장한 이후에 업데이트될 일이 전혀 없는 성격의 데이터들이다.
이런 데이터들을 저장하는데 있어서 RDBMS가 적절할까?를 고민했을 때
나는 NoSQL로 마이그레이션하는게 적절해보인다고 생각했다.

하지만 NoSQL로 변경했을 때 레이어간 의존성으로 인해 DB 접근 로직 뿐만 아니라
너무나도 많은 소스코드를 수정해야한다. 이런 코드의 양이 리스크나 리소스를 생각했을 때 도저히 감당 불가능한 수준이다.

비즈니스에 인프라의 의존없이 어떻게 개발할 수 있을지 고민해보자.