김 용묵의 절대공간 - 블로그

1990년대 초중반, 일반 서민 땅개들은 DOS를 벗어나지 못하고 기껏해야 Windows 3.x니 이런 바닥에서 놀고 있었는데,
하늘 위로, 혹은 바다 건너편에는 서민이 범접조차 할 수 없는 별세계가 있었다.
아래의 것들은 골수 얼리어답터나 직업적으로 컴터 연구하는 사람, 해외 문물을 재정 타격 없이 접할 수 있는 금수저의 산물이었다.

1. 매킨토시

매킨토시 컴터 화면으로 실사 사진이나 전자출판 인쇄물 화면이 쫙 뿌려져 있는 건 그야말로 꿈만 같은 신세계 별세계 그 자체였다.
이때는 산돌, 윤 같은 서체도 맥의 전유물이었다. Windows에서는 구경조차 할 수 없었다. PC는 저해상도 화면과 프린터에 튜닝이 잘 된 한양, 휴먼, 큐닉스의 나와바리였을 뿐이다.

마소 진영의 빌 게이츠는 장사꾼이어서 악랄한 독점뿐만 아니라 박리다매, 하위 호환성, 고객 눈높이.. 이런 이념을 중시했었다. 그러나 잡스는 그렇지 않고 교주, 소수의 매니아, 고가 프리미엄.. 이런 쪽이었다.
본가부터가 저런데 그 당시 애플 매킨토시의 한국 총판이었던 엘렉스는 안 그래도 비싼 제품 가격을 더 지랄맞게 쳐 올렸다.

PC로 치면 286 AT밖에 안 됐을 저가 보급 사양부터가 1990년대 가격으로 2, 300만 원부터 시작했다. 하이엔드급은 6, 700만 원.. 돈 좀 보태면 집이나 차를 살 수 있을 정도였다.
오죽했으면 흉악한 가격에 빡쳐서 그냥 미국 현지에 가서 제품을 직접 사서 들여 오는 사람도 있었다.

2. OS/2 2.x

1990년대 초에 각종 도스용으로 나왔던 업무용 프로그램· 개발툴들은 DOS뿐만 아니라 OS/2 지원을 Windows 지원보다도 더 중요하게 생각했었다.
PC용으로 만들어졌던 진정한 32비트 운영체제였다고는 하는데.. 이후에 OS/2 Warp니 멀린이니 이런 거 나왔다가 존재감 없이 사라진 것 같다. 들리는 말로는 코드 구조가 어셈블리어 기계어 코드 일색이고 포터블하지 못했던 것도 OS/2의 명줄을 더 재촉했다고 한다.

나와 개인적인 접점은 전무하다. 단지, "OS/2 써 보려면 컴터 램이 4MB 이상은 있어야 합니다" 이런 문구를 1992년도 컴터 잡지에서 보고 깜짝 놀라긴 했었다. ㅎㅎ

3. Windows NT 3.x

껍데기는 Windows 3.1처럼 생겼고 심지어 버전 번호도 똑같이 시작했지만 내부 구동은 정말 넘사벽으로 다른 물건이다.
안정적이고 탄탄하고 순수 32비트 기반이고.. 다 좋은데 램이 지랄맞을 정도로 많이 필요해서 돌릴 수 있는 컴퓨터가 별로 없었다. OS/2보다 더 자비심이 없었다.

NT는 Windows 2000, XP의 전신이고 심지어 오늘날 Windows 10/11의 먼 조상이라고도 볼 수 있다~!
도스 기반의 Windows 3은 x86에서 86 real, 286 standard, 386 enhanced 다양한 모드로 실행 가능했다.
그 반면, Windows NT는 그냥 여러 CPU를 지원했다. x86은 무조건 386인 거고, 그 밖에 MIPS, DEC alpha 등.. 개발 방향과 성격이 이런 차이가 있었던 것이다.

그리고 NT는 DirectX라는 게 개발되기 전부터 OpenGL을 지원하고 있었다. 게임보다는 업무용 그래픽을 위해서.
OpenGL에 대해서는 좀있다 다시 얘기하도록 하겠다.

4. NeXTSTEP

잡스가 애플을 잠시 떠나 있던 동안 개발했던 고급 컴퓨터와 거기서 돌아가던 운영체제 되시겠다.
id 소프트웨어의 존 카맥이 이 환경에서 Doom과 Quake를 개발했던 것으로 잘 알려져 있다.
그리고 국내에서는 Windows용 아래아한글 3.0b가 요 NeXTSTEP의 UI를 차용한 독자 UI를 채택했던 바 있다. 특히 스크롤바의 화살표 삼각형이 양쪽 끝에 있는 게 아니라 한데 몰려 있는 거 말이다. ◀-----▶가 아니라 -----◀▶

