JavaScript 작동 안 함 원인 8가지와 Console 확인 순서

스크립트 파일은 Network 탭에서 200으로 잘 내려왔는데 버튼을 눌러도 아무 반응이 없습니다. JavaScript 작동 안 함 상황은 파일이 도착했다는 사실과 코드가 끝까지 실행되었다는 사실이 별개라는 데서 시작합니다.

브라우저는 파일을 받은 뒤 해석하고 실행합니다. 이 과정에서 예외가 하나만 발생해도 그 뒤 코드는 모두 멈춥니다. 화면에는 아무 표시도 나오지 않기 때문에, Console 탭을 열지 않으면 원인을 알 수 없습니다. 이 글은 JavaScript 작동 안 함의 대표 원인을 나누고 확인 순서를 정리합니다.

가장 먼저 Console 탭을 여는 이유

실행 중 발생한 예외는 Console에 붉은 메시지로 남습니다. 메시지에는 오류 종류와 함께 파일 이름, 줄 번호가 표시되므로 수정할 위치가 바로 특정됩니다.

중요한 것은 첫 번째 메시지입니다. 하나의 예외가 연쇄적으로 여러 메시지를 만들어 내는 경우가 많아, 아래쪽 메시지부터 보면 엉뚱한 곳을 고치게 됩니다.

메시지가 하나도 없는데 JavaScript 작동 안 함 상태라면, 코드가 아예 실행되지 않았거나 조건 분기에서 빠져나갔을 가능성이 큽니다. 이 경우 확인 방향이 달라집니다.

가정 예시 — 실제 메시지 문구는 브라우저 버전에 따라 다릅니다

JavaScript 작동 안 함 증상은 대부분 이 다섯 가지 중 하나로 나뉩니다. 어느 형태인지만 정하면 다음에 열 탭이 하나로 정해집니다.

메시지가 여러 개라면 가장 위쪽 것부터 처리해야 합니다. 아래쪽 메시지는 앞선 실패 때문에 생긴 결과인 경우가 많습니다.

실행 순서가 어긋난 경우

스크립트가 문서보다 먼저 실행되면 아직 만들어지지 않은 요소를 찾게 됩니다. 결과값이 비어 있는 상태에서 속성을 읽으려 하면 예외가 발생하고 실행이 중단됩니다.

해결은 스크립트를 문서 끝으로 옮기거나 지연 실행 속성을 붙이는 방식입니다. 문서 구조가 모두 준비된 뒤 실행되도록 순서를 정리하면 증상이 사라집니다.

문서 준비 완료 시점에 실행하도록 감싸 주는 방법도 있습니다. 어느 쪽이든 요소가 존재하는 시점 이후에 코드가 돌도록 만드는 것이 핵심입니다.

의존 라이브러리 순서 문제

기반 라이브러리보다 그것을 사용하는 코드가 먼저 실행되면 함수가 정의되지 않았다는 예외가 납니다. 두 파일 모두 200으로 잘 내려왔는데도 JavaScript 작동 안 함 상태가 되는 전형적인 경우입니다.

워드프레스에서는 스크립트 등록 시 의존 관계를 지정할 수 있습니다. 이 값을 비워 두면 순서가 보장되지 않아 플러그인 조합에 따라 결과가 달라집니다.

비동기 속성을 붙인 스크립트는 도착하는 대로 실행되므로 순서가 뒤바뀔 수 있습니다. 순서가 중요한 파일에는 붙이지 않는 편이 안전합니다.

라이브러리를 쓰는 코드가 라이브러리보다 먼저 실행되면 필요한 값이 아직 없습니다. 이때 남는 메시지는 대부분 “정의되지 않았다”는 형태입니다.

워드프레스처럼 여러 곳에서 스크립트를 불러오는 구조라면 의존 관계를 직접 지정해 두는 편이 안전합니다. 순서를 지정해 두면 파일이 늦게 도착해도 실행 시점이 밀려 문제가 생기지 않습니다.

Network 탭에서 파일이 도착한 시각을 비교하면 순서가 어긋났는지 바로 확인할 수 있습니다. JavaScript 작동 안 함 증상 중 상당수가 이 한 가지 원인에서 나옵니다.

