웹사이트를 한 번 열 때 실제로 무슨 일이 일어날까

주소를 실제 위치로 바꾸는 단계

브라우저는 example.com이라는 이름으로는 아무 데도 연결하지 못합니다. 먼저 이 이름에 해당하는 서버 주소를 찾아야 합니다. 이 조회를 DNS가 담당합니다. 전화번호부에서 이름으로 번호를 찾는 과정과 비슷합니다.

이 단계가 실패하면 브라우저는 "서버를 찾을 수 없다"는 취지의 화면을 보여 줍니다. 여기서 중요한 것은 아직 서버에 연결조차 시도하지 않았다는 점입니다. 그래서 서버 코드를 아무리 들여다봐도 답이 없습니다. 도메인 설정이나 오타를 봐야 합니다. 방금 도메인을 연결했는데 안 된다면, 변경이 퍼지는 데 시간이 걸린다는 것도 알아 두면 조급함이 줄어듭니다.

연결을 만들고 신원을 확인하는 단계

주소를 찾으면 그 서버와 연결을 맺습니다. 그리고 https라면 여기서 한 단계가 더 붙습니다. 서버가 자기가 그 도메인의 주인이 맞다는 증명서를 제시하고, 브라우저가 그것을 확인한 뒤 이후 대화를 암호화하는 과정입니다.

브라우저에 "이 연결은 안전하지 않습니다" 같은 경고가 뜨는 상황이 바로 이 단계의 문제입니다. 증명서 기간이 지났거나, 증명서에 적힌 도메인과 실제 접속한 도메인이 다르거나, 신뢰할 수 없는 곳에서 발급됐을 때 나타납니다. 이 경고는 서버 코드와는 관계가 없고, 인증서 설정 쪽을 봐야 합니다.

배포를 직접 해 보면 이 단계가 손에 잡힙니다. 로컬에서만 돌리던 때는 존재하지도 않던 문제들이라, 한 번 겪어 보는 것만으로 웹의 그림이 크게 달라집니다. 이 감각에 대해서는 한 번 배포해 보면 코드 쓰는 법이 달라집니다에 따로 적었습니다.

요청을 보내고 응답을 받는 단계

연결이 만들어지면 그제서야 실제 요청이 나갑니다. 브라우저는 어떤 문서를 달라는 요청을 텍스트로 보내고, 서버는 상태 코드와 함께 응답을 돌려줍니다.

여기서 나오는 숫자들이 익숙한 것들입니다. 404는 서버까지는 잘 갔는데 그 경로에 해당하는 것이 없다는 뜻입니다. 500은 서버가 처리하다가 실패했다는 뜻이고, 이때는 서버 쪽 로그를 봐야 합니다. 두 숫자를 구분하는 것만으로 "내 주소가 틀렸나"와 "서버 코드가 터졌나"가 갈립니다. 요청과 응답의 구조 자체는 API 요청과 응답 읽기에서 한 줄씩 해부해 두었습니다.

이 두 단계는 터미널에서 직접 확인할 수 있습니다. 브라우저를 거치지 않고 확인하면 문제가 브라우저에 있는지 서버에 있는지가 바로 갈립니다.

# 1) 이름이 어떤 주소로 풀리는지
$ nslookup example.com
# 또는
$ dig +short example.com

# 2) 연결과 응답 첫 줄만 확인
$ curl -I https://example.com
HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=600
...

받은 것을 화면으로 만드는 단계

응답으로 온 HTML은 그 자체로 화면이 아닙니다. 브라우저가 위에서부터 읽으며 구조를 만들고, CSS를 적용해 모양을 정하고, JavaScript를 실행합니다. 그리고 HTML 안에 이미지나 스크립트 주소가 있으면 그것들을 받기 위한 요청이 다시 나갑니다. 페이지 하나를 여는 데 요청이 수십 개 오가는 것이 보통입니다.

"화면은 떴는데 데이터가 안 나온다"는 증상이 여기에 속합니다. HTML은 정상적으로 왔고, 그 안의 스크립트가 데이터를 가지러 보낸 두 번째 요청이 실패한 상황입니다. 첫 번째 요청만 확인하고 서버가 정상이라고 판단하면 원인을 못 찾습니다.

이럴 때 보는 곳이 개발자 도구의 Network 탭입니다. 무엇을 봐야 할지 목록으로 정리하면 이렇습니다.

