Camille ‘windoz’ Roux 씨가 0.8.1 버전까지 개발하였으며, David ‘d_rol’ Soulayrol 씨가 이를 이어받아 계속 개발하고 있습니다.

독자 규칙과 Uno 규칙이 존재하며, Uno의 규칙은 Uno 메뉴얼을 따릅니다.

독자 규칙으로서 Draw Two 카드와 Wild Draw Four 카드를 쌓을 수 있습니다. 플레이어가 동일한 Draw 카드를 내지 못할 경우, 쌓여 있는 Draw 카드의 수 많큼 카드를 받게 됩니다.

카드 모양이 맘에 안드신다면 DUO에서 UNO 카드 가지고 놀기 포스트를 읽어주세요.

이 프로젝트에 대한 자세한 내용은 Duo, A crazy eight card game에서 볼 수 있습니다.

Windows용 실행 파일이 들어 있는0.8.1 버전은 소스포지 Duo, a Crazy Eight Card Game에서 받을 수 있습니다.

Download DUO 0.10 Windows Installer

전체적으로 보면, 이번 베타테스트는 아쉬움이 남습니다. 한컴오피스 2010은 아직CBT(비공개 베타테스트) 단계입니다. 이는 어플리케이션의 오류를 잡고, 새로운 기능을 가다듬을 때이며. 베타테스트 자체도 그러한 부분이 중점이 되어야 한다고 생각합니다.

하지만 이번 베타테스트의 기본적인 미션은 사용기 5건을 블로그에 포스팅하는 것이었습니다. 베타테스터 들이 한컴오피스를 홍보해 주기를 바랐던 것일까요? 베타테스터는 회사를 위하여 제품의 QA를 자발적으로 요청한 사람입니다. 물론 새로운 제품을 남들보다 먼저 써보기를 원하는 사람일지도 모르지요. 그렇더라도 홍보는 이와는 별도로 진행되어야 한다고 생각합니다.

한컴오피스에 실망하게 된 두번째 이유는 어플리케이션 자체의 품질입니다. 저는 오늘까지 총 24개의 문제점을 보고하였습니다. 이 중 제가 ‘이 부분에는 분명 문제가 있을 것이다.’라고 생각하고 찾은 문제점이 11개 입니다. 적어도 제가 생각했던 것의 반절 이상에 문제가 있었습니다.

최소한 위와 같은 문제들은 자체의 QA 과정을 통해서 처리되어야 한다고 생각합니다. 베타테스트는 다양한 실행환경에서의 안정성을 확보하는 것이 주 목적이지, 구현될 기능들 자체의 정상 동작 여부를 봐야하는 것은 아니겠지요. 물론 CBT 인 만큼 기능의 문제점을 잡는 것도 중요하겠지만, 그 구현도는 기대 이하였습니다.

한컴오피스 제품에 있어서 가장 불만인점은 Windows에서 제공해주는리소스를 사용하지 않고, 많은 부분을 직접 만들어 쓴다는 것입니다. 가장 간단한 예로 파일 읽기 다이얼로그를 볼 수 있습니다.

아래는 Windows 7와 한글 2010의 파일읽기 다이얼로그입니다.

한컴오피스의 다이얼로그는 Windows 와 기본적인 구성이 다르기 때문에 한컴오피스의 UI를 익혀야합니다. 특히, 파일 관련 다이얼로그의 상당수는 기존 Windows의 구성을 흉내낸 부분이 많습니다. 그렇기 때문에 Windows가 업데이트 되었을 때, 새기능의 UI를 접하고 이를 환영한 사람에게, 한컴오피스의 다이얼로그는 매우 촌스럽게 보입니다.

외적인 면 외에도 기능적인 면에도 크게 문제가 있습니다. 1M가 넘는 고해상도 사진 파일 100개가 있는 폴더에서 썸네일을 표시할 때 걸리는 시간이 Windows의 다이얼로그는 3초 였습니다만, 한컴오피스의 경우 26초가 걸렸습니다. 게다가 26초 내내 CPU의 점유율이 50%이기 때문에(코어 1개의 점유율 100%) 사진 하나를 첨부하기 위해서 26초 동안 컴퓨터 작업을 하나도 하지 못하였습니다. 썸네일에 대한 저장도 없습니다. Windows는 썸네일을 저장하기 때문에 해당 폴더에 다시 들어가면 1초도 기다릴 필요없이 화면에 모든 썸네일이 표시됩니다. 하지만 한컴오피스는? 다시 26초 동안 아무것도 하지 못하도 기다려야합니다.

독자적인 UI이기 때문에, 사용자가 지정한 시스템 테마도 적용되지 않으며, 이미지 썸네일이 저장된다고 하더라도 윈도우즈와는 독자적으로 갈 수 밖에 없을 것입니다.

