국한문 혼용체를 위해 한글 정렬 웹표준 논의됐다

일본인 CSS 표준 에디터(로 추정되는) Koji Ishii씨가 2014년 7월 8일 웹표준화기구 W3C의 메일링리스트에 보낸 문의 스크린샷
일본인 CSS 표준 에디터(로 추정되는) Koji Ishii씨가 2014년 7월 8일 웹표준화기구 W3C의 메일링리스트에 보낸 문의. http://lists.w3.org/Archives/Public/public-i18n-cjk/2014JulSep/0002.html

안녕하세요. 지디넷코리아 임민철 기자입니다. 저와 일면식이 있든없든 일단 이 글을 보신 여러분 가운데 월드와이드웹, 한글 타이포그래피, 국어국문학, 디지털 출판, 정보과학, 정보접근성, 이 주제들 가운데 하나라도 관심이 있으신 모든 분들께 긴히 드릴 부탁이 있습니다.

이 아래에는 일본의 Koji Ishii 씨가 w3.org 메일링리스트에 올린 “[css-text]Justifying Korean text(http://lists.w3.org/Archives/Public/public-i18n-cjk/2014JulSep/0002.html)” 전문을 번역한 글이 있습니다. 이 글에 포함된 Koji 씨의 질문 가운데 답하실 수 있는 어떤 내용이든 적어주시면 됩니다.

현재 Koji 씨는 웹용 스타일언어 CSS의 미래 표준 내용 중 한국어를 모국어로 쓰는 사람들에게 중요할 수 있는 ‘한국어 웹문서의 한자와 한글 문자열 양쪽맞춤 작동방식’을 최대한 합리적으로 결정하기 위한 정보 및 의견을 요청하고 있습니다. 여기서 합리성의 범주는 한국어 환경에서 요구되는 한자 처리방식의 특수성과 중국, 일본에서 요구되는 한자 처리방식과 조화를 이루는 것도 포함합니다.

사람들이 Koji 씨에게 어떤 정보를 제공하느냐에 따라 또는 하지 않느냐에 따라 웹표준을 따르는 모든 미래 인터넷 환경에서 한국어를 표기하는 한글과 한자의 문자의 정렬방식이 달라질 수 있습니다. 이런 사안에 관심이 있는 모든 분들이 아래의 미숙한 번역문이나 앞서 제시한 링크로 보실 수 있는 원문을 읽고 알맞은 정보나 의견을 남겨 주셨으면 합니다.

제 번역문에 오탈자나 용어 의미상 원문을 잘못 옮긴 부분이 있을 경우도 지적해 주시길 바랍니다. 영어가 부담스러운 분께서는 일단 이 페이스북에 댓글로 의견을 남겨 주시면 제가 그 내용을 Koji 씨에게 전달할 수 있는 방법을 강구해 보겠습니다. 가급적 영작이 가능하신 분께서는 Koji 씨(kojiishi@gluesoft.co.jp)에게, w3.org메일링리스트(public-html-ig-ko@w3.org)를 통해 직접 의견을 남겨주시기 바랍니다.

이하 번역문입니다.

[css-text]한국어 문자열 양쪽맞춤(Justifying Korean text)

Hello/안녕하세요

한국어 문자열을 양쪽맞춤하기 위해 맞는 방법이 무엇인지에 대해 논의하는 것을 도와주실 수 있을까요? 다소 장문의 메일로 말씀드리는데, 짧게 쓰질 못해 미안합니다.

배경부터 말씀드릴게요. 지난해 CSS 작업반(WG)이 문자열 양쪽맞춤 속성(property)[1]에 대해 논의했고 몇가지 결정사항(resolutions)을 얻을 수 있었습니다. 전체 결정사항 내용은 여기[2]에 있습니다만, 요약하면요:

1. 가능하다면 콘텐츠의 언어[3]에 자동적으로 양쪽맞춤이 이뤄지도록 하고, 최대한 동작 지정값을 없애자.

2. 이에 따라, 표의문자(ideographic characters) 사이 간격을 넓히기 위한 ‘inter-ideograph’ 값은 제거됐습니다만, 표의문자 사이 간격을 늘리지 않는 ‘inter-word’ 값은 여전히 (표준화하고 있는 CSS 스펙에) 포함돼 있습니다.

(번역자 주: ideographic characters는 직역하면 ‘표의문자’인데, 글쓴이가 이 어구로 가리키는 개념은 우리가 일반적으로 ‘한자(漢字)’라 부르는 문자를 가리킵니다. 한중일 3국의 한자를 동등한 개념으로 취급하기 위해 이런 표현을 채택한 것으로 보입니다. 이하 원문의 ideographic characters는 모두 ‘한자’로 대체했습니다.)

이런 여건에서 한국어 문자열에 적용하기 좋은 방식을 만드는 데 어려움을 겪고 있습니다.

제가 알기로 한국어 문서에는 3가지 유형이 있는데요:

[유형1] 한자 전용인 고대 문서(어쩌면 일부 한글 문자를 포함했을 수도 있는.)

[유형2] 대부분 한글로 쓰여, 한 단락이나 한 쪽의 아주 일부만 한자로 써진 문서.

[유형3] 전부 한글이고, 한자가 없는 문서.

질문1 제가 제대로 알고 있는 건지, 아니면 빠뜨린 문서 유형이 있는 것인지? 저는 각 문서들이 유형별로 얼마나 많은지 짐작하지 못하겠어서요, 그래서 이 첫번째 질문을 드린 겁니다.

질문2 웹상에서 각 유형에 해당하는 문서들의 비율이 얼마나 될지 알려주실 수 있을까요? 제 말은, “0:40:60″같은 비율로요. 어떤 통계 자료든 아니면 여러분이 감으로 짐작하는 비율을 말씀해 주시든 도움이 될 거예요. 만일 10명이 저마다 느낀 비율을 답해 주신다면 그것도 일종의 통계라고 볼 수 있으니까요.

질문3 이런 비율이 서류/도서/전자책 형태일 경우 웹문서와 달라질까요? TV/영화 자막, 간판(signage), 또는 웹 플랫폼 이외의 다른 곳에서 쓰이는 문자라면 어떨까요?

다음으로, 작성자가 문서에 lang=”ko”를 설정하고 text-align:justify도 물론 쓴다고 생각해 봅시다. 이건 우리가 한국어에 맞는 방식에만 초점을 맞출 수 있으니까 훨씬 쉬운 경우죠. 이 경우, 제가 알기론, 여러분은 문자 간격 넓히기를 공백문자(spaces) 부분에만 적용하길 원하죠, 맞나요? 모든 기존 브라우저들은 한글의 글자 사이 간격을 늘려주지 않는데요, 저는 이게 맞는 동작인 것 같습니다. 하지만, 크롬/사파리는 한자 사이 간격을 늘려주는데요, 저는 이게 위 유형2 문서에 대한 올바른 동작이 아니기 때문에 여러분들이 고쳐지길 바라리라 짐작하고 있습니다.

(번역자 주: lang=”ko” 문자열은 웹문서에서 기본 언어를 한국어로 지정하는 메타태그 코드로 작동하고, text-align:justify 문자열은 문단의 글자들을 ‘양끝 맞춤’ 형태로 정렬하도록 지정하는 CSS 코드로 작동함.)

질문4 이런 추측들이 정확한 건가요? 이런 사례에서 문제가 되는 점은, 여러분이 위 유형1 문서에서 양쪽맞춤을 못하게 된다는 건데요, 왜냐면 문자 양쪽맞춤은 한자 사이 간격을 늘려주는 값을 갖지 못하니까요. 만일 여러분이 이런 문제가 해결돼야 한다고 보신다면, 아래 몇 가지 방식 가운데 선택을 할 수 있습니다:

1. 그러한 문서를 lang=”zh”로 표시하는 겁니다. 저는 이 방식이 여러분께 맞을지 틀릴지 모르겠어요; 이런 고대 문서들은 중국어로 쓰인 건가요, 아니면 고대 한국어로 쓰인 건가요? 저는 이런 생각이 잘못됐을 것 같지만, 그래도 여쭤보고 싶어요. 만일 이게 아주 못되고 무례한 질문이라면, 부디 여러분께서 이해해주시길 바랍니다 전 그저 기술적으로 가능한 경우의 수를 여기에 모두 제시해 보는 거니까요.

(번역자 주: Ishii 씨가 말한 ‘그러한 문서’는 내용에 한글 없이 한자만을 써서 작성된 문서를 가리키며, lang=”zh” 문자열은 웹문서에서 기본 언어를 중국어로 지정하는 매타태그 코드로 작동함.)

2. CSS WG에 ‘inter-ideograph’ 값을 되살려달라고 제안해서, lang=”ko” 표시를 하고 한자 사이의 간격을 늘릴 수 있도록 만드는 방법이 있습니다.

3. 기본적으로 “한자와 한글 사이 글자 간격을 늘릴 수 있게” 만들고, 위 유형2, 유형3 문서에 대해서는 매번 ‘inter-word’ 값을 사용하는 방법이 있습니다. 이건 여러분에게 선택권을 드리긴 하지만 여러분께서 모든 유형2, 유형3 문서에 ‘inter-word’를 집어넣어야 한다는 점에서 비용이 높죠. 이 비용이 그걸로 얻는 가치만큼 높지 않은 걸까요?

4. 그런 문서는 희귀하고, 그걸 양쪽맞춤해야 하는 문서는 거의 0에 수렴할 정도로 훨씬 희귀하니까, 이런 특수한 사례에 대해 뭘 고쳐야 할 필요는 없을 수도 있겠네요. (위 질문2와 질문3 내용을 고려해 주시길.)

질문5 어떤 방식이 맞는 것 같으신지, 아니면 다른 방법이 있을까요?

다음으로. 이건 더 어려운 건데요; 특정한 언어가 표기되지 않았을 경우예요. 기존 문서 대부분에는 lang 표시가 없어서, 이건 어쩌면 질문5의 내용보다 하위호환성에 더 영향을 줄 수 있는 사안 같습니다. 이런 점에서 말하면 모든 기존 브라우저가 다르게 동작하기 때문에 단일한 정답이 없는 셈인데요; 우리에겐 충분히 괜찮은 동작을 하도록 뭔가 타협안이 필요합니다.

(번역자 주: Ishii 씨가 말하는 ‘충분히 괜찮은’ 동작은, 실제와 정확하게 일치하는 동작이 아니라 마땅한 대안이 없을 때 차선으로 고려됨직한 동작을 가리킴.)

이 경우 중국어와 일본어 문서는 한자 사이의 글자 간격을 늘릴 수 있길 원하는데, 한국어의 경우 유형2 문서는 그렇게 동작하지 않게 한다면, 불일치(conflict)가 나타나죠. 저는 이 불일치 문제를 적절히 해결할 방법을 모르겠는데요, 짐작하기에 중국어와 일본어 문서는 그렇게 작동해야 할 것 같은게, 이들은 양쪽맞춤을 더 자주 쓰고, 반면에 한국에선 한자가 기본 사용되는 게 아니니까요, 하지만 이건 제 개인적인 의견입니다. 다른 분들은 생각이 다를 수 있고 위 질문2와 질문3에 대한 답에 대해서도 영향을 받겠죠.

질문6 여러분의 생각은 어떠신가요?

다음으로. 질문6에서 우리가 중국어와 일본어를 쓴다고 생각해 보죠(한자 간격을 늘릴 수 있는). 이 경우:

질문7 여러분은 a)유형2 문서에서 한글과 한자가 그렇듯이 한글 글자끼리도 사이 간격을 늘리길 원하시나요 아니면 b)유형2 문서에서 좀 이상할 수는 있어도 유형3 문서를 쓰기에 더 도움이 되도록, 한글 글자끼리 사이를 늘리지 않길 원하시나요?

