이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 운영 중인 테이블에 컬럼을 추가하는 마이그레이션을 처음 진행했습니다. 가장 어려웠던 건 기존 데이터가 있는 상태에서 NOT NULL 컬럼을 추가할 때 기본값 처리를 어떻게 할지였습니다. 처음엔 ALTER TABLE을 그냥 실행했다가 락이 걸려서 다른 쿼리가 막히는 문제를 경험했습니다. 이후에는 컬럼을 먼저 NULL 허용으로 추가하고, 기존 데이터를 배치로 채운 뒤 NOT NULL로 바꾸는 단계적 방식을 배웠습니다. 정합 검증에서는 마이그레이션 전후에 행 수와 집계값이 동일한지 확인하는 쿼리를 미리 준비해뒀습니다. 롤백 시나리오도 미리 짜두는 게 중요한데, 되돌릴 수 있는 방법을 먼저 설계하고 진행 여부를 결정하는 습관이 생겼습니다.
DB 마이그레이션은 코드 변경보다 순서가 더 중요한 자리라는 걸 그때 배웠습니다.
DB 마이그레이션에서 가장 두려운 순간은 운영 DB에 처음 스크립트를 실행하는 순간이었습니다. 스테이징에서 잘 됐어도 데이터 규모와 트랜잭션 패턴이 달라 운영에서 다르게 동작하는 경우가 있었습니다.
이후엔 BEGIN~ROLLBACK으로 드라이런을 먼저 실행해 어떤 행이 영향을 받는지, 실행 시간이 얼마나 되는지를 확인한 뒤 COMMIT하는 방식을 정착시켰습니다. 영향 행 수와 예상 시간을 로그로 남기고 팀과 공유한 뒤 실행 여부를 결정했습니다.
이 경험으로 마이그레이션 스크립트는 실행 전에 "얼마나 영향을 주는가"를 먼저 확인하는 단계가 스크립트만큼 중요하다는 걸 배웠습니다.
DB 마이그레이션 이후 데이터가 정상인지 확인하는 것이 마이그레이션만큼 중요하다는 걸 경험했습니다. 스키마 변경이 성공했어도 데이터 변환 과정에서 일부 행이 기대한 값과 달라진 경우가 있었습니다.
이후엔 마이그레이션 전과 후의 COUNT·SUM·NULL 개수를 비교하는 검증 쿼리를 스크립트에 포함했습니다. 불일치가 감지되면 ROLLBACK 후 원인을 찾는 순서로 진행했습니다. "마이그레이션이 성공했다"는 것과 "데이터가 정상이다"는 별개라는 인식이 생겼습니다.
이 경험으로 마이그레이션 완료는 스크립트 실행이 아니라 검증 쿼리가 통과된 순간이라는 걸 직접 배웠습니다. 성공 메시지보다 검증 숫자가 먼저입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 핀다 DBA 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.