과연 이러한 독자적인 체계를 한글과컴퓨터 사에서 계속 가져가는 이유? 솔직히 말해서 모르겠습니다. 기술적 우위? 그런건 없다고 생각합니다. 오히려 정체된 한컴오피스의 개발속도는 Windows의 개발속도에만 뒤쳐지고 있지요. 어떠한 이유로 이러한 방식으로 개발했는지에 대해서는 일부 이해가 되는 부분은 있습니다만, 더 발전하기 위해서는 이제는 과거의 모습을 버려야 할 때이지 않을까요?

하지만 슬라이드 2010을 쓰기에는 아직은 부족한 면이 없지 않은 것 같습니다. 가장 부족한 면은 사용한 글꼴을 함께 저장할 수있는 기능이 없다는 것입니다. 슬라이드를 작성한 컴퓨터와 프레젠테이션을 하는 컴퓨터에 차이가 있는 경우가 많은데, 이러한 경우에는 해당 컴퓨터에 필요한 글꼴이 존재하는지 확인하기 어렵기 때문에, 언제나 사용한 글꼴을 저장하도록 합니다.

또한, 슬라이드쇼를 위한 파일 형식이 존재하지 않습니다. 한글 2010의 경우 배포용 문서가 존재하나, 동일한 오피스에 포함되어 있는 슬라이드는 배포용 형식이나, 슬라이드쇼 형식의 파일이 없기 때문에, 언제나 슬라이드의 원본을 배포해야하는 문제가 발생합니다. 읽기용 암호와 수정용 암호를 따로 설정하는 기능도 없습니다. 슬라이드는 배포가 많이 되는 문서이니, 배포를 쉽고 편하게 할 수 있는 기능이 필요하다고 생각합니다.

PowerPoint를 쓰기는 하지만 애니메이션을 복잡하게 넣거나 하지는 않지 않고, 매우 간단하게 만들기 때문에 슬라이드를 이용해 제 스타일로 문서를 작성하는 것에는 큰 불편은 없었습니다. 몇가지 버그가 아직은 남아있는데, 이러한 부분은 정식 버전이 출시되면 해결될 문제라고 생각합니다.

2000년 무렵에 한글과컴퓨터 사가 많은 비난을 받았던  원인입니다. 달라진 어플리케이션, 달라진 파일 형식. 한글 97에 익숙한 사람에게 새로운 방식은 쉽게 받아들어지지 않았습니다.

하지만 한글 97이 편했음에도, 한글 워디안을 크게 반겼으며, 워디안을 쉽게 쓰기 위해 새로운 기능을 많이 연구해 보았죠.

수많은 새로운 기능 중에서도 ‘유니코드’를 지원한다는 것은, 다국어 문자와 언어 시스템에 많은 관심을 갖는 저에게는 큰 선물이었으니까요.

한글이 처음 윈도우로 등장하였을 때 부터, 한글은 Windows에서 제공하는 API나 툴킷을 사용하기 보다는, 필요한 것을 직접 구현하였습니다. 97 버전을 벗어난 워디안에서도 이러한 경향은계속 되었으며, UI와 유니코드 지원 부분이 모두 독자적인 코드로 동작하였습니다.

Windows 9x와 초창기의 Windows XP까지, Windows는 유니코드를 제대로 처리하지 못하였습니다. 독자적인 한글의 유니코드 처리 시스템은 윈도우즈에서 지원하지 않는 스크립트 등에 대해서도 지원하며, 한글의 글로벌 화를 위해 많은 노력을 기울였다고 생객합니다.

그리고 시간은 흘러흘러 2010을 앞두고 있는 지금. Microsoft는 자사의 유니코드 처리시스템 크게 향상 시켰으며, 많은 부분에서 한글보다 뛰어나게 처리해 주고 있습니다. 하지만 한글 2010 CBT는 여전히 자신만의 유니코드 처리 시스템을 고집하면서도, 스스로의 발전을 도모하지 않는 것 같스니다.

이건 한글과컴퓨터 사의 정책 문제일 수도 있습니다.

Q: 저장 다이얼로그에 다국어 문자를 붙어넣기하면 글자가 ?로 변경되어 저장할 수 없습니다.

A: 이전 버전에서 다국어 문자가 들어간 파일을 읽을 경우 문제가 생겨서, 다국어를 저장할 수 없도록 한 것입니다.(설계대로)

이제 2010년입니다. Windows의 기본 프로그램은 모두 유니코드 파일명을 정상적으로 처리하며, 최근에 제작된 많은 응용 프로그램도 유니코드 파일을 읽고 쓰는데 문제가 없습니다.

한글에서 유니코드 파일명을 입력할 수 없어도, 탐색기를 이용하면 유니코드가 들어가게 파일명을 바꿀 수가 있지요. 결국, 한글에서 저장 방식을 제한한다고 해결되는 문제가 아닙니다. 과거의 버전을 버리더라도 해결해야 문제는 해결해야하며, 과거의 문제는 과거 프로그램의 패치를 통해서 해결해야 할 것이라고 생각합니다.

또 다른 문제는 정렬에서 유니코드를 전혀 고려하지 않는다는 것입니다.

왼쪽은 간단한 단어들에 대해, 한글 2010에서 가나다 정렬을 한 것입니다.

