데이터 독립성으로 스키마와 저장 구조의 변화를 분리하는 법

변경이 애플리케이션까지 번지지 않게 하는 원칙

데이터베이스의 저장 방식이나 데이터 구조는 운영 중 계속 바뀐다. 이때 하위 계층의 변경이 상위 계층으로 전파되지 않도록 만드는 특성이 데이터 독립성이다. 저장 구조와 접근 방식의 변경을 사용자 관점에서 투명하게 처리함으로써, 유지보수와 확장 시의 영향 범위를 줄인다.

데이터 독립성은 변경 대상에 따라 논리적 데이터 독립성과 물리적 데이터 독립성으로 나뉜다.

논리 구조의 변화와 외부 스키마

논리적 데이터 독립성은 개념 스키마가 바뀌어도 외부 스키마가 영향을 받지 않는 특성이다. 전체 데이터베이스의 논리 구조를 변경하더라도 애플리케이션 프로그램이 이를 직접 떠안지 않도록 하는 데 목적이 있다.

외부 스키마와 개념 스키마 사이의 매핑으로 이를 구현한다. 예를 들어 테이블에 컬럼을 추가하거나, 테이블을 분할·통합하더라도 기존 애플리케이션은 수정 없이 동작할 수 있다.

저장 방식의 변화와 개념 스키마

물리적 데이터 독립성은 내부 스키마를 변경해도 개념 스키마를 유지하는 특성이다. 저장 장치, 파일 구조, 인덱싱 방식처럼 물리 계층에서 일어난 변화가 논리적 데이터 구조를 바꾸지 않아야 한다.

개념 스키마와 내부 스키마의 매핑이 이 경계를 맡는다. 저장 장치 교체, 인덱스 추가·삭제, 클러스터링 변경이 발생해도 데이터베이스의 논리 구조는 유지할 수 있다.

ANSI/SPARC 계층에서 보는 매핑의 역할

ANSI/SPARC 아키텍처는 데이터베이스를 외부·개념·내부 스키마로 구분한다. 계층을 나누는 것만으로 독립성이 생기는 것은 아니다. 각 계층을 연결하는 매핑이 변경을 흡수해야 한다.

⤢✕

외부 스키마는 사용자나 응용 프로그램이 바라보는 논리적 구조다. 사용자별로 다른 뷰를 제공할 수 있으며, 실제 데이터베이스의 일부만 보이도록 제한할 수도 있다.

개념 스키마는 데이터베이스 전체의 논리적 구조를 다룬다. 개체, 속성, 관계, 제약조건을 포함하며 데이터베이스 설계자가 정의한다. 내부 스키마는 저장 방식, 인덱싱, 접근 경로처럼 물리적 저장 구조와 성능 최적화 요소를 정의한다.

외부/개념 매핑은 개념 스키마 변경이 외부 스키마에 미치는 영향을 최소화하고, 매핑 정보의 수정으로 변경 사항을 반영한다. 개념/내부 매핑은 내부 스키마 변경이 개념 스키마까지 이어지지 않도록 하며, 저장 구조 최적화가 논리적 모델을 훼손하지 않게 한다.

복잡한 시스템에서 독립성이 필요한 이유

독립성이 없으면 작은 데이터 변경도 연결된 애플리케이션 전체의 수정으로 이어질 수 있다. 그에 따라 변경 비용은 기하급수적으로 증가한다. 한 기업이 데이터베이스 저장 엔진을 바꾼 사례에서는, 데이터 독립성이 확보된 시스템이 애플리케이션 코드 변경 없이 마이그레이션할 수 있었다.

시스템 규모가 커질수록 데이터 구조의 복잡도도 커진다. 계층별로 복잡도를 분리하면 각 계층은 자신의 책임 영역에 집중할 수 있다. 같은 데이터를 여러 형태로 중복 저장하는 상황도 통제할 수 있다. 논리적 구조를 유지한 채 물리적 저장을 최적화하면, 중복에 따른 데이터 불일치와 저장 공간 낭비를 줄일 수 있다.

