들어가며
이전 글에서 이어집니다.
이전 글에서는 stored procedure 장점에 대해 살펴보았습니다.
이번 글에서는 stored procedure 단점에 대해 살펴보겠습니다.
stored procedure 단점 & 실무에서 쓰기 조심스러운 이유
stored procedure를 사용하면, 유지 관리 보수 비용이 커진다.
stored procedure를 도입할 경우, 비즈니스 로직이 일부는 소스 코드로 관리되고 일부는 프로시저로 관리되기 때문에 개발자들은 소스 코드를 확인하고 나서 다시 프로시저를 확인하며 작업을 진행해야 합니다. 이로 인해 로직 파악 및 이해에 더 많은 시간과 노력이 필요할 수 있습니다. 또한 소스 코드와 프로시저 모두를 버전 관리해야 하므로 작업의 복잡성이 증가합니다.
또한, 프로시저 작성에 필요한 문법과 규칙을 숙지해야 합니다. 데이터베이스 시스템마다 프로시저 작성 방식이 다를 수 있으며, 이를 모두 익히는 것은 번거로울 수 있습니다.
마지막으로, 프로시저와 관련된 변경사항을 추적하고 관리하는 작업은 복잡할 수 있습니다. 소스 코드와 프로시저 간의 일관성을 유지하고 버전 관리를 원활하게 처리하는 것은 팀 전체의 협업을 더 어렵게 만들 수 있습니다.
DB 서버를 추가하는 것은 간단한 작업이 아니다
stored procedure를 사용하여 비즈니스 로직을 구현한 경우, traffic이 프레젠테이션 티어를 통과하여 로직 티어로 이동하면 대부분의 트래픽이 DB 서버까지 전달될 것입니다.
이로 인해 웹 애플리케이션 서버의 CPU 사용량보다 DB 서버의 CPU 사용량이 증가할 가능성이 있습니다. 만약 트래픽이 갑자기 몰리는 상황이 발생한다면, DB 서버의 CPU 사용량이 급격하게 상승하여 요청 처리량이 줄어들 수 있습니다. 특히 RDBMS의 CPU 사용량이 90% 이상으로 증가하는 상황이라면 서비스에 치명적인 위험을 초래할 수 있습니다.
이런 상황에서 개발팀은 문제를 해결하기 위해 RDBMS 서버의 확장을 고려할 수 있습니다. 그러나 서버를 증설한다고 해서 문제가 즉시 해결되지는 않습니다. 새로운 서버는 초기에 데이터가 없기 때문에 트래픽을 적절히 분산 처리할 수 없습니다. 즉, 기존 RDBMS의 데이터를 새로운 서버로 복제해야 합니다.
따라서 유사 시 긴급하게 대응하는 것이 어려울 수 있습니다.
하지만 비즈니스 로직을 로직 티어에서 소스 코드를 통해 관리한다면, 서버를 늘리는 것이 비교적 간단해집니다. 로직 티어는 데이터를 들고 있지 않기 때문에 애플리케이션 서버를 추가하는 것이 비교적 용이합니다.
stored procedure를 사용한 경우와 비교하여, 로직 티어에서 비즈니스 로직을 관리하는 방식은 긴급한 상황에서도 빠르게 대응할 수 있는 장점을 가지고 있습니다.
stored procedure가 언제나 transparent인 것은 아니다
stored procedure를 사용하여 비즈니스 로직을 구현한 경우, 항상 transparent인 동작하는 것은 아닙니다. 예를 들어, stored procedure의 이름이 변경되는 상황을 생각해보겠습니다. 기존의 프로시저 이름을 "A"로 설정했다고 가정합니다.
그런데 시간이 지난 후, 어떤 이유로 인해 해당 프로시저의 이름을 "B"로 변경해야 하는 상황이 발생할 수 있습니다. 이 때, 프로시저의 이름을 바꾼다면 로직 티어에 있는 소스 코드에서는 여전히 기존의 "A"를 호출하고 있을 것입니다. 따라서 로직 티어의 소스 코드를 수정하여 "B"를 호출하도록 변경해야 합니다. 또한 로직 티어의 웹 애플리케이션 서버를 재시작해야만 변경된 프로시저가 적용될 수 있습니다.
이런 변경 과정은 번거롭고 이로 인해 불필요한 작업과 중단이 발생할 수 있습니다.
따라서 소스 코드에 로직이 있는 경우보다 오히려 손이 더 많이 가는 상황이 발생할 수 있습니다.