확인 순서
1. Status   - 200인가, 4xx인가, 5xx인가
2. 요청 URL - 내가 의도한 주소가 맞는가 (오타, 슬래시, 포트)
3. Method   - GET인가 POST인가
4. Headers  - Content-Type, 인증 헤더가 실려 나갔는가
5. Response - 본문에 실제로 뭐가 들어 있는가
6. Timing   - 어느 구간에서 오래 걸리는가

체크 항목
[ ] Disable cache 켜고 새로고침해 봤는가
[ ] 실패한 요청이 목록에 아예 없지는 않은가

증상과 단계를 짝지어 둡니다

지금까지의 단계를 외우는 대신, 증상 하나에 단계 하나를 붙여 두면 실전에서 바로 쓸 수 있습니다. 무언가 안 될 때 처음부터 전부 뒤지지 않고 한 곳부터 열면 되기 때문입니다.

주소를 못 찾는다는 메시지가 뜨면 이름 조회 단계입니다. 인증서 경고가 뜨면 연결 단계입니다. 화면이 뜨는데 404가 보이면 서버까지는 갔고 경로가 틀린 것입니다. 500이 보이면 서버 코드가 실패한 것이므로 서버 로그가 유일한 단서입니다. 화면 골격은 나오는데 내용이 비어 있으면 두 번째 요청이 실패한 것이고, 화면이 통째로 하얗게 나오면 자바스크립트 실행 중에 예외가 났을 가능성이 큽니다. 이 마지막 경우는 Network 탭이 아니라 Console 탭을 먼저 봐야 합니다.

이 짝짓기가 익숙해지면 문제를 만났을 때 검색창에 무엇을 칠지도 정확해집니다. "웹사이트 안 됨" 대신 "인증서 만료 경고" 같은 단어를 쓰게 되기 때문입니다. 어느 단계에서 실패했는지를 말할 수 있으면 남에게 질문할 때도 대화가 훨씬 짧아집니다.

이 그림이 항상 맞지는 않습니다

위 순서는 기본형이고, 실제 웹에서는 중간이 생략되거나 다른 곳이 끼어드는 경우가 많습니다. 이것을 모르면 "분명히 고쳤는데 안 바뀐다"는 상황에서 한참을 헤매게 됩니다.

요청이 아예 안 나갈 수 있습니다. 브라우저는 한 번 받은 파일을 저장해 두고 재사용합니다. 그래서 서버의 CSS를 고쳐도 화면이 그대로인 일이 생깁니다. 코드를 의심하기 전에 강력 새로고침을 하거나 Network 탭에서 그 파일 요청이 실제로 나갔는지부터 확인하는 편이 빠릅니다.

내 서버가 아닌 곳이 응답할 수 있습니다. 큰 사이트는 사용자와 가까운 곳에 파일 사본을 두고 그쪽에서 응답하게 합니다. 회사 네트워크라면 중간에 프록시가 끼어 있을 수도 있습니다. 이 경우 내 서버 로그에는 요청 기록이 없는데 화면에는 예전 내용이 나오는, 처음 보면 당황스러운 상황이 생깁니다.

첫 로드 이후에는 페이지 이동이 왕복이 아닐 수 있습니다. 요즘 많은 사이트는 첫 요청에서 자바스크립트를 받아 온 뒤, 그다음부터는 화면 전환을 브라우저 안에서 처리합니다. 링크를 눌렀는데 Network 탭에 HTML 요청이 안 보이는 이유가 이것입니다. 이때 나가는 것은 데이터를 가져오는 요청뿐입니다.

마지막으로, 이 전체 흐름을 다 외우려 드는 것이 오히려 함정입니다. 각 단계를 깊게 파면 그것만으로 몇 달이 갑니다. 입문 단계에서 필요한 것은 정확한 지식이 아니라 증상을 보고 어느 단계를 먼저 볼지 고르는 능력입니다. 단계 이름과 대표 증상 하나씩만 짝지어 두면 충분합니다.

브라우저를 열어 두고 따라 해 보기

• 자주 쓰는 사이트에서 dig +short와 curl -I를 실행해 결과를 봅니다.
• 개발자 도구 Network 탭을 먼저 열고 새로고침해, 요청이 몇 개나 나가는지 셉니다.
• 그중 하나를 골라 Status, 요청 URL, Response를 확인합니다.
• Disable cache를 켜고 껐을 때 요청 목록이 어떻게 달라지는지 비교합니다.
• 일부러 없는 주소를 열어 404 응답이 어떤 모양인지 봅니다.

이 흐름 위에 무엇을 조심해야 하는지는 첫 프로젝트의 보안 기본에서 이어집니다.

웹은 마법이 아니라 단계입니다. 단계를 알면, 안 될 때 어디를 먼저 볼지가 정해집니다.