DNS와 URI 완벽 가이드

인터넷에서 웹사이트를 찾아가는 원리를 이해하는 핵심 개념입니다. 도메인 네임이 어떻게 IP 주소로 변환되는지, URI와 URL의 차이는 무엇인지 초급 개발자도 쉽게 이해할 수 있도록 설명합니다.

1. 도메인 네임(Domain Name) 이해

김개발 씨는 오늘 처음으로 회사 웹사이트를 배포하게 되었습니다. 선배가 "도메인 연결해 놨어?"라고 물었는데, 순간 머릿속이 하얘졌습니다.

IP 주소는 알겠는데, 도메인이 정확히 뭔지 설명하라고 하면 말문이 막히는 것 같았습니다.

도메인 네임은 숫자로 된 IP 주소를 사람이 기억하기 쉬운 문자로 바꿔놓은 것입니다. 마치 전화번호부에서 친구 이름으로 전화번호를 찾는 것과 같습니다.

192.168.0.1 같은 숫자 대신 google.com처럼 직관적인 이름을 사용할 수 있게 해줍니다.

다음 코드를 살펴봅시다.

// 도메인 네임의 계층적 구조를 이해하는 예제
const domainName = "www.example.com";

// 도메인은 오른쪽에서 왼쪽으로 계층 구조를 가집니다
const parts = domainName.split(".");
console.log("호스트명:", parts[0]);      // www (서브도메인)
console.log("2차 도메인:", parts[1]);    // example (실제 도메인명)
console.log("최상위 도메인:", parts[2]); // com (TLD)

// 실제 서버에서 호스트 정보 확인
const url = new URL("https://www.example.com/path");
console.log("전체 호스트:", url.hostname); // www.example.com
console.log("프로토콜:", url.protocol);    // https:

김개발 씨는 입사 후 처음으로 실서버 배포를 맡게 되었습니다. AWS에서 EC2 인스턴스를 띄우고 나니 54.180.123.45 같은 IP 주소가 할당되었습니다.

그런데 이 숫자를 고객에게 알려줄 수는 없는 노릇입니다. 선배 개발자 박시니어 씨가 설명을 시작합니다.

"도메인 네임이라는 게 있어요. 전화번호부 생각하면 쉬워요." 그렇다면 도메인 네임이란 정확히 무엇일까요?

쉽게 비유하자면, 도메인 네임은 마치 건물의 간판과 같습니다. 실제 건물 위치는 위도와 경도로 표현되지만, 우리는 "강남역 2번 출구 스타벅스"라고 말합니다.

이처럼 도메인 네임도 복잡한 숫자 주소를 친숙한 이름으로 바꿔주는 역할을 합니다. 인터넷 초창기에는 어땠을까요?

사람들은 접속하고 싶은 서버의 IP 주소를 직접 외워야 했습니다. 서버가 10개만 되어도 머리가 아팠습니다.

더 큰 문제는 서버 IP가 바뀌면 모든 사용자에게 새 주소를 알려야 한다는 것이었습니다. 바로 이런 문제를 해결하기 위해 도메인 네임 시스템이 등장했습니다.

이제 사용자는 google.com만 기억하면 됩니다. 구글 서버의 IP가 바뀌더라도 사용자는 전혀 신경 쓸 필요가 없습니다.

도메인 네임은 계층적 구조를 가집니다. www.naver.com을 예로 들면, 맨 오른쪽 com은 **최상위 도메인(TLD)**입니다.

그 왼쪽 naver는 2차 도메인으로 실제 소유자를 나타냅니다. 맨 왼쪽 www는 서브도메인 또는 호스트명입니다.

최상위 도메인에는 여러 종류가 있습니다. com은 상업용, org는 비영리 단체, kr은 대한민국을 나타냅니다.

이런 구조 덕분에 전 세계 수억 개의 도메인이 체계적으로 관리됩니다. 실무에서는 어떻게 활용할까요?

회사에서 새 서비스를 런칭할 때 먼저 도메인을 구매합니다. 가비아, AWS Route 53 같은 도메인 등록 대행업체에서 원하는 이름이 사용 가능한지 확인하고 등록합니다.

주의할 점도 있습니다. 도메인은 선착순입니다.

좋은 이름은 이미 누군가 가져갔을 가능성이 높습니다. 또한 도메인은 매년 갱신해야 하며, 깜빡하면 다른 사람에게 넘어갈 수 있습니다.

다시 김개발 씨 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 이해가 되기 시작했습니다.

"아, 그래서 도메인을 따로 구매하는 거군요!"

실전 팁

💡 - 도메인은 브랜드 자산입니다. 서비스 기획 단계에서 미리 확보하세요

도메인 만료일을 캘린더에 등록해두면 갱신을 놓치지 않습니다

2. 네임 서버(Name Server)의 역할

김개발 씨가 도메인을 구매하고 나니 다음 단계가 궁금해졌습니다. "도메인이랑 서버 IP를 어떻게 연결하는 거예요?" 박시니어 씨가 답합니다.

"네임 서버를 설정해야 해요. 도메인의 안내 데스크 같은 거예요."

네임 서버는 도메인 네임과 IP 주소의 매핑 정보를 저장하고 있는 서버입니다. 마치 114 안내에 전화하면 원하는 번호를 알려주는 것처럼, 네임 서버에 도메인을 물어보면 해당 IP 주소를 알려줍니다.

인터넷의 전화번호부 역할을 수행합니다.

다음 코드를 살펴봅시다.

// Node.js에서 DNS 조회하기
const dns = require("dns");

// 도메인의 IP 주소 조회 (A 레코드)
dns.resolve4("google.com", (err, addresses) => {
  if (err) throw err;
  console.log("IP 주소들:", addresses);
  // 출력: IP 주소들: ['142.250.196.110', ...]
});

// 네임 서버(NS) 레코드 조회
dns.resolveNs("google.com", (err, nameservers) => {
  if (err) throw err;
  console.log("네임 서버:", nameservers);
  // 출력: 네임 서버: ['ns1.google.com', 'ns2.google.com', ...]
});

김개발 씨는 도메인 구매까지는 성공했습니다. 그런데 구매한 도메인으로 접속하면 여전히 아무것도 나오지 않습니다.

뭔가 빠진 게 있는 것 같습니다. 박시니어 씨가 화면을 가리킵니다.

"여기 네임 서버 설정하는 곳 보여요? 이걸 설정해야 도메인이 작동해요." 네임 서버란 무엇일까요?

쉽게 비유하자면, 네임 서버는 마치 도서관 사서와 같습니다. 도서관에 가서 "파이썬 입문서 어디 있어요?"라고 물으면, 사서가 "3층 프로그래밍 섹션 A-15번 선반에 있습니다"라고 안내해줍니다.

네임 서버도 "google.com 어디야?"라고 물으면 "142.250.196.110이야"라고 알려줍니다. 네임 서버가 없던 시절에는 어땠을까요?

초기 인터넷에서는 hosts 파일이라는 것을 사용했습니다. 모든 컴퓨터가 도메인-IP 매핑 목록을 각자 가지고 있어야 했습니다.

새 서버가 추가되면 전 세계 모든 컴퓨터의 hosts 파일을 업데이트해야 했습니다. 상상만 해도 끔찍한 일입니다.

이 문제를 해결하기 위해 분산 데이터베이스 형태의 네임 서버 시스템이 만들어졌습니다. 중앙에서 모든 정보를 관리하는 대신, 각 도메인의 소유자가 자신의 네임 서버를 운영합니다.

네임 서버에는 여러 종류가 있습니다. 가장 먼저 만나는 것이 **리졸버(Resolver)**입니다.

통신사나 구글(8.8.8.8)이 제공하는 서버로, 사용자의 DNS 질의를 대신 처리해줍니다. 그 다음은 **권한 있는 네임 서버(Authoritative Name Server)**입니다.

특정 도메인에 대한 공식 정보를 가진 서버입니다. 예를 들어 google.com의 권한 있는 네임 서버는 구글이 직접 운영합니다.

