섹션12) 데이터베이스 로직의 함정과 현대적 대안

지난 시간에 우리는 데이터베이스 내부에 프로그램을 저장하는 저장 프로시저, 함수, 트리거의 개념과 장점에 대해 배웠다. 네트워크 트래픽을 줄이고, 로직을 데이터베이스로 다 중앙화하며, 보안을 강화할 수 있다는 점에서 이 기능들은 매우 강력하고 매력적으로 보인다. 

 

그렇다면, 왜 현대의 많은 개발 프로젝트, 특히 웹 기반의 애플리케이션 개발에서는 이 기능들의 사용을 기피하거나 최소화하는 경향이 있을까? 이번 시간에는 그 현실적인 이유와, 그렇다면 현대 개발에서는 어떤 대안을 사용하는지에 대해 알아보겠다. 이것은 기술의 '좋고 나쁨'의 문제가 아니라, 시대의 흐름과 소프트웨어 아키텍처의 패러다음 변화에 대한 이야기다. 

왜 지금은 잘 사용하지 않는가?

편리해 보이는 이 기능들이 실무에서 외면 받는 이유는 크게 세 가지다.

1. 유지보수의 어려움(어디에 로직이 있지?)

데이터 베이스에 비즈니스 로직이 들어가기 시작하면, 전체 시스템의 로직이 애플리케이션 코드와 데이터베이스 양쪽에 흩어지게 된다.

• 혼란의 시작: 비즈니스 규칙을 변경해야 할 때, 개발자는 혼란에 빠진다. "이 로직, 자바 코드에 있나? 아니면 데이터베이스 프로시저에 있나?" 로직을 추적하고 이해하는 데 드는 시간이 두 배가 되고, 수정 포인트를 잘못 찾아 버그를 만들 확률도 높아진다. 최악의 경우는 프로시저에도 있고 애플리케이션 코드에도 있어서 두 군데 다 실해되죠 회원이 주문 한번했는데 두 개 들어가고 그죠 별의별 문제들이 생길 수 있습니다. 
• 버전 관리의 어려움 

2. 성능 및 확장성 문제(누가 일을 해야 할까?)

과거에는 애플리케이션 서버보다 데이터베이스 서버가 월등히 성능이 좋은 '가장 비싼 컴퓨터'였다. 따라서 DB 서버에 일을 몰아주는 것이 합리적이었다. 하지만 지금은 상황이 완전히 바뀌었다. 

• 데이터베이스의 병목 현상
• 확장성의 차이: CUP 4개인 컴퓨터에서 CPU 20개인 컴퓨터로 바꾼다 이런 수직적 확장은 되게 비용이 훨씬 많이 들고  어렵습니다. 상대적으로 그리고 또 계속 좋은 컴퓨터로 바꿀 수 만은 없겠죠 그래서 한계가 있습니다. (샤딩이란? 데이터베이스를 수평으로 늘릴수 있게 어떤 키를 잡아서 하는 기술인데 그걸 쓰는 순간 데이터베이스 관리 난이도가 급증합니다) 

 

따라서 현대 아키텍처의 기본 원칙은, 값싸고 쉽게 확장할 수 있는(서버를 늘리면 되는거에요) 애플리케이션 서버가 비즈니스 로직 처리를 담당하고, 비싸고 확장하기 어려운 데이터베이스는 데이터 저장 및 관리에만 집중하도록 역할을 명확히 분리하는 것이다. 물론 데이터 조회도 인덱스 잘 조회하고 정말 고유의 데이터 베이스 기능에 집중하도록 역할을 명확하게 분리하는게 현대 개발 아키텍처의 대원칙으로 보시면 될 것 같아요 

3. 특정 데이터베이스에 대한 종속성(한 번 종속되면 빠져나올 수 없다)

저장 프로시저, 함수, 트리거는 표준 SQL이 없다고 보시면 되요 이거는 DB마다 다 달라요 

