사내 Portal 어드민 이관·모노레포 설계

문제

두 가지 문제가 이어졌다.

이관 단계에서는, 별도 시스템으로 운영되던 예약 백오피스를 사내 Portal 시스템으로 옮겨야 했다. 화면을 그대로 복사하면 동작은 하지만 두 시스템의 코드 컨벤션이 한 저장소 안에서 섞인다. 그러면 이관을 끝낸 뒤 다른 개발자가 어느 쪽 패턴을 따라야 할지 알 수 없게 된다.

이후에는 Portal 계열 운영 앱 6종이 각각 별도 저장소로 흩어져 있었다. 공통 컴포넌트와 유틸이 앱마다 복제돼 있어 한 곳을 고쳐도 나머지에 반영되지 않았고, 전체를 띄우려면 저장소마다 따로 설치하고 실행해야 했다.

해결

이관 (2025.06 - 2025.07)

• 옮기기 전에 이관 대상 시스템의 소스를 먼저 읽어 컨벤션을 파악했다 — 디렉터리 배치, 라우팅 방식, API 계층, 상태 관리 패턴
• 시설 관리(브랜드별 목록, 등록/수정 라우팅, 호텔그룹 필터링) 메뉴를 그 컨벤션에 맞춰 재구현
• 화면을 그대로 옮기지 않았기 때문에, 이관 후에도 대상 코드베이스의 일관성이 유지됐다

모노레포 전환 설계 (2025.10 - 2025.11)

• 운영 앱 6종을 yarn workspaces 단일 저장소로 묶는 구조를 설계하고, 실제로 동작하는 형태로 구현해 제출했다
• 공통 컴포넌트·유틸·타입을 별도 패키지로 분리해 앱들이 참조하도록 재배치
• 앱별 타입 검사 스크립트와 아이콘 번들 생성을 자동화하고, 한 번의 명령으로 전체를 실행할 수 있게 했다

효과

• 이관된 메뉴가 대상 시스템의 패턴을 그대로 따르게 되어, 이후 다른 개발자가 같은 방식으로 이어받을 수 있는 상태가 됐다
• 모노레포 전환은 도입이 아니라 설계·제출 단계다. 실행 가능한 구조와 문서를 만들어 검토를 받는 것까지가 이 작업의 범위였다