« Previous : 1 : 2 : 3 : 4 : 5 : ... 11 : Next »

1. 텍스트 에디터

macOS의 워드 프로세서 겸 에디터인 TextEdit은 신기하게도 '자동 줄 바꿈'을 끄는 기능이 없다...! 개인적으로 굉장한 문화 충격을 느꼈다. 줄 바꿈을 창이 아닌 용지를 기준으로 하게 하고 용지의 폭을 9999로 지정하는 간접적인 방법만 동원할 수 있다.

하긴 macOS는 터미널 창도 창 크기에 맞춰 줄 정렬을 꼬박꼬박 다시 해 주고 xcode의 코드 에디터에서도 자동 줄 바꿈이 지원되니.. 그쪽 바닥은 분위기가 전반적으로 wrap에 친화적인 것 같다.

2. 텍스트 뷰어

에디터처럼 파일을 linked list 형태로 재구성하지 말고 수백 MB~수 GB의 파일이라도 O(1) 상수 시간으로 즉시 읽어들이는 텍스트 뷰어가 좀 있으면 좋겠다. 당장 화면에 표시해야 하는 맨 앞이나 맨 뒷부분만 줄 바꿈과 탭 적용을 한 뒤, 나머지 화면에 안 보이는 부분에 대한 줄 수 계산, 글자 폭 계산 같은 건 그때 그때 백그라운드로 진행한다.
파일의 앞부분이나 맨 뒷부분만 신속하게 조회 가능하되, 필요하면 다른 부분으로 스크롤이나 텍스트 검색도 가능해야 한다. 텍스트 수정은..?? 파일의 크기를 변경하지 않는(= 삽입, 삭제) 변경만 있어도 좋다.

유닉스의 tail 명령은 뒷부분 조회는 가능하지만 내가 원하는 모든 기능이 들어있지는 않다.
워드 프로세서가 아니라 텍스트 에디터도 전문적인 개발 분야이듯.. 텍스트 뷰어만으로도 별개의 개발 분야가 될 수 있을 것 같다. 방대한 로그 파일 같은 건 이런 프로그램을 이용해서 열람해야 할 것이다.

3. 그래픽 에디터

(1) 요즘 세상에 2, 16, 256색 팔레트 기반의 이미지를 전문적으로 처리 가능한 그래픽 에디터가 살아 있기는 한가 모르겠다. 수요가 매우 드물어졌지만 그래도 전혀 없지는 않을 텐데 말이다. 나는 그런 일이 생기면 닥치고 Paint Shop Pro 구버전으로 고고씽 한다..;;

(2) 한편, 세상이 하도 많이 바뀌어서 손실 압축 코덱 기반의 통상적인 동영상이 gif 움짤보다도 더 가볍고 효율이 좋아지는 지경이 됐다. 전자는 jpg처럼 양자화 과정에서 손실이 발생하고, 후자는 디더링 과정에서 손실이 발생한다.
무손실 압축 기반으로 트루컬러가 지원되는 깔끔한 소규모 동영상 포맷이 등장하고 그게 Windows의 애니메이션 컨트롤 같은 데서도 지원됐으면 좋겠다. 일반적인 그래픽 툴로도 쉽게 만들 수 있고 말이다.

4. 파일 관리 셸

프로그래밍을 업으로 삼는 개발자 내지 파워 유저들은 갓 설치한 운영체제의 GUI 기반 파일 관리 셸에서 거의 공통으로 제일 먼저 설정을 변경하는 것이 있다. 바로 (1) 파일 목록에서 확장자까지 표시하도록 하고, (2) 숨김 파일도 나오게 하는 것이다.

  • Windows의 탐색기(Explorer): 예전에는 보기 옵션 대화상자를 꺼내고 번거로운 단계를 거쳐야 했다. 하지만 Windows 8인가 10쯤부터는 '보기' 탭에 체크 옵션이 바로 표시되기 때문에 접근하기 편해졌다.
  • macOS의 Finder: 아마 내 기억이 맞다면 어디 설정 파일을 텍스트 에디터로 열어서 고쳐야 하지 싶다. GUI에서 이런 설정을 변경할 수 있지는 않다. 구체적인 방법은 검색해 보면 나올 것이다.
  • 리눅스: 셸 엔진이 무엇이냐에 따라 차이가 있을 수 있지만(GNOME, KDE??).. 리눅스는 역시 GUI 셸이라도 기본적으로 파일의 확장자가 꼬박꼬박 표시되고 있지 싶다.

이런 사소한 디테일도 세 운영체제의 정책이 서로 차이가 있는 셈이다.
컴퓨터의 내부 디테일을 모조리 파악하고 싶어하는 사람 입장에서는 파일 확장자를 도대체 왜 숨기는지 답답함을 느낄 것이다. 아이콘은 확장자의 기능을 완벽하게 대체하지 못하기 때문이다.

하지만 일반인이나 컴맹의 입장에서는 필요 이상으로 쓸데없이 자세한 정보를 가능한 한 숨기는 게 바람직하다. 그러니 확장자나 숨김 파일을 취급하는 방식은 앞으로도 이렇게 옵션과 재량의 영역에 머무를 것으로 보인다.

5. 웹브라우저

요즘은 웹페이지 내부에서도 지도나 하드카피 문서(구글 도서 검색 같은..)를 조회하고 영역을 Ctrl+휠로 확대/축소할 수 있다.
그런데 똑같이 키보드 포커스를 주고 Ctrl+휠을 굴렸을 때 그 영역만이 확대/축소될 때가 있고, 아니면 웹페이지 전체가 확대/축소되어 버릴 때가 있다. 개인적으로 정확한 패턴이나 조건은 아직 모르겠다. 사용하는 브라우저와 이용하는 사이트가 무엇이냐에 따라서 케바케인 것 같다.

확대/축소에 이렇게 중의성이 발생한 게 참 웃긴데.. 사용자가 원하는 결과는 대부분의 경우 전자, 즉 그 영역만 확대/축소되는 것이다. 웹브라우저 내지 웹사이트를 개발할 때 이런 동작과 사용자 경험 쪽도 고려가 됐으면 좋겠다.

6. 요즘 Windows 10 근황

  • 언제부턴가 시작 메뉴와 작업 표시줄의 배경색이 Windows 10 특유의 검정이 아니라 밝은 회색으로 바뀐 컴퓨터가 눈에 띄기 시작했다. 싸제 테마로 customize를 한 건지 궁금했는데.. 그건 아니고 버전 1903부터 밝은 색 테마가 정식으로 추가된 거라고 한다.
  • 집과 회사 컴퓨터를 몇 대 살펴보니.. xps/oxps 확장자가 자체 viewer로 연결되어 있지 않은 곳이 좀 눈에 띈다. 정작 xps/oxps 파일을 생성해 주는 가상 프린터 드라이버는 다들 기본으로 설치돼 있는데, viewer가 없거나 연결돼 있지 않은 게 말이 되는지..?? 어디 좀 착오가 있는 것 같다.
  • Windows 10이 나온 지 벌써 5년이 돼 간다. 대부분의 운영체제 설정 기능들이 데스크톱 UI인 제어판(Control Panel)에서 메트로 UI인 Settings로 갈아탔지만, 키보드의 반복 속도를 설정하는 기능은 아무리 눈 씻고 검색해도 없는 것 같다.
    Settings에는 키보드 설정과 입력 언어 설정이 별 구분 없이 뒤섞여 있으며, 제어판 한구석에 처박힌 구닥다리 제어판 애플릿을 꺼내야 변경 가능하다.
  • 그리고 내 경험상, 처음 사용하는 컴퓨터들은 마우스 포인터 뒷배경에 그림자 효과가 적용돼 있지 않은 것 같다. 왜 뺐는지..?? 이걸 지정하는 것도 Settings에는 없고, 제어판 애플릿을 따로 열어야 한다.

7. 스플래시 화면

덩치와 규모가 좀 있는 소프트웨어라면 실행되어 로딩 중일 때 일명 스플래시 화면이라는 게 잠시 나타났다가 사라지곤 한다. 얘는 표시하는 내용이 About 대화상자와 좀 겹치는 구석이 있지만(제품 명칭, 버전, 저작권자..), 그 대화상자보다는 화려한 그림의 비중이 더 크다.

뭐, 요즘은 정말로 어마어마하게 방대 거대해서 로딩 시간이 긴 프로그램이라든지, 10년 20년 전부터 화려한 스플래시 화면이 컨셉이요 전통이었던 프로그램이 아닌 이상, 굳이 스플래시 화면을 넣지는 않는 편이다. 그냥 바로 본론으로 들어가서 자기 화면만 띄운다.
컴퓨터의 성능이 갈수록 좋아지면서 프로그램이 구동되는 데 걸리는 시간도 충분히 짧아졌고, 또 요즘은 추세도 새 프로그램의 구동을 요란하게 알리는 게 아니기 때문이다.

예를 들어, 설치 프로그램만 해도 화면 전체를 자기 창으로 꽉 채우고 파랑-검정 그러데이션을 띄우던 유행은 이미 20년도 더 전, 2000년대 초반쯤부터 없어졌고 간단한 마법사로 바뀌었다.
그리고 Windows 8쯤부터는 tada.wav 이래로 오랜 전통이던 운영체제의 시작 음향도 없어졌다. 이런 식이다.

옛날에 Windows 95 시절에는 딱 한 번, 워드패드도 실행될 때 스플래시 화면이 잠깐 나타나던 적이 있었다. 그 자그마한 프로그램에도 말이다.;; 물론 98과 그 이후부터는 싹 없어졌고 다시는 부활하지 않았다.
오늘날 마소 제품들 중에 Office나 Visual Studio 같은 건 실행될 때 스플래시 화면이 뜬다. 그런데 과거에 비해 중요한 변화가 생긴 게 있다.

옛날 버전들은 스플래시 화면에다가 마우스 포인터를 가져가면 모래시계 모양으로 바뀌었다.
그러나 Office는 2010부터, VS는 2012부터.. 마우스 포인터를 가져가도 모래시계가 아니라 일반 화살표 모양이 유지되며, 스플래시 화면을 마우스로 드래그 하면 그 화면을 딴 데로 이동시킬 수도 있다.

즉, 스플래시 화면에 대한 사용자 반응성을 더 개선한 것이다. 스플래시 화면이 들어갈 정도로 방대한 소프트웨어를 개발하는 분이라면 이런 면모도 생각해 볼 필요가 있다. 뭐, 본인이 개발하고 있는 날개셋 한글 입력기는 스플래시 화면이 필요할 정도로 방대한 프로그램이 전혀 아니기 때문에 해당사항이 없다.

8. ESC 또는 Alt+F4

Visual Studio는 '닷넷'으로 바뀌었던 200x 버전 시절부터 '시작 페이지'라는 것을 제공해 왔는데, 2019부터 이걸 그냥 대화상자로 대체했다. 그런데 이거 동작 방식이 꽤 재미있다.
대화상자를 ESC를 눌러서 닫으면 프로그램 실행이 계속 진행되어 정식 IDE 창이 뜬다. 하지만 대화상자를 Alt+F4 또는  [X] 버튼 클릭으로 종료하면.. 프로그램이 통째로 종료된다. 이 차이점을 눈치 챈 분 혹시 계시는가?

Windows에서 ESC와 Alt+F4는 차이점이 매우 미미하다. 대화상자를 '취소'로 닫을 수 있는 건 공통인데 후자는 전자의 상위 호환으로, 프로그램 main 창을 종료하고 시스템 종료까지 가능하다는 차이가 있을 뿐이다.
그리고 프로그램의 대화상자는 자신이 ESC로 닫혔는지 Alt+F4로 닫혔는지 같은 걸 일반적으로 분간할 수 없다. WM_CLOSE 내지 IDCANCEL 메시지가 오는 건 동일하기 때문이다.

그런데 굳이 둘을 구분해서 동작한다니.. by design인 걸까?
지금 메모장에서 파일을 저장하지 않고 종료했을 때 나타나는 "....를 저장할까요?" 메시지 대화상자를 Alt+F4로 닫으면 ESC로 닫았을 때와 달리 저장 대화상자가 뜬다. 이는 메시지 대화상자가 MessageBox가 아닌 TaskDialog 기반으로 바뀐 10여 년 전 Windows Vista 때부터 생긴 버그인데, 아직까지도 여전하고 고쳐지지 않았다..;;

ESC와 Alt+F4의 동작이 다른 프로그램을 메모장 이후로 처음으로 하나 더 발견하게 됐다.

9. 버전 넘버링

마소는 1990년대부터 2000년대까지는 Windows, Office, Visual Studio 같은 제품을 버전업할 때마다 외형 비주얼도 그야말로 널뛰기 하듯이 바꾸는 게 유행이었다. 그러나 2010년대 중후반부터는 이제 어지간히 만들 것들은 다 만들었는지 그런 유행이 사실상 끝났다.

그리고 버전 번호도 옛날처럼 과감하게 성큼성큼 올라가지 않고 있다. 글쎄, 웹브라우저들은 크롬의 주도 하에 버전이 자비심 없이 막 올라가는 중이지만 마소 제품들은 그렇지 않다. 다음 사례들을 생각해 보라.

  • Windows: 잘 아시다시피 지난 2015년부터 주 버전 및 브랜드는 Windows 10으로 고정돼 버렸으며, 이제는 연도/월이 기재된 별도의 하위 버전만 올리고 있다. (그래도 서버 제품군의 경우, 2016에 이어 2019를 따로 내놓은 듯하던데.. 연도 기반 네이밍의 의미가 많이 퇴색했다.)
  • Office: 2016과 2019, 그리고 365까지 모두 16.x 버전으로 동일하다.
  • Visual Studio: 최신 2019는 버전 번호가 Office와 마찬가지로 16.x이다. 그리고 내부적으로 통용되는 _MSC_VER 값은 2015까지는 100씩 증가해서 1900에 도달했지만, 다음 2017은 1910, 2019는 1920이 되어서 10씩만 증가하고 있다.
  • .NET Framework: 10년 전인 2010년에 4.5가 나왔지만 10년째 4.x 버전을 졸업하지 않고 있다. Windows 10과 함께 4.6이 나왔고 최신 버전에서도 그냥 4.8대이다.
  • DirectX: Windows 10과 함께 버전 12.x가 나왔으며, 12라는 숫자가 앞으로 더 올라갈 것 같지는 않다.
  • Internet Explorer, Media Player: 얘들은 최소한의 보안 패치만 하지 후속 개발 자체가 중단된 레거시이다. 버전 역시 각각 11, 12에서 멈추고 봉인됐다.

