블로그 nginx에서 리다이렉트 롤백과 RSS CORS 문제 해결

blog 도메인의 nginx 설정을 정리하는 과정에서, 앞서 준비했던 301 리다이렉트를 되돌리고 동시에 RSS 피드의 CORS 문제를 해결했다. 겉보기 단순한 설정 변경이지만, 그 뒤에는 의사결정의 변화와 우선순위 조정이 있었다.

301 리다이렉트를 되돌린 이유

처음 이 리다이렉트들을 설정했을 때는 insights 섹션을 다른 경로로 옮기려는 계획이 있었다. 이것은 자연스러운 의도다. 블로그 구조를 개선하거나 콘텐츠를 재정리할 때 기존 링크를 깨뜨리지 않으면서 새 위치로 안내하는 것이 웹의 기본 원칙이니까. 301(Moved Permanently) 상태 코드로 검색 엔진에도 "이제 여기 봐" 라고 명확히 알리고, 구독자들의 북마크도 자동으로 따라오게 된다.

그런데 그 이동 계획이 보류되었다. 개발 리소스, 우선순위, 또는 UX 재고 등 여러 이유가 있을 수 있다. 그럴 때 가장 현명한 선택은 임시방편을 빨리 정리하는 것이다. 리다이렉트 규칙을 그대로 두면:

• 혼동을 만든다 (원래 경로가 아닌데 왜 리다이렉트되지?)
• 나중에 실제로 이동할 때 충돌한다 (기존 규칙과의 우선순위 관리)
• 로그와 분석이 복잡해진다 (어느 경로로 들어오는 사람이 더 많은가?)

그래서 revert 선택지가 정답이었다.

병렬로 진행한 RSS CORS 개선

같은 설정 파일을 만지는 김에, RSS 피드에 CORS 헤더를 추가했다. 이것도 몇 가지 현실적인 배경이 있다:

왜 RSS에 CORS가 필요한가?
- RSS 피드를 JavaScript로 fetch 하려면 (브라우저 환경에서) CORS 헤더가 필수다
- 예를 들어, 블로그 피드를 내 포트폴리오 페이지에 embed 하거나, 제3자 서비스(Medium, Substack 같은)가 피드를 읽으려면 CORS 허용이 필요하다
- nginx 수준에서 처리하면 깔끔하다 (애플리케이션 레벨 수정이 불필요)

이런 작은 개선이 쌓여서 개발자 경험과 확장성을 높인다. 누군가 "내 포트폴리오에 블로그 RSS 넣고 싶은데…" 하면 이미 준비돼 있는 상태.

회고: 설정 관리의 의사결정 포인트

이 커밋으로 배운 점:

1. 임시방편은 빨리 정리할 것 - 301 리다이렉트는 "임시로 옮겨둔" 느낌을 주기 쉽다. 그 상태로 오래 두면 나중에 일관성 문제가 생긴다. 계획이 바뀌었다면 빨리 롤백하는 게 코드베이스 건강성을 지킨다.

2. 설정 파일 수정 기회 활용 - nginx 설정처럼 건드리기 조심스러운 파일들은 관성적으로 수정이 피해진다. 하지만 이미 손을 대는 순간이 오면, 그때 함께 개선할 다른 작은 것들을 살피는 게 효율적이다. 리뷰 부담도 한 번에 모아서 진다.

3. CORS 같은 인프라 개선은 조용히 할 수 있다 - 이게 별도 PR 이었으면 "왜 갑자기 CORS를?"이라고 리뷰이들이 물어볼 텐데, 함께 묶으면 맥락이 명확하다. "이미 설정 수정하는 것 같으니 함께" 이라는 설득력.

결국 side 작업이지만, 시스템을 관리하는 입장에서 놓치지 말아야 할 것들이 있다. 계획이 바뀐 건 흔하고, 그럴 때마다 과거의 결정을 재검토하고 정리하는 것. 그게 무섭고 번거롭지 않도록 nginx 같은 설정은 간결하게 유지해야 한다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.