200 OK인데 화면이 안 나오는 이유 7가지와 확인 방법

개발자 도구를 열어 보면 모든 요청이 초록색 200 OK인데, 정작 화면은 하얗게 비어 있거나 레이아웃이 무너져 있는 경우가 있습니다. 요청이 전부 성공했는데 결과가 정상이 아니라는 점에서 원인을 찾기가 까다롭게 느껴집니다.

200 OK는 “서버가 요청을 받아 응답 본문을 정상적으로 돌려주었다”는 뜻일 뿐입니다. 그 본문의 내용이 브라우저가 기대한 것인지, 화면을 그리는 데 실제로 쓰였는지까지는 보장하지 않습니다. 이 글은 200 OK가 나오는데도 화면이 어긋나는 대표 원인을 나누고, 어떤 순서로 확인하면 되는지 정리합니다.

200 OK가 보장하는 범위

상태 코드는 전송 계층의 결과만 알려 줍니다. 서버가 파일을 찾아 응답을 만들어 보냈다면, 그 안에 오류 메시지가 들어 있어도 200 OK가 됩니다. 브라우저는 내용을 판단하지 않고 전달만 담당합니다.

실제로 많은 서버가 처리 실패를 본문에 담아 200으로 내려보냅니다. API가 실패 사유를 담은 결과를 200 OK로 돌려주는 구성이 대표적입니다. 이 경우 Network 탭은 초록색이지만 화면에는 아무것도 그려지지 않습니다.

따라서 200 OK를 보았다면 다음 질문은 “무엇이 왔는가”가 되어야 합니다. Response 탭을 열어 실제 본문을 눈으로 확인하는 것이 첫 단계입니다.

확인 대상	200 OK가 보장하는 것	보장하지 않는 것	확인할 곳
요청 전달	서버까지 도달했음	올바른 파일이 왔는지	Response 탭의 본문
응답 생성	서버가 응답을 만들었음	내용이 비어 있지 않은지	Size 열과 본문 길이
형식	헤더를 붙여 보냈음	형식이 실제 내용과 맞는지	Content-Type 헤더
실행	파일이 도착했음	스크립트가 끝까지 실행됐는지	Console 탭의 오류
표시	문서가 만들어졌음	화면에 보이는지	Elements 탭과 스타일

가정 예시 — 실제 확인 항목은 서비스 구조에 따라 다를 수 있음

표를 보면 200 OK가 확인해 주는 범위가 생각보다 좁다는 점이 드러납니다. 전달과 생성까지는 보장하지만, 내용과 실행과 표시는 전혀 다른 단계입니다.

그래서 화면이 비어 있을 때 200 OK를 근거로 “서버는 정상”이라고 넘겨 버리면 원인을 찾는 시간이 길어집니다. 응답 코드 다음에는 반드시 응답 본문을 봐야 합니다.

응답 본문이 기대와 다른 경우

가장 흔한 사례는 CSS나 JS 요청에 HTML이 돌아오는 상황입니다. 경로가 잘못되어 서버의 404 안내 페이지가 반환되었는데, 그 안내 페이지 자체는 정상 문서라서 200 OK로 처리되는 것입니다.

이때 브라우저는 스타일시트 자리에 HTML을 받고 해석에 실패합니다. 화면에는 스타일이 전혀 적용되지 않은 원본 문서가 그대로 보입니다. Response 탭을 열면 CSS 대신 태그가 가득한 문서가 보이므로 판별이 쉽습니다.

JSON을 기대한 자리에 로그인 페이지가 돌아오는 경우도 같은 유형입니다. 세션이 만료되어 서버가 로그인 화면으로 안내했는데, 스크립트는 그것을 데이터로 해석하려다 실패합니다.

본문이 실제로 무엇인지 확인할 때는 헤더와 앞부분을 함께 받아 보는 방식이 확실합니다. 아래 명령은 응답 헤더와 본문 첫 부분을 한 번에 보여 줍니다.

snippetCODE

curl -i https://example.com/api/items | head -n 30

