URL은 어떻게 원하는 페이지를 찾아갈까?

앞선 글에서는 브라우저가 서버에 말을 거는 방법을 살펴보았다. IP 주소가 목적지 컴퓨터를 찾아주고 포트 번호가 그 안에서 통신할 프로그램을 구분하면, HTTP는 브라우저와 서버가 어떤 형식으로 요청과 응답을 주고받을지를 정하였다. HTTPS는 그 대화가 다른 사람에게 쉽게 드러나지 않도록 보호하였다.

그런데 여기까지 알고 나면 한 가지가 남는다. 서버에 도착했다고 해서 원하는 웹페이지가 저절로 나타나는 것은 아니다. 하나의 서버 안에도 첫 화면과 게시물, 이미지, 동영상, 검색결과처럼 수많은 자료가 들어 있을 수 있기 때문이다.

브라우저는 서버를 찾는 것에서 한 걸음 더 나아가 그 서버 안에서 어떤 자료를 원하는지도 알려주어야 한다. 우리가 주소창에 입력하는 긴 문자열에는 바로 그 정보가 들어 있다.

이 주소를 보통 URL이라고 부른다. URL은 웹사이트 이름 하나를 적어 놓은 표지판이라기보다, 어디로 가서 어떤 방법으로 무엇을 찾아야 하는지를 차례대로 적어 놓은 안내문에 가깝다.

한줄 요약

URL은 인터넷에서 사용할 통신 방식과 서버의 위치, 그리고 서버 안에서 찾아야 할 자료의 위치를 표현하는 주소이다.

주소창에 적힌 한 줄은 생각보다 많은 일을 한다

인터넷을 사용할 때 URL 전체를 직접 입력하는 경우는 예전보다 줄었다. 검색엔진에서 필요한 내용을 검색한 뒤 결과를 누르는 경우가 많고, 스마트폰에서는 주소창과 검색창의 경계조차 거의 느끼지 못한다.

그렇다고 URL의 역할이 사라진 것은 아니다. 사용자가 직접 보지 않을 뿐 브라우저는 여전히 URL을 바탕으로 어디에 접속하고 무엇을 요청해야 하는지를 판단한다.

예를 들어 다음과 같은 주소가 있다고 생각해 보자.

https://example.com/article/network?id=15#chapter2

사람 눈에는 하나의 긴 주소처럼 보이지만 브라우저는 이를 한 덩어리로만 바라보지 않는다. 앞부분에는 어떤 방식으로 통신할지가 들어 있고, 그 뒤에는 어느 서버로 가야 하는지가 표시된다. 다시 그 뒤에는 서버 안에서 찾아야 할 자료의 위치와 추가 조건이 붙을 수 있다.

우리가 실제 생활에서 주소를 사용하는 모습과도 조금 닮았다. 대한민국이라는 나라만 안다고 해서 특정 건물까지 찾아갈 수 없는 것처럼, 인터넷에서도 서버의 위치만 알아서는 그 안에 있는 수많은 자료 가운데 어느 것을 원하는지 알 수 없다.

주소가 도시와 도로, 건물번호를 거치며 목적지를 좁혀 가듯 URL도 여러 요소를 조합해 인터넷이라는 넓은 공간에서 원하는 자료를 좁혀 간다.

맨 앞의 HTTPS는 주소가 아니라 통신 방법이다

URL을 앞에서부터 살펴보면 가장 먼저 눈에 들어오는 부분이 https://이다. 직전 글에서 살펴본 바로 그 HTTPS이다.

웹주소를 볼 때는 흔히 이 부분까지 모두 사이트의 주소라고 생각하기 쉽다. 하지만 HTTPS는 서버의 위치를 알려주는 이름이 아니다. 앞으로 어떤 규칙을 이용하여 서버와 통신할지를 브라우저에 알려주는 역할을 한다.

