Eelco의 서브도메인/경로 혼용 방식은 개발과 프로덕션 환경 간의 근본적인 불일치를 야기하며, 이는 다음과 같은 여러 문제로 이어집니다.
1. URL 불일치 및 기능 오류
-
비 Rails 생성 URL 문제: Rails 라우터 외부에서 생성된 URL(예: 정적 파일)은 개발과 프로덕션에서 경로가 달라져 동적 처리가 필수적입니다.
-
Well-known URL 문제:
favicon.ico,robots.txt등 특정 루트 경로를 기대하는 URL들이 경로 네임스페이싱 환경에서는 제대로 작동하지 않습니다.
2. 보안 및 네트워크 설정 문제
-
CORS (Cross-Origin Resource Sharing) 문제: 개발 시 동일 출처로 간주되던 API 호출이 프로덕션에서 교차 출처가 되어 CORS 오류를 유발합니다. 이는 배포 후 발견되기 쉬우며, 과도한 보안 설정으로 이어질 수 있습니다.
-
CSP (Content Security Policy) 문제: CORS와 유사하게, CSP 정책이 개발과 프로덕션 환경의 출처 분류 차이로 인해 스크립트 실행을 차단하거나 예상치 못한 동작을 유발할 수 있습니다.
-
Rails 호스트 권한 부여 문제: Rails의 호스트 권한 부여 설정이 개발 환경에서는 작동하지 않아, 프로덕션 배포 시 서브도메인을 추가하는 것을 잊어 API 제공이 거부될 수 있습니다.
3. 인증 및 세션 관리 문제
- 쿠키 및 인증 문제: 경로 기반 환경에서는 일반 쿠키가 설정되지만, 서브도메인 환경에서는 와일드카드 도메인(
.myapp.com)으로 쿠키를 설정해야 합니다. 이 차이로 인해 인증 관련 문제가 발생할 수 있으며, 배포 전까지 인지하기 어렵습니다.
4. 시기상조의 아키텍처 복잡성
- 과도한 스케일링: API 및 웹훅에 별도 서브도메인을 사용하는 것은 성장에 유리할 수 있으나, 성장이 실제로 발생하기 전에는 불필요한 복잡성만 가중시킵니다. 동일 출처 애플리케이션을 다중 출처로 전환하는 것은 개발 환경에서 충분히 검증되지 않으면 매우 고통스러운 과정이 될 수 있습니다.