지난 글에서 다룬 링크 문제를 고치고, 로컬에서 빌드가 정상적으로 되는 것까지 확인한 뒤 커밋하고 푸시했다. 그런데 배포는 실패했다.
”모듈을 찾을 수 없다”는데, 방금 내 컴퓨터에선 됐다
에러 메시지는 Cannot find module 'github-slugger'였다. 이 새 기능에서 실제로 이
라이브러리를 직접 불러다 쓰고 있었으니, 없으면 당연히 안 될 텐데 — 방금 내 컴퓨터에서는
분명히 빌드가 성공했다.
원인은 금방 나왔다. 이 라이브러리를 내 프로젝트에 정식으로 추가한 적이 없었다. 대신 이
사이트가 쓰는 프레임워크 자체가 내부적으로 같은 라이브러리를 쓰고 있어서, 이미 설치된
패키지들 사이 어딘가에 끼어 있었을 뿐이었다. 그런데 내 로컬 환경은 몇 달치 세션 동안 쌓여온
node_modules라, 어쩌다 보니 그 라이브러리를 우연히 찾아낼 수 있었던 것 같았다. 반면
배포 환경은 매번 완전히 새로 설치하니, 정식으로 등록되지 않은 건 찾을 수가 없었다.
“로컬 빌드 성공”이 실제로 증명한 건 “이 코드가 맞다”가 아니라 “지금 이 컴퓨터의, 지금까지 쌓여온 우연한 상태에서는 된다”였다. 둘은 다른 얘기였다.
완전히 새로 설치해서 재현해보기
이 라이브러리를 정식으로 추가하고 나서, 이번엔 확인 방법을 바꿨다. node_modules를
통째로 지우고 처음부터 다시 설치한 뒤 빌드해봤다. 그랬더니 또 다른 에러가 났다 — 타입
정의를 가져오는 다른 두 패키지도 똑같이 정식으로 등록이 안 되어 있었다. 이번엔 이런 문제가
하나가 아니라 클래스 전체로 있었다는 뜻이었다.
전부 정리하고 나서, 아예 깃허브에서 새로 클론까지 해서 설치하고 빌드해본 뒤에야 안심할 수 있었다. 로컬 컴퓨터의 특수한 상태에 기대지 않고, 배포 환경이 실제로 보게 될 것과 최대한 비슷한 조건에서 확인한 것이다.
링크를 고치다가, 전혀 다른 버그를 만났다
깨진 링크에 옛날 주소로 들어오는 사람들을 위해 리다이렉트도 만들어두기로 했다. 그런데 이 설정 파일을 추가하자마자 빌드가 또 깨졌다 — 이번엔 완전히 다른 이유였다. 이 설정 파일은 확장자가 없는데, 빌드 도구가 이걸 자바스크립트 코드로 착각해서 파싱을 시도하다 실패하고 있었다. 알고 보니 이 프로젝트에서 확장자 없는 파일을 정적 자원 폴더에 넣은 게 이번이 처음이었다 — 그래서 지금까지 아무도 이 문제를 겪은 적이 없었다.
이건 아예 성격이 다른 버그였다. 앞의 문제가 “필요한 걸 빠뜨렸다”였다면, 이건 “빌드 도구가 파일 하나를 오해했다”였다. 다행히 설정 하나로 “이 파일은 코드가 아니라 그냥 자원으로 취급해라”라고 알려주는 것으로 해결됐다.
배운 점
같은 작업을 배포하는 중에 성격이 전혀 다른 문제를 두 번 만났다. 공통점은 둘 다 로컬에서는 전혀 안 보이던 문제였다는 것이다. 하나는 오래 쌓인 로컬 환경이 진짜 필요한 걸 가려주고 있었고, 다른 하나는 이 프로젝트가 지금까지 한 번도 마주친 적 없는 파일 형태였다. “내 컴퓨터에서는 된다”는 확인은, 그 컴퓨터가 지금까지 겪어온 역사만큼만 유효하다. 배포 환경에 가장 가까운 조건(완전히 새로 설치하는 것, 나아가 아예 새로 내려받는 것)에서 확인해야, 그 역사가 가려온 문제를 미리 볼 수 있다.