결론
Window, Mac OS는 case-insensitive(대소문자 무시)
Linux는 case-sensitive(대소문자 구별)
일반적인 OS 환경에서는 파일 명을 바꿀 때, 대소문자 변경일 경우 같은 파일로 인식하여 이름은 바뀌지만 수정되지 않았다고 인식한다.
코딩할 때 파일 명을 변경할 상황이 발생한다면, 직접적으로 바꾸기 보단 명령어를 사용하여 변경해주는게 안전하다.
파일 명 변경 커맨드
git mv (루트경로/폴더../현재 파일명) (루트경로/폴더../변경할 파일명)
과정
컴포넌트명이 소문자인 파일이 있어 앞글자를 대문자로 바꿔주고 모달창의 기능을 테스팅한 코드를 작성 후, 작업 커밋을 깃허브에 푸쉬하고 CI 테스팅을 기다리는데 에러가 발생했다.
확인해보니 모달창 컴포넌트의 경로가 잘못되었다고 하더라. 이 때는 단순히 CI가 파일의 절대경로를 못 읽어와서 생긴 에러라고 착각했다.

하지만 그 후로도 파일 명을 다시 바꿔보거나 경로를 재 지정해줘도 같은 오류가 반복되어 발생했다.
이 때 PR에서 File changed를 잘 확인했다면 금방 원인을 찾았을 텐데, 에러는 날지언정 파일명이 안 바뀌었다는 생각은 아예 배제되어 있었다.

결국 코드리뷰해주는 재희님을 불러서 도움을 청했는데, 확실히 현직자이다 보니 경험으로 인한 에러체킹이 남달랐다. 바로 원인을 찾고 기존 작업을 복기해봤다.
이전에 컨벤션을 잘 몰랐을 때 파일명을 편한대로 작성했던 적이 있었는데, 카멜케이스를 자주 사용했기 때문에 컴포넌트명도 그대로 카멜케이스로 작성했었다.
나중에 어느 기업에서 면접봤을 때, 굳이 컴포넌트명을 이렇게 작성한 이유가 있냐는 질문을 듣고 뇌정지가 와서 그 후로 표기법을 고쳤다. 하지만 손에 배어서 그런지 한 번씩 카멜로 작성할 때가 있어서, 해당 파일을 대문자로 바꿔주는 일이 잦았다.
이번에도 어김없이 카멜로 된 파일을 찾았고 해당 이름을 그냥 F2로 바꿔주었는데, vscode는 파일명이 변경될 때 해당 파일을 import하는 경로에도 바로 업데이트를 해주기 때문에 문제가 없다고 생각한 것이 잘못됐었다.
Window나 Mac에서는 대소문자가 변경되어도 이를 무시하기 때문에 같은 파일이라고 인식한다.
하지만, 리눅스 기반의 Git에서는 대소문자도 구별하기 때문에 여기에서 에러가 발생한 것이다.
한 시간동안 삽질하고 허무하게 이유를 알았더니 오히려 더 기억에 남아 실수를 줄일 수 있을 것 같다.
명령어를 이용해 파일명을 변경해주니 제대로 인식되어 CI 테스팅이 통과됐다.
코드 개발만 잘 하면 1인분은 한 줄 알았는데, 챙겨야 할 디테일이 한 두가지가 아니여서 매운 맛을 보고 있다.
'개발 TIL' 카테고리의 다른 글
| pnpm + vite 프로젝트 설치 명령어 (1) | 2025.06.23 |
|---|---|
| expo 앱 빌드 명령어 정리 (0) | 2025.06.14 |
| React-Native Modal (0) | 2025.04.30 |
| Jest expect() (0) | 2025.04.24 |
| react-native expo에서 jest testing (0) | 2025.04.23 |