일부 브라우저는 한글과 한자 사이 간격을 늘려주기는 하지만, 현존하는 모든 브라우저들이 한글 글자 사이 간격을 늘리지 않는다는 점을 염두에 두시길. 저는 이런 동작이 여러분께 얼마나 이상하게 느껴질지 모르겠습니다 특히 유형2 문서를 고려할 때는요. 여러분께서 기존 브라우저 동작에 관한 제 조사 결과에 관심이 있으시다면 여기[4]에 있습니다. 이건 기본적으로 제가 끄적인 내용이고 아주 거칠어서 이해하기 어려우실 수도 있지만요.

마지막으로, 이건 질문을 드리는 건 아닙니다만, 만일 여러분께서 양쪽맞춤을 지정한 한국어 HTML 문서를 만드신다면, 저는 1) lang=”ko” 와 2) text-justify:inter-word 문자열을 추가하시길 권장합니다. 미래를 예측하긴 어렵지만, 지금 여러분께 제가 말씀드릴 수 있는 것은, 이게 향후 여러분의 문서를 보호할 수 있는 최고의 방법으로 여겨진다는 점입니다.

만일 여러분께서 이 질문의 일부분에 대해서만 답할 수 있다 하시더라도, 여전히 도움이 될 것입니다. 이 긴 메일을 읽어주셔서 감사드리고, 의견을 기다리겠습니다.

