AI 도입 사례
같은 서비스의 iOS 앱은 회원의 다수를 차지하는 주 전장이었습니다. 그럼에도 알림은 Android 이상으로 조용히 침묵하고 있었습니다 — 구세대 알림 경로가 완전히 끊겨 있었던 것입니다. 실록⑥(Android 편)에 이어 이번에는 iOS 특유의 막히는 지점과, 두 OS에 공통되는 “낡은 서버를 건드리지 않고 알림을 현대화한” 이야기를 정리합니다.
“알아챌 수 없는 장애”야말로 가장 먼저 없앨 가치가 있습니다.
이용자의 대부분이 iOS. 그 iOS에서 알림은 죽어 있었습니다.
iOS 앱도 Android와 마찬가지로 네이티브 껍데기로 기존 웹 서비스를 표시하는 WebView 래퍼＋알림이라는 구성이었습니다. 알림 발송은 구세대 구조에 의존하고 있었고, 그 경로를 쓸 수 없게 된 시점에 배포가 정지됐습니다. 이용자의 다수가 이쪽에 있기 때문에 영향 범위는 최대였습니다. 이곳을 현대의 배포 기반으로 옮기는 것이 이번의 가장 큰 리턴입니다.
iOS의 막힘은 “실기에서만 나오는” 것들뿐이었습니다.
iOS는 가상 단말이나 코드 리뷰로는 알 수 없는, 실기에서 비로소 표면화되는 문제가 중심이었습니다.
껍데기는 Swift로 다시 만들고, 내용과 회원은 그대로.
iOS 앱은 AI 에이전트로 최신 네이티브 구성(Swift＋WKWebView＋현행 알림 기반)으로 다시 만들었습니다. 프로젝트 뼈대 생성부터 실기 확인까지 돌리며 Mac의 실기 빌드로 동작을 확인했습니다. 표시하고 있는 내용(기존 웹 서비스)과 약 14,000대의 등록 단말이라는 회원 자산은 그대로 이어받았습니다.
| 항목 | 이전 | 재구축 후 |
|---|---|---|
| 알림 경로 | 구세대 알림 방식 (서비스 종료·발송 불가) | 현행 배포 기반＋새 방식의 인증 키 |
| 앱 껍데기 | 세대가 오래된 네이티브 구현 | Swift＋WKWebView로 재생성 |
| 화면(내용) | 기존 웹 서비스를 표시 | 그대로 유지(회원 자산 보존) |
| 실기의 결함 | 일본어 깨짐 등 | 폰트·배지·세대 차이를 개별 대응 |
낡은 서버는 교체하지 않고 현대화했습니다.
두 OS에 공통되는 핵심은 발송 쪽 서버였습니다. 이 서버는 매우 낡은 실행 환경에서 돌아가고 있어 현행 공식 도구를 그대로 쓸 수 없습니다. 그래서 인증에 필요한 서명 처리를 자체 구현해 현행 배포 기반에 연결했습니다. 서버를 통째로 교체하지 않고 알림만 현대의 방식으로 옮겨 실었습니다.
또한 발송 쪽은 공유 기반에서 분리한 독립된 배포 서비스로 다시 만들어, 관리 화면에서 대상을 골라 보낼 수 있도록 했습니다.
“돌아가지 않는다”는 소리를 듣던 모바일 앱이라도 껍데기를 다시 만들고, 키와 회원 자산을 이어받고, 낡은 서버를 현대화하면 재구축은 단 한 번으로 현행 운용에 되돌릴 수 있습니다. 손댈 수 없다고 포기한 앱이 있다면 먼저 실물 분석부터 상담해 주세요.
※ 본 기사는 실제 프로젝트를 바탕으로 기업·서비스를 특정할 수 없는 범위에서 일반화해 기술했습니다. 수치는 2026년 8월 시점의 실측에 근거한 개략값입니다. 소요 기간·작업 내용은 앱의 구성에 따라 다릅니다.