더 큰 문제는 검증 시점입니다. Rolling Update는 배포가 시작되자마자 신규 트래픽의 일부가 곧바로 새 버전으로 갑니다. ‘먼저 10분 동안 새 버전을 관찰한 다음 괜찮으면 트래픽을 보낸다’는 개념이 아예 없습니다. 롤백을 결정할 즈음에는 사용자 일부는 이미 문제 버전을 경험한 뒤입니다.

그리고 롤백 자체도 빠르지 않습니다. 3장에서 kubectl rollout undo 명령을 썼을 때를 떠올려 보면, 이전 ReplicaSet을 다시 띄우고 새 ReplicaSet을 내리는 그 과정도 결국 또 한 번의 Rolling Update입니다. ‘잘못됐으니까 되돌려’라고 외친 시점부터 실제로 트래픽이 기존 버전으로 완전히 돌아오기까지 수십 초가 걸립니다. 그사이에 문제는 계속되고 있습니다.

5장에서 Blue/Green으로 넘어가는 이유는 바로 이 두 가지입니다. 첫째, 새 버전을 완전히 띄운 다음 원하는 만큼 확인하고 나서 트래픽을 한 번에 전환한다는 것. 둘째, 문제 발견 시 기존 버전으로 즉시 돌려놓을 수 있다는 것(기존 버전 Pod가 Green 전환 직후까지 그대로 떠 있기 때문입니다). 이 두 가지 성질을 얻으려면 ‘트래픽을 어디로 보낼지’를 유연하게 바꿀 수 있어야 하고, 그래서 외부 진입점부터 고쳐야 합니다.