간단히 살펴봐도 기호-로마자-기호-로마자-가나-한글(한자)-로마자로 매우 복잡하게 정렬되어 있습니다.

유니코드와 같이 한 개의 문자에 대해서 여러 자형(대문자 A와, 강세붙은 Á, 전각문자Ａ)이 존재하는 경우에는, 문자를 정렬할 때 이를 동일한 객체 또는 인접한 객체로 인식해야 합니다. 하지만 이러한 것은 한글이나, 가나 일부에만 적용되어 있을 뿐, 오히려 가장 흔히 사용되는 로마자에 대해서도 지원하지 않고 있습니다.

왼쪽의 결과를 보면, 대체적으로 유니코드의 코드 순서에 따라 정렬된 것으로 보이며, 일부 특수한 경우에만 사전을 사용한 것 같습니다. 정식 버전이 출시되기 전에는 정렬 사전을 더 추가해야 할 필요성이 있다고 생각합니다.

다음은 한글 자모의 문제입니다. 유니코드에서는 Hangul Jamo 문자 영역이 있으며, 이 문자 영역의 낱글자를 이용하여 한글 syllables를 표현할 수 있습니다. 한글에서도 Hangul Jamo의 문자를 입력하면 syllables가 출력되도록 되어있습니다. 하지만 글꼴 및 크기 표현에 있어서는 아직까지는 문제가 있습니다.

크기는 모든 글꼴에서 지정한 크기보다 크게 출력됩니다. 모양은 일부 글꼴에서만 적용되는데, 적용되는 글꼴의 수는 함초롱돋움 및 함초롱바탕 밖에 없습니다.

간단하게 한글 2010의 유니코드 지원에 대해 적어 보았습니다. 비록 아직까지는 문제가 많지만 한글 2010 버전에서는 이러한 문제가 해결되기를 바랍니다.

스프레트시트 프로그램은 처음부터 Excel이었고, 지금도 Excel만을 사용합니다. VBA를 사용하지 않기 때문에, Excel을 써야할 필요는 없지만, 어째서인지 다른 프로그램을 쓰는 것은 거부감이 느껴지더군요.

물론 넥셀 초창기 버전에서 작성해본 첫 문서부터 날려먹은 기억이 지대한 영향을 주었겠지만요.

넥셀 역시 한글과 같이 메뉴+리본 메뉴+도구모음이라는 동일한 UI를 사용합니다.

넥셀을 실행했을 때 가장 눈에 띄는 것은 셀강조입니다. 단순히 선택한 셀만이 강조되는 것이 아니라, 선택한 셀의 모든 열과 행의 셀들이 살짝 진한 하늘색으로 표시됩니다. 많은 데이터가 있는 Excel 파일을 보다보면, 어느 데이터가 같은 줄에 있는지 확인하기 어려울 때가 가끔 있는데, 넥셀에서는 그러한 걱정은 할 필요가 없을 것 같네요.

그러나… 그래프를 하나 만들자 마자 실망을 했습니다. 아래는 날짜별 감자와 고구마의 가격변화에 대한 간단한 자료이며, 아래를 블록잡아서 분산형으로 표를 생성하였습니다.

고구마가 표시도 안되고, 감자의 캡션도 잘못 나오고, 표의 여백도 어울리지 않는 등 여전히 그래프 부분은 개선할 여지가 많아 보입니다. 그래프 기능을 많이 쓰는데, Nexcel을 써보는 것은 좀 더 뒤로 미루어야 할 것 같습니다.

사용할 수 있는 수식은 Excel과 큰 차이는 없는 것 같습니다. 하지만 수식 입력 창에서 입력한 셀과 실제 셀의 색을 일치하여 보여주거나, 일치하는 ()의 색을 같은 색으로 칠하여, 수식을 더 편하게 입력하도록 도와주는 Excel의 기능에 비하면 많이 불편합니다.

이번 버전에서는 기존의 메뉴+도구모음에서 Microsoft Office 2007과 비슷한 리본 형 메뉴로 바뀌었습니다.

Office 2007의 경우 리본 메뉴만 있었는데, 한글 2010은 리본메뉴+메뉴+도구모음이라는 약간은 색다른 모습을 보여줍니다.

그리고 탭과 메뉴를 잘 융합하여서, 리본 메뉴에서 선택하기 어려운 부분은 탭에서 선택할 수 있도록 도와주고, 또, 기존 메뉴 구조에 익숙한 사람이 더 편하게 쓸 수 있도록 되었습니다.

관건은 문서를 편집할 때, 리본 메뉴와 도구모음를 얼마나 편하게 쓸 수 있느냐라고 생각합니다.

Word 2007을 사용할 때 불편한 점은, 현재의 서식을 편집할 때나 확인할 때에 언제나 홈으로 이동해야하는 불편이 있었습니다. 하지만 한글 2010의 경우 도구모음을 통해 언제나 바꿀 수 있기 때문에 이러한 불편은 조금 줄어듭니다.