지난 2~30년 동안 PC용 소프트웨어들은 기술이 하도 많이 발전하고 상향평준화하다 보니.. 그냥 무료 서비스 아니면 기간제 구독형으로 바뀌는 추세인 것 같다. 그래서 MS Office도 이제 20xx 같은 연도가 붙은 정규 릴리스 대신 슬슬 구독형을 밀고 있으며, Adobe의 비싼 그래픽 툴들도 진작에 구독형으로 바뀌었다.
Visual Studio는 기본적인 IDE와 컴파일러의 경우, 인디 개발자를 대상으로는 사실상 완전히 무료로 풀렸고, 일정 규모 이상의 인원을 갖춘 기업을 대상으로만 유료이다.

소프트웨어가 구독형으로 바뀌었으니 새 버전 출시와 업데이트도 예전보다 훨씬 더 자주 부담 없이 수시로 행해진다. 거창하게 서비스 팩이니 뭐니 하는 것도 필요하지 않다. Visual Studio만 해도 예전엔 상상도 못 할 정도로 시도 때도 없이 업데이트를 하라고 뜬다. 16.5.0 다음으로 16.5.1 같은 식..
이런 추세와 달리, 한 카피당 사용권 얼마 같은 전통적인 방식으로 유료 소프트웨어를 end-user에게 판매하는 개발자· 개발사와 제품들이 앞으로 얼마나 더 남아 있을지 궁금하다.

Posted by 사무엘

2020/08/14 08:35 2020/08/14 08:35
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1784

1. 독특한 윈도우 클래스

Windows의 GUI에는 버튼, 리스트박스, 에디트 컨트롤 등의 잘 알려진 제1군 컨트롤 윈도우들이 있고, 공용 컨트롤이라는 제2군 윈도우도 있다. 이런 것들은 누구나 널리 사용하라고 클래스 이름도 널리 알려져 있다.
그런데 Spy++로 들여다보면, 정식으로 공개되지 않았지만 이런 클래스들이 공용으로 쓰이는 것 같다. 정체가 무엇인지 궁금하다.

  • NetUIHWND: MS Office 프로그램들, 그리고 심지어 워드패드와 그림판에서도 리본이 이 클래스 이름으로 만들어져 있다. 마소에서만 내부적으로 사용한다. (Visual C++의 MFC 확장판에서 제공되는 리본은 마소 오리지널이 아님)
  • DirectUIHWND: task dialog 내부, IE 브라우저의 탭, 탐색기 제어판에서 뭔가 웹페이지처럼 꾸며진 대화상자들에서 종종 쓰인다. 클래스 스타일에 CS_GLOBALCLASS도 버젓이 지정돼 있다. 마소 내부에서 사용하는 GUI 엔진 윈도우 같은데..
  • HwndWrapper[모듈이름;;GUID]: 닷넷이나 WPF처럼 통상적인 Windows API나 기성 컨트롤이 아닌 다른 프레임워크를 이용해서 GUI를 꾸미는 프로그램 같다. 내가 아는 프로그램 중에는 Visual Studio 2010과 그 이후 버전, 그리고 아래아한글(+ 타 오피스 제품 포함) 요 두 프로그램만이 이런 스타일이다.

2. 파일 및 디렉터리의 삭제, 디스크 제거

Windows는 프로그램을 memory-mapped file 형태로 불러온다는 특성으로 인해.. 실행 중인 프로그램을 삭제할 수 없다. 그래서 실행 중인 프로그램을 제거하거나 업데이트 하는 것도 좀 어려운 편이다.
실행 중인 프로그램 파일을 '개명'하는 건 가능하다. 여기서 개명이란 같은 드라이브 안에서의 디렉터리 이동도 포함한다.

이런 Windows와 달리 macOS나 리눅스는 실행 중인 프로그램 파일을 삭제할 수 있다.
허나, 실행 중인 프로그램의 current directory를 당장 삭제할 수 있는 운영체제는 내가 아는 한도 내에서는 없다. 삭제 예약만 해 놓은 뒤, 프로그램이 종료되거나 디렉터리가 딴 데로 바뀌었을 때 삭제되는 게 그나마 제일 관대한 처분이다.

프로세스의 current directory는 USB 메모리를 안전하게 제거할 수 없다고 운영체제가 꼬장 부리면서 사용자를 귀찮게 하는 요인 중 하나이기도 하다.
특히 Windows의 경우, 파일 열기/저장 공용 대화상자를 열어서 USB  메모리를 조회하면 해당 프로그램의 current directory도 거기로 바뀌기 때문에 대화상자를 닫은 뒤에도 저런 꼬장이 발생할 가능성이 높아진다.

뭐, 사용자가 USB 메모리를 물리적으로 강제로 제거해 버리는 것에는 장사 없다. 과거의 디스켓이나 광학 드라이브도 매체를 강제로 꺼낼 수 있었으니 말이다. 하지만 이런 일이 발생하면 운영체제의 관점에서는 current directory가 갑자기 없어지는 것이나 다름없고, 거기에 파일이 열려 있던 것들도 다 꼬여 버린다. 프로세스가 아닌 스레드를 강제 종료하는 것만큼이나 좋지 않은 현상이다.
디스크 내용을 날리고 싶지 않으면 사용자도 가능한 한 그런 짓은 하지 않는 게 좋다.

3. Windows의 런타임 환경

Windows에서 전통적인 API 기반의 네이티브 코드 데스크톱 프로그램 말고 선보였던 프로그램 실행 환경으로는..
먼저 2000년대(XP..)엔 .NET이란 게 있었다. 얘는 네이티브가 아니라 가상 머신에서 돌아갔고, 언어도 C#가 주류였다. C++에는 C++/CLI라는 변종 언어가 도입됐다.
그 뒤 2010년대(8..)엔 메트로 UI와 함께 C++/CX라는 변종 언어가 도입됐다. 얘는 데스크톱 환경은 아니지만 의외로 네이티브 코드 기반이었다.

.NET이 표방했던 것이 언어의 통합이라면, Windows 8이 표방했던 것은 기기(PC와 모바일?)의 통합이었다. 그래서 오죽했으면 시작 버튼을 없애는 초강수까지 뒀었다.
그러나 Windows 8은 망했으며, 결정적으로 Windows Phone/Mobile도 안드로이드와 iOS에 완전히 밀렸다. 이젠 마소에서도 그쪽 사업을 접었다. 그 대신 Windows 10은 ARM용이 정식으로 출시되어서 그 CPU에서 네이티브 데스크톱 앱을 그대로 돌릴 수 있게 됐다.

그럼 이 와중에 메트로 앱을 돌리는 Windows Runtime이라는 건 무슨 존재의 의미를 갖게 되는지 난 궁금하다. 답을 잘 모르겠다.
그냥 데스크톱 앱보다 글자 큼직하고 시각적으로 flat하고, 안드로이드 용어로 치자면 material design스러운 외형을 제공하는 GUI 엔진 그 이상도 이하도 아니어 보이는데..??
쉽게 말해 기존 공용 컨트롤이 '제어판'을 가동한다면 이 UI 엔진은 '설정'을 가동한다는 것이다.

마소에서 새로운 걸 시도한 것이 언제나 다 성공적이고 오래 유지된 건 아니었던 듯하다.
그래서 GDI+는 닷넷 시절에 잠깐 뜨다가 Direct2D 부류로 대체됐고, 오히려 운영체제의 근간으로서 넘사벽급의 짬밥을 자랑하는 재래식 GDI보다도 존재감이 없어졌다.
Edge 브라우저는 잘 알다시피 재개발되어서 사실상 크롬과 다를 바 없는 브라우저가 됐다. 마소의 지난 20여 년의 개발 트렌드를 회고해 보니 이런 분석과 결론이 나온다.

4. 이모지, 날개셋 입력 패드

Windows 10의 1803버전쯤부터는 win+.을 눌러서 이모지 문자표를 꺼내는 기능이 추가되었다.
날개셋 한글 입력기에서는 지난 9.81 버전부터 자체적으로 이모지 문자표가 추가되었다. 그럼 이건 언뜻 보기에는 기능 중복처럼 보이지만 실제로는 꼭 그렇지 않다.

운영체제의 이모지 문자표는 마우스로 딴 델 클릭하기만 해도 사라져 버리는 반면, 날개셋의 입력 도구는 그렇지 않다. 더구나 결정적으로 이 문자표는 날개셋 편집기에서 자체 입력기를 지정해 놓았을 때는 사용할 수 없다.
그리고 내 프로그램에서는 선택된 이모지를 복사하기, 그리고 cursor가 가리키는 이모지를 문자표에서 찾아서 역으로 표시하기 같은 기능도 갖추고 있다.

예전에도 언급했듯, 2018~19년에 걸쳐 추가된 ‘필기 인식’과 ‘이모지’는 날개셋의 고유 기능이 아니라 운영체제가 제공하는 기능을 자체적인 UI 껍데기를 씌워서 제공하는 대표적인 입력 도구이다. Full feature를 갖춘 한글 IME로서 저런 기능도 한 프로그램 내부에서 제공할 필요가 있기 때문이다.

뭐 그건 그런데.. 운영체제에서 기본 제공하는 이모지 문자표는 응용 프로그램에다가 어떤 방식으로 이모지 문자를 보내는 걸까? 그게 갑자기 궁금해졌다. 쟤는 기술적으로는 ‘날개셋 입력 패드’과 비슷하게 훅킹을 사용해서 IME 메시지를 보낼 것 같은데..

프로그램이 TSF를 감지하는지 여부를 따져서 지원하면 TSF 방식으로 문자를 보내고, 그렇지 않으면 기존의 IME 메시지를 보낸다는 것을 확인할 수 있었다. IME 메시지만을 사용하는 날개셋 입력 패드보다 더 고차원적이다. 사실, TSF를 지원해야만 메트로 앱에서도 이모지를 입력할 수 있을 것이다.

날개셋 입력 패드를 처음 개발하던 시절에 본인도 개인적으로는 TSF 방식을 뚫어 볼까 생각을 했었다. 이게 성공하면 외부 모듈뿐만 아니라 입력 패드도 편집기와 비슷하게 주변 문자를 자유자재로 변형하면서 신기한 기능을 제공할 수 있다.

그러나 외부 모듈 하나만 개발해 봐도 내 경험상 TSF는 기술 난이도가 헬이고 응용 프로그램별로 제멋대로 동작하는 구현의 파편화가 너무 심하다. 더구나 그 TSF의 혜택을 보는 프로그램은 매우 소수이며, 편집기와 외부 모듈 다음으로 입력 패드 자체도 사용 빈도가 매우 낮은 제3군의 실험적인 유틸일 뿐이다.

그렇게 TSF를 뚫어 봤자 훅킹은 어차피 메트로 앱에서는 통하지도 않기 때문에 그 단계에서 막히니..
시간과 노력 대비 타산이 맞지 않는다는 결론을 얻어서 그 이상의 연구는 포기했다. 입력 패드는 write-only인 IME 프로토콜만 사용하는 데스크톱 앱 전용 프로그램으로 굳어져서 오늘에 이르고 있다.

5. 유니코드 5.2 자모

아시다시피 지난 10여 년 전에 KS X 1026-1 및 유니코드 5.2에서 옛한글 자모가 여럿 추가되었다. 시기가 시기이다 보니 연속된 공간을 쭉 확보하지 못하고 덕지덕지 지저분하게 추가되었지만, 그래도 잘 살펴보면 프로그래머의 관점에서 복잡함과 불편함을 최소화하는 방식으로 추가되었음을 알 수 있다.

답부터 말하면, 어떤 글자가 한글 초성인지 중성인지 종성인지 판별하기 위해 과거(유니코드 1.1)에는 A<=X<=B라는 영역 검사 하나만이 필요했다. 이제는 그래도 그 영역 검사가 각 성분별로 하나씩만 더 추가되면 된다.

  • 초성은 U+1100부터 1159까지 하던 영역에서 끝부분을 115E로 늘린 뒤(5개 추가), A960부터 A97C라는 새로운 영역 한 곳만 더 살펴보면 된다.
  • 중성은 U+1160부터 11A2까지 하던 영역에서 끝부분을 11A7로 늘린 뒤(5개 추가), D7B0부터 D7C6이라는 새로운 영역을 더 살펴보면 된다.
  • 종성도 그런 식으로 기존 영역을 조금 확장하고 나서 새로운 영역을 더 살펴보면 된다.

잘 알려져 있지 않지만, KS X 1026-1은 종성에 ㅇ으로 시작하는 겹받침(ㅇㄱ, ㅇㄲ, ㅇㅇ, ㅇㅋ)을 그냥 이응이 아닌 옛이응으로 수정한 규격(잠수함 패치..)이기도 하다.

그리고 KS X 1026-2는 정규화 규칙을 추가로 규정해서 현대 한글을 옛한글 자모의 조합으로 표현하는 것을 금지하고, 현대 한글 글자마디와 옛한글 자모가 합성되는 것도 명시적으로 금지했다. 한 한글은 오직 한 가지 방식으로만 표현되게 했다.
Windows는 2012년에 나온 8부터 저게 반영됐고, 날개셋 편집기에서는 지난 2015년에 나온 8.0 버전에서야 반영됐다. 저 표준을 제정한 분과 개인적으로 얘기까지 나누며 설명을 들은 뒤에야 말이다. 엇, 그러고 보니 둘 다 8부터네?!?

