6~7월의 React Native 생태계를 보고 있으면, 새 API가 쏟아진다기보다 ‘현장에서 덜 흔들리게 만드는’ 쪽으로 무게가 옮겨간 느낌이다. 요즘 PDA 앱을 자주 만들다 보니 성능이라는 말도 벤치마크 숫자보다 스캔 후 화면이 멈추지 않는지, 키보드와 하단 버튼이 겹치지 않는지, 장애를 재현할 수 있는지로 먼저 보게 된다.
6월 11일 React Native 0.86이 나왔고, 7월 1일 Expo SDK 57이 이를 받아왔다. 여기에 Expo MCP와 테스트·관측 도구 흐름까지 붙으면서, 이번 업데이트의 핵심은 렌더링·네이티브 경계·AI 개발 보조를 따로 보지 않게 됐다는 점이라고 생각한다.
현장 단말 앱에서는 ‘새 기능’보다 이미 있는 기능이 흔들리지 않는 편이 훨씬 큰 성능 개선이다.
연관 글
요약
- React Native 0.86은 Android 15+ edge-to-edge, 키보드·좌표·모달 관련 수정과 DevTools 색상 모드 에뮬레이션을 담았다.
- Expo SDK 57은 React Native 0.86을 가져오되, ‘무중단’이라는 표현만 믿고 바로 올리기보다 PDA 실기기 흐름을 확인할 이유도 남겼다.
- Expo MCP는 AI가 문서 검색만 하는 수준을 넘어 빌드·로그·로컬 화면 확인까지 돕는 방향을 보여준다.
- WatermelonDB는 이번 변화의 주인공은 아니지만, 오프라인 스캔 데이터와 동기화가 많은 앱에서는 여전히 설계 단계에서 떠올릴 만한 선택지다.
목차
이 글에서 다루는 내용
PDA에서 성능을 다시 보게 되는 순간
일반 스마트폰에서는 지나갈 수 있는 UI 문제가 PDA에서는 바로 업무 중단처럼 느껴진다. 바코드 스캔 뒤 목록이 갱신되는 타이밍, 숫자 키패드가 올라온 상태에서 수량 입력 버튼이 남아 있는지, 복귀했을 때 백 버튼 이벤트가 살아 있는지 같은 것들이다. 네트워크가 고르지 않은 창고·매장 환경이라면 더 그렇다.
그래서 최근 생태계 변화가 반갑다. New Architecture와 Hermes V1은 이미 큰 전환을 지나왔고, 0.86에서는 Android edge-to-edge·키보드·레이아웃·애니메이션의 자잘하지만 현실적인 틈을 메우는 수정이 많았다. 성능을 ‘더 빠르게’가 아니라 업무 흐름을 깨지 않게 보는 쪽에 가깝다.
React Native 0.86: Android 화면 가장자리와 디버깅
React Native 0.86은 공식적으로 사용자 코드 기준의 breaking change가 없는 릴리스다. Android 15+에서 OS가 edge-to-edge를 강제하는 경우에도 measureInWindow 좌표, KeyboardAvoidingView, Dimensions, 모달 중 StatusBar 처리를 보완했다.
PDA 앱에서 이 변화가 특히 눈에 들어오는 이유는 화면 하단의 고정 액션 영역과 입력 UI 때문이다. 단말별 내비게이션 바, 소프트 키보드, 제조사 키보드가 얽히면 ‘내 폰에서는 맞았는데 현장에서는 버튼이 가려지는’ 문제가 생긴다. 이번 수정이 모든 단말 차이를 없애는 것은 아니지만, 업그레이드 후보라면 스캔 화면·수량 입력·모달을 우선 회귀 테스트할 근거가 생겼다.
DevTools에는 light/dark mode 에뮬레이션도 추가됐다. 단말 설정을 계속 바꾸지 않고도 화면 모드를 확인할 수 있어, 현장에서 밝은 테마만 고집하다 놓치기 쉬운 대비 문제를 빨리 볼 수 있다. JSI에는 TypedArray, ArrayBuffer 관련 API도 추가됐다. 바이너리·네이티브 모듈을 직접 다루는 라이브러리에는 기반이 넓어진 변화지만, 앱 전체가 자동으로 빨라진다는 뜻은 아니다.
Expo SDK 57과 AI 개발도구가 바꾸는 흐름
7월 1일 나온 Expo SDK 57은 React Native 0.86을 포함한다. Expo는 0.85→0.86 사이에 601개 커밋과 1,552개 파일 변경이 있다고 짚으면서도, 더 가벼운 선택형 업그레이드 주기를 시험하고 있다. “breaking change 없음”은 좋은 신호지만 PDA 프로젝트에서는 곧바로 배포한다는 의미로 읽으면 위험하다. 네이티브 SDK, 스캐너 서비스, MDM 정책이 함께 움직이기 때문이다.
AI 쪽에서는 Expo MCP Server가 무료 플랜에도 열렸다. AI 코딩 도구가 Expo 문서만 읽는 것이 아니라 EAS 빌드·워크플로 로그·실패 원인, 로컬 에뮬레이터 화면과 로그까지 연결할 수 있다는 방향이다. 다만 도구가 로그를 읽어도 실제 단말의 스캐너 포커스나 절전 복귀는 대신 확인해주지 못한다. 저는 AI에게 변경 후보와 로그 정리를 맡기고, 마지막 승인 기준은 실기기 업무 시나리오에 남기는 방식이 맞다고 본다.
WatermelonDB는 이번 변화에서 어디에 놓이나
WatermelonDB는 6~7월 업데이트의 메인 뉴스는 아니다. 그래도 오프라인에서 스캔 결과를 쌓아두고, 연결이 돌아왔을 때 서버와 맞춰야 하는 PDA 앱을 생각하면 자연스럽게 다시 떠오른다. SQLite 위에 모델·쿼리·반응형 갱신·동기화의 구조를 얹기 때문이다.
다만 로컬 DB를 넣는다고 성능 문제가 해결되지는 않는다. 화면에 한 번에 올리는 데이터 양, 스캔 이벤트의 중복 처리, 동기화 충돌 규칙, 마이그레이션이 더 먼저 정리돼야 한다. 단순 캐시라면 과할 수 있고, 오프라인 작업 큐와 관계형 데이터가 커질 때 검토하는 편이 현실적이다.
이번 달에 확인할 것
| 영역 | PDA 프로젝트에서 먼저 볼 장면 |
|---|---|
| 0.86 업그레이드 | Android 15+ edge-to-edge, 키보드가 올라온 수량 입력, 모달·하단 버튼, 백 버튼 복귀 |
| 성능 | 스캔 직후 목록 갱신, 대량 항목 스크롤, 앱 복귀 후 이벤트 중복 여부 |
| AI 보조 | 빌드 로그 분류와 문서 확인은 맡기되, 실단말 스캔·절전 복귀·네트워크 단절은 사람이 확인 |
| 로컬 데이터 | 오프라인 큐·재전송·충돌 규칙을 먼저 정의한 뒤 WatermelonDB 같은 계층을 판단 |
마무리
이번 React Native 생태계의 변화는 화려한 기능 발표보다 개발의 마찰을 줄이는 쪽에 가깝다. Hermes V1과 New Architecture의 큰 전환 뒤에, 0.86은 화면 가장자리와 디버깅을 다듬었고 Expo는 업그레이드와 AI 작업 흐름을 더 가까이 가져왔다.
PDA 개발을 하다 보면 결국 중요한 것은 배포 노트의 문구보다 다음 교대조에서도 스캔과 입력이 끊기지 않는지다. 그래서 이번 달에는 최신 버전을 무조건 따라가기보다, 현장 흐름에 맞는 짧은 회귀 시나리오를 먼저 돌려보는 것부터 해보려 한다.
후속
- React Native PDA 앱에서 오프라인 동기화와 재전송을 설계할 때 보는 기준 — 작성중
참고 자료
확인일: 2026년 7월 11일. React Native·Expo 버전과 단말 제조사 SDK 조합은 프로젝트마다 달라, 실제 배포 전에는 보유 PDA에서 별도 검증이 필요하다.