달리는 자동차의 타이어를 교체하기 : Stored Procedure 기반 데이터 접근 방식에서 ORM 기반으로 전환 (1)
저는 IT가 핵심 사업이 아닌 전통적인 서비스 기업에서 웹 개발자로 근무하고 있습니다. 당사는 여러 서비스를 운영하고 있지만, 대부분은 과거 구축된 레거시 아키텍처 기반으로 현재까지 유지보수되고 있습니다. 저는 이러한 환경에서 레거시 시스템을 현대적인 구조로 전환하는 과정을 직접 경험하였기에, 이 글을 통해 그 과정에서 얻은 경험과 인사이트를 공유하고자 합니다.
특히 기존에 Stored Procedure(이하 SP) 기반으로 운영되던 시스템을 ORM 기반으로 전환하는 과정에서 겪은 어려움과 해결 방법, 그리고 그 전환을 통해 얻은 이점 등을 중점적으로 다룰 것입니다. 이 글이 비슷한 고민을 하고 계신 분들에게 실질적인 도움이 되기를 바랍니다.
[운영 중인 시스템에서 Stored Procedure를 ORM으로 전환하는 일은 결코 쉽지 않습니다.]
최근에 개발자로 입문한 분들이라면 SP 기반 개발 방식을 접하지 않았을 가능성이 큽니다(저 역시 그러했습니다). SP는 데이터베이스 내부에 저장되어 직접 실행되는 코드 블록으로, 데이터 처리 로직이 데이터베이스에 깊이 내재된 구조입니다. 과거 SP는 성능과 보안 면에서 강력한 장점을 제공하였으나, 시간이 지나면서 다음과 같은 문제점이 드러났습니다.
첫째, 비즈니스 로직의 복잡성입니다. SP가 많아질수록 함수와 의존성이 복잡하게 얽혀 디버깅과 유지보수의 난이도가 급격히 증가합니다.
둘째, 버전 관리의 어려움입니다. 데이터베이스 내의 SP와 함수는 버전 관리가 어렵기 때문에 서로 다른 버전의 함수가 혼재하는 상황이 자주 발생하며, 이로 인해 장애 발생 시 원인 파악과 대응이 어렵습니다.
셋째, 데이터베이스 벤더 종속성입니다. SP는 특정 데이터베이스 벤더의 SQL 방언을 주로 사용하기 때문에 다른 데이터베이스로 이전할 경우 대부분의 로직을 다시 작성해야 하는 등 확장성과 이식성이 제한됩니다.
이러한 SP의 문제를 해결하기 위해 ORM을 도입하더라도, 실제 전환 과정은 단순하지 않습니다. 특히 대규모 트래픽 환경에서의 성능 문제, N+1과 같은 쿼리 최적화 이슈, 기존 시스템을 장기간 사용한 조직 내부의 저항 등 다양한 어려움이 존재합니다. "이미 정상적으로 운영되는 시스템을 왜 바꾸려는가?"라는 의문이 제기되는 것은 당연하며, 전환 과정에서 발생 가능한 다양한 리스크 또한 무시할 수 없습니다.
[그럼에도 불구하고 Stored Procedure에서 ORM으로 전환이 필요한 이유]
이러한 난관에도 불구하고 ORM으로의 전환은 단순한 기술 스택 변경 이상의 가치를 지닙니다. ORM은 데이터 접근 로직을 애플리케이션 계층에서 통합적으로 관리함으로써 유지보수성과 코드 가독성을 크게 개선하며, 팀 간 협업을 보다 용이하게 합니다. 또한 여러 데이터베이스를 지원하는 범용성을 통해 벤더 종속성을 극복하고, 시스템의 확장성과 이식성을 높이는 효과도 기대할 수 있습니다.
물론, ORM 도입 과정에서는 성능 최적화, N+1 문제 해결, 조직 내부의 변화 관리 등 새로운 도전 과제가 발생합니다. 그러나 사전 분석과 단계적인 전환 전략을 통해 이러한 문제들을 효과적으로 관리할 수 있으며, 장기적으로 유지보수성 향상과 개발 생산성 증대를 얻을 수 있습니다.
다음 편에서는 본격적인 전환 과정과 전략에 대해 더 자세히 다루겠습니다.
2편 보러가기: https://na2ru2.tistory.com/47, https://okky.kr/articles/1529836