유니코드 2.0에서 한글 글자마디 11172자를 따 온 건 예전에 서울 올림픽 유치 성공만큼이나 역사에 길이 남을 위대한 쾌거였다. 현대 한글이 그렇게 정립된 뒤에 옛한글도 저렇게 됨으로써 한글 코드 논란은 완전히 종식됐다.

그 뒤로 유니코드 자체도 2003년쯤이던가 4.0에서 U+10FFFF라는 상한을 명확하게 정하고, 이 이상 글자를 더 등록하지는 않을 것이라고 못을 박았다. 그 이상은 UTF-16으로는 더 표현할 수가 없기 때문이다. 그래서 UTF-8도 4바이트 방식까지만 사용하고 5~6바이트 방식은 봉인했다.

따라서 현재 유니코드에 정의된 모든 평면이 고갈되고 글자들로 꽉 차는 날이 온다면.. 유니코드 위원회는 해산될 것이다. 지금의 문자 코드 체계는 지구와 현 인류 문명이 송두리째 멸망하지 않는 한 쭉 이어질 것으로 보인다.

Posted by 사무엘

2020/07/14 19:32 2020/07/14 19:32
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1773

1. 16색 팔레트

과거에 컴퓨터에서는 컬러를 표현할 수 있긴 하지만 해상도가 낮고 색깔수도 아주 제한됐던 시절이 있었다. 특히 고해상도라는 게 기껏 640*480이었고, 이 해상도에서는 표준 VGA 기준으로는 겨우 16색밖에 표현할 수 없었다. 1980년대 말에는 가로· 세로의 픽셀수가 모두 8비트 범위를 벗어난 것만으로도 고해상도라는 소리를 들었던 듯하다.

16색으로 가장 균형 잡힌 색상 팔레트를 꾸미는 방법은 뭐 뻔하다.
RGB 각 축별로 0, 1 조합을 시켜서 검정부터 하양까지 2^3 = 8색을 만들고, 이것보다 한 단계 더 밝은(혹은 어두운) 8색을 추가해서 16색을 만들곤 했다. 기본색 8색은 적록청과 흑백, 그리고 혼합된 색인 청록, 분홍, 노랑이다.

제일 단순하게 생각하면.. 어두운 그룹에서 비트별 on/off는 각각 128/0을 배당하고, 밝은 그룹에서 on/off야 최대치인 255/0을 배당한다.
다만, 0~15까지의 16색 중에서 7번(어두운 그룹의 가장 밝은 색)과 8번(밝은 그룹의 가장 어두운 색)은 각각 밝은 회색과 어두운 회색인데 얘는 예외적으로 각각 (192,192,192)와 (128,128,128)로 간주한다. 이렇게 하지 않으면 7번 색이 어두운 회색이 되고, 8번 색은 0번 검정(0,0,0)이 중복 배당되기 때문이다.

요게 바로 산술적으로 제일 단순하게 유도되는 팔레트이다.

사용자 삽입 이미지

하지만, 도스 시절에 EGA/VGA 그래픽 카드가 실제로 제공했던 기본 16색은 이와 대동소이한 차이가 있었다.
(1) 먼저, 어두운 그룹의 가중치가 128이 아니라 170 (0xAA)이어서 전반적으로 저것들보다 더 밝았다. 난 168인 줄로 오랫동안 알고 있었는데, 지금 다시 찾아보니 그렇지 않고 170이다. 최대치인 255의 정확히 2/3에 해당하는 값이다. 어째 256은 2의 8승이지만, 255는 3의 배수였구나.

(2) 그리고 밝은 그룹이야 on의 가중치는 응당 255이지만, off의 가중치가 0이 아니라 85이다. 그래서 밝은 파랑도 그저 (0,0,255)가 아니라 (85,85,255)이다. 앞서 언급된 단순 팔레트가 0 1/2 1로 색깔을 쪼갰다면 얘는 더 세분화해서 0 1/3 2/3 1을 추구한 셈이다.
이 체계에서는 따로 보정을 하지 않아도 7번은 산술적으로 자연스럽게 (170,170,170)이라는 밝은 회색이 되고, 8번은 (85,85,85)인 어두운 회색이 된다. 다른 색들은 전반적으로 단순 팔레트보다 더 밝지만, 회색은 어째 단순 팔레트보다 더 어두워졌다.

(3) 또한 VGA 팔레트는.. 구체적인 이유는 알 수 없지만 6번 색을 산술적인 (170,170,0) 어두운 노랑? 올리브색 대신, (170,85,0)으로 예외적인 변화를 줬다. 올리브색 대신 갈색을 만든 것이다. 노랑은 원래 밝은 색인데 어두운 노랑은 정체성이 모호하니.. 갈색이 더 실용적일 거라고 생각했던 모양이다.
그래서 VGA 팔레트는 단순 팔레트보다 약간 더 알록달록하고 채도가 높아졌다.

사용자 삽입 이미지

끝으로, Windows도 독자적으로 약간 변화를 준 16색 팔레트를 사용했다.
밝은 그룹은 255/0으로 간단하지만 어두운 그룹이 상황이 약간 복잡하다. on의 가중치는 170인데, off의 가중치는 0과 85가 뒤섞인 편이다.

파랑은 깔끔하게 (0,0,170)이지만 빨강과 초록에는 파랑이 반 정도 섞여서 각각 (170,0,85)와 (0,170,85)이다.
혼색인 cyan과 분홍, 올리브에도 색이 full로 들어가지 않은 나머지 축에는 0이 아닌 85가 들어간다. VGA와 달리 갈색 보정은 없고 올리브색은 (170,170,85)이다.

의외인 것은 7, 8번 회색들이다. 각각 (195,199,203), (134,138,142)로, RGB 값이 모두 근소하게 다른 별개의 가중치가 부여돼 있다. 흑백과 더불어 화면에서 제일 많이 보게 될 중립 무채색이니 나름 심혈을 기울여 이런 색을 만들었지 싶다.

사용자 삽입 이미지

지금까지 소개된 팔레트 세 종을 한데 늘어놓고 비교하면 다음과 같다.
Windows 팔레트는 밝은 그룹은 단순한 팔레트와 비슷하고, 어두운 그룹은 갈색 보정 여부만 제외하면 VGA 팔레트와 더 비슷하다고 볼 수 있다.

사용자 삽입 이미지

Windows의 경우, 고전 테마 GUI나 명령 프롬프트에서 기존 VGA 16색을 표시할 일이 있을 때 256색/high/true 컬러일 때는 128/255 기반의 단순 팔레트를 사용한다. 그러나 16색일 때만은위와 같이 약간 더 밝아진 팔레트를 사용한다.
그래서 똑같은 색상표를 사용하더라도 16색이다가 상위 색상으로 모드를 바꾸면 화면이 더 어둡고 차분하게 착 가라앉은 듯한 느낌이 든다. 흥미로운 점이다.

사용자 삽입 이미지

2. 256색 VGADemo

1990년대 초· 중반에 도스에다 Windows 3.1 정도나 설치돼 있던 컴에서는 일반적으로 util\tool이라는 디렉터리가 있었고, 여기에 각종 파일 압축 프로그램, 하드디스크 파킹, 파일 관리 셸 등 단독으로 돌아가는 자잘한 싸제 유틸리티들이 들어있곤 했다. 어느 디렉터리에서나 실행 가능하게 path도 걸려 있고 말이다.

그때 본인의 컴퓨터에 들어있었던 '툴' 프로그램 중에는 com인지 exe인지는 기억 안 나지만 vgademo라는 자그마한 프로그램도 있었다.
게임이 아니면서 VGA 320*200 256색 13h 모드로 진입해서 완전 현란한 팔레트 스크롤과 함께 선과 폴리곤, 원 그리기 따위를 선보이는 2D 그래픽 데모였다.

사용자 삽입 이미지

맨 처음에는 저렇게 동그란 그러데이션 형태의 인트로 화면이 나온다. 이때 space를 누르면 본 게임(?)이 시작된다.
한참 알아서 그림을 그리다가 일정 주기로 씬이 자동으로 바뀐다. 그럼 기존 화면은 fadeout 되기도 하고 모자이크 처리되면서 사라지기도 했다. (모자이크가 점점 더 커짐)

사용자 삽입 이미지

이거 단순히 난수 생성해서 아무렇게나 선을 찍찍 그어대는 게 아니다. 여러가지 그리기 시나리오와 화면 전환 조건, 무작위한 팔레트 스크롤 방식 등에 대해 나름 치밀한 설계가 필요하다.
CGA, EGA만 구경하다가 VGA에서 게임도 아니면서 이런 그래픽을 뿜어내는 프로그램을 PC에서 접했을 때 사람들이 적지 않게 놀랐지 싶다. 1990년대 초에 말이다. 해상도를 극도로 희생했지만 256색을 표현할 수 있게 된 덕분이다.

누가 언제 만든 무슨 이름의 프로그램이었는지 알 길이 없었는데.. 검색을 통해 razzle dazzle이라는.. 바로 요놈이라는 것을 나중에 파악할 수 있었다.
나름 셰어웨어 형태로 돈 받고 팔았고, 90년대 말까지 개발이 됐던 프로그램이었다. 그 시절에 유행했던 프로그램  장르인 눈요기 화면 보호기로는 꽤 적합했지 싶다.

Posted by 사무엘

2020/06/11 19:35 2020/06/11 19:35
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1761

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 사무엘

2020/05/14 08:36 2020/05/14 08:36
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1751

1. software is licensed, not sold

자동차의 소유 내지 운전 면허하고, 소프트웨어의 사용권은 공통점과 차이점을 비교해서 같이 생각해 볼 만한 사항인 것 같다. 자동차는 도난 방지 기능이 있고, 소프트웨어는 불법 복제 방지 기능이 있기 때문이다.

전자의 경우 옛날에는 전통적으로 물리적인 열쇠에만 의존하다 보니 보안이 상대적으로 취약했다. 수천 대 중 한 대꼴로 자물쇠 패턴이 일치하는 차량이 존재하기 때문에 그런 차는 내 키로 문을 열 수 있었다. 컴퓨터로 치면 마치 hash의 충돌과 비슷한 상황이라 하겠다.
그리고 영화 테이큰에서도 보듯이 열쇠 구멍을 적당히 쑤셔서 문을 따고, 비정상적인 방법으로 스타터 모터에 전기 자극을 줘서 시동을 걸 수도 있었다.

이런 상황을 막기 위해 과거에는 3rd-party 업체에서 개발한 싸제 도난 방지 시스템이 많이 쓰였다. 지정된 인증을 통과하지 않으면 물리적인 열쇠만으로 문을 따거나 시동을 걸 수 없으며, 오히려 경보음이 울리게 하는 것 말이다. 지금이야 이 정도 도난 방지 기능이 들어간 스마트키는 옵션이 아니라 자동차 제조사에서 기본으로 제공해 주는 영역이 됐다.

그럼 소프트웨어는 어떨까?
과거에는 좀 묵직하고 규모가 있는 제품은 병렬 포트에 락을 꽂는 것(..!)부터 시작해 하드웨어· 소프트웨어적인 온갖 방법으로 "귀하(= 소프트웨어 개발자/개발사)의 소중한 자산을 안전하게 보호하십시오"라고 광고하는 복제 방지 솔루션이 있었다. 하지만 그런 것들은 해커들이 작정하고 공략하면 몽땅 크랙 되는 건 시간 문제일 뿐이었다.

그나마 인터넷이 발달한 게 소프트웨어의 복제와 배포뿐만 아니라 개발사에서 사용자의 접속 여부를 파악하는 것까지(= 정품 인증) 용이하게 만들어 줬으니 호재이다. 스타크래프트도 배틀넷에 접속할 때만은 CD key를 체크했듯이 말이다.

자동차는 철저하게 자기 소유 위주이고 운전만 면허이지만, 소프트웨어는 처음부터 소유라는 개념 없이 사용권이 허가되는 것이라고 여겨진다. 영어로는 똑같이 license라고 한다.
자동차는 물리적인 실물이 존재하고 조작하는 것이 매우 위험한 물건이지만, 소프트웨어는 실물이 없이 무한 복제가 가능하고 사용 자체에 위험성은 없는 물건이라는 차이가 있다. 형태가 서로 매우 극과 극이라 하겠다.

그래서 불가피한 상황에서 자동차 문을 따거나 배선을 뜯어고쳐서 키 없이 시동 거는 방법을 소개하는 동영상을 보면.. "남의 차에다가 이 짓을 하는 건 불법입니다. 반드시 자기 소유의 차에다가만 at your own risk로 시도하세요!"라는 주의 문구가 있다.

소프트웨어도.. 정품 사용자가 자기 개인 소장용으로만 복제판을 만들거나.. 혼자 쓰는데 번거로워서 정품 인증 절차를 없앤(..) 크랙을 돌리는 것은 내가 알기로 합법이다. 글쎄, 단순 복제판을 넘어서 후자는 엄밀하게 따지면 사용권 계약서에 명시된 "리버스 엔지니어링과 변조 금지"의 위반일 수 있겠지만 그것까지 현실적으로 다 따지고 잡아내고 법을 집행하는 건 거의 불가능에 가깝지 싶다.

소프트웨어의 라이선스는 대외 공개 여부, 유료/무료, 소스 공개 여부 같은 변수를 따져서 다음과 같은 범주로 나눌 수 있겠다.

2. 소프트웨어 라이선스의 등급

(1) 존재 자체가 영업 기밀: 개발사의 내부에서만 쓰이며, 돈을 아무리 많이 준다 해도 애초에 남에게 판매 자체를 하지 않는다. 주로 서버(호스트) 사이드 프로그램, 혹은 소프트웨어 개발을 위해 내부적으로만 쓰이는 아주 특수한 도구가 이 범주에 속한다. 이런 프로그램의 내부를 외부인이 구경하고 싶으면 아예 개발사를 통째로 사 버리고 인수해야 할 것이다.. >_<

