reactnative10 [Backend] 지명은 번역이 아니라 로마자로 — 고유명사 로마자 처리하기 앱을 영어로 내보내면서 UI 문구는 번역으로 해결했습니다. 그런데 곧 번역으로는 안 되는 게 나타났습니다. 바로 지명입니다. "다대포해변"을 뜻으로 번역하면 어떻게 될까요? 억지로 옮기면 이상한 영어가 됩니다. 고유명사는 번역 대상이 아니라 로마자 표기 대상이기 때문입니다. 이 글에서는 한국 서핑 스팟 38곳과 기상청 파고 부이 13곳을 국립국어원 표기법으로 로마자화한 과정을 정리합니다.이 글은 React Native 국제화기 시리즈의 2편입니다. 1편에서 번역 누락의 함정을 다뤘고, 이번 편은 고유명사 처리를, 다음 편은 데이터베이스에 저장된 콘텐츠의 다국어를 다룹니다.원칙 — 번역과 로마자는 다르다국제화를 하다 보면 모든 한글을 "번역"하려는 관성이 생깁니다. 그런데 이름에는 두 종류가 있습니다. 뜻.. 2026. 7. 24. [Frontend] 번역률 100%인데 왜 한글이 남을까 — 자동 검증이 못 잡는 i18n 누락 3종 서핑 예보 앱을 영어로도 내보내려고 국제화(i18n)를 붙였습니다. 번역 키 사전을 검증해보니 미번역 0개, 한국어와 영어 키가 완전히 일치했습니다. 그런데 앱을 영어로 바꾸자, 여전히 곳곳에 한글이 남아 있었습니다. 키는 다 번역했는데 왜 한글이 나올까요? 이 글에서는 번역률 100%라는 착각 뒤에 숨어 있던 세 가지 누락과, 그걸 조용히 덮어버린 폴백 설정의 함정을 정리합니다.이 글은 React Native 국제화기 시리즈의 1편입니다. 다음 편들에서는 지명 같은 고유명사 처리와, 데이터베이스에 저장된 콘텐츠의 다국어를 다룰 예정입니다.왜 영어가 필요했나서핑 앱을 만들면서 처음엔 한국 스팟만 다뤘습니다. 그런데 발리 같은 해외 스팟까지 넣게 되면서, 자연스럽게 "한국어만으로는 부족하다"는 문제에 부딪.. 2026. 7. 22. [DevOps] "업데이트하세요" 팝업을 앱에 직접 붙이기 — 스토어 심사 없이 버전 제어하기 앱을 운영하다 보면 "옛날 버전을 쓰는 사용자"가 골칫거리가 됩니다. 서버 API를 바꿨는데 구버전 앱이 그걸 못 따라오거나, 심각한 버그가 있는 버전을 계속 쓰는 사용자가 있으면 문제가 커집니다. 그래서 앱에 버전 게이트를 붙였습니다. 앱이 켜질 때 버전을 확인해서, 필요하면 "업데이트하세요" 안내나 강제 업데이트 화면을 띄우는 장치입니다. 이 글에서는 스토어 심사 없이 서버로 버전을 제어하는 이 게이트를 어떻게 만들었는지 정리합니다. 코드 기교보다는, 출시한 앱을 안정적으로 운영하기 위한 전략에 가까운 이야기입니다.왜 버전 게이트가 필요했나모바일 앱은 웹과 다릅니다. 웹은 새로고침하면 최신 코드가 로드되지만, 앱은 사용자가 직접 스토어에서 업데이트하지 않으면 옛날 버전이 그대로 남습니다. 문제는 여기.. 2026. 7. 22. [Troubleshooting] 재배포했더니 이미 보낸 푸시가 또 갔다 — FCM 알림 중복 발송 잡기 위험 알림 푸시를 만들면서 예상 못 한 문제를 만났습니다. 서버를 재배포할 때마다, 이미 보냈던 알림이 사용자에게 또 가는 것이었습니다. 알림이 중복으로 오면 사용자는 앱을 스팸으로 느끼고, 심하면 알림을 꺼버립니다. 이 글에서는 "위험이 시작되는 순간에만" 알림을 보내려다 만난 세 가지 함정과, 그걸 어떻게 해결했는지를 정리합니다. 푸시 알림의 중복 발송이나 상태 기반 알림 설계로 고민하는 분께 도움이 될 만합니다.배경 — "전환되는 순간에만" 알리고 싶었다서비스에는 특정 지역의 바다가 위험 상태가 되면 사용자에게 배너 푸시를 보내는 기능이 있습니다. 위험이 감지되면 알림을 주는 건데, 여기엔 중요한 설계 원칙이 있었습니다. 위험이 "시작되는 순간"에만 알린다는 것입니다.이게 왜 중요하냐면, 위험이 지.. 2026. 7. 17. [Troubleshooting] "내 폰에선 되는데" — 테스터 폰에서만 죽던 크래시를 원격으로 잡기 앱을 만들며 가장 무서운 말이 "내 폰에선 되는데"입니다. 개발자 기기에서는 멀쩡한데 특정 사용자 기기에서만 앱이 죽으면, 재현이 안 되니 손을 쓸 수가 없습니다. 이 글은 비공개 테스트 단계에서 일부 테스터 기기에서만 발생하던 크래시를, 에러 추적 도구(Sentry)로 원격에서 포착해 해결한 과정을 다룹니다. 앞서 무료 모니터링 스택을 소개한 글의 후속으로, "그래서 실제로 뭘 잡았나"를 구체적으로 이야기합니다.이 글은 모니터링 시리즈의 2편입니다. 1편에서 Sentry·PostHog로 무료 관측 체계를 갖춘 이야기를 했고, 이번 편은 그 Sentry가 실제로 잡아낸 크래시 하나를 깊이 파헤칩니다.재현되지 않는 크래시의 공포앱을 테스터들에게 배포한 뒤, 몇몇에게서 비슷한 제보가 들어왔습니다. 다이어리에.. 2026. 7. 4. [Frontend] 작은 조각부터 쌓는 컴포넌트 설계 — Atomic Design과 UI 라이브러리를 안 쓴 이유 이 글은 디자인 토큰 위에 컴포넌트를 어떻게 체계적으로 쌓았는지, 그리고 잘 만들어진 UI 라이브러리들을 두고도 직접 컴포넌트를 만들기로 한 이유를 정리한 것입니다. 1인 개발이나 소규모 팀에서 컴포넌트 구조가 점점 뒤죽박죽이 되는 게 고민이거나, UI 라이브러리를 쓸지 직접 만들지 저울질하고 있다면 참고가 될 만한 내용입니다.함께 보면 좋은 글: 이 글은 디자인 시스템 2부작의 2편입니다. 1편에서는 색·간격·폰트를 토큰으로 묶어 일관성을 만드는 방법을 다뤘습니다. 토큰이 "값의 일관성"이라면, 이번 글은 "구조의 일관성"입니다.토큰만으로는 부족했다1편에서 색과 간격, 폰트를 토큰으로 묶고 나니 화면 사이의 시각적 어긋남은 크게 줄었습니다. 그런데 화면이 늘어나면서 다른 종류의 혼란이 찾아왔습니다. 같.. 2026. 6. 26. 이전 1 2 다음
