레이아웃 스크립트 누락 방지를 위해 무조건 로드로 전환

Base.astro에서 HawkEyesMaker.js 로딩 조건을 제거했다.

왜 조건부 로드가 문제였나

원래 코드는 대략 이런 식이었을 거다.

{import.meta.env.MOBONSCRIPT_CODE && (
  <script src="/HawkEyesMaker.js" />
)}

환경 변수 mobonScriptCode가 세팅되어 있을 때만 스크립트를 로드하는 구조. 얼핏 보면 "환경마다 다르게 제어한다"는 의도처럼 보이지만, 실제로는 이게 꽤 위험한 패턴이다.

레이아웃 파일에서 외부 스크립트 로딩을 환경 변수 하나에 묶어두면, 배포 파이프라인에서 해당 변수가 누락되거나 잘못 세팅되는 순간 스크립트 자체가 통째로 빠져버린다. 그리고 이런 류의 실수는 보통 로컬에서는 절대 재현이 안 된다. 로컬 .env에는 값이 있으니까. 문제는 항상 스테이징이나 운영 배포 직후에 터진다.

무조건 로드로 바꾼 이유

HawkEyesMaker.js가 psy 모듈과 연결된 스크립트라면, 이 파일은 페이지 동작에 필수적인 역할을 하고 있을 가능성이 높다. 환경 변수는 원래 값을 주입하는 용도지, 로딩 여부를 결정하는 게이트키퍼 역할을 맡으면 안 된다.

이번 픽스는 "로드 여부"를 env에 맡기는 구조 자체를 끊어낸 것이다. 필요하다면 스크립트 내부에서 mobonScriptCode 값을 받아서 동작을 분기하면 되고, 레이아웃 레벨에서는 그냥 항상 로드되어야 한다.

Base.astro에서 이런 패턴이 위험한 이유

Base.astro는 사이트 전체 레이아웃의 기반이다. 여기서 조건부 로딩을 잘못 걸면 영향 범위가 전체 페이지다. 특정 컴포넌트 하나가 아니라.

팀에서 레이아웃 파일을 건드릴 때 내가 항상 강조하는 게 있다.

• 레이아웃 레벨 변경은 반드시 전체 페이지 영향 검토
• 외부 스크립트 로딩 조건은 "정말 이 조건이 빠지면 어떻게 되는가"를 먼저 시뮬레이션
• 환경 변수는 설정값 주입에만 쓰고, 기능 on/off 게이트로 쓰지 말 것 (쓰더라도 기본값 fallback 필수)

이번 건도 아마 어느 순간 mobonScriptCode가 특정 환경에서 빠졌고, HawkEyesMaker.js가 조용히 로드 안 되면서 psy 모듈 동작이 깨진 걸 발견한 케이스일 거다. 조용히 깨지는 게 제일 무섭다. 에러도 없이.

변경 자체는 한 줄짜리 fix지만, 이 한 줄이 "레이아웃 파일에서 env를 gate로 쓰지 않는다"는 원칙을 명확히 박아두는 작업이었다.

끝.

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

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

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