응답 코드는 200 OK인데 본문이 비어 있거나 오류 안내 화면이 담겨 있다면 원인이 서버 쪽에 있습니다. 서버가 실패를 200으로 감싸 보내는 구성에서 자주 나타나는 형태입니다.

브라우저 화면과 이 결과가 다르다면 확장 프로그램이나 서비스 워커가 응답을 바꿔 놓았을 가능성이 큽니다.

콘텐츠 형식이 잘못 지정된 경우

서버가 응답에 붙이는 형식 표기가 실제 내용과 다르면 브라우저는 파일을 무시합니다. 스타일시트를 일반 텍스트로 표기해 내려보내면 200 OK를 받고도 스타일이 적용되지 않습니다.

스크립트도 마찬가지입니다. 형식이 자바스크립트로 지정되지 않으면 최신 브라우저는 보안상 실행을 거부합니다. 이 경우 Console 탭에 거부 사유가 문장으로 출력됩니다.

글꼴 파일이나 이미지에서도 같은 문제가 생깁니다. 서버 설정에서 확장자별 형식 표기를 추가하면 해결되며, 응답 헤더의 형식 항목을 보면 현재 값이 무엇인지 바로 확인할 수 있습니다.

파일 종류	올바른 형식 값	잘못 지정됐을 때 증상	확인 위치
HTML 문서	text/html	태그가 글자로 보임	Content-Type 헤더
스타일시트	text/css	스타일이 전혀 적용되지 않음	Console의 형식 경고
자바스크립트	text/javascript	실행되지 않고 무시됨	Console의 차단 메시지
JSON 응답	application/json	파싱 단계에서 실패	Response 탭의 본문
이미지	image/jpeg 등	깨진 이미지 표시	Preview 탭

가정 예시 — 실제 값은 서버 설정에 따라 달라질 수 있음

형식이 어긋나면 파일은 200 OK로 도착했는데도 브라우저가 사용하지 않습니다. 확장자만 보고 판단하지 말고 실제로 붙어 온 헤더를 확인해야 합니다.

스크립트 실행 중 오류가 난 경우

파일은 정상적으로 내려왔지만 실행 도중 예외가 발생하면 그 뒤 코드가 전부 멈춥니다. 화면을 그리는 코드가 뒤쪽에 있었다면 아무것도 표시되지 않습니다. Network 탭은 여전히 200 OK만 보여 줍니다.

이 유형은 Console 탭을 열면 즉시 드러납니다. 붉은 메시지와 함께 오류가 발생한 파일 이름과 줄 번호가 표시되므로, 수정할 위치를 바로 특정할 수 있습니다.

화면이 하얗게 비는 증상은 대부분 이 경우입니다. 요소를 그리기 전에 실행이 중단되었기 때문에 문서에 아무 내용도 추가되지 않은 상태가 됩니다.

파일은 왔지만 순서가 어긋난 경우

스크립트가 문서보다 먼저 실행되면 아직 존재하지 않는 요소를 찾다가 실패합니다. 이 역시 200 OK 상태에서 화면만 비정상인 전형적인 상황입니다.

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

여러 라이브러리를 함께 쓰는 경우 의존 관계 순서도 확인해야 합니다. 기반 라이브러리보다 그것을 사용하는 코드가 먼저 실행되면 같은 문제가 반복됩니다.

캐시가 옛 파일을 붙들고 있는 경우

수정한 파일이 반영되지 않으면 새 코드와 옛 코드가 섞여 화면이 어긋납니다. 요청은 모두 성공하므로 200 OK 또는 304가 표시되고, 겉보기에는 이상이 없습니다.

개발자 도구에서 Disable cache를 켠 뒤 다시 새로 고쳐 화면이 정상이 되면 캐시가 원인입니다. 이때는 파일 이름에 버전 값을 붙여 배포하는 방식으로 근본 해결이 가능합니다.

앞단에 CDN이 있으면 브라우저 캐시를 비워도 변화가 없습니다. 배포 후 경로 무효화를 함께 수행해야 새 파일이 전달됩니다.

화면은 있는데 보이지 않는 경우

