📚 FDE · 세션 · 데이터 · 서버 · 배포 (수정중) · L02

요청이 서버에 닿는 경로 (수정중)

작성일자 2026-06-28 · 수정일자 2026-08-06 · 강의차수 L02 · 예상소요 30분

목표 주소를 입력하면 DNS 에서 서버까지 요청이 어떤 길을 거쳐 화면이 뜨는지 큰 그림을 잡는다.

이 강의는 코드를 짜는 시간이 아니라, "우리가 만든 걸 사용자가 어떻게 보게 되는가"의 큰 그림을 잡는 시간입니다.

1. 큰 그림

브라우저에 https://education.popupstudio.ai 를 치고 엔터를 누르면, 눈에는 안 보이지만 네 단계가 순식간에 일어납니다.

그림 흐름: 브라우저 → ① DNS(도메인→IP) → ② IP 응답 → ③ 연결+자물쇠(https) → 우리 prod 박스(Apache → 정적 직접 / gunicorn→Django) → ④ 응답이 화면으로

아래에서 ①~④ 를 하나씩 풀어 봅니다.

2. ① 도메인 → IP (DNS)

왜 도메인을 쓰나

컴퓨터끼리는 사실 이름이 아니라 번호(IP 주소) 로 서로를 찾습니다. 우리 prod 서버의 실제 주소는 52.79.132.206 같은 숫자입니다.

하지만 사람이 52.79.132.206 을 외울 순 없으니, 사람이 외우기 쉬운 이름(education.popupstudio.ai)을 붙이고, 그 이름을 번호로 바꿔 주는 시스템을 둡니다. 그게 DNS(Domain Name System) 입니다.

DNS 는 인터넷의 전화번호부입니다. "홍길동"(도메인)을 찾으면 "010-1234-5678"(IP)을 알려줍니다. 가게 전화번호가 바뀌어도(서버 IP 변경) 이름은 그대로 두면 되니, 사람은 번호를 신경 쓰지 않아도 됩니다.

어떻게 찾나

도메인은 점(.)을 기준으로 오른쪽부터 계단식으로 찾아 내려갑니다.

education . popupstudio . ai
                          └─ ① root 서버에 "'.ai' 담당이 누구야?" 물어봄
            └──────────────── ② '.ai' 서버에 "'popupstudio.ai' 담당이 누구야?"
└──────────────────────────── ③ 'popupstudio.ai' 권위 서버에 "'education' 의 IP는?"
                                  → 52.79.132.206 회신

리졸버(resolver): 이 심부름을 대신 해 주는 중개자(보통 통신사·회사 DNS)입니다. 브라우저는 리졸버에게만 묻고, 리졸버가 위 ①②③ 을 돌아 답을 가져옵니다.
권위 네임서버(authoritative): 그 도메인의 정답을 가진 곳입니다. popupstudio.ai 의 정답은 우리가 AWS Route53 에 등록해 둡니다. "education 은 52.79.132.206" 같은 매핑을 우리가 거기 적어 둔 것입니다.
캐시 & TTL: 한 번 찾은 답은 잠시 저장(cache)해 두고 재사용합니다. 그래서 매번 ①②③ 을 다 돌지 않습니다. 저장 기간이 TTL 입니다. 그래서 도메인의 IP 를 바꿔도 전 세계에 퍼지는 데 시간이 걸립니다(주의 사항에서 다시 봅니다).

이 단계가 끝나면 브라우저는 비로소 "education.popupstudio.ai 는 52.79.132.206 이구나" 를 알게 됩니다.

3. ②③ 연결과 자물쇠 (TCP + TLS)

IP 를 알았으니 이제 그 주소로 직접 연결합니다.