(2) 상업용: 돈 받고 사용권을 판매하는 상업용 소프트웨어들. 옛날에는 제품을 디스크에 담고 패키지로 포장해서 일시불로 무기한· 영구적인 사용권을 제공했으나, 지금은 프로그램 자체는 웹사이트에서 받게 하고 사용권을 기간제로 찔끔찔끔 제공하는 형태가 대세이다. 얘부터는 소스 코드만이 영업 기밀이다.

(3) 무료 공개: 누구나 무료로 사용 가능하다. 하지만 제공된 형태 그대로 제품을 사용하는 것 말고 상업적 목적의 재배포, 변조 등등은 여전히 금지이다. 날개셋 한글 입력기는 이 등급이다.

(4) GPL 오픈소스: 단순히 무료 사용을 넘어서 소스까지 공개인 파격적인 제품이다. 하지만 저작권 자체가 아예 없는 건 아니며, 얘는 전염성, 즉 "오픈소스 덕을 봤으면 너도 오픈소스에 동참하라" +_+라는 이념이 담긴 등급이다. 그렇기 때문에 기업 영업 기밀에 속하는 소프트웨어에다 GPL 기반의 코드를 쓸 수는 없다.

(5) LGPL 오픈소스: GPL보다는 조건이 완화됐다. 요 등급은 상업용 제품에다가 끌어다 쓰더라도 자기 코드를 공개하지 않아도 된다. 요즘 많이 쓰이고 있는 MIT 라이선스도 이쪽 계열인 걸로 안다.
다만, 있는 그대로 쓰는 게 아니라 좀 변조해서 쓴다면 어떻게 바꿨는지 그 변조한 코드만은(자기 코드 말고) 공개하라는 식으로 바리에이션이 있다.

(6) public domain: 너무 오래돼서 저작권이 소멸됐거나, 저작권을 주장하는 주체 자체가 사라져서 존재하지 않거나, 아니면 이도 저도 아닌데 개발자가 너무 대인배여서 저작권을 주장하지 않고 "완전 니 마음대로 쓰셈"을 시전한 경우이다. SQLite처럼 드물게 public domain인 제품이 있다.

요 6등급 분류가 굉장히 깔끔하긴 하지만.. 현실에서는 이 범주에 딱 정확하게 떨어지지 않는 물건도 있다.

(1) 태생적인 반제품: 요즘은 소프트웨어라는 게 전반적으로 릴리스 후에도 끊임없이 보안 패치를 해야 하는 반제품 형태가 돼 있다. 하지만 그것 말고 미들웨어 라이브러리 같은 제품 중엔 유료로 판매되는 상업용이면서 아무 end-user에게나 판매하지 않고, 구매자에게 소스를 제공하는 형태가 있다.

(2) abandonware: 도스용/16비트용 프로그램들, 아래아한글 3.0/97, Windows 95/XP 따위.. 오늘날 아무도 실생활에서 사용하지 않는 옛날 구버전 소프트웨어들은 아무래도 상업적인 가치는 없다. 하지만 개발사에서 판매와 지원을 중단했다고 해서 그 프로그램의 저작권 자체가 법적으로 소실된 건 아니다. 저작권이야 거의 70년인가 그 동안 유지되기 때문이다. abandonware가 곧 public domain을 의미하지는 않는다.

그러니 한물 갔다고 해서 과거의 상업용 소프트웨어를 마음대로 불법복제 해서 써서는 안 된다. 개발사에서 정식으로 무료화를 선언하지 않은 한 말이다. 허나, 이제 더 정식으로 판매되지 않고, 돈 주고 사겠다고 해도 구할 수 없어서 복제해서 쓰는 걸 누가 어떻게 뭐라 하겠는가? 그런 구닥다리 제품으로 복돌이가 개인 단위로 무슨 금전적인 이익을 얻고 있을 리도 없고..
이런 이유로 인해 현실적으로는 개발사에서 저 정도는 사실상 그냥 방치· 묵인해 주고 있을 뿐이다.

3. 오픈소스

요즘 어지간히 규모 있는 소프트웨어에서 about 대화상자나 도움말의 한구석 acknowledgements란을 꺼내 보면.. 이 제품이 내부적으로 사용한 방대한 오픈소스 라이브러리 목록이 없는 경우를 찾기 어려울 것이다. 동영상이나 일반 데이터 압축, 암호화, 영상 처리, 폰트 렌더링, 심지어 머신러닝…

그 정도 규모와 기능이면 돈 받고 판매하는 미들웨어 솔루션으로 손색이 없을 텐데 이런 게 소스까지 공개로 죄다 풀리니 요즘 소프트웨어들은 기술 수준이 엄청나게 상향평준화될 수밖에 없다. 소프트웨어 업계는 자동차 같은 다른 업계에는 존재하지 않는 '오픈소스'라는 진영 내지 이념· 트렌드 때문에 판도가 굉장히 크게 바뀌었다.

이 진영이 없었으면, 혹은 오픈소스라 해도 몽땅 무식한 GPL 일색이어서 사실상 무용지물이었다면.. 컴퓨터에서 같은 기능을 사용하더라도 소비자는 더 비싼 제품을 써야 하고, 개발사는 여기 저기 로얄티를 내야 하는 게 많았을 것이다.

기능을 사용하는 것 자체는 몽땅 무료로 풀리게 됐으니.. 소프트웨어 업계는 그 사용자들이 무슨 기능을 즐겨 사용하고 무슨 생각과 취향을 갖고 있는지를 수집하고 분석하고.. 이걸로 "어떤 더 고차원적인 돈벌이를 할 수 있을까, 어떻게 하면 사용자의 취향을 더 정확하게 저격한 광고를 내보낼 수 있을까"를 고민하게 된 듯하다.

물론, 마소에서 개발한 소프트웨어에서 zlib나 FreeType, libPNG를 사용했네, MIT/LGPL 라이선스를 준수하네 이런 식의 acknowledgement를 볼 일은 지금까지 없었다. 걔네들은 오픈소스 진영과 동떨어진 채 타사에서 유료 구입하거나 자체 개발해 놓은 밑천이 워낙 많으니 어지간한 상황에 대해서는 그런 게 필요하지 않았던 것이다.

하지만 언제까지나 그렇게 지낼 수는 없을 것이고, 지금은 마소도 옛날 빌 게이츠/스티버 발머 시절처럼 오픈소스에 적대적인 독불장군이 절대 아니니 오픈소스 진영과 엮이는 비중이 차차 늘 것으로 보인다.

4. 소프트웨어 라이선스의 종류

이렇게 각종 소프트웨어들이 소스째로 무료로 풀렸다는 게 모든 지적 컨텐츠들이 풀려서 개나 소나 아무렇게나 사용해도 된다는 말은 결코 아니다. 오늘날 컴퓨터로 남이 만든 것을 활용해서 이를 바탕으로 또 뭔가 새로운 걸 만드는 일을 하는 사람이라면 그 어느 때보다도 저작권에 대한 인식을 분명히 하고 있어야 한다.

컴퓨터가 실행하는 코드의 집합체인 소프트웨어 프로그램뿐만 아니라 디지털 폰트, 그리고 하다못해 짤막한 4단짜리 찬양 악보나 노래 음원 하나라도 무료 사용이 허용되는 조건이 까다로워지는 것이 요즘 추세이다.

물론, 개인이 혼자 집에서 무료로 비영리 목적으로 사용하거나 보고 듣고 즐기는 것을 막는 저작권자는 사실상 없다. 음악, 특히 찬송 같은 건 알려져서 자기 곡이 어느 교회건 예배 때 회중 찬송으로 불리는 것을 싫어할 작곡자는 없을 것이다. 그러나 반대로 임의의 개작, 개조, 제작자 변조, 무단으로 상업적 활용 같은 걸 허용하는 저작권자는 이 세상에 존재하지 않는다.

운전 면허가 자가용과 사업용이 나뉘어 있듯, 소프트웨어의 사용권도 그런 형태로 나뉘는 경향이 있다.
폰트는 유료로 구매했다 하더라도 자기 개인 단위의 인쇄물이나 웹페이지에서만 사용할 수 있는 1차 라이선스, 더 나아가 옥외 간판이나 본격 상업 매체에 적용되는 2차 라이선스, 아예 제품에 범용적으로 포함되거나 특정 BI/CI에 들어가고 자기들만이 독점적으로 사용하는 전속 서체 급의 3차 라이선스 형태로 나뉘어진다.

반디소프트의 반디집의 경우 2020년 7.0 버전부터 유료 버전을 따로 내놓기 시작했는데, 파워 유저를 대상으로 하는 개인 단위 유료(프로) 에디션, 그리고 기업에서의 사용을 염두에 둔 PC 단위 유료(엔터프라이즈) 에디션을 내놓은 게 무척 독특하다. 현실성 있는 유료화 정책에 대해 개발사에서 고민을 많이 한 것 같다.

엔터프라이즈 에디션을 구매하지 않은 기업 내부라고 해도 각 직원이 무료 에디션은 여전히 사용할 수 있다. 그 대신 얘는 광고가 뜨며, 기업 서버와의 최소한의 접촉을 막을 수 없다(업데이트 체크, 언제나 온라인으로만 설치).

이런 라이선스 종류는 아까 같은 영업기밀~소스 공개 같은 수직 비교와는 다른 양상의 수평 비교라고 볼 수 있을 듯하다.

Posted by 사무엘

2020/03/12 08:35 2020/03/12 08:35
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1727

1. 동영상

유튜브가 광고 없는 유료 프리미엄 서비스를 밀고 홍보하기 시작하더니, 2019년 하반기쯤부터는 반대로 일반 무료 상태에서는 광고가 예전보다 더 길어지고 잦아진 것을 다들 느끼실 것이다. 원래 5초 1회로 시작했던 것이 6~7초 2회로 늘었다. 요런 걸로 유료 가입자를 확보하고 수익을 내려는가 보다.

하긴, 유튜브는 인터넷에서 깨진 동영상 링크라는 걸 없애고, 오프라인 다운로드가 당연하다고 여겨졌던 60프레임 HD급 초고화질 동영상까지 실시간 스트리밍으로 실현한 엄청난 사이트이다. 모니터 주사율만 해도 평소에 50~60Hz를 쓰다가 75Hz이상을 맞추면 화면이 훨씬 더 부드러워진 게 느껴지는데.. 동영상도 60프레임짜리를 보면 화질을 떠나서 움직임이 확~ 더 자연스럽고 부드럽고 보기 편한 게 티가 난다.

쟤는 그냥 지구상에 존재하는 모든 영상 기록들의 아카이브인 동시에 전세계의 개인 방송, 교회 설교 같은 것까지 몽땅 감당하고 있다. 집에 TV가 없어도 유튜브가 TV나 마찬가지이다. 동영상을 하나 보기 시작했다가 같이 뜨는 관련 동영상까지 섭렵하다 보면 시간 가는 줄 모른다.

이런 괴물이 등장할 거라고는 198, 90년대의 그 어떤 SF 작가도 예상하지 못했으며..
저걸 돌리려면 평소에 서버 유지비도 정말 장난 아니게 들지 싶다.;;; 이걸 버틸 재간이 안 되는 국내의 중소 동영상 포털들은 수지가 안 맞으니 2010년대 초· 중반을 못 넘기고 다들 망했다.

한 20여 년 전에 컴퓨터에서 동영상이라는 건 그냥 320*240의 자그마한 화면에서 노이즈 대신 JPG artifact가 가득한 허접한 화질로 보는 avi, mpg, mov가 전부였다. 전반적인 화질은 기존 VHS 비디오 테이프보다 결코 좋을 게 없고, 단지 아날로그가 아닌 디지털이라는 의의만 있을 뿐이었다.
1990년대 초-중까지는 MPEG1/2급 동영상을 시청하기 위해서 별도의 그래픽 가속 하드웨어를 장착해야 할 정도였다. 동영상 캡처/인코딩이 아니라 단순 시청을 위해서도 말이다. 이런 가속은 통상적인 3D 그래픽용 가속과는 별개의 분야일 것이다.

그러다가 한 2000년경엔 갑자기 온갖 코덱들이 난립하기 시작해서 통합 코덱 패키지가 나오고, '사사미'라고 자막이 화면에 깔끔하게 입혀진 채로 뜨는 새끈한 동영상 재생기가 개발되었다. 이때까지만 해도 고화질 영화· 애니 동영상은 각종 P2P 불법 공유 네트워크를 통해 많이 오갔던 것 같다.
온라인 실시간 스트리밍으로는 어림도 없고.. 유튜브만 해도 2010년대 이전에는 여전히 3~400대 해상도에 머물러 있었으며 동영상 하나당 10분 시간 제한까지 있었다. 지금으로서는 믿어지지 않을 것이다.

난 동영상 압축 알고리즘에 대해서는 아는 게 별로 없다. 인접한 프레임, 그리고 인접한 픽셀들이 서로 유사하다는 것을 이용해서 차이점만 담는다는 것이 골자일 텐데.. 이건 컴퓨터에서 캐시의 개념을 설명할 때 언급하는 시간 지역성, 공간 지역성하고 비슷한 개념 같다. 그나마 동영상 재생 및 압축 기술이 다들 대인배 오픈소스로 풀려 있기 때문에 사람들이 폰이나 PC에서 더 저렴하고 간편하게 동영상을 즐길 수 있다.

2. CPU의 다양다변화, 병렬화

21세기에 컴퓨터 CPU에서 단일 코어 클럭 속도의 '기하급수' 증가가 드디어 멈췄다. 그 대신 지금까지 슈퍼컴퓨터 세계의 전유물로 여겨졌던 멀티코어가 개인용 PC에도 등장하게 됐다. 이게 1차 변화이다.

그래서 어느 플랫폼에서나 동일한 방식으로 스레드를 생성하라고, CPU의 여러 코어를 잘 제어하고 활용하라고 OpenMP라는 규격이 제정되기도 했다. 이건 특정 연산에 대해서 적당히 병렬화하라고 지시를 내리는 여러 C 함수와 언어 확장, #pragma들의 모음이다. 난 지금까지 UI의 반응성 향상을 위해서만(= 백그라운드 작업) 스레드를 사용해 왔지, CPU 자원을 몽땅 쪽쪽 빨아서 쓰기 위해서 스레드를 동원해 본 적은 없었다.

