카카오톡은 왜 롤백이 어렵다고 했는지 수많은 생각에 대한 정리이다. 한마디로, 사실과는 무관한 뇌피셜이다.
나중에, 혹시나 이유가 공개되거나 한다면, 어떤 부분이 틀렸는지 맞았는지 알아보면 재밌을 것 같다.
또한, 나라면 어떻게 해결해야 할지 생각해보면, 조금은 성장하는데 도움이 될 것이다.
사실 뭐 돈과 관련된 것이겠지만, 그게 물질적이든 기회비용이든... 다른 개발자들과 대화하고 든 생각들을 정리해본다.
1. 변경된 카카오톡 화면에서 제공하는 광고 계약 해지 문제
변경된 카카오톡에서 광고 수익 비즈니스 모델을 구성했고, 관계자는 변경된 카카오톡에 미래를 보고 광고 계약을 했기 때문에, 해지 문제로 롤백을 할 수 없는 경우이다.
계약 문제와 신뢰 문제로 불가능하다고 판단 했을 경우이다.
2. 직책의 권한 문제
청문회 정도 되면, 말의 무게가 굉장히 무거운 장소이다.
"롤백 할 수 있나요?" 라는 질문에, "(기술적으로) 가능하긴 한데..." 라는 말을 하면, "할 수 있는데 왜 안해요?" 라는 꼬리 질문으로 갈 가능 성이 높다.
그러다보니, 가능하더라도, "어렵다"라고 말할 가능성이 있다.
또한, 직책상 롤백이라는 권한이 없거나, 그 파급력을 알 수 없어서 현장에서는 말을 아꼈을 가능성이다.
3. 마이그레이션 문제
카카오톡 정도 되는 초거대 실시간 시스템에서는 카카오톡이 데이터를 보관하는 시점부터 수많은 데이터가 쌓여 있을 것이다.
새로운 버전은 사실상 카카오톡2.0 처럼 백단(서버, 코어기능)이 대폭 변경되었을 가능성이 높다. 새로운 버전에 맞추어 데이터를 옮겨야 하는데, 데이터가 많기 때문에 어쩌면 지금도 옮기는 코드가 동작하고 있을 수 있다.
그러다 보니, 다시 기존 버전으로 내리기 위해서, 업데이트 이후에 쌓인 데이터를 다시 마이그레이션 해야하는 상황이라면, 서로가 서로를 데이터를 채워야 하는 이상한 구조가 나온다.
4. 비가역 데이터가 생긴 경우
카카오톡을 새로운 시스템으로 변경하면서, 기존 DB에서 비효율적이거나, 필요없는 데이터를 지우면서, 새로운 시스템을 채워 나갔을 수 있다. 이 경우, 새로운 데이터는 새로운 모델에 맞추어 데이터를 적재했을 가능성이 있는데, 기존 시스템을 A, 새로운 시스템을 B라고 했을 때, A -> B로는 가능하지만, B -> A로는 불가능한 경우일 수 있다.
이 경우, 롤백은 고려하지 않았을 가능성이 높다.
5. 롤백을 하려면, 서비스를 정지해야하는 경우
롤백을 하기 위해서, 카카오톡 서비스를 꺼야하는 경우이다. 이 경우, 사실상 카카오톡을 사용할 수 없는 것이 되기 때문에, 과거 데이터 센터 화재 사건이랑 동일한 상황이 되는 것이나 다름없다. 이 경우, 비즈니스적 비용 손실과 사용자들의 불편은 우주를 뚫을 수 있다.
6. 점진적 복구를 해야하는 경우
새로운 시스템을 한번에 완성 시킨 것이 아닐 것이기 때문에, 새로운 시스템을 바로 없애는 것은 불가능 하지만, 점진적으로 하나씩 걷어내는 것만이 가능할 때이다.
말 그대로, 점진적으로 걷어내야 하기 때문에, 수많은 인력이 다른 작업 없이, 기존 시스템으로 되돌리는데 집중할 것이고, 새로운 시스템을 만들어낸 것 만큼 혹은 그 이상 시간이 투입될 것이다.
7. 비즈니스 적으로 강제 업데이트가 불가능 한 경우
카카오톡은 초거대 실시간 서비스이다. 늦게 전송되는 것도 사용자의 UX를 나쁘게 만들정도로 고도의 실시간성을 요구하며, 긴급하게 사용될 가능성도 높다.
만약, 카카오톡이 롤백을 했다고 가정했을 때, 원활한 동작을 위해 모든 사용자의 휴대폰에 강제 업데이트를 진행했다고 가정했을 때, 긴급하게 사용해야하는 상황에서 방해가 될 가능성이 있다.
8. 커뮤니케이션 리스크
롤백을 한다 라는 결정은, 기업 내부적으로 프로젝트를 실패했다라는 메시지로 남을 수 있다.
정리
정리해보자면, 사실 전부 비용, 기회비용, 책임, 기술적 문제에 초점이 맞춰져 있다.
순수 궁금증으로, 관계자와 대화해보고 싶다...
| 계약/신뢰 | 외부 API, 정산, SDK 호환성 문제 |
| 권한 | 의사결정 구조 분산 |
| 마이그레이션 | 데이터 정합성 / 순서 일관성 / 해시 충돌 / 비가역 데이터 |
| 서비스 중단 | 클라이언트 버전 불일치 |
| 점진 복구 | 모듈 의존성의 그물망화 |
| 강제 업데이트 | 스토어 승인 지연 |
| 기타 | 조직 신뢰·커뮤니케이션 리스크 |
'IT' 카테고리의 다른 글
| [백엔드] output json을 신경써서 만들어야 하는 이유(안티패턴) (0) | 2025.11.12 |
|---|---|
| [Azure] 클라우드를 몰랐던 스타트업 개발자의 실수 (0) | 2025.10.31 |
| [LLM] 모든 모델을 쓰고 싶은 라이트 유저들의 플랫폼(T3 chat) (0) | 2025.09.07 |
| [Python] .get을 써야 하는 가? 인덱싱(subscription)을 써야 하는 가? (0) | 2025.07.30 |
| [PostgreSQL] Numeric type에 NaN이 들어가는 환장의 콜라보 (0) | 2025.07.18 |