PHP에서 React → 그리고 Express로, 한 번에 못 바꾸는 현실 속 점진적 전환기 (2탄)

마이그레이션 이야기 2탄

#PHP #React #Express #마이그레이션

지난 글 : http://jaeyonging.com/blog/50 이전 글에서는 PHP + HTML 기반으로 만든 프로젝트를 React + Express로 옮기기로 결심한 이유를 이야기했었다. 하지만 현실은 단순하지 않았다. 프로젝트가 두 개나 얽혀 있었다 내가 맡은 서비스는 PHP 프로젝트가 두 개가 얽혀서 돌아가는 구조 였다. 관리자 페이지, 사용자 페이지, 그리고 그 안에서 서로 include로 주고받는 파일들이 복잡하게 얽혀 있었기 때문에 한 번에 싹 React로 갈아엎는 건 불가능 했다. 코드도 많고, 구조도 꼬여 있어서 잘못 건드리면 어디서 터질지 모르는 상황이었다. 그래서 iframe부터 썼다 초기에는 게임이나 동영상 콘텐츠, 일부 기능성 페이지들을 먼저 React로 만들고 iframe으로 PHP 페이지에 끼워 넣는 방식 으로 붙였다. iframe src="/static/react-built-game/index.html?id=123" width="100%" height="600px" /iframe 이 방식은 React로 UI를 빠르게 개발할 수 있어서 좋았지만, 서버와 상태를 공유하기 어렵고, postMessage 없이 소통도 힘들었다. 결국 이건 임시방편이었고, 전체를 React로 옮겨가는 게 목표였다. 완전히 React로 갈아끼우기 시작 iframe으로 붙였던 기능들을 하나씩 React로 옮겨가기 시작했다. 기존 PHP는 이제 화면을 그리는 역할이 아니라, React가 필요한 데이터를 JSON 형태로 넘겨주는 API 서버처럼 동작 하도록 변경했다. 그러다 보니 필요한 API들이 보였다 React로 구조를 옮기다 보니, 어떤 API가 필요하고 어떤 데이터가 오가는지가 명확해졌다. 그제야 비로소 Express로 바꿔야 할 API들만 추릴 수 있었다. 처음부터 다 바꾸려 하지 않았고 진짜 필요한 API만 골라서 Express로 이관 결국 핵심 기능부터 차례로 옮겨가면서도, 서비스는 계속 운영 가능한 상태를 유지할 수 있었다. 결과적으로 이렇게 정리되었다 PHP는 점점 데이터 제공자 역할로 축소 iframe으로 붙였던 React 기능들은 전부 SPA 내부로 통합 Express는 진짜 필요한 부분부터 붙이기 시작했고, 지금은 거의 대부분의 API가 Express + MySQL 구조로 돌아가는 상태다. 정리하자면 이런 상황이었다면 처음부터 다 뜯어고치는 건 오히려 리스크였다. 나는 “이건 무조건 React로 가야 해”가 아니라 , 단계적으로 전환 가능한 영역부터 React로 옮겨가는 전략이 더 안정적 이라고 판단했다. 그리고 점진적으로 PHP의 역할을 줄이고 Express 기반으로 필요한 API만 재구성하는 식으로 안정적인 전환이 가능했다. 마무리 마이그레이션은 완벽하게 새로 시작하는 게 중요한 게 아니다. 지금 구조에서 어디서부터 바꿔야 효율적일지 판단하는 게 핵심 이다. 두 개의 프로젝트가 얽혀 있든, iframe으로 붙였든 상관없다. 내가 했던 것처럼 임시로 React 붙이고 , 그 안에서 필요한 부분부터 Express로 하나씩 교체하는 방법 도 충분히 좋은 방식이다. "일단 되는 것부터 React로 바꾸자"라는 접근이 결국은 전체 구조까지 안정적으로 바꾸는 데 성공하게 만들었다.