데이터 모델이 바뀌면, 서비스가 바뀐다

데이터 모델이 바뀌면, 서비스가 바뀐다

서비스를 설계할 때 우리는 종종 API나 기능 흐름부터 고민한다. 어떤 화면이 필요하고, 어떤 요청이 오가고, 어떤 로직이 실행되는지를 먼저 그려본다. 하지만 실제로 시간이 지나고 나면, 서비스의 형태를 가장 크게 좌우하는 것은 코드가 아니라 데이터 모델이라는 사실을 깨닫게 된다.

데이터 모델은 단순히 데이터를 저장하는 방식이 아니라, “무엇을 쉽게 할 수 있고 무엇을 어렵게 만드는지”를 결정한다. 어떤 관계를 명시적으로 표현할 것인지, 어떤 정보를 중복해서 가질 것인지, 어떤 조회 패턴을 기준으로 구조를 잡을 것인지에 따라 기능 구현의 난이도와 방향 자체가 달라진다.

예를 들어 관계형 모델에서는 데이터 간의 관계를 명확하게 정의하고, 정규화를 통해 중복을 최소화한다. 이 구조는 데이터의 일관성을 유지하는 데 강력하다. 여러 테이블을 조인해서 필요한 정보를 조합할 수 있고, 데이터 변경 시에도 하나의 소스만 수정하면 된다. 대신 복잡한 조회가 많아질수록 쿼리가 어려워지고, 성능 최적화가 중요한 과제가 된다.

반대로 비정형(NoSQL) 모델에서는 조회 패턴에 맞춰 데이터를 구성하는 경우가 많다. 필요한 데이터를 한 번에 가져올 수 있도록 구조를 설계하고, 일부 중복을 허용한다. 이 방식은 읽기 성능과 확장성에서 장점을 가지지만, 데이터 일관성을 유지하는 책임이 애플리케이션 레벨로 넘어오는 경우가 많다. 같은 정보를 여러 곳에서 관리하게 되기 때문에, 변경 시 동기화 문제를 신경 써야 한다.

이 선택은 단순한 저장 방식의 차이를 넘어, 서비스의 동작 방식 전체에 영향을 준다. 관계형 모델에서는 “데이터를 어떻게 조합할 것인가”가 중요한 문제가 되고, 비정형 모델에서는 “데이터를 어떻게 배치할 것인가”가 핵심이 된다. 같은 기능을 구현하더라도 접근 방식이 완전히 달라진다.

실무에서는 이 차이가 점점 더 크게 느껴진다. 처음에는 간단하게 시작했던 스키마가, 기능이 추가될수록 점점 부담이 되는 경우가 있다. 특정 데이터를 조회하기 위해 여러 테이블을 반복적으로 조인해야 하거나, 반대로 중복된 데이터를 여러 곳에서 동시에 수정해야 하는 상황이 발생한다. 이때부터는 코드 수정이 아니라 데이터 모델 자체를 다시 고민해야 하는 단계에 들어선다.

문제는 데이터 모델의 변경이 코드 수정보다 훨씬 큰 비용을 요구한다는 점이다. 이미 쌓여 있는 데이터를 마이그레이션해야 하고, 기존 로직과의 호환성도 고려해야 한다. 운영 중인 서비스라면 다운타임 없이 변경해야 하는 제약도 생긴다. 그래서 한 번 굳어진 데이터 구조는 쉽게 바꾸기 어렵다.

이 때문에 초기 설계에서 완벽한 모델을 만들려고 하는 시도도 자주 등장한다. 하지만 이 역시 쉽지 않다. 실제 사용 패턴은 시간이 지나면서 드러나기 때문에, 처음부터 모든 것을 예측하는 것은 거의 불가능하다. 결국 중요한 것은 “변경 가능한 구조”를 만드는 것이다.

예를 들어 특정 기능 단위로 데이터를 분리하거나, 점진적으로 스키마를 확장할 수 있는 여지를 남겨두는 방식이 도움이 된다. 또한 실제 사용 패턴을 관찰하면서, 자주 조회되는 데이터에 맞춰 구조를 조정해 나가는 접근이 현실적이다. 데이터 모델 역시 한 번에 완성되는 것이 아니라, 점진적으로 진화하는 대상이다.

결국 데이터 모델은 단순한 저장소 설계가 아니라, 서비스의 가능성과 한계를 정의하는 요소다. 어떤 선택을 하느냐에 따라 기능 개발의 속도, 성능, 유지보수 방식까지 모두 영향을 받는다.

그래서 한 번쯤은 이렇게 생각해볼 필요가 있다.
지금 이 구조는 단순히 데이터를 저장하기 위한 것인가, 아니면 앞으로의 기능을 제한하고 있는가.
그 질문에 답하는 순간, 데이터 모델을 바라보는 시선이 달라지기 시작한다.