URL

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
- 2.1. URL의 탄생과 표준화
- 2.2. 국제화 URL (Internationalized URL)
3. URL의 구조와 형식
4. URL 관련 표준
5. 기타
참조

1. 개요

URL은 웹 리소스를 식별하고 위치를 지정하는 데 사용되는 일종의 URI(Uniform Resource Identifier)이다. 1994년 팀 버너스 리와 IETF URI 워킹 그룹에 의해 RFC 1738에 정의되었으며, 도메인 네임 시스템과 파일 경로 구문을 결합한 형태를 갖는다. URL은 스키마, 호스트, 포트, 경로, 쿼리 등으로 구성되며, 프로토콜 상대 URL 및 영구 링크와 같은 관련 개념이 존재한다. 또한 URL은 데이터를 저장하는 데 사용될 수도 있으며, 국제화된 URL(IRI)을 통해 다양한 언어로 사용할 수 있다.

더 읽어볼만한 페이지

URL - URL 단축
URL 단축은 긴 URL 주소를 짧게 변환하여 가독성과 공유를 용이하게 하는 기술 또는 서비스로, 소셜 미디어나 메시징 플랫폼에서 유용하며 QR 코드 최적화, 데이터 분석 등의 기능을 제공하지만 악용될 가능성과 링크 부패의 위험성도 존재한다.
URL - URL 리다이렉션
URL 리다이렉션은 사용자를 다른 웹 페이지로 자동 이동시키는 기술이며, HTTP 상태 코드를 통해 구현되고 보안, URL 축약, 장치 타겟팅 등 다양한 목적으로 활용되지만, 보안 문제와 피싱 공격에 악용될 위험도 존재한다.
식별자 - 아카이벌 리소스 키
아카이벌 리소스 키(ARK)는 디지털, 물리적, 추상적 자원의 영구적인 식별을 위한 체계로, 분산된 웹 환경에서 관리 주체의 약속을 통해 객체의 보존과 접근성을 제공하며, ARK Alliance가 국제적인 사용을 장려하고 한국에서도 활용된다.
식별자 - 바코드
바코드는 다양한 폭의 막대와 공백 조합으로 정보를 나타내는 기호로, 상품 식별, 재고 관리 등에 사용되며 1차원과 2차원 바코드가 존재하고 바코드 스캐너로 판독되어 산업 효율성을 높인다.

URL
식별
긴 이름	유니폼 리소스 로케이터
상태	발행됨
버전	리빙 스탠다드
버전 날짜	2023
조직	인터넷 엔지니어링 태스크 포스(IETF)
위원회	웹 하이퍼텍스트 애플리케이션 기술 워킹 그룹(WHATWG)
기본 표준	. - 유니폼 리소스 로케이터 (URL). . - 유니폼 리소스 식별자 (URI): 일반 구문. . - 텔넷 URI 스키마. . - 고퍼 URI 스키마. . - 'mailto' URI 스키마. . - 메일서버 이동: URI 스키마에서 역사적으로. . - 'tn3270' URI 스키마.
관련 표준	URI, URN
약칭	URL
도메인	월드 와이드 웹
라이선스	CC BY 4.0
웹사이트	URL
첫 게시일	1994년
저자	팀 버너스 리
시리즈	요청 의견 (RFC)
편집자	안네 반 케스테렌
개요
설명	웹 주소를 파일 또는 페이지로 연결

2. 역사

URL은 1994년 월드 와이드 웹의 창시자 팀 버너스 리와 IETF URI 워킹 그룹의 협업으로 RFC 1738에 정의되었다.^[3]^[4] 이는 1992년 IETF Live Documents Birds of a feather 세션에서 시작된 논의의 결과였다.

