백엔드 DB 복제 지연 해결, 읽기 쓰기 분리만 하면 기술면접에서 떨어지는 진짜 이유

by 그릿 | GROWTH_ESSAY | 2026-11-13

면접관이 DB 읽기 쓰기 분리(Read/Write Splitting)에서 확인하려는 것은 데이터소스 라우팅 설정 코드가 아닙니다. Primary와 Secondary 사이의 비동기 복제 지연(Replication Lag) 때문에 발생하는 데이터 불일치를 비즈니스 맥락에 맞게 해결했는지 검증하려는 것입니다. 단순히 읽기 부하를 분산했다고 적어두고 지연 문제를 대비하지 않았다면 기술면접을 통과하기 어렵습니다.

방금 작성한 게시글이 목록에서 안 보이면 어떻게 합니까?

200명 넘게 멘토링을 진행하면서 수많은 2~3년차 백엔드 개발자들의 이력서를 봅니다. Master-Slave 구조로 DB를 이중화해 조회 성능을 높였다는 서술이 흔하게 등장합니다. 제가 "사용자가 글을 등록하고 목록으로 이동했는데, 방금 쓴 글이 보이지 않는다는 장애가 접수되면 어떻게 대처하시나요?"라고 물으면 열에 아홉은 말문이 막힙니다.

관계형 데이터베이스의 기본 복제는 비동기 방식입니다. Primary에서 바이너리 로그를 기록하고 Secondary의 릴레이 로그로 넘어가 반영되기까지 수십 밀리초에서 수 초의 지연이 발생합니다. 이 복제 지연 시간을 고려하지 않은 분리는 사용자에게 데이터 유실이라는 불안을 줍니다.

모든 조회를 슬레이브로 보내는 게 최선입니까?

복제 지연을 방어하는 첫 번째 원칙은 비즈니스에 따른 데이터 정합성 수준을 분리하는 사유입니다.

글을 작성한 본인의 즉시 조회나 결제 직후의 주문 상태 확인처럼 정합성이 깨지면 치명적인 API는 Secondary가 아니라 Primary로 직접 라우팅해야 합니다. 반면 일반 검색이나 통계 대시보드처럼 약간의 지연이 허용되는 조작만 Secondary로 보냅니다. 사용자 세션 쿠키에 쓰기 시점의 타임스탬프를 심어 일정 시간 동안만 Primary 조회를 강제하는 기법도 유효한 실무적 대안입니다.

지연이 수십 초로 늘어나면 어떻게 감지하고 복구합니까?

Secondary에 긴 트랜잭션이 걸리거나 대량의 배치가 돌면 복제 지연은 걷잡을 수 없이 커집니다. 이때 시스템 상태를 감지하는 모니터링 체계를 갖추었는지가 면접관의 핵심 질문입니다.

단순히 SHOW SLAVE STATUS 수치에만 의존하면 릴레이 로그 전송 지연을 놓치기 쉽습니다. 하트비트 테이블을 두어 Primary 쓰기 시점과 Secondary 갱신 시점을 대조하는 정밀한 메트릭을 수집해야 합니다. 지연이 임계치를 넘으면 해당 인스턴스를 라우팅 풀에서 제외하는 헬스체크 설계가 필요합니다.

DB를 복제해 인프라를 늘리는 것은 쉽습니다. 인프라 확장 뒤에 필연적으로 따라오는 데이터 일관성의 균열을 코드로 방어하는 논리가 백엔드 개발자의 진짜 무기입니다. 지금 내 백엔드 설계와 커리어 방향이 올바른 궤도에 있는지 점검하고 싶다면 https://teamgrit.co/direction 에서 확인해보세요.