T_era

DNS와 URI 개요 본문

이론/백엔드 개념정리

DNS와 URI 개요

블스뜸 2025. 5. 2. 18:53

DNS(Domain Name System) 는 사람이 가독적인 도메인 이름을 컴퓨터가 인식 가능한 IP 주소로 변환하는 시스템이다.

DNS 등장 배경

컴퓨터 간 통신에는 IP 주소가 필수적이나, IP 주소는 사이트별 특징이 없고 길이가 길어 암기가 어렵다.
또한, IP 주소는 유동적으로 변경될 수 있으며, 변경 시 기존 IP 주소로는 접근이 불가능해진다.
일반 가정에서 사용되는 IP는 대부분 유동 IP에 해당한다.

DNS 동작 순서

  1. 사용자는 원하는 도메인 이름을 구매 후 DNS 서버에 등록한다.
  2. 사용자가 웹 브라우저에 도메인 이름을 입력하면, DNS 서버는 해당 도메인 이름에 매핑된 IP 주소를 반환한다.
  3. IP 주소 변경 시, DNS 서버에 등록된 IP 주소 정보만 갱신하면 된다.

결과적으로 사용자는 IP 주소 형태가 아닌 도메인 이름 형태로 웹에 접속하며, URL은 DNS 활용의 대표적인 예시이다.\


왜 도메인을 구매하라고 하는 것일까?

DNS를 사용해야 하는 경우:

  • 자신만의 도메인 이름(예: mywebsite.com)으로 웹사이트나 서비스를 운영하고 싶을 때 도메인 이름을 먼저 구매해야한다. 구매한 도메인 이름을 특정 IP 주소에 연결하기 위해서는 DNS 설정이 필요하다.

DNS 사용 방법 선택지:

  1. 도메인 등록 업체의 DNS 서비스 이용 (일반적): 대부분의 도메인 등록 업체는 도메인을 구매하면 무료로 DNS 관리 서비스를 제공한다. 따라서 별도의 DNS 서버를 구축하거나 DNS 서비스를 구매할 필요 없이, 해당 업체의 관리 도구를 통해 IP 주소와 도메인 이름을 연결하는 등의 DNS 설정을 할 수 있다.
  2. 무료 DNS 서비스 이용: 일부 업체나 단체에서 무료 DNS 서비스를 제공하기도 한다. 개인적인 용도나 트래픽이 많지 않은 소규모 프로젝트의 경우 고려해 볼 수 있다. 다만, 유료 서비스에 비해 기능이나 안정성 면에서 제약이 있을 수 있다.
    (예: Google Public DNS, Cloudflare Free DNS 등)
  3. 클라우드 기반 DNS 서비스 이용 (유료): AWS Route 53, Google Cloud DNS, Azure DNS 등 클라우드 플랫폼에서 제공하는 DNS 서비스는 높은 가용성, 확장성, 다양한 부가 기능을 제공한다. 트래픽이 많거나 안정적인 DNS 운영이 중요한 상업적인 서비스에 적합하며, 일반적으로 사용량에 따라 비용이 발생한다.
  4. 자체 DNS 서버 구축 (고급 사용자): 직접 DNS 서버(예: BIND, PowerDNS)를 구축하고 운영할 수도 있지만, 이는 전문적인 지식과 지속적인 관리가 필요하며 일반적인 경우에는 권장되지 않는다.

결론:

  • 개인 도메인 이름으로 서비스를 운영하려면 도메인 구매는 필수적.
  • DNS 설정은 일반적으로 도메인 등록 업체의 무료 DNS 관리 서비스를 통해 간편하게 이용할 수 있다.
  • 무료 DNS 서비스 클라우드 기반 DNS 서비스는 필요에 따라 대안으로 고려할 수 있다.
  • 자체 DNS 서버 구축은 전문적인 환경이 아니라면 권장되지 않는다.



URI (Uniform Resource Identifier)

