A 레코드: 이름을 IPv4 주소로 매핑하기

당신이 클릭하는 모든 링크, 로드되는 모든 이미지, 앱이 만드는 모든 API 호출—이 모두는 하나의 질문으로 시작됩니다: "이 이름에 해당하는 숫자가 뭐지?"

A 레코드가 바로 그 질문에 답합니다. connected.app 같은 도메인 이름을 192.0.2.10 같은 IPv4 주소로 매핑합니다. "A"는 Address(주소)를 의미하며, 이 레코드 덕분에 숫자를 외우는 대신 브라우저에 단어를 입력할 수 있습니다.

사람은 의미로 생각합니다. 기계는 숫자로 생각합니다. A 레코드는 이 두 가지 방식 사이를 잇는 번역 계층입니다.

A 레코드의 작동 방식

브라우저에 도메인을 입력하면, 기기가 DNS 서버에 묻습니다: "이 이름의 IP 주소가 뭔가요?" DNS 서버는 A 레코드를 조회하고 IPv4 주소로 응답합니다. 브라우저는 그 주소에 연결합니다. 이 과정은 밀리초 단위로, 눈에 보이지 않게, 하루에도 수천 번 일어납니다.

A 레코드는 이렇게 생겼습니다:

example.com.    3600    IN    A    192.0.2.10

구성 요소를 살펴보면:

• 이름: 도메인 또는 서브도메인 (example.com 또는 www.example.com)
• TTL: Time To Live, 초 단위—리졸버가 이 응답을 캐시할 수 있는 시간
• 클래스: 인터넷을 의미하는 IN (실제로 접하게 되는 유일한 클래스)
• 타입: 주소 레코드를 의미하는 A
• 값: 점으로 구분된 십진수 표기법의 IPv4 주소

TTL 설정의 균형

TTL은 안정성에 대한 판단입니다. 높은 TTL은 "이건 바뀌지 않아—캐시해도 돼"라는 의미입니다. 낮은 TTL은 "이건 바뀔 수도 있어—자주 확인해"라는 의미입니다.

짧은 TTL (60~300초): 변화가 잦은 인프라에 적합합니다. 마이그레이션, 테스트, 또는 빠르게 변경해야 할 수 있는 모든 것에 사용합니다. DNS 쿼리가 더 많아지지만, 변경 사항이 몇 분 안에 전파됩니다.

중간 TTL (1~2시간): 프로덕션의 표준입니다. 성능과 적절한 업데이트 속도 사이의 균형을 잡습니다.

긴 TTL (24시간 이상): 거의 변경되지 않는 인프라에 적합합니다. 캐싱이 최대화되지만, 변경 사항이 전 세계에 전파되는 데 하루가 걸립니다.

마이그레이션 패턴: 계획된 IP 변경 24~48시간 전에 TTL을 낮추세요. 변경을 수행하세요. 전파가 완료되면 TTL을 다시 높이세요. 이렇게 하면 일부 사용자는 이전 주소에, 나머지는 새 주소에 접속하는 시간 간격을 최소화할 수 있습니다.

일반적인 구성

일반적인 도메인은 여러 A 레코드를 가지며 서로 다른 서브도메인을 서로 다른 서버로 연결합니다:

example.com.        3600    IN    A    192.0.2.10
www.example.com.    3600    IN    A    192.0.2.10
mail.example.com.   3600    IN    A    192.0.2.20
api.example.com.    3600    IN    A    192.0.2.30

루트 도메인과 www는 보통 같은 주소를 가리킵니다—사용자는 두 가지 모두 작동하기를 기대하니까요. 다른 서브도메인들은 전문화된 서버를 가리킵니다: 메일 핸들러, API 엔드포인트, 스테이징 환경. 이것이 하나의 도메인이 여러 서비스가 되는 방식입니다.

라운드 로빈 DNS

하나의 이름에 여러 A 레코드를 둘 수 있습니다:

example.com.    3600    IN    A    192.0.2.10
example.com.    3600    IN    A    192.0.2.11
example.com.    3600    IN    A    192.0.2.12

DNS 서버는 모든 주소를 반환하지만 쿼리마다 순서를 바꿉니다. 첫 번째 쿼리는 192.0.2.10이 먼저, 다음 쿼리는 192.0.2.11이 먼저 옵니다. 트래픽이 서버들에 자동으로 분산됩니다.

하지만 DNS는 stateless입니다. 서버가 정상인지 알지 못합니다. 알 수도 없습니다—DNS는 전화번호부이지 의사가 아닙니다. 라운드 로빈은 레코드를 제거하기 전까지 다운된 서버로 트래픽을 계속 보냅니다. 이건 결함이 아닙니다. DNS는 이름을 숫자로 매핑하도록 설계되었지, 인프라를 모니터링하도록 설계된 것이 아닙니다. 고가용성이 필요한 프로덕션 시스템은 실제로 서버 상태를 확인하는 전용 로드 밸런서를 사용합니다.

A 레코드 vs. AAAA 레코드

A 레코드는 이름을 IPv4 주소(32비트, 192.0.2.10 형식)로 매핑합니다. AAAA 레코드는 이름을 IPv6 주소(128비트, 2001:db8::1 형식)로 매핑합니다. 대부분의 도메인은 두 가지를 모두 설정하여 어느 프로토콜로도 연결할 수 있게 합니다. AAAA의 A가 네 개인 것은 IPv6 주소가 IPv4보다 네 배 길다는 것을 반영합니다.

A 레코드가 할 수 없는 것

A 레코드는 IP 주소를 가리키지, 다른 도메인 이름을 가리키지 않습니다. 하나의 이름이 다른 이름의 별칭이 되길 원한다면 CNAME 레코드가 필요합니다. 그리고 둘 다 가질 수는 없습니다—CNAME은 해당 이름의 유일한 레코드여야 합니다(DNSSEC 레코드는 예외). 이 제약은 CNAME이 "이 이름은 사실 저 이름이야"를 의미하기 때문에, 직접적인 답변과 혼합하면 모호성이 생기기 때문입니다.

A 레코드는 그 주소의 서버가 실제로 실행 중인지도 알려주지 않습니다. 그건 DNS의 역할이 아닙니다. 모니터링, 상태 확인, 페일오버는 스택의 다른 계층에서 이루어집니다.

A 레코드에 관한 자주 묻는 질문

A 레코드 변경이 전파되는 데 얼마나 걸리나요?

이전 레코드의 TTL에 따라 다릅니다. TTL이 3600초(1시간)였다면, 변경 후 최대 1시간 동안 전 세계 리졸버들이 이전 주소를 캐시할 수 있습니다. TTL은 최대값이지 보장이 아닙니다—일부 리졸버는 더 일찍 갱신하고, 일부는 정확히 지킵니다.

로드 밸런서 대신 라운드 로빈 DNS를 사용하는 이유는 무엇인가요?

라운드 로빈은 별도 비용 없이 쓸 수 있고 추가 인프라도 필요 없습니다. 소규모 사이트나 기본적인 부하 분산에는 잘 작동합니다. 하지만 상태 확인, 가중치 분산, 세션 지속성은 제공하지 않습니다. 출발점이지 목적지가 아닙니다.

A 레코드가 다운된 서버를 가리키면 어떻게 되나요?

레코드가 변경되거나 캐시된 항목이 만료될 때까지 트래픽이 계속 그 주소로 향합니다. 이것이 모니터링이 중요한 이유입니다—TTL이 오래된 항목을 유지하는 것보다 빠르게 장애를 감지하고 대응해야 합니다.