Go 미드레벨 데이터베이스 기술면접
새 면접Q. 복합 인덱스(Composite Index)를 생성할 때 컬럼 순서가 쿼리 성능에 미치는 영향을 설명하고, WHERE 절에 여러 조건이 있을 때 인덱스 컬럼 순서를 결정하는 실무 기준을 제시해주세요. 또한 Go에서 쿼리를 작성할 때 인덱스를 효과적으로 활용하기 위한 주의사항을 설명해주세요.
인덱스는 앞 컬럼부터 순차적으로 사용되며, 카디널리티와 조건 사용 빈도를 고려해야 합니다.
복합 인덱스는 최좌측 컬럼부터 순차적으로 사용되므로 컬럼 순서가 매우 중요합니다. 일반적으로 카디널리티가 높은(고유값이 많은) 컬럼을 앞에 배치하고, WHERE 절에서 등호(=) 조건으로 자주 사용되는 컬럼을 우선 배치합니다. 범위 조건(BETWEEN, >, <)은 인덱스 스캔을 멈추게 하므로 뒤쪽에 배치하는 것이 좋습니다. Go에서는 PreparedStatement를 사용할 때 파라미터 바인딩 순서가 인덱스 활용에 영향을 주지 않지만, 동적 쿼리 생성 시 WHERE 절 조건 순서를 인덱스 컬럼 순서와 일치시키는 것이 가독성에 좋습니다. EXPLAIN 명령어로 실행 계획을 확인하여 인덱스가 제대로 사용되는지 검증해야 합니다.
- • 복합 인덱스는 최좌측 컬럼부터 순차적으로 사용됨
- • 카디널리티가 높고 등호 조건으로 자주 사용되는 컬럼을 앞에 배치
- • 범위 조건 컬럼은 뒤쪽에 배치하여 인덱스 활용 극대화
- • EXPLAIN으로 실행 계획 검증 필수
전자상거래 주문 테이블에서 user_id, status, created_at 조건으로 검색할 때 복합 인덱스 컬럼 순서를 잘못 설정하면 풀 테이블 스캔이 발생하여 응답 시간이 급격히 증가합니다.
인덱스 커버링(Covering Index)이란 무엇이며, 이를 활용하면 쿼리 성능이 개선되는 이유를 설명해주세요.
Q. 데이터베이스에서 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)의 동작 원리와 차이를 설명하고, Go에서 각각을 구현하는 방법을 제시해주세요. 또한 실무에서 각 락 전략을 선택해야 하는 시나리오와 동시성 충돌이 빈번할 때의 대응 방안을 설명해주세요.
낙관적 락은 버전 컬럼을 활용하고, 비관적 락은 SELECT FOR UPDATE를 사용하며, 충돌 빈도에 따라 선택이 달라집니다.
낙관적 락은 데이터 읽기 시점에는 락을 걸지 않고 버전 컬럼(version 또는 updated_at)을 함께 읽어서, 업데이트 시 버전이 일치하는지 확인하여 충돌을 감지합니다. Go에서는 UPDATE users SET balance = ?, version = version + 1 WHERE id = ? AND version = ? 형태로 구현하며, affected rows가 0이면 재시도 로직을 수행합니다. 비관적 락은 SELECT FOR UPDATE를 사용하여 트랜잭션 내에서 행 수준 락을 획득하고, 다른 트랜잭션의 접근을 차단합니다. 충돌이 드문 경우(읽기 위주)에는 낙관적 락이 성능상 유리하고, 충돌이 빈번한 경우(재고 차감 등)에는 비관적 락으로 처음부터 락을 획득하는 것이 불필요한 재시도를 줄입니다. 동시성이 매우 높은 경우 Redis를 활용한 분산 락이나 메시지 큐를 통한 순차 처리를 고려해야 합니다.
- • 낙관적 락은 버전 컬럼으로 충돌 감지, 충돌 시 재시도 필요
- • 비관적 락은 SELECT FOR UPDATE로 행 락 획득
- • 읽기 위주는 낙관적 락, 쓰기 충돌 빈번하면 비관적 락 선택
- • 고동시성 환경에서는 분산 락이나 메시지 큐 고려
티켓팅 시스템에서 동시에 수천 명이 좌석을 예약할 때 적절한 락 전략 선택이 없으면 과매도나 성능 저하가 발생합니다.
데드락이 발생했을 때 데이터베이스가 이를 감지하고 해결하는 메커니즘과, Go 애플리케이션에서 데드락 발생을 최소화하기 위한 설계 원칙을 설명해주세요.
Q. 정규화(Normalization)의 제1정규형부터 제3정규형까지 각각의 목적과 조건을 설명하고, 실무에서 의도적으로 비정규화(Denormalization)를 선택해야 하는 상황과 그때 발생할 수 있는 문제점 및 대응 방안을 제시해주세요. Go 애플리케이션에서 비정규화된 데이터의 정합성을 유지하는 방법도 함께 설명해주세요.
정규화는 중복 제거와 이상 현상 방지가 목적이며, 비정규화는 조인 비용 절감을 위해 선택하지만 데이터 정합성 관리가 필요합니다.
제1정규형은 원자값만 저장하여 반복 그룹을 제거하고, 제2정규형은 부분 함수 종속을 제거하여 모든 비키 속성이 기본키 전체에 종속되게 하며, 제3정규형은 이행 함수 종속을 제거하여 비키 속성 간 종속을 없앱니다. 실무에서는 조인 비용이 높은 대용량 조회 쿼리나 집계 데이터가 자주 필요한 경우 의도적으로 비정규화를 선택합니다. 비정규화 시 데이터 중복으로 인한 불일치 문제가 발생할 수 있으므로, Go에서는 트랜잭션 내에서 관련된 모든 테이블을 함께 업데이트하거나, 이벤트 기반 아키텍처로 비동기 동기화를 수행합니다. 또한 주기적인 배치 작업으로 데이터 정합성을 검증하고, 쓰기는 정규화된 원본 테이블에 하고 읽기는 비정규화된 조회 테이블을 사용하는 CQRS 패턴도 고려할 수 있습니다.
- • 정규화는 1NF(원자값), 2NF(부분 종속 제거), 3NF(이행 종속 제거) 단계로 중복 제거
- • 비정규화는 조인 비용 절감이 목적이나 데이터 불일치 위험 존재
- • 트랜잭션으로 동시 업데이트하거나 이벤트 기반 동기화 필요
- • CQRS 패턴으로 쓰기/읽기 테이블 분리 고려
소셜 미디어 피드에서 사용자 정보를 매번 조인하면 성능이 저하되므로, 게시물 테이블에 작성자 이름과 프로필 이미지를 비정규화하여 저장합니다.
샤딩(Sharding)된 데이터베이스 환경에서 조인 쿼리가 불가능할 때 데이터 모델링을 어떻게 설계해야 하는지 설명해주세요.
Q. N+1 쿼리 문제가 무엇인지 설명하고, Go에서 ORM(GORM 등)을 사용할 때 이 문제가 발생하는 구체적인 시나리오와 해결 방법을 제시해주세요. 또한 Eager Loading과 Lazy Loading의 차이점 및 각각의 적절한 사용 시나리오를 실무 관점에서 설명해주세요.
N+1 문제는 연관 데이터를 개별 쿼리로 조회하여 발생하며, JOIN이나 Preload로 해결할 수 있습니다.
N+1 쿼리 문제는 메인 엔티티 N개를 조회한 후 각 엔티티의 연관 데이터를 개별 쿼리로 가져와 총 N+1번의 쿼리가 실행되는 성능 문제입니다. Go의 GORM에서 사용자 목록을 조회한 후 루프를 돌며 각 사용자의 주문을 조회하면 N+1 문제가 발생합니다. 해결 방법으로는 Preload나 Joins를 사용하여 한 번의 쿼리로 연관 데이터를 함께 가져오는 Eager Loading을 적용합니다. Lazy Loading은 연관 데이터가 실제로 필요할 때만 조회하므로 메모리 효율적이지만 N+1 위험이 있고, Eager Loading은 초기에 모든 데이터를 가져와 추가 쿼리가 없지만 불필요한 데이터까지 로드될 수 있습니다. 실무에서는 대부분의 경우 연관 데이터가 필요하면 Eager Loading을, 선택적으로만 필요하면 Lazy Loading을 사용하되 쿼리 로그를 모니터링하여 N+1 발생을 감지해야 합니다.
- • N+1 문제는 메인 쿼리 1번 + 연관 데이터 N번 조회로 성능 저하
- • GORM의 Preload나 Joins로 Eager Loading 구현
- • Eager Loading은 초기 로드, Lazy Loading은 필요 시 로드
- • 쿼리 로그 모니터링으로 N+1 발생 감지 필수
게시판에서 게시글 목록과 각 게시글의 댓글 수를 표시할 때 N+1 문제가 발생하면 응답 시간이 수십 배 증가합니다.
대용량 데이터를 페이지네이션할 때 OFFSET 방식의 성능 문제와 Cursor 기반 페이지네이션의 장점을 설명하고, Go에서 구현하는 방법을 제시해주세요.
Q. 분산 트랜잭션 환경에서 2PC(Two-Phase Commit) 프로토콜의 동작 과정과 한계를 설명하고, 마이크로서비스 아키텍처에서 Saga 패턴이 2PC의 대안으로 사용되는 이유를 설명해주세요. Go에서 Saga 패턴의 Orchestration 방식과 Choreography 방식을 각각 구현할 때 고려사항을 제시해주세요.
2PC는 동기적 일관성을 보장하지만 블로킹 문제가 있고, Saga는 비동기 보상 트랜잭션으로 최종 일관성을 달성합니다.
2PC는 Prepare 단계에서 모든 참여자가 커밋 가능 여부를 확인하고, Commit 단계에서 코디네이터의 지시에 따라 일괄 커밋하여 원자성을 보장합니다. 하지만 코디네이터 장애 시 참여자들이 블로킹되고, 네트워크 지연에 민감하며 성능이 낮아 마이크로서비스 환경에 부적합합니다. Saga 패턴은 각 서비스의 로컬 트랜잭션을 순차 실행하고, 실패 시 보상 트랜잭션(Compensating Transaction)으로 이전 단계를 롤백하여 최종 일관성을 달성합니다. Orchestration 방식은 중앙 오케스트레이터가 Go로 구현된 워크플로우 엔진에서 각 단계를 순차 호출하고 실패 시 보상을 관리하여 제어가 명확하지만 단일 장애점이 될 수 있습니다. Choreography 방식은 각 서비스가 이벤트를 발행하고 구독하여 자율적으로 동작하므로 결합도가 낮지만 전체 흐름 파악이 어렵고 디버깅이 복잡합니다.
- • 2PC는 동기적 원자성 보장하나 블로킹과 성능 문제 존재
- • Saga는 로컬 트랜잭션 + 보상 트랜잭션으로 최종 일관성 달성
- • Orchestration은 중앙 제어로 명확하나 단일 장애점 위험
- • Choreography는 이벤트 기반으로 결합도 낮으나 복잡도 증가
주문 생성 시 결제, 재고 차감, 배송 준비가 각각 다른 마이크로서비스에서 처리될 때 한 단계 실패 시 이전 단계를 보상하는 Saga 패턴이 필수적입니다.
이벤트 소싱(Event Sourcing) 패턴과 CQRS를 결합하여 사용할 때의 장점과, Go에서 이를 구현하기 위한 아키텍처 설계 방안을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!