비교 포인트

같은 분산 환경에서도 "쓰기 권한을 어디에 두느냐"가 구조를 갈라놓습니다.

두 지역에서 모두 서비스를 운영한다고 가정하면, Master-Slave는 쓰기 지점을 하나로 고정해 충돌을 막고, Multi-Master는 양쪽에서 쓰기를 받아 가용성과 확장성을 얻는 대신 충돌 해결 책임을 가져갑니다.

공통 상황
두 지역이 같은 데이터를 함께 서비스 읽기는 가까운 곳에서 처리하고, 장애에도 멈추지 않게 만들고 싶습니다.
선택 1
쓰기 권한을 한 곳에 집중 일관성은 단순하지만, 전환 시 승격 절차가 필요합니다.
선택 2
양쪽에서 모두 쓰기 허용 즉시 전환은 쉬워지지만, 같은 row 동시 수정 충돌이 생깁니다.
비교 축
Master-Slave
Multi-Master
쓰기 처리
Master 한 곳만 write
Slave는 read 중심 충돌 거의 없음

쓰기 순서가 한 노드로 모여서 운영 모델이 단순합니다.

각 master가 직접 write
쓰기 확장 가능 지역별 write 가능

지연이 줄고 쓰기 지점이 늘어나지만, 동일 데이터 갱신 충돌을 감수해야 합니다.

장애 대응
Failover 후에 다시 write
Slave 승격

대체 경로는 있지만 승격과 라우팅 전환이 필요해 순간 공백이 생길 수 있습니다.

남은 master가 계속 write
즉시 전환

한쪽 장애에도 다른 master가 바로 쓰기를 받기 쉬워 가용성이 높습니다.

운영 대가
구조는 단순, 확장은 제한

대부분의 시스템에서 채택하기 쉽지만, write 병목은 남습니다.

복잡도 증가, 정책 필수
충돌 해결 정합성 설계

Last Write Wins, 우선순위, 애플리케이션 merge 같은 규칙을 먼저 정해야 안전합니다.

핵심 결론

Multi-Master는 "쓰기 확장성과 즉시 가용성"을 얻는 대신, "충돌 해결과 운영 복잡도"를 시스템 설계로 감당해야 합니다.