Config 이후의 경계: 멀티플랫폼 React를 core·rsConfig·platform으로 나눈 이유

Config가 해결한 것과 남긴 것

설정은 호텔마다 달라지는 값과 기능 사용 여부를 컴포넌트 안의 조건 분기에서 꺼내는 데 유효했습니다. 하지만 플랫폼별 배포 브랜치가 계속 수정되면 같은 설정 구조를 사용하더라도 공통 코드의 구현이 서로 달라질 수 있습니다.

그래서 다음 질문이 필요했습니다.

공통 동작, 값 차이, 화면·로직 차이는 각각 어디에 배치할 것인가?

세 종류의 차이를 서로 다른 경계에 둡니다

모든 플랫폼에서 같은 동작은 core에 둡니다. 예약 단계 전환이나 공통 API 호출처럼 호텔이 달라도 같은 규칙을 따라야 하는 코드가 여기에 해당합니다. 공통 수정은 기준 소스의 core에서 한 번 다룹니다.

동작은 같고 값만 다르면 rsConfig에 둡니다. 문구, 기능 사용 여부와 호텔별 설정처럼 데이터로 표현할 수 있는 차이를 코드 구현과 분리합니다.

화면 구성이나 처리 로직 자체가 다르면 platform에 둡니다. 공통 계약으로 표현하기 어려운 호텔 고유 구현을 확장 영역에 남기되, 공통 동작까지 통째로 위임하지 않도록 범위를 좁힙니다.

모든 플랫폼의 공통 동작 → core
값만 다른 차이           → rsConfig
화면·로직 자체의 차이    → platform

기준 소스와 배포 단위는 같은 개념이 아닙니다

이 구조는 하나의 기준 소스에서 세 경계를 관리하지만 런타임 tenant 전환 구조는 아닙니다. build-time alias로 대상 platform을 선택하고, 플랫폼별 빌드와 호텔별 운영 폴더 배포를 계속 수행합니다.

따라서 기준 코드가 하나라는 사실을 전체 호텔이 한 번에 배포된다는 뜻으로 확대할 수 없습니다. 공유하는 것은 소스의 기준이고, 빌드와 운영 반영은 플랫폼 단위입니다.

적용할 조건과 그대로 적용하지 않을 조건

공통 예약 흐름을 공유하면서 호텔별 설정과 일부 화면·로직 차이를 유지해야 하고, 플랫폼별 빌드·배포가 필요한 경우에 이 경계를 적용할 수 있습니다. 차이의 성격을 세 범주로 설명할 수 있어야 합니다.

반대로 런타임에 tenant를 전환해야 하거나 플랫폼들이 공유하는 도메인 흐름이 거의 없다면 이 구조를 그대로 적용하지 않습니다. 전자는 runtime 설정·격리 설계가 더 필요하고, 후자는 공통 core가 억지 결합이 될 수 있습니다.

위임 경계에는 검증 비용이 남습니다

platform이 전체 화면 구현을 대신할 수 있으면 예외를 빠르게 수용할 수 있지만, core의 공통 변경을 빠뜨리기도 쉽습니다. 그래서 값 차이와 작은 행동 차이는 좁은 contract로 표현하고 전체 구현 위임은 꼭 필요한 범위에 제한해야 합니다.

디렉터리와 import 경로가 맞고 빌드가 성공하는지만 확인해서는 행동 패리티를 증명할 수 없습니다. 공통 contract 검사와 플랫폼별 주요 행동 검증을 함께 두어야 세 경계가 시간이 지나도 같은 의미를 유지합니다.