React Native CodePush(Hot Updater) 적용기

두려워서 시작했는데, 결국 적용해버린 이야기

프론트엔드 개발자로서 가장 무서운 순간이 언제일까.

• 배포 버튼을 누를 때
• 금요일 오후에 긴급 이슈가 터졌을 때
• 그리고 스토어 심사를 다시 기다려야 한다는 걸 깨달았을 때

영끌 앱을 운영하면서 이 모든 순간을 다 겪었다.
특히 모바일 앱은 웹과 달리 “한 번 나가면 바로 고치기 어렵다”는 점에서
항상 묘한 긴장감을 안고 있었다.

그러다 자연스럽게 이런 생각이 들었다.

“웹처럼, 조금 고치고 바로 반영할 수는 없을까?”

처음엔 Hot Updater가 아니었다

사실 처음부터 Hot Updater를 쓰려던 건 아니다. 비교적 단순한 revopush라는 서비스를 사용했다.

하지만 현실은 예상보다 빠르게 나를 때렸다.

• iOS 수정 → Android에서 문제 발생
• Android 수정 → iOS에서 다시 문제 발생

하루는 iOS가 멀쩡했고,
다음 날은 Android가 멀쩡했다.
둘 다 멀쩡한 날은 없었다.

그때 깨달았다.
문제를 해결하는 게 아니라 확률 게임에 가까웠다.

 

그래서 다시 마주한 Hot Updater

 

이전부터 알고는 있었지만 미뤄왔던 이녀석을
다시 꺼내 들었다.

솔직히 말하면 여전히 무서웠다.

• 잘못 배포하면 모든 유저에게 동시에 영향
• 플랫폼별 미묘한 차이

하지만 한 가지는 분명해졌다.

지금 방식이 더 위험하다.

핫 업데이트가 무서운 게 아니라,
통제할 수 없는 배포가 무서운 거였다.

그래서 CodePush를 “편의 기능”이 아니라
통제 가능한 배포 수단으로 설계하기로 했다.

 

적용하면서 가장 신경 쓴 것들

 

1. 핫 업데이트의 범위를 명확히 정하기

모든 걸 CodePush로 해결하려는 순간 사고가 난다.

• UI 수정
• 텍스트 변경
• 경미한 비즈니스 로직 수정

이 정도까지만 허용했다.
네이티브 영역이나 구조 변경은 절대 금지.

웹처럼 쓰되, 웹처럼 믿지는 말자.

 

2. 플랫폼별 분리와 롤백 전략

이전의 가장 큰 문제는
iOS와 Android를 한 번에 묶어버린 것이었다.

• 플랫폼별 배포 분리
• 항상 이전 안정 버전 유지
• 문제 발생 시 즉시 롤백 가능하도록 설계

이때 처음으로
프론트엔드도 배포 전략을 설계해야 한다는 걸 실감했다.

 

3. 운영 관점에서의 안정화

 

CodePush를 “적용했다”로 끝내지 않았다.

• 플랫폼별 동작 차이 체크
• 업데이트 타이밍에 따른 UX 검증

 

적용하고 나서 달라진 것들

 

가장 큰 변화는 이거였다.

• 긴급 이슈 대응 속도
• CS 대응 시간
• 그리고 배포에 대한 두려움

스토어 재배포 없이
그날 안에 문제를 해결할 수 있다는 것은
운영하는 입장에서 엄청난 안정감을 줬다.

무엇보다 좋았던 건,

“프론트엔드가 단순 구현자가 아니라
서비스 운영의 한 축이 되었다”

 

라는 감각이었다.

 

마무리하며

 

CodePush는 여전히 조심스럽다.
지금도 배포할 때마다 한 번 더 확인한다.

하지만 분명한 건,

• 레포 푸시로 겪은 시행착오 덕분에
• 배포를 더 진지하게 고민하게 되었고
• 그 결과 CodePush를 제대로 설계할 수 있었다

 

두려웠지만,
그래서 더 공부했고
그래서 더 안전해졌다.

프론트엔드 개발자로서
“화면을 만드는 사람”을 넘어
“서비스를 안전하게 운영하는 사람”이 되게 만든 경험

그게 내 핫 업데이트 적용기다.