gRPC 주니어 데이터베이스 기술면접
새 면접Q. gRPC 서비스에서 사용자(User)와 주문(Order)의 1:N 관계를 데이터베이스에 설계할 때, 외래키(Foreign Key)는 어느 테이블에 어떻게 추가해야 하나요? 그리고 그 이유는 무엇인가요?
1:N 관계에서 N쪽 테이블이 1쪽 테이블의 기본키를 참조하는 방식을 생각해보세요.
외래키는 Order 테이블에 추가해야 합니다. user_id 컬럼을 Order 테이블에 만들고, 이 컬럼이 User 테이블의 기본키를 참조하도록 설정합니다. 1:N 관계에서는 N쪽(Many)이 1쪽(One)의 키를 가지는 것이 정규화 원칙에 부합하며, 데이터 중복을 방지할 수 있습니다. 이렇게 하면 한 명의 사용자가 여러 주문을 가질 수 있고, 각 주문은 정확히 한 명의 사용자에게 속하게 됩니다. gRPC 서비스에서 주문 조회 시 JOIN을 통해 사용자 정보를 함께 가져올 수 있습니다.
- • 외래키는 N쪽 테이블(Order)에 추가
- • 1쪽 테이블(User)의 기본키를 참조
- • 데이터 중복 방지 및 정규화
gRPC 마이크로서비스에서 사용자 서비스와 주문 서비스가 분리되어 있을 때, 각 서비스의 데이터베이스 스키마를 설계하는 상황에서 사용됩니다.
만약 사용자와 주문이 M:N 관계라면 어떻게 설계하시겠습니까?
Q. gRPC API에서 사용자 이메일로 조회하는 요청이 자주 발생합니다. users 테이블의 email 컬럼에 인덱스를 생성하면 어떤 장점과 단점이 있나요?
조회 성능과 쓰기 작업의 트레이드오프를 생각해보세요.
인덱스의 장점은 SELECT 쿼리의 성능이 크게 향상된다는 것입니다. 특히 WHERE 절에서 email로 검색할 때 Full Table Scan 대신 인덱스를 통해 빠르게 데이터를 찾을 수 있습니다. 단점은 INSERT, UPDATE, DELETE 작업 시 인덱스도 함께 갱신해야 하므로 쓰기 성능이 저하되고, 인덱스를 저장하기 위한 추가 디스크 공간이 필요합니다. 또한 email 컬럼은 중복이 없어야 하므로 UNIQUE 인덱스로 생성하면 데이터 무결성도 보장할 수 있습니다. gRPC 서비스에서 조회가 빈번하다면 인덱스 생성의 이점이 더 큽니다.
- • 조회 성능 향상(Full Table Scan 방지)
- • 쓰기 성능 저하 및 저장 공간 증가
- • UNIQUE 인덱스로 무결성 보장 가능
gRPC 인증 서비스에서 로그인 요청 시 이메일로 사용자를 조회하는 쿼리의 성능을 개선할 때 사용됩니다.
복합 인덱스(Composite Index)는 언제 사용하는 것이 좋을까요?
Q. gRPC 결제 서비스에서 주문 생성과 재고 감소를 하나의 트랜잭션으로 처리해야 합니다. 트랜잭션의 ACID 속성 중 Atomicity(원자성)가 왜 중요한지 설명하고, 이를 보장하지 않으면 어떤 문제가 발생할 수 있나요?
트랜잭션 내 모든 작업이 성공하거나 모두 실패해야 하는 이유를 생각해보세요.
Atomicity는 트랜잭션 내의 모든 작업이 전부 성공하거나 전부 실패해야 함을 보장하는 속성입니다. 주문 생성은 성공했지만 재고 감소가 실패하면, 재고는 그대로인데 주문만 생성되어 실제 재고보다 많은 주문이 발생하는 문제가 생깁니다. 반대로 재고는 감소했지만 주문 생성이 실패하면, 주문 없이 재고만 줄어드는 데이터 불일치가 발생합니다. Atomicity를 보장하면 중간에 오류가 발생했을 때 자동으로 롤백되어 데이터베이스가 일관된 상태를 유지합니다. gRPC 서비스에서는 BEGIN, COMMIT, ROLLBACK을 사용하여 트랜잭션을 명시적으로 관리해야 합니다.
- • 모든 작업이 성공하거나 모두 실패
- • 데이터 불일치 방지
- • 롤백을 통한 일관성 유지
gRPC 전자상거래 서비스에서 결제, 주문, 재고를 동시에 처리할 때 데이터 정합성을 보장하기 위해 사용됩니다.
트랜잭션의 격리 수준(Isolation Level)에는 어떤 것들이 있고, 각각 어떤 특징이 있나요?
Q. gRPC 좌석 예약 시스템에서 동시에 여러 사용자가 같은 좌석을 예약하려 할 때, Optimistic Lock과 Pessimistic Lock 중 어떤 방식이 더 적합한지 설명하고 그 이유를 말씀해주세요.
동시성 충돌 빈도와 데이터 일관성 요구사항을 고려해보세요.
좌석 예약 시스템에는 Pessimistic Lock이 더 적합합니다. 좌석은 한 번에 한 명만 예약할 수 있어야 하므로, 동시 접근 시 반드시 순차적으로 처리되어야 합니다. Pessimistic Lock은 SELECT FOR UPDATE를 사용하여 조회 시점에 행을 잠그므로, 다른 트랜잭션이 대기하게 만들어 중복 예약을 원천 차단합니다. Optimistic Lock은 버전 컬럼으로 충돌을 감지하지만, 충돌 시 재시도가 필요하고 사용자 경험이 나빠질 수 있습니다. 인기 좌석의 경우 동시 접근이 빈번하므로 처음부터 락을 거는 Pessimistic 방식이 효율적입니다.
- • Pessimistic Lock이 적합
- • SELECT FOR UPDATE로 행 잠금
- • 중복 예약 원천 차단
gRPC 콘서트 예매 서비스나 항공권 예약 시스템에서 동시 예약 요청을 안전하게 처리할 때 사용됩니다.
Pessimistic Lock 사용 시 데드락이 발생할 수 있는 상황과 해결 방법은 무엇인가요?
Q. gRPC 서비스에서 EXPLAIN 명령어를 사용하여 쿼리 실행 계획을 분석할 때, 어떤 지표들을 주로 확인해야 하며, 성능 문제를 의심할 수 있는 신호는 무엇인가요?
테이블 스캔 방식과 조회되는 행의 수를 중점적으로 살펴보세요.
EXPLAIN 결과에서 주로 확인해야 할 지표는 type, rows, Extra 컬럼입니다. type이 ALL이면 Full Table Scan을 의미하므로 성능 문제의 신호입니다. 이상적으로는 type이 const, eq_ref, ref 등이어야 합니다. rows는 검사해야 할 행의 수를 나타내며, 이 값이 크면 인덱스가 제대로 활용되지 않는다는 의미입니다. Extra에 Using filesort나 Using temporary가 나타나면 정렬이나 임시 테이블 생성으로 인한 성능 저하가 있을 수 있습니다. 인덱스를 추가하거나 쿼리를 재작성하여 이러한 문제를 해결할 수 있습니다.
- • type이 ALL이면 Full Table Scan
- • rows 값이 크면 인덱스 미활용
- • Using filesort, Using temporary는 성능 저하 신호
gRPC 서비스의 응답 시간이 느려질 때, 데이터베이스 쿼리를 분석하여 병목 지점을 찾고 최적화하는 상황에서 사용됩니다.
쿼리에 인덱스가 있는데도 사용되지 않는 경우는 어떤 상황이 있을까요?
Q. gRPC 리포트 생성 서비스에서 통계 데이터를 조회하는 중에 다른 트랜잭션이 데이터를 수정하여 같은 쿼리를 두 번 실행했을 때 결과가 달라지는 문제가 발생했습니다. 이것은 어떤 현상이며, 어떤 격리 수준으로 해결할 수 있나요?
트랜잭션 내에서 같은 쿼리의 결과가 달라지는 현상의 이름을 떠올려보세요.
이것은 Non-Repeatable Read 현상입니다. 하나의 트랜잭션 내에서 같은 행을 두 번 읽었을 때, 다른 트랜잭션이 중간에 해당 행을 수정하고 커밋하면 두 번째 읽기 결과가 달라지는 문제입니다. 이를 해결하려면 격리 수준을 REPEATABLE READ 이상으로 설정해야 합니다. REPEATABLE READ에서는 트랜잭션이 시작된 시점의 스냅샷을 사용하므로, 다른 트랜잭션의 변경사항이 보이지 않아 일관된 결과를 얻을 수 있습니다. MySQL InnoDB의 기본 격리 수준이 REPEATABLE READ이므로 대부분의 경우 이 문제를 자동으로 방지할 수 있습니다.
- • Non-Repeatable Read 현상
- • REPEATABLE READ 격리 수준으로 해결
- • 트랜잭션 스냅샷으로 일관성 보장
gRPC 정산 서비스에서 일일 매출 통계를 계산하는 동안 새로운 주문이 계속 들어오는 상황에서 일관된 결과를 보장해야 할 때 사용됩니다.
Phantom Read는 Non-Repeatable Read와 어떻게 다르며, 어떤 격리 수준에서 방지할 수 있나요?
Q. gRPC 서비스의 데이터베이스 테이블에서 정규화(Normalization)가 필요한 이유는 무엇이며, 제1정규형(1NF)의 조건은 무엇인가요?
데이터 중복과 원자값(Atomic Value)을 생각해보세요.
정규화는 데이터 중복을 최소화하고 데이터 무결성을 보장하기 위해 필요합니다. 중복된 데이터가 있으면 수정 시 모든 곳을 업데이트해야 하고, 일부만 수정하면 데이터 불일치가 발생합니다. 제1정규형의 조건은 모든 컬럼이 원자값을 가져야 한다는 것입니다. 즉, 하나의 셀에 여러 값을 저장할 수 없으며, 배열이나 리스트 형태의 데이터를 포함해서는 안 됩니다. 예를 들어 전화번호 컬럼에 여러 번호를 쉼표로 구분하여 저장하는 것은 1NF를 위반하며, 별도의 전화번호 테이블로 분리해야 합니다.
- • 데이터 중복 최소화 및 무결성 보장
- • 제1정규형: 모든 컬럼이 원자값
- • 배열이나 다중값 저장 금지
gRPC 마이크로서비스에서 새로운 도메인 모델을 설계할 때, 효율적이고 유지보수 가능한 데이터베이스 스키마를 만들기 위해 사용됩니다.
정규화를 과도하게 하면 어떤 문제가 발생할 수 있으며, 역정규화(Denormalization)는 언제 고려하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!