손님 태블릿부터 배포 파이프라인까지,
혼자 설계하고 만든 주문 시스템

원인

발행 스크립트가 실행 번들의 asset key를 매번 같은 상수로 보내고 있었다. 단말 쪽 업데이트 라이브러리는 이 key로 디스크 파일명을 만든다. 즉 모든 번들이 디스크에서 같은 파일명을 차지했다. 새 번들을 받을 때 라이브러리는 '그 key의 파일이 이미 디스크에 있다'는 이유로 해시를 비교하지도 않고 다운로드를 건너뛰었다. 그래서 DB의 업데이트 레코드만 새것으로 갱신되고, 실제 실행되는 번들 파일은 옛것 그대로 남았다.

남은 것

라이브러리가 '값'이 아니라 '식별자'로 캐시를 판단하는 지점을 놓치면, 상위 레이어의 모든 지표가 정상이라고 말한다. 서버 로그도, DB도, 단말이 보고하는 버전도 전부 맞았고 오직 화면만 틀렸다. 원인을 찾은 건 라이브러리 소스에서 파일명을 만드는 함수를 직접 읽고 나서였다.

원인

네이티브 백그라운드 서비스의 초기화 함수가 '이미 연결되어 있으면 아무것도 하지 않고 빠져나가는' 구조였다. 재등록으로 구독할 토픽 목록은 새 매장 것으로 갱신됐지만, 연결이 살아 있다는 이유로 재구독 자체를 건너뛰었다. 결과적으로 앱이 알고 있는 토픽과 브로커에 실제로 걸린 구독이 어긋났다.

남은 것

'이미 되어 있으면 넘어간다'는 최적화는 설정이 절대 변하지 않는다는 가정 위에 서 있다. 단말이 매장을 옮겨 다니는 순간 그 가정이 깨졌다. 그리고 급한 불은 배포가 빠른 레이어에서 먼저 끄고, 근본 수정은 배포 비용이 큰 레이어에서 따로 했다.

원인

새 렌더링 아키텍처로 올린 상태에서, 아직 그 아키텍처를 지원하지 않는 이미지 라이브러리를 쓰고 있었다. 미지원 조합은 예외를 던지지 않고 그냥 그리지 않는다. 실패가 조용해서 '가끔 안 나온다'로만 보였다.

남은 것

런타임 아키텍처를 바꾸는 마이그레이션에서는 '에러가 안 난다'가 정상 동작의 증거가 되지 못한다. 이후로는 화면 라이브러리를 올릴 때 지원 여부를 먼저 확인하고 넘어간다.

원인

카드 컴포넌트에 메모이제이션을 걸어뒀지만, 부모가 콜백을 인라인 함수로 내려주고 있었다. 렌더마다 새 함수 참조가 만들어지니 메모이제이션이 통째로 무효가 됐고, 카드 하나를 누를 때마다 화면의 카드 전부가 다시 렌더됐다.

남은 것

메모이제이션은 단독으로는 아무것도 보장하지 않는다. props 참조를 안정화하는 쪽과 항상 한 세트로 다뤄야 하고, 둘 중 하나만 하면 '건 것 같은데 안 듣는' 상태가 된다.