비즈니스 요구사항은 계속 변한다. 독립성이 보장된 구조에서는 필요한 계층만 수정해 요구사항을 반영하고, 전체 시스템 재구축 대신 점진적인 개선을 선택할 수 있다.

운영자·설계자·개발자가 얻는 여지

DB 관리자는 스토리지 디바이스를 교체하거나 확장할 때 상위 계층을 바꾸지 않고 작업할 수 있다. 데이터 접근 패턴에 맞춰 물리 구조를 최적화하고, 시스템 간 데이터 이동에서도 논리 구조를 유지하기 쉬워진다. 클라우드 마이그레이션에서도 물리적 독립성이 있으면 애플리케이션 변경 없이 온프레미스에서 클라우드로 전환할 수 있다.

DB 설계자에게는 스키마 진화와 모듈화된 설계의 기반이 된다. 비즈니스 요구사항에 따라 스키마를 변경하고, 각 계층을 독립적으로 설계·최적화하며, 기존 구조에 영향을 덜 주면서 기능을 추가할 수 있다. 전자상거래 시스템에서 상품 정보에 지속가능성 지표 같은 새 속성을 넣을 때도 기존 애플리케이션 수정 없이 반영할 수 있다.

개발자와 사용자는 저장 구조나 접근 방식의 변화가 투명하게 처리되는 환경을 얻는다. 데이터베이스 구조가 달라져도 API를 바꾸지 않고 일관된 인터페이스를 유지할 수 있어, 데이터 접근 방식보다 비즈니스 로직에 집중할 수 있다. 페이스북과 같은 대규모 시스템에서도 내부 데이터 구조의 변경이 수백만 사용자의 경험에 영향을 주지 않도록 하는 방향과 맞닿아 있다.

추상화 계층과 뷰, API로 경계 만들기

애플리케이션과 DBMS 사이에 데이터 접근 계층을 두면 변경을 흡수할 위치가 생긴다.

⤢✕

DAO 패턴은 데이터 소스 접근을 추상화하고 캡슐화한다. 리포지토리 패턴은 도메인과 데이터 매핑 계층 사이에서 중간 계층으로 작동한다. ORM은 객체 모델과 관계형 데이터베이스 사이의 매핑을 자동화한다.

뷰도 외부 스키마를 구성하는 수단이 된다. 사용자에게 필요한 데이터만 제공하는 가상 테이블을 만들고, 기본 테이블 구조가 바뀌었을 때 뷰 정의를 수정해 애플리케이션 영향을 최소화할 수 있다. 복잡한 조인과 계산을 뷰에 캡슐화하면 애플리케이션도 단순해진다.

API 계층에서는 REST API나 GraphQL 같은 인터페이스로 데이터 접근을 표준화할 수 있다. 백엔드 데이터 구조가 바뀌더라도 API 계약까지 영향을 주지 않도록 설계하고, 버저닝으로 하위 호환성을 유지한다.

독립성이 모든 변경을 없애지는 않는다

추상화 계층에는 일정 수준의 성능 오버헤드가 따른다. 매핑 과정의 변환 작업은 지연 시간을 늘릴 수 있으므로, 캐싱과 인덱싱 전략으로 오버헤드를 줄여야 한다.

다중 계층 구조는 초기 설계도 복잡하게 만든다. 계층별 매핑 규칙을 정의하고 관리해야 하므로 명확한 아키텍처 문서화와 표준 패턴 적용이 필요하다.

또한 모든 변경을 한 계층에만 가둘 수는 없다. 핵심 비즈니스 엔티티의 근본적 구조가 바뀌는 경우에는 여러 계층이 불가피하게 영향을 받는다. 이때는 변경 영향도 분석 프로세스를 두고 점진적 마이그레이션 전략을 수립해야 한다.