요소가 문서에 추가되었는데도 눈에 보이지 않는 상황이 있습니다. 높이가 0으로 계산되었거나, 다른 요소에 가려졌거나, 투명도나 표시 속성이 감춤으로 지정된 경우입니다.

Elements 탭에서 해당 요소를 선택해 계산된 스타일을 확인하면 원인을 찾을 수 있습니다. 200 OK와는 무관한 순수 스타일 문제이므로 Network 탭만 봐서는 알 수 없습니다.

글꼴이 로드되지 않아 글자가 배경색과 같아지는 경우도 있습니다. 이때는 요소를 선택해 색상 값을 직접 확인하는 편이 빠릅니다.

렌더링 차단과 빈 화면의 관계

브라우저는 문서를 위에서 아래로 읽으며 화면을 구성합니다. 이 과정에서 스타일시트와 동기 방식 스크립트는 해석을 잠시 멈추게 만듭니다. 파일이 늦게 도착하면 그동안 화면에는 아무것도 그려지지 않습니다.

느린 외부 자원 하나가 페이지 전체를 붙잡는 경우가 여기에 해당합니다. 요청은 결국 성공하지만 도착까지 몇 초가 걸리면 사용자에게는 빈 화면으로 보입니다. Timing 구간에서 대기 시간이 유독 긴 요청을 찾으면 원인이 드러납니다.

해결 방향은 두 가지입니다. 화면을 그리는 데 꼭 필요하지 않은 스크립트는 지연 실행으로 돌리고, 첫 화면에 쓰이는 스타일만 문서 안에 직접 넣어 두는 방식입니다. 나머지 스타일은 뒤이어 불러오면 됩니다.

서버 사이드 렌더링 환경에서의 차이

서버에서 화면을 미리 만들어 내려보내는 구성에서는 문서 자체에 내용이 담겨 옵니다. 이 경우 화면이 비었다면 브라우저가 아니라 서버 쪽 렌더링 과정에서 문제가 생겼을 가능성이 큽니다.

확인 방법은 간단합니다. 브라우저에서 페이지 소스 보기를 눌러 원본 문서를 확인하면, 서버가 실제로 내려보낸 내용이 그대로 나옵니다. 여기에 내용이 없다면 브라우저 쪽 코드를 아무리 손봐도 달라지지 않습니다.

반대로 소스에는 내용이 있는데 화면에서 사라진다면, 브라우저에서 실행되는 코드가 문서를 다시 그리는 과정에서 실패한 것입니다. 이 경우 Console 탭에 관련 메시지가 남습니다.

확인을 마친 뒤 정리할 것

원인을 찾았다면 같은 문제가 재발하지 않도록 배포 절차에 확인 항목을 추가해 두는 편이 좋습니다. 스타일시트와 스크립트가 올바른 형식으로 서비스되는지, 첫 화면이 실제로 그려지는지 두 가지만 점검해도 대부분 걸러집니다.

특히 형식 표기 문제는 서버 설정을 한 번 바로잡으면 이후로는 발생하지 않습니다. 반면 캐시 문제는 배포할 때마다 반복되므로, 파일 이름에 버전 값을 붙이는 방식을 표준으로 삼는 편이 안전합니다.

원인을 찾은 뒤에는 같은 상황이 다시 생기지 않도록 구성을 손봐 두는 편이 좋습니다. 서버가 실패를 200 OK로 감싸 보내고 있었다면 실패에 맞는 응답 코드를 돌려주도록 바꾸는 것이 가장 확실한 정리입니다.

코드 쪽에서는 화면을 만드는 단계가 중간에 멈췄을 때 빈 화면 대신 안내 문구가 남도록 처리해 두면 됩니다. 사용자가 무엇을 보고 있는지 알 수 있어야 제보 내용도 구체적으로 들어옵니다.

마지막으로 이번에 확인한 순서를 짧게 적어 두면 다음 사람이 같은 길을 다시 찾지 않아도 됩니다.

브라우저 확장 프로그램이 만드는 변수

광고 차단이나 보안 관련 확장 프로그램은 페이지의 요소를 직접 지우거나 요청을 가로챕니다. 서버는 정상적으로 응답했고 기록에도 성공으로 남지만, 화면에서는 특정 영역이 사라진 것처럼 보입니다.

