Blog Archive

레이블이 오라클인 게시물을 표시합니다. 모든 게시물 표시
레이블이 오라클인 게시물을 표시합니다. 모든 게시물 표시

2008-06-12

비 라틴 계열 문자를 한꺼번에 엔티티 문자로 바꾸기

우리 회사에서는 오라클 사의 아이러닝(iLearning)이라는 학습 관리 시스템을 쓰고 있다. 그 시스템은 비교적 국제화(globalization)가 잘 되어 있어서 지금까지 영어, 한국어, 스페인어, 프랑스어, 네덜란드어, 독일어로 된 하위 시스템을 구축하는 데에 문제가 거의 없었다. (물론 그냥 데이터는 그 밖에 언어인 중국어, 러시아어 등을 쓰는 데에도 문제가 없었다.) 그런데 이번에 중국어(Simplified Chinese) 기반으로 다시 하위 시스템을 만드는 과정에 여러 곳에서 문제가 발견되었다. 중국어쪽 고객이 많지 않아서인지 아예 중국어쪽 메뉴 타이틀에 대한 사전(dictionary)을 만들어놓지 않은 경우도 꽤 있었다.

그 중에 하나가 로컬에서 만든 CJK(중국어, 일본어, 한국어) 문자가 포함된 유니코드 파일을 서버에 업로드하면 문제가 생겼다. 서버는 분명히 유니코드 인코딩 방식의 하나인 UTF-8로 페이지를 보여주고 있었지만… 처음에는 파일을 잘못 만들었나 여러 가지로 검토해보았으나, 문제는 명백히 서버 쪽에 있었다. 그래서 결국에는 원본 파일에서 CJK 문자를 쓰지 않도록 할 수 밖에 없었는데, CJK 문자를 문자열 단위로 HTML의 엔티티 문자(entity character)로 바꾸어주는 사이트를 이용하다가 이건 아무래도 너무 불편해서, HTML 타이디(Tidy)에 인코딩 방식을 자동으로 바꾸어주는 옵션이 있다는 것을 알았다. CJK 문자가 포함된 문서를 ISO-8859-1로 바꾸면서 CJK 문자를 한꺼번에 엔티티 문자로 바꾸려면 아래와 같이 하면 된다.

tidy --input-encoding utf8 --output-encoding latin1 input_file > output_file

2007-03-03

오라클이 접근성 때문에 고소당했다는 소식을 듣고

현준호님 블로그에서 글로벌 기업인 오라클이 접근성 위배로 고소당했다는 이야기를 읽었습니다. 기사 원본이 어디 나와있을까 한참 찾다보니 현준호님 글 맨 끝에 Oracle sued for failing blind users라는 기사가 연결되어 있었습니다.

우리 회사도 오라클에서 만든 교육 관리 시스템(Learning Management System, LMS)을 비롯해 인적 자원 관리를 온통 오라클로 하고 있기 때문에 관심이 갔습니다. 처음에 오라클 소프트웨어(데이터베이스가 아닌 주로 ERP 류의 소프트웨어)를 접해본 느낌은 아주 복잡하고 난해하다는 것이었습니다. 그리고 정말 사용자 인터페이스에는 전혀 신경을 쓰지 않은 것 아닌가라고 생각하게 됩니다. 그런데 기술적인 배경이 강한 사람들은 오라클을 쓰면서 점점 감탄하게 됩니다. 그 복잡한 세상을 이렇게 일관성있게 관리할 수 있도록 구축해놓은 것에 놀라게 됩니다. 그러나 여전히, 도대체 이걸 누가 쓰라고 만들어 놓은 것인가 다시 묻게 합니다. 일반적인 우리 나라의 학습 관리 시스템이라면 현황 자료를 뽑을 때에 그냥 버튼 하나 누르면 간편하게 엑셀로 다운받아 줍니다. 그런데 오라클에서는 그런 현황 자료 하나 뽑을려면, 일일이 SQL 만들어서 돌리고, 다시 템플릿을 XML이나 XSLT로 만들어서 리포트를 만들어주어야 합니다. 그것도 정말 불편하고 느린 인터페이스로 되어 있지요. 다시 말해, 사용자가 SQL, XML 따위를 모르면 아무 것도 못하게 되어 있습니다. 설사 SQL을 안다고 해도 그 거대한 시스템의 데이터베이스 구조를 기술적으로 파악하고, 또 운영을 해봐야 이게 실제 어떻게 연관된 것인지 자세히 알 수 있기 때문에 현업에서 SQL 만들어서 실제로 써먹으려면 하세월이 걸립니다. 그래도 저는 그런 오라클의 방법이 그냥 단순하게 엑셀 파일에 서식까지 잔뜩 입혀서 다운로드받게 해주는 국산 프로그램들보다 어떤 면에서 낫다고 생각했습니다. 왜냐면 엑셀 형식은 적어도 보편적인 형식이 아닌 특정한 업체의(proprietary) 형식이기 때문입니다.

또 우리 나라 업체의 제품 같으면 웹에서 트리 구조를 표현하기 위해 이상한 액티브 엑스(Active X) 깔아서 클라이언트에서 트리를 펼쳤다 닫았다 할 수 있게 만들었을 것입니다. 실제 그런 경우가 매우 많지요. 모두가 윈도우즈에 인터넷 익스플로러만 쓰고, 자기 컴퓨터에 그런 프로그램 수십 수백 개 깔리는 것 신경 안쓰는 사람들은 그게 훨씬 편한 방법일 지도 모릅니다. 그런데 오라클은 정말 느리고 불편하게 서버에서 트리를 완전히 다시 갱신하는 방법을 쓰고 있었습니다. 사실 요즘 같으면 아마 에이잭스(AJAX)를 써서 훨씬 빠르게 만들 수도 있었겠지요. 그런데 그 불편한 서버 갱신 방식을 채택한 것도 어찌 보면 이유가 있었습니다. 트리를 펼치는 것과 줄이는 것은 물론이고, 트리의 특정 노드로 점프하는 것 등이 모두 키보드로 작동 가능하고, 시각 장애인이 쓸 수 있게 해놓았더군요.

