피드로 돌아가기
Dev.toBackend
원문 읽기
Interface 기반 Store Seam 설계를 통한 스토리지 마이그레이션 비용 최소화
Build the Seam on Day One, the Second Driver on Day Ninety
AI 요약
Context
고볼륨 Telemetry 데이터 처리 플랫폼 구축 시 초기 단계에서 최적의 Storage 엔진(Columnar/Time-series)을 확정하기 어려운 제약 존재. RDB 기반의 빠른 초기 배포가 필요하나, 도메인 로직에 특정 DB 의존성이 전파될 경우 향후 마이그레이션 시 수백 개의 Call site를 수정해야 하는 기술 부채 발생 위험이 큼.
Technical Solution
- Store Seam 패턴 도입을 통해 Storage 인터페이스(Contract)와 실제 구현체(Driver)를 엄격히 분리한 구조 설계
- Eloquent 기반의 Boring Driver를 우선 구현하여 초기 개발 속도를 확보하고 비즈니스 로직은 오직 Interface에만 의존하도록 제한
- Service Provider의 bind() 설정을 통해 런타임에 구현체를 주입함으로써 코드 수정 없이 Storage 엔진을 교체 가능한 유연성 확보
- Internal ID(정수형)와 Public UUID를 이원화하여 조인 성능 최적화와 보안 노출 방지를 동시에 달성
- Versioned Additive Envelope 전략을 적용하여 스키마 변경 시 하위 호환성을 보장하고 클라이언트 강제 업데이트 없는 점진적 확장 구현
- Empty Map의 JSON 직렬화 방식을 객체({})로 강제하여 언어 간 스키마 검증 오류를 방지하는 일관성 유지
실천 포인트
- 신규 플랫폼 설계 시 '최적의 DB' 선택보다 '교체 가능한 인터페이스' 정의를 우선순위에 둘 것 - YAGNI 원칙을 맹신하여 인터페이스를 생략하기보다, 단 하나의 파일 추가로 미래의 리팩토링 비용을 보험 처리할 것 - API 응답 및 저장소 경계에서는 Internal ID를 숨기고 UUID를 사용하여 데이터 노출을 최소화할 것 - 데이터 스키마 진화 시 삭제/수정 대신 '추가 전용(Additive-only)' 정책을 적용하고 버전 필드를 통해 라우팅할 것