HTTP를 사용한다면 브라우저와 서버는 HTTP 방식으로 요청과 응답을 주고받는다. HTTPS가 적혀 있다면 그 통신에 TLS를 이용한 보호 절차를 더한다.

이 부분을 스킴(Scheme) 또는 프로토콜 부분이라고 부르기도 한다. 웹에서는 HTTP와 HTTPS가 익숙하지만 인터넷에서 사용하는 주소 체계가 항상 웹페이지에만 사용되는 것은 아니기 때문에 다른 방식이 표시될 수도 있다.

여기에서 앞선 글과의 연결이 다시 보인다. HTTPS를 먼저 알고 URL을 보면 주소 맨 앞의 문자가 단순한 장식이 아니라 브라우저에게 통신 방법을 지시하는 정보라는 것을 이해할 수 있다.

사용자는 주소 하나를 입력했을 뿐이지만 브라우저 입장에서는 이미 첫 번째 명령을 받은 셈이다. 어디로 갈 것인가를 결정하기 전에 먼저 어떤 방식으로 대화할 것인가를 확인한 것이다.

도메인을 알았다고 원하는 페이지까지 찾은 것은 아니다

HTTPS 다음에는 보통 example.com처럼 사람이 읽을 수 있는 이름이 나온다. 이것이 도메인이다. DNS를 살펴보았던 글에서 도메인은 사람이 기억하기 어려운 IP 주소 대신 사용할 수 있는 이름이라고 설명하였다.

브라우저는 이 도메인을 바탕으로 DNS에 해당 서버의 IP 주소를 물어본다. IP 주소를 알아내면 라우터와 여러 네트워크 장비를 거쳐 목적지 서버까지 데이터를 보낼 수 있다.

여기까지는 지금까지 살펴본 기술들이 차례대로 다시 등장한다. URL에서 도메인을 확인하고, DNS를 이용하여 IP 주소를 찾고, 네트워크는 패킷을 목적지까지 전달한다. TCP가 필요한 통신에서는 연결 상태와 데이터 전달을 관리하고, 포트 번호를 이용해 서버 안에서 필요한 프로그램을 찾아간다.

각 기술을 따로 볼 때는 서로 다른 주제로 느껴졌지만 실제 인터넷에서는 이런 기술들이 따로 움직이지 않는다. 사용자가 주소창에 주소 하나를 입력하는 순간 여러 기술이 순서대로 자신의 역할을 수행한다.

URL에는 포트 번호가 직접 표시될 수도 있다. 예를 들어 도메인 뒤에 콜론과 숫자를 붙이는 방식이다. 다만 일반적인 웹 이용에서는 HTTP와 HTTPS가 주로 사용하는 포트가 정해져 있기 때문에 주소창에서 포트 번호를 직접 보는 일은 많지 않다.

그렇다고 포트가 사라진 것은 아니다. 주소에 적지 않았을 뿐 브라우저와 서버가 통신하기 위해서는 여전히 어떤 서비스와 연결할지 구분하는 과정이 필요하다.

짧은 생각

DNS와 IP 주소, 라우터, TCP, 포트, HTTP를 하나씩 배울 때는 각자 떨어져 있는 기술처럼 보였다. URL 하나를 따라가 보면 이 기술들이 실제로는 한 번의 웹 접속을 위해 차례대로 이어져 있다는 사실이 조금 더 분명해진다.

서버 안에서는 경로가 다시 목적지를 좁힌다

도메인이 서버까지 찾아가기 위한 주소라면 그 뒤에 붙는 /article/network 같은 부분은 서버에서 어떤 자료를 요청하는지를 표현한다. 이를 보통 경로 또는 Path라고 한다.

하나의 뉴스 사이트만 생각해도 서버에는 수많은 기사가 있다. 쇼핑몰에는 상품 페이지와 장바구니, 주문내역, 고객센터 같은 여러 기능이 들어 있다. 도메인만 전달한다면 어느 사이트에 접속할지는 알 수 있어도 그 안에서 무엇을 보고 싶은지는 충분히 알기 어렵다.

