IT
매일 쓰는 주소창의 비밀, URL 구조 완벽 정리 (Protocol부터 Fragment까지)
Hans L
2026. 6. 7. 14:36
우리가 인터넷을 할 때 하루에도 수십 번씩 마주치는 주소창, 바로 URL(Uniform Resource Locator)입니다.
개발을 하다 보면 이 URL을 파싱하거나, 직접 파라미터를 붙여 데이터를 전송해야 하는 일이 정말 많죠. 기술 면접에서도 단골로 나오는 주제이기도 합니다. 오늘은 URL의 각 구성 요소가 어떤 역할을 하는지 핵심만 쏙쏙 뽑아 정리해 보겠습니다.
📌 URL 한눈에 보기
우리가 예시로 볼 URL은 다음과 같습니다.
https://dailyhans.com:8080/blog/posts/88?utm_source=menu#subtitle2
이 긴 주소는 사실 각자의 명확한 역할을 가진 6개의 조각으로 이루어져 있습니다. 하나씩 쪼개서 살펴보시죠?
1. Protocol (프로토콜)
- 예시: https://
- 역할: 브라우저와 서버가 어떤 방식으로 통신할지 결정하는 규약입니다.
- Tip: 과거에는 보안이 없는 http를 주로 썼지만, 최근에는 데이터가 암호화되는 https가 표준으로 자리 잡았습니다. 보안(SSL/TLS)이 적용되었다는 뜻입니다.
2. Domain Name (도메인 네임)
- 예시: dailyhans.com
- 역할: 사람이 기억하기 힘든 숫자로 된 IP 주소 대신, 기억하기 쉽게 만든 웹사이트의 이름입니다.
- 상세 구조: com은 탑레벨 도메인(TLD), dailyhans는 메인 도메인입니다. 만약 앞에 www나 blog 같은 글자가 붙는다면 그것은 서브 도메인(Subdomain)이라고 부릅니다.
3. Port (포트)
- 예시: :8080
- 역할: 서버 안에서 어떤 문(프로그램)으로 들어가야 하는지 지정하는 번호입니다. 한 컴퓨터(서버) 안에서 웹 서버, 데이터베이스 등 여러 프로그램이 동시에 돌고 있기 때문에 포트 번호로 구분을 해줍니다.
- Tip: 일반적인 http는 80번, https는 443번 포트를 기본으로 사용하며, 이 경우 주소창에서 생략이 가능합니다. 예시의 8080은 주로 개발 환경이나 톰캣(Tomcat) 같은 웹 애플리케이션 서버에서 많이 쓰는 포트 번호입니다.
4. Path (경로)
- 예시: /blog/posts/88
- 역할: 웹 서버 안에서 구체적으로 어떤 페이지나 리소스(파일)에 접근할지 나타내는 자원의 위치입니다.
- Tip: 요즘 웹 개발(REST API 등)에서는 예시처럼 /posts/88 형태로 경로 뒤에 데이터의 ID(88번 글)를 붙여서 명시하는 방식을 자주 사용합니다.
5. Query String & Parameters (쿼리 스트링과 파라미터)
- 예시: ?utm_source=menu
- 역할: 서버에 추가적인 정보(데이터)를 전달할 때 사용합니다.
- 구조: ? 기호로 시작하며, Key=Value 형태로 데이터를 보냅니다. 만약 보낼 데이터가 여러 개라면 & 기호로 연결합니다 (예: ?page=1&sort=desc).
- Tip: 예시에 나온 utm_source는 마케터들이 사용자가 어떤 경로(여기서는 메뉴)를 통해 유입되었는지 추적(Tracking)할 때 쓰는 대표적인 파라미터입니다.
6. Fragment (프래그먼트 / 해시)
- 예시: #subtitle2
- 역할: 페이지를 새로고침하지 않고, 해당 페이지 안의 특정 위치(앵커)로 바로 스크롤을 이동시킬 때 사용합니다.
- 특징: 예시의 #subtitle2가 붙으면 글이 로딩되자마자 '두 번째 부제목'이 있는 위치로 화면이 자동 스크롤됩니다. 이 값은 서버로 전송되지 않고 오직 웹 브라우저 안에서만 처리된다는 특징이 있습니다.
URL 구조 요약
| 구성 요소 | 예시 값 | 한 줄 요약 |
| Protocol | https:// | 통신 규칙 (어떻게 통신할 것인가) |
| Domain | dailyhans.com | 서버의 주소 (어디로 갈 것인가) |
| Port | :8080 | 서버의 포트 번호 (어느 Port로 들어갈 것인가) |
| Path | /blog/posts/88 | 상세 위치 및 자원 ID (어떤 방의 몇 번 항목인가) |
| Query | ?utm_source=menu | 전달할 데이터 (무엇을 가지고 갈 것인가) |
| Fragment | #subtitle2 | 페이지 내 위치 (어느 지점을 바로 보여줄 것인가) |
마무리하며
매일 무심코 지나쳤던 URL 주소창이지만, 알고 보면 웹 통신의 모든 규칙과 목적지가 이 한 줄에 압축되어 있다는 사실이 놀랍지 않나요? 개발할 때 이 구조를 명확히 이해하고 있으면 네트워크 에러를 디버깅하거나 API 주소를 설계할 때 큰 도움이 됩니다.
다음 포스팅 예고: 깔끔한 URL의 정석, 'REST API 주소 체계'
오늘 URL의 기본 구조를 살펴봤다면, 다음 글에서는 실무에서 개발자들이 가장 많이 고민하는 'REST API 주소(URI)를 어떻게 하면 직관적이고 깔끔하게 설계할 것인가?'에 대해 다루어 보려고 합니다.
- 왜 주소에 명사만 써야 할까? (/get-posts 대신 /posts를 쓰는 이유)
- 행위(조회, 생성, 수정, 삭제)는 주소가 아닌 어디에 담아야 할까?
- 복수형(Plural) 표현은 언제 쓸까?
협업하기 좋은 코드의 시작인 RESTful한 API 주소 설계 규칙으로 이야기하는, 다음 포스팅도 많이 기대해 주세요!
Thanks
Hans