URI는 인터넷 자원을 나타내는 통일된 고유 식별자이다.

  • Uniform: 자원 식별의 통일된 방식 의미
  • Resource: 페이지, 텍스트, 이미지, 동영상, 파일 등
  • Identifier: 식별자

URI는 인터넷 자원을 식별하는 문자열이며, Locator, Name 또는 둘 다로 분류될 수 있다.

URL (Uniform Resource Locator)

URL자원의 위치를 명시하며, 일반적으로 도메인 주소로 알려져 있다. 프로토콜을 포함하는 것이 특징이다.
(예: https://spartacodingclub.kr/)

URL 구조

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

  • scheme: 주로 프로토콜 (http, https, ftp 등). https는 http에 보안(Secure) 기능이 추가된 것이다.
  • user[:password]: 사용자 정보. 보안 취약성으로 인해 URL에 직접 사용하지 않는다.
  • host[:port]: 호스트명 (도메인명 또는 IP 주소). http: 80, https: 443 포트를 사용하며, 일반적으로 생략된다.
  • [/path]: 리소스의 경로. 계층 구조로 표현된다. (예: /products/macbookPro, /backend)
  • [?query]: key=value 형태의 질의 문자열 (Query Parameter, Query String과 동일한 의미). ?로 시작하고 &으로 구분된다. (예: ?key1=value1&key2=value2)
  • [#fragment]: HTML 내부 북마크 등에 사용되며, URL 접속 시 특정 위치로 이동한다.

URL프로토콜을 포함하여 자원의 위치를 나타낸다.

URL 방식의 한계

자원의 위치가 변경되면 기존 URL은 더 이상 유효하지 않다.
예를 들어, 웹사이트 주소가 변경되면 기존 URL을 알고 있는 사용자는 업데이트된 URL 정보를 확인하지 않으면 접속할 수 없다.

URN (Uniform Resource Name)

URN자원의 이름(Name)을 의미한다. (예: 튜터)
리소스의 위치가 변경되더라도 이름으로 리소스를 찾을 수 있어 URL 방식의 한계를 극복하기 위해 등장했다.
프로토콜을 포함하지 않는 것이 특징이다. 그러나 URN을 통해 실제 리소스에 접근하는 방식은 아직 널리 사용되지 않고 있다.


왜 아직 URL을 많이 사용할까?

URL의 압도적인 보급과 인프라:

  • WWW(World Wide Web)의 기반: 웹은 URL을 중심으로 설계되어서 전환비용이 상당하다
  • 직관성과 사용 편의성: URL은 자원의 위치를 명시적으로 보여주기 때문에 사용자 입장에서 이해하기 쉽고, 웹 브라우저 주소창에 직접 입력하거나 링크를 클릭하여 쉽게 접근할 수 있다.

URN의 실질적인 접근 및 해결 메커니즘 부재:

  • 해석(Resolution) 문제: URN은 자원의 고유한 이름을 제공하지만, 그 이름을 기반으로 실제 자원에 어떻게 접근해야 하는지에 대한 표준화된 해결(resolution) 메커니즘이 널리 채택되지 못했다.
    URN으로 탐색해도 메인화면을 벗어나지 못한다
  • 중앙 집중화의 어려움: URN은 전역적으로 고유해야 하므로, 이를 관리하고 유지하기 위한 중앙 집중화된 시스템이 필요
    이러한 시스템을 구축하고 모든 자원에 고유한 URN을 할당하는 것은 현실적으로 매우 복잡하고 어려운 문제.

URL의 지속적인 발전:

  • URL 자체도 끊임없이 발전해서 HTTPS를 통한 보안 연결, 국제화된 도메인 이름(IDN) 지원 등 다양한 개선이 이루어져 왔다.

결론적으로, URN은 이론적인 장점에도 불구하고 실제 웹 환경에서의 접근성기존 인프라의 강력한 영향력으로 인해 URL만큼 널리 사용되지 못하고 있다.