SQL 중심적인 개발의 문제점

애플리케이션을 개발할 때는 보통 객체지향 언어로 개발한다. 그런데 데이터베이스 세계는 보통 대부분 관계형 DB를 이용한다. 왜 굳이 애플리케이션은 객체 지향, 데이터는 관계형 DB라 이야기를 했나면, 지금 우리가 사는 시대는 우리가 만든 객체, Object를 관계형 DB에 보관하고 관리하는 시대이다.

그런데 이 객체를 관계형 DB에 보관하려 하다보면 쿼리를 엄청나게 작성해야 한다. 이게 바로 SQL 중심적인 개발의 문제점이다.

일단 무한 반복되고 지루하다. 우리는 기본적으로 CRUD라고 하는 데이터 등록, 수정 삭제 작업이 기본적으로 필요한데, 그러면 Insert, Update, Select, Delete 같은 쿼리를 객체 하나를 DB에 보관하고 꺼내고 변경, 삭제하려면 계속 쿼리를 작성해야 하게 된다. 그래서 Java 객체를 SQL 로 바꾸고, SQL 을 Java 객체로 바꾸고 이러한 과정들을 계속 무한 반복해야 한다.

예시를 하나 보도록 하자.

스크린샷 2025-03-20 오전 11.35.39.png

우리가 회원이 있다 가정하면 회원이라는 클래스를 만든다. 그리고 필드들을 정의한다. 그러면 이것들을 데이터베이스에 저장하려면 어떻게 해야할까? 결국 insert into 멤버, select, update 하는 SQL 을 결국 리포지토리나 DAO 에서 다 작성해야 한다.

스크린샷 2025-03-20 오전 11.35.28.png

또 하나의 문제는 다음과 같다. 개발을 거의 다 해가는데 기획자가 갑자기 연락처를 추가해달라 요구한다 가정해보자. Insert, Update, Query 에 전부 연락처 필드를 다 넣어야 한다. 그러다 실수로 연락처 필드를 안넣는 등의 일이 일어나는 일들이 다반사 생길 수 있다.

→ 결국 객체 필드를 하나 추가하게 되면 Query 문을 다 고쳐야 된다. 즉, SQL 에 의존적이 개발을 피하기 어렵다. 어쨌든 우리는 결국 관계형 데이터베이스를 쓰고 관계형 데이터베이스랑 통신하려면 SQL을 사용해야 하기에 SQL 에 의존적이게 된다.

패러다임의 불일치

그러면서 또 나오게 되는게 패러다임의 불일치가 있다. 우리가 생각해보면 뭔가 객체와 관계형 데이터베이스의 테이블이라는 건 비슷한 것 같지만 굉장히 다르다.

이 차이에 대해 알아보자.

스크린샷 2025-03-20 오전 11.40.26.png

객체 지향 프로그래밍이라는 것은 추상화, 캡슐화, 정보은닉, 상속, 다형성 등 시스템의 복잡성을 제어할 수 있는 다양한 장치들을 제공한다. 그래서 우리가 처음부터 다시 고민을 해보면, 객체는 RDB, NoSQL, 파일 등 객체를 영구 보관하는 다양한 보관소들이 있다. 그 중 선택을 해야 한다면 현실적인 대안은 관계형 데이터베이스이다. (8-90% 에 NoSQL 은 보조적 수단)

스크린샷 2025-03-20 오전 11.42.03.png

그렇다면 이 과정이 지루하다. 지금의 과정을 도식화해보면, 회원을 저장해야 한다면 회원 객체를 DB에 저장하려면 Insert 문을 다 만들어야 하고, SQL 로 다 변환해야 한다. 조회할 때도 SQL 의 select 문을 다 조회한 다음, 그걸 객체로 바꿔야 한다.

그래서 이 그림을 잘 보면 객체를 어쨌든 객체에 대한 데이터를 SQL로 변환해 RDB에 SQL 로 전달해야한다. 그런데 이걸 개발자인 우리가 해야한다.

이렇게 되면 개발자는 거의 SQL 매퍼의 일을 하게 된다.