URL (r1)

스킴은 URL의 첫 번째 구성 요소로, 자원에 접근하는 데 사용할 프로토콜이나 프로시저를 지정합니다. 콜론(:)으로 끝나며, URL의 나머지 부분을 해석하는 방법을 정의합니다. 가장 흔한 예는 HTTP와 HTTPS이며, 각각 http:와 https:로 표시됩니다. 이 외에도 FTP(ftp:), 메일토(mailto:), 파일(file:) 등 다양한 스킴이 존재합니다.

스킴은 클라이언트(예: 웹 브라우저)나 서버가 어떤 통신 규칙을 사용해야 하는지를 알려줍니다. 예를 들어, http: 스킴은 서버와의 표준 하이퍼텍스트 통신을, https:는 암호화된 보안 연결을 사용하도록 지시합니다. mailto: 스킴은 이메일 클라이언트를 실행시키고, ftp:는 파일 전송 프로토콜을 통해 파일 서버에 접근하게 합니다.

일부 스킴은 권한 구성 요소(예: //example.com)를 필요로 하지만, mailto:나 news:와 같은 스킴은 이를 요구하지 않을 수 있습니다. 스킴 이름은 대소문자를 구분하지 않으며, 일반적으로 소문자로 작성하는 것이 관례입니다. 스킴의 존재는 URL을 다른 종류의 식별자나 주소와 구분하는 핵심 특징입니다.

권한 부분은 URL에서 자원이 위치한 서버나 네트워크 위치를 식별하는 구성 요소이다. 이 부분은 일반적으로 호스트를 포함하며, 선택적으로 포트 번호와 사용자 정보(사용자명과 비밀번호)를 포함할 수 있다. 권한 구성 요소는 스킴 다음에 콜론 두 개(://)로 시작하여 구분된다.

권한의 가장 핵심 요소는 호스트이다. 호스트는 도메인 이름(예: www.example.com)이나 IP 주소(예: 192.0.2.1)로 표현된다. 호스트 앞에는 선택적으로 사용자 정보가 올 수 있으며, 이는 사용자명:비밀번호@ 형식으로 표기한다. 그러나 보안상의 이유로 현대에는 자격 증명을 URL에 직접 포함하는 방식은 거의 사용되지 않는다. 호스트 뒤에는 콜론(:)으로 구분하여 포트 번호를 지정할 수 있다. 포트는 특정 네트워크 서비스를 식별하는 논리적인 통로이다. 만약 포트가 생략되면, 스킴에 따라 기본 포트가 사용된다(예: HTTP는 80, HTTPS는 443).

다음은 권한 구성 요소의 구조를 보여주는 표이다.

권한 부분은 DNS를 통해 호스트 이름을 IP 주소로 변환하는 과정을 거쳐, 클라이언트(예: 웹 브라우저)가 올바른 서버에 연결할 수 있도록 한다. 포트 지정은 동일한 서버에서 여러 서비스(예: 웹 서버와 메일 서버)를 구분하여 실행할 때 중요하게 작동한다.

경로는 URL에서 서버 내부의 특정 리소스나 디렉터리의 위치를 지정하는 부분이다. 권한 구성 요소 뒤에 슬래시(/)로 시작하며, 서버의 파일 시스템 구조나 논리적 계층을 반영하는 계층적 구조를 가진다.

경로는 일반적으로 디렉터리와 파일명을 슬래시(/)로 구분하여 표현한다. 예를 들어, /wiki/URL이라는 경로는 최상위 루트 디렉터리 아래의 wiki 디렉터리 내에 있는 URL이라는 리소스를 가리킨다. 현대의 웹 애플리케이션에서는 실제 물리적 파일 구조가 아닌, 라우팅을 위한 논리적 경로로 사용되는 경우가 많다.

경로 구성 요소는 선택 사항이다. 경로가 생략된 URL(예: https://example.com)은 일반적으로 서버에 정의된 기본 리소스(예: index.html)를 요청한다. 경로의 구분자 슬래시(/)는 예약 문자에 속하므로, 경로 내에서 일반 문자로 사용해야 할 경우 퍼센트 인코딩(%2F)을 통해 표현해야 한다.

쿼리 문자열은 URL에서 물음표(?)로 시작하여 프래그먼트가 있다면 해시(#) 전까지, 없다면 URL의 끝까지 이어지는 부분이다. 주로 웹 서버에 추가적인 매개변수를 전달하는 데 사용된다. 이는 사용자가 검색을 하거나, 필터를 적용하거나, 폼 데이터를 제출할 때 서버에 정보를 보내는 표준적인 방법이다.

쿼리 문자열은 일반적으로 키=값 쌍으로 구성되며, 여러 개의 쌍이 있을 경우 앰퍼샌드(&)로 구분된다. 예를 들어, ?category=books&sort=date라는 쿼리는 'category' 키에 'books' 값을, 'sort' 키에 'date' 값을 할당하여 서버에 전달한다. 키와 값은 반드시 URL 인코딩을 통해 안전한 문자 집합으로 변환되어야 한다. 예를 들어 공백은 %20 또는 더하기 기호(+)로 인코딩된다.

서버 측 애플리케이션은 이 쿼리 문자열을 파싱하여 사용자의 요청을 처리한다. PHP의 $_GET, 파이썬의 cgi.FieldStorage(), 자바스크립트의 URLSearchParams와 같은 도구들이 이를 위한 내장 기능을 제공한다. 쿼리 문자열은 상태가 없는 HTTP 프로토콜에서 특정 리소스에 대한 임시적인 상태나 옵션을 지정하는 중요한 수단으로 작동한다.

프래그먼트는 URL의 마지막 구성 요소로, 해시(#) 기호 뒤에 오는 부분을 가리킨다. 이 부분은 서버로 전송되지 않으며, 브라우저가 리소스 내부의 특정 지점을 식별하는 데 사용한다. 주로 HTML 문서 내의 특정 앵커 요소나 미디어 파일의 특정 시점으로 이동할 때 활용된다.

프래그먼트의 주요 용도는 다음과 같다.

* 문서 내부 탐색: 긴 웹 페이지에서 특정 제목이나 단락으로 바로 스크롤할 수 있게 한다. 예를 들어, #역사라는 프래그먼트는 해당 페이지에서 id="역사" 속성을 가진 요소로 이동시킨다.

* 미디어 조각 식별: 비디오나 오디오 파일의 특정 재생 시간대로 이동할 때 사용된다. 예를 들어, #t=120은 120초 지점부터 재생을 시작하도록 지시한다.

* 단일 페이지 애플리케이션(SPA) 내비게이션: 자바스크립트 기반의 현대 웹 애플리케이션에서 화면 전환을 관리하는 데 활용되기도 한다.

프래그먼트는 서버에 요청을 보내지 않기 때문에 페이지를 새로고침하지 않고도 콘텐츠의 특정 부분을 보여줄 수 있다. 이는 사용자 경험을 향상시키고 대역폭을 절약하는 데 기여한다. 또한, 프래그먼트가 포함된 URL을 공유하면 받는 사람이 정확히 같은 콘텐츠 지점부터 볼 수 있다는 장점이 있다.

URL의 표준화와 발전은 주로 IETF에서 발행하는 RFC 문서를 통해 이루어졌다. 초기 개념은 1994년 팀 버너스리에 의해 제안되었으며, 월드 와이드 웹의 핵심 요소로 자리 잡았다.

공식적인 표준화는 RFC 1738 "Uniform Resource Locators (URL)"에서 시작되었다. 이 문서는 URL의 일반 문법과 특정 스킴의 구체적 문법을 정의했다. 이후 1998년 RFC 2396 "Uniform Resource Identifiers (URI): Generic Syntax"가 등장하며, URI의 일반 문법을 통합적으로 정의했고, URL은 URI의 하위 개념으로 자리매김했다. 최종적으로는 2005년 RFC 3986 "Uniform Resource Identifier (URI): Generic Syntax"가 현재의 표준 문법을 확립했다[5].

RFC 문서의 발전 과정을 연표로 정리하면 다음과 같다.

이러한 표준화 과정을 통해 URL은 단순한 주소 체계를 넘어, 인터넷 상의 자원을 체계적으로 식별하고 접근하는 데 필수적인 표준 프로토콜로 발전했다.

URI(Uniform Resource Identifier)는 인터넷 상의 자원을 식별하는 문자열의 가장 포괄적인 개념이다. URI는 자원의 위치를 나타내는 URL(Uniform Resource Locator)과 자원의 이름을 나타내는 URN(Uniform Resource Name) 두 가지 주요 하위 개념으로 나뉜다. 모든 URL과 URN은 URI이지만, 모든 URI가 URL이나 URN인 것은 아니다.

URL과 URN의 가장 큰 차이는 자원의 위치와 이름에 있다. URL은 http://, ftp://와 같은 프로토콜과 호스트명, 경로를 포함하여 자원의 구체적인 위치와 접근 방법을 지정한다. 예를 들어 https://www.example.com/page.html은 그 자원이 어디에 있는지 위치를 알려준다. 반면, URN은 위치에 독립적인 영구적인 자원의 이름을 제공하는 것을 목표로 한다. urn:isbn:0451450523과 같은 형식은 특정 책을 고유하게 지칭하지만, 그 책을 어디서 얻을 수 있는지는 알려주지 않는다.

실제 웹에서 가장 널리 사용되는 것은 URL이다. URN은 개념적으로는 유용하지만, 널리 구현되거나 채택되지는 못했다. 따라서 현실에서는 URI와 URL이라는 용어가 종종 혼용되어 사용되기도 한다. 기술적으로는 URI가 더 넓은 범주이며, URL은 그 하위 집합이다.

퍼센트 인코딩은 URL에서 특정 문자를 안전하게 표현하기 위한 메커니즘이다. 이는 ASCII 문자 집합에 포함되지 않거나, URL 문법에서 특별한 의미를 가지는 '예약 문자'를 URL에 포함시킬 때 사용된다. 인코딩은 퍼센트 기호('%') 뒤에 해당 문자의 ASCII 코드를 16진수(hexadecimal) 두 자리로 나타내는 방식으로 이루어진다[6].

주요 인코딩 대상은 다음과 같다.

이 인코딩은 쿼리 문자열을 통해 데이터를 전송할 때 특히 중요하다. 예를 들어, 검색어 "안녕 하세요"는 "안녕%20하세요"와 같이 인코딩되어 전송된다. 또한, 영어가 아닌 문자(예: 한글, 한자)나 이모지와 같은 유니코드 문자는 일반적으로 UTF-8과 같은 문자 인코딩 방식으로 바이트 시퀀스로 변환된 후, 각 바이트가 퍼센트 인코딩된다[7].

웹 브라우저나 서버 측 애플리케이션은 URL을 해석할 때 이 인코딩된 문자열을 원래의 문자로 자동 변환(디코딩)한다. 개발자는 데이터를 URL에 포함시킬 때 적절히 인코딩해야 하며, 수신 측에서는 안전하게 디코딩하여 처리해야 한다. 이를 통해 다양한 문자로 구성된 데이터도 URL을 통해 오류 없이 전달될 수 있다.

URL에서 사용 가능한 문자는 퍼센트 인코딩 규칙에 따라 예약 문자(reserved characters)와 비예약 문자(unreserved characters)로 구분된다. 이 구분은 해당 문자가 URL 내에서 특별한 의미(구분자 역할)를 가지는지, 아니면 데이터 자체를 나타내는 데 자유롭게 사용될 수 있는지에 기반한다.

비예약 문자는 URL의 어느 부분에서도 그대로 사용할 수 있는 안전한 문자 집합이다. 이는 대소문자 영문 알파벳(A-Z, a-z), 숫자(0-9), 그리고 하이픈(-), 밑줄(_), 마침표(.), 물결표(~) 네 개의 특수 문자로 구성된다[8]. 이 문자들은 퍼센트 인코딩으로 변환되지 않아도 되며, 일반적으로 리터럴 데이터를 표현하는 데 사용된다.

반면, 예약 문자는 URL 구조에서 구분자(delimiter) 역할을 하기 위해 예약되어 있다. 따라서 이 문자들을 해당 구분자 역할이 아닌, 데이터의 일부로 사용하려면 반드시 퍼센트 인코딩되어야 한다. 주요 예약 문자와 그 일반적인 용도는 다음과 같다.

예를 들어, 쿼리 문자열에서 &는 일반적으로 키-값 쌍을 구분하는 데 사용된다. 따라서 실제 값에 & 문자를 포함시키려면 %26으로 인코딩해야 한다. 이 규칙을 준수하지 않으면 URL 파서가 구조를 잘못 해석하여 오류를 일으키거나 의도하지 않은 동작을 초래할 수 있다.

HTTPS는 HTTP의 보안 버전으로, SSL 또는 TLS 프로토콜을 통해 데이터 통신을 암호화한다. 이는 클라이언트와 서버 사이에 전송되는 모든 데이터(예: 로그인 정보, 결제 정보, 개인 메시지)가 제3자에 의해 도청되거나 변조되는 것을 방지하는 것을 목표로 한다. HTTPS를 사용하는 웹사이트의 URL은 "https://" 스킴으로 시작하며, 대부분의 현대 웹 브라우저는 주소창에 자물쇠 아이콘을 표시하여 보안 연결 상태를 시각적으로 알려준다.

보안 연결의 핵심은 디지털 인증서를 통한 서버 신원 확인과 암호화 채널 구축에 있다. 사용자가 HTTPS 사이트에 접속하면, 서버는 인증 기관으로부터 발급받은 인증서를 브라우저에 제공한다. 브라우저는 이 인증서가 신뢰할 수 있는 기관에 의해 발급되었는지, 그리고 해당 인증서의 도메인 이름이 접속하려는 사이트의 도메인과 일치하는지 검증한다. 이 과정을 통해 사용자는 의도한 정당한 서버와 통신하고 있음을 확인할 수 있다.

HTTPS의 채택은 웹 보안의 표준이 되었다. 주요 검색 엔진들은 HTTPS 사이트를 검색 결과 순위에서 약간의 가중치를 주며, 크롬과 같은 브라우저는 HTTP 사이트에 대해 "안전하지 않음" 경고를 표시한다[10]. 이로 인해 개인정보 보호, 데이터 보안, 그리고 사이트 신뢰도 향상을 위해 모든 유형의 웹사이트가 HTTPS로 전환하는 것이 강력히 권장된다.

피싱은 사이버 범죄 기법의 하나로, 합법적인 웹사이트나 서비스를 사칭하여 사용자의 개인 정보나 금융 정보를 탈취하는 행위를 말한다. 피싱 공격은 주로 이메일이나 문자 메시지를 통해 위조된 URL을 전송하는 방식으로 이루어진다. 이 URL은 사용자를 속여 악성 사이트로 유도한다.

피싱 URL은 시각적으로 합법적인 URL과 유사하게 위장하는 방법을 사용한다. 공통적인 기법으로는 호모그래프 공격[11], 서브도메인을 악용한 긴 URL 생성, 또는 일반적으로 신뢰받는 도메인 이름 뒤에 악의적인 경로를 추가하는 방법이 있다. 예를 들어, www.secure-paypal.com과 같은 도메인은 공식 PayPal 사이트(www.paypal.com)와 무관할 수 있다.

사용자는 피싱 URL로부터 자신을 보호하기 위해 몇 가지 주의 사항을 지켜야 한다. 링크를 클릭하기 전에 마우스 커서를 올려 실제 목적지 URL을 확인하는 것이 중요하다. 또한, 발신자의 이메일 주소나 메시지의 문맥을 의심하고, 특히 긴급한 조치를 요구하거나 개인 정보 입력을 유도하는 통신에 대해 주의를 기울여야 한다. 최신 웹 브라우저와 안티바이러스 소프트웨어는 종종 피싱 사이트를 차단하는 기능을 포함하고 있다.

의심스러운 사이트에 개인정보를 입력한 경우, 즉시 해당 계정의 비밀번호를 변경하고 필요한 경우 금융 기관에 연락해야 한다. 많은 기관과 국가는 피싱 사례를 신고할 수 있는 공식 채널을 운영하고 있다[12].