TCP 연결: 두 컴퓨터가 "연결할게요" / "네 좋아요" 하고 손을 맞잡는(핸드셰이크) 과정입니다. 이게 돼야 데이터를 주고받을 수 있습니다.
TLS (= https 의 s): 그 위에 자물쇠를 채웁니다. 주고받는 내용을 암호화해서, 중간에 누가 엿봐도 못 읽게 합니다. 브라우저 주소창의 자물쇠 아이콘이 이것입니다.
자물쇠를 채우려면 서버가 인증서(SSL 인증서) 를 갖고 있어야 합니다. 우리는 Let's Encrypt 라는 무료 인증서를 certbot 도구로 발급·자동 갱신합니다.
그래서 http:// 로 들어와도 우리 서버는 자동으로 https:// 로 돌려보냅니다(redirect). 자물쇠 없는 길로는 다니지 않게 합니다.

한 줄로: ②③ 은 그 번호로 전화를 걸고(TCP), 도청 못 하게 암호 통화로 바꾸는 것입니다(TLS).

4. ④ 우리 서버 안

이제 요청이 드디어 우리 서버(52.79.132.206) 에 도착했습니다. 서버 안에서도 역할이 나뉘어 있는데, 여기서는 응답이 만들어지는 마지막 단계만 얇게 봅니다.

Apache 는 문지기(웹서버)입니다. 바깥에서 오는 모든 요청을 맨 앞에서 받습니다. 자물쇠(TLS)를 풀고, "이 요청을 어디로 보낼지" 판단합니다. 여기서 길이 둘로 갈립니다.
정적 파일이면 Apache 가 직접 돌려줍니다. 이미 만들어져 있는 파일(HTML·이미지·CSS)을 그냥 집어서 응답합니다. 우리 교육 사이트(education.popupstudio.ai)가 바로 이 경우로, 강의노트를 미리 HTML 로 빌드해 둔 것이라 Apache 가 파일만 내주면 끝입니다. 그래서 빠르고 단순합니다.
매번 계산이 필요한 앱이면 gunicorn 에게 넘깁니다. 로그인 상태·DB 조회처럼 그때그때 만들어야 하는 페이지는 Apache 가 직접 못 만듭니다. 그래서 뒤에 있는 gunicorn(Django 앱을 실제로 돌리는 일꾼)에게 넘기고, gunicorn 이 Django 코드를 실행해 페이지를 만들어 돌려줍니다.

            ┌── (정적) ──→ Apache 가 파일 바로 응답         ← 교육 사이트
요청 → Apache
            └── (동적) ──→ gunicorn → Django 가 페이지 생성   ← Django 앱

이렇게 만들어진 응답(HTML) 이 왔던 길(TLS→TCP)을 거꾸로 타고 브라우저로 돌아가면, 화면에 페이지가 그려집니다. 여기까지가 한 번의 요청·응답입니다.

서버 안에서 Apache·gunicorn·Django·PostgreSQL 이 어떻게 협업하는지는 서버 한 대 안 에서 자세히 다룹니다.

마무리

핵심 정리: 브라우저에 도메인을 치면 ① DNS 가 도메인(education.popupstudio.ai)을 IP(52.79.132.206)로 바꿔 주고, ② 그 IP 로 TCP 연결 + ③ TLS 자물쇠(https) 를 채운 뒤, ④ 우리 서버의 Apache(문지기) 가 받아 정적이면 직접, Django 앱이면 gunicorn→Django 로 페이지를 만들어 돌려줍니다.
주의 사항: ① DNS 전파 지연: 도메인의 IP 를 바꿔도 캐시(TTL) 때문에 전 세계에 퍼지는 데 시간이 걸립니다("바꿨는데 왜 아직 옛날 걸 보여줘?"의 흔한 원인). ② 인증서 만료: 인증서가 만료되면 브라우저가 "안전하지 않음" 경고를 띄웁니다(그래서 certbot 자동 갱신을 둡니다).
다음 시간: 서버 한 대 안 에서 서버 안을 열어 부품들이 어떻게 협업하는지 보고, 이어서 배포가 바뀌는 것 으로 넘어갑니다.
자습 권장: 터미널에서 nslookup education.popupstudio.ai(또는 dig education.popupstudio.ai)를 쳐서 도메인이 어떤 IP 로 풀리는지 직접 확인해 봅니다. 그리고 브라우저 주소창의 자물쇠 아이콘을 눌러 우리 인증서가 누구(Let's Encrypt)에게서 발급됐는지 봅니다.

이 강의를 학습하셨나요?