[1] http://dev.w3.org/csswg/css-text/#text-justify-property

[2] http://lists.w3.org/Archives/Public/www-style/2013Feb/0474.html

[3] http://dev.w3.org/csswg/css-text/#content-language

[4] http://1drv.ms/1r3iYme

/koji

일본인 Koji Ishii 씨가 국한문혼용체 문서를 처리하기 위해 적절한 CSS 구현이 어떤 것인지를 파악하고자 140708 CSS 표준화 워킹그룹 메일링리스트에 보낸 글. Ishii 씨의 글을 전문 번역해 140709 페이스북 노트에 게재했던 내용을 160626 개인 블로그에 옮기고 160805 재편집. 170401 재편집.

Ishii 씨는 웹표준화기구 W3C의 CSS 표준화 워킹그룹 에디터로, 그가 이 사안을 어떻게 파악하느냐에 따라 국한문혼용체 문서의 CSS 구현을 위한 표준이 달라질 수 있었음. 그러나 극소수 CSS 표준 옵저버를 제외하면 한국에서 이 사안에 관심을 가진 사람은 없었음.

231029 추가. 이후 한국을 포함한 각지 전문가들이 Ishii 씨에게 의견을 남겼고, 그는  2014년 8월 초까지 수렴한 의견을 CSS Ruby Layout Module Level 1 이라는 W3C 표준 초안(working draft)에 반영했다고 밝힘. 이 표준 규격 명칭은 이후 CSS Ruby Annotation Layout Module Level 1으로 바뀜. 2022년 12월 31일 최신 개정된 이 규격(https://www.w3.org/TR/2022/WD-css-ruby-1-20221231/)은 현재도 working draft 단계임.