3-1. 데이터베이스 중심 설계 vs 인터페이스 중심 설계

데이터베이스 중심 설계 vs 인터페이스 중심 설계: TDD와의 비교

프로그래머로서 우리는 시스템 설계를 다양한 방식으로 접근합니다. 이번 내용은 데이터베이스에서 시작하는 설계(Database-First Design)와 인터페이스에서 시작하는 설계(Interface-First Design)의 특징을 비교하고, TDD(Test-Driven Development)가 어떻게 인터페이스 중심을 강화하는지 설명합니다. 

TDD는 요구사항을 테스트로 구체화하며, 데이터베이스를 기능 구현 도구로 활용해 유연성을 강조합니다. 이를 통해 두 설계 방식의 차이를 이해하고, 실습에서 임의 테스트 데이터 생성 기법을 통해 TDD의 실용성을 살펴보겠습니다.

 

1. 데이터베이스에서 시작하는 설계 (Database-First Design)

￮ 이 접근은 요구사항을 데이터베이스 테이블 스키마에 먼저 투영하며, 시스템 설계를 데이터 중심으로 진행합니다. 데이터 무결성을 우선하지만, 유연성이 제한적입니다.

• 장점: 데이터베이스 제약으로 무결성·일관성 유지 쉬움. 데이터 중심으로 안정적.
• 단점: 변경 비용 큼(스키마 수정 시 전체 영향). 비즈니스 지식 표현력 낮음(동사 중심 요구사항을 명사 중심 스키마로 제한). 작업 부하 분산 어려움(CRUD 중심으로 기술 선택 제한). 애플리케이션 역할이 데이터 연결 수단으로 축소.
• 적합 상황: 기능·비기능 요구사항 난이도 낮고 변경 적을 때. 대표적으로 데이터베이스 중심 아키텍처.

￮ 과정:
(1) 요구사항 분석 후 테이블 스키마 설계(예: 관계, 제약 조건 정의).
(2) 스키마를 기반으로 인터페이스 입출력 설계(주로 CRUD 연산 중심).
(3) 구현 코드는 인터페이스를 데이터베이스에 위임(직접 매핑).

 

￮ 한계: 스키마가 기반이 되어 시스템 유연성 감소. 환경 변화(요구사항 수정)에 적응 어려움.

 

2. 인터페이스에서 시작하는 설계 (Interface-First Design)

이 접근은 요구사항을 인터페이스 설계에 먼저 반영하며, 클라이언트 가치 중심으로 진행합니다. 데이터베이스는 필요 시 도입되어 유연성이 높습니다.

• 과정:
  1. 요구사항 분석 후 인터페이스 설계(클라이언트 요구 중심).
  2. 인터페이스와 정책 기반 기능 구현.
  3. 구현 중 데이터 영속 필요 시 테이블 스키마 변경(필요 없을 시 생략).

 

• 특징:
  • 장점: 클라이언트 가치(비즈니스 지식)를 동사·명사로 풍부하게 표현. 인터페이스가 데이터베이스에 의존하지 않아 기술 선택 자유로움. 시스템 적응력 높음.
  • 단점: 초기 인터페이스 설계가 복잡할 수 있음.
  • 적합 상황: 요구사항 변경 잦고, 클라이언트 중심 설계 필요 시.

 

• 강점: 데이터베이스가 도구로 활용되어 변경 유연성 확보.

 

3. TDD 절차와 비교: 인터페이스 중심의 강화된 형태

TDD는 요구사항을 테스트 시나리오로 구체화하며, 인터페이스에서 시작하는 설계를 테스트 주도로 강화합니다. 데이터베이스는 기능 구현 도구로 필요할 때만 도입되어 데이터베이스 중심 설계의 한계를 보완합니다.

• TDD 과정:
  1. 요구사항 분석 후 필요한 인터페이스 설계.
  2. 테스트 시나리오 목록 작성.
  3. 하나의 시나리오를 테스트 코드로 변환.
  4. 테스트 통과 위한 기능 구현(데이터베이스 필요 시 스키마 변경).
  5. 목록 완료 확인, 반복.
• TDD 특징:
  • 인터페이스 중심: 요구사항을 클라이언트 가치로 우선, 데이터베이스 의존 최소.
  • 데이터베이스 역할: 상태 관리 도구로 필요 시 사용(테스트 시나리오 구현 과정에서 도입).
  • 비교 우위: 데이터베이스 중심(무결성 강하지만 유연성 낮음) vs TDD(가치 중심, 변화 적응 쉬움). TDD는 인터페이스 설계와 유사하지만, 테스트로 요구사항 누락 방지·확신 쌓음.
• 왜 데이터베이스 늦게 도입?: TDD는 요구사항 충족이 우선. 데이터베이스 필요 없을 시 고려 안 함. 불안 시 테스트 시나리오 검토로 보완.
• 장점: 시스템 상태(데이터베이스) 도입 시 자연스러움. 극단적 경우, 데이터베이스 불필요 시 생략 가능.

 

4. 실습: 임의 테스트 데이터 생성 (Random Test Data)

TDD에서 시스템 상태(데이터베이스) 도입 시, 테스트 독립성을 위해 임의 데이터를 생성합니다. 고정 데이터 사용 시 정책 위배(예: 중복 오류)나 거짓 양성 발생 방지.

• 목적: 각 테스트가 독립적·안정적으로 실행. 시스템 정책(예: 유일성) 준수.
• 과정:
  1. 생성기 작성: UUID 등으로 매번 다른 데이터(예: 이메일, 사용자 이름) 생성.
  2. 테스트 코드 교체: 고정 값 대신 생성기 사용(Arrange 단계에서 사전 조건 연출).
  3. 엔터티 수정: 제약 추가(예: 유일성), 예외 처리(예: 중복 시 400 Bad Request).
  4. 테스트 실행: 모든 테스트 통과 확인.
• 특징:
  • Arrange 단계 강화: 입력 데이터뿐만 아니라 시스템 사전 조건(예: 중복 상황) 준비.
  • 롤백 대체: 임의 데이터로 롤백 불필요, 테스트 성능·안정성 향상.
• 효과: 거짓 양성 해결, TDD 안정성 강화. 데이터베이스 도입 후에도 테스트 독립성 유지.