해결된 질문
작성
·
62
0
관계형 데이터베이스는 데이터가 들어간 이후 스키마를 변경하는 게 권장되지 않는다고 알고 있습니다. 그래서 최대한 스키마 설계 단계에서 제공해야 하는 서비스에 대한 명세를 최대한 자세히 작성해야 한다고 들었습니다.
그러면 비즈니스 요구사항이 추가됨에 따라 기존 테이블에 추가적인 정보가 필요하게 되면 어떻게 대처해야 하나요?
예를 들어 MVP로 서비스를 할 때는 user 테이블에 id(PK), password, name만 있었는데 서비스가 확장되며 age를 필수로 넣어야 하는 경우 어떻게 접근해야 하나요? 처음 설계 시 out of scope 기능을 자세하고 광범위하게 예측하여 모든 정보를 넣을 수 있도록 테이블을 만들어야 하나요?
감사합니다.
답변 2
1
좋은 질문입니다. 답변이 늦어졌네요. 요즘 빅테크 한 곳과 이직 인터뷰가 있기도 하고 이사도 하느라 늦어진 점 사과드립니다.
많은 분들이 관계형 DB는 스키마 변경이 어렵다고 알고 계시지만, 실제로 대형 서비스에서는 스키마 변경은 흔하고 자연스러운 과정입니다. 중요한 건 무작정 모든 필드를 처음부터 다 예측해서 설계하려고 하기보다, 변화에 유연하게 대응할 수 있는 구조와 프로세스를 갖추는 거예요.
서비스를 운영하다 보면 비즈니스 요구사항은 계속해서 변합니다. 유저 테이블에 age
가 새롭게 필요해졌다면, 그냥 다음처럼 추가하면 됩니다
ALTER TABLE user ADD COLUMN age INT;
요즘 대부분의 RDBMS 는 이런 단순한 컬럼 추가 작업은 논블로킹 non-blocking 으로 처리하기 때문에, 실시간 서비스 운영 중에도 문제없이 반영할 수 있습니다.
또한, MVP 단계에서 모든 필드를 예측해 넣으려다 보면, 과한 스키마 설계로 이어지고,
이는 오히려 서비스 속도와 유지보수성을 떨어뜨립니다.
그렇기 때문에 중요한 건 완벽한 예측이 아니라, 변화에 대응 가능한 유연한 설계를 하는 것 입니다.실무에서는 핵심 도메인에 집중해 작고 명확한 스키마로 출발하고, 변화에 따라 점진적으로 확장하는 것이 일반적이라고 할 수 있습니다.
0
안녕하세요, 인프런 AI 인턴입니다.
한재현님, 관계형 데이터베이스에서 비즈니스 요구사항이 추가됨에 따라 기존 테이블에 새로운 열을 추가하는 것은 일반적입니다. 비즈니스 요구사항은 시간에 따라 변화할 수 있기 때문에, 처음부터 모든 것을 예측하여 설계하는 것은 어렵고 비효율적일 수 있습니다. 아래는 이런 상황에 대처하는 방법입니다:
ALTER TABLE
문을 사용하여 user
테이블에 age
열을 추가할 수 있습니다.ALTER TABLE user ADD COLUMN age INT;
DDL을 통한 변경 자동화: Spring Boot와 같은 프레임워크를 사용할 경우, JPA의 DDL 생성 기능을 활용하여 애플리케이션 시작 시점에 스키마 변경을 자동으로 적용할 수 있습니다. 이를 위해 spring.jpa.hibernate.ddl-auto
설정을 사용하여 스키마 변경을 관리할 수 있습니다. (자세한 내용은 여기를 참고하세요)
기존 데이터의 마이그레이션: 새로운 열이 필수인 경우, 기존 레코드에 적절한 기본값을 설정하거나 별도의 마이그레이션 스크립트를 작성하여 데이터를 업데이트해야 할 수 있습니다.
단계적 접근: 처음 시스템 설계 시 모든 것을 포함하려는 시도보다는, 요구사항이 확정된 부분만을 대상으로 설계하고 필요에 따라 확장하는 방식이 더 현실적입니다.
지속적인 요구사항 변화에 대응할 수 있도록, 스키마 변경과 데이터 마이그레이션을 포함한 데이터베이스 변경 관리에 유연한 접근이 필요합니다.