주소의 언어와 전송 형식을 구별하는 판단
진료 페이지 주소에 한글을 사용할지는 독자가 이해할 언어와 URL이 처리되는 형식을 나누어 판단할 수 있습니다. Google은 URL에 잠재고객의 언어로 된 단어를 사용하고 해당하는 경우 음역된 단어를 사용할 수 있다고 안내합니다. 따라서 한글이라는 이유만으로 주소 후보에서 제외하는 공통 규칙을 만들 필요는 없습니다.
이 권장사항은 특정 언어의 주소가 검색 순위에서 더 유리하다는 비교 자료가 아닙니다. 한국어 독자가 이해할 수 있는 설명을 선택하는 판단과 순위의 상승 또는 하락을 예측하는 판단은 구별됩니다. 한글 주소를 선택했다는 사실만으로 검색결과의 개선을 확정하거나, 영문 주소가 반드시 불리하다고 설명하지 않습니다.
독자에게 읽히는 단어를 정했더라도 실제 링크에서는 문자가 어떻게 표현되는지 대조해야 합니다. Google은 링크의 href 속성에 필요한 경우 퍼센트 인코딩을 사용하며 ASCII 범위 밖의 문자는 퍼센트 인코딩되어야 한다고 설명합니다. 한국어라는 언어를 선택하는 문제와 URL 표준에 맞는 링크를 만드는 문제가 함께 있지만 같은 판단은 아닙니다.
Google의 URL 구조 안내는 사이트를 효과적으로 크롤링하기 위한 요구사항으로 제시됩니다. 기준을 충족하지 않으면 비효율적으로 크롤링되거나 아예 크롤링되지 않을 가능성을 설명합니다. 이 원문에서 기술 조건의 목적은 주소를 처리하고 콘텐츠에 접근할 수 있도록 하는 것입니다. 독자의 언어를 선택한 뒤에도 크롤링 가능한 형식인지 별도로 대조할 이유가 여기에 있습니다.
언어 후보를 비교하는 편집 제안
| 주소의 언어 후보 | 비교할 독자의 이해 조건 | 후보 선택에서 구별할 부분 |
|---|---|---|
| 한국어 단어 | 한국어로 안내할 독자가 실제로 쓰는 표현인지 | 일상 표현과 정확한 진료명 사이의 의미 차이 |
| 영문 명칭 | 그 명칭을 독자가 알고 있는지 | 전문가에게 익숙한 말과 방문자가 이해하는 말 |
| 음역된 단어 | 발음을 옮긴 이름으로 주제를 알아볼 수 있는지 | 단어의 발음이 알려진 것과 의미가 알려진 것 |
퍼센트 인코딩이 표현하는 정보
Google이 안내하는 IETF STD 66의 문법은 RFC 3986에서 설명합니다. 이 표준의 퍼센트 인코딩은 데이터의 한 바이트를 퍼센트 기호와 두 자리의 16진수로 나타내는 방식입니다. 눈에 보이는 한글 한 글자를 영어 단어로 번역하는 절차가 아닙니다. 주소의 뜻을 바꾸는 명명 작업과 문자 데이터를 전송 가능한 형식으로 표현하는 처리를 구별해야 합니다.
RFC는 문자를 나타내는 데이터와 URI를 표현하는 문자의 단계가 다를 수 있음을 설명합니다. 외부에 제공할 식별자를 만들 때 내부의 문자 인코딩을 적합한 형식으로 변환하고 URI 문자 범위로 표현하는 과정이 있습니다. 한글이 들어간 주소를 처리할 때에도 겉으로 보이는 글자만 비교하기보다 실제 구현이 어떤 문자 데이터와 URL 표기를 연결하는지 대조하는 기술 점검이 필요합니다.
표준은 유니코드 문자를 나타내는 새로운 URI 구성요소를 정의할 때 UTF-8 바이트로 먼저 표현한 뒤 비예약 문자에 해당하지 않는 바이트를 퍼센트 인코딩하도록 설명합니다. 이 내용은 문자와 바이트 변환의 관계를 이해하는 참고입니다. 병원 원고에서 주소의 언어를 선택하는 일을 기술 구현의 세부 설정까지 결정하는 작업으로 확대하지 않습니다.
예약 문자는 주소의 구성요소를 나누는 역할로 쓰일 수 있습니다. RFC는 주소 구성요소의 데이터가 예약 문자의 구분 역할과 충돌하면 URI를 만들기 전에 그 데이터를 퍼센트 인코딩하도록 설명합니다. 따라서 문장에 쓰이는 기호를 주소에 그대로 붙여도 언제나 같은 의미로 처리된다고 볼 수는 없습니다. 기호의 역할은 실제 URL 구성요소에 맞춰 판단해야 합니다.
보이는 글자와 링크 목적지의 대조
독자가 읽는 설명과 실제 링크 목적지는 구별해 대조할 수 있습니다. Google의 퍼센트 인코딩 권장사항은 페이지에 연결하는 링크의 href 속성을 대상으로 설명합니다. 화면에서 한글 이름이 보인다는 사실만으로 그 링크 속성의 URL이 올바르게 처리되는지 알 수는 없습니다. 반대로 링크에서 인코딩된 문자열이 보인다고 원래 문서의 주제가 영문으로 바뀌는 것도 아닙니다.
RFC는 URI를 처리할 때 의미 있는 구성요소와 하위 구성요소를 먼저 분리한 뒤 그 안의 인코딩된 데이터를 해석하도록 설명합니다. 순서를 구별하지 않으면 데이터가 주소의 구분자로 오인될 수 있기 때문입니다. 실제 링크를 처리하는 구현에서는 단순히 화면에 보이는 문자열을 한꺼번에 풀어 쓰기보다 URL의 구조와 데이터 변환 순서가 맞는지를 기술적으로 대조해야 합니다.
혼합 주소에서 적용할 표기 원칙
주소에 영문자가 함께 들어간다면 대소문자 처리도 별도로 대조할 수 있습니다. Google은 URL을 대소문자를 구분해 처리하며 대소문자가 다른 경로를 각각 고유한 URL로 취급한다고 설명합니다. 웹서버가 대소문자를 동일하게 처리하는 경우에는 표기를 동일하게 변환하도록 권고합니다. 이는 서버의 처리 조건이 붙은 설명이며 모든 경로의 대소문자를 임의로 바꿔도 된다는 뜻은 아닙니다.
단어를 구분할 때에는 Google이 밑줄보다 하이픈을 권장합니다. 사용자와 검색엔진이 URL의 개념을 더 잘 식별할 수 있기 때문이라는 설명입니다. 한글 사용 여부와 단어 구분 방식은 다른 선택입니다. 한글과 영문을 비교하는 중에도 구분 기호가 서로 다른 규칙으로 적용되고 있지는 않은지 대조할 수 있으며, 구분 기호 하나로 검색 순위를 확정하지 않습니다.
Google은 가능하면 콘텐츠를 변경하지 않는 불필요한 매개변수를 줄여 URL 길이를 줄이도록 권고합니다. 주소가 길게 보이는 원인이 인코딩된 한글의 표현인지 불필요한 매개변수인지 구별하는 데 참고할 수 있습니다. 필요한 문자 표현을 임의로 지우는 방식과 실제로 콘텐츠를 바꾸지 않는 매개변수를 정리하는 방식은 같은 작업이 아닙니다.
기존 주소와 새 주소 후보의 구별
이미 운영하는 진료 페이지에서는 현재 주소의 언어가 마음에 들지 않는다는 이유만으로 새 주소로 바꾸는 규칙을 만들지 않는 선택안을 제안할 수 있습니다. 언어의 취향과 실제 문제를 구별하는 판단입니다. 기존 주소가 어떤 페이지를 가리키는지, 독자가 이해하는 이름과 실제 처리에 문제가 있는지를 대조한 뒤 변경이 필요한지를 논의합니다.
기존 주소와 다른 표기를 비교할 때 모든 차이를 동일한 것으로 정규화해서는 안 됩니다. RFC는 예약 문자를 그에 해당하는 퍼센트 인코딩 표기로 바꾼 URI가 동등하지 않으며 대부분의 구현에서 해석이 달라질 수 있다고 설명합니다. 한글 인코딩을 정리하는 과정에서도 주소의 구분 기호를 바꾸는 작업은 별도로 판단해야 합니다. 겉으로 더 읽기 쉽다는 이유로 구조의 차이를 없애는 변경안을 적용하지 않습니다.
매개변수에서 구별할 세 가지 구분 방식
| Google이 제시한 형식 | 구분하는 대상 | 한글 데이터가 함께 있을 때의 대조 제안 |
|---|---|---|
| 등호 | 하나의 키와 값 | 이름과 데이터의 경계가 유지되는지 |
| 앰퍼샌드 | 추가하는 매개변수 | 새 키와 값이 앞선 값에 섞이지 않는지 |
| 표준에 충돌하지 않는 쉼표 등 | 동일한 키에 속하는 여러 값 | 복수의 값과 다른 매개변수를 구별할 수 있는지 |
한글 주소 처리에 남는 질문
인코딩의 16진수에서 대소문자가 다르면 다른 주소인가요?
RFC 3986은 퍼센트 인코딩에 사용하는 16진수의 영문 대문자와 소문자가 동등하다고 설명합니다. 두 URI가 그 16진수 표기의 대소문자만 다르면 동등하며 일관성을 위해 대문자 사용을 권고합니다. 이는 인코딩된 바이트 표현의 조건입니다. 경로 안의 일반 영문 단어까지 대소문자를 같은 것으로 취급하는 규칙은 아닙니다.
비예약 문자도 반드시 인코딩해야 하나요?
표준의 비예약 문자에는 영문자, 숫자, 하이픈, 마침표, 밑줄, 물결표가 포함됩니다. 해당 문자를 퍼센트 인코딩한 표기는 같은 자원을 식별하지만 일관성을 위해 이런 인코딩을 새로 만들지 않도록 제시합니다. 문법상 사용할 수 있는 기호의 목록과 Google이 단어 구분에 권장하는 기호는 구별해서 적용해야 합니다.
이미 인코딩한 문자열을 다시 인코딩해도 되나요?
RFC는 같은 문자열을 두 번 이상 퍼센트 인코딩하거나 디코딩하지 않아야 한다고 명시합니다. 이미 처리한 문자열에 다시 적용하면 퍼센트 데이터와 인코딩의 시작 표시를 잘못 해석할 수 있다는 설명입니다. 복사한 주소를 처리하는 과정에서 현재 문자열이 어느 단계의 표현인지 구별하는 기술 점검이 필요합니다.
주소 데이터에 퍼센트 기호 자체가 필요하면 어떻게 표현하나요?
퍼센트 기호는 인코딩된 바이트를 나타내는 시작 표시로 쓰이므로, 그 기호 자체를 데이터로 사용할 때에는 %25로 퍼센트 인코딩해야 한다고 표준이 설명합니다. 기호가 있다는 사실과 인코딩을 시작하는 표기라는 사실을 구별하는 조건입니다. 실제 주소에서 기호가 어떤 데이터인지 파악한 뒤 구현에서 처리해야 합니다.
한글 이름을 # 뒤에 넣어 페이지 내용을 바꾸면 괜찮나요?
Google은 일반적으로 URL 프래그먼트를 지원하지 않으며 프래그먼트를 사용해 페이지 콘텐츠를 변경하지 말라고 안내합니다. 한글을 사용할 수 있는지와 별개로 주소가 콘텐츠를 식별하는 방식에 관한 조건입니다. JavaScript로 내용을 바꾸는 경우에는 문서에서 History API 사용을 안내하므로 실제 사이트의 동작과 함께 기술 검토가 필요합니다.