중복 로드와 이름 충돌

같은 라이브러리가 두 번 불러와지면 나중 것이 앞선 것을 덮으면서 이미 등록된 동작이 사라지기도 합니다. 테마와 플러그인이 각자 같은 라이브러리를 등록할 때 자주 생깁니다.

전역 이름이 겹치는 경우도 마찬가지입니다. 서로 다른 코드가 같은 이름의 변수를 쓰면 뒤에 실행된 쪽이 앞선 값을 지웁니다.

Network 탭에서 같은 파일 이름이 두 번 이상 요청되는지 확인하면 중복 여부를 바로 알 수 있습니다. Sources 탭의 파일 목록에서도 확인할 수 있습니다.

같은 라이브러리를 두 번 불러오면 나중에 읽힌 쪽이 앞의 상태를 지웁니다. 앞에서 등록해 둔 이벤트나 설정이 사라지므로 겉으로는 기능이 조용히 멈춘 것처럼 보입니다.

Network 탭에서 같은 이름의 파일이 두 번 이상 보이는지 확인하면 됩니다. 테마와 플러그인이 각자 같은 라이브러리를 포함하는 경우가 대표적입니다.

문법 오류로 파일 전체가 실행되지 않는 경우

해석 단계에서 문법 오류가 발견되면 파일 전체가 실행되지 않습니다. 일부만 동작하는 것이 아니라 처음부터 아무것도 실행되지 않는다는 점이 특징입니다.

최신 문법을 지원하지 않는 브라우저에서 이런 상황이 생깁니다. 특정 브라우저에서만 JavaScript 작동 안 함이라면 문법 호환성을 먼저 확인해 보십시오.

빌드 도구로 변환하는 구성이라면 변환 대상 브라우저 설정을 확인합니다. 설정이 너무 최신으로 잡혀 있으면 구형 브라우저에서 해석에 실패합니다.

문법 오류는 파일 전체를 멈추게 하므로 증상이 유독 넓게 나타납니다. 아래처럼 괄호 하나가 어긋나도 그 파일의 모든 기능이 동작하지 않습니다.

1
2
3
4
5
6

