1. 에러 메시지의 친근성
먼 옛날 도스 시절에는 명령 프롬프트에서 파일 이름이나 명령을 잘못 입력하면 갖가지 에러 메시지들을 볼 수 있었다. 제일 흔한 건 Bad command or file name... 아무말이나 입력하고 엔터 누르면 볼 수 있으니 말이다.
오늘날 Windows의 명령 프롬프트에서 XXXX is not recognized as an internal or external command, operable program or batch file이라고 정말 길고 정황하게 나오는 그 메시지가 옛날에는 저렇게 간결하고 무뚝뚝하게 나왔던 것이다. bad가 뭐냐 도대체.. ㅡ,.ㅡ;;
유닉스 계열만 해도 XXX: command not found 내지 XXX: no such file or directory로 나뉘어 있으나.. 도스는 그 특성상 파일 실행과 명령의 구분이 없는 관계로, 단일 메시지에 파일과 명령을 모두 포함해야 했던 것이다.
그런데.. 그렇게 문장 한 줄만 뜨고 아무 뒤끝 없이 프롬프트로 돌아오는 에러와 달리.. 어떤 에러는 Abort? Retry? Ignore? 이러면서 사용자를 물고 늘어지고 놔 주질 않았다. 이게 초딩 시절엔 굉장히 무섭고 강압적으로 느껴졌다.
이런 무서운 에러는 디스켓과 관련해서 자주 볼 수 있었다. 드라이브에 디스켓을 넣지 않은 상태에서 A: 같은 드라이브 변경을 시도했거나.. 아니면 디스켓 파일을 복사하던 중에 오류가 발생했을 때도 저런 사태가 벌어졌다. 디스크 에러와 데이터 에러라는 게 있었는데, 둘의 차이는 지금 생각해 봐도 오리무중이다.
위의 그림은 도스/Windows 9x vs 오늘날 NT 계열 Windows에서 각각 디스크 없이 FDD 드라이브 전환을 시도했을 때의 에러 메시지의 모습이다.
아 옛날에는 ignore이 아니라 fail이었구나... 아무튼 저런 차이가 있었다는 것이다.
옛날에는 디스켓이 거의 복불복 지뢰밭 수준으로 오류가 잦았으며, 일반 프로그램이 파일을 읽고 쓰다가 지뢰를 밟지 않도록 주기적으로 표면 검사를 해서 bad sector 기입을 해 주는 게 필수이기도 했다.
사실, 시스템 전체의 관점에서는 에러가 이런 식으로 발생하는 게 효율적이다. 무작정 실패 판정만 내리고 끝나는 게 아니라 말 그대로 디스켓을 집어넣을 기회를 다시 준다거나, 오류를 무시하고 일단 더 진행한다거나.. 그러는 게 더 유도리가 있으며, 사용자 친화적이기까지 하다. 사용자가 모든 경황을 아는 전문가라면 말이다.
하지만 초보자의 입장에서는 저런 말이 뜨면 뭘 해야 할지를 모르고, 그냥 다 끄고 명령을 내리기 이전 상황으로나 돌아가고 싶을 것이다. 그런데 저놈의 메시지는 Ctrl+C고 ESC고 뭘 눌러도 없어지질 않고.. UI 측면에서 좀 미스인 건 사실이다.
게다가 말들이 표현이 아주 세고 기계적이고 부정적이다. Abort는 무슨 약속 예약 취소 같은 걸 넘어서 하던 걸 다 때려치우고 철회, 중단한다는 뜻이다. 오죽했으면 낙태라는 뜻까지 있다. Ignore도.. 무시, 묵살, '씹기', 생까기 같은.. 절대로 좋은 어감이 아니다.
물론 어떤 장애물에 부딪혀서 일이 진행되지 않았을 때, 그냥 포기하거나, 한번 더 시도하거나, 그 장애물을 일단 제끼고 넘어가는.. 세 가지 방법 중 하나로 의사결정을 하는 것은 일상생활에서 존재하며 필요하다.
DOS가 없어지고 Windows로 바뀐 오늘날까지도 본인이 프로그래머로서 저 패턴의 메시지를 보는 것은 디버깅 중인 프로그램이 뻗었을 때.. 더 구체적으로는 assertion failure가 났을 때이다. Retry가 디버거 실행과 연결된다.
Windows 2000/ME에서는 Abort/Retry/Ignore(중단/다시 시도/무시 MB_ABORTRETRYIGNORE) 대신, Cancel/Try again/Continue(취소/다시 시도/계속 MB_CANCELTRYCONTINUE)라고 말이 다소 부드럽게 바뀐 메시지 박스가 등장했다. 기존의 표현이 바뀌지는 않았으며, 새로운 플래그를 사용하는 프로그램에서만 새로운 표현을 볼 수 있다. 사실, A/R/I라는 단축키가 도스 시절 이래로 아주 익숙하며, 새로운 표현은 CTC로 이니셜이 겹치기도 하니 말을 일괄적으로 변경해 버리는 건 좀 부담스럽기도 했을 것이다.
그런데 MessageBox의 리턴값까지도 IDRETRY와 별도로 IDTRYAGAIN을 추가하고 IDIGNORE뿐만 아니라 IDCONTINUE도.. 이름뿐만 아니라 값까지 서로 별개로 추가해 버린 것은 의외이다. 두 쌍은 용도가 완전히 동일한데도 말이다.
참고로 MessageBox의 후신격인 TaskDialog에는 표준 버튼으로 '재시도 try again'만이 도입되었고, ignoer/continue는 포함되지 않았다. 기존의 확인/닫기/취소 등으로 보편적인 의사결정은 다 표현할 수 있다고 간주한 듯하다.
지금이야 Cancel/Try again/Continue가 첫 등장한 지도 20년 가까이 지났다. 컴퓨터 대신 PC, 디바이스라고 하고 응용 프로그램도 그냥 앱이라고 하는 세상이다. 게다가 이제는 전통적으로 무뚝뚝함과 충격과 공포 그 자체이던 패닉 BSOD화면에도 이모티콘과 한글 메시지가 표시되는 세상이 됐다. press any key의 번역은 "... 누르십시오" 대신 "... 누르세요"로 바뀌었다. 여러 모로 격식이 없어지고 말이 친근하게 바뀌고 있는 것 같다.
하지만 C/C++ 프로그램의 디버그 빌드에서 assertion failure가 났을 때, 무식한 A/R/I 메시지박스와 함께 "Press Retry to debug this application"이 뜨던 건.. 깔끔한 task dialog로 바뀌는 날이 올지 모르겠다.
end user는 볼 일 없고 어차피 개발자들이나 보는 메시지이니 아무도 신경 안 쓰려나? =_=
2. 반응성과 존재감
어떤 소프트웨어가 인터페이스 내지 반응성 관점에서 사용자에게 좋은 인상을 주려면 자잘하게 뻗는다거나 화면 잔상이 생기는 버그가 없어야 하고, 키· 마우스 입력에 대한 반응이 신속해야 할 것이다. 반응성을 보장하기 위해 필요하다면 스레드 같은 것도 적절하게 활용해야 한다. 어지간해서는 5초 이상 반응이 없어서 '응답 없음' 판정을 받는 일이 없어야 한다.
마우스로 창 크기를 변경했을 때 너무 굼뜬다거나, 화면 전체가 지워져서 번쩍거리면서 그려진다거나 하지도 않아야 한다. 새로 그리는 게 시간이 너무 오래 걸리는 게 있으면, 스크롤 내지 크기 변경 중에는 뼈대만 간략하게 그렸다가 키보드· 마우스 버튼이 놓였을 때 다시 그려도 좋다.
그런데.. 이런 것들과 반대로, 눈에 보이지 않고 백그라운드에서만 몰래 돌아가는 프로그램에도 지켜야 할 덕목이 있다.
사용자가 직접 명령을 내려서 실행된 게 아닌 서비스, 업데이트 체크 같은 부류의 프로그램이라면 정말 절대적으로 사용자의 눈에 띄지 않아야 한다.
컴퓨터의 성능을 떨어뜨리는 티를 절대 내지 말아야 한다.
요즘 컴터는 코어가 많으니 한 프로그램이 코어 하나를 다 점유한다고 해서 당장 속도가 느려지지는 않는다. 하지만 컴터를 열받게 할 수 있고 배터리 소모를 증가시킬 수 있고, 냉각팬이 쓸데없이 돌아가게 만들 수 있다. 특히 노트북에서 말이다.
업데이트를 받더라도 무슨 당장 안 받으면 컴퓨터가 악성 코드에 감염되어 박살나기라도 하는 울트라 초특급 필수가 아니라면 아주 쉬엄쉬엄 찔끔찔끔 받도록 하고, 네트웍 상태가 안 좋아서 발생하는 딜레이가 UI의 딜레이나 CPU 쳐묵 대기 상태로 절대로 이어지지 않게 해야 한다.
이는 음악회에서 넘돌이 넘순이(페이지 터너..;;)가 연주자보다 더 돋보여서는 안 되고, 무슨 집회에서 통역사가 연사보다 더 돋보이지 말아야 하는 것과도 같은 이치이다.
인터넷 연결이 안 된 곳에서 Windows Update 서비스라든가, 구글 크롬 브라우저의 software report tool이 도대체 뭔 짓을 하느라 CPU 코어를 다 쓰면서 날뛰고 있었나 모르겠다. 현재로서는 요 둘이 내 블랙리스트에 올라 있다.
컴퓨터 프로그램은 n초 이상 응답이 없으면 저렇게 다운 의심 판정을 받게 되고, 운전자는 교차로에서 파란불 신호를 받고도 n초 이상 응답 없이 움직이지 않으면 뒷차로부터 경적 세례를 받고 욕 먹게 된다. 개인적으로는 이게 서로 비슷한 양상의 현상인 것 같다.
3. 이식성
로터스 1-2-3, dBase III+ 같은 프로그램은 한때 시대를 풍미했던 명품 업무용 소프트웨어였다. 하지만 도스에서 Windows로 넘어가는 변화를 따라가지 못하고 그대로 도태해서 사라졌다.
내가 듣기로는 이 두 프로그램은 긴 짬밥답게 주요 코드가 쑤제 어셈블리어로 한땀 한땀 작성됐다고 한다. 덕분에 1980년대에 컴퓨터가 느리고 비싸던 시절에는 잘 최적화돼서 쌩쌩 돌아갔겠지만, 훗날 이 코드는 구조 확장이나 유지 보수가 도저히 안 되는 지경에 이르렀다고 한다. 특히 dBase가 말이다.
이래 가지고는 Windows로 포팅은 물론이고 같은 도스에서 32비트로 갈아타는 것조차도 쉽지 않았을 것이다. 현재의 하드웨어에서 돌아가지만 시간이 그 상태 그대로 멈춰 버린 코드는 그야말로 오늘만 사는 죽은 코드나 다름없다.
운영체제 중에서 Windows 9x야 저사양 똥컴 x86만 겨냥한 특이한 변종이니 어셈블리어 최적화가 없으면 안 됐고.. OS/2도 잘 만들어진 32비트 OS이긴 하지만 이식성이 부족했다. 훗날 64비트니 ARM이니에 전혀 대처하지 못하고 그대로 묻혀 버렸다.
그러나 유닉스처럼 C/C++을 처음부터 주력으로 사용한 Windows NT는 비록 처음에 나왔을 때는 너무 무겁고 느리다고 욕 먹었을지언정, 결국 여러 아키텍처들을 거쳐 오늘날까지 천수를 누리는 운영체제 커널이 됐다. 미래를 대비한 것에 대한 보상을 받은 것이다.
이런 게 이식성의 힘이다. 다만, 이 2020년대에는 이제 x86 계열과 ARM 계열 말고 또 획기적으로 새로운 컴퓨터 아키텍처가 설마 등장할 일이 있을까 싶다. ARM은 전력 효율이 x86이 범접할 수 없을 정도로 좋긴 하지만, 그렇다고 x86을 완전히 대체할 정도로 범용적인 성능이 좋은 건 아니다. 그러니 결국 이 두 아키텍처가 64비트 형태로 끝까지 갈 것 같다.
4. Windows와 맥이 추구한 가치의 차이
과거에 비해 텃새랄까 격차가 많이 줄긴 했지만 그래도 사과가 그려진 맥OS 컴퓨터는 예술, 출판, 디자인 업계에서 오늘날까지도 Windows보다 강세이다. UI 비주얼이 간지 날 뿐만 아니라, 같은 글꼴을 써도 글자의 렌더링이 정말 고퀄인 것을 부인할 수 없다.
그런데 그 분야 말고 게임은.. 특히 모바일용 말고 PC용은 맥 진영이 절대 범접하지 못할 정도로 Windows가 강세이다.
물론 게임은 애초에 특정 업계 종사자만 쓰는 업무용 생산성 앱이 아니며, Windows는 게임을 즐기는 end user 고객의 점유율이 압도적으로 높은 운영체제이다.
오늘날의 결과만 놓고 보면 저런 점유율이 당연히 저절로 이뤄진 것 같지만 사실은 그렇지 않았다. 먼 옛날에 IBM 호환 PC라는 물건은 동시대의 다른 컴퓨터들에 비해 사용자의 눈과 귀를 현혹시키는 기술에는 그렇게 관심을 두지 않았었기 때문이다.
지금으로서는 믿어지지 않지만 한때 Windows 같은 멀티태스킹에 하드웨어 추상화가 갖춰진 복잡한 환경에서 현란한 게임은 어림도 없는 일이었다. 그렇기 때문에 1990년대 중반까지만 해도 PC용 게임은 하드웨어 자원의 독점이 가능한 도스용으로만 나왔다.
그리고 90년대 중반, Windows 95는 바로 이런 배경에서 출시되었다.
빌 게이츠는 가히 목숨을 걸고 Windows를 게임과 멀티미디어에 최적화된 홈 엔터테인먼트 운영체제로 만들려고 애썼다. 구닥다리 WinG로는 성이 안 차고 OpenGL은 그 시절엔 아직 업무용에다 NT의 전유물이었으니.. 거기서도 하드웨어 직통 액세스가 가능한 DirectX를 만들고 게임 개발을 위해 물심양면 지원을 했다. Doom을 만들어 냈던 이드 소프트웨어를 인수할 생각까지 했던 것도 유명한 일화이다.
이런 마소 진영에 비해, 맥은 클래식 시절이건 OS X의 개발 초창기이건 잡스 아저씨가 저렇게 게임에 눈독을 들였다거나, Doom을 자기 맥OS에서 꼭 구동하고 말겠다고 나선 적이 없다. 빌처럼 가정 소비자들의 취향을 저격하는 방법, 시장에서 팔리는 제품을 만드는 방법을 기를 쓰고 연구하기보다는 그냥 자신의 천재적인 감과 괴팍· 고상한 취향을 따라 제품을 만들었다. 다수의 보편적인 소비자보다는 소수의 골수 매니아 애플빠를 양성하는 노선을 추구한 듯하다.
5. 설치/배포 패키지
Windows Installer (msi)라는 기술이 개발된 게 20여 년 전 1999~2000년 사이의 일이다.
소프트웨어의 설치와 제거라는 게 '파일 열기/저장 대화상자'만큼이나 응용 프로그램들이 공통으로 요청하고 수행하는 기능이니, 이를 위한 공통의 API를 정의하고 만든 것은 일면 바람직한 일이다.
하지만 얘는 2009~2010년 정도까지 버전업이 되었다가 그 뒤부터는 이렇다 할 변화가 없는 것 같다. 2010년대부터는 마소에서도 Office나 Visual Studio 같은 제품을 배포할 때 msi를 사용하지 않는다. 또 자신들만의 독자적인 설치/제거 시스템을 개발하기라도 한 것 같다.
통상적인 배포 패키지 시스템이라면 프로그램의 구성요소들을 세부적으로 나눠서 지금 당장은 사용자가 원하는 부분만 설치하고, 설치하지 않은 기능은 나중에 언제든지 추가 설치 가능하게 되어 있다.
그런데 2010년대 이후의 배포 패키지 시스템이라면 적어도 두 가지 요소를 반드시 지원해야 할 것 같다.
(1) 먼저, 웹을 통한 설치이다. 지금 로컬 installer 실행 파일에 내장된 데이터가 아니라 지정된 주소를 통해 서버로부터 데이터를 받아서 설치하는 것이다.
그리고 (2) 요즘 프로그램들의 거의 필수 기능이 된 최신 버전 체크 및 자동 업데이트와의 연계이다. 현재 버전과 최신 버전을 비교하여 부분만 자동 업데이트가 가능한지 판단하고, 꼭 바뀌어야 하는 분량만큼만 다운로드를 한다.
설치 후에 마이너 버전이 바뀐 것은 '프로그램 추가/제거' 목록에도 당연히 반영된다.
Windows Installer가 웹 연계 내지 자동 업데이트까지 고려하여 개발되었는지 잘은 모르겠지만 내가 알기로 그 정도까지는 아니지 싶다.
통합된 API가 없으니 Visual Studio고 아래아한글이고 다 독자적인 설치 및 업데이트 시스템을 구축하고 있는데.. 업데이트를 시켜 보면 프로그램뿐만 아니라 설치 관리자 자체부터 업데이트 하는 경우가 굉장히 잦다.
저건 뭐 한번 만들어 놓고 나면 버전 체크, 파일 설치 등등 끝.. 처음에 한번 안정적으로 잘 만들어 놨으면 바뀔 일이 없어야 하는 시스템이지 않은가? 그런데 뭐 이리 자주 바뀌나 모르겠다. 그리고 궁극적으로는 이런 분야도 운영체제 차원에서의 통합 솔루션이 나와야 할 것 같다.
그나저나 10~20여 년 전에 시대를 풍미한 배포 패키지이던 InstallShield는 요즘도 잘 먹고 살고 있는지 모르겠다.
6. 각종 약관 동의 화면
웹사이트에서 회원 가입을 할 때나 응용 프로그램을 처음 설치할 때는 사용자에게 뭔가 법적으로 동의를 구하는 계약 안내문이 표시되는 것이 관례이다. 사용자가 그 내용에 대해 명시적으로 yes라고 동의 의사를 밝혀야만 다음 단계로 넘어갈 수 있다.
응용 프로그램을 설치하는 경우라면 안내문의 내용은 주로 저작권과 관련된 것이다. 마소에서는 이 안내문의 명칭을 EULA(end-user license agreement)라고 붙인 것으로 잘 알려져 있다. 상업용 소프트웨어에는 불법 복제 금지와 관련된 경고문이 으레 들어가지만 그것 말고도 해킹이나 리버스 엔지니어링 금지 같은 조항도 있다.
한편으로 웹사이트 회원 가입이라면 개인 정보 수집 정책과 관련된 내용이 꼭 포함된다.
아울러, 요즘은 응용 프로그램도 사용권 계약과는 별개로 사용자의 사용 패턴 데이터나 오류 정보를 수집해서 개발사 서버로 보내도 되겠는지 동의를 구하기도 한다. 이걸로 사용자 개인을 식별하는 건 절대로 아니니 안심하라고 하면서.. 물론 이건 동의하지 않아도 프로그램을 설치하거나 사용하는 데는 지장이 없다.
이런 약관이나 법적 주의사항 고지 문구는 너무 비현실적인 상황까지 일일이 어려운 단어와 장황한 문장으로 미주알고주알 열거하면서 길고 딱딱하고 재미없는 걸로 악명 높다.
뭐 이건 온갖 애매한 상황까지 철저하게 논리적으로 방어해서 갑 쪽의 법적 책임을 최대한 피하기 위해 말이 그런 식으로 만들어진 것이다. 계약서는 아니지만.. 망토 하나를 만들어도 소송을 피하기 위해 “주의: 이걸 목에다 두르고 옥상에서 뛰어내리지 마시오” 경고문까지 들어가는 게 세상 돌아가는 이치이지 않은가?
그런데 말이 하도 재미없으니 갑이나 을이나 텍스트를 꼼꼼히 제대로 읽지 않는 건 마찬가지 같다. 그러니 한 10여 년 전이었나? “본 약관이 해지되는 순간 뼈와 살이 분리됩니다”던가? 개드립이 들어간 약관이 복붙 되어서 여러 웹사이트들에서 그대로 쓰인 게 뉴스에까지 방영되곤 했다.
약관과 관련된 말이 좀 길어졌는데..
본인이 이걸 표시하는 소프트웨어 UI와 관련해서 굉장히 큰 불만을 품고 있는 건.. 아니, 이건 나만의 불만도 분명 아닐 것이다.
안 그래도 재미없고 귀찮아서 안 읽는 긴 약관을 너무 작은 크기의 텍스트 셀에다가 집어넣고는 창의 크기 조절도 안 되게 해 놓으면.. 사용자는 읽고 싶은 생각이 더욱 멀리 달아날 것이다. 그렇지 않겠는가?
쪼금 생각을 한 곳에서는 약관을 plain text가 아니라 서식을 적용한 텍스트로 제공하고, 인쇄 기능 정도는 갖다놓았다. 하지만 이걸 인쇄까지 해서 보는 사람도 과연 얼마나 될까?
그냥 화면에서 창 크기 조절과 본문 검색 정도만 가능하게 하는 게 제일 좋아 보인다.
Posted by 사무엘
