달리는 자동차의 타이어를 교체하기 : Stored Procedure 기반 데이터 접근 방식에서 ORM 기반으로 전환 (1)

나는 IT가 주된 핵심이 아닌 고전적인 서비스 기업에서 웹 개발자로 근무하고 있다. 이 회사는 다수의 서비스를 운영하고 있으나, 대부분은 과거에 구축된 레거시 아키텍처를 기반으로 현재까지 유지보수되고 있다. 나는 이런 환경에서 레거시 시스템을 모던 아키텍처로 전환하는 과정을 직접 겪어보았기에, 그 경험을 기록하고 나누고자 이 글을 작성하게 되었다.

특히 기존에 Stored Procedure(이하 SP) 기반으로 동작하던 시스템을 ORM 기반으로 전환하는 과정에서 겪은 어려움과 해결 방법 그리고 그 전환이 가져다 준 이점등을 집중적으로 다룰 예정이다.  이 글은 그 여정에서 얻은 경험과 인사이트를 공유함으로써 비슷한 고민을 하는 사람들에게 도움을 주는 것을 목표로 한다.

• 운영중인 시스템에서 Stored Procedure 기반을 ORM 기반으로 바꾸는 것은 결코 쉬운 일이 아니다.

최근 들어 개발자로 입문하는 세대라면 SP를 사용한 개발 방식을 접해보지 못했을 수 있다. (나도 마찬가지였다.) 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/1529724