개발자라면 한 번쯤은 겪어봤을, 아니 어쩌면 매일매일 마주하고 있을지도 모를 그 이름, ‘STATUS_MODULE_NOT_FOUND’! 이 녀석이 갑자기 나타나면 등골이 서늘해지고, 하루가 꼬이는 건 순식간이죠. 웹 서버 아파치에서 ‘lynx: command not found’ 메시지를 띄우거나, Vue.js 프로젝트에서 ‘Can’t resolve module’ 경고를 뱉어낼 때, 심지어 파이썬 환경에서 ‘mysql_config not found’ 같은 황당한 오류를 만났을 때까지, 정말 다양한 상황에서 우리를 당황하게 만듭니다.
특히 최근에는 복잡해지는 개발 환경, 컨테이너화된 배포 방식, 그리고 셀 수 없이 많은 라이브러리 의존성 때문에 이 모듈 누락 에러는 더욱 흔한 골칫거리가 되어가고 있어요. 단순히 경로 문제일 수도 있고, 환경 변수 설정 오류, 심지어 최신 버전 충돌 같은 예상치 못한 원인일 때도 많죠.
왜 내 코드는 잘 돌아가던 모듈을 못 찾겠다고 하는 걸까요? 이 답답함을 한 번에 날려버릴 수 있는 명쾌한 해답과 해결 꿀팁들을 지금부터 제가 확실히 알려드릴게요!
개발자라면 한 번쯤 겪어봤을, 아니 어쩌면 매일 마주하고 있을지도 모를 그 이름, ‘모듈을 찾을 수 없습니다’ 에러!
그 모듈, 대체 어디로 사라진 걸까요?
어리석은 경로 설정, 우리가 놓치는 가장 기본적인 실수
제가 직접 겪었던 일인데, 얼마 전 새로운 프로젝트를 시작하면서 Vue.js 에서 ‘Can’t resolve module’ 에러가 계속 뜨는 거예요. 분명 구문은 똑같이 썼는데, 이전 프로젝트에서는 아무 문제 없었거든요. 몇 시간을 삽질하다가 겨우 알아낸 건, 별칭()을 사용하면서 를 하나 빼먹었지 뭐예요!
‘@components’라고 써야 할 걸 ‘@component’라고 쓰고 있었던 거죠. 이런 사소한 실수가 정말 사람을 미치게 만든다니까요. 파일 경로의 대소문자 문제도 흔해요.
특히 리눅스나 macOS 같은 운영체제에서는 대소문자를 엄격하게 구분하니까, 윈도우에서 잘 되던 코드가 서버에 올리자마자 에러를 뿜어내는 경우가 비일비재하답니다. 이런 건 정말 ‘아차!’ 싶을 때가 많아요. 저도 한 번은 폴더를 로 써서 한참을 헤맸던 기억이 있네요.
이렇게 기본적인 경로 설정에서 문제가 생기면 다른 복잡한 원인을 찾느라 시간을 허비하기 쉬우니, 가장 먼저 내 눈으로 경로를 한 번 더 꼼꼼히 확인하는 습관을 들이는 게 중요해요.
나도 모르게 지워진, 혹은 설치되지 않은 녀석들
가끔은 너무나 당연하게 설치되어 있을 거라고 생각했던 모듈이 사라지거나, 아예 설치조차 안 되어 있을 때가 있어요. 아파치 웹 서버에서 명령을 실행했는데 ‘lynx: command not found’라는 메시지가 뜨는 것도 같은 맥락이죠. 이건 라는 웹 브라우저 프로그램이 서버에 설치되어 있지 않거나, 환경 변수 에 경로가 제대로 설정되어 있지 않아서 생기는 문제거든요.
파이썬에서 를 설치할 때 ‘OSError: mysql_config not found’ 에러가 발생하는 경우도 마찬가지예요. 이건 모듈이 제대로 빌드되려면 필요한 같은 개발 라이브러리가 미리 설치되어 있어야 하는데, 그걸 깜빡하고 설치하지 않아서 생기는 일이거든요. 마치 요리를 할 때 필요한 재료를 미리 준비하지 않고 갑자기 ‘재료 없음!’이라고 외치는 것과 같아요.
이런 상황에서는 당황하지 말고, 에러 메시지에 언급된 모듈이나 라이브러리가 내 시스템에 실제로 존재하는지, 그리고 필요한 모든 종속성이 설치되어 있는지 차분히 확인해보는 게 답이랍니다.
꼬리에 꼬리를 무는 의존성 지옥, 어떻게 헤쳐나갈까?
얽히고설킨 라이브러리, 의존성 충돌의 늪
개발을 하다 보면 여러 라이브러리를 사용하게 되는데, 이 라이브러리들이 서로 다른 버전의 또 다른 라이브러리를 요구하는 경우가 있어요. 예를 들어, 내가 A라는 라이브러리 버전 1.0 을 쓰고 있는데, 얘가 C 라이브러리 버전 1.5 가 필요하다고 해요. 그런데 다른 B라는 라이브러리 버전 2.0 은 C 라이브러리 버전 3.0 이 필요하다고 주장하는 거죠.
이런 상황에서 ‘Module not found’ 에러가 발생하면 정말 머리가 지끈거린답니다. Gradle 같은 빌드 도구는 이런 의존성 충돌을 나름의 규칙에 따라 해결하려고 하지만, 때로는 해결하지 못하고 에러를 뿜어내곤 해요. 제가 예전에 Node.js 프로젝트에서 npm install 만 하면 계속 에러가 났는데, 알고 보니 몇몇 패키지가 서로 호환되지 않는 버전의 서드파티 라이브러리를 요구하고 있었던 거예요.
이때는 나 같은 명령어로 의존성 트리를 확인해서 어떤 녀석들이 문제인지 파악하고, 버전을 맞춰주거나 같은 옵션을 사용해서 강제로 특정 버전을 사용하도록 설정해줘야 해요. 정말이지, 의존성 관리는 개발자의 숙명인 것 같아요.
개발 환경과 배포 환경, 다른 점이 문제라고?
“내 로컬에서는 잘만 돌아가는데, 서버에 올리기만 하면 왜 에러가 날까요?” 개발자라면 한 번쯤 해봤을 하소연이죠? 도커(Docker) 컨테이너에서 ‘ModuleNotFoundError’가 발생하는 경우가 딱 이런 케이스예요. 로컬 환경에서는 필요한 모듈이 전역적으로 설치되어 있거나, PATH 환경 변수에 경로가 잘 잡혀 있어서 문제가 없는데, 막상 도커 컨테이너는 격리된 환경이라서 그 모듈을 찾지 못하는 거죠.
| 에러 유형 | 주요 원인 | 흔한 해결책 |
|---|---|---|
| Module not found (경로 문제) |
|
|
| Command not found (외부 명령어) |
|
|
| Missing dependencies (종속성 누락) |
|
|
특히 도커 이미지 빌드 시 명령어 하나로 모든 걸 해결했다고 생각하기 쉽지만, 이때 중요한 건 설정과 파일이에요. 불필요한 파일들이 컨테이너로 복사되지 않도록 를 잘 설정하고, 같은 종속성 파일은 먼저 복사해서 을 한 다음, 나머지 소스를 복사하는 멀티 스테이지 빌드 방식을 사용하면 이런 문제를 줄일 수 있어요.
또한, 파이썬 프로젝트에서 가 발생하면 에 모듈 경로를 직접 추가해주는 방법도 있답니다. 개발 환경과 배포 환경의 차이를 이해하고, 그에 맞는 설정을 해주는 것이 정말 중요하죠.
버전의 늪, 예상치 못한 복병들
내가 쓴 코드는 그대로인데, 갑자기 왜 안돼?
개발자들이 가장 당황하는 순간 중 하나가 바로 이거 아닐까요? 어제까지 잘 돌아가던 코드가 오늘 갑자기 ‘Module not found’ 에러를 뿜어낼 때 말이에요. 이런 경우엔 보통 라이브러리나 프레임워크의 ‘버전’ 문제가 숨어있을 때가 많아요.
다른 팀원이 새 버전을 설치했거나, CI/CD 파이프라인에서 최신 버전이 자동으로 업데이트되면서 기존 코드와의 호환성이 깨지는 거죠. 특히 Vue.js 같은 프레임워크에서 특정 모듈이 갑자기 인식되지 않는다면, 웹팩(Webpack) 버전 5 에서의 주요 변경 사항 때문에 Node.js 코어 모듈의 폴리필(Polyfill)이 기본적으로 포함되지 않아서 생기는 문제일 수 있어요.
이런 경우 을 설치하고 에 관련 코드를 추가해줘야 한답니다. 정말이지, 버전은 항상 우리의 발목을 잡는 것 같아요.
최신 버전이 항상 답은 아니더라
저도 ‘최신이 최고’라는 생각으로 무조건 최신 버전만 고집했던 시절이 있었는데요, 그러다 몇 번 크게 데였답니다. 특정 모듈이 최신 버전으로 업데이트되면서 기존에 사용하던 API가 변경되거나 아예 제거되는 바람에 코드를 대폭 수정해야 했던 경험도 있고요. 반대로 너무 오래된 버전을 사용해서 최신 운영체제나 다른 라이브러리와 호환성 문제가 생기는 경우도 많아요.
파이썬의 처럼, SSL 모듈이 없어서 HTTPS URL에 연결할 수 없다는 에러가 나는 경우, 이건 파이썬 환경 자체의 문제일 수도 있지만, 라이브러리의 특정 버전과 파이썬 버전 간의 호환성 문제일 수도 있다는 거죠. 가장 좋은 방법은 프로젝트를 시작하기 전에 사용할 라이브러리의 버전을 명확히 정의하고 나 같은 파일을 통해 버전을 ‘고정’하는 거예요.
그리고 새로운 버전을 적용할 때는 항상 테스트 환경에서 충분히 검증하는 과정을 거쳐야 해요. ‘선 업데이트 후 확인’은 개발자의 악몽이 될 수 있습니다!
꼼꼼한 진단, 빠른 해결의 지름길
에러 로그, 개발자의 가장 친한 친구
‘Module not found’ 에러를 만났을 때, 많은 개발자들이 바로 구글링부터 시작하곤 하죠. 저도 물론 그렇게 합니다만, 가장 먼저 해야 할 일은 바로 에러 메시지를 꼼꼼히 읽는 거예요. 에러 메시지 안에는 이미 답의 절반이 들어있다고 해도 과언이 아니거든요.
예를 들어, ‘Can’t resolve ‘axios” 같은 메시지는 모듈을 찾을 수 없다는 뜻이니까, 가 제대로 설치되었는지, 아니면 경로가 잘못되었는지부터 확인해야 한다는 단서를 주는 거죠. Vue.js 에서 모듈을 찾을 수 없다는 에러는 웹 브라우저 환경에서 파일 시스템 모듈을 직접 사용할 수 없기 때문에 발생하는 경우가 많고요.
저도 처음에는 에러 메시지가 너무 길고 복잡해서 제대로 안 보려고 했었는데, 지금은 에러 메시지에 어떤 파일, 어떤 라인에서 어떤 모듈을 못 찾는지 명확하게 나오면 ‘오케이, 이제 어디를 봐야 할지 알겠다!’ 하고 반갑게 느낄 정도예요. 에러 로그는 단순히 오류를 알려주는 것을 넘어, 문제 해결의 방향을 제시해주는 나침반과 같답니다.
환경 변수, 이 복병을 놓치지 마세요
개발 환경을 설정하다 보면 , , 같은 환경 변수를 건드릴 때가 많아요. 이 환경 변수들은 시스템이 특정 실행 파일이나 라이브러리를 어디에서 찾아야 할지 알려주는 역할을 하죠. 만약 이 변수들이 잘못 설정되거나 필요한 경로가 누락되면, 아무리 모듈이 제대로 설치되어 있어도 ‘not found’ 에러가 발생할 수 있어요.
제가 한 번은 파이썬 프로젝트에서 특정 라이브러리를 로 설치했는데도 계속 가 뜨는 거예요. 알고 보니 환경 변수에 가상 환경 경로가 제대로 추가되어 있지 않아서 파이썬 인터프리터가 설치된 모듈을 찾지 못하고 있었던 거죠. 이런 상황은 특히 컨테이너 환경이나 가상 환경을 사용할 때 자주 발생하니, 모듈이 제대로 설치되어 있는데도 에러가 난다면 환경 변수를 한 번쯤 의심해봐야 합니다.
(리눅스/macOS)나 (윈도우) 명령으로 현재 환경 변수 설정을 확인하고, 필요하다면 적절한 경로를 추가해주는 것이 중요해요.
미리미리 예방하는 습관, 최고의 방어책
개발 환경 표준화로 혼란 줄이기
프로젝트를 진행하다 보면 여러 개발자가 각자의 환경에서 작업하게 되는데, 이때 개발 환경이 조금씩 달라서 문제가 생기는 경우가 많아요. “내 컴퓨터에서는 잘 되는데, 네 컴퓨터에서는 왜 안 돼?”라는 말이 괜히 나오는 게 아니죠. 이를 방지하기 위한 가장 좋은 방법은 개발 환경을 표준화하는 거예요.
Docker 를 사용해서 개발 환경을 컨테이너화하면 모든 개발자가 동일한 환경에서 작업할 수 있어서 모듈 누락이나 버전 충돌 같은 문제를 사전에 방지할 수 있어요. 저도 예전에 팀원들과 각자 다른 운영체제와 파이썬 버전을 사용하다가 라이브러리 호환성 문제로 진땀을 뺀 적이 있었거든요.
그때 도커를 도입하고 나서부터는 그런 문제가 확 줄었답니다. 이나 같은 의존성 관리 파일을 철저하게 관리하고, 훅 같은 도구를 활용해서 커밋 전에 기본적인 검사를 수행하는 것도 좋은 방법이에요. 개발 환경을 잘 정비해두면 나중에 발생할 수 있는 수많은 에러들을 미리 막을 수 있다는 사실, 꼭 기억해두세요.
정기적인 업데이트와 점검의 중요성
소프트웨어는 살아있는 생명체와 같아서 끊임없이 변화하고 발전해요. 새로운 기능이 추가되거나 보안 취약점이 패치되기도 하고, 때로는 기존 기능이 deprecated 되기도 하죠. 그래서 사용하는 라이브러리나 프레임워크를 정기적으로 업데이트하고 점검하는 것이 중요해요.
물론 업데이트가 항상 쉬운 일만은 아니지만, 너무 오래된 버전을 사용하다 보면 나중에 한꺼번에 큰 문제를 겪을 수 있답니다. 저도 한동안 바쁘다는 핑계로 몇 달간 프로젝트 의존성 업데이트를 미뤘다가, 나중에 한 번에 업데이트하려고 하니 수많은 경고와 에러가 터져 나와서 며칠 밤을 새운 적이 있어요.
중요한 건 업데이트하기 전에 변경 로그(Changelog)를 꼼꼼히 확인하고, 작은 단위로 업데이트하면서 문제가 없는지 충분히 테스트하는 거예요. 보안 취약점 점검 도구를 활용해서 현재 사용 중인 라이브러리에 알려진 문제가 없는지 확인하는 것도 잊지 말아야겠죠. 꾸준한 관심과 노력이 ‘Module not found’의 악몽에서 우리를 지켜줄 거예요.
글을 마치며
휴, 정말 개발자라면 한두 번이 아니라 매번 마주하는 ‘모듈을 찾을 수 없습니다’ 에러에 대해 함께 깊이 파헤쳐 봤네요! 이 골칫덩이 에러는 단순히 코딩 실수의 문제가 아니라, 경로 설정부터 환경 변수, 복잡한 의존성, 그리고 개발 및 배포 환경의 차이까지 다양한 원인에서 비롯된다는 것을 알 수 있었어요. 하지만 걱정 마세요. 오늘 제가 알려드린 꿀팁들을 차근차근 적용해 본다면, 다음번에는 훨씬 더 침착하고 능숙하게 문제를 해결할 수 있을 거예요. 모듈 에러는 우리를 괴롭히는 존재가 아니라, 더 견고하고 안정적인 시스템을 만들 수 있도록 이끌어주는 소중한 선생님이라는 점, 꼭 기억해 주셨으면 좋겠습니다!
알아두면 쓸모 있는 정보
여러분들의 개발 여정을 더욱 쾌적하게 만들어 줄 몇 가지 핵심 꿀팁들을 정리해 보았어요. 직접 해보면 알겠지만, 이 작은 습관들이 정말 큰 차이를 만든답니다.
1. 에러 메시지는 내비게이션! 에러 로그를 대충 넘기지 마세요. 어떤 파일의 몇 번째 줄에서 어떤 모듈을 못 찾았는지 정확히 알려주는 가장 확실한 단서예요. 저도 처음엔 겁먹었지만, 이 친구와 친해지면 문제 해결 속도가 두 배는 빨라져요. 에러 메시지에 나온 키워드로 구글링을 시작하면 대부분의 경우 유사한 문제를 겪었던 다른 개발자들의 해결책을 쉽게 찾을 수 있답니다.
2. 환경 변수 점검은 필수! PATH, PYTHONPATH, NODE_PATH 같은 환경 변수는 시스템이 프로그램을 찾는 길잡이와 같아요. 개발 환경을 바꾸거나 새로운 모듈을 설치했는데도 ‘not found’ 에러가 뜬다면, 십중팔구 이 변수들이 제대로 설정되지 않았을 가능성이 커요. 특히 가상 환경이나 컨테이너 환경에서는 꼭 확인해봐야 할 체크리스트 중 하나입니다. (리눅스)나 (윈도우)로 현재 설정을 확인하고 필요에 따라 수정하는 습관을 들이세요.
3. 의존성 관리는 ‘미리미리’! 프로젝트 시작 전 이나 에 사용할 라이브러리 버전을 명확히 명시하고 고정하는 것이 정말 중요해요. 저처럼 ‘버전은 최신이 최고!’라며 무작정 업데이트하다가 낭패 보는 일이 없도록 말이죠. 개발 초기에 의존성 버전을 잘 관리해두면 나중에 예상치 못한 호환성 문제로 밤새는 일이 훨씬 줄어들 겁니다.
4. 개발 환경 표준화로 ‘내 컴퓨터 병’ 퇴치! “내 컴퓨터에선 잘 되는데…” 이 말, 개발자라면 다들 공감하시죠? Docker 같은 컨테이너 기술을 활용해서 개발 환경을 표준화하면 모든 팀원이 동일한 환경에서 작업할 수 있어요. 이렇게 하면 개발 환경 차이로 인한 모듈 누락이나 버전 충돌 같은 불필요한 논쟁과 시간 낭비를 확 줄일 수 있답니다. 협업의 효율성을 높이는 가장 확실한 방법 중 하나예요.
5. 정기적인 업데이트, 그러나 ‘신중하게’! 사용하는 라이브러리나 프레임워크는 꾸준히 업데이트해주는 것이 좋아요. 보안 취약점 패치나 성능 개선이 이루어지니까요. 하지만 무조건 최신 버전으로 올리기보다는, 업데이트 전 변경 로그(Changelog)를 꼼꼼히 확인하고 테스트 환경에서 충분히 검증한 후 적용하는 ‘신중함’이 필요해요. 급할수록 돌아가라는 말이 딱 맞는 경우죠.
중요 사항 정리
‘모듈을 찾을 수 없습니다’ 에러는 개발자의 숙명이자 성장을 위한 발판이라고 할 수 있습니다. 이 에러를 마주했을 때 가장 중요한 것은 당황하지 않고, 체계적으로 문제에 접근하는 태도예요. 에러 메시지를 꼼꼼히 읽는 것부터 시작해서, 파일 경로, 필요한 모듈의 설치 여부, 환경 변수 설정, 그리고 라이브러리 간의 의존성 충돌까지, 마치 CSI 수사관처럼 차근차근 원인을 찾아나가야 해요. 때로는 개발 환경과 배포 환경의 차이에서 문제가 발생하기도 하고, 버전 호환성 때문에 예측하지 못한 복병을 만나기도 합니다. 하지만 이런 문제들을 하나하나 해결해나가면서 우리의 문제 해결 능력은 더욱 단단해지고, 결국 더 안정적이고 효율적인 코드를 작성할 수 있는 진정한 전문가로 성장하게 될 거예요. 포기하지 않고 끈기 있게 파고드는 것이 개발자의 가장 큰 미덕이라는 점을 기억하면서, 오늘 얻은 꿀팁들이 여러분의 개발 여정에 큰 도움이 되기를 진심으로 바랍니다. 우리는 이 작은 에러들을 통해 더 큰 시스템을 이해하는 소중한 경험을 얻게 되는 거니까요!
자주 묻는 질문 (FAQ) 📖
질문: 개발자를 이렇게 속 태우는 ‘Module Not Found’ 오류, 대체 왜 생기는 걸까요?
답변: 아, 정말 개발자라면 한 번쯤은 만나봤을 법한 이 지긋지긋한 ‘Module Not Found’ 에러! 저도 처음엔 얼마나 당황했는지 몰라요. 이게 말 그대로 ‘야, 너 필요한 거 없는데?
어디다 뒀어!’ 하고 컴퓨터가 빽 소리 지르는 거랑 똑같거든요. 가장 흔한 이유는 크게 두 가지예요. 첫째, 정말로 그 모듈이나 라이브러리가 설치되어 있지 않은 경우예요.
‘pip install’이나 ‘npm install’ 같은 설치 명령을 깜빡했거나, 운영체제에서 필요한 패키지 (예를 들어, Python 의 오류라면 같은)를 설치하지 않은 경우가 많죠. 둘째는 설치는 했는데, 컴퓨터가 어디에 있는지 못 찾는 경우예요.
환경 변수 설정이 잘못되어 있거나, 가상 환경을 사용하는데 활성화가 안 되어 있거나, 아니면 프로젝트 내에서 모듈을 불러오는 경로가 틀린 경우가 그렇죠. 제가 직접 여러 프로젝트를 해보면서 느낀 건데, 특히나 여러 버전의 파이썬이나 노드를 왔다 갔다 할 때 이런 경로 문제가 많이 발생하더라고요.
정말이지 사소해 보여도 우리 개발자들을 밤새게 만드는 주범 중 하나죠!
질문: 그럼 이 ‘Module Not Found’ 오류, 어떻게 해결해야 할지 막막한데, 해결할 수 있는 만능 꿀팁이라도 있을까요?
답변: 물론이죠! 제가 겪었던 경험을 바탕으로 ‘이거 해보면 십중팔구 해결된다!’ 싶은 꿀팁들을 알려드릴게요. 먼저 가장 기본적이면서도 중요한 건, 에러 메시지를 꼼꼼히 읽는 거예요.
‘어떤 모듈을 못 찾겠다’라고 정확히 알려주기 때문에, 그 이름을 구글에 검색해보는 것부터 시작하는 거죠. 대부분은 설치 명령어를 찾아낼 수 있을 거예요. 만약 설치했는데도 못 찾는다면, 환경 변수 를 확인해 보세요.
특히 리눅스나 macOS 환경에서는 터미널에서 를 쳐보고, 해당 모듈의 실행 파일이 있는 경로가 포함되어 있는지 확인해야 해요. 파이썬 프로젝트라면 가상 환경(나 )을 사용하는 게 정말 중요해요! 프로젝트별로 의존성을 분리해서 관리하면 이런 모듈 충돌이나 누락 문제를 확 줄일 수 있답니다.
웹 프로젝트(Vue.js 처럼)에서는 폴더를 지우고 이나 을 다시 해보는 것만으로도 거짓말처럼 해결되는 경우가 많아요. 서버 쪽 문제(Apache 같은)라면 처럼 해당 명령어를 설치해주면 바로 해결됩니다.
제가 직접 겪어보니, 대부분은 이 팁들 안에서 답을 찾을 수 있었어요!
질문: 특정 개발 환경에서 자주 발생하는 ‘Module Not Found’ 오류는 어떤 것이 있고, 각 환경에 맞는 해결책이 궁금해요!
답변: 네, 특정 환경에서 유독 자주 출몰하는 ‘Module Not Found’ 악당들이 있죠. 제가 자주 만났던 녀석들을 환경별로 나눠서 해결책을 좀 더 구체적으로 알려드릴게요. 첫째, 파이썬 환경에서는 나 같은 특정 라이브러리에서 ‘module not found’나 ‘config not found’ 오류가 뜨는 경우가 많아요.
이건 파이썬 모듈 자체의 문제가 아니라, 해당 모듈이 의존하는 C 라이브러리나 개발 도구가 시스템에 설치되어 있지 않아서 발생하는 경우가 태반이에요. 예를 들어, 라면 (데비안/우분투 계열)나 (레드햇 계열)처럼 데이터베이스 개발 라이브러리를 설치해주면 해결돼요.
같은 GUI 자동화 툴은 X Window System 관련 라이브러리가 필요한 경우도 있고요. 항상 에러 메시지에 나오는 ‘config not found’ 키워드를 놓치지 마세요! 둘째, 웹 프런트엔드 (특히 Vue.js 같은 SPA)에서는 ‘Can’t resolve module’ 오류를 정말 자주 보게 되죠.
대부분은 에 정의된 의존성 패키지가 제대로 설치되지 않았거나, 버전 충돌로 인해 발생해요. 이때는 폴더와 또는 파일을 완전히 삭제한 다음, 또는 명령으로 의존성을 깨끗하게 다시 설치하는 게 가장 효과적이에요.
때로는 캐시 문제일 수도 있으니 같은 명령어를 사용해보는 것도 좋은 방법이고요. 셋째, 리눅스 서버 (Apache 같은)에서 오류는 시스템 에 해당 명령어가 없거나, 아예 설치되지 않은 경우예요.
‘lynx: command not found’처럼 특정 명령어가 없을 때는 해당 패키지를 나 같은 패키지 관리자로 설치해주면 끝! 정말 간단한데 의외로 헤매는 경우가 많죠. 제 경험상, 에러 메시지가 길고 복잡해 보여도 핵심 키워드 몇 개만 잘 파악하면 의외로 쉽게 해결되는 경우가 많답니다!