실무에서 도메인을 구매하면 등록 대행업체에서 기본 네임 서버를 제공합니다. 하지만 AWS나 클라우드플레어 같은 서비스를 사용한다면 해당 서비스의 네임 서버로 변경하는 경우가 많습니다.

주의할 점이 있습니다. 네임 서버를 변경하면 전파되는 데 최대 48시간이 걸릴 수 있습니다.

중요한 서비스라면 미리 변경하고 충분히 기다려야 합니다. 김개발 씨는 AWS Route 53의 네임 서버 주소를 도메인 등록 업체에 입력했습니다.

몇 시간 후, 드디어 도메인으로 접속이 되기 시작했습니다. "와, 진짜 되네요!"

실전 팁

💡 - 네임 서버 변경 후 전파 시간을 고려해 여유있게 작업하세요

nslookup이나 dig 명령어로 DNS 설정을 확인할 수 있습니다

3. 계층적 네임 서버 구조

김개발 씨가 궁금증이 생겼습니다. "전 세계 도메인이 수억 개인데, 네임 서버 하나로 어떻게 다 처리해요?" 박시니어 씨가 웃으며 답합니다.

"하나가 아니에요. 계층 구조로 나뉘어 있어요.

마치 행정 구역처럼요."

DNS는 루트 서버, TLD 서버, 권한 있는 서버로 이어지는 계층 구조를 가집니다. 마치 대통령 - 도지사 - 시장 - 동장으로 이어지는 행정 체계처럼, 각 단계가 자신의 관할 영역을 담당합니다.

이런 분산 구조 덕분에 수십억 개의 도메인을 효율적으로 관리할 수 있습니다.

다음 코드를 살펴봅시다.

// DNS 계층 구조 시뮬레이션
const dnsHierarchy = {
  // 루트 서버 (전 세계 13개)
  root: {
    role: "최상위 관리자",
    manages: ["com", "org", "net", "kr", "jp", "..."]
  },
  // TLD 서버 (최상위 도메인 관리)
  tld: {
    "com": { manages: ["google", "naver", "amazon", "..."] },
    "kr": { manages: ["co.kr", "or.kr", "go.kr", "..."] }
  },
  // 권한 있는 네임 서버 (개별 도메인 관리)
  authoritative: {
    "google.com": { ip: "142.250.196.110", ns: "ns1.google.com" }
  }
};

// 도메인 질의 경로: . -> com -> google.com
console.log("www.google.com 질의 경로:");
console.log("1. 루트 서버에게 'com' TLD 서버 위치 질의");
console.log("2. com TLD 서버에게 'google.com' 네임서버 질의");
console.log("3. google.com 네임서버에게 IP 주소 질의");

김개발 씨는 점심 시간에 문득 의문이 들었습니다. 매일 수십억 건의 DNS 질의가 발생할 텐데, 서버 하나로 어떻게 처리할 수 있을까요?

박시니어 씨가 냅킨에 그림을 그리며 설명합니다. "DNS는 피라미드처럼 생겼어요." DNS 계층 구조는 크게 세 단계로 나뉩니다.

맨 꼭대기에는 루트 네임 서버가 있습니다. 전 세계에 단 13개뿐입니다.

A부터 M까지 알파벳으로 이름이 붙어 있습니다. 하지만 실제로는 애니캐스트 기술로 수백 대의 서버가 분산 운영됩니다.

루트 서버는 모든 도메인 정보를 알고 있을까요? 아닙니다.

루트 서버는 오직 TLD 서버의 위치만 알고 있습니다. "com은 저쪽에 물어봐", "kr은 저기로 가봐"라고 안내만 해줍니다.

두 번째 단계는 TLD(Top-Level Domain) 서버입니다. com, org, net 같은 일반 TLD와 kr, jp, uk 같은 국가 코드 TLD를 각각 다른 서버가 관리합니다.

com TLD 서버는 google.com, naver.com 등 com으로 끝나는 도메인의 네임 서버 위치를 알고 있습니다. 세 번째는 권한 있는 네임 서버입니다.

실제 도메인 소유자가 운영하는 서버입니다. 여기서 비로소 "google.com의 IP는 142.250.196.110이야"라는 최종 답을 얻습니다.

왜 이렇게 복잡하게 만들었을까요? 한 서버가 모든 도메인을 관리하면 단일 장애점이 됩니다.

그 서버가 다운되면 전 세계 인터넷이 마비됩니다. 계층 구조로 분산하면 한 서버에 문제가 생겨도 영향이 제한됩니다.

또한 확장성 문제도 있습니다. 새 도메인이 등록될 때마다 루트 서버를 업데이트할 필요가 없습니다.

google.com이 새 서브도메인을 추가해도 구글의 네임 서버만 수정하면 됩니다. 실무에서 이 구조를 이해하면 DNS 문제 해결이 쉬워집니다.

dig 명령어에 +trace 옵션을 붙이면 실제로 질의가 어떤 경로로 진행되는지 볼 수 있습니다. 김개발 씨가 터미널에서 직접 실행해봅니다.

"오, 진짜 루트에서 시작해서 단계별로 내려가네요!"

실전 팁

💡 - dig +trace google.com 명령어로 DNS 질의 경로를 추적해보세요

루트 서버 목록은 root-servers.org에서 확인할 수 있습니다

4. DNS 질의 과정

김개발 씨가 브라우저에 google.com을 입력했습니다. 엔터를 누르는 순간부터 화면이 뜨기까지, 보이지 않는 곳에서 어떤 일이 벌어질까요?

박시니어 씨가 말합니다. "그 짧은 순간에 꽤 많은 일이 일어나요."

DNS 질의는 재귀적 질의와 반복적 질의 두 가지 방식으로 진행됩니다. 사용자의 컴퓨터가 리졸버에게 물어보면, 리졸버가 대신 여러 서버를 돌아다니며 답을 찾아옵니다.

한번 찾은 결과는 캐싱되어 다음에 더 빠르게 응답할 수 있습니다.

다음 코드를 살펴봅시다.

// DNS 질의 과정 시뮬레이션
async function simulateDnsQuery(domain) {
  console.log(`[1] 브라우저: ${domain} 접속 시도`);

  // 로컬 캐시 확인
  const localCache = checkLocalCache(domain);
  if (localCache) {
    console.log("[2] 로컬 캐시에서 발견! 바로 반환");
    return localCache;
  }

  console.log("[2] 로컬 캐시 없음 -> 리졸버에게 질의");
  console.log("[3] 리졸버 -> 루트 서버: 'com TLD 서버 어디?'");
  console.log("[4] 리졸버 -> com TLD: 'google.com NS 어디?'");
  console.log("[5] 리졸버 -> google.com NS: 'IP 주소 뭐야?'");
  console.log("[6] 응답: 142.250.196.110");
  console.log("[7] 결과 캐싱 (TTL: 300초)");

  return "142.250.196.110";
}

금요일 오후, 김개발 씨가 잠깐 쉬면서 유튜브에 접속합니다. 브라우저 주소창에 youtube.com을 입력하고 엔터를 누릅니다.

화면이 뜨기까지 불과 0.5초. 그 사이에 무슨 일이 일어났을까요?

박시니어 씨가 화이트보드에 그림을 그립니다. "DNS 질의 과정을 따라가 볼게요." 가장 먼저 일어나는 일은 로컬 캐시 확인입니다.

브라우저는 최근에 방문한 도메인의 IP를 기억하고 있습니다. 조금 전에 유튜브를 방문했다면 바로 그 IP로 접속합니다.

운영체제도 자체 DNS 캐시를 가지고 있습니다. 캐시에 없다면?

리졸버에게 물어봅니다. 리졸버는 보통 인터넷 서비스 제공자(ISP)가 운영하거나, 구글(8.8.8.8)이나 클라우드플레어(1.1.1.1) 같은 공개 DNS를 사용할 수 있습니다.

리졸버도 캐시에 없다면 반복적 질의를 시작합니다. 먼저 루트 서버에게 "youtube.com 아세요?"라고 묻습니다.