요즘 컴퓨터들은 뺑뺑이를 돌려 봤자 전체 CPU 사용량이 10%대밖에 되지 않는 건 사실이다. 하지만 그렇다고 해서 별다른 최적화 없이 무턱대로 스레드를 만들어서 CPU 사용량을 늘리면 그래 봤자 throughput이 그저 전체 CPU 사용량에 비례해서 팍팍 오르는 것은 확실히 아니어 보인다.

작업 스레드를 만들면 각 작업들의 수행 속도도 눈에 띄게 느려지기 때문이다. 이는 어지간한 하이엔드급 컴에서도 관찰 가능한 현상이다. 뭐랄까, 작업 스레드가 증가하면 context switching 같은 다른 오버헤드도 추가되어서 전체 효율이 떨어지는 것 같다.

프로그램을 너무 많이 띄워서 메모리가 부족해지면 가상 메모리 페이징(디스크 스와핑)만 죽어라고 하느라 컴퓨터의 작업 수행 속도가 급락한다. 좁은 화면에 창을 너무 많이 띄우면 사람도 창 전환만 하느라 작업 능률이 급락하며, 반대로 모니터를 여러 개 연결하는 건 생산성을 사기급으로 향상시킨다.
이와 마찬가지로 CPU의 성능에 걸맞지 않게 작업 스레드가 너무 많아지만.. 작업 전환 비용의 증가만으로 성능이 극도로 떨어질 수 있겠다.

그런데 요즘은 그걸로 끝이 아니다. 게임용 3D 그래픽 렌더링이나 좀 보조하라고 만들어졌던 add-on인 GPU도 거기에만 쓰는 게 아깝다. 굳이 3D 그래픽이 아니어도 그것처럼 단순무식하고 물량빨인 계산 작업이 있으면 거기에도 GPU를 투입할 수 있다. 특히 살인적인 노가다 계산이 필요한 머신러닝 분야에서 GPU 연산이 더욱 각광받기 시작했다.

그러니 이것도 별도의 프로그래밍 영역이 됐다. nVIDIA에서 GPU 활용 프로그래밍을 위해 OpenMP와 비슷한 컨셉으로 CUDA라는 라이브러리를 내놓았다. 이건 그냥 인텔 내장 그래픽을 쓰는 노트북 같은 기계에서는 활용할 수 없다는 것이 멀티코어 CPU와 다른 점이다. 그것 말고 OpenCL 같은 다른 GPU 라이브러리도 등장했다.

하긴, 아직 싱글코어 시절일 때도 아까 얘기했던 동영상 정도의 멀티미디어 처리를 위해서 인텔에서는 SIMD(1명령 다중 데이터) 정도의 병렬 처리를 지원하는 명령을 도입한 적이 있었다. 그게 옛날 1990년대 말의 펜티엄 프로~III 기간에 추가된 MMX 내지 SSE 명령이다. 얘가 기존 x87 명령을 대신해서 부동소수점 연산까지 처리한다.

옛날에 하드웨어의 성능을 극한으로 짜내는 게임을 만들려면 어셈블리어를 알아야 하고 비디오 메모리에 직통으로 내용을 직접 뿌린다거나 해야 했다. 지금은 특정 CPU의 인스트럭션을 써 주는 짓은 필요 없지만, 그것과는 좀 다른 양상으로 하드웨어를 직접 다루는 최적화 테크닉이 필요한 시대가 되어 있다.

3. 슈퍼컴퓨터 내지 CPU 아키텍처의 명멸

본인은 어린 시절에 슈퍼컴퓨터라고 하면 덩치가 크고, 내부에 무슨 금칠이라도 했는지 가격이 억소리 나게 비싸면서.. 개인용 PC보다 메모리가 훨씬 더 방대하고 반응 속도가 수십 수백 배 정도 더 빠른 물건 정도로나 생각했다.
뭐, 20세기 옛날에는 개인용 컴퓨터 대비 전용 슈퍼컴의 차이가 그런 단순한 차이점에 더 근접해 있기도 했다.

하지만 오늘날은 개인용 PC가 10~20년 전의 업계 최고의 슈퍼컴보다 더 빠르다. 마치 오늘날의 무선 인터넷이 10~20년 전의 유선 인터넷보다 더 빠르듯이.. 정말 경이로운 노릇이다.
이제 슈퍼컴이라고 해서 개인용 PC보다 단순히 기계적으로 무식하게 더 빠르지는 않다. "개인용 PC가 64비트 3~4GHz대니까 슈퍼컴은 machine word가 256비트이고 클럭 속도는 40GHz 정도 하겠지"가 아니라는 뜻이다.

이제는 슈퍼컴 전용 아키텍처, 전용 운영체제 같은 것도 존재하지 않으며, 비트 수가 차이 나는 것도 아니고.. 다 똑같이 x86이다.
차이가 나는 건 계산을 위한 코어수뿐이다. 그걸 정교하게 제어하는 별도의 프로그램을 짜서 돌려야 슈퍼컴의 성능을 제대로 활용할 수 있다.

단일 코어의 클럭 속도는 이제 개인 PC도 슈퍼컴과 비슷하거나 더 나으면 낫지, 결코 뒤쳐지지 않는다.
그냥 단일 코어만 열나게 돌리는 PC용 PI 계산 프로그램을 그대로 돌리면 슈퍼컴이라고 해서 몇백만 자리가 즉시 짠~ 하고 튀어나오지 않는다.

옛날의 전용 패러다임과 재래식 생산 공정 하에서 슈퍼컴을 열심히 연구 개발했던 크레이 같은 공돌이가 오늘날의 컴퓨팅 환경을 본다면 놀라서 까무러치지 않을까 싶다.
통상적인 시뮬레이션· 계산용 슈퍼컴은.. 단순히 외부로부터의 대용량 트래픽 처리용인 고성능 서버하고는 지향하는 게 다르다. 스포츠 사격과 군대 사격이 다른 것만큼이나 다르다고 생각하면 될 듯하다. IBM 메인프레임은 둘 중 어느 용도에 더 가까운 걸까..?

오늘날은 PC가 성능이 워낙 향상되어서 PC와 슈퍼컴 사이의 경계 축에 들던 '워크스테이션'이라는 컴퓨터 체급도 의미가 많이 퇴색했다. 굳이 따지자면 맥 프로 같은 high-end급 PC일 뿐이겠지.
그 시절에 워크스테이션이란 운영체제도 OS/2나 솔라리스, NextStep, Windows NT 정도 돌리던 전문가 업무용 컴터였으며 가격은 거의 경차 한 대에 육박했었다. 노는 물이 도스나 Windows 3.1 따위하고는 완전히 달랐다.

이런 식으로.. 데스크톱 PC는 호환성이 깡패인 x86+x64 천지가 됐고, 모바일은 ARM인데 얘들도 PC로 호시탐탐 진출하려고 노력하는 중.. 거기에다 게임기는 아직 PowerPC가 살아 있나 모르겠고, 메인프레임에 IBM POWER 정도가 살아 있는 것 같다.
이젠 구글과 애플도 CPU를 직접 만들려고 하고.. 과거 Windows NT 3~4 시절과는 다른 의미의 CPU 아키텍처 춘추 전국 시대가 열리는 게 아닌가 모르겠다. 결국은 이식성 좋게 만들어진 소프트웨어가 승자가 된다.

4. 전자와 전산의 관계

가만히 생각해 보면.. C++ 언어로 Windows MFC 등.. 상대적으로 '특정 플랫폼 실무에 가까운 프로그래밍'을 자주 하는 사람은 전산· 컴공보다는 전자공학 쪽에 더 많았던 것 같다. 과거에 유명한 Visual C++ 프로그래밍 베스트셀러 책을 집필했던 분들도 전공이 그런 쪽이었다. 세부적으로는 로봇 공학이라든가 디지털 신호 처리 쪽으로 말이다.

그럼 진짜 전산· 컴공을 한 사람들은 뭘 하는가 하면.. 좀 더 크로스 플랫폼이나 오픈소스에 친화된 스타일의 코딩을 한다. 뭐, 웹 프로그래밍도 방법론은 사뭇 다르지만 크로스 플랫폼 프로그래밍의 범주에 들 테고..
특히 PL 쪽 덕후들은 C++ 같은 지저분한(?) 언어는 거들떠보지도 않고 Rust나 go 같은 더 마이너한 언어, 함수형 언어 같은 걸 즐겨 쓴다. 쉽게 말해 더 추상적이고 고차원적인(?) 걸 추구하는 듯하다.

아 그렇다고 모든 전자과 출신이나 모든 전산과 출신이 취향이 그렇게 갈린다는 말은 물론 아니다.
그리고 신호 처리는 전자공학이지만 컴퓨터그래픽스는 명백하게 전산학의 세부 분야인 것 같다. 요컨대 영상을 렌더링 하는 건 전산학이고, 그 생성된 영상을 손실 압축해서 저장하는 건 전자공학 쪽인 셈이다. 다음으로 영상 인식 같은 건 전자와 전산이 별 구분 없이 같이 파는 것 같다.

Posted by 사무엘

2020/02/16 08:36 2020/02/16 08:36
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1717

1.
작년 말(12월)부터 국내에서는 잘 알다시피 5G 이동통신 기술이 상용화 됐다. 그런데 그런 뉴스가 전해지기 전부터 언제부턴가 집과 각종 공공장소의 와이파이 접속명은 뒤에 5G가 붙기 시작해서 iptime5G 이런 식으로 바뀌었고, 속도도 더 빨라지긴 했다.
똑같은 전자기파와 똑같은 랜선을 쓰면서 어떻게 인터넷 속도가 이렇게 계속 더 빨라질 수 있는지 신기할 따름이다. 컴퓨터 클럭 속도는 멈춘 지 15년 가까이 됐지만, 현재까지 아직도 치트키 수준으로 경이롭게 증가하고 있는 건 인터넷 속도인 것 같다.

2.
컴퓨터 키보드의 글쇠들 주변을 보면, 다른 먼지들이 쌓여서 더러워지는 건 이해가 되는데 1~2cm 남짓한 길이의 솜털들은 도대체 어디서 떨어진 건지 모르겠다.
손가락 끝이나 손바닥서 털이 나는 것도 아니고, 사람 얼굴에서 떨어진 털이 거기로 갈 리는 없을 텐데.. 알 수 없는 노릇이다.

3.
옛날에 비해 컴퓨터 장치들이 독립성이 강화되고 더 똑똑해지는 게 느껴진다.
가령, 옛날에 모니터와 이어폰은 전통적으로 자신만의 전용 단자가 있으며(직렬· 병렬 포트나 USB 따위가 아닌), 컴퓨터의 입장에서는 꽂든지 말든지 소프트웨어적으로 별 차이나 반응이 없던 물건이었다.

그러던 것이 언제부턴가 컴퓨터에서 각 모니터의 탈착을 감지할 뿐만 아니라 그 모니터의 종류, 적정 해상도와 주사율까지 알아서 조절하게 됐다. 그리고 사운드 쪽도 이어폰을 꽂은 상태에서 볼륨을 너무 높이면 컴퓨터가 사용자의 청력까지 걱정해 주는 경지에 다다랐다.

옛날 브라운관 모니터는 밝기 조절, 채도 조절, 상하좌우 shift/resize를 전부 별도의 다이얼을 돌려서 해야 했다. 그러나 요즘 모니터는 자체적으로 컴퓨터 프로그램 UI가 내장되어 있기 때문에 메뉴와 화살표, 엔터 같은 키만 있다.
아울러, 노트북의 터치패드도 단순히 마우스와 호환되는 포인팅 장비가 아니라 자체적인 옵션을 갖고 있고(각종 제스처 인식 여부) 드라이버를 잡아 줘야 하는 물건으로 탈바꿈했다.

4.
본인이 회사에서 사용하는 컴퓨터는 CPU, 그래픽 카드, 메모리 등 하드웨어 전반이 전형적인 2010년대 중반급의 사양이고 별다른 이상이 없다. 그런데 화면의 반응이 왠지 굼뜨고 느리게 느껴져서 불편했다. 간단히 창을 마우스로 끌어서 이동시켜 봐도 모션이 매끄럽지 않고 미묘하게 랙이 걸려서 뚝뚝 끊기는 것 같았다.

듀얼 모니터 중 하나가 4K급 해상도여서 혹시 비디오/디스플레이 쪽으로 성능이 딸리는 병목이 존재하나 의문이 들었는데.. 그 예상이 반은 맞고 반은 틀렸다. 그쪽 문제인 건 맞지만 원인이 컴퓨터 쪽이 아닌 모니터에 있었기 때문이다.
모니터가 4K 해상도에서는 주사율이 30hz밖에 되지 않았던 것이다.

옛날에는 그냥 평범한 모니터가 보통 50hz이고, 좀 좋은 제품은 60내지 그 이상이었던 것 같다. 주사율이 높으면 마우스 포인터의 이동 모습이 아주 부드러워져서 컴퓨터를 쓰는 인상, 경험, 느낌을 좋게 하는 데 큰 기여를 했다.
또한, 유튜브 동영상만 해도 단순히 화질만 720~1080 HD급이 아니라 프레임 수도 60fps라고 기재된 게 있다. 그건 타 동영상에 비해 모션이 아주 자연스럽고 부드러운 게 티가 나며, 감상할 때 심리적으로 굉장히 긍정적인 느낌을 준다.

그런데 모니터에서 초고해상도를 구현하기 위해서 이런 중요한 주사율을 등가교환하다니...;; 컴퓨터가 성능이 아무리 좋아서 화면을 초당 수백 회 고치더라도 사람은 모니터 주사율보다 더 부드러운 화면을 볼 수 없게 된다.
LCD는 과거의 브라운관 CRT보다는 주사율이 낮아도 괜찮다고 하지만 그래도 그렇지 30hz는 너무 심한 것 같다.