국내 학습 관리 시스템 같으면, 특정 과정을 개설할 때 강사를 지정하는 것 정도는 아무나 쉽게 할 수 있습니다만 오라클 시스템에서 그것은 무지무지하게 어려운 일에 속합니다. 시스템을 아무리 뒤져봐도 강사(instructor)라는 말이 나오지 않습니다. 그것을 한 번 하려면 오라클 권한 부여 모형(Oracle permission model)과 역할(role), 권한(privilege)을 이해해야 하고, 또 사이트(site), 자원(resource), 자원 유형(resource type)이라는 개념과 자원 예약(booking), 확인(confirmation) 개념에 대해서도 알아야 합니다. 한 마디로 한 방에 할 수 있는 것은 아무것도 없습니다. 강사 지정한다고 해서 강사 권한이 바로 부여되는 것도 아니구요.


아무튼 오라클 소프트웨어를 쓰면서 한편으로는 방대하고 어마어마한 구조에 감탄하게 되고, 한편으로는 전혀 무신경한 사용자 인터페이스에 불만을 갖게 됩니다. 오라클의 웹 소프트웨어의 사용성은 제가 써본 바로는 별로입니다. 엔지니어들에게는 많은 자유를 줄 수 있지만 기술과는 거리가 먼 업무 전문가들 입장에서는 꽝이라고 할 수도 있지요. 그런데 웹 인터페이스는 그나마 낫습니다. 재활법 508조가 있기 때문이겠지요. 적어도 형식적으로는 대체 텍스트, 키보드 접근성 등을 대부분 지켜서 나옵니다. 그렇다고 웹 표준을 지키지는 않았습니다. 웹에 있어서는 아주 구닥다리 코드들을 사용하고 있지요. 그런데 시각적으로 보이지 않는 사람이 과연 이렇게 복잡한 시스템을 머릿속에 담아서 직렬적으로 처리할 수 있을까를 생각해보니, 상당히 무리이겠다는 느낌이 들었습니다. 그래도 우리 나라에서 만든 웹처럼 다른 브라우저에서는 아예 화면이 안 뜨고, 화면 레이아웃이 깨지고, 작동도 안 하고 그런 일은 없습니다. 그런데 이번에 고소를 당한 소프트웨어는 아마 자바 애플릿 기반의 소프트웨어쪽이 대상이 된 것 같습니다. 오라클이 만든 자바 애플리케이션을 써보면 정말 가관입니다. 처음 보면 도대체 어디에서부터 무엇을 하라는 것인지 감이 오질 않습니다. 그리고 자바 애플리케이션들은 접근성을 거의 고려하지 않은 것 같습니다. 사실 자바의 접근성이 아주 나쁜 것은 아닙니다. 100% 자바로만 만든 넷지(NETg)의 이러닝(e-learning) 콘텐츠나 스킬소프트의 온라인 콘텐츠는 접근성이 아주 좋습니다. 우리 나라 이러닝 콘텐츠들의 경우는 기본적인 웹 표준과 웹 접근성, 상호 운용성, 최소한의 사용성과는 상당히 거리가 멀고 오로지 서로 다른 학습 시스템간의 상호 운용성을 보장해준다는 스콤(SCORM)에만 신경을 쓰고 있지요. 기본적인 데이터로서 가치가 낮고 재활용이 거의 불가능한 콘텐츠를 아무리 스콤 표준에 맞추어봤자 무슨 소용이 있는지 모르겠습니다만.


오라클은 아주 거대한 회사입니다. 그래서 제 주관적인 느낌으로는 움직임도 상당히 느리더군요. 그리고 워낙 제품군이 많고 방대하기 때문에 고액 연봉을 받는 오라클의 전문 컨설턴트들도 자기가 전문성을 가진 특정 분야 제품이 아니면 뭐가 어떻게 돌아가는지 자세히 모르는 것 같습니다. 재활법 508조 때문에 오라클은 형식적으로만 접근성을 지켜왔던 것이 아닌가 추측됩니다. 그나마 자바 기반의 애플리케이션에는 신경을 덜 써왔던 것이고. 이제 그런 형식적인 접근성을 지켰다고 해도, 실제 장애인 사용자의 "원활한" 사용이 "사실상" 불가능하다면 아무 소용이 없다는 것을 이번 사건이 드러내줄 것이라고 생각합니다. 이번 사건에서 장애인 사용자가 인사 정보를 열람하기 위해 항상 비장애인 사용자의 도움을 받아야 해서, 자신의 개인 정보를 남에게 다 노출할 수 밖에 없는 심각한 문제를 참아 왔다고 합니다. 그래서 접근성을 지키는 것은 어찌 보면 매우 어려운 일입니다. 겉으로 드러나는 (그리고 단순해보이는) 접근성 규칙들 이면에 숨어있는 사용자 편의성(usability)이라는 측면이 너무 복잡하게 얽혀 있기 때문입니다. 아무튼 사용자 편의성, 접근성 문제에 상대적으로 둔감함을 보여왔던 오라클에 어떤 변화가 생기는 계기가 되었으면 좋겠습니다.