이상이다.
일반 흙수저 서민들이 저런 급의 OS를 만져보게 된 첫 기폭제가 사실상 Windows 95라고 봐도 과언이 아니다.
그리고 그게 가능해진 건 램값이 싸진 덕분이다.
1990년대 이후 PC의 발전을 논할 때는 컴퓨터 속도의 향상(그 뒤 멀티코어화), 램 용량의 증대(단가 하락), 그리고 네트워크 속도 향상.. 이 순서를 기억하면 될 것 같다.

1990년대 말쯤부터는 슈퍼컴퓨터만을 위한 전용 컴터 아키텍처라는 것도 없어졌고,
워크스테이션이라는 개념도 아주 희박해져서 그냥 하이엔드 급 PC로 흡수된 것 같다.

※ 번외: OpenGL과 화면 보호기

과거.. 1990년대 후반~2000년대 초에는 Windows 컴터에 "3D 텍스트, 3D 미로, 3D 날으는 객체들, 3D 미로"라는 화면보호기가 있었다.
Windows 95 때는 '쁘라스 확장팩'에만 수록되어 있었고, 98부터 XP에는 기본 내장돼 들어갔었다.

얘들은 OpenGL이라는 하드웨어 가속 3차원 그래픽 라이브러리의 기술 데모 명목으로 만들어졌다.
마소는 전통적으로 게임용 그래픽 명목으로 DirectX를 강력하게 지지하곤 했는데 웬 OpenGL인 걸까?
"얘들은 '3D 핀볼'처럼 제3자 외주 개발 프로그램이기라도 했나? 근데 겨우 화면보호기를 외주로 개발해?"

개인적으로 궁금했는데 그게 아니구나.
얘들은 마소에서 자체 개발한 프로그램인데, Windows 95가 아니라 Windows NT 3.5에서 유래된 것이었다.
95 시절에 출시됐던 Hover! 이라든가 Fury!! 같은 초보적인 수준의 가정용 3D 게임과는 기술 계보가 완전히 달랐다. 이게 핵심이다.

(* 참고로, 저 당시에 마소는 팀 간에 경쟁과 알력 싸움이 장난이 아니었던 것이 공공연한 비밀이다. Windows 9x 팀 vs NT 팀, Office 팀, Visual C++ 팀 등등.. 그래서 서로 정보 공유도 안 하고, 같은 기능 API도 다 따로따로 중복 개발했을 정도였다.. 무슨 구 일본군 육군 vs 해군처럼.. 그 당시 빌 게이츠라든가 스티브 발머는 정말 살벌한 경영자였다. *)

하드웨어 가속이 없이 평범한 재래식 그래픽으로는 화면보호기에 점, 선, 글자 같은 초보적인 그래픽 애니메이션만 가능했다. 그것도 2D 위주..
물론, 쌍팔년도 시절 화면보호기의 정석 교과서는 별들이 씽씽 3차원 원근법이 적용되어 날아다니는 '우주여행'이긴 했다. 아니면 불꽃놀이..??? 시꺼먼 화면에서 점과 선만 갖고 나름 근사한 눈요깃거리였다. 직접 코딩해서 만들어 보고 싶다.

그런데 OpenGL이나 DirectX 같은 게 등장한 덕분에 텍스처나 광원이 들어간 3차원 애니메이션이 구현 가능해졌다.
그래서 마소에서는 OpenGL 데모를 화면보호기 형태로 제공하기로 했고.. 사내 OpenGL 화면보호기 덕질 공모전을 열어서 제일 우수한 작품 하나를 Windows 제품에다 넣기로 했다.
그랬는데 결국은 출품된 작품들을 모두 제품에다 넣어서... 그게 저렇게 전세계에 퍼진 것이다.

얘들은 훗날 Windows Vista에서 대부분 빠지고 '3D 텍스트'만 남았다. 그리고 비누방울 같은 다른 보호기가 도입돼서 오늘날에 이르고 있다. 새로 개발된 걔들은 당연히 Direct3D 기반이겠지..??

지금이야 화면보호기라는 개념 자체가 완전히 레거시 퇴물이 됐다. 마치 도스 시절에는 하드디스크 파킹 유틸리티가 각종 현란한 그래픽과 함께 유행이었는데 그것도 유행 지나고 퇴물이 됐듯이 말이다.
화면보호기가 하는 일은 세계 절경 풍경이 나오는 잠금 화면, 아니면 아예 컴 화면을 완전히 끄는 절전 모드로 계승되었다. 스마트폰에 화면보호기 따위가 있지는 않다.

이 화면 보호기 얘기는 the old new thing 블로그의 내용을 토대로 작성되었다.
하긴, 옛날에는 화면 보호기처럼 화면 전체를 마치 프레젠테이션 화면 전환처럼 조작하는 거 말이다.
Doom 게임에서 화면 녹으면서 내려가던 효과, 하늘소 프로그램에서 텍스트 화면이 좌우로 쫙 갈라지는 거..
비디오 메모리를 직접 조작하던 게 추억의 프로그래밍 테크닉이었다. ^^

Posted by 사무엘

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