SQL 프로시저, 함수는 어떤때 쓰세요?

이유는 간단합니다. "비즈니스 로직은 DB에 있으면 안된다" 저는 이 말을 처음 들었을 때가 2004년이었고, 실제로는 그 이전부터 있어온 이야기입니다. 그런데 여러 개발 프레임워크가 발전해 오면서 이 주장은 계속 힘을 얻어 왔죠. 그리고 지금은 대다수가 당연한 것으로 받아 들입니다. 다시 스토어드 프로시저로 돌아오면, 스토어드 프로시저는 다양한 Query문을 하나의 로직으로 캡슐화합니다. 여기서 사람들은, DB에 비즈니스 로직이 있으면 안되는데 스토어드 프로시저를 쓰면 이 원칙이 깨진다고 생각하는 겁니다. (개인적으로는 동의하지 않는 주장입니다.) 그래서 오래된 회사이거나 새로운 프레임워크로의 전환이 늦은 조직이 아니라면, 대부분 스토어드 프로시저나 함수는 RDB를 관리하거나 일부 배치 작업을 처리하는 제한적 용도로만 사용합니다. 또는 아예 사용하지 않는 경우도 많습니다. 하지만 예외도 있습니다. 첫 째로, MS SQL Server를 사용하는 환경입니다. MS는 오래전부터 스토어드 프로시저 사용을 권장해 왔고 최적화가 잘되어 있습니다. 공부에 필요한 스토어드 프로시저 교재도 내용이 충실하고 다양하죠. 예전에는 주로 온라인 게임에 많이 사용되었습니다. 둘 째로, 현업에서 스토어드 프로시저를 프레임워크 수준으로 잘 사용하는 조직입니다. 이 경우는 백엔드 서버가 RDB의 테이블 에 직접 액세스하는 것이 아니라, 프로시저를 추상화 레이어로 사용하게 됩니다. 이렇게 하면 백엔드 서버와 RDB의 결합도 (Coupling)가 극단적으로 낮아집니다. 그 결과로 백엔드 코드에 영향을 주지 않고 RDB를 자체적으로 리팩토링하고 별도로 배포할 수 있어서 변경에 유연한 서비스를 만들 수 있습니다. 지금 자바와 스프링을 공부하고 계신다면 아마 스토어드 프로시저를 접할 기회는 없을 것으로 생각합니다. 다만 RDB를 설계하고 SQL로 무엇을 할 수 있는지는 깊이 있게 공부해야 한다고 생각합니다. JPA도 결국은 SQL을 대신 만들어 주는 것이라.. 결국 시니어로 가는 과정에서 RDB에 대한 깊이 있는 지식은 필수적이기 때문입니다.