이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 PostgreSQL 마이그레이션 작업을 처음 지원했습니다. 가장 먼저 한 건 현재 스키마와 데이터를 전체 백업하고 마이그레이션 전후 상태를 비교할 수 있는 체크포인트를 만드는 것이었습니다. 실행 전에 스테이징 환경에서 먼저 동일 절차를 돌려보고 예상치 못한 외래키 제약 오류를 미리 발견했습니다. 운영 서버 적용은 트래픽이 낮은 시간대에 진행했고, healthcheck 엔드포인트로 서비스 응답을 자동으로 확인했습니다. 완료 후에는 주요 쿼리 응답 시간과 에러율을 30분간 집중 모니터링했습니다. 롤백 계획은 복원 절차와 예상 소요 시간을 미리 문서화해서, 문제가 생기면 팀이 즉시 실행할 수 있게 했습니다.
마이그레이션에서 가장 중요한 건 되돌아갈 수 있는 경로를 먼저 확보하는 것이라는 걸 배웠습니다.
대규모 테이블 스키마 변경이 필요한 상황에서 ALTER TABLE을 직접 실행하면 수십 분간 테이블이 잠기는 문제를 직접 겪었습니다. 이 경험 이후 온라인 DDL 도구를 찾아봤는데, gh-ost 같은 도구가 섀도우 테이블을 만들어 운영 중에 스키마를 변경하는 방식을 이해하게 됐습니다. 테이블 락 없이 변경할 수 있어서 서비스 중단 없이 스키마를 개선할 수 있다는 것이 인상적이었습니다. 블루-그린 배포 전략도 DB 업그레이드에 적용했는데, 기존 버전 DB와 새 버전 DB를 병렬로 운영하다가 리플리케이션으로 동기화를 맞추고 트래픽을 전환하는 방식이었습니다. 전환 직후 문제가 생기면 즉시 롤백할 수 있다는 것이 장점이었습니다.
롤백 계획을 테스트하는 것 자체가 마이그레이션 절차의 한 단계라는 것을 배웠습니다. 배포 계획서에 롤백 단계별 소요 시간까지 적어두는 습관이 생겼습니다.
DB 복구 절차를 공부하면서 논리 백업과 물리 백업의 차이를 체감하는 경험이 있었습니다. pg_dump로 만든 논리 백업은 복원 시간이 데이터 양에 비례해 길어지는 문제가 있었고, WAL 아카이빙을 통한 물리 백업은 복원 속도가 빠르지만 설정이 복잡하다는 트레이드오프를 이해했습니다. PITR(특정 시점 복구)은 실수로 데이터를 삭제했을 때 삭제 직전 시점으로 복구할 수 있는 기능인데, WAL 아카이빙이 켜져 있어야 가능하다는 것을 처음 알았습니다. RTO(복구 목표 시간)와 RPO(복구 목표 시점)라는 개념도 이때 이해했습니다. 얼마나 빠르게 복구할 수 있는지와 얼마나 오래된 데이터까지 잃을 수 있는지가 서로 다른 요구 사항이라는 것을 배웠습니다. 복구 절차를 문서화할 때 예상 RTO를 계산해서 적어두는 것도 이때 배웠습니다.
백업 설정을 갖추는 것보다 실제 복원 테스트를 주기적으로 돌려보는 것이 더 중요하다는 것을 이 경험에서 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 DBA 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.