하지만 아직은 리본 메뉴가 명확하게 구분되었다고는 생각하지 않습니다. 오히려 도구 모음과 메뉴 때문에, 리본 메뉴의 특징을 살리지 못한 점도 많이 눈에 띕니다.

일단, 탭의 순서가 기존의 메뉴와 유사합니다. 일반적으로 문서를 작성할 때에는 서식 및 입력을 가장 많이 사용할 것입니다. 두 탭이 탭의 앞부분에 위치하는 것이 더 좋았을 것이라고 생각합니다.

Word 2007과 차별화가 되게, 편집화면을 주로 사용하는 것으로 유도하려는 것 같습니다. 하지만 도구모음에서 지원하는 서식 편집 기능이 부족하기 때문에, 서식 메뉴가 주 메뉴가 되는 것이 낫다고 생각합니다.

한글 2005의 기능과 비교할 때, 뚜렸하게 새로운 기능은 눈에 띄지 않습니다. 기능 보다는 보안 탭이 등장하다보니, 보안이 매우 강화된 것으로 보입니다. 개인 정보 보호 기능 중 가장 눈에 띄는 것은 찾아서 보호 기능입니다. 주민번호나 전화번호 같은 개인 정보를 자동으로 찾아서 *와 같은 문자로 바꾸어주는 기능인데, 문서를 배포할 때 매우 유용하게 쓸 수 있을 것 같습니다.

2007을 써보지 않아서 이번에 구현된 것인지는 명학하게 모르겠습니다만, 투명한 PNG가 드디어 투명하게 표시됩니다. 각종 도형도 투명도를 지정할 수 있네요. 제가 한글을 버리고 Word로 넘어간 가장 큰 이유는 투명화를 제대로 지원하지 않기 때문이었습니다. 이제 다시 한글로 돌아올 때가 된 것일까요?

하지만 넘어가지 못하는 큰 단점이 있으니 그것은 바로 유니코드 지원입니다. 한글 97에서 가장 불만스러운 부분이었고, 그래서 한글 워디안을 대대적으로 환영하게 되었던 부분이기도 하지요. 워디안이 처음 등장한지도 10년이 되가는 것 같으나, 여전히 한글의 유니코드 지원은 단어 수준을 벗어나지 못하는 것 같습니다.

Microsoft는 유니코드를 처리하기 위한 Uniscribe Unicode script processor를 지속적으로 업데이트하고 있으며, 각종 스크립트 언어 처리 및 형식 지정 문자들에 대한 지원이 많이 향상되었습니다. 한글은 유니코드 처리 수준이 낮으면서도, Uniscribe processor를 사용하지 않기 때문에, 워드패드보다도 안좋은 출력결과를 보여줍니다. 독자적인 개발과 기본 라이브러리의 사용에 있어서 현명한 선택이 필요한 시점이라고 생각합니다.

도스를 쓸 때 부터 윈도우즈로 넘어와서까지 한글과 컴퓨터 사의 한글 시리즈는 오랫동안 애용해왔던 프로그램이었습니다. 그렇지만 정품으로 가지고 있는 것은 한컴오피스 2007 뿐으로, 한글과 컴퓨터 사에 피해를 주는 고객이었을지도요.

한컴오피스 2010 베타테스트는 일찍 시작되었지만, 개인적인 사정으로 이제서야 미션을 수행하게 되었습니다. 첫 경험이니, 프로그램을 설치하고 처음으로 실행하는 순간까지만 살펴볼게요.

설치 화면 중에 가장 눈에 띄는 것은 설치 장소입니다. 음… 시작부터 불만이 나오는 군요.

“C:\HNC”

한글을 예전부터 써왔던 사람이라면 매우 친숙한 폴더입니다. 하지만 Windows 7까지 나오는 이 시점에 있어서, 위 장소를 고수하는 이유를 이해할 수 없습니다. Windows 뿐만 아니라, Unix나 Linux 등 많은 운영체제에서는 시스템을 효율적으로 관리하기 위하여 목적별로 폴더를 구분하여 사용합니다.

Windows에는 어플리케이션을 설차하는 폴더로 Program Files를 제공합니다.

“C:\Program Files\HNC”

매번 설치할 때마다 설치 주소를 위와 같이 바꿉니다. Windows에서 동작하는 프로그램이면, 제대로된 자기자리로 돌아갔으면 합니다.

설치에 있어서는 기존과 큰 차이가 없습니다. 정식버전에서 설치화면이 크게 바뀔 것이라고 예상되므로, 이에 대해서는 자세히 적지 않겠어요.

설치가 완료되면, 바탕화면에 아이콘이 설치됩니다. 옆에는 사이좋은 친구 Word씨가 있네요. 확대 가능한 아이콘은 Vista 부터 지원이 된 기능인데, 2010년을 목표로 출시를 준비 중인 프로그램에서 아직도 이런 기능을 지원하지 않았다는 것에 살짝 실망하게 되네요.

물론 이런 것을 해결하기 위한 베타테스트라고 생각합니다. 사용자의 의견을 받아 많은 부분을 수정하고 있는 것도 기대됩니다.

