배포 스크립트 환경변수 치환 실패로 DB 연결이 깨지던 문제 수정

배포 스크립트에서 sed quote 처리가 조용히 실패하고 있었다.

배경

SITE_ID 기본값을 DB 레이어에서 세팅하는 구조였는데, 로컬에서는 문제가 없었다. 환경변수가 제대로 주입되는 상황에서는 기본값 코드 경로 자체를 타지 않으니까. 문제는 sed로 환경변수를 주입하는 스크립트에서 quote 처리가 실패하면서, SITE_ID에 기대한 값 대신 빈 문자열이나 의도치 않은 문자열이 들어가는 상황이었다.

src/lib/db.ts는 DB 연결 초기화와 기본 설정값을 관리하는 파일이다. 이런 파일은 건드리는 빈도가 낮은 만큼, 한 번 잘못 들어간 기본값은 꽤 오래 살아남는다. 그래서 더 조심해야 하는 영역이기도 하다.

무슨 일이었나

sed 치환 스크립트에서 싱글쿼트/더블쿼트 중첩 문제가 있었다. 흔한 패턴이다. 예를 들면 이런 식이다.

# 실패 케이스 - 내부 값에 특수문자가 있을 때 quote가 깨짐
sed -i "s/SITE_ID_PLACEHOLDER/$SITE_ID/g" config.ts

# 더 안전한 패턴
sed -i "s|SITE_ID_PLACEHOLDER|${SITE_ID}|g" config.ts

/를 구분자로 쓸 때 값 자체에 슬래시가 있으면 치환이 깨지고, 더블쿼트 안에 $VAR를 넣을 때도 쉘 확장 타이밍에 따라 빈 값이 들어가는 경우가 있다. 이번 건도 그 계열의 문제였다.

db.ts 쪽에서는 이 치환이 실패했을 때를 대비해 기본값(default value) 처리 로직이 있었는데, 그 기본값 자체가 잘못 세팅되어 있었거나 fallback 경로가 의도대로 동작하지 않았던 것이다. 결국 SITE_ID가 제대로 들어가지 않은 채로 DB 연결이 시도되는 상황.

// before: sed 치환 실패 시 의도치 않은 값이 그대로 들어감
const SITE_ID = process.env.SITE_ID || "SITE_ID_PLACEHOLDER";

// after: 명시적 fallback + 유효성 검증
const SITE_ID = process.env.SITE_ID || "default-site";
if (!SITE_ID || SITE_ID === "SITE_ID_PLACEHOLDER") {
  throw new Error("SITE_ID is not configured properly");
}

회고

이런 류의 버그는 항상 두 계층의 문제가 동시에 존재할 때 터진다. 스크립트 레이어의 quote 처리 실패, 그리고 애플리케이션 레이어의 기본값 방어 로직 미흡. 둘 중 하나만 제대로 처리됐어도 문제가 드러나지 않았을 거다.

팀 레벨에서 이런 이슈가 반복되는 패턴을 보면, 대개 배포 스크립트가 "일단 돌아가니까" 하는 상태로 오래 방치된 경우가 많다. 특히 sed, awk, envsubst 같은 쉘 치환 도구들은 로컬에서 검증하기가 애매한 영역이라 코드리뷰에서도 그냥 넘어가기 쉽다.

db.ts 같은 파일은 변경 빈도가 낮다 보니 오히려 리뷰 집중도도 낮아지는 경향이 있다. 근데 그만큼 잘못 들어간 값이 오래 살아남는다. 다음에 배포 스크립트 건드릴 일 있으면 envsubst 전환도 한 번 검토해볼 것 같다. sed보다 quote 문제에서 훨씬 자유롭다.

끝.

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

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

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