과거에 영화라는 게 처음 발명됐을 때의 기본 프레임 수인 24fps는 30보다도 작은데, 사람이 끊김 없이 자연스러운 영상이라고 느끼는 가히 최소의 마지노 선으로 잡은 값이라고 한다. 이 숫자를 정하기 위해 인지과학적인 실험과 고찰이 들어갔지 싶다.
아날로그 텔레비전의 주사율은 교류 전기의 진동 주기와도 연계해서 설정되었다고 한다. 60hz이면 그와 연계해서 30hz (= 30fps) 같은 식이다. 물론 디지털 동영상에서 프레임 수나 최신 디스플레이에서 주사율은 굳이 그런 것에 얽매이지 않고 그냥 정하기 나름이고 기계의 제조 원가나 전력 소모 대비 기술적 한계에 달려 있다.

일반 정지 영상에서 여러 안티앨리어싱 기법이 존재하듯, 영상에서도 motion blur라고 그야말로 애니메이션계의 안티앨리어싱에 해당하는 기법이 있다. 낮은 fps에서도 동영상이 뚝뚝 귾기지 않고 최대한 부드럽게 이어지듯 보이게 하기 위해서이다. 3D CG로 동영상을 생성하는 그래픽 소프트웨어 내지 각 프레임들을 이어서 동영상을 만드는 인코더가 그런 것까지 감안해서 넣어 주는 기능이 있을 것이다.

말이 나왔으니 말인데, 화면의 해상도와 프레임 수뿐만 아니라 종횡비 그 자체도 어쩌다가 지금처럼 바뀐 걸까? 어쩌다 보니 컴퓨터용 모니터는 가로로 더 길쭉해졌고 스마트폰은 세로로 더 길쭉해졌을까? 모든 영화들은 종횡비가 동일한 걸까? 이런 것도 알고 보면 내력과 사연이 많이 있는데 기회가 되면 차츰 더 알고 싶다.

5.
SSD는 뭐랄까.. 양날의 검 같다.
기계적인 동작이 없으니 소음 없고 전력 소모 적고, 엄청 빠르고.. 비싼 것만 빼면 하드디스크를 완전히 압도하여 조만간 주기억장치와 보조 기억장치의 경계를 허물 것 같은 신기술임이 틀림없다. 반도체 공학의 신비로움을 다시 생각하게 된다.

반도체 기반 보조 기억 장치들은 외형과 단자 형태에 따라 (1) USB 메모리 스틱, (2) SD 카드, 또는 (3) SSD로 나뉘는 듯하다. 그 중 SSD는 광학 디스크(CD/DVD)나 USB/SD와 달리, 하드처럼 같은 C: 고정식 디스크 역할을 한다는 특징이 있다. 동작 원리는 기계식 하드와 완전히 다르지만 말이다.

그러니 하드/SSD만 일컫는 통합 명칭이 필요해 보인다. 고정 디스크? 하드라는 명칭이 너무 굳어졌다면 '기계식 하드/SSD 하드'라는 말이라도 쓰여야 할 것 같다.
그리고 어떤 로컬 디스크에 대해서 파일 시스템이야 요즘은 Windows 기준으로 NTFS가 아닌 곳이 없을 테니 별 의미가 없고.. 디스크가 기계식 하드인지 SSD인지를 되돌리는 API도 GetVolumeInformation 같은 급의 함수에 있어야 하지 않나 생각이 든다.

그런데 자동차가 엔진 제어 방식이 기계식에서 전자식으로 바뀌면서 원인 불명의 급발진이 발생하기 시작한 것처럼.. 디스크 역시 기계식에서 전자식으로 바뀌면서 일상적으로 편리해진 대신에 뭔가 안정성이 떨어진 것이 있다. 단순 가격 차이를 떠나서 SSD는 기계식 하드를 완전히 대체하기에는 아직 5% 부족한 면모가 있다. 이 사이트의 글을 한번 읽어보자. "화 있을진저, 너희 백업 없이 SSD를 쓰는 족속들아!"

  • SSD는 한번 고장 나면 데이터를 살릴 가능성이 거의 없는 매체이다.
  • 하드가 충격이나 자성에 약하다면 SSD는 열과 전기 충격에 매우 약하다. (불안정한 전류, 갑작스러운 정전, 컴퓨터 다운, 과열..) 취약한 분야가 서로 다름.
  • 하드는 배드 섹터를 빼고 나머지 부분이라도 읽고 복구가 가능하지만 SSD는 그런 것 없다.

하긴, 정전이 돼서 작업 중인 데이터를 날렸다고 해서 자기 컴의 RAM의 복구를 시도하는 건 불가능할 것이다. 물론 SSD는 RAM과 같은 구조의 기억장치는 아니지만 SSD도 그만치 훅 가기 쉽다는 뜻이다.

본인도 새로 산 노트북을 사용한 지 불과 5개월 남짓 만에 SSD 불량으로 인한 교환을 경험했기 때문에 이 경고가 더욱 공감이 갔다. 심각한 피해를 입은 정도까지는 아니지만 그래도 꼼꼼히 백업하지 않던 기록과 소스 코드를 일부 날렸기 때문이다.
하드디스크는 떨어뜨리고 물에 집어넣은 것도 국가 수사 기관 차원에서 작정하고 털면 무슨 끈질긴 생명체마냥 내용을 어느 정도 복구해 낸다고 한다. 하지만 SSD는 정말로 훅 가기 때문에 이거 뭐 정보 보호와 보안 관점에서는 더 편리할지도 모르겠다..;;

옛날에는 노트북에서 자주 발생하던 잔고장이 액정 화면의 접촉 불량, 그리고 키캡 이탈이었는데.. 2010년대에 구매한 제품에서는 그런 건 없고 하드와 SSD의 접촉 불량을 더 자주 겪었다. 그러고 보니 운영체제를 재설치하는 통과의례도 Vista 시절부터는 없어졌다. 자동차고 컴퓨터고 모두 지난 20여 년 동안 참 많이 바뀐 것 같다.

Posted by 사무엘

2019/08/18 19:35 2019/08/18 19:35
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1652

1. Windows 명령 프롬프트에서의 UTF-8 지원

본인은 1년 남짓 전에 UTF-8 인코딩에 대해서 글을 쓰면서 Windows도 콘솔 환경에서 UTF-8이 지원되는 날이 올까 썰을 푼 적이 있었다.
이건 Windows 10이 업데이트를 거치면서 어느 정도 현실이 됐다. chcp 65001이 가능해졌다. 명령 프롬프트와 배치 파일에서 깨지는 문자열 걱정 없이 파일 이름이나 각종 메시지를 지정할 수 있다는 것은 좋은 소식임이 틀림없다.

사실, 콘솔 자체는 문자의 특정 인코딩에 전혀 구애받지 않고 임의의 바이트 나열을 주고받을 수 있는 '파일'일 뿐이다. 그러니 콘솔의 코드 페이지가 437이건 949건 65001이건 전혀 상관없이 프로그램은 모조리 생까고 아무 인코딩으로나 유니코드 문자열을 printf 같은 함수로 출력할 수 있다. 가령, chcp 949 상태이더라도 consoleapp.exe > output_in_utf8.txt 는 깨지는 문자 없이 얼마든지 가능하다는 것이다.

다만, C# 같은 언어로 콘솔 프로그램을 만들어서 System.Console.WriteLine을 해 보면, 닷넷 프레임워크가 현재 콘솔의 코드 페이지 번호에 따라(아마도 GetConsoleOutputCP 함수) 문자열을 1바이트 단위 기반으로 변환해서 출력한다.
그러므로 chcp 949 상태에서 듣보잡 한자를 찍으면 깨진 문자열이 아니라 완전히 정보가 소실된 ?로 바뀌어 찍히며, 이는 >를 이용해 파일로 redirect하더라도 마찬가지이다. chcp 65001을 해 줘야 이런 손실이 없어진다.

상황이 이러한데.. 현재 운영체제는 새로운 셸인 PowerShell 말고 기존 명령 프롬프트에 대해서는 chcp 65001이 그냥 가능은 하다는 선에서만 지원을 멈춘 듯하다. 하위 호환 문제 때문에 아예 처음부터 UTF-8를 디폴트로 구동시키지는 못하는 것 같다. 새로운 콘솔 프로세스를 생성해서 거기 코드 페이지를 65001로 변경하는 작업도 불가능하지는 않지만 꽤 번거롭고 지저분하다. Windows의 콘솔 API들은 자기 자신의 코드 페이지를 변경하는 것만 직통으로 지원하기 때문이다.

하긴, 437이니 949니 하는 ANSI 코드 페이지라는 건 유니코드를 지원하지 않는 레거시 앱들과의 호환 때문에 존재하는 개념이다. 그러니 시스템의 기본 코드 페이지가 65001이더라도 저런 디폴트 fallback용 코드 페이지는 계속해서 존재해야 할 것이다.
배치 파일은 @echo off로 시작하는 게 거의 관행인데, @를 거의 메타커맨드 식별자화해서 앞에 @encoding 이런 식으로 인코딩을 지정하는 것도 아주 황당한 생각은 아닐 것 같다.

더 궁극적으로는 굳이 콘솔에만 국한되지 않더라도, Windows API에서 A 함수와 W 함수는 UTF-8이냐 UTF-16이냐의 차이밖에 없어지는 날이 올까? UTF-8을 native로 지원한다는 표식이 된 프로그램에 한해서라도 말이다.
물론 요즘 만들어지는 프로그램이야 처음부터 W 함수만 쓰겠지만.. 타 플랫폼에서 1바이트 문자열 기반으로 유니코드를 지원해 온 프로그램을 포팅할 때는 저런 접근 방식도 분명 도움이 될 것이다.

레거시 프로그램들과의 호환은.. 지금 마소에서 high DPI 지원을 위해서 기를 쓰고 제공하는 샌드박스 가상화 계층만 만들면 얼마든지 가능하지 않겠나 개인적으로 생각한다. manifest 파일에 native UTF8을 지원한다고 명시해 주는 식으로 말이다.

2. 메뉴 간소화

기능이 너무 많아서 메뉴가 "파일, 편집, 보기, 도구"부터 시작해 10개를 훌쩍 넘어가고, 각 카테고리별로 항목들이 20개 가까이 주렁주렁 달린 방대한 프로그램을 생각해 보자. 사용자에게 굉장히 위압적으로 보일 것이다.

더구나 이런 메뉴들은 static한, 고정된 기능 나열 목록일 뿐이다. 파일 내지 글꼴 같은 다이나믹한 목록이 아니며, 사용자가 자주 사용하는 기능을 곧장 고를 수 있게 해 주는 것도 아니다. 프로그램의 모든 기능을 골고루 다 쓰면서 지내는 사용자는 당연히 극소수이고 말이다.

사정이 이러하니 이런 압박스러운 메뉴를 어찌해 보려는 노력이 먼 옛날부터 있었다.
자주 쓰는 기능과 그렇지 않은 기능을 프로그램 개발사에서 답정너 분류한 뒤.. 메뉴를 반토막 간소화해서 보여주는 옵션을 갖춘 프로그램의 예로는.. 도스 시절 MS QuickBasic IDE, 그리고 아래아한글 2.1과 그 이후 버전이었다. 메뉴에서 사라진 기능이라 해도 단축키로는 물론 상시 접근 가능하다.

아래아한글의 경우, 워디안/2002 이전의 3.x~97에도 간소화 메뉴 옵션이 있었던가 그건 잘 모르겠다.

마소에서는 딱 2000년대 초에 일명 Personalized menu라는 걸 도입했다. 사용 빈도를 동적으로 체크해서 오랫동안 안 쓰인다 싶은 메뉴는 감춰 버리고, 메뉴를 꺼낸 지 시간이 좀 오래 지나거나 맨 아래의 ▼을 눌러야만 메뉴가 마저 다 나오게 했다.
Windows 2000/ME의 시작-프로그램 메뉴, 그리고 MS Office 2000/XP/2003 정도에서 이런 메뉴를 볼 수 있었다.

사용자 삽입 이미지

이건 마소의 입장에서는 많은 시간과 비용을 들여 진행한 실험이었으며, 실제로 메뉴 첫인상을 좀 단순하게 보이게 하는 효과가 있었다.
하지만 사용자의 반응은 썩 좋지 않아서 최종적으로는 FAIL 판정을 받았다. Office 길잡이 같은 급의 병맛 흑역사는 아니었지만 몇 년 못 가 없어졌으며, 결국 2000년대 후반부터는 리본 인터페이스가 도입되었다.

참고로 Visual Studio IDE는 일반인이 쓰는 프로그램이 아니어서 그런지.. MS Office의 UI 엔진을 그대로 쓰던 시절에도 Personalized menu가 쓰인 적이 없었다. macOS에도 저런 게 도입된 적은 없지 싶다.

3. macOS

한편, macOS는..

  • 응용 프로그램 패키지(.app)는 하위 디렉터리와 그 밑의 여러 파일들로 구성돼 있음에도 불구하고 Finder에서는 단일 파일인 것처럼 취급해 준다.
  • 그 반면, zip 압축 파일은 그냥 단일 파일 형태임에도 불구하고 내부에 들어있는 하위 디렉터리와 파일들을 실제 파일과 다를 바 없이 seamless하게 표시해 준다.

없는 디렉터리를 있는 것처럼 표시하고, 반대로 있는 디렉터리를 숨기는 가상화를 구현하느라 애 많이 썼을 것 같다.
app 패키지도 안드로이드 apk처럼 그냥 압축 파일 컨테이너에다 넣어 버리지 싶은 생각이 든다. 성능 문제 때문에 그렇게 하지 않은 건지?

그리고 macOS는 GUI 응용 프로그램은 app이고 콘솔 프로그램은 그런 껍데기 없이 a.out 실행 파일인 건가? 일반 실행 파일과 달리 app은 표준 C 함수 말고 NSWorkspace 소속의 코코아 API를 써서만 실행할 수 있는 거고? (내부의 하드코딩된 경로에 일반 실행 파일이 있긴 함) 그 관계를 잘 모르겠다.

