PostgreSQL 미드레벨 기술면접
새 면접Q. PostgreSQL의 Trigger를 BEFORE와 AFTER로 구분할 때 각각의 실행 시점과 사용 사례를 설명하고, INSTEAD OF Trigger의 개념과 활용 방법을 설명해주세요. 또한 Trigger 사용 시 성능 저하를 방지하기 위한 전략은 무엇인가요?
BEFORE Trigger는 데이터 변경 전에 실행되어 입력값 검증이나 변환에 사용되며, AFTER Trigger는 변경 후 실행되어 로그 기록이나 파생 데이터 갱신에 적합합니다. INSTEAD OF Trigger는 View에 대한 DML 작업을 가로채어 실제 테이블에 대한 복잡한 로직을 수행할 때 사용합니다. 성능 저하 방지를 위해서는 Trigger 내 복잡한 로직을 최소화하고, 비동기 처리가 가능한 작업은 큐 시스템으로 분리하며, 재귀 호출을 방지하고, 필요한 경우에만 Row-level Trigger를 사용해야 합니다.
- • BEFORE Trigger는 데이터 검증/변환, AFTER Trigger는 로그/파생 데이터 처리에 적합
- • INSTEAD OF Trigger는 View에 대한 DML 작업을 실제 테이블 로직으로 전환
- • 성능 최적화: 로직 최소화, 비동기 처리 분리, 재귀 방지
- • Row-level vs Statement-level Trigger 선택의 중요성
Trigger와 Application Level에서의 로직 처리를 비교했을 때, 각각 어떤 상황에서 사용하는 것이 적합한가요?
Q. PostgreSQL의 Sequence 객체의 동작 원리를 설명하고, nextval(), currval(), setval() 함수의 차이점과 트랜잭션 롤백 시 Sequence 값의 동작을 설명해주세요. 또한 여러 세션에서 동시에 Sequence를 사용할 때 gap이 발생하는 이유와 이를 방지해야 하는 경우의 대안을 제시해주세요.
Sequence는 트랜잭션과 독립적으로 동작하는 원자적 카운터입니다. nextval()은 다음 값을 반환하고 증가시키며, currval()은 현재 세션의 마지막 nextval() 값을 반환하고, setval()은 Sequence 값을 직접 설정합니다. 트랜잭션이 롤백되어도 nextval()로 할당된 값은 되돌려지지 않아 gap이 발생합니다. 동시성 환경에서 gap은 성능을 위한 트레이드오프이며, gap 없는 연속 번호가 필요한 경우 별도 테이블에 카운터를 저장하고 SELECT FOR UPDATE로 락을 걸거나, 애플리케이션 레벨에서 Redis 등을 활용한 분산 카운터를 사용해야 합니다.
- • Sequence는 트랜잭션과 독립적으로 동작하여 성능과 동시성 보장
- • 롤백 시에도 할당된 Sequence 값은 반환되지 않아 gap 발생
- • Gap은 정상적인 동작이며 고성능 ID 생성을 위한 설계
- • 연속 번호가 필수인 경우 테이블 기반 카운터나 분산 락 활용
마이크로서비스 환경에서 여러 인스턴스가 동일한 Sequence를 사용할 때 발생할 수 있는 병목 현상을 어떻게 해결하시겠습니까?
Q. PostgreSQL의 4가지 트랜잭션 격리 수준(Read Uncommitted, Read Committed, Repeatable Read, Serializable)에서 발생할 수 있는 현상(Dirty Read, Non-Repeatable Read, Phantom Read, Serialization Anomaly)을 설명하고, PostgreSQL이 MVCC를 통해 이를 어떻게 처리하는지 설명해주세요. 또한 Serializable 격리 수준에서 발생하는 Serialization Failure를 애플리케이션에서 어떻게 처리해야 하나요?
PostgreSQL은 MVCC 구조로 인해 Read Uncommitted를 지원하지 않으며 실제로는 Read Committed로 동작합니다. Read Committed는 Non-Repeatable Read와 Phantom Read가 발생 가능하고, Repeatable Read는 Phantom Read를 방지하며 동일 트랜잭션 내 일관된 스냅샷을 제공합니다. Serializable은 SSI(Serializable Snapshot Isolation) 기법으로 모든 동시성 이상을 방지하지만, 충돌 시 SQLSTATE 40001 에러를 발생시킵니다. 애플리케이션은 Serialization Failure를 catch하여 지수 백오프 방식으로 재시도하고, 트랜잭션을 가능한 짧게 유지하며, 읽기 전용 작업은 낮은 격리 수준을 사용해야 합니다.
- • PostgreSQL은 MVCC로 Dirty Read를 원천 차단하며 Read Uncommitted는 실제로 Read Committed로 동작
- • Repeatable Read는 스냅샷 격리로 Phantom Read까지 방지
- • Serializable은 SSI 기법으로 완전한 직렬화 보장하나 충돌 시 재시도 필요
- • 애플리케이션 레벨에서 40001 에러 핸들링과 재시도 로직 구현 필수
재고 관리 시스템에서 동시에 여러 주문이 마지막 재고를 차감하려 할 때, 어떤 격리 수준과 Lock 전략을 조합하여 사용하시겠습니까?
Q. PostgreSQL의 Extension 시스템의 개념을 설명하고, PostGIS, pg_trgm, hstore 같은 주요 Extension들의 활용 사례를 제시해주세요. 또한 Custom Data Type과 Custom Operator를 생성하는 것이 유용한 시나리오와, Extension 설치 시 보안 및 버전 관리 측면에서 고려해야 할 사항을 설명해주세요.
Extension은 PostgreSQL의 핵심 기능을 확장하는 패키지 시스템으로 CREATE EXTENSION 명령으로 설치합니다. PostGIS는 공간 데이터 처리, pg_trgm은 유사도 기반 검색과 퍼지 매칭, hstore는 Key-Value 저장에 사용됩니다. Custom Type은 도메인 특화 데이터(IP 주소, 통화, 좌표 등)를 타입 안전하게 처리할 때 유용하며, Custom Operator는 특수한 비교나 연산 로직을 SQL 레벨에서 표현할 수 있게 합니다. Extension 설치 시 신뢰할 수 있는 출처 확인, 프로덕션 적용 전 테스트, PostgreSQL 버전 호환성 검증, 정기적인 업데이트 관리가 필요합니다.
- • Extension은 플러그인 방식으로 PostgreSQL 기능 확장
- • PostGIS(공간), pg_trgm(유사도 검색), hstore(KV 저장) 등 다양한 실무 활용
- • Custom Type/Operator로 도메인 특화 로직을 DB 레벨에서 구현 가능
- • 보안, 호환성, 버전 관리 측면의 운영 고려사항 중요
대규모 전자상거래 시스템에서 상품 태그 검색 성능을 개선하기 위해 pg_trgm Extension을 어떻게 활용하시겠습니까?
Q. PostgreSQL의 Physical Replication과 Logical Replication의 차이점을 설명하고, 각각의 장단점과 적합한 사용 사례를 비교해주세요. 또한 Streaming Replication 환경에서 Synchronous Replication과 Asynchronous Replication의 트레이드오프를 설명하고, 금융 시스템처럼 데이터 손실이 허용되지 않는 환경에서 어떤 설정을 선택하시겠습니까?
Physical Replication은 WAL 파일을 바이트 단위로 복제하여 전체 클러스터를 동일하게 유지하며, Logical Replication은 논리적 변경사항을 디코딩하여 선택적 테이블/데이터베이스 복제가 가능합니다. Physical은 성능이 우수하고 설정이 간단하지만 전체 복제만 가능하며 PostgreSQL 버전이 동일해야 하고, Logical은 선택적 복제와 버전 간 복제가 가능하지만 DDL은 자동 복제되지 않습니다. Synchronous Replication은 Standby 서버의 확인을 받아 데이터 손실을 방지하지만 대기 시간이 증가하고, Asynchronous는 빠르지만 장애 시 데이터 손실 가능성이 있습니다. 금융 시스템에서는 Synchronous Replication을 사용하되, synchronous_commit을 'remote_apply'로 설정하고 최소 2개 이상의 Standby를 구성해야 합니다.
- • Physical Replication은 WAL 기반 전체 복제, Logical은 선택적 테이블 복제
- • Physical은 성능 우수하나 유연성 부족, Logical은 유연하나 DDL 수동 처리 필요
- • Synchronous는 데이터 안정성 보장, Asynchronous는 성능 우선
- • 금융 시스템은 Synchronous + remote_apply + 다중 Standby 구성 필수
글로벌 서비스에서 지역별로 읽기 성능을 최적화하면서도 쓰기 일관성을 보장하기 위한 복제 아키텍처를 어떻게 설계하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!