루트 서버는 "com은 192.12.94.30한테 물어봐"라고 답합니다. 리졸버는 com TLD 서버에게 다시 질의합니다.

TLD 서버는 "youtube.com은 ns1.google.com한테 물어봐"라고 알려줍니다. 마지막으로 구글의 네임 서버에게 질의하면, 드디어 "youtube.com은 142.250.207.46이야"라는 최종 답을 받습니다.

이 모든 과정이 보통 수십 밀리초 안에 끝납니다. 그리고 받은 결과는 TTL(Time To Live) 동안 캐싱됩니다.

TTL이 300초라면 5분 동안은 다시 물어볼 필요가 없습니다. 실무에서 이 과정을 이해하면 여러 상황에 대처할 수 있습니다.

DNS가 느리면 웹사이트 전체가 느려 보입니다. DNS 설정을 변경했는데 바로 반영되지 않는 것은 캐시 때문입니다.

주의할 점이 있습니다. TTL을 너무 짧게 설정하면 DNS 서버 부하가 커집니다.

너무 길게 설정하면 IP 변경 시 전파가 늦어집니다. 보통 300초에서 3600초 사이가 적당합니다.

김개발 씨가 크롬 개발자 도구를 열어봅니다. Network 탭에서 DNS Lookup 시간을 확인할 수 있습니다.

"오, 이게 그 시간이었군요!"

실전 팁

💡 - ipconfig /flushdns (Windows) 또는 sudo dscacheutil -flushcache (Mac)로 로컬 캐시를 비울 수 있습니다

구글 DNS(8.8.8.8)나 클라우드플레어 DNS(1.1.1.1)를 사용하면 더 빠른 경우가 많습니다

5. URI(Uniform Resource Identifier)

코드 리뷰 시간, 선배가 김개발 씨의 코드를 보며 물었습니다. "여기서 URL이라고 썼는데, 정확히는 URI가 맞아요.

차이점 알아요?" 김개발 씨는 순간 당황했습니다. 같은 거 아니었나요?

URI는 인터넷에서 자원을 식별하는 통합된 방식입니다. 마치 모든 물건에 고유한 바코드가 있는 것처럼, 인터넷의 모든 자원에는 URI가 있습니다.

URI는 URL과 URN을 포함하는 상위 개념으로, 자원의 위치뿐 아니라 이름으로도 식별할 수 있습니다.

다음 코드를 살펴봅시다.

// URI의 구조 분석
const uri = "https://user:pass@example.com:8080/path/to/resource?query=value#section";

const url = new URL(uri);
console.log("스킴(프로토콜):", url.protocol);  // https:
console.log("사용자 정보:", url.username);     // user
console.log("호스트:", url.hostname);          // example.com
console.log("포트:", url.port);                // 8080
console.log("경로:", url.pathname);            // /path/to/resource
console.log("쿼리 문자열:", url.search);       // ?query=value
console.log("프래그먼트:", url.hash);          // #section

// URI는 자원을 식별하는 모든 방식을 포함
const examples = {
  url: "https://example.com/page",           // 위치로 식별
  urn: "urn:isbn:978-89-6848-123-4",        // 이름으로 식별
  dataUri: "data:text/plain;base64,SGVsbG8=" // 데이터 자체 포함
};

김개발 씨는 API를 개발하면서 항상 URL이라는 용어를 사용했습니다. 그런데 RFC 문서를 읽다 보니 URI라는 단어가 더 자주 나옵니다.

둘이 뭐가 다른 걸까요? 박시니어 씨가 설명을 시작합니다.

"URI가 더 큰 개념이에요. 수학으로 치면 집합과 부분집합 관계예요." **URI(Uniform Resource Identifier)**는 무엇일까요?

쉽게 비유하자면, URI는 마치 사람을 식별하는 방법과 같습니다. 사람을 찾으려면 "서울시 강남구 어디에 사는 김철수"라고 주소로 찾을 수도 있고, "주민등록번호 123456-1234567"이라고 고유 번호로 찾을 수도 있습니다.

둘 다 한 사람을 식별하는 방법입니다. URI는 인터넷 자원을 식별하는 통합된 규격입니다.

여기서 자원이란 웹 페이지, 이미지, API 응답, 심지어 현실 세계의 책까지 포함합니다. URI의 일반적인 문법은 다음과 같습니다.

**스킴(Scheme)**이 맨 앞에 옵니다. https, ftp, mailto, tel 같은 것들입니다.

어떤 프로토콜을 사용할지 알려줍니다. 권한(Authority) 부분에는 사용자 정보, 호스트, 포트가 포함됩니다.

사용자 정보는 대부분 생략하지만, FTP 같은 곳에서 가끔 사용합니다. **경로(Path)**는 자원의 위치를 나타냅니다.

파일 시스템의 경로와 비슷합니다. **쿼리(Query)**는 물음표 뒤에 오는 키-값 쌍입니다.

