데이터베이스 관리자(Database Administrator, DBA) 면접을 앞두고 계신가요? 2025년 현재, DBA는 클라우드 기반 데이터베이스와 AI 혁신 가속화 등 데이터 기반의 디지털 대전환을 주도하는 핵심 인재로 주목받고 있습니다. 하지만 막상 면접장에서는 어떤 질문이 나올지, 어떻게 답변해야 할지 막막하죠. 그래서 이번 포스트에서는 “DBA 면접 인터뷰 예상 질문 Top10과 Best 답변”이라는 주제로, 오라클(Oracle)과 MySQL 환경을 운영해온 경험과 최근 면접 트렌드를 분석해서, 면접관이 정말 듣고 싶어하는 핵심 포인트를 담은 답변 가이드를 준비했습니다. 실제 면접에서 바로 사용할 수 있는 구두 답변 형태로 작성해 보았습니다.
1. “ACID 속성에 대해 간단히 설명해보세요”
면접관의 핵심 의도:
- DBA 기본 이론 지식 확인
- 트랜잭션 개념 이해도 측정
- 데이터 무결성 인식 수준 파악
구두 답변 (30초): “ACID는 데이터베이스 트랜잭션의 4가지 속성입니다.
원자성(Atomicity)은 All or Nothing, 계좌이체처럼 모두 성공하거나 모두 실패해야 합니다. 일관성(Consistency)은 트랜잭션 전후에 데이터가 항상 유효한 상태를 유지하는 것이고요. 격리성(Isolation)은 동시 실행되는 트랜잭션들이 서로 간섭하지 않도록 하는 것으로, 오라클은 언두 세그먼트로 이를 보장합니다. 마지막으로 지속성(Durability)은 커밋된 데이터가 리두 로그를 통해 영구히 저장되는 것입니다.
실무에서는 READ COMMITTED와 SERIALIZABLE 같은 격리 수준을 조정해서 성능과 일관성의 균형을 맞추는 게 중요합니다.”
2. “쿼리 성능이 갑자기 느려졌다면 어떻게 접근하시겠습니까?”
면접관의 핵심 의도:
- 체계적 문제 해결 능력 확인
- 트러블슈팅 경험과 역량 검증
- 우선순위 판단 능력 평가
구두 답변 (45초): “4단계로 접근합니다.
첫째, 현재 상황 파악입니다. V$SESSION이나 SHOW PROCESSLIST로 실행 중인 세션과 락 상태를 확인하고, 최근 변경사항이 있었는지 체크합니다.
둘째, 실행계획 분석입니다. EXPLAIN으로 실행계획을 보고 카디널리티 추정치나 풀테이블스캔이 발생하는지 확인합니다.
셋째, 통계정보 점검입니다. 테이블 통계가 오래됐다면 CBO(Cost-Based Optimizer)가 잘못된 계획을 세울 수 있어요.
넷째, 리소스 모니터링입니다. CPU, 메모리, 디스크 I/O 사용률과 주요 대기 이벤트를 확인합니다.
실제로 최근에 대량 데이터 입력 후 통계정보가 갱신되지 않아 실행계획이 풀스캔으로 바뀐 사례가 있었는데, GATHER_TABLE_STATS로 바로 해결했습니다.”
3. “MongoDB와 MySQL을 언제 사용하시겠습니까?”
면접관의 핵심 의도:
- 다양한 데이터베이스 기술 이해도 확인
- 비즈니스 요구사항에 맞는 기술 선택 능력 평가
- NoSQL과 RDBMS 차이점 이해도 측정
구두 답변 (40초): “용도에 따라 선택이 달라집니다.
MySQL은 ACID 트랜잭션이 중요한 경우에 씁니다. 금융 시스템, 주문 관리, 재고 관리처럼 데이터 정합성이 중요하거나 복잡한 JOIN이 많은 경우죠. InnoDB 스토리지 엔진으로 MVCC를 지원하고 스키마가 안정적일 때 적합합니다.
MongoDB는 스키마가 유연해야 할 때 사용합니다. BSON 형태로 중첩 구조를 저장할 수 있어 제품 카탈로그처럼 구조가 다양하거나, 수평 확장(Sharding)이 필요할 때 좋습니다.
실제 이커머스 프로젝트에서는 주문 시스템은 MySQL에, 상품 정보와 리뷰는 MongoDB에 저장해서 각각의 장점을 활용했습니다.”
4. “Redis는 언제 사용하나요?”
면접관의 핵심 의도:
- 인메모리 데이터베이스 이해도 확인
- 캐싱 전략과 성능 최적화 경험 평가
- 시스템 아키텍처 설계 능력 측정
구두 답변 (30초): “Redis는 주로 세 가지 용도로 사용합니다.
첫째, 캐싱입니다. 자주 조회되는 데이터를 메모리에 저장해서 응답 속도를 밀리초 단위로 높입니다. LRU나 LFU 정책으로 메모리를 효율적으로 관리하죠.
둘째, 세션 저장소입니다. 웹 애플리케이션의 사용자 세션이나 JWT 토큰을 저장할 때 TTL(Time To Live) 기능이 유용합니다.
셋째, 실시간 데이터입니다. Sorted Set으로 게임 리더보드, List로 메시지 큐, Hash로 장바구니 같은 빠른 읽기/쓰기가 필요한 경우에 씁니다.
Redis는 단일 스레드 모델이라 원자적 연산이 보장되지만 메모리 용량 제한이 있어서 적절한 데이터 선별이 중요합니다.”
5. “데이터베이스 인덱스 설계 시 고려사항은 무엇인가요?”
면접관의 핵심 의도:
- 인덱스에 대한 깊이 있는 이해 확인
- 성능 최적화 실무 경험 평가
- 비용 대비 효과 판단 능력 측정
구두 답변 (40초): “세 가지를 주로 고려합니다.
첫째, 선택도입니다. 고유값이 많은 컬럼일수록 B-Tree 인덱스 효과가 높습니다. 성별처럼 값이 2개뿐인 컬럼은 인덱스가 별로 도움이 안 되죠.
둘째, 사용 빈도입니다. WHERE, JOIN, ORDER BY에서 자주 쓰이는 컬럼을 우선으로 하고, 실행계획에서 실제 index seek 비율을 확인합니다.
셋째, 복합 인덱스 순서입니다. 카디널리티가 높은 컬럼을 앞에 둬야 효과적이고, 커버링 인덱스로 설계하면 키 룩업 없이 인덱스만으로 결과를 얻을 수 있어요.
주의할 점은 인덱스가 너무 많으면 INSERT, UPDATE 시 페이지 분할이 빈번해져 성능이 떨어진다는 것입니다. 그래서 정기적으로 사용률을 체크해서 안 쓰는 인덱스는 제거해야 합니다.”
6. “백업 전략을 어떻게 수립하시겠습니까?”
면접관의 핵심 의도:
- 데이터 보호 책임감과 전략적 사고 확인
- RTO/RPO 개념 이해도 측정
- 재해 복구 계획 수립 경험 평가
구두 답변 (40초): “먼저 업무 중요도에 따라 복구 목표 시간을 정합니다.
백업은 3단계로 나눠서 합니다. 주말에 전체 백업, 평일에는 변경된 부분만 백업, 그리고 실시간으로 변경 로그를 15분마다 백업하죠. 이렇게 하면 최대 15분 전 상태로 복구할 수 있습니다.
저장은 3곳에 합니다. 서버 로컬에 하나, 별도 저장장치에 하나, 그리고 다른 지역 클라우드에 하나씩 보관해요. 혹시 화재나 자연재해가 있어도 안전하죠.
가장 중요한 건 테스트입니다. 매달 한 번씩 실제로 백업에서 복구해보는 연습을 합니다. 막상 장애가 나면 백업이 깨져있거나 복구 방법을 몰라서 당황하는 경우가 많거든요.
실제로 작년에 서버 장애가 났을 때 이 백업 덕분에 30분 만에 서비스를 복구할 수 있었습니다.”
7. “클라우드 데이터베이스와 온프레미스의 차이는 무엇인가요?”
면접관의 핵심 의도:
- 최신 기술 트렌드 이해도 확인
- 클라우드 환경 적응 능력 평가
- 비용과 성능 최적화 관점 측정
구두 답변 (40초): “각각 장단점이 다릅니다.
클라우드는 확장성이 좋고 관리가 편합니다. Auto Scaling으로 트래픽에 따라 자동 확장되고, RDS나 Aurora 같은 매니지드 서비스로 패치나 백업이 자동화되죠. Pay-as-you-use 모델로 초기 투자 부담도 적습니다.
온프레미스는 완전한 통제가 가능하고 보안이 엄격합니다. 네트워크 레이턴시가 일정하고, 하드웨어나 커널 파라미터를 직접 튜닝할 수 있어요. CAPEX 모델로 예측 가능한 고정 비용 구조를 가집니다.
실무에서는 미션 크리티컬한 OLTP 시스템은 온프레미스에, 개발환경이나 분석 워크로드는 클라우드에 두는 하이브리드 방식을 많이 사용합니다.”
8. “NoSQL의 CAP 정리에 대해 설명해보세요”
면접관의 핵심 의도:
- NoSQL 이론적 배경 이해도 확인
- 분산 시스템 개념 숙지 정도 평가
- 기술 선택 시 고려사항 이해도 측정
구두 답변 (35초): “CAP 정리는 분산 시스템에서 세 가지 중 두 개만 보장할 수 있다는 이론입니다.
C는 일관성(Consistency)으로 모든 노드가 같은 데이터를 보는 것이고, A는 가용성(Availability)으로 시스템이 항상 응답하는 것입니다. P는 분할 내성(Partition Tolerance)으로 네트워크 장애에도 동작하는 것이죠.
MongoDB는 CP를 선택해서 Primary-Secondary 구조로 강한 일관성을 보장하지만 네트워크 문제 시 Secondary가 읽기 전용이 됩니다. Cassandra는 AP를 선택해서 Multi-Master로 높은 가용성을 제공하지만 최종 일관성(Eventual Consistency) 모델을 사용해요.
실제로는 PACELC 정리로 확장해서, 네트워크 파티션이 없을 때도 레이턴시와 일관성 간의 트레이드오프를 고려합니다.”
9. “데이터베이스 격리 수준에 대해 설명해보세요”
면접관의 핵심 의도:
- 동시성 제어 개념 이해도 확인
- 트랜잭션 격리에 대한 실무 지식 평가
- 성능과 일관성 트레이드오프 이해도 측정
구두 답변 (40초): “격리 수준은 동시 실행되는 트랜잭션들의 간섭 정도를 조절합니다.
네 단계가 있는데, READ UNCOMMITTED는 커밋 안 된 데이터도 읽어서 더티 리드(Dirty Read)가 발생할 수 있습니다. READ COMMITTED는 커밋된 데이터만 읽는 게 일반적인 기본값이고, 공유 락(Shared Lock)을 사용해요.
REPEATABLE READ는 같은 데이터를 반복 읽을 때 일관성을 보장하고 넌리피터블 리드를 방지하지만, 팬텀 리드는 발생할 수 있습니다. SERIALIZABLE은 Range Lock으로 가장 엄격하지만 동시성이 가장 떨어집니다.
실무에서는 대부분 READ COMMITTED를 사용하고, 금융 시스템처럼 정합성이 중요하면 SERIALIZABLE을, 리포팅처럼 성능이 중요하면 더 낮은 수준을 선택합니다.”
10. “마이크로서비스에서 데이터베이스 설계는 어떻게 하나요?”
면접관의 핵심 의도:
- 최신 아키텍처 트렌드 이해도 확인
- 분산 시스템 설계 경험 평가
- 데이터 일관성과 성능 균형 감각 측정
구두 답변 (45초): “마이크로서비스에서는 Database per Service 패턴을 사용합니다.
각 서비스가 독립적인 데이터베이스를 가지고, 서비스 간 데이터 공유는 API를 통해서만 합니다. 이렇게 하면 Bounded Context에 맞는 최적의 데이터베이스를 선택할 수 있어요.
예를 들어 주문 서비스는 MySQL로 ACID 트랜잭션을 보장하고, 추천 서비스는 Neo4j로 그래프 분석을 하고, 세션 관리는 Redis를 쓸 수 있습니다.
문제는 분산 트랜잭션인데, 2PC(Two-Phase Commit) 대신 Saga 패턴이나 Event Sourcing으로 해결합니다. CQRS(Command Query Responsibility Segregation)와 함께 최종 일관성(Eventual Consistency)을 받아들이는 게 핵심이죠.
실무에서는 각 서비스의 읽기/쓰기 패턴과 확장성 요구사항을 분석해서 가장 적합한 데이터베이스를 선택하는 게 중요합니다.”
“Cassandra의 Consistency Level은 무엇인가요?” → “읽기/쓰기 시 몇 개 레플리카에서 응답받을지 정하는 설정으로, ONE/QUORUM/ALL 등이 있습니다.”
성공적인 DBA 면접을 위한 마지막 팁!
면접에서는 단순한 암기보다는 ‘왜 그렇게 동작하는지’에 대한 이해와 실무 경험을 바탕으로 한 구체적인 사례를 들어 설명하는 것이 중요합니다. 그리고 항상 비즈니스 관점에서 기술적 결정이 어떤 가치를 만들어내는지 설명할 수 있어야 합니다.
면접 답변 시 주의사항:
- 길게 설명하지 말고 핵심만 간결하게
- 실무 경험이나 구체적인 수치를 포함
- 기술적 한계나 트레이드오프도 언급
- “모릅니다”보다는 “경험은 없지만 이렇게 접근하겠습니다”
여러분 모두 좋은 결과 있으시길 바라며, 이상의 내용으로 DBA 채용 면접 시 잘 참고해보시길 추천드립니다. 🙂