경로는 바로 이 문제를 해결한다. 서버는 브라우저가 요청한 경로를 확인하고 그에 맞는 자료나 기능을 찾아 응답한다.

다만 주소창에 보이는 경로가 실제 서버의 폴더 구조와 반드시 똑같은 것은 아니다. 예전의 웹에서는 서버에 저장된 파일과 주소가 비교적 직접적으로 연결되는 경우가 많았다. 지금의 웹서비스는 프로그램이 주소를 해석한 뒤 데이터베이스에서 정보를 조회하거나 여러 기능을 실행해 그 결과를 만들어 주는 경우가 많다.

우리가 게시물 하나를 열었을 때 서버가 미리 만들어 놓은 HTML 파일 하나만 꺼내 주는 것이 아니라는 뜻이다. 사용자의 요청을 받은 서버 프로그램이 데이터베이스에서 글 제목과 본문, 작성시간 같은 정보를 찾고 필요한 화면을 만들어 브라우저에 전달할 수도 있다.

여기에서 인터넷 이야기는 자연스럽게 다음 단계로 넘어간다. 지금까지는 데이터를 목적지까지 보내는 방법을 주로 살펴보았다면, 이제부터는 목적지에 도착한 요청을 서버가 어떻게 처리하는가라는 문제가 중요해진다.

물음표 뒤에는 찾고 싶은 조건을 더 넣을 수 있다

URL을 보다 보면 주소 중간에 물음표가 붙고 그 뒤로 여러 문자가 길게 이어지는 경우가 있다. 이 부분은 흔히 쿼리스트링(Query String)이라고 부른다.

경로가 어떤 기능이나 자료를 원하는지를 알려준다면 쿼리스트링은 그 요청에 조건을 더하는 데 사용할 수 있다.

검색 사이트를 떠올리면 이해하기 쉽다. 사용자가 어떤 단어를 검색했는지, 몇 번째 페이지를 보고 있는지, 어떤 조건으로 목록을 정렬했는지 같은 정보를 주소에 담아 서버로 전달할 수 있다.

온라인 쇼핑몰에서도 비슷하다. 같은 상품목록이라도 가격순으로 정렬할 수도 있고 인기순으로 볼 수도 있다. 특정 브랜드나 가격 범위를 선택할 수도 있다. 기본적으로 같은 기능을 이용하면서 사용자가 선택한 조건만 추가해 서버에 전달할 수 있는 것이다.

쿼리스트링은 물음표 뒤에서 시작하며 여러 조건이 있을 때는 각각을 구분하여 전달할 수 있다. 서버 프로그램은 이를 읽고 필요한 처리를 수행한다.

여기에서 주의할 점도 있다. 주소창에 나타난 정보는 사용자에게 보인다. 주소를 복사하면 그 내용도 함께 복사될 수 있고 방문 기록에도 남을 수 있다. 따라서 비밀번호처럼 노출되어서는 안 되는 정보를 단순히 URL에 넣는 것은 적절하지 않다.

HTTPS를 사용한다고 해서 주소에 어떤 정보를 넣어도 괜찮다는 뜻도 아니다. HTTPS는 통신 과정의 중요한 부분을 보호하지만 프로그램을 어떻게 설계하고 어떤 데이터를 어디에 담을 것인가는 또 다른 문제이다.

주소의 마지막 조각은 같은 페이지 안에서도 위치를 가리킨다

URL 끝에서 # 뒤에 붙는 부분을 프래그먼트(Fragment)라고 한다. 긴 웹페이지에서 특정 위치로 바로 이동할 때 사용할 수 있다.

설명서나 긴 문서를 열었을 때 주소를 눌렀더니 페이지의 처음이 아니라 중간의 특정 제목으로 바로 이동하는 경우가 있다. 이런 동작에 프래그먼트가 사용될 수 있다.

