최종적 일관성

"저장했는데 안 보여요"

사용자가 프로필 사진을 바꿉니다. "저장 완료"가 뜹니다. 그런데 새로고침하니 옛날 사진이 그대로 있습니다. 다시 새로고침하니 이번엔 새 사진이 나옵니다.

사용자는 확신합니다. "이 서비스 고장 났네."

버그가 아닙니다. 복제가 정상 작동한 결과입니다. 그리고 이 현상을 이해하지 못하면 절대 고칠 수 없습니다.

무슨 일이 일어났나

0ms   사진 저장 요청 → 원본에 기록 → "완료!" 응답
10ms  사용자가 새로고침 → 사본을 읽음 → 아직 옛날 사진 ❌
80ms  원본의 변경이 사본에 도착
200ms 사용자가 다시 새로고침 → 사본을 읽음 → 새 사진 ✓

원본에 적힌 내용이 사본에 도착하기까지 이 예에서는 80밀리초가 걸렸습니다. 사용자는 하필 그 사이에 읽었습니다. 이걸 오래된 읽기(stale read)라고 합니다.

왜 시간이 걸릴까요. 사본이 다른 기계에 있기 때문입니다. 전기 신호가 케이블을 타고 가는 데에도 시간이 듭니다. 지연을 0으로 만드는 건 물리적으로 불가능합니다.

"최종적으로는 일치한다"

이 상태를 최종적 일관성(eventual consistency)이라고 부릅니다. 이름이 하는 약속을 정확히 읽어야 합니다.

약속하는 것: 더 이상 새로운 변경이 없다면, 언젠가는 모든 사본이 같은 값을 갖게 된다. 약속하지 않는 것: 그 '언젠가'가 언제인지. 그리고 그때까지 여러분이 무엇을 볼지.

두 번째 줄이 핵심입니다. 이 약속은 놀랍도록 약합니다. "결국엔 맞춰집니다"는 "지금 화면에 뭐가 보일지는 모릅니다"와 같은 말입니다.

더 이상한 일도 생깁니다. 사본이 여러 개면 어느 사본을 읽느냐에 따라 답이 다릅니다. 새로고침을 누를 때마다 새 사진과 옛 사진이 번갈아 나올 수 있습니다. 이걸 시간이 거꾸로 가는 읽기라고 부릅니다. 사용자에게는 유령이 나오는 것처럼 보입니다.

그런데 왜 이걸 견디는가

대안이 있긴 합니다. 원본이 모든 사본이 다 받았다고 확인할 때까지 응답을 미루는 것입니다. 그러면 지연이 사라집니다. 대신

• 쓰기가 가장 느린 사본만큼 느려집니다.
• 사본 하나가 죽으면 쓰기 전체가 멈춥니다.

즉 안전을 얻는 대가로 속도와 가용성을 냅니다. 그리고 대부분의 데이터에서는 이 거래가 손해입니다. 프로필 사진이 0.1초 늦게 보이는 것과, 사본 하나가 죽어서 서비스 전체가 멈추는 것 중 무엇이 더 나쁜가요.

그래서 화면마다 다르게 판단한다

"전부 최신"도 "전부 사본"도 답이 아닙니다. 화면마다 묻습니다.

아래 세 줄에는 공통점이 있습니다. 본인이 방금 바꾼 것을 본인이 확인하는 상황입니다. 남의 변경이 늦게 보이는 건 알아채지 못하지만, 내 변경이 안 보이면 즉시 알아챕니다.

이 요구에는 이름이 있습니다. "자기가 쓴 것 읽기(read-your-writes)"입니다. 가장 흔한 해법은 단순합니다.

무언가를 쓴 직후 몇 초 동안, 그 사용자의 읽기는 원본으로 보낸다.

전체 트래픽에서 이런 요청은 극소수라 원본에 부담이 거의 없습니다. 나머지 압도적 다수의 조회는 계속 사본이 처리합니다. 좁게 예외를 두는 것이지, 포기하는 게 아닙니다.

정리

복제 지연은 없앨 수 있는 버그가 아니라 관리해야 할 성질입니다. 설계자가 할 일은 지연을 0으로 만드는 게 아니라, 어느 화면이 지연을 견디지 못하는지 골라내는 것입니다. 그 화면만 원본으로 보내면 됩니다.

아래 과제에서 원본만 바라보다 무너지는 시스템을 사본으로 살리되, 최신이어야 하는 화면은 남겨 두는 판단을 직접 해보세요.