서버에 추가 정보를 전달할 때 사용합니다. **프래그먼트(Fragment)**는 샵(#) 뒤에 오는 부분입니다.

문서 내의 특정 위치를 가리킵니다. 중요한 점은 프래그먼트는 서버로 전송되지 않는다는 것입니다.

브라우저에서만 사용됩니다. 실무에서 URI를 올바르게 다루는 것은 중요합니다.

특수 문자가 포함된 한글 검색어는 인코딩해야 합니다. JavaScript의 encodeURIComponent 함수를 사용하면 됩니다.

주의할 점이 있습니다. URI에서 슬래시(/), 물음표(?), 앰퍼샌드(&) 등은 특별한 의미가 있습니다.

값으로 사용하려면 반드시 인코딩해야 합니다. 김개발 씨가 이해했다는 듯 고개를 끄덕입니다.

"그래서 URL은 URI의 한 종류인 거군요!"

실전 팁

💡 - encodeURIComponent로 쿼리 파라미터 값을 인코딩하세요

프래그먼트(#)는 서버로 전송되지 않으므로 서버 사이드 처리에 사용하면 안 됩니다

6. URL과 URN 구분

김개발 씨가 URI를 이해하고 나니 또 궁금증이 생겼습니다. "그럼 URL이랑 URN은 정확히 뭐가 달라요?" 박시니어 씨가 답합니다.

"URL은 '어디에 있는지', URN은 '무엇인지'를 알려줘요. 주소와 이름의 차이예요."

URL은 자원의 위치를 알려주고, URN은 자원의 고유한 이름을 알려줍니다. 마치 "서울시 강남구 테헤란로 123"이 주소(URL)라면, "주민등록번호 123456-1234567"은 이름(URN)입니다.

URL은 위치가 바뀌면 무효화되지만, URN은 자원이 어디로 이동해도 변하지 않습니다.

다음 코드를 살펴봅시다.

// URL vs URN 비교
const examples = {
  // URL: 위치 기반 식별자 (Location)
  url: {
    web: "https://example.com/docs/guide.pdf",
    ftp: "ftp://files.example.com/downloads/app.zip",
    file: "file:///Users/kim/Documents/report.pdf"
  },

  // URN: 이름 기반 식별자 (Name)
  urn: {
    isbn: "urn:isbn:978-89-6848-123-4",      // 책의 ISBN
    uuid: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
    ietf: "urn:ietf:rfc:3986"                // RFC 문서 번호
  }
};

// URL은 위치가 바뀌면 깨짐
console.log("파일 이동 전:", "https://old.com/file.pdf"); // 작동
console.log("파일 이동 후:", "https://old.com/file.pdf"); // 404 에러!

// URN은 위치와 무관하게 같은 자원을 식별
console.log("어떤 서점이든:", "urn:isbn:978-89-6848-123-4"); // 같은 책

김개발 씨가 북마크해둔 기술 문서 링크를 클릭했습니다. 404 에러가 뜹니다.

사이트가 개편되면서 URL이 바뀐 것입니다. 북마크가 무용지물이 되어버렸습니다.

박시니어 씨가 말합니다. "URL의 한계예요.

위치가 바뀌면 소용없어지죠. URN은 그런 문제가 없어요." **URL(Uniform Resource Locator)**과 **URN(Uniform Resource Name)**의 차이를 알아봅시다.

쉽게 비유하자면, URL은 집 주소와 같습니다. "서울시 강남구 테헤란로 123번지"라고 하면 그 위치로 찾아갈 수 있습니다.

하지만 그 사람이 이사하면? 주소는 더 이상 유효하지 않습니다.

URN은 주민등록번호와 같습니다. 그 사람이 어디로 이사를 가든, 외국에 가서 살든, 주민번호는 변하지 않습니다.

언제나 같은 사람을 가리킵니다. URL의 구성 요소를 살펴보면, 스킴(프로토콜), 호스트, 경로 등이 있습니다.

https://example.com/path에서 https가 스킴, example.com이 호스트, /path가 경로입니다. URN은 조금 다릅니다.

urn:isbn:978-89-6848-123-4처럼 "urn:"으로 시작하고, 그 뒤에 네임스페이스와 고유 식별자가 옵니다. isbn은 책을 식별하는 네임스페이스이고, 뒤의 숫자가 특정 책을 가리킵니다.

현실에서 URN은 어떻게 사용될까요? 도서관 시스템에서 ISBN으로 책을 검색하면, 그 책이 어느 도서관 어느 선반에 있든 찾을 수 있습니다.

DOI(Digital Object Identifier)도 URN의 일종으로, 학술 논문을 영구적으로 식별합니다. 하지만 실무에서는 대부분 URL을 사용합니다.

왜냐하면 URL은 바로 접근이 가능하기 때문입니다. URN은 "이름"만 알려주고, 그 자원이 실제로 어디 있는지는 별도의 리졸버가 필요합니다.

웹 개발자라면 URL을 주로 다루게 됩니다. 하지만 URI, URL, URN의 관계를 이해하면 RFC 문서나 기술 스펙을 읽을 때 혼동하지 않습니다.

김개발 씨가 정리합니다. "URI는 전체 개념, URL은 위치로 식별, URN은 이름으로 식별.

이제 확실히 알겠어요!"

실전 팁

💡 - 일상적인 웹 개발에서는 URL을 주로 사용합니다. URL이라고 불러도 대부분 통합니다

DOI 링크(doi.org)는 URN을 URL로 변환해주는 리졸버 서비스입니다

7. 주요 DNS 레코드 타입(A, CNAME, MX 등)

김개발 씨가 DNS 설정 페이지를 열었습니다. A 레코드, CNAME, MX, TXT...

종류가 너무 많습니다. "이게 다 뭐예요?" 박시니어 씨가 옆에 앉습니다.

"하나씩 설명해줄게요. 실무에서 자주 쓰는 건 몇 개 안 돼요."

DNS 레코드는 도메인에 대한 다양한 정보를 저장합니다. A 레코드는 IPv4 주소, AAAA 레코드는 IPv6 주소를 매핑합니다.

CNAME은 도메인 별칭, MX는 메일 서버, TXT는 텍스트 정보를 담습니다. 각 레코드 타입은 고유한 목적이 있습니다.

다음 코드를 살펴봅시다.

// 주요 DNS 레코드 타입 설명
const dnsRecords = {
  // A 레코드: 도메인 -> IPv4 주소
  A: { domain: "example.com", value: "93.184.216.34" },

  // AAAA 레코드: 도메인 -> IPv6 주소
  AAAA: { domain: "example.com", value: "2606:2800:220:1:248:1893:25c8:1946" },

  // CNAME: 도메인 별칭 (다른 도메인을 가리킴)
  CNAME: { domain: "www.example.com", value: "example.com" },

  // MX: 메일 서버 (우선순위 포함)
  MX: { domain: "example.com", priority: 10, value: "mail.example.com" },

  // TXT: 텍스트 정보 (SPF, DKIM 등 인증에 사용)
  TXT: { domain: "example.com", value: "v=spf1 include:_spf.google.com ~all" },

  // NS: 네임서버 지정
  NS: { domain: "example.com", value: "ns1.example.com" }
};

// Node.js로 DNS 레코드 조회
const dns = require("dns");
dns.resolveMx("gmail.com", (err, addresses) => {
  console.log("Gmail MX 레코드:", addresses);
});

새 프로젝트를 배포하면서 김개발 씨는 DNS 설정을 직접 해보게 되었습니다. AWS Route 53 콘솔을 열었는데, 레코드 타입 선택하는 드롭다운에 종류가 엄청 많습니다.

박시니어 씨가 핵심만 짚어줍니다. "실무에서 자주 쓰는 건 5-6개예요.

나머지는 특수한 경우에만 써요." 가장 기본인 A 레코드부터 시작합니다. A는 Address의 약자로, 도메인을 IPv4 주소에 매핑합니다.

example.com을 93.184.216.34에 연결하고 싶다면 A 레코드를 만들면 됩니다. AAAA 레코드는 IPv6 버전입니다.

IPv6 주소는 훨씬 길어서 A가 네 개입니다. 요즘은 IPv6 지원이 늘어나고 있어서 함께 설정하는 경우가 많습니다.

CNAME 레코드는 별칭입니다. www.example.com을 example.com의 별칭으로 만들면, 둘 다 같은 곳을 가리키게 됩니다.

서버 IP가 바뀌어도 A 레코드 하나만 수정하면 됩니다. 주의할 점이 있습니다.

CNAME은 루트 도메인에 사용할 수 없습니다. example.com에는 A 레코드를 써야 하고, www.example.com에는 CNAME을 쓸 수 있습니다.

MX 레코드는 메일 서버를 지정합니다. 회사 도메인으로 이메일을 받으려면 MX 레코드가 필요합니다.

구글 워크스페이스나 네이버 웍스를 사용한다면 해당 서비스의 MX 레코드를 등록합니다. MX에는 우선순위 숫자가 붙습니다.

숫자가 낮을수록 우선입니다. 메인 메일 서버가 다운되면 백업 서버로 메일이 갑니다.

TXT 레코드는 텍스트 정보를 저장합니다. 가장 흔한 용도는 SPF, DKIM 같은 이메일 인증입니다.

또한 도메인 소유권 인증에도 사용됩니다. 구글 서치 콘솔이나 SSL 인증서 발급 시 TXT 레코드를 추가하라고 하는 경우가 많습니다.

NS 레코드는 네임서버를 지정합니다. 도메인 등록 업체에서 AWS Route 53으로 네임서버를 변경하려면 NS 레코드를 수정합니다.

실무에서 DNS 설정 실수는 서비스 장애로 직결됩니다. TTL을 낮추고 변경한 뒤, 정상 작동을 확인하고 다시 TTL을 올리는 것이 안전합니다.

김개발 씨가 A 레코드와 CNAME을 설정합니다. 몇 분 후 도메인으로 접속이 됩니다.

"생각보다 어렵지 않네요!"

실전 팁

💡 - DNS 변경 전 TTL을 낮춰두면 문제 발생 시 빠르게 롤백할 수 있습니다

dig나 nslookup으로 레코드가 제대로 설정되었는지 확인하세요
CNAME은 루트 도메인(@)에 사용할 수 없습니다. ALIAS나 ANAME을 지원하는 DNS 서비스를 사용하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Network#DNS#URI#URL#DomainName#NameServer#DNSRecord#Network,네트워크,웹

DNS와 URI 완벽 가이드

# DNS와 URI 완벽 가이드 인터넷에서 웹사이트를 찾아가는 원리를 이해하는 핵심 개념입니다. 도메인 네임이 어떻게 IP 주소로 변환되는지, URI와 URL의 차이는 무엇인지 초급 개발자도 쉽게 이해할 수 있도록 설명합니다. --- ## 목차 1. [도메인 네임(Domain Name) 이해](#도메인-네임(domain-name)-이해) 2. [네임 서버(Name Server)의 역할](#네임-서버(name-server)의-역할) 3. [계층적 네임 서버 구조](#계층적-네임-서버-구조) 4. [DNS 질의 과정](#dns-질의-과정) 5. [URI(Uniform Resource Identifier)](#uri(uniform-resource-identifier)) 6. [URL과 URN 구분](#url과-urn-구분) 7. [주요 DNS 레코드 타입(A, CNAME, MX 등)](#주요-dns-레코드-타입(a,-cname,-mx-등)) --- ## 1. 도메인 네임(Domain Name) 이해 김개발 씨는 오늘 처음으로 회사 웹사이트를 배포하게 되었습니다. 선배가 "도메인 연결해 놨어?"라고 물었는데, 순간 머릿속이 하얘졌습니다. IP 주소는 알겠는데, 도메인이 정확히 뭔지 설명하라고 하면 말문이 막히는 것 같았습니다. **도메인 네임**은 숫자로 된 IP 주소를 사람이 기억하기 쉬운 문자로 바꿔놓은 것입니다. 마치 전화번호부에서 친구 이름으로 전화번호를 찾는 것과 같습니다. 192.168.0.1 같은 숫자 대신 google.com처럼 직관적인 이름을 사용할 수 있게 해줍니다. 다음 코드를 살펴봅시다. ```javascript // 도메인 네임의 계층적 구조를 이해하는 예제 const domainName = "www.example.com"; // 도메인은 오른쪽에서 왼쪽으로 계층 구조를 가집니다 const parts = domainName.split("."); console.log("호스트명:", parts[0]); // www (서브도메인) console.log("2차 도메인:", parts[1]); // example (실제 도메인명) console.log("최상위 도메인:", parts[2]); // com (TLD) // 실제 서버에서 호스트 정보 확인 const url = new URL("https://www.example.com/path"); console.log("전체 호스트:", url.hostname); // www.example.com console.log("프로토콜:", url.protocol); // https: ``` 김개발 씨는 입사 후 처음으로 실서버 배포를 맡게 되었습니다. AWS에서 EC2 인스턴스를 띄우고 나니 54.180.123.45 같은 IP 주소가 할당되었습니다. 그런데 이 숫자를 고객에게 알려줄 수는 없는 노릇입니다. 선배 개발자 박시니어 씨가 설명을 시작합니다. "도메인 네임이라는 게 있어요. 전화번호부 생각하면 쉬워요." 그렇다면 **도메인 네임**이란 정확히 무엇일까요? 쉽게 비유하자면, 도메인 네임은 마치 건물의 간판과 같습니다. 실제 건물 위치는 위도와 경도로 표현되지만, 우리는 "강남역 2번 출구 스타벅스"라고 말합니다. 이처럼 도메인 네임도 복잡한 숫자 주소를 친숙한 이름으로 바꿔주는 역할을 합니다. 인터넷 초창기에는 어땠을까요? 사람들은 접속하고 싶은 서버의 IP 주소를 직접 외워야 했습니다. 서버가 10개만 되어도 머리가 아팠습니다. 더 큰 문제는 서버 IP가 바뀌면 모든 사용자에게 새 주소를 알려야 한다는 것이었습니다. 바로 이런 문제를 해결하기 위해 **도메인 네임 시스템**이 등장했습니다. 이제 사용자는 google.com만 기억하면 됩니다. 구글 서버의 IP가 바뀌더라도 사용자는 전혀 신경 쓸 필요가 없습니다. 도메인 네임은 **계층적 구조**를 가집니다. www.naver.com을 예로 들면, 맨 오른쪽 com은 **최상위 도메인(TLD)**입니다. 그 왼쪽 naver는 **2차 도메인**으로 실제 소유자를 나타냅니다. 맨 왼쪽 www는 **서브도메인** 또는 호스트명입니다. 최상위 도메인에는 여러 종류가 있습니다. com은 상업용, org는 비영리 단체, kr은 대한민국을 나타냅니다. 이런 구조 덕분에 전 세계 수억 개의 도메인이 체계적으로 관리됩니다. 실무에서는 어떻게 활용할까요? 회사에서 새 서비스를 런칭할 때 먼저 도메인을 구매합니다. 가비아, AWS Route 53 같은 도메인 등록 대행업체에서 원하는 이름이 사용 가능한지 확인하고 등록합니다. 주의할 점도 있습니다. 도메인은 선착순입니다. 좋은 이름은 이미 누군가 가져갔을 가능성이 높습니다. 또한 도메인은 매년 갱신해야 하며, 깜빡하면 다른 사람에게 넘어갈 수 있습니다. 다시 김개발 씨 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 이해가 되기 시작했습니다. "아, 그래서 도메인을 따로 구매하는 거군요!" **실전 팁** 💡 - 도메인은 브랜드 자산입니다. 서비스 기획 단계에서 미리 확보하세요 - 도메인 만료일을 캘린더에 등록해두면 갱신을 놓치지 않습니다 --- ## 2. 네임 서버(Name Server)의 역할 김개발 씨가 도메인을 구매하고 나니 다음 단계가 궁금해졌습니다. "도메인이랑 서버 IP를 어떻게 연결하는 거예요?" 박시니어 씨가 답합니다. "네임 서버를 설정해야 해요. 도메인의 안내 데스크 같은 거예요." **네임 서버**는 도메인 네임과 IP 주소의 매핑 정보를 저장하고 있는 서버입니다. 마치 114 안내에 전화하면 원하는 번호를 알려주는 것처럼, 네임 서버에 도메인을 물어보면 해당 IP 주소를 알려줍니다. 인터넷의 전화번호부 역할을 수행합니다. 다음 코드를 살펴봅시다. ```javascript // Node.js에서 DNS 조회하기 const dns = require("dns"); // 도메인의 IP 주소 조회 (A 레코드) dns.resolve4("google.com", (err, addresses) => { if (err) throw err; console.log("IP 주소들:", addresses); // 출력: IP 주소들: ['142.250.196.110', ...] }); // 네임 서버(NS) 레코드 조회 dns.resolveNs("google.com", (err, nameservers) => { if (err) throw err; console.log("네임 서버:", nameservers); // 출력: 네임 서버: ['ns1.google.com', 'ns2.google.com', ...] }); ``` 김개발 씨는 도메인 구매까지는 성공했습니다. 그런데 구매한 도메인으로 접속하면 여전히 아무것도 나오지 않습니다. 뭔가 빠진 게 있는 것 같습니다. 박시니어 씨가 화면을 가리킵니다. "여기 네임 서버 설정하는 곳 보여요? 이걸 설정해야 도메인이 작동해요." **네임 서버**란 무엇일까요? 쉽게 비유하자면, 네임 서버는 마치 도서관 사서와 같습니다. 도서관에 가서 "파이썬 입문서 어디 있어요?"라고 물으면, 사서가 "3층 프로그래밍 섹션 A-15번 선반에 있습니다"라고 안내해줍니다. 네임 서버도 "google.com 어디야?"라고 물으면 "142.250.196.110이야"라고 알려줍니다. 네임 서버가 없던 시절에는 어땠을까요? 초기 인터넷에서는 hosts 파일이라는 것을 사용했습니다. 모든 컴퓨터가 도메인-IP 매핑 목록을 각자 가지고 있어야 했습니다. 새 서버가 추가되면 전 세계 모든 컴퓨터의 hosts 파일을 업데이트해야 했습니다. 상상만 해도 끔찍한 일입니다. 이 문제를 해결하기 위해 **분산 데이터베이스** 형태의 네임 서버 시스템이 만들어졌습니다. 중앙에서 모든 정보를 관리하는 대신, 각 도메인의 소유자가 자신의 네임 서버를 운영합니다. 네임 서버에는 여러 종류가 있습니다. 가장 먼저 만나는 것이 **리졸버(Resolver)**입니다. 통신사나 구글(8.8.8.8)이 제공하는 서버로, 사용자의 DNS 질의를 대신 처리해줍니다. 그 다음은 **권한 있는 네임 서버(Authoritative Name Server)**입니다. 특정 도메인에 대한 공식 정보를 가진 서버입니다. 예를 들어 google.com의 권한 있는 네임 서버는 구글이 직접 운영합니다. 실무에서 도메인을 구매하면 등록 대행업체에서 기본 네임 서버를 제공합니다. 하지만 AWS나 클라우드플레어 같은 서비스를 사용한다면 해당 서비스의 네임 서버로 변경하는 경우가 많습니다. 주의할 점이 있습니다. 네임 서버를 변경하면 전파되는 데 최대 48시간이 걸릴 수 있습니다. 중요한 서비스라면 미리 변경하고 충분히 기다려야 합니다. 김개발 씨는 AWS Route 53의 네임 서버 주소를 도메인 등록 업체에 입력했습니다. 몇 시간 후, 드디어 도메인으로 접속이 되기 시작했습니다. "와, 진짜 되네요!" **실전 팁** 💡 - 네임 서버 변경 후 전파 시간을 고려해 여유있게 작업하세요 - nslookup이나 dig 명령어로 DNS 설정을 확인할 수 있습니다 --- ## 3. 계층적 네임 서버 구조 김개발 씨가 궁금증이 생겼습니다. "전 세계 도메인이 수억 개인데, 네임 서버 하나로 어떻게 다 처리해요?" 박시니어 씨가 웃으며 답합니다. "하나가 아니에요. 계층 구조로 나뉘어 있어요. 마치 행정 구역처럼요." DNS는 **루트 서버**, **TLD 서버**, **권한 있는 서버**로 이어지는 계층 구조를 가집니다. 마치 대통령 - 도지사 - 시장 - 동장으로 이어지는 행정 체계처럼, 각 단계가 자신의 관할 영역을 담당합니다. 이런 분산 구조 덕분에 수십억 개의 도메인을 효율적으로 관리할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // DNS 계층 구조 시뮬레이션 const dnsHierarchy = { // 루트 서버 (전 세계 13개) root: { role: "최상위 관리자", manages: ["com", "org", "net", "kr", "jp", "..."] }, // TLD 서버 (최상위 도메인 관리) tld: { "com": { manages: ["google", "naver", "amazon", "..."] }, "kr": { manages: ["co.kr", "or.kr", "go.kr", "..."] } }, // 권한 있는 네임 서버 (개별 도메인 관리) authoritative: { "google.com": { ip: "142.250.196.110", ns: "ns1.google.com" } } }; // 도메인 질의 경로: . -> com -> google.com console.log("www.google.com 질의 경로:"); console.log("1. 루트 서버에게 'com' TLD 서버 위치 질의"); console.log("2. com TLD 서버에게 'google.com' 네임서버 질의"); console.log("3. google.com 네임서버에게 IP 주소 질의"); ``` 김개발 씨는 점심 시간에 문득 의문이 들었습니다. 매일 수십억 건의 DNS 질의가 발생할 텐데, 서버 하나로 어떻게 처리할 수 있을까요? 박시니어 씨가 냅킨에 그림을 그리며 설명합니다. "DNS는 피라미드처럼 생겼어요." **DNS 계층 구조**는 크게 세 단계로 나뉩니다. 맨 꼭대기에는 **루트 네임 서버**가 있습니다. 전 세계에 단 13개뿐입니다. A부터 M까지 알파벳으로 이름이 붙어 있습니다. 하지만 실제로는 애니캐스트 기술로 수백 대의 서버가 분산 운영됩니다. 루트 서버는 모든 도메인 정보를 알고 있을까요? 아닙니다. 루트 서버는 오직 **TLD 서버의 위치**만 알고 있습니다. "com은 저쪽에 물어봐", "kr은 저기로 가봐"라고 안내만 해줍니다. 두 번째 단계는 **TLD(Top-Level Domain) 서버**입니다. com, org, net 같은 일반 TLD와 kr, jp, uk 같은 국가 코드 TLD를 각각 다른 서버가 관리합니다. com TLD 서버는 google.com, naver.com 등 com으로 끝나는 도메인의 네임 서버 위치를 알고 있습니다. 세 번째는 **권한 있는 네임 서버**입니다. 실제 도메인 소유자가 운영하는 서버입니다. 여기서 비로소 "google.com의 IP는 142.250.196.110이야"라는 최종 답을 얻습니다. 왜 이렇게 복잡하게 만들었을까요? 한 서버가 모든 도메인을 관리하면 **단일 장애점**이 됩니다. 그 서버가 다운되면 전 세계 인터넷이 마비됩니다. 계층 구조로 분산하면 한 서버에 문제가 생겨도 영향이 제한됩니다. 또한 **확장성** 문제도 있습니다. 새 도메인이 등록될 때마다 루트 서버를 업데이트할 필요가 없습니다. google.com이 새 서브도메인을 추가해도 구글의 네임 서버만 수정하면 됩니다. 실무에서 이 구조를 이해하면 DNS 문제 해결이 쉬워집니다. dig 명령어에 +trace 옵션을 붙이면 실제로 질의가 어떤 경로로 진행되는지 볼 수 있습니다. 김개발 씨가 터미널에서 직접 실행해봅니다. "오, 진짜 루트에서 시작해서 단계별로 내려가네요!" **실전 팁** 💡 - dig +trace google.com 명령어로 DNS 질의 경로를 추적해보세요 - 루트 서버 목록은 root-servers.org에서 확인할 수 있습니다 --- ## 4. DNS 질의 과정 김개발 씨가 브라우저에 google.com을 입력했습니다. 엔터를 누르는 순간부터 화면이 뜨기까지, 보이지 않는 곳에서 어떤 일이 벌어질까요? 박시니어 씨가 말합니다. "그 짧은 순간에 꽤 많은 일이 일어나요." DNS 질의는 **재귀적 질의**와 **반복적 질의** 두 가지 방식으로 진행됩니다. 사용자의 컴퓨터가 리졸버에게 물어보면, 리졸버가 대신 여러 서버를 돌아다니며 답을 찾아옵니다. 한번 찾은 결과는 **캐싱**되어 다음에 더 빠르게 응답할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // DNS 질의 과정 시뮬레이션 async function simulateDnsQuery(domain) { console.log(`[1] 브라우저: ${domain} 접속 시도`); // 로컬 캐시 확인 const localCache = checkLocalCache(domain); if (localCache) { console.log("[2] 로컬 캐시에서 발견! 바로 반환"); return localCache; } console.log("[2] 로컬 캐시 없음 -> 리졸버에게 질의"); console.log("[3] 리졸버 -> 루트 서버: 'com TLD 서버 어디?'"); console.log("[4] 리졸버 -> com TLD: 'google.com NS 어디?'"); console.log("[5] 리졸버 -> google.com NS: 'IP 주소 뭐야?'"); console.log("[6] 응답: 142.250.196.110"); console.log("[7] 결과 캐싱 (TTL: 300초)"); return "142.250.196.110"; } ``` 금요일 오후, 김개발 씨가 잠깐 쉬면서 유튜브에 접속합니다. 브라우저 주소창에 youtube.com을 입력하고 엔터를 누릅니다. 화면이 뜨기까지 불과 0.5초. 그 사이에 무슨 일이 일어났을까요? 박시니어 씨가 화이트보드에 그림을 그립니다. "DNS 질의 과정을 따라가 볼게요." 가장 먼저 일어나는 일은 **로컬 캐시 확인**입니다. 브라우저는 최근에 방문한 도메인의 IP를 기억하고 있습니다. 조금 전에 유튜브를 방문했다면 바로 그 IP로 접속합니다. 운영체제도 자체 DNS 캐시를 가지고 있습니다. 캐시에 없다면? **리졸버**에게 물어봅니다. 리졸버는 보통 인터넷 서비스 제공자(ISP)가 운영하거나, 구글(8.8.8.8)이나 클라우드플레어(1.1.1.1) 같은 공개 DNS를 사용할 수 있습니다. 리졸버도 캐시에 없다면 **반복적 질의**를 시작합니다. 먼저 루트 서버에게 "youtube.com 아세요?"라고 묻습니다. 루트 서버는 "com은 192.12.94.30한테 물어봐"라고 답합니다. 리졸버는 com TLD 서버에게 다시 질의합니다. TLD 서버는 "youtube.com은 ns1.google.com한테 물어봐"라고 알려줍니다. 마지막으로 구글의 네임 서버에게 질의하면, 드디어 "youtube.com은 142.250.207.46이야"라는 최종 답을 받습니다. 이 모든 과정이 보통 **수십 밀리초** 안에 끝납니다. 그리고 받은 결과는 **TTL(Time To Live)** 동안 캐싱됩니다. TTL이 300초라면 5분 동안은 다시 물어볼 필요가 없습니다. 실무에서 이 과정을 이해하면 여러 상황에 대처할 수 있습니다. DNS가 느리면 웹사이트 전체가 느려 보입니다. DNS 설정을 변경했는데 바로 반영되지 않는 것은 캐시 때문입니다. 주의할 점이 있습니다. TTL을 너무 짧게 설정하면 DNS 서버 부하가 커집니다. 너무 길게 설정하면 IP 변경 시 전파가 늦어집니다. 보통 300초에서 3600초 사이가 적당합니다. 김개발 씨가 크롬 개발자 도구를 열어봅니다. Network 탭에서 DNS Lookup 시간을 확인할 수 있습니다. "오, 이게 그 시간이었군요!" **실전 팁** 💡 - ipconfig /flushdns (Windows) 또는 sudo dscacheutil -flushcache (Mac)로 로컬 캐시를 비울 수 있습니다 - 구글 DNS(8.8.8.8)나 클라우드플레어 DNS(1.1.1.1)를 사용하면 더 빠른 경우가 많습니다 --- ## 5. URI(Uniform Resource Identifier) 코드 리뷰 시간, 선배가 김개발 씨의 코드를 보며 물었습니다. "여기서 URL이라고 썼는데, 정확히는 URI가 맞아요. 차이점 알아요?" 김개발 씨는 순간 당황했습니다. 같은 거 아니었나요? **URI**는 인터넷에서 자원을 식별하는 통합된 방식입니다. 마치 모든 물건에 고유한 바코드가 있는 것처럼, 인터넷의 모든 자원에는 URI가 있습니다. URI는 URL과 URN을 포함하는 상위 개념으로, 자원의 위치뿐 아니라 이름으로도 식별할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // URI의 구조 분석 const uri = "https://user:pass@example.com:8080/path/to/resource?query=value#section"; const url = new URL(uri); console.log("스킴(프로토콜):", url.protocol); // https: console.log("사용자 정보:", url.username); // user console.log("호스트:", url.hostname); // example.com console.log("포트:", url.port); // 8080 console.log("경로:", url.pathname); // /path/to/resource console.log("쿼리 문자열:", url.search); // ?query=value console.log("프래그먼트:", url.hash); // #section // URI는 자원을 식별하는 모든 방식을 포함 const examples = { url: "https://example.com/page", // 위치로 식별 urn: "urn:isbn:978-89-6848-123-4", // 이름으로 식별 dataUri: "data:text/plain;base64,SGVsbG8=" // 데이터 자체 포함 }; ``` 김개발 씨는 API를 개발하면서 항상 URL이라는 용어를 사용했습니다. 그런데 RFC 문서를 읽다 보니 URI라는 단어가 더 자주 나옵니다. 둘이 뭐가 다른 걸까요? 박시니어 씨가 설명을 시작합니다. "URI가 더 큰 개념이에요. 수학으로 치면 집합과 부분집합 관계예요." **URI(Uniform Resource Identifier)**는 무엇일까요? 쉽게 비유하자면, URI는 마치 사람을 식별하는 방법과 같습니다. 사람을 찾으려면 "서울시 강남구 어디에 사는 김철수"라고 주소로 찾을 수도 있고, "주민등록번호 123456-1234567"이라고 고유 번호로 찾을 수도 있습니다. 둘 다 한 사람을 **식별**하는 방법입니다. URI는 인터넷 자원을 식별하는 **통합된 규격**입니다. 여기서 자원이란 웹 페이지, 이미지, API 응답, 심지어 현실 세계의 책까지 포함합니다. URI의 일반적인 문법은 다음과 같습니다. **스킴(Scheme)**이 맨 앞에 옵니다. https, ftp, mailto, tel 같은 것들입니다. 어떤 프로토콜을 사용할지 알려줍니다. **권한(Authority)** 부분에는 사용자 정보, 호스트, 포트가 포함됩니다. 사용자 정보는 대부분 생략하지만, FTP 같은 곳에서 가끔 사용합니다. **경로(Path)**는 자원의 위치를 나타냅니다. 파일 시스템의 경로와 비슷합니다. **쿼리(Query)**는 물음표 뒤에 오는 키-값 쌍입니다. 서버에 추가 정보를 전달할 때 사용합니다. **프래그먼트(Fragment)**는 샵(#) 뒤에 오는 부분입니다. 문서 내의 특정 위치를 가리킵니다. 중요한 점은 프래그먼트는 서버로 전송되지 않는다는 것입니다. 브라우저에서만 사용됩니다. 실무에서 URI를 올바르게 다루는 것은 중요합니다. 특수 문자가 포함된 한글 검색어는 **인코딩**해야 합니다. JavaScript의 encodeURIComponent 함수를 사용하면 됩니다. 주의할 점이 있습니다. URI에서 슬래시(/), 물음표(?), 앰퍼샌드(&) 등은 특별한 의미가 있습니다. 값으로 사용하려면 반드시 인코딩해야 합니다. 김개발 씨가 이해했다는 듯 고개를 끄덕입니다. "그래서 URL은 URI의 한 종류인 거군요!" **실전 팁** 💡 - encodeURIComponent로 쿼리 파라미터 값을 인코딩하세요 - 프래그먼트(#)는 서버로 전송되지 않으므로 서버 사이드 처리에 사용하면 안 됩니다 --- ## 6. URL과 URN 구분 김개발 씨가 URI를 이해하고 나니 또 궁금증이 생겼습니다. "그럼 URL이랑 URN은 정확히 뭐가 달라요?" 박시니어 씨가 답합니다. "URL은 '어디에 있는지', URN은 '무엇인지'를 알려줘요. 주소와 이름의 차이예요." **URL**은 자원의 위치를 알려주고, **URN**은 자원의 고유한 이름을 알려줍니다. 마치 "서울시 강남구 테헤란로 123"이 주소(URL)라면, "주민등록번호 123456-1234567"은 이름(URN)입니다. URL은 위치가 바뀌면 무효화되지만, URN은 자원이 어디로 이동해도 변하지 않습니다. 다음 코드를 살펴봅시다. ```javascript // URL vs URN 비교 const examples = { // URL: 위치 기반 식별자 (Location) url: { web: "https://example.com/docs/guide.pdf", ftp: "ftp://files.example.com/downloads/app.zip", file: "file:///Users/kim/Documents/report.pdf" }, // URN: 이름 기반 식별자 (Name) urn: { isbn: "urn:isbn:978-89-6848-123-4", // 책의 ISBN uuid: "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", ietf: "urn:ietf:rfc:3986" // RFC 문서 번호 } }; // URL은 위치가 바뀌면 깨짐 console.log("파일 이동 전:", "https://old.com/file.pdf"); // 작동 console.log("파일 이동 후:", "https://old.com/file.pdf"); // 404 에러! // URN은 위치와 무관하게 같은 자원을 식별 console.log("어떤 서점이든:", "urn:isbn:978-89-6848-123-4"); // 같은 책 ``` 김개발 씨가 북마크해둔 기술 문서 링크를 클릭했습니다. 404 에러가 뜹니다. 사이트가 개편되면서 URL이 바뀐 것입니다. 북마크가 무용지물이 되어버렸습니다. 박시니어 씨가 말합니다. "URL의 한계예요. 위치가 바뀌면 소용없어지죠. URN은 그런 문제가 없어요." **URL(Uniform Resource Locator)**과 **URN(Uniform Resource Name)**의 차이를 알아봅시다. 쉽게 비유하자면, URL은 집 주소와 같습니다. "서울시 강남구 테헤란로 123번지"라고 하면 그 위치로 찾아갈 수 있습니다. 하지만 그 사람이 이사하면? 주소는 더 이상 유효하지 않습니다. URN은 주민등록번호와 같습니다. 그 사람이 어디로 이사를 가든, 외국에 가서 살든, 주민번호는 변하지 않습니다. 언제나 같은 사람을 가리킵니다. URL의 구성 요소를 살펴보면, **스킴**(프로토콜), **호스트**, **경로** 등이 있습니다. https://example.com/path에서 https가 스킴, example.com이 호스트, /path가 경로입니다. URN은 조금 다릅니다. urn:isbn:978-89-6848-123-4처럼 "urn:"으로 시작하고, 그 뒤에 **네임스페이스**와 **고유 식별자**가 옵니다. isbn은 책을 식별하는 네임스페이스이고, 뒤의 숫자가 특정 책을 가리킵니다. 현실에서 URN은 어떻게 사용될까요? 도서관 시스템에서 ISBN으로 책을 검색하면, 그 책이 어느 도서관 어느 선반에 있든 찾을 수 있습니다. DOI(Digital Object Identifier)도 URN의 일종으로, 학술 논문을 영구적으로 식별합니다. 하지만 실무에서는 대부분 URL을 사용합니다. 왜냐하면 URL은 바로 접근이 가능하기 때문입니다. URN은 "이름"만 알려주고, 그 자원이 실제로 어디 있는지는 별도의 **리졸버**가 필요합니다. 웹 개발자라면 URL을 주로 다루게 됩니다. 하지만 URI, URL, URN의 관계를 이해하면 RFC 문서나 기술 스펙을 읽을 때 혼동하지 않습니다. 김개발 씨가 정리합니다. "URI는 전체 개념, URL은 위치로 식별, URN은 이름으로 식별. 이제 확실히 알겠어요!" **실전 팁** 💡 - 일상적인 웹 개발에서는 URL을 주로 사용합니다. URL이라고 불러도 대부분 통합니다 - DOI 링크(doi.org)는 URN을 URL로 변환해주는 리졸버 서비스입니다 --- ## 7. 주요 DNS 레코드 타입(A, CNAME, MX 등) 김개발 씨가 DNS 설정 페이지를 열었습니다. A 레코드, CNAME, MX, TXT... 종류가 너무 많습니다. "이게 다 뭐예요?" 박시니어 씨가 옆에 앉습니다. "하나씩 설명해줄게요. 실무에서 자주 쓰는 건 몇 개 안 돼요." DNS 레코드는 도메인에 대한 다양한 정보를 저장합니다. **A 레코드**는 IPv4 주소, **AAAA 레코드**는 IPv6 주소를 매핑합니다. **CNAME**은 도메인 별칭, **MX**는 메일 서버, **TXT**는 텍스트 정보를 담습니다. 각 레코드 타입은 고유한 목적이 있습니다. 다음 코드를 살펴봅시다. ```javascript // 주요 DNS 레코드 타입 설명 const dnsRecords = { // A 레코드: 도메인 -> IPv4 주소 A: { domain: "example.com", value: "93.184.216.34" }, // AAAA 레코드: 도메인 -> IPv6 주소 AAAA: { domain: "example.com", value: "2606:2800:220:1:248:1893:25c8:1946" }, // CNAME: 도메인 별칭 (다른 도메인을 가리킴) CNAME: { domain: "www.example.com", value: "example.com" }, // MX: 메일 서버 (우선순위 포함) MX: { domain: "example.com", priority: 10, value: "mail.example.com" }, // TXT: 텍스트 정보 (SPF, DKIM 등 인증에 사용) TXT: { domain: "example.com", value: "v=spf1 include:_spf.google.com ~all" }, // NS: 네임서버 지정 NS: { domain: "example.com", value: "ns1.example.com" } }; // Node.js로 DNS 레코드 조회 const dns = require("dns"); dns.resolveMx("gmail.com", (err, addresses) => { console.log("Gmail MX 레코드:", addresses); }); ``` 새 프로젝트를 배포하면서 김개발 씨는 DNS 설정을 직접 해보게 되었습니다. AWS Route 53 콘솔을 열었는데, 레코드 타입 선택하는 드롭다운에 종류가 엄청 많습니다. 박시니어 씨가 핵심만 짚어줍니다. "실무에서 자주 쓰는 건 5-6개예요. 나머지는 특수한 경우에만 써요." 가장 기본인 **A 레코드**부터 시작합니다. A는 Address의 약자로, 도메인을 IPv4 주소에 매핑합니다. example.com을 93.184.216.34에 연결하고 싶다면 A 레코드를 만들면 됩니다. **AAAA 레코드**는 IPv6 버전입니다. IPv6 주소는 훨씬 길어서 A가 네 개입니다. 요즘은 IPv6 지원이 늘어나고 있어서 함께 설정하는 경우가 많습니다. **CNAME 레코드**는 별칭입니다. www.example.com을 example.com의 별칭으로 만들면, 둘 다 같은 곳을 가리키게 됩니다. 서버 IP가 바뀌어도 A 레코드 하나만 수정하면 됩니다. 주의할 점이 있습니다. CNAME은 **루트 도메인에 사용할 수 없습니다**. example.com에는 A 레코드를 써야 하고, www.example.com에는 CNAME을 쓸 수 있습니다. **MX 레코드**는 메일 서버를 지정합니다. 회사 도메인으로 이메일을 받으려면 MX 레코드가 필요합니다. 구글 워크스페이스나 네이버 웍스를 사용한다면 해당 서비스의 MX 레코드를 등록합니다. MX에는 **우선순위** 숫자가 붙습니다. 숫자가 낮을수록 우선입니다. 메인 메일 서버가 다운되면 백업 서버로 메일이 갑니다. **TXT 레코드**는 텍스트 정보를 저장합니다. 가장 흔한 용도는 **SPF**, **DKIM** 같은 이메일 인증입니다. 또한 도메인 소유권 인증에도 사용됩니다. 구글 서치 콘솔이나 SSL 인증서 발급 시 TXT 레코드를 추가하라고 하는 경우가 많습니다. **NS 레코드**는 네임서버를 지정합니다. 도메인 등록 업체에서 AWS Route 53으로 네임서버를 변경하려면 NS 레코드를 수정합니다. 실무에서 DNS 설정 실수는 서비스 장애로 직결됩니다. TTL을 낮추고 변경한 뒤, 정상 작동을 확인하고 다시 TTL을 올리는 것이 안전합니다. 김개발 씨가 A 레코드와 CNAME을 설정합니다. 몇 분 후 도메인으로 접속이 됩니다. "생각보다 어렵지 않네요!" **실전 팁** 💡 - DNS 변경 전 TTL을 낮춰두면 문제 발생 시 빠르게 롤백할 수 있습니다 - dig나 nslookup으로 레코드가 제대로 설정되었는지 확인하세요 - CNAME은 루트 도메인(@)에 사용할 수 없습니다. ALIAS나 ANAME을 지원하는 DNS 서비스를 사용하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: Network,네트워크,웹

언어: JavaScript

태그: Network, DNS, URI, URL, DomainName, NameServer, DNSRecord, Network,네트워크,웹

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

DNS와 URI 완벽 가이드

목차

1. 도메인 네임(Domain Name) 이해

2. 네임 서버(Name Server)의 역할

3. 계층적 네임 서버 구조

4. DNS 질의 과정

5. URI(Uniform Resource Identifier)

6. URL과 URN 구분

7. 주요 DNS 레코드 타입(A, CNAME, MX 등)

이 카드뉴스가 포함된 코스

컴퓨터 네트워크 완전 정복

댓글 (0)

함께 보면 좋은 카드 뉴스

서비스 메시 완벽 가이드

EFK 스택 로깅 완벽 가이드

Grafana 대시보드 완벽 가이드

분산 추적 완벽 가이드

CloudFront CDN 완벽 가이드