내 경험상 mac은 프로세스 간 통신이 Windows보다 제약이 심하고 폐쇄적인 것 같다. 특히 훅킹 같은 게 없기 때문에 macOS용으로 Spy++ 같은 프로그램을 만들 수는 없는 듯하다.
게다가 한 프로그램이 다른 프로그램으로 키 입력을 보내는 게 요 1, 2년 전쯤 시에라에서부터 막혔다. 사용자가 제어판을 열어서 동의를 찍은 프로그램에서만 가능하다.

이런 이유로 인해 macOS에서는 날개셋 편집기나 외부 모듈 같은 프로그램은 만들어도 날개셋 입력 패드 같은 구현체는 만들 수 없겠다. 또한 외부 모듈에서 키 입력을 보내는 날개셋문자도 구현할 수 없겠다. =_=;;

4. 맥 계열과 타 PC와의 차이

(1) 같은 파일이 컴퓨터를 옮기니까 크기가 몇십 MB씩 차이가 나 있어서 깜짝 놀랐는데..
알고 보니 Windows는 전통적으로 1024 기반의 MiB 단위를 쓰는 반면, 맥은 그냥 깔끔하게 1000 단위로 자리수를 매겨서 발생한 차이였다.

(2) 그러고 보니 맥OS는 메시지 박스에서의 버튼 배치 방식도 Windows와 다르다. '예'에 해당하는 1순위 버튼이 색깔도 파랗게 강조된 형태로 대화상자의 맨 오른쪽 아래에 있다. 이건 뭐 그냥 디자이너의 취향 차이인 것 같다.

(3) 일반적으로 키보드의 좌측 하단에는 modifier key들이 ctrl, fn, win, alt의 순으로 배치돼 있다. 그러나 애플 제품들은 맥북/아이맥 구분 없이 다 fn, ctrl, alt, cmd(win)의 순이기 때문에 1234가 2143으로 기묘하게 바뀌어 있다.
서로 알력 싸움에 따로 노는 건지는 모르겠지만, 두 종류의 컴퓨터를 드나드는 사람의 입장에서는 이게 불편하기 그지없다..;;

5. 안드로이드와 iOS

요즘 전세계에 보급된 스마트폰들에서 안드로이드와 iOS의 점유율이 적게는 7:3, 많게는 4:1 가까이 된다고 한다.
이 둘을 더하면 진짜 99.99%이고, Windows Phone 등 타 운영체제는 이제 유의미한 점유율을 완전히 상실한 듣보잡이라고 한다. 마소에서도 Windows 기반의 자체 모바일 운영체제는 이미 포기하고 접었고..

오픈소스 진영에다가 구글· 삼성의 막강한 지원 덕분에 안드로이드는 확실한 주류가 됐다. 하지만 그렇다고 iOS가 무시 가능한 처지인 건 아니다.
이건 마치 전세계 도로의 우측통행 vs 좌측통행의 점유율과 비슷한 구도인 것 같다. 내 기억으로 저것도 비율이 3:1 내지 4:1쯤이지 싶다.

좌측통행이 분명 비주류이긴 하지만 그렇다고 극소수인 건 아니며, 영국· 일본· 오스트레일리아 등 존재감을 절대로 무시할 수 없는 강대국 선진국들이 엄연히 좌측통행을 하고 있다. 그러니 완전히 없어질 수가 없다.
이런 좌측통행의 점유율과 위상이 마치 오늘날 iOS의 그것과 비슷하게 느껴진다는 것이다. 오래된 생각이다. (CPU 업계에서 리틀 엔디언과 빅 엔디언의 점유율 비율은 어찌 되었나 궁금해지기도 한다만..)

그러고 보니 세벌식도 여전히 1%가 채 안 되고, 내가 혼자 생각하는 것보다 훨씬 더 지위가 약한 마이너이구나..;;
더구나 지금 세벌식을 쓰는 사람들도 자기 자식에게까지 차마 세벌식을 권하지는 않겠다고 다짐하는 경우가 적지 않다. 이걸 생각하면 일면 우울해진다. 타자가 편리한 것보다 당장 생활에서 불편하고 번거로운 게 더 크게 느껴지는가 보다.
그나마 명분이 옳고 객관적으로 이론적으로 성능이 우수하기 때문에 오늘날까지도 명맥이 유지되고 있는 것이다.

Posted by 사무엘

2019/08/04 08:34 2019/08/04 08:34
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1647

1. Windows 재설치

(1) 본인 주변의 어떤 컴퓨터는 절전이나 최대 절전 말고 '시스템 종료'로 확실하게 껐는데도 불구하고 나중에 다시 와 보면 무슨 좀비처럼 저절로 다시 켜져 있곤 했다. 사람이 건드린 건 당연히 전혀 아니고..
절전 상태에서 깨어나는 게 아니라 완전히 꺼졌던 컴퓨터가 왜 어떻게 저절로 다시 켜지는지는 나로서는 도무지 이해할 수 없다. 컴퓨터를 끄는 걸로도 모자라서 플러그까지 완전히 뽑아야 되나 하는 생각마저 들었다.
이건 검색을 해 보니 2015~16년경 Windows 10 초창기에 존재했던 버그였다.

(2) Windows가 맛이 가서 제대로 부팅이 되지 않을 때 안전 모드로 부팅한다거나, 컴을 팩토리 리셋 시키기 전에 최소한 백업이라도 하기 위해서 긴급 명령창이라도 열려면 파란 배경의 Windows RE (Recovery Environment)에 들어가야 한다.
부팅 때 F8 같은 특정 단축키를 눌러서 여기로 바로 들어갈 수 있으면 좋겠구만.. 꼭 부팅 중에 컴퓨터를 강제로 끄는 무식한 삽질을 5~10번쯤 해야 그제서야 "잠시 기다려 주세요"와 함께 저리로 들어가는 게 개인적으로 굉장히 마음에 안 든다.

(3) Windows를 새로 설치한 직후에 다중 모니터를 연결해 봤는데.. 무작정 꽂기만 한다고 장땡이 아니구나. 2개 중 HDMI 케이블로 연결한 4K급 모니터는 아무리 제대로 꽂아도 화면이 나타나지 않았다. 그래픽 드라이버를 업데이트 한 뒤에야 잡히더라.

그래도 요즘 컴퓨터는 수십 년 전 옛날에 비해 새 하드웨어를 꽂아서 사용하는 게 얼마나 간편 편리해졌나 모른다. 상당수가 plug & play와 USB 덕분인데, 생각해 보니 두 기술이 동시에 같이 등장한 건 아니라는 게 의외이다.

2. 자동 시작 프로그램 목록

그나저나 Windows 10은 아마 3.x 이래로 20년 가까이 변함 없던 '시작 프로그램' 등록 지점을 변경했구나. 난 지금까지 모르고 있었다. 어쩐지 '시작프로그램'이라는 폴더가 왜 안 보이나 했다. Windows 8 시절에도 변함없었던 것 같은데..
디렉터리 기반인 건 변함없지만 그게 시작 메뉴의 목록 디렉터리 아래가 아닌 다른 곳으로 바뀐 것 같다.

운영체제가 부팅될 때 자동으로 실행시킬 프로그램의 목록은 저 디렉터리뿐만 아니라 레지스트리에도 여러 군데가 있다. 이것만 한데 정리해도 블로그 글 한 편이 써지지 싶다. 도스가 사라지면서 config.sys와 autoexec.bat가 없어졌지만, 걔네들이 하던 기능까지 없어진 건 아닌 셈이다.
리눅스나 macOS는 자동 시작 프로그램 목록을 어디에서 지정하는 걸까? 궁금해진다.

아울러, 요즘 Windows는 SMB(쌈바)가 기본으로 깔리지 않는가 보다. 랜선 꽂고 인터넷이 멀쩡히 되는데 탐색기에서 \\로 시작하는 공유 폴더 서버에 왜 이리 접속이 안 되나 했더니.. "프로그램 추가/제거"에서 해당 기능을 설치해야 했다. 인터넷 검색을 하면 '로컬 보안 정책'을 고치라니 뭐니 하는 말이 있었지만, 그걸 건드릴 필요는 없었다.

3. embedded 컴포넌트로 활용 가능한 브라우저

2010년대 이후로 웹브라우저 시장에서 IE의 독주가 꺾이고 크롬, FireFox, Edge 같은 대체 브라우저들이 많이 쓰이고 있다.
그런데 IE는 여느 브라우저들과 달리 컴포넌트화가 잘 돼 있다. 그래서 임의의 프로그램 내부에 IE 기반의 브라우저 창을 집어넣어서 단순 HTML 내지 웹 컨텐츠를 표시할 수 있다. 기술 기반은 잘 알다시피 COM/ActiveX이고 말이다.

IE 말고 다른 브라우저 창을 내 프로그램에다가 내장시키는 건 가능한지 모르겠다.
그게 가능하지 않다면 IE는 이쪽 고정 수요 때문에 계속 없어지지 않고 명맥을 유지할 것 같다.

4. 잠금 화면의 배경 그림

Windows 8(.1)까지만 해도 안 그랬던 것 같은데.. 10부터는 부팅 직후, 또는 Win+L을 눌렀을 때 나타나는 잠금 화면에 기본적으로 근사한 각종 자연 경관 배경 그림이 나타난다. 각종 업데이트를 받기에도 네트워크 트래픽이 빠듯할 텐데, 어떤 서비스는 거기에 또 짬을 내서 그림 파일도 찔끔찔끔 받아 놓는가 보다.

이 그림도 분명 디스크 어딘가에 파일 형태로 저장될 텐데, 슬쩍 빼돌리는 방법에 대해서는 이미 팁이 나돌고 있기 때문에 검색해 보면 다 나온다. 그런데 본인이 문득 궁금한 건 이 그림들을 마소의 어느 부서에서 담당하고 있으며, 누가 어디서 이런 사진들을 구해서 올리느냐 하는 것이다.
Windows와 mac 진영 모두 근사한 자연 경치 사진을 공급받는 비밀 거래처가 있는 것 같다. 그건 개인일 수도 있고 기업일 수도 있다. Windows XP의 초원 배경은 이미 아주 유명한 사례이다.

5. Windows - 설정 창의 불편한 점

요즘 Windows는 버전업을 거듭할수록 제어판은 뒷전으로 밀려나고 운영체제의 모든 설정을 메트로 앱인 '설정'으로 하게 UI를 옮기려는 게 보인다.

(1) 그런데 이놈의 설정 앱은 좀 여러 개를 띄울 수 없나? 프로그램 추가/제거 같은 창을 꺼내 놓은 상태로 디스플레이/개인 설정 같은 걸 띄우려니 기존 창이 바뀌어 버리는 게 굉장히 불편하다. 10수년 전에 탭이 없던 IE6 시절에, 응용 프로그램에서 인터넷 링크를 클릭하면 기존 브라우저 창에서 그 링크가 열려서 짜증 나던 게 고스란히 재연되고 있다.

(2) '설정'에서는 키보드의 연타 속도를 조절하는 방법이 1803 내지 1809 빌드 기준으로 여전히 존재하지 않는다. 그럼 그런 키보드 설정은 기존의 제어판에 들어가서 하라고 링크라도 띄워 놔야 되는데 그것도 없는 건 문제인 것 같다.
마우스의 경우, '설정'에서는 좌우 버튼 교환이나 휠 스크롤 분량 같은 대중적인(?) 옵션만 있다. 포인터 모양을 바꾸는 매니악한 옵션은 제어판에 가서 하라고 '추가 마우스 옵션' 링크가 표시되어 있다. 키보드는 그런 게 없고 '고급 키보드 옵션'은 그냥 IME/문자 입력 쪽 설정밖에 안 나온다.

(3) 요즘 Windows 10에서 중국어· 일본어 IME를 쓰고 싶으면 해당 언어와 키보드만 등록하는 게 아니라, 언어 팩을 다 받아서 설치해야 하는 것 같다. 전자까지만 하면 IME가 뜨긴 하지만 실질적으로 중국어· 일본어 입력이 되지 않는다.
20년쯤 전 먼 옛날에는 마소에 내장돼 있는 외국어 IME를 처음 등록할 때 운영체제 CD를 집어넣어야 했다. Vista~7에서는 그냥 전세계 언어가 다 깔렸었는데 이제는 인터넷으로 받는 형태로 절차가 바뀐 것 같다.

(4) 그리고 외국어 UI 팩이나 입력기, 필기· 음성 인식 데이터를 받고 설치하는 버튼을 실수로 잘못 눌렀는데, 작업을 취소하는 버튼을 왜 마련해 놓지를 않았는지? 이것 때문에 꽤 당혹스럽고 불편한 경험을 하기도 했다. =_=;;

6. 입력 도구모음줄의 불편한 점

오늘날 Windows 10에서는 IME에 대해서 브랜드 아이콘(한)과 상태 아이콘(가/A) 딱 둘만 작업 표시줄에 붙어 있는 극도로 단순화된 아이콘 표시 모델을 지원한다. 요건 사실 2012년의 Windows 8때부터 도입된 것이니 생각보다는 오래됐다.

지금도 과거의 XP~7 시절을 풍미했던 길쭉한 입력 도구모음줄을 쓰는 것 자체는 가능하다. 특히 키보드에 한자 키가 없거나, 그 키를 자기 멋대로 가로채는 프로그램(MS 오피스 프로그램..)에서 한글 IME의 고유 방식대로 한자 변환을 하려면 이 도구모음줄이 필수이다. 한자(漢) 버튼이 노출되어 있어서 마우스 클릭이 곧장 가능하기 때문이다.

그런데 이 도구모음줄을 꺼내는 옵션이 꽤 찾기 어려운 구석진 곳에 있다는 점은 차치하고라도.. 이 도구모음줄이 불편한 점 중 하나는 floating 상태일 때 화면에서 찾기가 어렵다는 점이 아닐까 한다. 그리고 그 이유 중 하나는 배경색이 순 화이트이기 때문이지 싶다.