쿼리스트링과 비슷하게 주소 뒤에 붙어 있어 처음 보면 같은 종류처럼 보이지만 역할은 다르다. 쿼리스트링은 서버에서 어떤 결과를 만들어 달라고 요청하는 조건으로 사용되는 경우가 많은 반면, 프래그먼트는 받아온 문서 안에서 특정 위치를 찾는 데 사용될 수 있다.

결국 URL 한 줄에는 여러 단계의 목적지 정보가 겹쳐 있다. 어떤 방식으로 통신할 것인지, 어느 서버로 갈 것인지, 서버에서 어떤 자원을 원하는지, 어떤 조건으로 처리할 것인지, 화면의 어느 위치를 보여줄 것인지까지 표현할 수 있다.

구성요소	주요 역할	쉽게 이해하면
HTTPS	서버와 어떤 방식으로 통신할지 정한다.	대화 방법
도메인	접속하려는 서버를 찾는 데 사용한다.	찾아갈 건물
포트	서버 안에서 통신할 서비스를 구분한다.	건물 안의 창구
경로	서버에서 필요한 자료나 기능을 지정한다.	찾아갈 방
쿼리스트링	요청에 필요한 조건이나 값을 전달한다.	추가 요청사항
프래그먼트	문서 안의 특정 위치를 가리킬 수 있다.	문서 안의 위치

인터넷 주소를 이해하면 정보체계가 조금 다르게 보인다

URL은 웹브라우저에서 사용하는 주소이지만 그 안에 들어 있는 생각은 생각보다 넓다. 결국 컴퓨터가 수많은 시스템과 정보 가운데 필요한 대상을 정확하게 식별하고 그곳에 필요한 요청을 전달하는 방법의 하나이기 때문이다.

인터넷에서는 수많은 서버와 서비스가 동시에 운영된다. 사용자가 원하는 정보를 얻으려면 먼저 어느 서버와 통신할 것인지 알아야 하고, 그 서버에서 어느 기능을 사용할 것인지도 구분해야 한다.

정보체계의 규모가 커질수록 이런 구분은 더 중요해진다. 서버가 여러 대가 되고 데이터베이스와 응용프로그램이 늘어나면 어떤 정보가 어디에 있으며 어느 시스템이 어떤 기능을 제공하는지 알아야 서로 연결할 수 있기 때문이다.

이 문제는 우리가 사용하는 일반 인터넷에만 있는 것이 아니다. 기업이나 공공기관의 업무체계도 여러 서버와 데이터베이스, 사용자 단말기와 응용프로그램을 연결하여 운영한다. 필요한 정보를 정확한 시스템에서 찾아 필요한 사용자에게 제공해야 한다는 기본 원리는 같다.

군에서 사용하는 정보체계도 규모와 보안 수준은 다르지만 정보가 어디에서 만들어졌고 어디로 전달되어야 하는지를 구분해야 한다는 점에서는 비슷한 문제를 가지고 있다.

지휘소에서 만들어지는 정보도 있고 감시체계나 센서에서 들어오는 정보도 있다. 다른 부대나 다른 종류의 정보체계에서 전달되는 자료도 있다. 이처럼 연결되는 대상이 많아질수록 단순히 통신망을 연결하는 것만으로는 충분하지 않다.

어떤 정보인지 구분해야 하고, 어느 체계가 사용해야 하는지 알아야 하며, 서로 다른 체계가 같은 데이터를 어떻게 이해할지도 정해야 한다. 필요한 사람에게 필요한 정보를 전달하면서 허가되지 않은 사용자는 접근하지 못하도록 하는 문제도 함께 해결해야 한다.

앞선 글에서 HTTPS를 살펴보며 안전하게 정보를 전달하는 문제를 만났다면 URL에서는 필요한 정보를 정확하게 찾아가는 문제를 만나게 된다. 앞으로 살펴볼 서버와 데이터베이스, 시스템 간 연동 기술까지 더해지면 이러한 요소들이 실제 정보체계 안에서 어떻게 하나로 묶이는지도 조금씩 보이기 시작한다.

