어떤 플랫폼이었나
관리사무소와 입주민을 잇는 관리 플랫폼이었습니다. 공지·민원·관리비 안내·알림 같은 기능이 오래된 PHP 기반 웹/백엔드 위에서 돌고, 입주민은 모바일 앱(React Native)으로 접속하는 구조였습니다. 수백 세대 규모가 매일 실제로 쓰는, 멈추면 바로 민원이 들어오는 운영 서비스였습니다.
넘겨받을 때 상황
이런 레거시 플랫폼은 대개 공통점이 있습니다. 설계·배포 문서가 거의 없고, 처음 만든 사람과 연락이 어렵고, 기능이 서로 얽혀 어디를 건드리면 어디가 터질지 모르는데, 그런데도 지금 돌고 있고 멈추면 안 됩니다. 그래서 "낡았으니 새로 만들자"가 첫 선택이 되기 어렵습니다.
가장 먼저 한 것 — 파악과 안정화
자주 터지던 문제들
오래된 PHP 운영에서 반복되는 함정들입니다. 자세한 건 PHP 운영 배포 체크리스트·레거시 PHP 운영 사례에 정리돼 있습니다.
PHP 서버와 앱(RN)을 같이 유지보수
관리 플랫폼은 서버와 앱이 한 몸입니다(위 구조도 참고). 서버 API가 바뀌면 앱이 깨지고, 앱 스토어 정책(권한·처리방침·심사)이 바뀌면 다시 올려야 합니다. 그래서 둘을 나눠 맡기면 "서로 떠넘기기"가 생깁니다. 한 곳에서 서버와 앱을 함께 보는 것이 레거시 운영에서는 특히 유리했습니다. 변경이 양쪽에 미치는 영향을 한 번에 보고 대응할 수 있기 때문입니다.
전면 재구축 vs 점진 운영 — 무엇을 골랐나
전면 재구축 (처음 유혹)
- 깨끗하지만 몇 달간 큰 비용
- 그동안 기존 서비스는 계속 돌려야 함
- 숨은 요구사항 누락 위험
- 정말 유지 불가능할 때의 마지막 선택
점진 운영 (실제 선택)
- 멈추지 않고 넘겨받아 바로 안정화
- 위험한 부분부터 조금씩 정리
- 비용·리스크가 낮고 되돌리기 쉬움
- 대부분의 경우 이 방법으로 충분
운영하며 세운 원칙
- 멈추지 않게가 1순위: 개선보다 중단 방지가 먼저.
- 되돌릴 수 있게: 백업·배포 되돌리기를 항상 준비.
- 만료는 달력으로: 인증서·도메인·발송 승인 등 만료형 자산은 사전 관리.
- 조금씩 정리: 한 번에 새로 만들지 않고, 운영하며 위험한 부분부터.
비슷한 상황이라면
"오래된 PHP 관리 시스템을 넘겨받았는데 문서가 없다", "서버는 PHP인데 앱도 같이 있다", "멈추면 안 되는데 손대기 무섭다" — 이런 경우 무턱대고 새로 만들기 전에 파악·안정화·사전 방어 순으로 접근하는 것을 권합니다.
자주 묻는 질문
문서 없이 넘겨받아도 유지보수가 되나요?
됩니다. 문서가 없으면 코드와 DB, 로그에서 구조와 흐름을 역추적해 정리합니다. 시간이 더 들 수 있어, 먼저 인수 점검으로 범위와 위험을 진단한 뒤 진행합니다.
PHP가 너무 낡았는데 새로 만들어야 하나요?
대부분은 아닙니다. 돌아가는 서비스를 멈추지 않고 넘겨받아 위험한 부분부터 점진적으로 정리하는 편이 안전하고 비용도 적습니다. 전면 재구축은 구조상 더 이상 유지가 불가능할 때의 마지막 선택입니다.
서버(PHP)와 앱을 한 곳에서 함께 유지보수할 수 있나요?
가능하고, 관리 플랫폼처럼 서버와 앱이 한 몸인 경우 오히려 한 곳에서 보는 편이 유리합니다. 서버 API 변경이 앱에 미치는 영향과 스토어 정책 대응을 함께 처리할 수 있어 '떠넘기기'가 생기지 않습니다.
운영 중인데 사고가 날까 겁납니다. 어떻게 시작하나요?
손대기 전에 백업부터 확실히 하고, 바로 고치기보다 로그·사용 흐름을 관찰해 중요한 부분을 먼저 파악합니다. 만료형 자산(인증서·도메인·발송 승인)을 달력에 올려 사전에 막는 것만으로도 큰 사고 대부분을 예방할 수 있습니다.
무료 점검부터 시작하세요
넘겨받은 PHP 플랫폼이나 앱이 있다면, 가진 자산 목록만 주셔도 인수 가능 여부와 위험도를 먼저 알려드립니다.
문의: appmonster.kr@gmail.com
함께 보기: 레거시 PHP 운영 사례 · PHP 운영 배포 체크리스트 · 소스코드 없는 앱