이 도구모음줄은 도입된 이래로 배경색은 줄곧 작업 표시줄의 색깔과 일치해 왔다.
Windows 98/2000/ME에서는 회색, XP에서는 파랑 같은 테마 색 또는 회색(고전), 그리고 Vista/7에서는 역시 검정..
그러니 10에서도 저 패턴이라면 배경색이 작업 표시줄의 색깔과 같은 검정이어야 할 텐데, 어째 제목 표시줄의 색깔과 같은 흰색이 됐다.

제목 표시줄도 흰색이지, 프로그램의 일반 클라이언트 영역도 흰색이지, 그런데 설상가상으로 도구모음줄 주변엔 아무 테두리도 없고 그림자도 없으니.. 찾기 어려울 수밖에 없다.
역대 Windows들 중에 TSF 도구모음줄의 배경색이 흰색인 버전 자체가 Windows 10이 유일하다시피하다. 8과 8.1에서는 어땠는지 기억이 안 난다만 걔네들도 흰색은 아니었지 싶다.

하지만 이 도구모음줄은 MDI 창이라든가 HTML 도움말처럼 마소에서 더 개발이나 지원을 하지 않는 레거시일 뿐이니, 얘에 대한 개선은 앞으로 기대하기 어려울 것 같다.

7. caret의 깜빡임이 멈추는 현상

이제 단순히 불편한 점을 넘어 버그 얘기를 좀 해 보자. 내 컴퓨터만 그런 줄 알았는데 아니더라.
요즘 Windows에서 날개셋 편집기, 메모장, 워드패드처럼 운영체제가 제공하는 caret(키보드 커서)을 사용하는 프로그램을 띄워서 가만히 놔둬 보면..
caret이 딱 5번 깜빡이고 나서 6번째로 나타난 뒤부터는 깜빡이지 않고 그대로 멈춰 버린다.

Windows 10의 1803과 1809 버전에서 모두 확인했는데 이런 버그가 왜 생겼나 모르겠다. 2015~16년대의 구버전에서는 이런 일이 없었다. 아니, 수십 년 전의 Windows 95 이래로 이런 현상은 처음 본다.
Spy++로 들여다보면.. caret을 깜빡여 주라는 메시지 자체가 더 오지 않고 멈춘다. 그에 반해 아래아한글이나 MS Word 같은 전문 워드 프로세서는 이런 메시지에 의존하지 않고 자체적으로 caret을 운용해서 그런지 깜빡임이 멈추지 않는 것 같다.

8. Dependency Walker의 오동작

이전에는 이런 현상이 없었던 것 같은데.. Windows 10 1809를 설치한 뒤에는.. 각종 실행 파일을 Dependency Walker 유틸로 들여다보고 분석하는 게 다소 불편해졌다.
Windows 7쯤부터 운영체제의 자체 제공 EXE/DLL들은 kernel32.dll의 함수들을 kernel32로부터 직통으로 import하는 게 아니라 프로세스, 스레드, 파일, DLL로딩 등 각종 세부 분야로 나뉜 가상의 DLL로부터 import하기 시작했다. comctl32의 로딩 방식은 side-by-side assembly 방식으로 바뀌더니 kernel32는 저렇게 바뀌었다는 게 흥미롭다.

그런데 Windows 10 1809 버전에서는.. KERNEL32.DLL은 API-MS-WIN-CORE-PROCESSTHREADS-L1-1-1.DLL에 의존하고, 후자는 또 전자에 의존하는 구조가 돼서 여기서 일종의 무한루프에 빠진다.
비록 Dependency Walker 자체가 뻗는다거나 하지는 않지만, 이 때문에 분석 시간이 굉장히 길어지고 모듈 분석 트리도 쓸데없이 거대하고 지저분한 모양으로 만들어진다.
문제가 개선됐으면 좋겠지만 Dependency Walker는 무려 Windows Vista 초창기인 2006~7년 이후로 개발이 중단되고 버전업이 없으니 아쉽다.

Posted by 사무엘

2019/06/28 08:38 2019/06/28 08:38
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1634

1. 32비트 컴파일러: 16비트 메모리 접근의 한계를 극복하기

예전에도 언급한 적이 있지만.. 1993년 말에 발매되었던 Doom 게임은 그야말로 충격적인 3차원 그래픽 덕분에 게임 업계에 큰 충격을 선사했다. 업계 종사자들은 기술 수준 자체뿐만 아니라 "얘는 어셈블리어를 거의 사용하지 않고 순수 C만으로 개발되었습니다"라는 존 카맥의 말에 더 큰 충격을 받게 됐다.

훗날(1997년) Doom의 소스 코드가 공개되면서 이 말은 사실임이 밝혀졌다.
Doom은 무슨 16비트 Windows 같은 쑤제 어셈블리어 튜닝 위주로 개발된 게 아니라, Windows NT처럼 굉장히 이식성 있게 개발되었다. 그러니 Doom 엔진 기반의 수많은 게임과 mod들이 온갖 플랫폼으로 이식되어 만들어질 수 있었다.

단지, 오리지널 도스용의 경우, 컴파일러를 그 당시에 흔하던 볼랜드나 MS 같은 16비트용을 쓴 게 아니라 Watcom이라는 다소 생소한 32비트 고성능 제품을 썼을 뿐이다.
그리고 어셈블리어를 안 쓰더라도 고정소수점이라든가, IEEE754의 특성을 이용해서 3차원 그래픽용 실수 연산(삼각함수, 제곱근, 벡터 정규화...)을 왕창 빠르게 수행하는 각종 tweak들은 응당 최대한 구사해서 성능을 끌어올렸다.

그러니 Doom은 아직 상대적으로 생소하던 32비트 컴파일러라든가 DOS/4G 도스 익스텐더 같은 물건의 인지도를 끌어올려 줬다. 이렇게 Doom을 통해 Watcom 컴파일러까지 알렸던 id 소프트웨어에서는 훗날 퀘이크를 만들어서 이번에는 오픈소스 진영의 걸출한 도스용 32비트 컴파일러이던 djgpp를 알리게 되었다.

운영체제 자체를 OS/2나 Windows NT처럼 통째로 32비트로 쓰기에는 아직 기계값이 너무 비싸고 특히 메모리가 부족했다. 그러니 도스에서 돌아가는 일부 대형/고사양 프로그램이 자체적으로 도스의 한계를 극복하고 보호 모드로 진입하는 솔루션을 내장했던 것이다.

생각해 보니 국내에서도 아래아한글 2.1이 전문용은 Watcom C/C++을 이용한 32비트 전용으로 만들어졌다. 얘는 발매 시기가 심지어 Doom보다도 3개월 남짓 더 앞섰다(1993년 9월 vs 12월). 그러니, 터보 C, 볼랜드 C++ 하던 그 시절에도 32비트 컴파일러에 대해서 알 사람은 이미 다 알기는 했던 모양이다.

다만, 아직도 286 똥컴이 많이 굴러다니고 서민용 운영체제들은 아직도 16비트 도스와 Windows가 주류인데, 내 프로그램을 386 전용으로 개발하는 것에 대한 득과 실을 신중하게 따져야 했다. 오죽했으면 아래아한글도 후속 버전인 2.5와 3.0에서는 일반용/전문용 구분이 없어지고 그냥 hwp86.exe와 hwp386.exe 두 에디션을 모두 내장하는 것으로 형태가 바뀌었다. 추가 글꼴과 사전 컨텐츠는 '확장팩'으로 분리되고 말이다.

아래아한글은 Phar Lap 도스 익스텐더를 사용했다. 아래아한글이 그 시절의 도스용 게임처럼 DOS/4G(W) 로고를 띄우면서 실행되었다면 무척 볼 만했을 것이다.
86과 386 에디션은 성능 말고는 덧실행 프로그램이 지원되는지의 여부가 가장 큰 차이점이었다. 덧실행은 16/32비트용이 따로 나오지 않고 32비트 전용이었기 때문이다.

화면 보호기들, 그리고 확장팩에서 제공되었던 프라임 영한사전도 다 덧실행 프로그램이었다.
먼 옛날 1.2 시절에는 별도의 액세서리로 테트리스 게임이 있었는데 나중에 그게 덧실행으로 컴백한 걸 보니 개인적으로 감회가 새로웠었다.

이렇게 1990년 중반에 도스용 프로그램들의 32비트화 추세와 달리, 마소는 진작부터 PC에서 도스를 Windows로 대체하려는 큰 그림을 갖고 있어서 그런지.. 도스용으로 32비트 컴파일러를 결코 내놓지 않았다. 정작 자기들은 그 기술을 내부적으로 보유하고 사용했으면서 말이다.
Visual C++ 1.5x는 16비트 도스/Windows 바이너리들을 빌드할 수 있었는데, 명령 프롬프트에서 돌아가는 컴파일러와 링커 같은 툴들은 그냥 32비트 프로그램이 아니라 32비트 PE 기반의 콘솔 프로그램이었다.

Windows NT 같은 데서는 직통으로 실행 가능하고, 도스에서 실행되면 stub으로 embed된 도스 익스텐더가 컴을 보호 모드로 진입시키고 CreateFile/GlobalAlloc 같은 Win32 API를 제공해서 프로그램을 실행했다.
스레드를 만들지는 못했겠지만 컴파일러· 링커가 사용하는 Win32 API야 뭐 파일이나 메모리 I/O 정도밖에 없었을 것이고, 이건 도스 익스텐더가 감당 가능했다. 결국 한 바이너리만으로 도스와 Windows에서 모두 사용 가능.

이건 뭐 콘솔 프로그램계의 Win32s나 마찬가지인 엄청난 기술인데.. 마소의 Visual C++에서 이런 이중 바이너리를 만드는 걸 end-user에게 지원한 적은 내가 알기로 없다.
마치 C# 네이티브 코드 컴파일러만큼이나 대외적으로 공개되지 않고 마소 내부에 봉인된 기술인 것 같다.

2. 슈퍼 VGA 라이브러리: 표준 VGA의 한계를 극복하기

IBM 호환 PC라고 불리는 물건에서 IBM이 주도하는 PC의 단일/표준 규격이라는 건 286 AT 이후로 없어졌다. 그러니 286 이후로 최초의 386 PC는 IBM이 아닌 컴팩에서 출시되기까지 했다.
그리고 그래픽 카드도 절대불변 단일 표준은 1987년의 구닥다리 VGA가 마지막이다. 표준 VGA는 800*600 해상도조차 지원하지 않았으며, 그나마 색깔이 아쉬운 대로 다양해진 256색은 겨우 320*200에서밖에 지원되지 않아서 업무라기보다는 그냥 게임 전용 모드로만 쓰였다.

그 뒤로 VGA보다 더 높은 해상도와 더 많은 색상을 지원하는 규격은 그야말로 온갖 싸제 SVGA 제조사들이 난립하면서 파편화 천국이 됐다. VESA 같은 규격이 괜히 필요해진 게 아니다.

이게 불과 1990년대 초반의 일이니, 앞에서 언급한 보호 모드가 어떻고 DPMI가 제정되던 때와 시기적으로 비슷하다. 하긴, 1990년에 나온 그 옛날 프로그램인 Deluxe Paint조차도 처음 실행될 때 맨 아래에 1024*768 256색 SVGA 모드가 있긴 했다. 물론 당대에 그걸 선뜻 고를 수 있을 정도의 금수저 컴퓨터를 소유한 사용자는 매우 소수였을 것이다.

마소의 베이직 컴파일러야 SCREEN 명령으로 SVGA 지원은 전무했다. API 구조가 완전히 다른 3rd-party 라이브러리를 구해서 써야 했다.
볼랜드의 경우는 상황이 약간 낫다. 비록 자체적으로는 VGA까지밖에 지원하지 않았지만, 일종의 그래픽 드라이버인 bgi 파일이 내부 스펙이 공개돼 있고 확장 가능했기 때문에 이걸 기반으로 SVGA 라이브러리를 만든 곳이 있긴 했다.

검색을 해 보니 Jordan Hargraphix 소프트웨어가 이 업계의 독자적인 큰손이었던 모양이다. 이미 1991년 무렵부터 유명했다.
바이오스를 거치지 않고 일명 VGA mode X라고 불리는 320*240, 400*300 같은 변형 모드까지 다 지원했다.
그때는 소프트웨어가 잘못된 명령을 내려서 컴퓨터만 뻗게 하는 게 아니라 모니터를 손상시키는 것도 가능했던 시절이다. (주사율 변조..) 옛날에 CGA도 160*100 같은 tweak mode가 있었다고 하는데 그것만큼이나 신기한 일이 아닐 수 없다.

다만, BGI라는 그래픽 API는 무려 1980년대 후반에 개발된 것이며, 아무리 bgi 드라이버를 새 하드웨어에 맞게 확장한다 해도 256색 이상의 색을 지원하는 것은 구조적으로 불가능했다고 한다. 트루컬러 SVGA를 지원하려면 완전히 새로운 독자 라이브러리를 써야 했다.
BGI는 색상을 관리하는 게 RGB값 기반이 아니라 팔레트 인덱스 기반으로 고정돼 있었던 모양인데, 16비트 시절에 이는 충분히 수긍이 간다. 쟤가 무슨 Windows GDI 급으로 하드웨어 통합과 추상화를 표방한 물건은 아니었으니 말이다.

도스용 아래아한글은 16비트 바이너리의 경우 Turbo/Borland 컴파일러로 개발되었다. 하지만 아주 초창기인 1.x 시절부터 그래픽 라이브러리를 독자 구현했는지, 볼랜드의 보급 BGI 라이브러리를 사용한 흔적이 전혀 없는 것이 매우 흥미롭다.
이건 비슷한 시기에 도스용 한메 타자 교사도 마찬가지다. 얘도 MS C로 개발되었지, 의외로 볼랜드 출신이 아니다.

Posted by 사무엘

2019/03/23 08:31 2019/03/23 08:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1600

« Previous : 1 : 2 : 3 : 4 : 5 : ... 11 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/09   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

Site Stats

Total hits:
1444650
Today:
483
Yesterday:
534