지금까지 이러한 제품을 쓰지 못한 것은 보급형이나 중급형의 저렴한 것만 구입해서 일지도 모른다. 그래도 지금까지 써온 제품들은 최소한의 납득할 만한 점들이 몇 가지 있었다.

아이리버의 E100에게 최악의 UI라는 평가를 내리게 된 것, 물론 이 제품이 내가 요구하는 인터페이스를 충족시키지 못했다는 것에 가장 큰 원인이다. 하지만 플래시 기반의 휴대용 MP3 재생기를 6년간 만들어온 회사로서의 디자인 철학을 E100에서는 전혀 느낄 수 없다는 것도 큰 이유 중에 하나이다.

E100의 UI에는 아래와 같은 문제가 있다고 생각한다.

1. 액정이 꺼져있을 때에는 버튼을 눌러도 기능이 실행되지 않는다.

E100은 액정이 꺼져있을 때 버튼을 누르면 액정을 켤 뿐, 액정에 할당된 다양한 기능은 실행하지 않는다.

터치 스크린이 입력장치인 제품의 경우 액정을 켜는 것이 당연한 것이겠지만, 버튼이 입력장치인 E100에서는 이러한 동작은 잘못된 것이라고 본다.

E100에는 ‘볼륨 조절 키, 상하좌우 키, 선택 키, 전원 키’ 등 총 8개의 버튼이 있다. 상황에 따라 버튼의 기능이 달라지만, E100의 주 기능인 음악 재생화면에서는 ‘볼륨 조절, 재생/멈춤, 다음/이전 곡 이동’ 등과 같은 기능으로 버튼이 동작한다.

E100의 여러 기능 중에서 가장 많이 쓰이는 것은 물론 음악 재생일 것이며, 또한, 화면이 꺼진 상태에서도 음악 재생이 되고 있을 가능성이 많다.(적어도 동영상을 보거나, 사진을 보거나, 글을 읽고 있었다면 액정은 커져있을 것이다.)

제품의 버튼을 누른다는 것은 원하는 기능을 실행한다는 것이다. 위에서 언급한 것처럼 재생 화면에서 버튼으로 입력 받는 기능은 고정되어 있기 때문에, 한 번의 버튼을 누르는 것으로 원하는 기능을 실행되는 것이 매우 자연스러운 동작이다.

또한, 버튼을 누르기 전에 화면을 확인해야 할 필요도 없다. 버튼을 누르면 소리에 변화가 있을 것이다. 의도하지 않았던 변화가 있거나, 변화가 없을 경우에만 액정을 확인함으로써 잘못된 조작을 복구할 수 있다.

물론, 재생화면이 보거나 액정만 켜야할 때가 있다. 이 때는 가볍게 전원 버튼을 한 번 눌러주면 된다. 구지 8개의 버튼 모두 액정을 켜는 버튼으로 만들 필요가 없는 것이다.

이것에 대해 가볍게 버튼을 두 번 누르면 된다라는 반박도 있다. 하지만 E100의 UI가 잘못되었다라고 말하는 것은 바로 이 부분과 관련되어 있다.

위에서 언급한 것처럼 휴대용 음악 재생기에서 버튼을 눌렀을 때 액정을 반드시 확인해야할 필요는 없다. 그렇지만 E100은 언제나 화면을 확인하고 버튼을 누르도록 조장을 한다.

음악을 끄기 위해서는 정지 버튼을 누른다. E100은 습관적으로 정지 버튼을 두 번 누르도록 사용자를 학습시킨다. 하지만 만약 이 때 액정이 켜져 있다면 음악은 다시 재생될 것이다.

이러한 오류를 여러번 겪게 되면, 사용자는 화면을 확인하는 습관을 갖게 된다. 결국 나도 모르게 불필요한 동작을 하게 되는 것이다.

2. 현재 재생화면으로 한번에 돌아갈 수 있는 기능이 없다.

음악을 들으면서, 설정을 고치거나 파일 관리를 하는 등 여러 가지 동작을 할 수 있다.

이런 것을 모두 완료했을 때, 가장 보고 싶은 것은 음악 재생 화면이다. 하지만 E100에서 재생화면으로 돌아가기 위해서는 복잡한 절차가 필요하다.

하나는 왼쪽 버튼을 길게 눌러 메인 메뉴로 나간 뒤, 위쪽 버튼을 길게 누르는 것이며,
또 하나는 왼쪽 버튼 여러번->좌우 버튼 여러번->확인 버튼 두 번을 누른 것이다.

위 두 방법은 모두 문제가 있다. 첫 번째 방법은 E100에서 길게 누르는 동작을 인식해야하기 때문에 메인 메뉴로 나가는데 약 2초, 재생 화면으로 들어가는데 약 3초가 걸리며 빨라도 5초 아니면 그 이상의 시간이 걸린다.

두 번째 방법으로 빠르게 누르면 첫 번째 방법보다 빠르게 재생화면으로 갈 수 있지만, 메뉴마다 눌러야 하는 버튼의 수가 다르기 때문에 이 것 역시 3초 이상의 시간이 걸리다.