구분 방법은 시크릿 창입니다. 시크릿 창에서는 확장 프로그램이 기본적으로 비활성화되므로, 여기서 화면이 정상이면 확장 프로그램이 원인이라고 판단할 수 있습니다.

번역 기능이나 접근성 도구가 문서 구조를 바꾸면서 스크립트가 찾던 요소를 놓치는 경우도 있습니다. 사용자 문의가 특정 조건에서만 들어온다면 이 가능성을 함께 검토해 보십시오.

확장 프로그램은 응답을 바꾸기도 하고 화면 요소를 지우기도 합니다. 광고 차단이나 보안 관련 확장은 특정 주소의 요청을 조용히 막기 때문에 겉으로는 200 OK만 남고 화면만 비어 보일 수 있습니다.

확인 순서는 시크릿 창에서 먼저 재현해 보고, 정상이라면 확장을 하나씩 켜 가며 범위를 좁히는 방식이 빠릅니다. 사용자 제보를 받을 때도 확장 사용 여부를 함께 물어 두면 확인 시간이 줄어듭니다.

기록을 남겨 두면 좋은 항목

화면 문제는 재현 조건이 까다로워 시간이 오래 걸립니다. 원인을 찾았을 때 브라우저 종류와 버전, 실패한 요청 주소, Console에 나온 첫 메시지 세 가지만 기록해 두면 다음 대응이 훨씬 빨라집니다.

같은 유형이 반복된다면 원인이 개별 코드가 아니라 구조에 있다는 신호입니다. 이때는 개별 수정을 반복하기보다 로딩 순서나 배포 절차 자체를 손보는 편이 결과적으로 시간을 아낍니다.

같은 증상이 다시 생겼을 때 처음부터 확인하지 않으려면 아래 항목을 함께 적어 두는 편이 좋습니다.

문제가 보인 주소와 시각
브라우저 종류와 버전, 시크릿 창 여부
로그인 상태와 계정 권한
문서 요청의 응답 코드와 본문 길이
Console 탭의 첫 번째 오류 메시지
캐시를 끈 상태에서의 결과

항목이 많아 보이지만 대부분 개발자 도구 화면에서 그대로 옮겨 적을 수 있는 값입니다. 200 OK 응답이 나온 상황일수록 이런 기록이 원인을 가르는 근거가 됩니다.

측정과 재현을 돕는 도구

브라우저에 내장된 성능 탭을 사용하면 화면이 그려지기까지의 과정을 시간 순으로 볼 수 있습니다. 어느 시점에 문서 해석이 멈췄고 언제 첫 화면이 표시되었는지 구간으로 확인할 수 있어, 빈 화면의 지속 시간을 숫자로 파악하는 데 도움이 됩니다.

네트워크 속도를 임의로 낮추는 기능도 유용합니다. 느린 환경에서만 나타나는 순서 문제를 사무실 회선에서도 재현할 수 있어, 사용자 제보를 확인할 때 자주 쓰입니다.

기기별 화면 크기를 흉내 내는 기능을 함께 쓰면 화면 폭에 따른 분기 문제도 확인할 수 있습니다. 다만 실제 기기와 완전히 같지는 않으므로, 최종 확인은 실물에서 한 번 더 하는 편이 안전합니다.

도구를 늘리기보다 브라우저에 이미 들어 있는 기능을 끝까지 쓰는 편이 효율적입니다. Network 탭의 조절 기능으로 느린 회선을 흉내 내면 실행 순서 문제를 재현하기 쉬워지고, 성능 탭의 기록 기능으로는 화면이 만들어지는 시점을 확인할 수 있습니다.

외부 도구가 필요한 경우는 여러 지역에서 동시에 확인해야 할 때 정도입니다. 지역마다 앞단 캐시가 다르면 같은 주소에서 200 OK 응답을 받고도 서로 다른 화면을 보게 됩니다.