function init() {
  const el = document.querySelector('.btn');
  el.addEventListener('click', onClick;
}

init();

이 경우 Console에는 해당 파일의 줄 번호와 함께 해석에 실패했다는 메시지가 남습니다. 값을 고치기 전에 그 위쪽 문법부터 확인해야 합니다.

빌드 과정을 거치는 구조라면 원본이 아니라 결과 파일을 열어 확인하는 편이 확실합니다. 원본은 정상인데 결과에서 코드가 잘리는 경우가 있습니다.

이벤트가 연결되지 않은 경우

버튼을 눌러도 반응이 없다면 이벤트 연결 자체가 되지 않았을 수 있습니다. 요소를 찾는 코드가 실행되는 시점에 그 요소가 없었다면 연결이 이루어지지 않습니다.

화면이 그려진 뒤 코드로 추가된 요소는 특히 그렇습니다. 이 경우 상위 요소에 연결해 두고 발생 지점을 판별하는 방식으로 처리하면 안정적입니다.

개발자 도구에서 요소를 선택한 뒤 이벤트 목록을 확인하면 실제로 연결되어 있는지 눈으로 볼 수 있습니다.

확장 프로그램과 보안 정책의 개입

광고 차단이나 보안 확장 프로그램이 특정 스크립트를 막으면 파일이 도착하지 않거나 실행이 차단됩니다. 시크릿 창에서 정상이라면 확장 프로그램이 원인입니다.

콘텐츠 보안 정책이 걸려 있는 사이트에서는 문서 안에 직접 적은 코드가 실행되지 않습니다. 이때는 Console에 정책 위반 안내가 함께 출력됩니다.

외부 도메인의 스크립트를 불러오는 경우 출처 정책에 걸릴 수 있습니다. 이 역시 Console 메시지에 사유가 명시됩니다.

가정 예시 — 실제 표시 문구는 브라우저 버전에 따라 다릅니다

차단은 서버가 아니라 브라우저가 스스로 내린 판단입니다. 서버 로그에는 아무 기록이 없으므로 JavaScript 작동 안 함 원인을 서버에서 찾으면 시간을 잃게 됩니다.

중단점으로 실행 흐름을 따라가기

Sources 탭에서 줄 번호를 누르면 그 위치에 중단점이 걸립니다. 페이지를 새로 고쳤을 때 실행이 그 줄에서 멈추면 코드가 도달했다는 뜻이고, 멈추지 않으면 아예 실행되지 않은 것입니다.

멈춘 상태에서는 그 시점의 변수 값을 그대로 확인할 수 있습니다. 요소를 찾는 코드의 결과가 비어 있는지, 서버에서 받은 값이 예상과 다른지 눈으로 확인할 수 있어 추측을 줄여 줍니다.

조건을 붙인 중단점도 유용합니다. 반복 구간에서 특정 값일 때만 멈추도록 설정하면 수백 번 반복되는 코드에서도 원하는 시점만 잡아낼 수 있습니다.

예외가 발생할 때 자동으로 멈추는 설정을 켜 두면 JavaScript 작동 안 함의 원인이 되는 지점을 놓치지 않고 잡을 수 있습니다.

서버에서 받은 데이터가 원인인 경우

코드에는 문제가 없는데 서버에서 온 값의 형태가 달라져 실행이 실패하는 사례도 많습니다. 목록을 기대했는데 빈 값이 오거나, 항목 이름이 바뀐 경우입니다.

Network 탭에서 해당 요청의 응답 본문을 직접 확인하면 바로 드러납니다. 상태 코드는 200이지만 내용이 예상과 다른 상황입니다.

이런 유형은 값이 없을 때의 기본 동작을 정해 두면 예방됩니다. 값이 비어 있어도 실행이 멈추지 않도록 방어적으로 작성하는 편이 안전합니다.

캐시가 옛 코드를 유지하는 경우

수정한 스크립트가 반영되지 않으면 예전 동작이 그대로 남습니다. 개발자 도구에서 캐시 사용을 끄고 새로 고쳐 결과가 달라지면 캐시가 원인입니다.

워드프레스에서는 스크립트 등록 시 버전 값을 함께 지정할 수 있습니다. 이 값을 갱신하면 주소가 달라져 브라우저가 새 파일로 인식합니다.

앞단에 CDN이 있다면 경로 무효화를 함께 수행해야 합니다. 브라우저 캐시만 비워서는 변화가 없습니다.

배포 직후에만 증상이 보인다면 캐시를 먼저 의심하는 편이 빠릅니다. 브라우저, 서버, 앞단 캐시가 각각 사본을 들고 있을 수 있습니다.

한 곳만 비우고 확인하면 결과가 그대로여서 원인이 아니라고 판단하기 쉽습니다. 바깥쪽부터 순서대로 비워 가며 확인해야 합니다.

확인을 마친 뒤 정리할 것

원인을 찾았다면 어떤 단계에서 멈췄는지 기록해 두십시오. 해석 실패인지, 실행 순서 문제인지, 데이터 형태 문제인지만 남겨도 다음 대응이 훨씬 빨라집니다.

같은 유형이 반복된다면 등록 순서와 의존 관계를 코드에 명시하는 것이 근본 해결입니다. 조합에 따라 결과가 달라지는 구조를 그대로 두면 문제가 계속 재발합니다.

테마와 플러그인 조합을 좁히는 방법

워드프레스에서 원인을 찾기 어려울 때는 범위를 좁히는 방식이 효과적입니다. 플러그인을 모두 끈 뒤 증상이 사라지는지 확인하고, 하나씩 다시 켜면서 어느 지점에서 재현되는지 봅니다.

운영 중인 사이트에서 직접 하기 어렵다면 복제본을 만들어 시험하는 편이 안전합니다. 최근에는 대부분의 호스팅이 시험용 사본을 만들어 주는 기능을 제공합니다.

테마를 기본 테마로 잠시 바꿔 보는 것도 좋은 방법입니다. 기본 테마에서 정상이라면 원인은 테마 쪽 코드에 있습니다.

범위가 좁혀지면 해당 플러그인이나 테마의 스크립트 등록 부분만 확인하면 되므로, JavaScript 작동 안 함의 원인을 훨씬 빨리 특정할 수 있습니다.

사용자 제보를 받을 때 물어볼 것

내 화면에서는 정상인데 사용자만 문제를 겪는 경우가 있습니다. 이때는 브라우저 종류와 버전, 설치된 확장 프로그램, 접속 네트워크 세 가지를 먼저 확인하십시오.

가능하다면 Console 화면을 캡처해 달라고 요청하는 편이 가장 확실합니다. 붉은 메시지 한 줄이면 원인 대부분이 특정됩니다.

재현이 되지 않을 때는 조건을 하나씩만 바꿔 가며 확인해야 합니다. 여러 변수를 동시에 바꾸면 무엇이 원인이었는지 알 수 없게 됩니다.

제보를 받을 때는 아래 항목을 함께 물어 두면 확인 왕복이 줄어듭니다.

• 어떤 화면에서 무엇을 눌렀는지
• 브라우저 종류와 버전, 시크릿 창 여부
• Console에 빨간 메시지가 있는지
• 로그인 상태와 계정 권한
• 확장 프로그램 사용 여부
• 다른 기기에서도 같은지

대부분 사용자가 몇 초 안에 답할 수 있는 항목입니다. 이 정보만 있어도 JavaScript 작동 안 함이 특정 환경 문제인지 전체 문제인지 바로 갈립니다.

실행 시간과 성능이 만드는 착시

코드가 정상적으로 실행되고 있는데도 반응이 늦어 동작하지 않는 것처럼 보이는 경우가 있습니다. 무거운 계산이나 많은 요소를 한꺼번에 다루는 코드가 화면 갱신을 붙잡고 있는 상황입니다.

성능 탭에서 기록을 남겨 보면 어느 함수가 시간을 오래 쓰는지 그래프로 확인할 수 있습니다. 특정 구간이 유독 길게 표시된다면 그 부분을 나누어 처리하는 방향을 검토하면 됩니다.

외부 서버 응답을 기다리는 동안 아무 표시가 없으면 사용자는 멈춘 것으로 받아들입니다. 대기 중임을 알리는 표시를 넣어 두는 것만으로도 문의가 크게 줄어듭니다.

코드가 무거우면 화면이 잠시 멈춘 것처럼 보입니다. 사용자는 버튼이 동작하지 않는다고 느끼지만 실제로는 처리 중인 경우가 있습니다.

Performance 탭으로 기록을 남겨 보면 어느 구간이 오래 걸리는지 확인할 수 있습니다. 처리 시간이 길다면 JavaScript 작동 안 함이 아니라 성능 문제로 접근해야 합니다.

누른 직후 화면에 표시를 남기는 것만으로도 체감이 크게 달라집니다. 처리 중이라는 신호가 있으면 사용자가 같은 버튼을 반복해서 누르는 일도 줄어듭니다.

확인 순서를 짧게 정리하면

Console을 열어 첫 붉은 메시지를 읽고, 없으면 Network에서 파일 도착과 응답 본문을 확인합니다. 그다음 Sources에서 중단점을 걸어 실행 여부를 봅니다.

여기까지 정상인데도 반응이 없다면 이벤트 연결과 실행 시점을 확인하면 됩니다. 이 순서를 지키면 JavaScript 작동 안 함의 원인은 대부분 짧은 시간 안에 특정됩니다.

JavaScript 작동 안 함을 좁히는 점검 순서

아래 순서는 위에서부터 차례대로 확인하도록 정리한 것입니다. 앞 단계에서 원인이 드러나면 뒤 단계는 건너뛰어도 됩니다.

1단계 · Console의 첫 번째 메시지 읽기

메시지에 적힌 파일 이름과 줄 번호를 그대로 따라갑니다. 대부분의 원인은 그 줄이나 바로 위쪽에 있습니다.

메시지가 아예 없다면 예외 없이 조용히 끝난 것이므로 조건문과 이벤트 연결을 확인하는 쪽으로 넘어갑니다.

2단계 · 파일이 실제로 실행됐는지 확인

Network 탭에서 해당 스크립트의 상태 코드와 크기를 봅니다. 파일이 오지 않았거나 비어 있으면 코드를 아무리 고쳐도 소용이 없습니다.

파일은 왔는데 실행되지 않았다면 형식 지정이나 문법 오류를 의심합니다.

3단계 · 불러오는 순서 확인

필요한 라이브러리가 먼저 와 있어야 합니다. Network 탭에서 로드 순서를 보면 뒤늦게 도착한 파일을 찾을 수 있습니다.

문서를 다 읽기 전에 실행되는 코드라면 요소를 찾지 못해 조용히 실패합니다. 실행 시점을 문서 로드 이후로 옮기면 해결되는 경우가 많습니다.

4단계 · 중단점으로 흐름 따라가기

Sources 탭에서 실행이 시작되는 줄에 중단점을 걸고 한 줄씩 진행합니다. 어느 줄에서 값이 예상과 달라지는지 직접 확인할 수 있습니다.

조건문에서 갈라진다면 그 조건에 쓰인 값이 무엇인지 확인하면 원인이 바로 드러납니다.

5단계 · 확장 프로그램과 정책 배제

시크릿 창에서 같은 동작을 반복합니다. 여기에서 정상이라면 확장 프로그램이 개입한 것입니다.

시크릿 창에서도 같다면 보안 정책이나 서비스 워커를 확인합니다.

6단계 · 캐시를 끄고 다시 확인

개발자 도구에서 캐시를 끄고 새로 고칩니다. 옛 코드가 남아 있어 JavaScript 작동 안 함 증상이 이어지는 경우가 적지 않습니다.

배포마다 파일 이름에 버전을 붙이면 이 문제가 반복되지 않습니다.

내 상황에 맞는 JavaScript 작동 안 함 판단 기준

• Console에 붉은 메시지가 있다 — 첫 메시지의 파일과 줄 번호부터 확인합니다.
• 메시지가 전혀 없다 — 코드가 실행되지 않았거나 조건에서 빠져나간 경우입니다.
• 특정 브라우저에서만 안 된다 — 문법 호환성과 지원 여부를 확인합니다.
• 시크릿 창에서는 정상이다 — 확장 프로그램이 원인입니다.
• 가끔만 동작한다 — 실행 순서와 의존 관계 문제입니다.

JavaScript 작동 안 함을 확인하는 5단계 체크리스트

1. Console 탭의 첫 붉은 메시지를 읽습니다. 파일과 줄 번호가 함께 나옵니다.
2. Network 탭에서 파일이 실제로 왔는지 봅니다. 200인데 본문이 비어 있는 경우도 있습니다.
3. 같은 파일이 두 번 요청되는지 확인합니다. 중복 로드는 흔한 원인입니다.
4. Sources 탭에서 중단점을 걸어 실행 여부를 확인합니다. 멈추지 않으면 실행되지 않은 것입니다.
5. 시크릿 창에서 재현해 봅니다. 정상이면 확장 프로그램이나 캐시가 원인입니다.

JavaScript 작동 안 함에서 흔히 생기는 오해 3가지

첫 번째, 파일이 200이면 실행도 되었다고 보는 시각입니다. 도착과 실행은 다른 단계입니다. 해석 단계에서 멈추면 아무것도 실행되지 않습니다.

두 번째, 코드를 다시 올리면 해결된다는 생각입니다. 순서나 충돌이 원인이라면 같은 결과가 반복됩니다.

세 번째, Console 메시지를 모두 고쳐야 한다는 판단입니다. 경고 수준의 메시지는 동작에 영향을 주지 않는 경우가 많습니다. 붉은 오류부터 처리하는 편이 효율적입니다.

스크립트가 아니라 예전 파일이 계속 불려오는 상황이라면 캐시를 먼저 의심해야 합니다. 캐시 삭제 방법과 캐시 작동 원리를 함께 보면 원인을 빠르게 가릅니다.

JavaScript 작동 안 함 자주 묻는 질문

Console에 아무것도 없는데 동작하지 않습니다

코드가 실행되지 않았을 가능성이 큽니다. Sources 탭에서 해당 파일에 중단점을 걸고 새로 고쳐 멈추는지 확인해 보십시오.

관리자 화면에서만 동작하지 않습니다

관리자 화면은 불러오는 스크립트 목록이 다릅니다. 등록 위치와 의존 관계를 확인하십시오.

업데이트 후 갑자기 멈췄습니다

라이브러리 버전이 올라가면서 사용하던 기능이 사라졌을 수 있습니다. Console에 함수가 없다는 메시지가 있는지 확인해 보십시오.

모바일에서만 반응이 없습니다

터치 이벤트와 마우스 이벤트가 다르게 처리되기 때문일 수 있습니다. 원격 디버깅으로 해당 기기의 Console을 직접 확인하는 편이 정확합니다.

느린 회선에서만 문제가 생깁니다

파일 도착 순서가 달라지면서 의존 관계가 깨진 경우입니다. 순서를 명시적으로 지정하면 해결됩니다.

콘솔에서 직접 실행하면 잘 됩니다

코드 자체는 정상이고 실행 시점이 문제라는 뜻입니다. 문서 준비 완료 이후에 실행되도록 순서를 조정하십시오.

버튼을 눌러도 아무 반응이 없습니다

이벤트가 연결되지 않았을 가능성이 큽니다. 요소를 나중에 만들어 넣는 구조라면 연결 시점이 요소 생성보다 앞서 있는지 확인해야 합니다.

한 페이지에서만 동작하지 않습니다

그 화면에서만 불러오는 파일이 있는지 확인합니다. 같은 이름의 변수를 두 파일이 함께 쓰면 나중에 읽힌 쪽이 앞의 값을 덮어씁니다.

오류는 없는데 값이 비어 있습니다

서버에서 받은 데이터가 예상과 다른 형태일 수 있습니다. Network 탭의 Response를 열어 실제로 어떤 값이 왔는지 확인하는 편이 빠릅니다.

편집팀 노트 — JavaScript 작동 안 함을 직접 따져보며 정리한 기준

이 글을 정리하면서 편집팀은 같은 코드를 순서, 형식, 정책 조건을 바꿔 가며 실행해 결과를 비교했습니다. 가장 자주 시간을 뺏긴 지점은 Console을 열지 않고 코드를 먼저 고친 순간이었습니다.

메시지 한 줄에는 파일과 줄 번호가 함께 적혀 있습니다. 그 줄을 먼저 열어 보는 것만으로 JavaScript 작동 안 함 원인의 상당수가 그 자리에서 정리됩니다.

또 하나 정리해 둔 기준은 메시지가 없을 때와 있을 때를 다르게 다룬다는 점입니다. 메시지가 없다면 실패가 아니라 애초에 실행되지 않았을 가능성을 먼저 봅니다.

마지막으로 확인 조건을 기록해 두기를 권합니다. 브라우저, 로그인 여부, 회선 속도에 따라 실행 순서가 달라져 같은 코드에서도 결과가 갈립니다.

핵심 요약

JavaScript 작동 안 함은 전송이 아니라 실행 단계의 문제입니다. Console의 첫 오류 메시지, 실행 순서, 의존 관계, 중복 로드, 문법 호환성을 차례로 확인하면 원인 대부분이 드러납니다.

Network 탭의 200만 보고 판단하지 말고 Console과 Sources를 함께 여는 습관이 확인 시간을 크게 줄여 줍니다. 이 글은 정보 제공을 위한 정리이며, 실제 적용은 사용 중인 환경에 맞춰 확인하시기 바랍니다.

함께 보면 좋은 자료와 관련 글

• 200 OK인데 화면이 안 나오는 이유와 확인 방법
• CSS 적용 안 됨 원인과 브라우저에서 확인하는 방법
• Chrome DevTools 공식 문서 · 자바스크립트 디버깅
• MDN 웹 문서 · 자바스크립트 오류 참조

본문에 적은 탭 이름과 항목 위치는 2026년 8월 기준으로 확인한 내용입니다.

Leek의 블로그 홈으로

다른 속도 최적화와 문제 해결 가이드도 홈에서 모아 보실 수 있습니다.