간단하게 버튼 하나를 클릭하는 것으로 재생화면(동영상 재생, 음악 재생, 파일 읽기 등)이 뜨게 한다면, 훨씬 편하지 않을까?

E100에는 할일 없이 놀고 있는 버튼이 있다. 제품의 오른쪽에 달려있는 전원 버튼은 ‘길게 누를 때’ 켜고 끄는 것 말고는 하는 일도 없다. 화면이 꺼져있을 때 짧게 한번 누르면 화면이 켜진다. 하지만 화면이 켜져있을 때에는 버튼을 짧게 눌러도 아무런 동작을 하지 않는다.

전원 버튼에 그런 기능을 넣으면 메뉴를 돌아다니다 오동작을 할 수 있다는 반박도 있다. 하지만 그러한 제품이라면 하드웨어 설계부터가 잘못된 것이 아닐까?

3. 잠금 모드에서 어떤 버튼이 눌려도 화면이 켜진다.

잠금 모드에서 어떤 버튼을 눌러도 화면이 켜진다. 잠금 모드를 쓰는 것은 고의적으로 키가 눌릴일이 많기 때문이다. 그렇다면 언제나 액정을 켜는 것이 좋은 방법일까? E100에서 지정할 수 있는 조명 시간의 폭이 좁기 때문에(5초, 10초, 1분, 5분, 30분), 1분으로 조명 시간을 해 둔다. 바지 주머니에 넣어둘 경우 버튼이 잘못 눌릴 경우가 많은데, 이 때 불필요한 전원 소모가 생길 것이다.

이 글에서 계속 언급이 되고 있는데, 전원 버튼을 가볍게 누르는 것만 액정을 켜는 것으로 한다면 버튼이 잘 못 눌려 액정이 켜져 있는 일이 줄어들 것이다. 면적이 넓은 상하보다 면적이 좁은 좌우의 버튼이 잘못 눌릴 가능성도 더 적을 것이다.

4. 곡의 정보를 전부 표시해 주지 않는다.

E100에서는 음악을 재생할 때 세 줄에 음악의 정보를 표시해 준다. 위에서부터 음반/가수/곡 제목이다. 곡 제목은 길이가 길 경우 스크롤이 된다.

하지만 음반 이름과 가수 이름의 경우 그 길이가 길면 중간에 잘라서 …을 붙인다. 스크롤을 할 것인지를 설정할 수 조차도 없다.

MP3 재생기가 높은 해상도/큰 크기의 액정을 가지는 것은 사진이나 동영상을 보여주기 위함도 있지만, 가장 중요한 것은 ‘재생중인 곡의 정보를 보기 좋게 보여주기 위한 것’이라고 생각한다.

QVGA의 해상도를 가지고 있으면서 과거 도츠 액정보다도 보여주는 정보가 더 적다면 심각한 문제가 있는 것 아닐까? 앨범 이름/가수의 길이가 긴 것에는 그 이유가 있다고 생각한다. 이것은 줄여서 표시할 것이 아니라, 제대로 표하는 것이 ‘기본’이 되어야 한다고 본다.

5. 볼륨은 언제나 보여주고, 볼륨 설정창은 더 작게…

음악을 재생할 때 볼륨을 조절하면, 볼륨 조절창이 화면을 가린다. 음악을 재생할 때에는 앨범 아트의 절반, 앨범 이름, 가수 이름이 가려진다.

볼륨 조절창은 마지막으로 볼륨 키가 눌린뒤 약 4초 뒤에 사라지기 때문에, 볼륨을 조절하고 앨범 정보를 보기 위해서는 4초를 기다리거나 다른 키를 눌러야 한다. 초대형 조절창을 쓰지 않아도 현재 볼륨을 확인하거나 바꾸는 데에 문제가 없다.

이 때 눌러야하는 다른 키도 ‘좌, 우, 재생 키’로 상하 키를 누르면 재생되는 곡이 바뀐다. 계속 주장하고 있지만, 다른 키는 원래 기능을 하도록 하고, 전원 키를 누르는 것으로 창을 없앤다면 일관성 있는 인터페이스가 가능할 것이다.

그리고 현재 볼륨을 화면에 표시해 주자. 현재 볼륨을 확인하기 위해 매번 볼륨키를 누를 필요가(물론 화면은 켜야겠지만) 없어진다. 보다시피 남는 공간도 많다. 여백의 미를 너무 좋아하는 거 아냐?

a. 하드웨어 문제도 하나 지적하자면…

MicroSD 슬롯의 설계가 잘못되었다. MicroSD를 사용하는 장치를 많이 사용하였지만, 슬롯 덮개를 누를 때, MicroSD가 같이 눌리는 것은 E100이 처음이다. 슬롯 덮게는 MicroSD를 보호하기 위한 것이데, 덮개를 닫다가 MicroSD가 눌려서 빠질 것을 걱정해서, 덮개를 살짝 만 걸쳐두어야 한다.

회사의 이미지는 로우엔드 제품…