만약 Oracle의 PL/SQL로 수백 개의 복잡한 프로시저를 작성했는데, 몇 년 뒤 비용 문제로 My SQL이나 다른 오픈소스 데이터베이스로 이전하기로 결정했다면 어떻게 될까? 기존에 작성했던 모든 데이터베이스 로직을 새로운 데이터베이스의 문법에 맞춰 전부 새로 작성해야 한다. 이것은 엄청난 시간과 비용을 유발하며, 사실상 데이터베이스 이전을 불가능하게 만드는 '기술적 부채'이자 '벤더 종속(Vendor Lock-in)' (Lock, 이제 자물쇠로 잠궈서 넌 이제 우리 기술을 써야하니까 다른 데는 못가 라고 하는거죠) 의 덫이 된다.

현대의 대안: 명확한 역할 분리

그렇다며 현대적인 애플리케이션 개발의 대안은 무엇인가? 바로, 앞서 이야기한 명확한 역할 분리다.

• 애플리케이션 계층: (요새 네트워크 빠르기 때문에 웬만큼은 뭐 왔다 갔다 그렇게 느려지지 않거든요)
• 데이터베이스 계층: (복잡한 비즈니스 로직 이런거는 데이터베이스에 넣지말고 애플리케이션으로 가져와야 합니다.)

이러한 접근 방식은 시스템을 더 유연하고, 확장 가능하며, 유지 보수하기 쉽게 만든다  

최종 정리

물론 저장 프로시저와 같은 기능이 완전히 쓸모없다는 뜻은 아니다. 데어 웨어하우징(DW)(여러군데에 있는 데이터베이스에 데이터 를 어떤 되게 큰 데이터베이스에 모아서 데이터를 조회용으로 만든 그런 데이터베이스) 이러한 환경에서 대용량 데이터를 배치 처리하거나, DBA가 특정 관리 작업을 자동화하는 등 여전히 유용하게 스이는 특정 영역이 존재한다.(DB안에서 가급적이면 처리하길 원하신다 DBA는) 

하지만 이 강의를 듣는 대부분의 여러분이 접하게 될 웹/앱 서비스 개발 환경에서는, 비즈니스 로직을 데이터베이스에 넣는 것은 매우 신중해야 한다는 점을 기억하자 

실무에서 옛날에 레거시 프로젝트할때는 저장 프로시저, 함수, 트리거를 많이 사용했어요 현대에는 잘 안써요 지금은 물론 진짜 가끔 쓸때가 있죠 DB같은 경우에는 필터링하고 그룹핑 하고 정렬하고 인덱스 잘 타고 해서 최소한으로 데이터를 줄여서 조회하고 이런것 까지는 DB에서 하고 어떤 로직이 있거나 이런것들은 웬만한 것은 다 애플리케이션에서 합니다 요즘에는 거의 DB에서 백엔드 개발자가 이런걸 만들리는 거의 없었어요 회사에서 DBA분들이랑 작업하면 DBA분들은 자동화하거나 하기위해서 본인들이 나름의 어떤 프로시저를 만들거나 왜냐면 그분들은 자바 파이썬 같은걸 코딩하고 이것보다는 그냥 DB에서 SQL로 뭔갈하고 프로시저를 쓰는게 편하니까 필요하면 트리거도 쓰고 하셨는데 백엔드 개발자들은 이런 일을 거의 안하고 다 애플리케이션 계층에서 다했고 DBA분들이 본인들의 필요에 의해서 이런것들을 안에서 넣어서 처리하고 요런것들은 좀 있었어요 

그래서 현대적인 개발에서는 비즈니스 로직은 애플리케이션, 데이터를 잘 조회하고 처리하는 것은 데이터베이스, 요렇게 명확하게 잘 분리해서 사용하시는게 어떤 확장성이나 나중에 유지보수하기에 훨씬 좋으실 거에요