도구를 고를 때는 결과를 파일로 남길 수 있는지 확인해 두면 좋습니다. 나중에 같은 증상이 생겼을 때 이전 기록과 나란히 비교할 수 있습니다.

200 OK인데 화면이 비어 있을 때의 점검 순서

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

1단계 · 문서 요청의 본문 먼저 확인

첫 번째 요청, 즉 문서 자체의 Response 탭을 엽니다. 여기가 비어 있다면 이후 파일을 아무리 확인해도 소용이 없습니다.

본문에 내용이 있는데 화면만 비어 있다면 표시 단계의 문제이므로 다음 단계로 넘어갑니다.

2단계 · Console 탭에서 실행 중단 지점 찾기

스크립트가 중간에 멈추면 이후 코드가 실행되지 않아 화면이 만들어지지 않습니다. 첫 번째 오류 메시지가 대부분 출발점입니다.

오류가 여러 개라면 가장 위쪽 것부터 해결해야 합니다. 뒤에 있는 오류는 앞선 실패의 결과인 경우가 많습니다.

3단계 · 응답 형식과 실제 내용 대조

Content-Type 헤더와 Response 탭의 내용이 서로 맞는지 확인합니다. HTML이 와야 할 자리에 JSON이 오거나 그 반대인 경우가 있습니다.

형식이 어긋나면 200 OK 응답이라도 브라우저는 그 파일을 사용하지 않습니다.

4단계 · Elements 탭에서 요소 존재 여부 확인

화면에 보이지 않아도 문서 안에는 요소가 만들어져 있을 수 있습니다. 요소가 있다면 크기나 표시 속성 때문에 보이지 않는 것입니다.

요소 자체가 없다면 화면을 만드는 코드가 실행되지 않은 것이므로 다시 실행 단계로 돌아갑니다.

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

개발자 도구에서 캐시 사용을 끄고 새로 고칩니다. 이때 정상으로 바뀐다면 옛 파일이 남아 있던 것이 원인입니다.

변화가 없다면 캐시는 원인이 아니므로 확인 대상에서 제외하면 됩니다.

6단계 · 시크릿 창과 다른 브라우저에서 재현

확장 프로그램이 응답이나 화면을 바꾸는 경우가 있습니다. 시크릿 창에서 정상이라면 확장 프로그램을 하나씩 켜 가며 범위를 좁힙니다.

모든 환경에서 같은 증상이라면 서버나 배포 쪽 구성을 다시 확인하는 편이 빠릅니다.

내 상황에 맞는 200 OK 화면 문제 판단 기준

화면이 완전히 하얗다 — Console 탭의 스크립트 오류를 먼저 확인합니다.
글자만 있고 스타일이 없다 — 스타일시트 응답 본문과 형식 표기를 확인합니다.
일부 기능만 동작하지 않는다 — 실행 순서와 의존 관계를 확인합니다.
새로 고치면 가끔 정상이다 — 캐시 또는 로딩 순서 문제일 가능성이 큽니다.
요소는 있는데 보이지 않는다 — 스타일 계산 결과를 직접 확인합니다.

200 OK 화면 문제를 확인하는 5단계 체크리스트

Console 탭을 먼저 엽니다. 스크립트 오류가 있으면 여기서 끝나는 경우가 많습니다.
실패가 의심되는 요청의 Response 탭을 봅니다. 기대한 내용이 실제로 왔는지 눈으로 확인합니다.
응답 헤더의 형식 표기를 확인합니다. 형식이 맞지 않으면 200 OK라도 무시됩니다.
Disable cache를 켜고 다시 확인합니다. 결과가 달라지면 캐시가 원인입니다.
Elements 탭에서 요소가 실제로 존재하는지 봅니다. 있으면 스타일, 없으면 스크립트 문제입니다.

200 OK 상황에서 흔히 생기는 오해 3가지

첫 번째, 초록색이면 문제가 없다고 보는 시각입니다. 200 OK는 전송 성공만 알려 줍니다. 내용이 맞는지는 별도로 확인해야 합니다.

두 번째, 서버를 다시 시작하면 해결된다는 생각입니다. 응답이 이미 정상적으로 오고 있으므로 서버 재시작은 대부분 효과가 없습니다.