회사의 이미지를 결정하는 제품은 하이엔드 제품이 아니고, 많은 사람에게 팔리는 로우엔드 제품이라고 생각한다. 그런 면에서 E100은 매우 실망스러운 기기였고, 아이리버에 대한 부정적인 이미지를 씻기는커녕, 더 확실하게 만들어준 기기였던 것 같다.

디스켓의 구조를 배울 때에는 용량이 1440×1024B인 3.5인치 디스켓이 1.44MB(=1.44×1000×1024B)로 불렸다는 것을 알게되어 더더욱 혼란스러웠습니다.

5.25인치 디스켓의 경우 1.2MB로 불렸는데, 약 1.17×1024×1024바이트로 소수점 아래 두번째에서 반올림하면 1.2가 되기 때문에 갸우뚱 하면서도 큰 의심은 하지 않았습니다. 물론 왜 얘는 소수점 아래로 한자리만 적은 걸까라는 고민은 했지만요.

이러한 혼란 속에서 아마도 ‘시험 점수를 위해’ kB=1024B, MB=1024²B이라고 외웠을 것입니다. 그리고 의심하지 않고 수 년간 써왔고, 당연히 그래야 하는 것으로 생각했습니다. 하지만 몇 년 전 복사할 파일을 선택하면서, 접두어가 2의 배수를 나타내는 정보통신 계열의 용량의 표기법에 대해 의문을 가지게 되었습니다.

저는 아래의 이유로  1kB를 1024B로 계산하는 현재의 방법을 버리고, 이를 1KiB로 표기하는 방법으로 강력하게 바뀌어야 하다고 생각합니다.

1. SI(표준 도량형)에 맞지 않고, 정보 교환에 혼란을 줄 수 있습니다.

표준 도량형에서는 k, M, G 등과 같은 SI 접두어를 10의 배수에만 쓰도록 요구합니다. 또한 ISO나 IEC에서 제정한 표준에서도 이 접두어를 모두 10의 배수를 의미하는 것으로 정의하였습니다. 그렇게 때문에 이를 2의 배수일 때도 사용할 경우에는 1000을 의미하는지 아니면 1024를 의미하는지에 대한 혼란이 올 수 있습니다.

These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits). The IEC has adopted prefixes for binary powers in the international standard IEC 60027-2: 2005, third edition, Letter symbols to be used in electrical technology – Part 2: Telecommunications and electronics. Although these prefixes are not part of the SI, they should be used in the field of information technology to avoid the incorrect usage of the SI prefixes. (출처: SI brochure)

SI 접두어는 10의 배수를 나타낼 때에만 사용해야 합니다. 2의 배수를 나타낼 때는 사용할 수 없습니다(예를 들면, 1킬로비트는 1024비트가 아닌 1000비트를 나타냅니다). IEC는 국제 표준 IEC 60027-2: 2005, 제3판, 전기기술분야에 사용되는 기호 – 제2부: 통신 및 전자에서 이진 배수에 대한 접두어를 채택하였습니다. 이 접두어는 표준 도량형의 부분은 아니지만 정보 분야에서, 잘못된 SI 접두어의 사용을 피하기 위해, 사용되어야 합니다.

바이트 또는 비트 일 경우에만 k 등을 이진 배수로 보면 되지 않느냐는 의견도 있지만, 동일하게 바이트와 비트를 사용하는 통신 영역는 십진 배수의 의미로 사용될 때가 많기 때문에 혼란은 피할 수 없습니다.

(예를 들면 10MBps로 데이터을 전송하는 것10×10⁶과 파일을 복사하는 것10×2²⁰ 처럼 같은 기호가 다른 값을 나타낼 수도 있습니다.)

표준 도량형이 있는 것은 값을 정확하게 표현하고, 이를 정확하게 전달하는 데 목적이 있습니다. 비록 관습적으로 사용되었고, (이 쪽 분야를 해온 사람에게는) 무리없이 통용된다고 하더라도, 잘못된 전달의 가능성이 있다는 것 자체가 표기법의 문제이기 때문에 강력하게 바꾸어 나가야 한다고 봅니다.

2. 불필요한 이진 배수에 의한 계산을 요구합니다.

지금 제 하드디스크에는 용량이 361 961 472B인 파일이 한 개 있습니다. 이 파일의 용량은 kB로, MB로, GB로 각각 어떻게 될까요?

1GB의 하드에 100MB 파일을 4개 넣으면 남은 용량은 몇 GB일까요? 거기에 100KB파일이 100개 더 복사한다면 남은 용량은 몇 KB가 될까요?

827kB와 0.808MB 중 어느 쪽이 더 큰 용량을 나타낼까요?

컴퓨터를 쓰다보면 위와 같은 문제를 접하게 될 때가 있습니다. 하지만 저는 이러한 문제를 전혀 머리로는 풀 수 없습니다. 언제나 계산기를 실행하게 1024를 곱하거나 나누어 줌으로써 확인을 합니다. 많은 사람들 역시 그러할 것이라고 생각합니다.

