AI 도입 사례
“앱은 돌아갑니다. 다만 알림만 몇 년째 오지 않습니다.” 상담은 그렇게 시작됐습니다. 회원제 B2C 서비스용 Android 앱이었습니다. 스토어에 공개돼 있고 실행도 되는데, 공지 푸시 알림만 어느새 한 통도 나가지 않고 있었습니다. 이번에는 만든 사람도 자료도 없는 “손댈 수 없는 모바일 앱”을, 회원 자산과 서명 키를 하나도 빠짐없이 그대로 이어받은 채 AI로 다시 만든 기록입니다.
죽지 않은 채, 중요한 기능만 조용히 멈춰 있는 앱입니다.
“돌아가고는 있다”의 아래에서, 알림은 몇 년 전에 멈춰 있었습니다.
이 앱의 정체는 네이티브 껍데기 안에서 기존 웹 서비스를 표시하는 WebView 래퍼＋푸시 알림이라는 구성이었습니다. 화면은 기존 웹 자산을 재사용하므로 살아 있었습니다. 문제는 알림이었습니다. 발송 구조가 구세대 배포 기반에 의존하고 있었고, 그 기반이 서비스 종료된 시점에 경로 자체가 사라져 있었습니다. 데이터베이스에는 새 방식의 토큰을 저장할 열만 추가돼 있고 거기에는 아무것도 기록되지 않은 채 — 배선이 도중에 끊긴 상태로 방치돼 있었습니다.
“손댈 수 없다”의 8할은 사실 “다시 만드는 것에 대한 두려움”이었습니다.
실제로 부딪힌 벽은 코드의 난이도보다 “이어받는 것에 대한 두려움”이었습니다. 특히 Android는 한 번 잘못하면 기존 사용자가 업데이트할 수 없는 다른 앱이 되어 버립니다.
남길 것과 다시 만들 것을 분명히 나눴습니다.
할 일은 “전부를 새것으로 만드는 것”이 아닙니다. 살릴 수 있는 자산은 그대로 살린다. 분해하면 이렇게 됩니다.
| 항목 | 이전 | 재구축 후 |
|---|---|---|
| 알림 경로 | 구세대 배포 기반 (서비스 종료·발송 불가) | 현행 배포 기반(FCM)으로 이전 |
| 앱 껍데기 | 세대가 오래된 네이티브 구현 | 최신 네이티브 구현으로 재생성 |
| 화면(내용) | 기존 웹 서비스를 표시 | 그대로 유지(회원 자산 보존) |
| 서명 키 | 2016년 발급 | 동일한 키를 계승(업데이트로 배포) |
| 회원·단말 데이터 | 약 14,000대 단말이 등록 완료 | 그대로 인계 |
재구축 자체는 AI 에이전트로 단숨에 진행했습니다. 다시 만든 앱은 가상 단말에서 알림 토큰 취득 → 서버 등록 → 실제로 알림 도착까지의 일련의 흐름을 끝까지 통과시켜 왕복이 성립하는 것을 확인했습니다. 산출물은 그대로 배포할 수 있는 서명된 형식입니다.
돌아가지 않는다고 하는 앱의 대부분은 전손이 아닙니다. 멈춰 있는 일부 배선과 이어받아야 할 키만 확보하면, 실물을 살린 채 현대의 기반으로 되돌릴 수 있습니다. iOS 편(실록⑦)에서는 회원의 다수를 차지하는 다른 한쪽 플랫폼과, 두 OS 공통의 “낡은 서버를 그대로 두고 알림을 현대화한” 이야기를 씁니다.
※ 본 기사는 실제 프로젝트를 바탕으로 기업·서비스를 특정할 수 없는 범위에서 일반화해 기술했습니다. 수치는 2026년 8월 시점의 실측에 근거한 개략값입니다. 소요 기간·작업 내용은 앱의 구성에 따라 다릅니다.