세 번째, Network 탭만 보면 충분하다는 판단입니다. 화면이 그려지는 과정의 문제는 Console과 Elements에서 드러납니다. 세 탭을 함께 보는 습관이 필요합니다.

200 OK 관련 자주 묻는 질문

모든 요청이 200인데 화면이 하얗습니다

스크립트 실행 중 예외가 발생했을 가능성이 가장 큽니다. Console 탭의 첫 번째 붉은 메시지부터 확인하십시오.

Response 탭이 비어 있습니다

응답 본문이 실제로 비었거나, 브라우저가 본문을 보관하지 않은 경우입니다. Disable cache를 켜고 다시 요청하면 내용이 보이는 경우가 많습니다.

로컬에서는 정상인데 서버에서만 어긋납니다

경로 대소문자, 형식 표기 설정, 빌드 산출물 차이 세 가지를 먼저 비교해 보십시오. 200 OK 상태에서 발생하는 차이는 대부분 이 범위 안에 있습니다.

새로 고침을 여러 번 하면 정상이 됩니다

파일 로딩 순서가 일정하지 않아 생기는 문제입니다. 의존 관계를 명시적으로 지정해 순서를 고정하는 편이 안전합니다.

API 응답이 200인데 데이터가 없습니다

서버가 처리 실패를 본문에 담아 200으로 내려주는 구성일 수 있습니다. 본문의 결과 항목을 확인하고, 필요하다면 실패 시 상태 코드를 구분해 주도록 서버를 수정하는 편이 좋습니다.

모바일에서만 화면이 깨집니다

화면 폭에 따른 스타일 분기나 기기별 기능 지원 차이일 가능성이 큽니다. 원격 디버깅으로 해당 기기의 Console을 직접 확인하면 원인이 드러납니다.

응답은 200 OK인데 Size가 0으로 표시됩니다

서버가 본문 없이 응답만 보낸 상태입니다. 조건에 따라 빈 응답을 돌려주는 처리가 있는지, 또는 앞단 캐시가 빈 사본을 들고 있는지 확인해야 합니다.

화면 일부만 비어 있습니다

필요한 파일 중 일부만 실패했을 가능성이 큽니다. 목록을 상태별로 걸러 실패한 요청이 있는지부터 확인하고, 없다면 해당 영역을 만드는 코드의 실행 여부를 봅니다.

첫 방문에만 화면이 비어 있습니다

실행 순서나 초기 데이터 요청의 시점 문제인 경우가 많습니다. 두 번째부터 정상이라면 캐시된 자원 덕분에 순서가 맞아떨어진 것일 수 있습니다.

편집팀 노트 — 200 OK 화면 문제를 직접 따져보며 정리한 기준

이 글을 정리하면서 편집팀은 응답 코드는 정상인데 화면만 비어 있는 상황을 여러 형태로 만들어 확인했습니다. 가장 자주 시간을 뺏긴 지점은 200 OK를 보고 서버 쪽을 확인 대상에서 제외한 순간이었습니다.

실제로는 서버가 실패를 200으로 감싸 보내는 구성이 적지 않았습니다. 응답 코드보다 응답 본문을 먼저 열어 보는 습관 하나로 확인 시간이 크게 줄었습니다.

또 하나 정리해 둔 기준은 전달·실행·표시를 나누어 본다는 점입니다. 세 단계 중 어디에서 끊겼는지만 정하면 이후에 볼 탭이 하나로 좁혀집니다.

마지막으로 재현 조건을 기록해 두기를 권합니다. 첫 방문인지, 로그인 상태인지, 캐시가 있는지에 따라 같은 200 OK 응답에서도 화면 결과가 달라집니다.

핵심 요약

200 OK는 전송이 성공했다는 신호일 뿐, 내용이 올바르다는 보증이 아닙니다. 화면이 어긋난다면 Console의 스크립트 오류, 응답 본문의 실제 내용, 형식 표기, 캐시, 스타일 계산 순서로 확인하면 원인 대부분이 드러납니다.

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

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

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

Leek의 블로그 홈으로

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