그런데 파일 용량을 이진 배수로 계산하여 표시해 줄 필요가 있는 것일까요? EE에 들어와서 CS를 배우고 있지만, 전 컴퓨터를 처음 접했을 때 부터 지금까지 단 한번도 파일 용량을 1024의 배수로 표현해야 할 필요성을 느끼지 못했습니다. 오히려 갈 수록 의문만 더 생깁니다.

파일 용량은 이진 배수에 의해 할당되지 않습니다. 하드디스크의 할당 단위가 2의 배수이기는 대용량의 저장매체를 사용하고, 한 개의 파일의 수백개 이상의 할당 단위를 사용하는 현대에 와서는 할당 용량이 갖는 숫자 적인 의미는 많이 퇴색되었죠. 파일의 할당 단위를 1개라도 줄이기 위해 1.0000000009GiB파일을 정확히 1GiB로 줄여서 저장하는 일도 없고요.

만약 SI 접두어를 십진으로 계산하게 된다면 위 문제는 아주 간단한 산수 문제가 됩니다(비록 제가 요즘엔 산수 조차도 계산기를 두들기긴 하지만요).

361 961 472B는 361 961kB, 361MB, 0.361GB라고 표현할 수 있고,

1GB의 하드에 100MB 파일을 4개 넣으면 0.6GB가 남고, 여기에 100KB 파일을 다시 100개 넣으면 590 000kB가 남고,

827kB가 0.808MB보다 큰 용량이다라고 자연스럽게 말할 수 있게 됩니다.

하지만 지금은 이러한 방법을 나타낼 수가 없습니다. 하고 싶어도 1000를 나타낼 수 있는 접두어가 없기 때문에, 1024에 의한 복잡한 계산법을 강요받을 수 밖에 없는 것입니다. 1번 문제보다도 전 이 문제가 더욱 심각하다고 생각합니다. 1024라는 숫자에 의해 인간의 사고가 지배받고, 쉬운 방법이 있음에도 불구하고 복잡하고 어려운 방법을 사용하도록 강요받아야 하죠.

사람이 이해하기 쉬운 방식으로 가기 위한 유일한 방법은 SI 접두어에게 원래의 10의 배수에 의한 값을 돌려주는 방법 밖에 없다고 봅니다. 그리고 메모리 모듈의 용량과 같이 이진 배수에 의한 표기가 필요할 때에만 이진 배수에 의한 접두어를 사용해야 한다고 생각합니다.

바뀌어가는 중간 단계에 있어서 매우 혼란스러울 수도 있고, 사회적인 비용도 클 것입니다. 하지마 이 것을 미룬다면 더 큰 비용과 혼란은 뒷 사람에게 남겨두는 것이 되는 것이 아닐까요?

이름: Diesellokomotive 360 866 (V60)
축적: 1:87(H0)
설계도 제작: V.M. Bollig 2004 fur Blue Sky Interactive
모형 제작 시간: 5시간
모형 난이도: ★★★☆☆

V60은 1956년에 독일에서 처음 운행되었습니다. 중간에 클래스 260으로 바뀌었고 지금은 클래스 360으로 불립니다. 최고 속도가 60km/h로 느린 이 열차는 객차나 화차를 끌고 운행을 가는 열차는 아닙니다.

열차의 편성을 바꾸거나, 목적지에 도착한 열차를 해체하는 작업 등을 입환이라고 하는 데, 이 열차는 그러한 작업을 하는 것에 목적이 있습니다.

Blue Sky Interactive에서 발매한 ProTrain Extra 2를 구입하면 열차의 전개도를 얻을 수 있습니다.

감상

종이 모형은 전부터 만들고 싶었습니다. 잉크젯 프린터도 있고 평량 116gms의 잉크젯 전용지도 있었지만, 언제나 완성을 보지 못하고 중간에 폐기되었습니다.

그리고 드디어, 오늘, 처음으로 종이 모형을 완성하게 되었네요. 그리고 지금까지 실패했던 이유를 알게 되었습니다. 원인은 접착제로 딱풀을 사용한 것이었습니다. 딱풀은 두꺼운 종이에는 부족하더군요. 이번에 구입한 목공용 풀이 큰 도움이 되었습니다.

운송 기관 중에서 가장 좋아하는 것은 기관차(열차)입니다. 자태를 뽑낼 수 있는 덩치도 마음에 들지만, 무엇보다도 개개의 기관차가 독자적인 분위기를 연출하는 다양함도 열차를 좋아하는 큰 이유 중에 하나입니다. 그래서 우연히 이 열차의 전개도를 보았을 때, 꼭 만들고야 말겠다는 다짐을 하였죠.

첫 번째 결과물이라는 점에서는 마음에 들긴 합니다만, 너무 시행착오가 많아서 실망도 많았습니다. 사진에서는 확인하지 힘들지만 수평이 맞지 않는 부분이 많이 있고, 기관차 이곳 저곳에 접착제가 묻은 흔적도 많이 남아 있거든요. 하지만 다음에 모형을 만든다면 이번의 경험이 큰 도움이 될 것 같네요.

모형 완성 사진

전면 및 후면

측면

윗면