이러한 기반기술은 시간이 지나면서 군 정보통신에서도 다양한 형태로 활용되어 왔다. 그리고 많은 정보체계가 연결되면서 지휘통제체계와 센서, 전술데이터링크 같은 기술이 서로 정보를 주고받는 환경으로 발전하였다. 군 뿐만 아니라 어느 조직에서도 AI를 업무에 적용하고 AI를 발판으로 삼아 한단계 업그레이드 하려는 노력이 계속되고 있지만 아직은 완전한  AIX 로의 시대라기 보다는 그 과도기라고 보면 된다. 이미 과도기에서 새로운 문제가 생기고 있다. 정보를 전달하지 못해서가 아니라 오히려 너무 많은 정보가 빠르게 들어오기 때문에 사람이 필요한 내용을 골라내고 판단하는 일이 어려워지는 문제이다. 오늘날 인공지능이 정보분석과 상황인식, 의사결정 지원 분야에서 주목받는 이유도 결국 이러한 변화와 떨어져 있지 않다.

군 정보체계의 AI 로드맵까지는 아직 갈 길이 멀다. 이 블로그에서도 마찬가지다. AI 적용 이전에  정보가 서버에서 어떻게 처리되고 저장되는지, 서로 다른 시스템은 어떻게 정보를 주고받는지부터 이해해야 한다. 지금까지 살펴본 인터넷의 기본기술은 바로 그 다음 이야기를 이해하기 위한 바닥을 만들고 있다.

주소 하나를 입력한 뒤에 벌어지는 일

URL을 단순히 인터넷 주소라고만 알고 있어도 웹을 사용하는 데 큰 불편은 없다. 브라우저가 대부분의 과정을 대신 처리하기 때문이다.

하지만 주소 하나를 조금 나누어 보면 지금까지 살펴본 인터넷 기술들이 한꺼번에 모습을 드러낸다. HTTPS는 통신 방법을 알려주고 도메인은 DNS를 통해 서버의 IP 주소를 찾게 한다. 네트워크는 그 서버까지 패킷을 전달하고 포트는 사용할 서비스를 구분한다. 경로와 쿼리스트링은 서버에 어떤 자료와 처리를 원하는지를 보다 구체적으로 알려준다.

이 모든 과정은 사용자가 주소창에 몇 글자를 입력하고 엔터를 누른 뒤 아주 짧은 시간 안에 이루어진다.

그런데 아직 하나의 과정이 크게 남아 있다. 요청이 서버에 도착한 뒤의 일이다.

수많은 사람이 동시에 웹사이트에 접속하면 서버에는 계속해서 요청이 들어온다. 어떤 사람은 첫 화면을 요청하고, 다른 사람은 로그인하며, 누군가는 검색을 하고 또 다른 사람은 파일을 내려받는다.

서버는 이 요청을 어떻게 구분하고 처리할까. 필요한 정보는 어디에서 찾아오며, 수많은 요청이 동시에 몰려와도 어떻게 각각의 사용자에게 올바른 결과를 돌려줄까.

지금까지는 정보를 목적지까지 보내는 길을 따라왔다. 다음부터는 그 길 끝에 있는 서버와 정보체계의 안쪽으로 조금 더 들어가 볼 차례이다.

짧은 생각

인터넷을 이해하다 보면 처음에는 서로 상관없어 보였던 기술들이 하나씩 연결된다. 주소를 찾고, 길을 선택하고, 데이터를 나누어 보내고, 통신할 프로그램을 찾아 안전하게 대화한다. 이제 그 데이터가 목적지에 도착한 뒤 어떻게 처리되는지를 알게 되면 우리가 사용하는 정보체계의 모습도 조금씩 보이기 시작한다.