[Sprint 성취도 평가] 데이터베이스 설계와 Spring JPA 이론평가
문제1. INNER JOIN과 LEFT OUTER JOIN의 차이점을 설명하고, 각각이 어떤 상황에서 유용하게 사용될 수 있는지 실무 사례를 들어 설명하세요.
[SB] [데이터베이스 설계와 Spring Data JPA]
문제1-1. 답변
INNER JOIN- 양쪽 테이블이 서로 매칭되는 행만 가져옴
- 예시 : 주문 조회
LEFT OUTER JOIN- 왼쪽 테이블의 모든 행 + 매칭되는 오른쪽 테이블의 null이 아닌 행을 가져옴
- 전체 직원 + 직책 정보를 가져오는데, 직책이 없는 직원이 존재할 때
문제 1-2. 정리
INNER JOIN은 두 테이블에서 조인 조건을 만족하는 데이터만 결합하는 방식입니다. 양쪽 테이블 모두에 매칭되는 데이터가 있는 경우에만 결과가 반환됩니다.
LEFT OUTER JOIN은 왼쪽 테이블의 모든 데이터를 포함하고, 오른쪽 테이블은 매칭되는 데이터가 있는 경우에만 결합합니다. 매칭되는 데이터가 없는 경우 오른쪽 테이블의 컬럼들은 NULL로 채워집니다.
INNER JOIN의 실무 활용 사례:
- 주문 테이블과 상품 테이블을 결합하여 실제 판매된 상품의 상세 정보 조회
- 회원 테이블과 등급 테이블을 결합하여 현재 활성 회원의 등급 정보 조회
LEFT OUTER JOIN의 실무 활용 사례:
- 모든 회원의 주문 현황을 파악할 때, 주문이 없는 회원도 포함하여 조회
- 전체 상품의 판매 현황을 분석할 때, 아직 판매되지 않은 상품도 포함하여 조회
문제 1-3. 채점 코멘트
| ✔️ INNER JOIN의 동작 방식 설명 | 3/3점 |
| ✔️ LEFT OUTER JOIN의 동작 방식 설명 | 3/3점 |
| ✔️ INNER JOIN의 실무 활용 사례 제시 | 1/2점 |
| ✔️ LEFT OUTER JOIN의 실무 활용 사례 제시 | 2/2점 |
✅ 잘한 부분
- INNER JOIN을 “양쪽 테이블이 매칭되는 행만 가져온다”라고 핵심을 정확히 짚은 점이 좋았았습니다.
- LEFT OUTER JOIN에서 “왼쪽 테이블 기준 + 매칭되지 않으면 NULL”이라는 특징을 잘 설명하고 있어요.
- 직책이 없는 직원까지 포함해야 하는 상황을 LEFT JOIN으로 설명한 부분이 아주 좋았어요.
❗ 아쉬운 부분
- INNER JOIN의 실무 사례가 “주문 조회”로만 짧게 언급되어 있어 구체적인 상황 설명까지 포함해서 답변할 수 있어야 합니다. 예를 들어 주문 + 상품 정보처럼 두 테이블 모두 반드시 존재해야 하는 이유까지 설명해야 합니다.
📚 더 공부하면 좋은 내용
- INNER JOIN과 LEFT JOIN을 동일한 테이블 구조에서 각각 실행했을 때 결과가 어떻게 달라지는지 직접 쿼리로 비교해보세요.
- LEFT JOIN 이후 NULL 데이터를 활용해서 “미등록 데이터 찾기” 같은 쿼리를 작성해보면 좋겠습니다.
- JPA에서 join fetch와 일반 join의 차이, 그리고 OneToMany 조인 시 데이터가 중복되는 문제도 함께 학습해보세요.
문제2. 데이터베이스 설계의 4단계(요구사항 분석, 개념적 모델링, 논리적 모델링, 물리적 모델링)에 대해 각 단계별 주요 산출물과 함께 설명해주세요.
[SB] [데이터베이스 설계와 Spring Data JPA]
문제 2-1. 답변
- 요구사항 분석 어떤 서비스를 만들 것이고, 어떤 기능이 필요한지 정의하는 단계 - 주요 산출물 : 요구사항 명세서
- 개념적 모델링 ERD로 정리하는 단계로, DBMS에 종속적이지 않음 - 주요 산출물 : ERD
- 논리적 모델링 table과 column, 제약 조건, 관계를 정의하는 단계 - 주요 산출물 : 관계가 포함된 ERD
- 물리적 모델링 사용할 DBMS에 적용하는 단계 - 주요 산출물 : DDL 스크립트
문제 2-2. 정리
데이터베이스 설계는 4단계로 진행됩니다:
요구사항 분석 단계에서는 비즈니스 요구사항을 수집하고 분석하여 요구사항 정의서와 데이터 사전을 작성합니다. 이는 후속 단계의 기초가 되어 전체 설계의 방향을 결정합니다.
개념적 모델링 단계에서는 엔티티를 도출하고 엔티티 간 관계를 정의하여 ERD를 작성합니다. 이는 비즈니스 관점의 데이터 구조를 표현하며, 이해관계자와의 의사소통 도구로 활용됩니다.
논리적 모델링 단계에서는 상세 속성을 정의하고 정규화를 수행하여 논리 데이터 모델을 산출합니다. 이 단계에서는 데이터의 중복을 제거하고 일관성을 확보하여 데이터 품질을 보장합니다.
물리적 모델링 단계에서는 DBMS 특성을 고려한 테이블 구조를 설계하고 DDL을 작성합니다. 이 단계의 산출물은 실제 데이터베이스 구현의 기초가 되며, 시스템의 성능과 안정성에 직접적인 영향을 미칩니다.
문제 2-3. 채점 코멘트
| ✔️ 각 단계의 목적과 핵심 활동 설명 | 3/3점 |
| ✔️ 각 단계별 주요 산출물 나열 및 설명 | 3/3점 |
| ✔️ 단계별 산출물 간의 연관성 설명 | 1/2점 |
| ✔️ 각 단계가 최종 데이터베이스 품질에 미치는 영향 설명 | 1/2점 |
✅ 잘한 부분
- 요구사항 분석, 개념적 모델링, 논리적 모델링, 물리적 모델링 각각의 단계 목적을 간결하게 정리한 점이 좋았습니다.
- 요구사항 명세서, ERD, 관계 정의, DDL 스크립트까지 단계별 산출물을 정확하게 나열한 점이 아주 좋았어요.
- 개념적 모델링이 DBMS에 종속되지 않는다는 특징을 짚어준 부분도 중요한 포인트를 잘 이해하고 있어요.
❗ 아쉬운 부분
- 단계별 산출물이 어떻게 이어지는지에 대한 흐름 설명이 부족합니다. 요구사항 명세서 → ERD → 논리 스키마 → DDL로 이어지는 과정까지 포함해서 답변할 수 있어야 합니다.
- 논리적 모델링의 산출물을 “관계가 포함된 ERD”로 표현한 부분은 아쉽습니다. 논리 스키마(테이블 구조, PK/FK, 제약조건)로 명확하게 구분해서 설명할 수 있어야 합니다.
- 각 단계가 데이터 품질에 어떤 영향을 주는지에 대한 설명이 빠진 점도 아쉽습니다. 정규화를 통한 일관성 확보, 물리적 설계에서의 성능 최적화 등을 포함해서 답변할 수 있어야 합니다.
📚 더 공부하면 좋은 내용
- 요구사항 정의서에서 ERD가 도출되고, ERD가 테이블 구조로 변환되는 전체 설계 흐름을 한 번 직접 그려보세요.
- 논리적 모델링 단계에서 정규화(1NF~3NF)를 적용하는 이유와 실제 분해 과정 예시를 학습해보세요.
- 물리적 모델링에서 인덱스, 데이터 타입, 파티셔닝이 성능에 어떤 영향을 주는지 실습을 통해 확인해보면 좋겠습니다.
문제3. 데이터베이스 정규화의 목적과 함께 제1정규형(1NF)부터 제3정규형(3NF)까지의 개념을 설명하고, 정규화와 성능의 관계에 대해 설명하세요.
[SB] [데이터베이스 설계와 Spring Data JPA]
문제 3-1. 답변
정규화의 목적
데이터 무결성을 높이고, 이상 방지하는 것
제1, 2, 3정규형
- 제1정규형(1NF)
- column이 Atomic해야 한다.
- 제2정규형(2NF)
- 제1정규형 만족 + 기본키의 일부에만 종속되는 속성 제거
- 제3정규형(3NF)
- 제1정규형, 제2정규형 만족 + 이행 함수 종속 제거
정규화와 성능
- 장점 : 정규화를 더 진행할 수록 데이터 일관성과 무결성 향성
- 단점 :
JOIN을 많이 할 수 있기 때문에 오류 증가
문제 3-2. 정리
정규화는 데이터의 중복을 최소화하고 일관성을 보장하기 위한 체계적인 방법입니다. 데이터 중복으로 인한 갱신 이상을 방지하고 데이터 무결성을 확보하는 것이 주요 목적입니다.
제1정규형(1NF)은 테이블의 각 컬럼이 원자값을 가지도록 하는 규칙입니다. 반복 그룹이나 복합 속성을 제거하여 데이터의 기본적인 원자성을 보장합니다.
제2정규형(2NF)은 부분 함수적 종속을 제거하는 단계입니다. 복합키의 일부에만 종속되는 속성을 별도 테이블로 분리하여 데이터 중복을 줄입니다.
제3정규형(3NF)은 이행적 함수적 종속을 제거합니다. 기본키가 아닌 컬럼에 종속되는 컬럼을 별도 테이블로 분리하여 데이터의 일관성을 강화합니다.
정규화는 데이터 일관성과 시스템 성능 사이의 트레이드오프 관계를 가집니다. 높은 수준의 정규화는 데이터 일관성을 향상시키지만, 테이블 조인 증가로 인한 성능 저하를 초래할 수 있습니다. 따라서 실무에서는 업무의 특성과 성능 요구사항을 고려하여 적절한 수준의 정규화를 적용해야 합니다.
문제 3-3. 채점 코멘트
| ✔️ 정규화의 목적과 필요성 설명 | 2/2점 |
| ✔️ 각 정규형의 개념과 규칙 설명 | 3/3점 |
| ✔️ 정규화가 데이터 일관성에 미치는 영향 설명 | 1/2점 |
| ✔️ 정규화와 시스템 성능 간의 관계 및 트레이드오프 설명 | 1/3점 |
✅ 잘한 부분
- 정규화의 목적을 데이터 무결성과 이상 방지 관점에서 설명한 점이 좋았습니다.
- 제1정규형, 제2정규형, 제3정규형을 단계적으로 정리한 구조가 명확해서 이해하기 쉬웠어요.
- 각 정규형의 핵심 조건을 간결하게 정리한 점이 좋았습니다.
❗ 아쉬운 부분
- 정규화가 데이터 일관성에 어떤 영향을 주는지 갱신 이상, 삽입 이상, 삭제 이상과 같은 구체적인 설명이 빠진 점이 아쉽습니다. 포함해서 답변할 수 있어야 합니다.
- 성능 부분에서 JOIN 증가를 언급한 것은 좋았지만, “오류 증가”라는 표현은 부정확합니다. 성능 저하와 쿼리 복잡도 증가로 설명해야 합니다.
- 트레이드오프 설명에서 반정규화와 같은 보완 전략이 빠진 점이 조금 아쉬웠어요.
📚 더 공부하면 좋은 내용
- 갱신 이상, 삽입 이상, 삭제 이상을 실제 테이블 구조 예시로 학습해보세요.
- 정규화된 구조에서 JOIN이 많아질 때 실행 계획이 어떻게 변하는지 확인해보세요.
- 반정규화 적용 사례와 언제 사용하는지 기준을 정리해보면 좋겠습니다.
문제4. 객체 지향 프로그래밍과 관계형 데이터베이스 간의 패러다임 불일치 문제를 해결하기 위한 ORM의 등장 배경과 JPA를 도입했을 때의 장점에 대해 설명하세요.
[SB] [데이터베이스 설계와 Spring Data JPA]
문제 4-1. 답변
ORM 등장 배경
- 반복되는 로직을 제거하고, 비즈니스 로직에 집중하기 위해서
- 객체에 초점을 맞추기 위해서
JPA 도입 시 장점
- 간단한 조회는 메서드 호출만으로 사용 가능하기에 생산성 향상
문제 4-2. 정리
객체지향 프로그래밍에서는 상속, 다형성, 캡슐화 등의 개념을 활용하지만, 관계형 데이터베이스는 테이블 간의 관계를 통해 데이터를 표현합니다. 이로 인해 객체를 테이블에 맞추어 모델링하거나, 조인을 통해 객체를 조회하는 등의 패러다임 불일치 문제가 발생합니다.
SQL 중심의 개발에서는 객체와 테이블을 매핑하기 위한 많은 SQL을 작성해야 하며, 이는 생산성 저하와 유지보수의 어려움을 초래합니다. 또한 데이터베이스 설계가 변경될 경우 관련된 모든 SQL을 수정해야 하는 부담이 있습니다.
JPA는 자바 진영의 ORM 표준으로, Hibernate는 JPA의 구현체입니다. JPA는 개발자가 직접 SQL을 작성하지 않고도 객체지향적으로 데이터베이스를 사용할 수 있게 해줍니다.
JPA 도입의 장점으로는 객체지향적인 코드 작성이 가능하고, SQL을 자동으로 생성해주어 생산성이 향상되며, 데이터베이스 설계 변경 시 객체만 수정하면 되어 유지보수가 용이해집니다. 또한 영속성 컨텍스트를 통한 성능 최적화와 데이터베이스 벤더에 종속되지 않는 장점이 있습니다.
문제 4-3. 채점 코멘트
| ✔️ 객체지향과 관계형 데이터베이스 간의 패러다임 불일치 문제 설명 | - |
| ✔️ SQL 중심 개발의 문제점 서술 | - |
| ✔️ JPA의 정의와 Hibernate와의 관계 설명 | - |
| ✔️ JPA 도입 시 얻을 수 있는 실질적인 장점 제시 | 1/3점 |
✅ 잘한 부분
- ORM의 등장 이유를 생산성과 비즈니스 로직 집중 관점에서 설명한 점은 방향성이 맞았어요.
- JPA 사용 시 메서드 호출로 조회가 가능하다는 점을 통해 생산성 향상을 언급한 점은 좋았습니다.
❗ 아쉬운 부분
- 객체지향과 관계형 데이터베이스의 패러다임 불일치(상속, 참조 vs 외래키, 객체 그래프 탐색 문제 등)를 설명하지 못한 점이 아쉬웠어요.
- SQL 중심 개발의 문제점(반복 SQL 작성, 유지보수 어려움 등)을 포함해서 답변할 수 있어야 합니다.
- JPA가 ORM 표준이고 Hibernate가 구현체라는 관계를 설명하지 못한 점이 조금 아쉬웠어요.
- 장점이 생산성 하나로 제한되어 있어 영속성 컨텍스트, DB 독립성 등은 설명하지 못한 점이 아쉽습니다.
📚 더 공부하면 좋은 내용
- 객체지향과 RDB의 차이(상속, 연관관계 표현, 객체 그래프 탐색)를 정리해서 학습해보세요.
- SQL 중심 개발의 문제와 유지보수 비용 증가 사례를 정리해보세요.
- JPA, Hibernate, Spring Data JPA의 관계를 구조적으로 구분해서 학습해보세요.
- 영속성 컨텍스트의 동작 방식(1차 캐시, 변경 감지, 쓰기 지연)을 확인해보세요.
문제5. 온라인 쇼핑몰에서 상품 주문 시 발생할 수 있는 문제 상황을 예시로 들어, 트랜잭션의 ACID 속성이 왜 중요한지 설명하세요.
[SB] [데이터베이스 설계와 Spring Data JPA]
문제 5-1. 답변
트랜잭션 ACID
- A: 원자성
- 전부 수행되거나 전부 실패해야 한다.
- 예시: 결제는 성공했는데 재고가 없어 돈만 날리는 경우는 방지
- C: 일관성
- 트랜잭션 커밋 전 후로도 일관적이야 한다.
- I: 격리성
- 트랜잭션이 혼자 실행되는 것처럼 동작
- D: 지속성
- 트랜잭션이 commit되면, 영구적으로 유지되어야 한다.
문제 5-2. 정리
온라인 쇼핑몰의 주문 처리에서는 재고 감소, 결제 처리, 주문 정보 저장 등 여러 작업이 하나의 트랜잭션으로 처리되어야 합니다.
원자성과 일관성은 주문 과정에서 결제는 성공했으나 재고 차감에 실패하는 등의 불일치를 방지합니다. 모든 작업이 성공하거나 모두 실패하여 롤백되어야 하며, 재고와 결제 상태는 항상 일관성을 유지해야 합니다.
격리성은 동시에 여러 고객이 같은 상품을 주문할 때 중요합니다. 한 고객의 주문 처리가 완료되기 전에 다른 고객이 동일 재고에 접근하여 발생할 수 있는 문제를 방지합니다.
지속성은 주문 완료 후 시스템에 문제가 발생하더라도 주문 정보가 안전하게 저장되어 있음을 보장합니다. 이는 주문 이력 관리와 고객 신뢰도 유지에 필수적입니다.
문제 5-3. 채점 코멘트
✔️ 상품 주문 시나리오에서 발생할 수 있는 문제 상황 제시1/2점
✔️ 원자성과 일관성이 주문 처리에 미치는 영향 설명2/3점
✔️ 격리성이 동시 주문 처리에 미치는 영향 설명1/3점
✔️ 지속성이 주문 데이터 보존에 미치는 영향 설명1/2점
✅ 잘한 부분
- 원자성을 결제 성공 후 재고 실패 상황으로 설명한 점은 정확한 답변이에요.
- ACID 각각의 개념을 간단하게라도 정리하려는 흐름은 좋았습니다.
- 전체적으로 핵심 키워드를 빠뜨리지 않고 작성한 점은 아주 좋았어요.
❗ 아쉬운 부분
- 문제 상황이 원자성에만 집중되어 있어 아쉽습니다. 격리성과 지속성에 대해서도 각각의 상황 예시를 포함해서 답변할 수 있어야 합니다.
- 일관성 설명이 “일관적이어야 한다” 수준으로 끝나서 아쉽습니다. 재고 음수 방지나 결제 금액 불일치 같은 구체적인 비즈니스 규칙으로 설명해야 합니다.
- 격리성은 “혼자 실행되는 것처럼”이라는 개념만 있고, 동시에 주문 시 재고가 중복 차감되는 문제를 포함해서 설명할 수 있어야 합니다.
- 지속성도 개념만 있고, 장애 발생 후에도 주문 데이터가 유지되는 상황을 포함해서 설명할 수 있어야 합니다.
📚 더 공부하면 좋은 내용
- ACID를 각각 “실제 장애 시나리오” 기준으로 정리해보세요.
- 동시성 문제(재고, 결제)를 코드 레벨에서 어떻게 해결하는지 학습해보세요.
- 트랜잭션 흐름과 rollback 동작을 예제 기반으로 학습해보면 좋겠습니다.
Leave a comment