URL 형식은 1985년에 만들어진 기존의 도메인 네임 시스템과 파일 경로 구문을 결합한 것이다. 슬래시는 디렉토리와 filename을 구분하는 데 사용되며, 서버 이름을 파일 경로 앞에 붙이고 이 앞에 이중 슬래시(//)를 붙이는 규칙은 이미 존재했다.

버너스 리는 나중에 URI 내에서 도메인 네임의 각 부분을 점(.)으로 구분한 것에 대해 후회하며, 처음부터 슬래시(/)를 사용했어야 했다고 말했다. 또한 URI의 첫 번째 구성 요소 뒤에 콜론(:)이 오는 것을 감안할 때, 도메인 이름 앞에 두 개의 슬래시(//)가 필요하지 않았다고 언급했다.

초기 WorldWideWeb 협력자들은 UDI(Universal Document Identifiers, 범용 문서 식별자)를 제안하기도 했다. 1993년 초기 HTML 사양 초안은 "Universal" Resource Locators(범용 리소스 로케이터)를 언급했으나, 1994년 6월 (1630)과 1994년 10월 사이에 삭제되었다. 버너스 리는 그의 저서 ''Weaving the Web''에서 "uniform"이라는 단어보다 "universal"을 포함하는 것을 선호한다고 강조했다.

2. 1. URL의 탄생과 표준화

1994년, 월드 와이드 웹의 창시자 팀 버너스 리는 IETF URI 워킹 그룹과의 협업을 통해 RFC 1738에서 URL을 정의하였다.^[3]^[4] 이는 1992년 IETF Birds of a feather 세션에서 시작된 논의의 결과였다. 초기에는 UDI(Universal Document Identifiers, 범용 문서 식별자)라는 용어가 제안되기도 했으나, 최종적으로 URL(Uniform Resource Locator)로 결정되었다.

URL은 기존의 도메인 네임 시스템과 파일 경로 구문을 결합한 형태로, 슬래시(/)를 사용하여 디렉토리와 파일을 구분한다. 팀 버너스 리는 후에 URI 내에서 도메인 네임의 각 부분을 구분하는 데 점(.)을 사용한 것에 대해 후회하며, 슬래시(/)를 사용했어야 했다고 언급했다.

2. 2. 국제화 URL (Internationalized URL)

국제화된 자원 식별자(IRI)는 유니코드 문자를 포함하는 URL의 한 형태이며, 전 세계 인터넷 사용자들이 자신의 언어로 URL을 사용할 수 있도록 한다. 모든 최신 브라우저는 IRI를 지원한다. 서로 다른 문자에 대해 특별한 처리가 필요한 URL의 부분은 도메인 이름과 경로이다.

IRI의 도메인 이름은 국제화된 도메인 이름(IDN)으로 알려져 있다. 웹 및 인터넷 소프트웨어는 도메인 이름을 Punycode로 자동 변환하여 도메인 이름 시스템에서 사용할 수 있도록 한다. 예를 들어, 중국어 URL `http://例子.卷筒纸`는 `http://xn--fsqu00a.xn--3lr804guic/`로 변환된다. `xn--`은 해당 문자가 원래 ASCII가 아니었음을 나타낸다.

URL 경로 이름도 사용자가 로컬 표기 시스템으로 지정할 수 있다. 아직 인코딩되지 않은 경우 UTF-8로 변환되며, 기본 URL 문자 집합에 속하지 않는 모든 문자는 퍼센트 인코딩을 사용하여 16진수로 이스케이프 처리된다. 예를 들어, 일본어 URL `http://example.com/引き割り.html`는 `http://example.com/%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.html`로 변환된다. 대상 컴퓨터는 주소를 디코딩하고 페이지를 표시한다.

3. URL의 구조와 형식

URL은 RFC 1738에서 정의되었으며, 지정된 스킴(scheme)에 따라 표현 방법이 다를 수 있다. URL은 일반적으로 다음과 같은 형식을 갖는다.^[22]

:(스키마 이름)''':'''(스키마별로 정해진 어떤 표현 형식)

스키마 이름으로는 프로토콜 이름이 사용되는 경우가 많지만, 거기에 한정되지는 않는다. URL은 URI와는 달리, #를 포함하지 않으며, ?까지만 포함한다.^[16]

IETF RFC 1738에는 다음의 스키마 이름이 정의되어 있다.

스키마	설명
ftp	FTP를 위한 스키마
http	HTTP를 위한 스키마
gopher	고퍼 프로토콜을 위한 스키마
mailto	전자 메일 주소를 나타내기 위한 스키마
news	넷뉴스 (유즈넷)를 위한 스키마
nntp	NNTP를 사용한 넷뉴스를 위한 스키마
telnet	텔넷 접속을 나타내기 위한 스키마
wais	Wide Area Information Servers를 위한 스키마
file	파일 시스템 안의 디렉토리나 파일을 참조하기 위한 스키마
prospero	Prospero Directory Service를 위한 스키마

2000년 5월, IETF RFC 2818에서 HTTPS를 위한 스키마가 추가되었다.

IANA에 등록된 스키마^[14]가 공식적으로 인정된 스키마로 간주되며, 등록 절차는 IETF RFC 7595에서 규정하고 있다. 이 외에도 javascript 스키마 (이 뒤에 쓰여진 내용이 자바스크립트 언어에 의해 쓰여진 스크립트임을 나타냄)처럼 널리 보급된 비공식 스키마도 있다.^[15]

3. 1. 일반 형식

URL은 일반적으로 다음과 같은 형식을 갖는다.^[22]

:(스키마 이름)''':'''(스키마별로 정해진 어떤 표현 형식)

스키마는 리소스에 접근하는 데 사용되는 프로토콜을 나타낸다. 예를 들어 gopher, telnet, ftp, http, usenet 등이 있다. 프로토콜 이름 다음에는 구분자 ":"를 적고, IP 혹은 도메인 네임 정보가 필요한 프로토콜이면 ":" 다음에 "//"를 적는다. "//" 다음에는 프로토콜에 특화된 정보를 적는다.

예시는 다음과 같다.

`http://www.somehost.com/a.gif` : IP 혹은 도메인 네임 정보가 필요한 형태 (www.somehost.com에 있는 a.gif)
`ftp://id:pass@192.168.1.234/a.gif` : IP 혹은 도메인 네임 정보가 필요한 형태 (192.168.1.234에 있는 a.gif)
`mailto:somebody@mail.somehost.com` : IP 정보가 필요없는 프로토콜 (mailto 프로토콜은 메일을 받는 사람 주소를 나타냄)

RFC 1738에 정의된 일반적인 URL 형식은 다음과 같다.



scheme://:@:/

`scheme`: 프로토콜
``: 사용자 이름 (생략 가능)
``: 비밀번호 (생략 가능)
``: 호스트 이름, FQDN 또는 IP 주소
`https://192.168.10.2/` (IPv4의 경우)
`https://[fe80::a1b3:125d:c1f8:4781]/` (IPv6의 경우)
``: 포트 번호 (기본값 존재시 생략 가능)
``: 경로 (생략 가능)

HTTP URL은 다음과 같이 표현한다.

http://:/?

``: 호스트 내 리소스 경로
``: `?` 뒤에 추가적인 파라미터

URL은 `#`를 포함하지 않고, `?`까지만 포함한다.^[16]

HTTPS URL 형식 예시는 다음과 같다.

https:	//ja.wikipedia.org	/wiki/Wikipedia
↑	↑	↑
｜	｜	경로명
｜	호스트명	(디렉토리명 포함)
스키마 (프로토콜명 아님)

`https`는 HTTPS를 사용해야 함을 나타낸다.
`ja.wikipedia.org`는 리소스가 보관된 호스트를 나타낸다.
`/wiki/Wikipedia`는 리소스를 특정하기 위한 상세 정보다.

IANA에 등록된 스키마^[14]가 공식 스키마로 간주되며, 등록 절차는 7595에서 규정한다. 널리 보급된 비공식 스키마도 있다.^[15]

3. 2. URL 표현 방법 (한국어 위키백과)

RFC 1738에 정의되어 있으며, 지정된 스킴(scheme)에 따라 표현방법이 다를 수 있다. 일반적으로 많이 사용하는 HTTP URL 스킴은 다음과 같이 표현한다.



http://:/?

URL은 URI와는 달리, #를 포함하지 않으며, ?까지만 포함한다.

일반적으로 URL은

(스키마 이름)''':'''(스키마별로 정해진 어떤 표현 형식)

형태를 하고 있다. 스키마 이름으로는 프로토콜 이름이 사용되는 경우가 많지만, 거기에 한정되지는 않는다.

https나 ftp와 같이 특정 호스트에 IP 접속하는 종류의 스킴에서는 다음과 같은 공통 형식이 사용되고 있다. 이 표기에서는, 접속하는 프로토콜은 호출하는 기능의 프로토콜과 같은 것이 사용된다.



//:@:/?

`<user>` - 호스트에 접속할 때 사용하는 사용자 이름. 필요하지 않으면 생략 가능.
`<password>` - 사용자 이름에 대응하는 비밀번호. 필요하지 않으면 생략 가능.
`<host>` - 호스트 이름, FQDN 또는 IP 주소
`https://192.168.10.2/` ← IPv4의 경우
`https://[fe80::a1b3:125d:c1f8:4781]/` ← IPv6의 경우
`<port>` - 접속 대상 포트 번호. 호스트의 어떤 포트에 접속할지를 나타낸다. 스키마가 기본값 포트 번호를 규정하고 있는 경우는 생략해도 좋다.
`<url-path>` - 호스트에 요구하는 경로. 호스트의 파일 시스템에서의 경로와 대응하는 경우가 많지만, 그렇지 않은 경우도 있다. 필요하지 않으면 생략 가능.
`<query-string>` - 접속 대상이 이용하는 파라미터. `?`에 이어 임의의 형식으로 데이터를 기술한다. 생략 가능. 정식 명칭은 "URL-query string"이다.

3. 3. URL과 URI

URL은 URI(Uniform Resource Identifier)의 하위 개념이다. URI는 리소스를 식별하는 일반적인 방법이며, URL은 리소스의 위치를 특정하는 URI의 한 종류이다. URL은 URI와 달리 프래그먼트(`#fragment`)를 포함하지 않고, 쿼리(`?query`)까지만 포함한다.^[22]

일반적으로 URL은 다음과 같은 형태를 가진다.

:(스키마 이름)''':'''(스키마별로 정해진 어떤 표현 형식)

스키마 이름으로는 프로토콜 이름이 사용되는 경우가 많지만, 거기에 한정되지는 않는다. 1738에는 다음의 스키마 이름이 정의되어 있다.

스키마	설명
ftp	FTP를 위한 스키마
http	HTTP를 위한 스키마
gopher	고퍼 프로토콜을 위한 스키마
mailto	전자 메일 주소를 나타내기 위한 스키마
news	넷뉴스 (유즈넷)를 위한 스키마
nntp	NNTP를 사용한 넷뉴스를 위한 스키마
telnet	텔넷 접속을 나타내기 위한 스키마
wais	Wide Area Information Servers를 위한 스키마
file	파일 시스템 안의 디렉토리나 파일을 참조하기 위한 스키마
prospero	Prospero Directory Service를 위한 스키마

2000년 5월, 2818에서 HTTPS를 위한 스키마가 추가되었다.

IANA에 등록된 스키마^[14]가 공식적으로 인정된 스키마로 간주되며, 7595에서 등록 절차 등에 대해 규정하고 있다. 이 외에도 javascript 스키마 (이 뒤에 쓰여진 내용이 자바스크립트 언어에 의해 쓰여진 스크립트임을 나타냄)처럼 널리 보급된 비공식 스키마도 있다.^[15]

URL의 스키마 이름 이후의 부분은 스키마별로 정해진 규칙을 따른다. 예를 들어, 전자 메일 주소를 나타내는 mailto 스키마의 URL은 `mailto:example@example.com` 와 같이 되어 있으며, https 스키마의 예와는 크게 다르다.

https나 ftp와 같이 특정 호스트에 IP 접속하는 종류의 스키마에서는 다음과 같은 공통 형식이 사용되고 있다.

:`//:@:/?`

`<user>` : 호스트에 접속할 때 사용하는 사용자 이름. 필요하지 않으면 생략 가능.
`<password>` : 사용자 이름에 대응하는 비밀번호. 필요하지 않으면 생략 가능.
`<host>` : 호스트 이름, FQDN 또는 IP 주소
`https://192.168.10.2/` ← IPv4의 경우
`https://[fe80::a1b3:125d:c1f8:4781]/` ← IPv6의 경우
`<port>` : 접속 대상 포트 번호. 호스트의 어떤 포트에 접속할지를 나타낸다. 스키마가 기본값 포트 번호를 규정하고 있는 경우는 생략해도 좋다.
`<url-path>` : 호스트에 요구하는 경로. 호스트의 파일 시스템에서의 경로와 대응하는 경우가 많지만, 그렇지 않은 경우도 있다. 필요하지 않으면 생략 가능.
`<query-string>` : 접속 대상이 이용하는 파라미터. `?`에 이어 임의의 형식으로 데이터를 기술한다^[16]. 생략 가능. 정식 명칭은 "[https://url.spec.whatwg.org/#url-query-string URL-query string]"이다.

3. 4. 예시 (일본어 위키백과)

"'''https''':'''//ja.wikipedia.org'''/'''wiki/Wikipedia'''"는 URL의 전형적인 예이다. 이 URL은 위키백과 일본어판의 위키백과 항목을 가리킨다.^[13]

'''스키마명''' `https`는 HTTPS를 사용하여 이 항목을 가져와야 함을 나타낸다.
`ja.wikipedia.org`는 자료가 보관된 호스트를 나타낸다.
`/wiki/Wikipedia` 부분은 리소스를 특정하기 위한 상세 정보다. 파일 시스템 내의 파일명이나 디렉토리명에 해당하는 경우가 많지만, 그렇지 않은 경우도 있다.

대략, 위의 URL은 "'''ja.wikipedia.org'''라는 컴퓨터에 접속하여 '''HTTPS''' 규칙에 따라 '''/wiki/Wikipedia'''라는 이름의 데이터를 요청하면 목적한 것을 얻을 수 있다"라고 해석할 수 있다. 참고로, 스키마명 뒤의 이중 슬래시 `//`는 큰 의미가 없는 경우가 많다. 2009년 10월, URL 제안자인 팀 버너스 리는 이중 슬래시를 "제거하고 싶다"라고 말했다.^[13]

4. URL 관련 표준

URL 관련 표준은 여러 RFC 문서와 WHATWG의 URL Living Standard가 있다.

URL은 1994년 월드 와이드 웹의 창시자 팀 버너스 리와 IETF의 URI 워킹 그룹이 협업하여 RFC 1738에 정의하였다.^[17]

WHATWG가 [https://url.spec.whatwg.org/ URL Living Standard](URL 리빙 스탠다드)를 제정하고 있다. 이는 RFC 3986 등을 대체하는 표준 사양이다.

URL과 관련된 RFC는 다음과 같다.

RFC 1738 - Uniform Resource Locators (URL)
RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax
RFC 7595 (BCP 35) - Guidelines and Registration Procedures for URI Schemes

W3C가 발행한 URL에 관한 문서는 다음과 같다.

[https://www.w3.org/TR/url/ URL] (2017년, 워킹 그룹 노트): WHATWG URL Standard의 스냅샷이다.

5. 기타

사이트 데이터를 데이터 베이스에 저장하는 것이 아닌 URL에 저장할 수 있다. 가장 쉽게 접할 수 있는 곳은 네이버 파파고인데, 번역을 원하는 글을 URL에 전부 집어 넣는 방식이다.^[1]

5. 1. 프로토콜 상대 URL (Protocol-relative URLs)

프로토콜 상대 URL(PRURL)은 프로토콜을 명시하지 않고 현재 페이지의 프로토콜(일반적으로 HTTP 또는 HTTPS)을 사용하는 URL이다. 예를 들어 `//example.com`과 같이 사용한다.^[1]

5. 2. 영구 링크 (Permanent link)

영구 링크(permanent link^영어)란 영구적인 URL을 의미한다. 주로 콘텐츠 관리 시스템, 특히 블로그에서 개별 기사에 대한 URL이 업데이트 작업을 반복해도 변경되지 않는 메커니즘을 의미한다. 일반적으로 URL은 영구적으로 변경되지 않는 것이 바람직하다.^[19]^[20]

특정 기사 또는 웹 페이지에 대한 직접 링크(직접 링크라고도 함)가 증가함에 따라, 한편으로는 '''링크 끊김'''^[21]()의 대량 발생도 큰 문제로 대두되고 있다. 이러한 사태를 피하기 위해 콘텐츠 업데이트 작업이 이루어지고, 업데이트 기록이 저장되는 시스템에서 유효한 콘텐츠에 대한 URL이 변동하지 않도록 데이터 참조 번호 등을 고정하고 참조 방법을 단순화하여 URL이 불필요하게 길어지지 않는 것이 바람직하다.

이를 위한 특수한 기술로 Apache 웹 서버의 경우, '''mod_rewrite'''를 사용하여 URL을 변경하거나 PATH_INFO에서 매개변수를 가져와 프로그램을 실행하는 방법 등이 있다. 특히 mod_rewrite의 경우, PHP에 의한 동적 콘텐츠를 정적인 html 콘텐츠처럼 보이게 하는 것이 용이하다. 또한 PATH_INFO 방식의 경우 동적 콘텐츠를 하위 디렉토리처럼 보이게 할 수 있다. 이 외에도 휴대폰 사이트에서는 URL을 단축하기 위한 다양한 기술이 사용되고 있다. 어느 경우든 URL뿐만 아니라 원본 파일 확장자를 숨김으로써 스크립트를 이미지나 음악 파일처럼 위장하는 등 악용될 우려도 있으므로, 호스팅 서버에서는 사용이 제한되는 경우가 많다.

5. 3. URL과 데이터 저장 (한국어 위키백과)

URL에 데이터를 저장하는 방법도 가능하다. 예를 들어 네이버 파파고의 번역 URL을 들 수 있다. 이 방식은 URL에 번역할 텍스트를 포함시켜 데이터를 전달한다.^[1]

참조

_[1] 웹사이트 Forward and Backslashes in URLs https://zzz.buzz/201[...] 2018-09-19
_[2] 웹사이트 The Difference Between URLs and URIs https://danielmiessl[...] 2017-03-16
_[3] 간행물 Hypertext Markup Language (draft RFCxxx) https://www.ucc.ie/a[...] 2017-10-23
_[4] 간행물 Uniform Resource Locators (URL) https://listserv.hea[...] UCSF Library and Center for Knowledge Management 2017-10-23
_[5] 서적 Secure Development for Mobile Apps: How to Design and Code Secure Mobile Applications with PHP and JavaScript https://books.google[...] CRC Press 2015-10-12
_[6] 서적 HTML, XHTML, and CSS Bible https://books.google[...] John Wiley & Sons 2015-10-12
_[7] 문서 World-Wide Web http://www-linac.kek[...] 1994-01-21
_[8] 간행물 1630 IETF RFC
_[9] 웹사이트 URLとは？意味やドメインとの違い、構成する要素を徹底解説！｜ferret https://ferret-plus.[...]
_[10] 웹사이트 "「ホームページアドレスとは？」その疑問、ここで全解決！ - Value Note - わかる、なるほどなIT知識。" https://www.value-do[...]
_[11] 웹사이트 アドレスバーの位置を変更する - Google Chrome ヘルプ https://support.goog[...]
_[12] 웹사이트 Firefox のアドレスバーで検索する | Firefox ヘルプ https://support.mozi[...]
_[13] 뉴스 The Web's Inventor Regrets One Small Thing https://bits.blogs.n[...] 2021-01-05
_[14] 웹사이트 Uniform Resource Identifier (URI) Schemes https://www.iana.org[...] IANA
_[15] 간행물 The 'javascript' resource identifier scheme draft-hoehrmann-javascript-scheme-03 https://tools.ietf.o[...] インターネットドラフト
_[16] 웹사이트 URL Living Standard ver.2021-03-23 https://url.spec.wha[...]
_[17] 웹사이트 私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 http://postd.cc/my-u[...] POSTD 2016-06-03
_[18] 웹사이트 はじめてのDjangoアプリ作成その3 http://e-class.cente[...] 2019-08-24
_[19] 웹사이트 Hypertext Style: Cool URIs don't change. https://www.w3.org/P[...] World Wide Web Consortium 2017-02-19
_[20] 웹사이트 クールなURIは変わらない -- Style Guide for Online Hypertext https://www.kanzaki.[...] 2017-02-19
_[21] 논문 失われていくインターネット上の参照文献図書館情報学分野の雑誌論文に参照されたインターネット文献の入手可能性の分析調査 https://doi.org/10.1[...] 国立研究開発法人科学技術振興機構 2019-08-24
_[22] 문서 URL Spec - 5. BNF for specific URL schemes http://tools.ietf.or[...]

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com