1. SQL활용 - Procedure(프로시저)

Procedure(프로시저)는 DB에서 일련의 작업을 처리하기 위해 작성되는 절차를 RDBMS(관계형 데이터베이스)에 저장한 것을 의미합니다.

이런 저런 이유가 있지만 제가 알아본 가장 큰 이유는 DB와 WAS(Web Application Server)간의 데이터 이동량이 많을 경우 WAS의 부담을 줄이기 위해 DB에서 모든 로직을 처리하고 웹의 구동 효율성을 올리기 위해서라고 보입니다.

• 하나의 요청으로 여러 SQL문을 한번에 실행 가능
• 네트워크 소요 시간을 줄여 성능개선 가능
• 다른 어플리케이션과 공유 가능
• 기능 변경 편리

이상의 장점이 존재하지만 개인적으로 현업에서 기존의 프로시저를 기반으로 유지보수를 진행하게 되면 해당 프로시저를 파악하는데 시간이 오래 걸리는 것 같습니다.
(커뮤니티에서 찾아보니 단순한 겉멋이라고 치부해버리는 분들도 존재할 만큼 WAS의 성능개선이 지속되는 현재 굳이 사용할 필요성이 있는지에 대한 의문이 있습니다.)

• 낮은 처리 성능
• 디버깅의 어려움
• 구문의 복잡성 등으로 인한 유지보수의 어려움

이상의 3가지를 프로시저의 큰 단점으로 뽑는것 같습니다. 낮은 처리 성능은 프로그래밍 언어의 개선 및 하드웨어의 발전으로 결국 SQL을 통한 연산처리보다 프로그래밍 언어를 통한 처리가 훨씬 빠르다는 점입니다.

또한 저도 직접 겪은 바입니다만 프로시저를 분석하고 유지보수하는 것이 장점으로 꼽히기도 하지만 저에게는 단점으로 더 다가온 부분이 있습니다. 해당 결과물이 반환되어 저장되는 변수 를 찾아내기가 난해했거든요. 특히 해당 프로시저가 개발 된지 오래된 경우일 수록 더욱 그러한 부분이 단점으로 다가오는것 같습니다.

물론 프로시저가 가지는 장점도 존재하기 때문에 위에서 기술한 것처럼 단순한 겉멋으로 치부하기에는 어려운 점이 존재한다고 생각합니다.

하지만 이직이 잦은 개발업계의 특성상 누군가 설계한 프로시저는 해당 DB의 구조를 파악하고 다시 프로시저를 파악해야 한다는 업무가 이중으로 발생한다고 개인적으로 생각합니다.

특히 10년 넘은 회사에서 해당 프로시저가 다른 업무와 마찬가지로 원활하게 인수인계 될 수 있을지까지 생각한다면 저는 프로시저를 통한 개발을 선택하지 않을 것 같습니다.
(물론 초보 개발자인 저의 개인적인 입장이기 때문에 다른 의견도 겸허히 수용할 수 있도록 하겠습니다.)