이번 프로젝트는 정말 오류가 많이 발생했다.
앞선 적었던 두 개의 문제들 (문제1, 문제2)도 쉽진 않았지만 잘 마무리짓고 vercel을 통해서 배포하여 웹 페이지가 잘 동작하고 UI가 잘 렌더링되는지 확인하고자 했다.
근데?! 막판에 넣은 부가적인 내용인 포켓몬 타입 이미지 삽입에서 오류가 발생했다.
이 부분부터 순서를 매겨 오류에 대한 나의 디버깅 과정을 가감없이 나타내고자한다.
1. 처음에는 이미지 파일의 위치에 대한 의문점이 들었다.
찾다보니 vite는 정적인 이미지는 명시적으로 Public 폴더에 넣고, 동적인 이미지는 src 폴더 안에서 관리한다는 것을 알게됐다.
그 이유는 vite의 빌드 과정에서 차이점 때문이다.
Public-> 빌드 시 변환되지 않음, 폴더 구조 유지, 그렇기에URL로 접근 해야함src-> 빌드 시 모듈화 혹은 최적화 처리,asset handling적용, 모듈화 되기에URL로 접근 시 파일에 접근 불가
때문에 최초 수정 시에 Public 폴더로 이미지들을 옮겼다.
그러나 이후에도 해당 파일을 접근할 수 없다는 오류 메시지만 보게됐다.
2. 사실 이 당시에는 위에서 설명한 내용에 위반되는 코드를 작성했다.
Public으로 이미지 경로를 변경했으면 import를 통해 모듈로 불러오는 것이 불가능하지만, 모든 이미지 파일을 한꺼번에 처리하고 싶어서
const svgModules = import.meta.glob(
"/public/image/Details/*.svg", {eager: true,});해당 코드로 진행했지만 여전히 이미지는 적용되지 않았다.
(당연한 결과)
3. 결과적으로 해당 내용을 깨달았다.
그렇지만 처음처럼 src 파일로 옮겨도
const svgModules = import.meta.glob(
"/src/asset/image/Details/*.svg", {eager: true,});Failed to load resource: the server responded with a status of 404 ()계속해서 값을 찾지 못한다는 메시지만 받게됐다.
4. 그래서 오류가 날만한 것들을 수정하기 시작했다.
처음으론 한글로 작성된 이미지 파일명을 모두 영어로 변경하여 파일에 적용했다.
사실 dev 환경에서는 문제없이 렌더링 됐지만 배포 환경에서는 파일 이름이 깨져서 오류가 날 수도 있다는 조원 분의 피드백이 있었기에 즉시 수정했다.
5. 계속해서 오류가 발생했다.
The page could not be found
NOT_FOUND
icn1::rp6vg-1739148107944-276ea146ac6f해당 메시지는 vercel에서 배포를 위해 run build 실행 시 해당 이미지의 경로를 찾을 수 없어서 생기는 메시지였던 것이다.
6. 그러다 vite에서 작은 이미지 파일에 대해서는 경로로 접근이 불가능하다는 사실을 알아냈다.
검색을 통해서 이미지의 크기가 4kb 미만일 경우 Base64 포맷으로 인한 URL 접근이 불가능하다고 해서 해당 방법들을 적용했다.
그러나 계속된 오류..
사실 이 내용을 찾아 냈을 때 '와! 이런 내용이 존재했구나!! 무조건 되겠다!' 라고 생각했지만?
진짜 김칫국을 한사발 들어 마셨다...
7. 사실 정리하자면..
Public폴더는 이미지를 가져오기 위해URL로 접근해야 함src안에 있는 폴더는 이미지를 가져오기 위해import로 모듈화를 통해 사용해야 함- 그런데, 현재
src폴더 안에서URL로 이미지를 접근하려다 보니vite로 빌드된 후 해당URL로 접근이 불가하여 오류가 나는 것
그렇다면 제대로 이미지를 가져오기 위해선
Public폴더에 이미지 삽입 후URL로 이미지 가져오기
혹은src안에 이미지 삽입 후import를 통해 이미지 접근
해결 방법은 매우 심플했다.
해당 이미지는 state나 동적으로 변경되는 것이 아니기 때문에 Public에 이미지를 넣고, URL로 이미지를 가져올 수 있도록 코드를 변경했다.
const matchingFiles = (type) => `/image/${TypeName[type]}.svg`;마무리..
지금은 해당 내용을 정리하고 오류를 다시 검색하여 확인하면서 글을 쓰다보니 매우 간단한 원인 파악 및 해결방법을 찾을 수 있었지만,
오류 디버깅 당시에는
dev 환경과 다른배포 환경에서의 동작- 계속해서 같은 내용을 확인하고 코드를 작성하다보니 이전에 작성했던 내용을 체크하지 못 함
- 정리하지 않고 코드로만 디버깅하다보니 오류 내용에 대한 정확한 인지 X
등의 원인들이 겹치다 보니 수정 작업이 길어지게 된 것이다.
덕분에 문제 상황이 겹치는 개발환경을 경험할 수 있었다.
실제 상황에서는 서비스 제공을 혼자서만 감당하는 것이 아니라 각 부서가 나눠서 담당하겠지만, 디버깅에 대한 수정은 내가 검증하고 고쳐나가는 거 말곤 없다고 생각한다.
그렇기 때문에 이와 같은 상황에서 오류 내용을 정확히 인지하고, 검증 리스트? 혹은 수정 내용을 정리하면서 체계적인 방식을 수행해야된다는 걸 깨달았다.
이번 트러블 슈팅은 나의 개발적 능력 뿐만 아니라 문제를 바라보고 해결하는 나의 관점을 발전시키는 계기가 될 수 있다고 생각한다.
