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

1. 디지털 카메라

요즘은 아시다시피 스마트폰에 카메라 렌즈도 하나로 모자라서 둘 이상이 달리며, 이걸로 사람 눈과 뇌가 하는 것처럼 원근감까지 기계가 인지하는 지경에 도달했다.
하긴, 모니터와 TV는 종횡비가 진작에 다 와이드로 바뀌었는데 카메라로 찍는 사진의 종횡비는 여전히 4:3이 기본인 게 좀 답답하게 느껴진다. 카메라 렌즈의 화각이 커지고 렌즈가 여러 개 달리기까지 한다면 한번에 더 넓은 풍경을 길쭉하게 사진에 담을 수 있을 것이다.

화소 수나 후보정 기능뿐만 아니라 본인이 정말 신기하게 생각하는 기능은.. 사진의 흔들리는 걸 걱정할 일이 예전에 비해 매우 줄어들었다는 것이다. 이건 소프트웨어적인 흔들림 보정 알고리즘의 산물이다.

옛날에 덜 스마트하던 디카는 사진이 흔들려서 망치는 일이 흔했을 뿐만 아니라, 그 자그마한 화면으로는 찍었던 사진이 흔들렸다는 걸 인지하는 것조차 쉽지 않았다.
사진을 찍은 현장에서 흔들림을 감지했으면 곧장 다시 찍기라도 했을 텐데.. 여행을 마치고 돌아와서 사진을 PC로 옮겨서 큰 모니터 화면으로 본 뒤에야 흔들리는 걸 알게 됐다면 허탈함 그 자체이다. 위조지폐를 현장에서 바로 적발하지 못하고 은행에 입금할 때에야 뒤늦게 알아챈 것과도 비슷한 상황이다.

그나마 재래식 디카가 스마트폰보다 나은 점은 배터리 용량이 더 많고, 안 쓸 때는 꺼 놨다가 나중에 켤 때 부팅이 필요 없이 즉시 켜져서 ready 상태가 된다는 점, 비슷한 체급일 때 zoom 성능이 더 뛰어나다는 점 정도를 꼽을 수 있겠다.

앞으로 영상뿐만 아니라 음성도.. PC에서 마이크 꽂아서 2채널 스테레오 음향을 한번에 입력해 넣는 방법은 생길 기미가 없는지 궁금하다.

2. 휴대전화

라떼는 말이야..

  • 체크카드: 신용카드 = 피처폰: 스마트폰 과 비슷한 관계인 것 같다. 특히 둘 다 왼쪽에 비해 오른쪽(신용, 스마트..)은 영업사원들이 기를 쓰고 팔려고 안달 나 있다는 공통점이 있기도 하다.
  • 인류 역사상 전화기가 크기가 가장 작던 때는 폴더폰 시절일 것이다. 그러다가 요즘 스마트폰은 화면과 배터리 때문에 어쩔 수 없이 다시 좀 커져 있다.
  • 폴더폰 시절에는 전화기를 통째로 거치대에 꽂아서 배터리 충전을 하던 시절이 있었다~!! ㄷㄷㄷ 기억하시는가? 그리고 2000년대엔 충전 단자를 통일한답시고 한때 24핀짜리 표준 단자가 제정되기도 했었다.
  • 그렇게 전화기가 자그맣고 별 기능이 없던 시절에는 배터리를 한번 충전해서 2~3일은 기본으로 썼다. 통화를 안 하고 있으면 무려 1주일 가까이 가는 물건도 있었다.

먼 옛날에 사람들이 뭔가 자원이 남은 비율 퍼센티지를 신경 쓰던 것이 30여 년 전엔 Windows 3.x/9x의 시스템 리소스 퍼센티지였다. 그러나 지금 사람들의 최고 관심사는 폰의 배터리 퍼센티지일 것이다.;;
그 밖에..

(1) 전화기에서 스피커폰은 귀를 송수화기에다 대지 않아도 통화를 들을 수 있게 하는 무척 편리한 기능이다. 하지만 이때 기기에서 내는 수신음이 또 마이크를 통해서 송신되고, 그게 또 수신되어 스피커폰으로 들리는 현상이 무한 반복되면서 소리가 울리는 문제가 발생할 수 있다.

이건 통신 기기에서 굉장히 고전적으로 유명한 문제이다. 자기가 받은 소리가 중복 송신되어서 울리지 않게 하는 건 echo 제거(echo cancelling) 기술이라고 따로 있다. 보통은 받는 쪽에서 echo 제거를 적용해야 보내는 쪽에서 echo를 듣지 않게된다.
뭔가.. 헬리콥터에서 로터가 돌면서 동체까지 돌아가는 현상을 상쇄하는 것과 비슷해 보인다. (꼬리날개, 반대 방향 로터 등..)

(2) 내가 말하지 않고 듣고 있을 때는 내 쪽의 불필요한 소음이 상대방에게 전혀 송신되지 않게 하는 일종의 mute(마이크 끄기) 기능이 있으면 좋겠다. 내 쪽에도 상대방에게 들리기를 원하지 않는 배경 소리 같은 게 있기 때문이다. 뭔가 전화기를 무전기에 가깝게 사용하게 되는 듯하네..

(3) 자동차 번호판이 공간이 부족해서 자릿수가 하나 확장됐고, 인터넷 주소도 공간이 부족해서 IPv6가 등장했는데.. 휴대전화 번호도 마찬가지다. 010 다음의 8자리는 좀 간당간당해 보이는데 이건 어째 공간을 확장한다는 말이 없는 것 같다.

(4) 스마트폰은 앞서 언급했던 디지털 카메라뿐만 아니라 다른 여러 휴대용 전자기기들의 역할을 흡수하고 대체했다. mp3 플레이어, 전자 사전, 계산기 따위는 얄짤없지만, 그나마 독자적인 역할이 있어서 완전한 상위 호환 대체가 어려운 건 손목시계이다.
스마트폰은 이것저것 기능이 많아지다 보니 보다시피 옛날 폴더폰이나 어설픈 피처폰 시절에 비해 덩치가 꽤 커졌기 때문이다. 그러니 얘는 과거의 회중시계의 대체제이지, 이대로 손목시계를 대체하기는 난감하다. 그 분야는 스마트워치라는 물건이 따로 만들어져 나오게 됐다.

3. 소프트웨어

  • 지난 2009년은 코드소프트와 티맥스 윈도우,
    2016년은 서든어택 2 (온라인 게임), 그리고 갤럭시 노트 7 (스마트폰)이 업계 최악의 굴욕 흑역사로 기록됐다.
  • 2021년은 LG전자가 스마트폰 사업을 완전히 접고 철수한 해, 인텔에서 비운의 IA64 프로세서를 드디어 20여 년 만에 완전히 단종시킨 해, 그리고 30여 년을 존속했던 경상용차 다마스와 라보가 단종된 해가 되었다.
  • 또한, 2020년대가 되니 애플에서는 PowerPC, x86에 이어 CPU 이주를 또 시도하고 있고.. Windows와 macOS 모두 메이저 버전이 10에서 11로 올라갔다.;;

2010년대 중후반에 컴터 소프트웨어 세계에서 개인적으로 굉장히 인상깊게 느낀 변화는 다음과 같다.

  1. 플래시가 순식간에 웹에서 싹 퇴출되고 사라짐. 브라우저들에서 지원도 끊김.
  2. 왕년에 스타와 워3, 디아블로를 만들었던 그 천하무적 제작사가 정말 급속히 몰락하고 망조가 듦.
  3.  IE 브라우저가 이제 완전 퇴출 직전임. 얘 없어진 뒤에도 공인인증서 로그인과 은행 돈거래가 가능하려나..??

(1) 플래시 액션스크립트는 전부 천하무적 html5 자바스크립트로 바뀌어서 오늘날까지 건재한다. 이젠 웹브라우저가 그 자체만으로 가상 머신에 반쯤 운영체제처럼 돼 버렸다.
플래시에서 원래 주전공이던 벡터 애니메이션 대신 웬 동영상(flv)을 지원하기 시작한 것, 그리고 유튜브가 플래시 없이 html5 기반으로 바뀐 것, 인터넷 지도와 구글 어쓰가 아무런 플러그인 없이 브라우저에서 바로 구동되기 시작한 것.. 모두 굉장히 충격적이었다. 플래시는 vb6에 대응하고, html5는 vb.net에 대응하는 것 같다.

(2) 게임 업계는 정말 영원한 강자란 없는 것 같다. 이드 소프트, 세가의 스즈키 유, 오리진의 울티마 만들었던 그 우주먹튀 뭐시기.. (아! 리처드 개리엇) 등등.. 한때의 스타 개발자가 언제까지나 계속 스타이지는 못한 것 같다.
지금은 FPS고 RTS고 나올 거 다 나오고 나서 새로운 게 뭐가 있을까? 이젠 현질 아이템 장사 말고 다른 돈 버는 방법이 남아 있을까..?? 궁금하다.
뭐 몇 년 전에 리니지 M은 돈을 빗자루로 긁어모으면서 그렇게도 성공했다고는 하더라;;

(3) 20여 년 전엔 마소 IE의 독점 불공정 끼워넣기 때문에.. 수장인 빌 아저씨는 평생 먹을 욕을 이 시기에 다 쳐먹었다. 카피레프트 안티 마소 진영으로부터는 완전 뿔 달린 악마 취급까지 받았다.
사실 더 옛날에, 1994~95년경엔 빌 아저씨가 msn으로 세계를 정복할 생각까지 했었다. 하지만 어림없는 얘기. 인터넷의 물결을 막을 수 없으니 다음으로 브라우저 독점을 생각했었으나 그 계획은 2004년 파이어폭스 0.8, 2008년 크롬과 함께 완전히 물 건너갔다. 넷스케이프가 이루지 못한 일을 쟤들이 대신 해냈다.

그리고 지금이야.. 웹브라우저 점유율을 제일 많이 떼어간 건 모바일이다. 마소가 범접하지 못한 완전히 다른 플랫폼..
10여 년 전에는 마소에서도 고인물 썩은물인 IE 6을 퇴출시키려고 난리였는데, 이제는 IE 자체가 퇴출 수순을 밟고 있다.

Posted by 사무엘

2021/12/03 08:34 2021/12/03 08:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1960

바야흐로 2021년에 또 30여 년 전의 고전 게임인 페르시아의 왕자를 소재로 글을 써 올리게 되다니.. 감격스럽기 그지없다.
이번에는 이 게임에서 주인공의 적으로 등장하는 검객, 경비병들에 대해 외국 사이트에서 분석한 데이터를 본인의 경험과 곁들여서 소개하고자 한다. 갑자기 이 주제로 글을 쓰고 싶어졌다.

페르시아의 왕자 게임에는 가시, 칼날, 절벽처럼 주인공의 체력을 깎아먹거나 주인공을 즉사시키는 트랩들이 여럿 존재한다. 검객은 그런 트랩들과 달리 유일하게 생명체이다.
조던 메크너가 열심히 코딩을 하다가.. 게임이 더 다이나믹하고 재미있기 위해서는 '전투'라는 요소가 필요하다는 걸 뒤늦게 깨닫고 검객을 구현했다고 한다. 이건 유명한 일화이다.

본인은 어린 시절에 이들을 knight를 연상시키는 기사라고 부르곤 했다. 하지만 얘들에 대한 공식 명칭은 guard(s), 즉 경비병에 가깝다. 검객이라고 하니까 무슨 일본 시노비나 암살 자객 같은 느낌이 들고.. 앞으로는 그냥 간단하게 적병이라고 부르도록 하겠다.

페르시아의 왕자 게임은 칼싸움 동작을 "휘둘러 찌르는 공격 아니면 막기"라는 두 종류로 극도로 단순화시켰다. 남의 공격을 평범하게 막으면 대미지를 입지 않는 대신, 찌르는 사정거리 밖으로 살짝 후퇴도 하게 된다. 물론 칼빵을 맞아도 후퇴..

막으면서 잽싸게 공격을 시도하면 뒤로 밀려나지 않으면서 적에게 반격을 할 수도 있다. 그런데 적도 그걸 막으면서 반격하고 나도 또 막고 반격하면.. 뭔가 그럴싸한 칼싸움이 연출된다. 자신과 상대방이 거리가 어느 정도 되는지도 이 싸움의 진행에 영향을 끼친다.
그렇게 공격과 방어를 반복하다 보면 언젠가 컴퓨터 적병이 반드시 맞고 뒤로 밀려나는 것으로 순환이 끝난다. 재미를 위해 알고리즘이 주인공의 필승으로 귀결되게 구현돼 있는 것 같다.

이 게임이 무슨 대전 액션 시뮬레이션은 아니니, 현실의 칼싸움처럼 이동과 공격을 동시에 한다거나, 상하 좌우 다양한 방향으로 칼을 휘두르고 기상천외한 부위를 찌르고 서로 칼날을 부딪친 채로 힘싸움을 하는 건 존재하지 않는다.
하지만 그 시절에 칼싸움이라는 걸 이렇게 단순화된 형태로 구현한 것만으로도 굉장히 참신한 시도가 아닐 수 없다. 플랫폼 아케이드 장르의 게임에 공격뿐만 아니라 '방어'라는 기동이 존재하는 물건 자체가 매우 드무니까 말이다.

게다가 이 게임은 적병들의 AI를 나름 다양한 난이도로 구현하는 섬세함까지 보였다.
1편에서 레벨 1에 나오는 적병, 그리고 2편에서도 레벨 1, 궁전 옥상에서 마주치는 적병은 난이도가 최하이다. 칼을 휘둘러 찌르는 것만 반복하고 있으면 알아서 다가와서 칼 맞고 꽥~ 죽어 준다. 그러나 이렇게 너무 쉬운 적병은 그 다음 레벨부터는 결코 다시 등장하지 않는다.

그 다음 레벨부터 나오는 적병들은 내가 칼을 쉬지 않고 휘두르는 동안에는 나에게 다가오지 않는다. 조금 뜸을 들여야만 접근하며, 그렇게 다가올 때 공격을 몇 번 성공시키면 적병이 죽는다. 페르시아의 왕자 1편은 대부분의 적들을 이 테크닉만으로 해치울 수 있다.

그런데 레벨 4쯤 되면 적이 약간은 더 똑똑해진 것 같다. 내 공격을 호락호락 맞아 주지 않고 막는 빈도가 유의미하게 높아져 있다. 그리고 아주 가끔은 막고 나서 내게 반격도 한다.
게다가 레벨 6에 나오는 그 '뚱보', 그리고 최종 보스인 Jafar는 공격 키만 사용해서는 해치우기가 거의 불가능하다. 내 공격을 90% 이상의 확률로 막고는 반격을 하기 때문이다. 나도 '막기'와 '공격'을 뒤섞으면서 난전을 벌여야만 놈을 때릴 수 있다.

이런 것들이 내부적으로는 어떻게 구현돼 있을까?
페르시아의 왕자 게임은 소스가 공개되어 있다지만 너무 옛날 애플 II 어셈블리어여서 분석이 상당히 난감하다.
하지만 제작자가 이것 말고도, 타 플랫폼 포팅 작업 때 참고하라고 내부 알고리즘 기술 문서를 만들었던 것도 공개한 게 있어서 큰 도움이 된다. 얘는 2000년대 이후부터는 이미 레벨 에디터까지 다 만들어져 있다.

이것들을 분석한 자료에 따르면 적병들의 AI는 다음과 같은 형태라고 한다. (☞ 문서)

사용자 삽입 이미지

  • 레벨 1에만 나오는 제일 쉬운 적병의 skill은 0
  • 나머지 레벨 2에서 11 사이에 나오는 일반적인 적병들의 skill은 1부터 4까지 4등급으로 나뉜다. 참고로 레벨 3에서 등장하는 해골의 skill은 2로, 그냥 평범한 편이다.
  • 레벨 6에 나오는 뚱보의 skill은 5이다.
  • 레벨 8의 첫 부분에만 나오는.. 스스로 공격을 절대로 하지 않는 특이한 적병의 skill은 7이다.
  • 레벨 12에서 등장하는 그림자 인간/도플갱어의 skill은 3이다.
  • 그리고 최종 보스인 쟈파의 skill은 9이다.
  • 0부터 11 사이의 skill 코드 12개 중, 나머지 값들은 쓰이지 않았다. (6, 8, 10, 11)

저 문서에서는 게임의 인트로 화면을 가만히 지켜보고 있을 때 잠깐 등장하는 데모 플레이의 칼싸움도 5, 즉 레벨 6 뚱보의 skill이라고 말한다. (무슨 근거로?)
하지만 내 생각은 다르다. 데모에서 왕자(주인공)와 적병의 스킬이 각각 10과 11, 또는 11과 10이 아닐까 생각한다.
왜냐하면 일단 페르시아의 왕자 원판 소스에서 "10: kid (demo) / 11: enemy (demo)"라는 문자열을 볼 수 있기 때문이다. 저 10과 11이 AI 인덱스를 가리키는 게 아닐까..?

또한, 데모를 오랫동안 지켜보고 있으면 주인공과 적병의 칼싸움 결과는 그때 그때 다르다(난수를 잘 사용하는군!!). 하지만 주인공은 이길 때보다는 질 때가 훨씬 더 많다. 주인공은 적병보다 반격을 당해 칼빵을 맞는 경우가 더 잦으며, 심지어 계속 뒤로 밀려나다가 절벽에서 떨어져 처참하게 죽기도 한다. 최소한 이 두 사람의 skill이 동일해 보이지는 않는다.

이런 이유로 인해 본인은 skill 테이블에서 정말로 미사용인 것은 6과 8 둘뿐이라고 생각한다만.. 이 역시 추측일 뿐이다.

적병의 AI를 결정하는 변수들은 다음과 같다. 어떤 건 직관적으로 이해가 되지만 어떤 건 제대로 문서화돼 있지 않아서 알기가 어렵다. 제일 이해하기 쉬운 방어 관련 변수부터 소개하면 다음과 같다.

  • 방어 확률(blockprob): 주인공의 공격에 얻어맞기만 하는 게 아니라 막을 확률. 레벨 1의 적병은 그런 게 전혀 없어서 우리의 공격에 반드시 당한다. skill 1,2에서는 150/255(대략 60%), 3,4는 200/255(78%)이라고 한다.
    뚱보와 쟈파는 100%로 무조건 막는다. 그래도 가끔은 쟤들에게 막기 없이 공격을 성공시키는 경우도 있는데, 그건 살짝 멀리 떨어진 상태에서 쟤들이 이동이 덜 끝나고 미처 방어 기동을 하기 전에 찌르기가 먹혔기 때문에 그렇다.

  • 방어 후의 재반격(restrikeprob) 확률: 우리 역시 막기 기동을 쓰지 않을 수 없게 하고 칼싸움의 체감 난이도를 크게 끌어올리는 변수이다. skill 0~2의 적병은 재반격을 전혀 하지 않으며, 3,4는 극히 드문 빈도로 재반격을 한다. 그 반면, 뚱보와 쟈파는 매우 높은 확률로 재반격을 하며, 쟈파는 100% 반드시 반격한다.

다음으로 공격 관련 변수이다.

  • 공격 영역에 들어올 확률(advprob): 주인공을 향해 사정거리 안으로 진격해 올 확률..이라기보다는 속도이다. 이건 적병들의 난이도별로 딱히 유의미한 차이가 없는데, 딱 하나 튀는 놈은 바로 레벨 8에 유일하게 등장하는 그놈이다. 얘는 확률이 0이기 때문에 절대로 먼저 들어오지를 않는다. 주인공이 칼을 완전히 집어넣어야만 들어오기 때문에 이때 다시 칼을 꺼내서 공격하거나, 아니면 우리가 치고 들어가서 공격을 막고 반격해야 한다.

  • 공격 확률(strikeprob ??): 주인공이 사정거리 안에 있을 때 공격을 할 확률 내지 속도인데.. 이게 적병들별로 유의미한 차이가 무엇을 만드는지는 잘 모르겠다. 얘도 레벨 8의 그 특이한 적병만이 이번엔 반대로 유난히 높은 값을 갖고 있다.

그 외에도 이런 게 있다.

  • 칼 맞은 뒤의 refractory 시간(refract timer): 공격을 당하고 나서 움찔 하는 시간으로, 얘 역시 그렇게 유의미한 동작 차이를 만들지는 않는다. 얘가 10으로 설정된 적병은 20으로 설정된 적병보다 칼에 맞은 뒤에도 좀 더 빨리 앞으로(하지만 주인공의 칼에 맞지는 않는 거리로) 다가온다.

  • 방어가 impair되는 확률(impblockprob ??): 제일 미스터리한 놈이다. 심지어 기술 문서나 소스 코드에 설명도 전혀 되어 있지 않고 대놓고 존재감이 없다. 상급 몬스터로 갈수록 값이 커지는 걸 보니 뭔가 좋은 속성 같은데, impaired block이라는 말은 핸디캡을 나타내는 부정적인 의미인 것도 이해되지 않는다.

아까도 얘기했다시피 제일 쉬운 skill 0짜리 적병은 주인공이 제자리에서 방어 없이 칼을 휘두르고만 있어도 알아서 달려와서 칼 맞고 죽어 주는 유일한 놈이다. 언뜻 보기에 여기에 해당하는 듯한 특성은 advprob이 최대치인 255인 것이다. 그런데 얘는 뚱보, 쟈파 등 다른 악당들의 AI도 최대치 255이기 때문에 유일한 변별 요소가 되지 못한다. 쟤만 blockprob이 완전히 0인데 여기에 그 동작 특성도 포함돼 있는 건가 궁금해진다.

아 그리고 impblockprob 말이다. 문득 드는 생각은.. 주인공과 적병이 계속 막고 치고 난전을 반복하고 있다가 결국 적병이 힘이 밀려서 맞고 나가떨어질 확률과 관계가 있어 보인다. 값이 클수록 오래 버티는 걸까..?? 즉, 쟈파나 뚱보 정도는 돼야 의미를 지니는 변수라 하겠다. 이건 외국의 페르시아의 왕자 해킹 커뮤니티에도 나와 있지 않는 내 추측이다.

게임에 칼싸움도 모자라서 이 정도로 다양한 적병 skill을 대여섯 개 남짓한 변수값의 조절만으로 구현한 거라면 정말 대단하지 않을 수 없다.

사용자 삽입 이미지사용자 삽입 이미지

(페르시아의 왕자 1의 데모 진행 장면. 이 데모 레벨은 실제 게임에서는 존재하지 않는다.
한편, 2편도 게임 실행 후 키를 누르지 않고 스토리를 끝까지 지켜보고 있으면 플레이 데모가 나오기는 한다. 얘는 실제 게임의 레벨 1에서 시작하는데, 왕자는 얼마 가지도 못하고 그 쉬운 적에게도 거의 자살 급으로 칼에 맞아 허무하게 죽어 버린다. 2편이 데모의 퀄리티가 1편의 것보다 더 부실하다.)

페르시아의 왕자 1편은 보스급 몬스터인 뚱보와 쟈파만이 막고 치는 고급(?) 스킬이 필요한 반면, 2편은 빨간 궁전에 나오는 새대가리 적병들이 모두 그 정도 스킬을 보유하고 있다.
2편은 한 화면에 적병이 여러 명 한꺼번에 등장할 수도 있고, 싸우다가 자리를 바꿔서 회피하는 게 거의 불가능해졌고, 막고 치면서 싸우다 보면 서로 가까워지다가 좌우 자리를 바꾸기도 하는 등.. 전투 요소가 1편보다 훨씬 더 강화되었다. 그리고 최종 보스는 칼싸움이 아니라 장풍을 맞혀서 죽이는 것으로 게임 진행 방식이 달라졌다.

끝으로, 저 문서에서 special color와 one extra health는 칼싸움 skill과 무관한 boolean 값이며 큰 의미는 없다.
페르시아의 왕자 1편의 경우, 각 레벨별로 모든 적병들의 기본 HP가 정해져 있어서 동일한데, one extra health가 true인 skill이 지정된 적병은 HP가 그 기본값보다 1 더 많게 된다.
이 비트가 true인 skill은 4가 유일하다. 즉, 보스가 아닌 졸개 중에서 칼싸움을 약간 잘하는 놈이 HP도 1 더 많은 것이다.

그래서 레벨 4에서는 후반부에 HP가 4인 적병이 처음으로 등장하며(기본값 3), 레벨 5에서는 HP가 4부터 시작했다가 나중에 5로 늘어난다.
skill 4인 적병은 던전 레벨에서는 전혀 존재하지 않고 궁궐 레벨에만 존재한다는 것이 흥미로운 점이다. 레벨 4~5, 10~11 말이다.

Posted by 사무엘

2021/11/07 08:35 2021/11/07 08:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1951

1. open이라는 타이틀이 붙은 유명 라이브러리들

  • OpenGL: 3차원 그래픽. (DirectX만이 직접적인 경쟁자로 남아 있는 듯..)
  • OpenCV: 2차원 래스터 그래픽에서의 영상 처리. 뽀샵질 보정, 사물 윤곽 인식 따위
  • OpenMP: 병렬처리 프로그래밍. 단순히 함수· 클래스만 제공하는 게 아니라 프로그래밍 언어 자체의 확장까지 수반한다.
  • OpenSSL: 각종 보안/암호 키 교환 프로토콜 구현, 해시· 암호화 함수들과 제반 연산 기능(큰 정수) 컬렉션

또 뭐가 있을까?
얘들은 각자 자기 분야에서 유구한 역사와 압도적인 인지도를 자랑하는 데다, 엄청 방대한 기능들을 무료로 덥석 제공한다. 다양한 언어와 플랫폼을 지원할 뿐만 아니라 최신 알고리즘이 수시로 반영되어 추가되고, 최신 하드웨어의 명령어에 맞게 최적화와 검증도 잘 돼 있다. 그야말로 더 바랄 게 없는 상태이다.

그렇기 때문에 개인적으로 내부 동작 원리를 공부를 하는 게 아닌 이상, 누군가가 현업에서 저런 기능들을 굳이 처음부터 다시 구현할 필요는 없다. 방대한 라이브러리의 사용법을 익혀야 한다는 최소한의 부담만이 있을 뿐.

유닉스에 대해서 누가 말했던가..? "유닉스를 쓸 줄 모르는 사람은(grep 등의 각종 명령어와 유틸리티, 정규 표현식 따위..), 유닉스가 제공하는 기능을 결국은 스스로 직접 또 만들게 될 것이다"라고..;; (reinvent the wheel) 그런 것처럼 말이다.

다만, Open이라는 단어가 붙었고 사용이 무료라고 해서 반드시 오픈소스이기까지 하지는 않은 것 같다. 가령, OpenGL이 오픈소스이고 git 저장소가 있다는 얘기는 난 못 들었다.
그리고 폰트 렌더링 분야의 본좌 라이브러리는 이름이 FreeType이다. OpenType은 라이브러리가 아니라 폰트 파일 포맷 규격의 명칭이다.

지금 국내의 오픈소스 진영엔 libhangul이라고 한글 입력 오토마타를 구현해 놓은 라이브러리가 있고 그걸 유수의 공개 한글 IME들이 사용하고 있다. 얘들은 초창기에 이름이 '열린 한글 프로젝트'였던 것 같은데 지금도 그러한지 궁금하다.

한때 '열린 한글'은 1990년대 말에 아래아한글이 개발 중단 위기에 처했을 때 "우리 다같이 힘을 합쳐서 아래아한글의 클론을 오픈소스 형태로 밑바닥부터 만들어 봅시다~!!" 이런 프로젝트의 명칭으로 쓰이기도 했었다..;; 거의 IMF 금 모으기 운동 같은 발상이었다.

이제는 마소에서 개발한 제품조차도 about이나 acknowledgement 화면에.. 제품 내부에 사용된 각종 오픈소스 프로젝트들 목록이 뜨는 날이 올 것 같은데... 격세지감이다. (하지만 나는.. 정작 내 한글 입력기부터가 오픈소스가 아니며 기존 오픈소스를 사용하는 것도 전혀 없다..;; )

2. GWBASIC 소스 공개!!

작년에는 마소에서 GWBASIC의 원본 소스 코드를 공개했다. 오오 +_+ (☞ 링크)
마소에서는 진작부터 MS-DOS와 Word의 옛날 초창기 버전의 소스를 공개한 바 있다. 하지만 그것들은 본인이 직접 써 본 기억이 없는 너무 옛날 버전이어서 그다지 감흥이나 공감이 없다.

그에 비해 GWBASIC은 본인의 어린 시절의 경험이 잔뜩 깃든 물건이고, 프로그램을 만들어 돌리는 프로그램이다 보니 접하는 느낌이 다른 제품들의 소스와는 사뭇 다르다.

  • Syntax error, Missing operand, Illegal function call, FOR Without NEXT (한글판은 "문법이 틀렸읍니다, 피연산자가 없읍니다, 기능호출 사용이 잘못되었읍니다" 등등..) 같은 친숙한 에러 메시지 문자열들은 GWDATA.ASM에 있다. 전설적인 Ok 프롬프트 값도 저기에 정의돼 있다.
  • 그래픽 모드에서 이차차분 알고리즘으로 원을 그리는 함수, 재귀호출로 flood fill을 수행하는(PAINT 문) 함수는 ADVGRP.ASM에 구현돼 있다.
  • MOTOR문은 하는 일 없이 에러만 내뱉는 것 같았는데, GIOCAS.ASM을 보니 실제로도 그러하다. 저건 카세트 테이프의 잔재일 뿐, 16비트 PC용인 GWBASIC에서는 하는 일이 원래 없다.

  • F1에 LIST부터 시작해 TRON, TROFF, KEY, SCREEN 0,0,0을 기본 배당하는 테이블은 GWRAM.ASM에 있고..
    Alt+A에 AUTO부터 시작해 BSAVE, COLOR, ... 등을 배당하는 테이블은 IBMRES.ASM에 있다.
  • 소스를 저장할 때 SAVE에다가 P 옵션을 줘서 어설프게 암호화 프로텍션을 거는 부분은 GIODSK.ASM, DISKCOM.ASM을 참고하면 될 듯하다.
    암호화된 파일과 그렇지 않은 파일이 첫 바이트 0xFE 또는 0xFF로 구분된다는 것을 확인 가능하다.
  • PLAY문에서 A~G 등 각종 문자열들을 해석하는 부분은 GWSTS.ASM을 보라. "MUSIC MACRO LANGUAGE"라고 주석이 돼 있다.

  • 부동소수점 연산?? 요즘처럼 전용 CPU 명령어 한 방으로 끝나는 시절이 아니었으니 전부 자체 구현이다.
    빌 게이츠가 왕년에 직접 고안했다는 MBF 부동소수점의 구현부가 바로 MATH1/2.ASM에 있다. 삼각함수, 로그도 내부적으로 테이블을 내장해서 소프트웨어적으로 직접 계산한다.
  • 난수를 생성하는 RND 함수의 공식은 MATH1/2.ASM에 있다. 그 유명한 Donald Knuth 아재의 책을 참고해서 구현했다고 주석에 적혀 있다.

아아.. 옛날 추억이 새록새록~~~
어셈블리어 코드를 읽을 수 있다면 흥미로운 유물들이 넘쳐날 것이며 아는 만큼 보일 것이다. 내가 읽을 수 있다는 뜻은 아님..;;
GWBASIC은 아무래도 정상적인 소프트웨어 개발 도구와는 좀 동떨어진 구석이 있지만, 그 옛날에 대화식 프로그래밍 환경이라는 걸 만들 생각을 한 건 충분히 참신하다고 볼 수 있다.

2000년대 이후에 태어난 뉴비 프로그래머들을 위해서 FAQ를 아주 자상하게 써 놨다. 이런 질문의 답변까지..;;

  • 아니, 오픈소스라면서 확장자가 C/CPP인 파일이 왜 하나도 안 보이나요?
  • C 파스칼 놔두고 왜 이렇게 알아보기 어려운 언어로 코딩을 했나요?

저 때는 고급 언어 컴파일러들이 엄청나게 비쌌고, 생성하는 코드의 성능이 좋지 못했다.
빌 게이츠와 그 일당들은 20대 나이 때, 지금보다 컴퓨터가 훨씬 더 열악하고 비싼 기계이던 시절에 여느 평범한 프로그램이 아니라 딴 프로그램을 만들고 돌리는 가상 머신급의 프로그램을 한땀 한땀 어셈블리어로 코딩해서 돌리고 납품하고 팔아먹었다는 거다.
그리고 한 언어의 인터프리터로서의 기능이 다 들어있던 GWBASIC.EXE의 크기는 실행 파일 압축 따위 없이도 겨우 6만 바이트 남짓밖에 안 했다는 거다.

이건 16비트 x86이 다른 CPU 아키텍처와 비교해 봐도 명령어 배치가 이례적으로 굉장히 조밀하기도 했기 때문에 가능한 일이다. 메모리 아끼기 위한 CISC 방식의 승리인 셈이다.

Posted by 사무엘

2021/07/27 19:36 2021/07/27 19:36
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1914

1. 90년대 중반의 제품 데모: 3D Studio R3, Windows 95

인터넷이란 게 없던(= 가정용으로 널리 보급되지 않은) 시절에 컴퓨터로 바깥의 최신 문물을 접하는 방법은 기껏해야 PC 통신, 아니면 컴퓨터 잡지와 함께 배포되던 부록 CD였다.
그런데 모뎀으로 접속하던 PC 통신은 접속 시간에 비례해서 부과되는 전화비의 압박이 심했으며, 전송 속도도 지금의 인터넷 전용선과는 비교조차 할 수 없을 정도로 느렸다. 그렇기 때문에 수십~수백 MB 이상의 대용량 자료를 배포하는 수단으로는 CD 같은 물리적인 매체가 여전히 의미가 있었다.

PC 통신 자료실이건, 잡지 부록 CD건, 이런 매체에는 유명 소프트웨어의 무료 체험판과 데모가 많이 포함돼 있었다. 유료로 판매되는 제품에서 일부 기능만 사용할 수 있거나 사용 기간이 제한된 것 말이다. 아니면 애초에 사용자가 조작해 볼 수 있는 기능은 없고 파워포인트 프레젠테이션처럼 일방적인 기능 소개와 화면 시연만 들어있는 데모 프로그램도 있었다.

그 중 본인이 인상깊게 봤던 것은 3D Studio R3.. 3DS에 MAX라는 이름이 붙기도 전, 게다가 도스용이 존재하던 시절 버전의 데모이다. 이거 화면을 유튜브에서 다시 보는 날이 오게 될 줄은 몰랐다. 정말 유튜브에 별별 것들이 다 올라온다..;; (☞ 링크)

요즘 같으면 파워포인트.. 하다못해 플래시로도 만들 수 있을 것 같은데.. 몇몇 화면 전환이나 프로그램 실제 화면 애니메이션 같은 건 난이도의 압박이 있을 것 같다.
1994년에는 아직 플래시도 없었기 때문에 도스에서 exe 형태로 저런 프레젠테이션 데모만 제작하는 전문 업체가 있었던 모양이다.

그리고 다음으로 소개하고 싶은 것은.. 국내에서 제작됐던 Windows 95의 데모 겸 기초 기능 튜토리얼이다. 95~96년 사이에 이거 보신 분 계신가..?? (☞ 링크)

"윈도우즈 구십오", "엠에스 더~스" 라고 또박또박 말하는 여성 나레이터 목소리가 찰지게 느껴진다.;;
도스와 Windows 3.1의 타성에 젖어 있던 사람들한테 시작 메뉴와 바탕 화면, 탐색기, 단축 아이콘(현재 명칭은 '바로가기') 개념을 처음으로 가르치고 홍보하느라 마소에서 그 당시에 돈 엄청 많이 쓰긴 했다.

이 데모 프로그램은 Windows 95 한글판의 CD에 포함된 프로그램은 아니었는데 어느 경로로 유포되었는지 궁금하다. 그냥 PC 통신이나 잡지 부록 CD였는지..?

2. 게임 데모

예전에도 한번 언급한 적이 있지 싶은데.. 과거에 스티브 잡스는 소수의 추종자 매니아를 양성하는 식으로 제품을 판매한 반면, 빌 게이츠는 정말 통 크게 남녀노소 가릴 것 없이 전세계에 컴퓨터를 보급해서 세계인들의 생활을 확 바꿔 놓고, 그 컴퓨터라는 기계에 우리 회사의 운영체제를 몽땅 뿌려 버리겠다는 심보로 장사를 했다.

그래서 Windows 95에서 드디어 32비트로 체제를 바꾸기도 했으니.. 얘를 본격적으로 게임용 홈 엔터테인먼트 플랫폼으로 만드는 일에 가히 사운을 걸었다. 그래서 거의 곧장 DirectX를 만들었으며, 특히 세계적인 히트를 치고 있던 Doom 2 게임 정말 0순위로 Windows용으로 포팅을 지원해 줬다.

PC에서, 그것도 DOS가 아닌 Windows에서 텍스처 매핑이 적용된 실시간 3D 게임이 돌아간다는 건 굉장히 획기적인 일이었다. Windows는 그저 지뢰찾기나 카드 게임 같은 가벼운 게임만 하는 플랫폼이라는 고정관념이 드디어 깨지기 시작했다.

애초에 Windows 95 원본 CD에는 Hover!이라고.. 범퍼카를 몰고 맵을 돌아다니며 깃발을 상대방보다 먼저 뺏는 게임이 있었다. 마소가 게임 전문 개발 업체는 아니지만, 이건 외주가 아니라 마소에서 직접 개발했던 듯하다.

사용자 삽입 이미지

얘는 비록 세계적인 명작인 Doom만치 막 박진감 넘치는 요소까지는 없지만, 그래도 그래픽은 Doom과 비슷한 수준이었다. 그리고 초보적이나마 1층 공간 위에 2층이 구현돼 있기도 했다는 점에서 Doom 엔진과 결정적인 차이가 있었다.

그리고 내 기억이 맞다면 Windows 95와 거의 동시에 Fury라고.. Hover의 공중 버전 내지 윙 커맨더의 축소판 같아 보이는 게임도 개발돼 나왔다. 얘는 외부 개발사와 합작 내지 외주 형태로 개발됐고 Windows 95에 포함돼 있지는 않았다.

사용자 삽입 이미지

게임 진행은.. 뭐 공중을 날아다니면서 총 쏘고 부수는 것 정도만 기억에 남아 있다.
마소는 Fury니, Hover!이니 하는 아기자기한 게임들을 같이 내놓으면서 우리 Windows 95는 저런 화려한 3D 그래픽이 가능한 게임용 플랫폼이라는 걸 기를 쓰고 내세웠던 듯하다.

그러고 보니 Win95의 발매 직후에는 DirectX라는 것도 아직 완전 듣보잡이거나, 버전이 2~3 이러던 시절이었을 텐데.. 3D 그래픽 가속이라는 건 퀘이크도 나오고 최소한 96~97년, Voodoo니 뭐니 하던 게 나온 시절부터 주목 받았을 텐데 저런 게임들은 CPU빨만으로 3D 그래픽 애니메이션을 구현했던 건지 궁금해진다.

끝으로, 비록 저렇게 1인칭 3D는 아니지만 3D 핀볼이라는 유명한 번들 게임도 있었다. 얘는 나름 Windows 3.1 + win32s에서도 돌아갔던 까마득한 옛날 프로그램이다.
마소에서 외부 업체로부터 소스 코드를 구입해서 자사 제품에다 포함시켰는데.. the old new thing 블로그에서의 회고에 따르면 코드가 주석 한 줄 없이 도저히 유지보수 가능한 상태가 아니었다고 한다.

훗날 Windows가 32비트에 이어 64비트로 갈아탈 때가 임박했는데, 얘는 내부적으로 오프셋 계산에 문제가 있었는지 64비트에서는 제대로 동작하지 않았다. 그런데 문제의 원인이 무엇이고 어디를 고쳐야 할지를 알 길이 없었고, 그렇다고 얘는 오픈소스화가 가능한 물건도 아니다 보니 64비트에서는 핀볼이 결국 짤리게 되었다.
그 외부 업체가 코드를 컴파일만 가능하고 유지 보수는 도저히 가능하지 않은 형태로 일부러 변조해서 줬던 것 같다.

3. 왓콤 win386

1990년대에 왓콤(Watcom)이라는 컴파일러 제조사는 PC의 도스 환경에서 32비트 프로그램의 개발 환경을 시세 대비 매우 저렴하게 제공한 일등공신으로 칭송받았다.

그 시절에는 아직 386/486급 PC의 가격도 아주 비쌌고, 32비트 코드 생성을 지원하는 컴파일러도 비쌌고, 특히 도스에서 이런 프로그램을 돌아가게 해 주는 DOS Extender도 아주 고가였다. 그런데 왓콤은 32비트 컴파일러와 무료 번들용 DOS extender까지 아주 파격적인 가격에 보급했던 것이다. 그러니 아주 전문적인 대형 고급 소프트웨어를 개발하는 분야에서 수요와 고객을 확보할 수 있었다. 볼랜드나 마소 같은 주류 컴파일러 제조사들은 그저 16비트에 안주하고 있었기 때문이다.

그런데 왓콤의 무서운 면모는 도스용 32비트 개발툴만 만든 게 아니었다는 점이다. 1990년대 초, 아직 Windows NT 3.1이 정식으로 나오기도 전에 멀쩡한 Windows 3.0/3.1를 마개조해서 32비트 코드를 구동해 주는 win386 Extender를 개발했다~! 그리고 이 시스템을 기반으로 돌아가는 32비트 코드를 생성하는 Windows 타겟용 컴파일러를 덤으로 보급했다. 기존의 16비트짜리 도스/Windows API를 호출할 때는 물론 입출력값을 변환할 테고 말이다. (☞ 더 자세한 소개)

이게 내부적으로 어떤 원리로 동작했는지는 잘 모르겠다. 오늘날의 Windows NT처럼 PE 포맷을 사용하지도 않았을 텐데..
하긴, 16비트 시절에는 Windows용 한글 바이오스(한메한글~!!)도 있었으니, 뭔가 시스템 내부를 마개조하기가 더 쉬웠던 것 같다.
당장 마소에서 옛날에 개발했던 FoxPro 2.5~2.6이 왓콤 win386을 기반으로 개발됐다고 한다.

그로부터 몇 년 뒤에 마소 본가에서 Windows NT를 출시해서 32비트 Windows API가 제대로 정립되고, 32비트용 Visual C++ 1.0과 win32s 같은 게 줄줄이 나오면서 왓콤 win386의 시대는 막을 내리게 됐다.
Windows의 32비트화 내력을 요약하면 다음과 같다.

  • real 모드: 1.0~3.0 (1985~1990) 사실상 640KB 기본 메모리밖에 사용하지 못하는 초 열악 모드.
  • 286 standard: 2.0~3.1 (1987~1993) real보다는 나은 것 같지만 정확하게 언제 처음으로 등장했고 차이점이 뭔지 존재감이 매우 없음.
  • 386 enhanced: 3.0~ (1990~??) 아직 32비트 코드를 시행하는 건 아니지만 도스창을 완전히 가상화할 수 있고 확장 메모리를 더 사용 가능함.
  • Win32s: 3.1 (1992~1996) 딱 32비트 코드 실행만 가능한 최소한의 모드
  • Windows 9x: 95~ME (1995~2000) 프로세스 별 주소 공간이 독립하고, 멀티스레드가 가능해짐
  • Windows NT: 3.1~10 (1993~현재) 유니코드 기반, 온전한 메모리 보호, 16비트 코드의 완전 가상화까지 실현

사실 386 enhanced mode라는 건 Windows 3.0 이전에 2.x의 386 에디션에서 최초로 도입되긴 했다. 하지만 이건 마치 Windows XP의 x64 에디션만큼이나 존재감이 없다.

4. 오 성식 생활 영어 SOS

우와~~ 이거 정말.. 추억의 멀티미디어 CD 타이틀이었다. (☞ 링크)
그 시절에 ToolBook이라고 CBT 멀티미디어 교육용 소프트웨어 저작도구가 있었는데..
쟤도 바로 툴북을 기반으로 만들어졌었다.
컴터에서 avi 허접 동영상이 재생된다는 것만으로도 왕창 신기하던 시절에 나왔던 물건이다.
저 타이틀에서는 도움말 나레이션만 낭독한 이 보영 씨 역시 현재까지 현역으로 뛰고 있는 유명 영어 강사이다.

그 뒤 저런 멀티미디어 컨텐츠를 만드는 플랫폼은 플래시로 넘어갔다가..
요즘은 플래시를 쓸 필요도 없이 저런 건 그냥 웹에서 HTML5 자바스크립트만으로 다 처리 가능하게 된 지 오래다.

쟤는 프로그램을 바로 종료하려 하면.. "공부라는 건 최소한 50분은 넘게 집중해서 해야 효과가 납니다. 그래도 지금 바로 종료하시겠습니까..."라는 확인 질문이 떴다. 내가 태어나서 지금까지 접했던 소프트웨어들 중 가장 훈계조로 종료를 저지하는 물건이었다.
반대로 Doom 2 게임은 온갖 농담 조크를 날리면서 종료를 저지했던 프로그램이고..

인트로 화면 보소..
딱 미리내 소프트웨어 "그 날이 오면 3" 게임의 인트로와 비슷한 환상적이고 몽환적인 느낌이 들지 않는가..??

레 솔솔 라 레레 솔 라시 레 시라솔 라~~
25년 가까이 지난 지금도 나는 멜로디를 정~확하게 녹음기로 틀어 놓은 듯이 기억하고 있다. 초딩 나이로 워낙 환상적인 경험이어서...

Credits를 보니.. 요 아름다운 인트로 음악을 작곡한 사람이 이 영수 교수(1951-2018. 영남 대학교 음대 작곡과)였다고 나온다.
어머니의 마음 "낳실제 괴로움 다 잊으시고..."의 멜로디를 만든 작곡가 이 흥렬의 아들이다.

Posted by 사무엘

2021/06/10 08:36 2021/06/10 08:36
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1897

2021년이 된 와중에 문득 생각을 해 보니.. Windows 8과 8.1은 정말 존재감 없이 소리소문 없이 싹 묻히고 사라진 것 같다.
XP, 7 다음에 바로 10이다. 8 계열은 20년 전의 ME만치 망한 건 아니지만 Vista보다는 더 흑역사이다.

사실 난 개인적으로는 옛날에 XP 다음의 Vista는 그 정도로 욕 먹을 퀄리티는 아니었으며, 일부는 오해와 누명을 쓴 것도 있다고 생각한다. 5년 만에 출시됐다 보니 갑자기 시스템 요구 사항이 너무 높아지고 일부 하드웨어와 호환이 깨지고, 사용자 계정 컨트롤이 도입된 게 반발을 일으켰을 뿐.. 그건 시간이 해결해 줄 수 있고 사후 재평가의 여지가 있는 이질감이었다. 7이라도 XP 다음에 바로 갑툭튀였다면 맞았을 질타를 미리 맞아 준 것의 비중이 크다.

그럼 8 계열은 사정이 어땠을까? 잠시 10여 년 전 당시 상황으로 되돌아가 보자.
이때는 나름 격변기였다. 아이폰이니 안드로이드니 하면서 본격적으로 스마트폰이라는 새로운 컴퓨팅 생태계가 조성되고 있었으며, 마소에서도 초대 원로 경영진(빌 게이츠, 스티브 발머)이 대거 은퇴하고 세대가 교체되고 있었다. 사내 분위기가 크게 요동칠 수밖에 없었을 것이다.

이 와중에 얼리어답터들은 “Windows가 7 이후로 2010년대엔 도대체 어디까지 변모할까? 마소는 이 시점에서 어떤 결정을 내릴 것이며 PC와 모바일과의 접목은 어떻게 이룰까?”라고 기대와 주목을 잔뜩 하고 있었다. 그때는 다음 버전이 심지어 재래식 NT 커널을 버리고 처음부터 다시 개발된다는 루머까지 나돌았다. (실제로는 그럴 리가.. NT 커널은 지금 Windows 10에서도 건재함! 없어질 수가 없다)

그랬는데.. Windows 7의 차기 버전인 8은 결과적으로 뭔가 구심점 없고 나사 빠진 듯한 망작이 되었다.
비주얼이 다시 심플해진 것은 그렇다 친다만, 갑자기 시작 메뉴가 없어지고 전체 화면으로 바뀐 것은.. PC와 스마트폰의 크기와 용도의 차이에 대한 고찰이 결여된 자충수였다. 게다가 8은 시작 메뉴 버튼 자체가 없었다~! 이런 제품이 어째 QA나 사용성 테스트를 통과하고 출시됐는지 모르겠다.

더 옛날인 2000년대엔 새 밀레니엄 컴퓨팅을 표방하면서 인텔 Itanium이라는 64비트 프로세서가 출시되었고 Windows는 2000뿐만 아니라 ME도 나왔었는데.. 아시다시피 Itanium과 ME는 대차게 망했다. 그런 것처럼 2010년대를 개막했던 Windows 8은 사용성 면에서 큰 혹평을 받으면서 XP와 7의 아성을 넘지 못했다.

그리고 사실은 스마트폰 OS의 쟁탈전도 매우 싱겁게 끝났다. 지금 다들 경험하시는 바와 같이 안드로이드 아니면 iOS로 양분되었고, 마소는 이 바닥에서의 주도권을 완전히 빼앗겼다. 심지어 웹 브라우저마저 IE 독점은 진작에 물 건너갔고 Edge 브라우저도 자체 개발을 포기하고 크로뮴 엔진에 흡수되지 않았는가?
국내로 치면 모바일에서 주도권을 완전히 주도권을 빼앗기고 삼성 전자와는 정반대의 처지가 된 LG 전자와 비슷하다고 하겠다..;

그러니 8 시절부터 Windows에 도입된 Metro 앱이니 하는 것 역시 폰에서는 볼 일이 없어졌다. Universal이라는 수식어가 무색해졌고 지금은 그냥 스마트폰 같은 큼직한 글자의 UI 엔진이 제공되는 특이한 프로그래밍 플랫폼? 가상 머신?처럼 됐을 뿐이다. NT 커널 없이 새로 개발된다는 엔진이 이런 곳에 적용된 거라고 보면 되겠다.

그렇게 결판이 난 뒤 마소에서는 스마트폰용 OS가 아니라 그냥 기존의 데스크톱용 Windows 10을 스마트폰용 CPU인 ARM64에다가 포팅하는 식으로.. 즉, 자기 정체성을 유지하면서 모바일 환경에다 손을 내민 상태이다. 요즘 PC와 스마트폰의 경계가 많이 모호해지긴 했지만 그래도 PC는 안 쓸 때도 24시간 내내 켜 놓는 물건은 아니며, 떨어뜨려도 될 정도로 튼튼한 물건도 아니라고 여겨진다. 그리고 스마트폰은 프린터나 재래식 하드디스크 같은 장치와는 여전히 친숙하지 않다.

그렇게 Windows 8 내지 8.1은 2010년대 초반 마소의 시행착오가 깃들어 있는 비운의 작품이 됐다.
개인적으로는 Windows 제어판이 Metro 기반인 ‘설정’으로 야금야금 대체된 건 글쎄.. 그냥 reinvent the wheel 삽질 같고 멀쩡한 인도 보도블록을 교체하는 듯한 느낌이다. 기존 제어판에 익숙한 사용자를 괜히 헷갈리게만 하고 말이다.
지금도 키보드의 반복 속도를 최대로 조절하는 것만 해도 설정에서 가능하지 않기 때문에 재래식 제어판으로 가야 한다.

그리고 프로그램의 제목 표시줄에 제목이 가운데 정렬로 표시되었던 Windows는 과거의 16비트 시절 1~3.x 아니면 후대의 8/8.1밖에 없다~!! 거기 말고는 MS Office가 뜬금없이 2007부터 현재까지 가운데 정렬을 하며 따로 노는 중이다.

나머지 Windows 95, NT4부터 7, 그리고 지금의 Windows 10은 다 왼쪽 정렬이다.
Windows의 역사상 32/64비트 시대에 프로그램 제목을 가운데에다 표시했던 버전, 그리고 시작 버튼이 없던 버전이 있었다는 걸 기억하는 사람이 얼마나 있을까? 문득 궁금해진다.

한글 IME의 개발이라는 관점에서 보면 Windows 8 계열은 메트로 앱에 대해서는 키보드 포커스를 얻었을 때 가/A 한영 상태를 IME가 근처에다 팝업 창으로 수동으로 잠깐 띄워주고, 상태가 바뀌었을 때도 그걸 띄우는 수고를 해 줘야 하는.. 약간 원시적인 조치가 필요하던 유일한 운영체제였다.
메트로 앱은 전체 화면에서 실행되는 관계로, 운영체제의 기존 도구모음줄(language bar)의 보조를 전혀 받을 수 없기 때문이다.

이것도 아무리 생각해 봐도 뻘짓이었다. 도구모음줄을 IME가 제각각으로 구현해야 했던 1990년대도 아니고.. Windows 10부터는 메트로 앱도 창 모드로 실행 가능하고, 입력기의 상태를 작업 표시줄(task bar)에서 확인 가능하기 때문에 저렇게 할 필요가 없어졌다. 즉, 저 관행 역시 일회적인 이벤트로 끝났다는 것이다.

이상. 이 글에서는 Windows 8 계열에 대해 주로 다뤘지만, 걔네 말고 Windows라는 운영체제 제품에 대해서 개인적으로 의아하거나 궁금한 점을 더 꼽자면 다음과 같다.

1. 비현실적인 권장 사양

마소에서는 Windows 7 64비트 정도의 시점을 마지막으로.. 자기 운영체제의 동작을 위한 최소 PC 사양과 권장 사양을 더 올려서 기재하지 않고 있다.
7이 램 최소 1GB 이상, 권장 2GB 이상인데.. 이게 Windows 8과 10까지 동일하다. 하지만 이건 개인적으로 생각하기에 완벽한 허위· 과장 광고라고 여겨진다.

도대체 어느 정도 돌아가는 게 최소 사양이고 어느 정도로 여유가 남는 게 권장인지 정확한 정의는 잘 모르겠다만.. 요즘 Windows 10은 램 8GB에서 돌려도 부팅 직후에 크롬 브라우저 창 몇 개나 MS Office 프로그램, Visual Studio 같은 걸 열면 메모리가 거덜난다. 정말 못 해도 16GB는 돼야 넉넉하다는 느낌이 든다.

Windows 7에서야 최소 1GB, 권장 2GB는 수긍할 만하며 램 8GB는 펄펄 날아다니는 용량이다. 하지만 10은 절대 그렇지 않다. 아무리 못 해도 최소 2, 권장 4 이상으로는 수정돼야 하리라 여겨진다. 그리고 요즘도 32비트 에디션이 나오고 있나 모르겠는데.. 걔는 이제 단종시켜도 될 것이다.

2. 서버 제품군의 존재감

Windows의 개인 사용자용 제품군은 아시다시피 2015년부터 10이라는 단일 브랜드 하에서 주기적인 업데이트를 통해 프로그램을 진화(?)시키는 형태로 바뀌었다. 하지만 서버 제품군은 여전히 2008, 2012, 2016 등의 연도 브랜드를 쓰고 있어서 다소 이질적이다. 이런 이원화된 버전 넘버링이 언제까지 계속될지.. 마치 Office 365와 기존 Office 20xx 패키지의 관계만큼이나 궁금해진다.

그리고 더 결정적으로는 기업 같은 데서 서버 제품군을 쓰는 곳이 있긴 한지..?? 이건 마치 Itanium 컴퓨터만큼이나 본인이 태어나서 지금까지 한 번도 구경해 보지 못했다.
왜냐하면 서버 제품군을 쓸 정도의 컴퓨터라면 차라리 유닉스 터미널이 내장돼 있는 리눅스나 맥OS를 쓰고 말지 Windows를 쓰지는 않기 때문이다.

서버 에디션은 원래 Windows NT나 2000까지는 동일 버전의 바리에이션 형태로만 존재해 왔다. 그랬는데 XP 때는 웬일인지 Server 2003이라고 제품명은 물론 내부 버전 번호까지 다르게 붙일 정도로(5.1 vs 5.2) 차별화를 했었다. 그 대신 XP는 개인용 에디션이 홈 vs 프로로 더 세분화됐다.
그 뒤로 서버 제품군은 버전 번호는 클라이언트와 동일하지만 제품명은 저렇게 Server 20xx 식으로 나가고 있다.

3. 자잘한 UI 버그

  • 가끔씩 재래식 TSF 입력 도구모음줄과, 작업 표시줄 쪽의 Windows 10 스타일 입력 상태 아이콘이 동시에 나타나는 버그는 꽤 유명했는데 19xx나 20xx 사이에서 드디어 고쳐진 것 같다. 요즘은 눈에 띄지 않는다.
    하지만 caret (cursor)이 여섯 번 정도 깜빡이다가 깜빡임이 중단되는 버그는 여전히 건재한 듯하다. Windows 3.1 이래로 이런 특이한 현상은 처음이다.

  • 가~~~끔. 컴을 절전 모드에서 꺼냈을 때나 프로그램 창을 전환했을 때.. 이미 띄워져 있는 프로그램 창들이 부르르 다시 그려지면서 깜빡이고 떨리는 현상.
    내 개인용 컴과 회사 컴이 모두 그러는데 좀 보기 거슬린다.
    윈10 초창기에는 이런 현상이 없었고, 특정 컴에서만 그러는 것 같지는 않은데 왜 그러나 모르겠다. (2004대 버전 기준)

  • 컴퓨터에 따라서 케바케이긴 하지만.. 메뉴가 '파일, 편집' 같은 라벨의 우측 하단 ┗ 모양이 아니라 ┛ 왼쪽으로 펼쳐지는 기괴한 현상이 왜 발생하는지 모르겠다. 아랍권도 아닌 멀쩡한 한국어/영어에서 말이다.
    로컬라이즈나 사용 접근성을 위해 필요한 옵션이라면 제어판에라도 옵션을 정식으로 갖다 놓든지..? 저런 동작이 왜 존재하는지도 모르겠고, 또 사용자의 동의 없이 불쑥 바꿔 놓고는 원상복구를 왜 레지스트리 수정을 통해서 해야 하는지 모르겠다.

Posted by 사무엘

2021/06/02 08:36 2021/06/02 08:36
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1894

1. 압축 유틸

요즘은 Adobe Reader 같은 거 설치할 필요 없이 크롬이나 Edge 같은 브라우저만으로도 자체적으로 pdf 문서를 바로 열어 볼 수 있다.
압축 유틸리티에서 광학 디스크 이미지 파일의 내용을 바로 볼 수 있게 된 것과 비슷해 보인다. 한 분야의 프로그램이 비슷한 다른 분야의 프로그램의 역할을 일부 흡수해 버렸다.

물론 이미지 파일을 새로운 드라이브로 mount 시키는 것까지 압축 유틸이 지원하지는 않는다. 그것까지 지원하면 압축 유틸의 기능이 옛날 도스 시절의 Double Space 같은 디스크 압축 유틸 급으로 커지는데.. 요즘은 그런 기능이 필요할 정도로 디스크의 용량이 부족한 시절이 아니기 때문에 유행이 지났다. 그리고 결정적으로 드라이브 mount는 이제 운영체제(Windows 10)가 자체적으로 제공해 주는 기능으로 흡수되기도 했다;;

국내의 경우 20여 년 전, 이 바닥이 WinZip, WinRAR 같은 외국산 압축 유틸리티 일색이던 시절에 이스트소프트의 '알집'이 처음에 적절한 마케팅 덕분에 시장 선점을 잘 해서 폭발적인 인기를 누렸다. 그러나 버그· 안정성 문제에 적절히 대처하지 못해서 2000년대 말쯤에 컴덕들 사이에 욕을 엄청 먹었으며, 그 와중에 기업 대상 유료화까지 선언하는 바람에 입지를 더욱 잃게 됐다.

그 와중에 개인 개발자 1인의 작품인 '빵집'이 알집의 대체제로 각광 받아서 2000년대 후반에 큰 인기를 끌었다.. 하지만 빵집은 개발자의 개인 취미 생활이다 보니 유지보수에 한계가 있었고, 결국 개발이 중단되어 역사 속으로 사라졌다.
그리고 오늘날이야.. 그 틈새를 저격한 반디소프트의 '반디집'이 탁월한 완성도로 천하를 평정했다.

압축 유틸의 역사를 읽어 보노라면, 소프트웨어는 모름지기 수요와 타이밍, 시장 공략을 잘 해야겠다는 걸 느낀다.
zip은 압축 해제뿐만 아니라 생성까지 소스가 완전히 공개돼 있고 그 다음부터 7z, ace, rar 등 압축 알고리즘들의 압축률은 이론적인 정보량 한계에 근접해서 거기서 거기이다 보니.. 알고리즘은 zip 하나만 있으면 되고 그 뒤 멀티코어, 64비트, 유니코드, 기본적인 보안, 운영체제 셸과 잘 연계하는 UI...

이것만 제공되면 그 다음부터 굳이 유료 유틸을 쓸 필요가 크게 줄어드는 것 같다. 실제로 본인도 '-집' 계열 유틸을 사용하기 시작한 뒤부터는 Windows에서 zip 말고 rar 등 다른 압축 파일을 '생성'해 본 적이라고는 전혀 없는 것 같다.

2. 유튜브

(1) 유튜브 동영상에 광고가 5~10여 년 전에 비해 굉장히 많이 늘어난 게 느껴진다.
뭐, 쟤들도 흙 파서 먹고 사는 건 아닐 테니, 오랫동안 무료로 잔뜩 뿌리고 투자했던 것을 회수할 때가 됐다. 전세계에서 발생하는 천문학적인 수의 동영상들을 저장하고 전송 트래픽을 감당할.. 서버 유지비가 장난 아니게 깨질 것이며.. 몸값 비싼 엔지니어들을 고용하는 인건비도 상상을 초월할 것이다. 서버 관리자, 웹 UI 디자이너 및 개발자, 동영상 코덱 전문가, 동영상 컨텐츠들의 검색과 분류 알고리즘 전문가 등..

그러니 동영상 포털이 사용자에게 거부감을 제일 덜 주면서 수익을 내는 건 광고 또는 사용자에게 "광고 안 뜨는 기간제 유료 계정" 판매로 자연스럽게 귀착될 것이다. 나도 광고가 너무 잦아지니 잠시 동안만이라도 광고 없는 유튜브 프리미엄 유료 계정을 써 보고 싶다는 생각이 종종 든다. 유튜브도 사용자를 이렇게 적당히만 귀찮게 하는 걸 목표로 하지 싶다.

요즘 친구들끼리 생일 선물로 카카오톡으로 이모티콘이라든가 커피 상품권을 주고 받는 게 있다. 그런 것처럼 몇천 내지 1~2만원대의 유튜브 프리미엄 n개월 이용권이 온라인/모바일 생일 선물로 오가는 건 어떨까 싶다.

여담이지만, 유튜브뿐만 아니라 평소에 위키백과를 지식 습득용으로 유용하게 사용해 온 사람이라면 거기에도 후원금을 소액이나마 내는 게 좋을 것이다. 특정 기업의 입맛에 휘둘리지 않고 상업 광고도 없는 개방된 지식 저장소는 컴퓨터와 인터넷을 지금 같이 누구에게나 평등하고 투명하게 개방된 정보의 바다로 만드는 데 절대적인 기여를 했기 때문이다.

(2) 다음으로, 돈이나 광고와 별개로 본인이 요 근래에 유튜브에 대해서 느끼는 굉장히 큰 불만이 하나 있다.
HD급 이상의 무거운 고화질 동영상일수록 더 두드러지는 것 같은데.. 슬라이더에서 좌우 화살표를 눌러서 앞뒤 5초 남짓 단위로 seek를 한번 하는 데 걸리는 딜레이가 너무 길다는 것이다. 동일 화질 기준으로 그냥 하드에 저장된 동영상을 데스크톱용 플레이어 앱에서 seek하는 것만치 빨리 즉시는 절대 못 한다. 답답하지 않으신가?

옛날 저화질 동영상은 이렇지 않다. 이건 다운로드 자체는 이미 다 된 구간을 돌아다니는 것만 말한다. 그러니 네트워크 상태하고도 무관하다.
기술적인 한계 때문에 느린 건지 아니면 이것도 설마 현질 유도를 위해 고의로 들어간 핸디캡인지는 잘 모르겠다.

(3) 끝으로, 유튜브 유료 계정에 제공되는 서비스로는 광고 제거뿐만 아니라 동영상을 아예 로컬에다 다운로드하는 것도 있었다.
하지만 그건 별도의 서비스가 없더라도 뒷구멍을 통한 다운로드 서비스가 넘쳐나다 보니 유튜브에서도 단속을 포기한 것 같다. 별도의 앱이던 게 더 간편한 웹으로 바뀌기까지 하고 말이다. 사실 이건 기술적으로, 근본적으로 막을 수 있어 보이지는 않는다.

3. 이메일: 대용량 파일 첨부, 발송 확인 및 취소 기능

15년쯤 전에 구글 gmail이 최초로 1GB짜리 웹 기반 무료 이메일을 개설한 이래로 요즘은 어디건 이메일 서비스는 기본이고 용량이 기가바이트급이다. 하지만 이메일은 편지함 용량과 컴퓨터의 하드 용량이 증가한 것에 ‘비하면’, 무슨 영화 파일 급의 대용량 첨부 파일을 주고 받기에는 여전히 좀 버거운 수단이다. 기껏해야 수~수십 MB 정도가 한계?

초대용량 파일은 메일에다가 직접 붙이는 게 아니라 다른 클라우드/웹하드에다 올리고 나서 그거 링크만 메일에다 넣는 형태로 대체되는 게 요즘 추세이다.
수신 확인 및 오발신 취소 같은 것도 이메일의 정식 프로토콜/스펙에 규정된 기능이 아니라 각 웹메일 서비스 사이트에서 자기 계정간 이메일에 한해서만 제공되는 비표준 편의 기능인데.. 이것도 좀 표준으로 승격됐으면 하는 바람이 있다.

4. 크롬 브라우저로 네이버 블로그 첨부 파일 다운로드

크롬 브라우저로는 네이버 블로그 기반의 사이트에서 첨부 파일 다운로드가 잘 되지 않는 문제가 있다.
나만 겪는 현상인 줄 알았는데 아니었구나..

검색을 해 보니, 네이버 블로그는 https 기반인데 다운로드 링크는 보안이 취약한 http 기반이어서 크롬이 의심스럽다는 이유로 다운로드를 차단한 것이었다.
즉, 네트워크 구조에 문제가 있어서이지, 첨부 파일의 내용에 문제가 있어서가 아니었다.

이렇게 웹페이지의 구성요소에 https와 http가 뒤섞여 있으면 브라우저가 의심스럽고 불안하다고, 그래도 내용을 다 보고 싶냐고 온갖 귀찮은 확인 메시지를 사용자에게 띄운다. 다들 한 번쯤은 그 모습을 본 적이 있을 것이다.

그런데 크롬의 경우, 그 어떤 에러 메시지도 없이 그냥 일방적으로 네이버 블로그로부터의 다운로드를 씹어 버리니 당혹스러웠다. 은행 ActiveX도 아니고 파일 다운로드를 위해서 구닥다리 IE를 끄집어내는 촌극이 벌어지기도 했다.
뭐, 궁극적으로는 천하의 네이버가 이 문제를 해결하고 네트워크 구조를 불안 요소가 없게 어서 고쳤으면 좋겠다.

크롬은 이제 올해부터 플래시조차 지원을 완전히 끊었다. 아직도 메뉴가 플래시 기반인 웹사이트는 한 몇 년은 관리를 안 한 완전 구닥다리.. "1024*768 해상도에서 IE 6 브라우저에서 가장 잘 보입니다" 이러면서 제로보드 게시판까지 같이 붙어 있는 사이트일 가능성이 높을 것이다.
세월이 참 많이도 흘렀다. 플래시, 제로보드, Visual Basic 6, 재래식 hlp.. 이런 것들이 역사 속으로 사라졌다.

5. 마이너한 검색들

일반적으로 널리 쓰이는 기능은 아닐 테니 유료 서비스 형태로 제공되더라도..

(1) 많고 많은 웹툰들은 그림 파일뿐만 아니라 말풍선 안의 대사들도 색인화돼서 대사로 해당 컷의 검색이 됐으면 좋겠다.
짤방으로 써먹고 싶은데 그 그림이 긴 웹툰 시리즈의 어느 화에 있었는지 기억을 못 할 때가 많다.
물론 "이 학교의 주인은 이사장인 나예요."(사립정글고), "네놈을 살려 두긴 쌀이 아까워!"(이말년), "선 넘네"(엉덩국 애기공룡 둘리) 같은 거야 너무 강렬하고 유명하니 일반 검색 엔진으로도 대사와 컷 이미지가 개념적으로 연결돼 버렸지만.. 그렇지 않은 컷도 많다.

(2) 주선율 음표 표기로 음악 검색. 밖에서 재생되는 음원을 들려줘서 비슷한 음반의 노래를 찾는 건 이미 서비스 되는 게 있지만.. 그건 음원이 없고 사람의 오랜 기억 속에만 존재하는 음악을 찾아 주지는 못한다. 내가 말하는 건 음악들의 주선율 악보를 색인화해서 검색하는 것이다. 다만, 이걸로 검색하려면 사용자도 최소한의 채보· 기보 능력이 있어야 한다.

검색 엔진이란 게 처음에는 같은 웹에서 텍스트 위주로만 검색을 지원했다. 그러나 요즘은 웹뿐만 아니라 종이책, 잡지, 옛 신문들과 방송 자료, 논문 같은 오프라인 매체로 범위가 확장되었으며, 정보의 형태도 텍스트에 국한되지 않고 그림과 동영상까지 취급한다.

그러니 이게 앞으로는 텍스트뿐만 아니라 사람이 마우스로 얼추 끄적인 스케치와 비슷하게 생긴 그림이나 실제 로고타입을 찾아 주고, 콩나물 배열만으로 음악을 찾아 주는 경지에 도달하지 않을까 싶다. 그야말로 사람의 기억을 보조해 주는 도구가 되는 것이다. 그리고 국내 웹툰뿐만 아니라 과거의 뉴스 보도, 특히 대한뉴스들도 다 색인화되면 엄청난 도움이 될 것이다.

Posted by 사무엘

2021/04/16 08:33 2021/04/16 08:33
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1877

지금으로부터 30년쯤 전에 도스용으로 만들어졌던 프로그래밍 툴 중에는 자기 언어로 만들어진 예제 프로그램으로 그럴싸한 게임을 제공하는 경우가 있었다.
QBasic의 경우, 포트리스 내지 Scorched Earth와 비슷한 형태의 턴 기반 슈팅인 '고릴라'가 유명했으며.. 길다란 뱀을 사방으로 적절히 조종하면서 아이템(?)을 먹는 퍼즐인 nibbles도 있었다.

사용자 삽입 이미지사용자 삽입 이미지

아이템을 먹을수록 뱀은 길이가 더 길어지며, 머리가 벽은 물론이고 자기 몸통과도 부딪치지 않도록 조종을 잘 해야 한다. 그리고 레벨이 올라갈수록 뱀의 이동 속도가 더 올라가고 장애물도 더 많아져서 게임 진행이 더 어려워진다.
영문판 원판은 80*25 텍스트 화면에서도 아스키 그래픽 문자를 적절히 이용해서 글자 한 칸을 상하로 쪼개어 세로 공간을 두 배로 늘리는 편법을 구현했다. 하지만 한글판에서 제공된 nibbles는 문자 코드의 한계로 인해 그런 게 다 삭제되었다.

그런데 가만히 생각해 보니 마소 말고 볼랜드 개발툴에서 제공한 예제 프로그램 중에는 가히 이 분야의 끝판왕이 있었다. 번듯한 체스 게임이 컴퓨터 AI까지 포함해서 소스가 통째로 제공되었던 것이다.

사용자 삽입 이미지

이거 기억하는 분 계신가..?
그런데 이게 bgidemo보다 훨씬 덜 유명하고, 본인도 지난 수십 년 동안 얘의 존재를 까맣게 잊고 있었던 이유는.. 아무래도 아무 버전에서나 쉽게 볼 수 있는 예제는 아니었기 때문이지 싶다.
즉, 보급형인 Turbo가 아니라 기함급인 Borland라는 브랜드가 붙은 C++ 내지 Pascal을 설치하고, Windows 개발 환경에다 자체 프레임워크 라이브러리까지 다 선택해야 얘를 구경하고 돌려볼 수 있다.

이 예제 프로그램의 이름은 볼랜드에서 개발한 C++용 Windows API 프레임워크의 이름을 딴 OWL Chess였다.
하지만 내 기억이 맞다면 Turbo Vision 기반의 도스용 체스 예제도 있었다. 체스판과 말을 그래픽 모드가 아니라 텍스트 모드에서 꽤 기괴한 색과 특수문자를 동원해서 표현했던 걸로 기억하는데.. 정확한 내역은 너무 오래돼서 잘 모르겠다.

Windows용 OWL Chess는 이런 식으로 동작했던 걸로 본인은 기억한다.

  • 16비트 전용이다. 32비트 에디션에도 포함됐다거나, Delphi 및 C++ Builder 같은 후대의 컴포넌트 기반 RAD툴로 리메이크 됐다는 소식은 내가 아는 한 없다. 그러니 얘는 Windows XP에서 실행됐을 때도, 저 스크린샷에서 보다시피 프로그램의 제목 표시줄에 테마가 적용돼 있지 않다.
  • 역시 저 스크린샷에서 묘사된 바와 같이, 창 크기는 고정 불변이다. 요즘처럼 모니터가 크고 화면 해상도가 높은 시대엔 크기 조절이 안 되는 프로그램은 사용자에게 좋은 인상을 주기 어려울 것이다.
  • 키보드 포커스가 딴데로 넘어가서 프로그램이 비활성화 되면 즉시 게임판이 가려지고 pause 모드로 바뀐다.
  • 컴퓨터 AI는 1990년대의 바둑 같은 보드 게임 AI들이 그랬던 것처럼 규칙 기반으로 move를 평가하고, 재귀적으로 수읽기를 하면서 알파-베타 가지치기로 복잡도를 제어하는 식으로 구현됐다. 생각하는 데 시간이 많이 걸리긴 하지만, 멀티스레드라는 것도 없던 시절에 이 동작이 찔끔찔끔 idle time processing만으로 잘 만들어져 있다. 컴퓨터의 생각이 현재 어느 정도까지 진행됐는지가 수시로 현란하게 시각적으로 표시되기 때문에 지겹지 않다.

하긴, 1990년대 초중반에는 프로그래밍깨나 공부 좀 한 사람들이 도스의 그래픽 모드에서 아기자기한 오목· 장기 게임을 구현해서 PC 통신 자료실에 무료로 공개한 게 많았다. 아, 심지어 화투 치는 고도리...도 그 시절부터 있었다.
또한 그 시절에 유명한 프로그래밍 기술 간행물이던 '비트 프로젝트' 시리즈에도 초창기엔 Borland C++로 개발한 Windows용 장기 게임이 있었다.

지금이야 국내에서 유료 판매까지 되고 있는 장기 게임 프로그램으로는 '장기도사'가 있다. 하지만 그 전에는 '바다장기'라는 프로그램도 있었는데, 얘가 내 기억이 맞다면 저 원조 OWL Chess의 소스를 기반으로 만들어진 듯했다.
프로그램의 외형과 동작이 굉장히 비슷하게 느껴졌었기 때문이다. 또한 바다장기도 검색을 해 보면 16비트스러운 스크린샷밖에 안 나오는 게 더욱 비슷하다.

사용자 삽입 이미지

그래도 서양의 체스와 동양의 장기가 완전히 동일한 게임은 아닐 텐데, 체스 AI를 장기 AI로 룰을 개조하는 건 건 아무나 할 수 있는 일이 아니었을 것이다. 그리고 그 원판 AI 코드도 move를 기술하고 평가하는 룰 계층만 바꿔 주면 어지간한 보드 게임의 AI에 모두 대응 가능하도록 상당히 추상적이고 깔끔하게 잘 만들어져 있었던 모양이다. 바다장기는 AI를 '추론 엔진'이라는 용어를 써서 표현했다.

일개 예제 프로그램의 체스 AI가 전문 상업용 AI에 비할 바는 아니겠지만.. 이 정도만 해도 어디인가? 지금 저 프로그램의 소스를 다시 볼 수 있으면 보드 게임 AI의 구현과 관련해서 많은 통찰을 얻을 수 있을 텐데 아쉽다. 얘의 소스만 어디 github에 따로 올라와도 될 텐데 말이다.
본인은 체스는 룰조차도 모르지만.. 그래도 학창 시절에 오목과 스크래블이라는 보드 게임 AI를 연구했던 이력이 있는 사람이어서 이런 쪽에 더욱 흥미를 느낀다.

Posted by 사무엘

2021/03/17 19:35 2021/03/17 19:35
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1866

오늘날처럼 컴퓨터의 문자 인코딩이 유니코드로 천하통일이 되기 전엔 국내에서는 2바이트 완성형과 조합형 한글 코드 논란이 가라앉지 않고 있었다. 완성형은 94*94 격자 모양의 단순하고 국제 규격에 부합하는(?) 방식으로 인코딩돼 있었지만 한글의 구성 원리를 무시하고 한글을 난도질했다는 비판을 떠안고 있었다.

완성형은 “한글 vs 비한글”을 구분하고 처리하는 데 유리했다.
그에 비해 민간에서는 “한글 글자 vs 낱자”의 처리가 더 용이한 조합형이 훨씬 더 대중적으로 쓰였다. 그도 그럴 것이 640KB 기본 메모리를 1KB라도 더 확보하려고 목숨 걸던 시절, 메모리 모델이 어떻고 far 포인터가 어떻고 이러던 시절에.. 한글 처리를 위해서 2350자 테이블을 내장하고 다닌다는 건 성능과 효율로나 민족 정서(?)로나 도저히 용납할 수 없었기 때문이다.

허나, 명목상 국가 표준은 완성형이었기 때문에 마소 역시 도스와 Windows의 한글판을 전적으로 완성형 기반으로 만들었다. 완성형은 두벌식과 마찬가지로 그 시절에 소프트웨의 한글판을 필요 이상으로 더 무겁게 만든다는 비판을 피하기 어려웠다. 다만, 이건 애초에 우리나라에서 표준을 이상하게 만든 게 잘못이지 마소의 잘못은 아닐 것이다.

Windows 3.1이야 이런 배경에서 만들어졌기 때문에 한글 IME로 똠, 펲 같은 글자가 입력되지 않았으며, 또ㅁ, 페ㅍ이라고 글자가 풀어졌다. ‘썅’은 2350자에 속해 있는데 중간의 ‘쌰’는 그렇지 않기 때문에 ‘썅’까지 덩달아 입력할 수 없는 것은 유명한 사실이다.

그리고 처음부터 ‘쌰’를 입력하면 ‘ㅆㅑ’라고 잘 갈라지는데, 두벌식에서 ‘있’ 다음에 ㅑ를 입력하면 ‘이ㅆㅑ’가  되지 않고 뭔가 올바른 동작이 나오지 않았던 걸로 본인은 기억한다.
이런 것들이 한글 입력기, 특히 특정 문자 입력 제한이 걸린 두벌식 입력 방식을 구현할 때 고려해야 하는 복병이다. 날개셋이야 이 분야 전문이기 때문에 그런 것들도 다 정상적으로 처리해 준다.

그럼 차기 버전인 Windows 95는 상황이 어땠을까?
Windows 95는 오늘날 세계 표준 문자 집합 겸 인코딩인 유니코드, 특히 유니코드 중에서도 버전 2.0이 한창 제정되고 있던 와중에 개발되고 먼저 출시되었다. 이건 굉장히 중요한 사건이었다.

우리나라에서는 수 년 전 유니코드 1.x 시절에는 완성형 2350자만 그대로 제출하는 삽질을 저지른 적이 있었다. 그러다가 유니코드 2.0에서 문자 체계를 싹 재정비하는 인류 역사상 마지막 기회가 찾아왔을 때.. 한글을 11172자 모두 순서대로 등록하려는 과감한, 역사적인 계획을 세웠다. 그래야 글자 코드값으로 자모 정보를 쉽게 추출할 수 있기 때문이다.
이건 스타에다 비유하자면 종족 밸런스를 앞으로 다시는 바꾸지 않는 1.08 패치와 비슷한 타이밍이었다.

그런데 그렇게 하려면 세계를 설득해야 했다.
다른 나라들은(특히 일본과 중국도) BMP 영역의 1/5 가까이를.. 그것도 사용자가 1억도 채 안 되는 언어의 고유 문자로 싹 도배하려는 한국을 고깝게 보고 이의를 제기했다.
유니코드 회의에서 누가 발언권을 얻으려면 한화로 억대에 달하는 회원 등록비도 많이 내야 하는데, 이런 비용을 한컴 같은 기업에서 많이 후원해 줬다. 저 때는 삼성전자도 훈민정음 워드 같은 프로그램이나 간간이 만들었지, 지금 정도로 IT계에 세계구급 영향을 행사하는 기업이 아니었다는 걸 생각해 보자!

이런 우여곡절 끝에 한글 11172자는 1996년 7월, 유니코드 위원회의 승인을 받아서 성공적으로 등재되었다. 이거 내막을 아는 사람이라면 이것도 1981년 서울 올림픽 바덴바덴의 기적에 맞먹는 외교 승리라고 여기고 칭송한다. 올림픽은 52:27의 압승이라도 했지만 11172자 등재는 찬성이 반대를 한 표 차이로 정말 간신히 꺾은 거라고 한다.

그런데 문제는 Windows 95는 유니코드 2.0이 정식으로 발표되기 미묘하게 약간 전에 출시되었다는 것이다. 한글판도 1995년 11월 말에 출시됐으니..;;
그럼에도 불구하고 각종 글꼴과 코드 변환 테이블은 이미 유니코드 2.0을 기준으로 맞춰져 있다. 어떻게 이게 가능했을까?

유니코드 2.0에다가 한글을 2350자가 아니라 11172자를 몽땅 집어넣기 위해서는.. 근거가 필요했다. 유니코드가 아닌 기존 2바이트 인코딩 중에도 한글 11172자 표현이 가능한 놈이 있어야 했다.
그럼 Windows가 처음부터 조합형 코드로 개발됐으면 좋았겠지만 모종의 이유로 인해 그리 되지 못했고.. 결국은 기존 완성형에다가 지저분한 독자적인 편법을 동원해서 비완성형 한글을 끼워넣을 수밖에 없었다.

이게 그 이름도 유명한 확장완성형, 일명 CP949 인코딩이다.
KS X 1001은 한글 2350자, 한자 4888자 등을 포함하는 그 2바이트 완성형 문자 집합/코드이고, KS X 1003은 역슬래시를 원화로 대체한 그 한국 특유의 1바이트 영문/숫자 아스키 문자 집합이다. 이 둘을 합쳐서 EUC-KR이라고 부르고, 여기에다가 확장완성형까지 추가하면 CP949가 된다. 집합 관계를 정리하자면 (KS X 1001 ∪ KS X 1003) = EUC-KR ⊂ CP949이다.

(참고: KS X 1002는 완성형 형태로 현대 한글, 옛한글, 한자를 추가로 정의하는 규격이다. 하지만 KS X 1001과 병용하는 인코딩 규칙이 제정되지 않아서 컴퓨터에서 실제로 쓰인 적은 없는 캐잉여이다. 얘는 애초에 유니코드 1.1에다가 글자를 추가로 등록할 근거를 마련하려고 어거지로 만든 문자 집합에 지나지 않는데, 이제는 유니코드 1.1 자체도 오래 전에 흑역사가 됐으니 더욱 의미와 존재감이 없다.)

이렇듯, 확장완성형이라는 건.. 비록 처음에 첫단추를 잘못 끼우긴 했지만 뒤늦게 유니코드 2.0에라도 한글을 11172자를 순서대로 다 집어넣기 위해서 도입한 2바이트용 타협 절충안이었다. 마소에서는 한국 편을 들면서 도와 주면 도와 줬지, 최소한 상황을 더 나쁘게 만든 건 절대 없었다.

그럼에도 불구하고 1990년대 당시에는 마소에서 완성형에다가 그보다 더한 확장완성형까지 집어넣어서 한글을 난도질한다고 엄청난 논란이 일었다. 심지어 한컴에서도 아래아한글 도움말 및 제품 광고에서 이 괴담을 어느 정도 활용하고 부추겼다.

왜 한글을 난도질 하느냐 하면, 확장완성형은 이미 2350가 조밀하게 순서대로 배치된 건 그대로 유지하면서 나머지 틈새에다가 비완성형 8822자를 집어넣는 형태가 되기 때문이다. 그러면 겉보기로는 11172자가 모두 배당되지만 문자의 코드값 순서가 그 문자의 사전상의 배열 순서와 일치하지 않게 된다. 사전 순 정렬을 하려면 코드값을 별도로 보정을 해야 한다.

물론 코드값만으로 문자를 정렬할 수 있는 게 가능하지 않은 것보다는 더 직관적이고 깔끔하고 낫다. 하지만 오늘날 유니코드는 시간 차를 두고 뜬금없이 여기저기 지저분하게 추가된 문자들이 워낙 많기 때문에(특히 한자~!!), 거시적으로 봤을 때 코드값만으로 문자들을 정렬하는 건 어차피 불가능하고 무의미해져 있다.

뭐, 이것도 논란이 다 끝난 오늘날의 관점에서 보니까 별것 아닌 것처럼 보이지, 2바이트 한글 코드만 단독으로 생각하던 시절에 확장완성형이 답답하고 지저분하게 보이는 것도 부인할 수 없어 보인다.
그리고 마소는 훗날 IMF 때 경영난에 빠진 한컴에다가 돈줄을 대 주는 대신 아래아한글의 개발을 중단시키려 했던 바 있다. 그러니 확장완성형에 대한 불필요한 오해 실드를 감안하더라도 마소에 대한 국민 감정이 마냥 좋을 수만은 없었을 것이다.

아무튼, 그 시절 Windows 95는 유니코드 2.0의 정식 도입을 선도하면서 온전한 한글 11172자의 입출력이 가능해지려는 과도기에 연결 고리 역할을 했다.
참고로 95 말고 Windows NT는 도스 짬뽕이던 기존 Windows와 달리, 1993년 첫 버전부터 2바이트 wide char 유니코드 기반이었다. 얘도 유니코드 2.0이 정착할 무렵이 돼서야 본격적으로 정식 한글판이 나올 수 있었다. 3.51부터 말이다.

사용자 삽입 이미지

Windows NT 3.5 한글판의 ‘베타 버전’ 평가판. 이건 Windows NT의 역사상 최초로 만들어진 한글판으로, 정말 엄청난 희귀 레어템이다. 마치 Windows 2.x의 듣보잡 한글판처럼 말이다.

저 화면에서 한글 글꼴은 기존 Windows 3.1의 돋움체(큐닉스 제작) 8포인트이다. 하지만 영문은 정체를 모르겠다. W와 i의 폭이 다른 가변폭인 걸 보니 같은 돋움체의 영문은 아닌데, Arial은 물론이고 심지어 후대에 등장한 Tahoma나 Verdana까지 그 어떤 영문 글꼴도 저 크기에서 9나 5의 획이 저렇게 생기지 않았다.

그런데 저 영문 모양이 내가 보기에 전혀 낯설지는 않다.
마소에서 개발한 1990년대 옛날 프로그램의 스플래시 화면 내지 About 대화상자에서 Copyright 문구가 저런 스타일의 글꼴로 표시된 걸 본 것 같기도 한데.. 정확한 정체는 모르겠다.

내 기억이 맞다면 Windows NT 3.51의 정식 한글판은 3.51의 특성상 Windows 3.1과 같은 구형 UI 기반임에도 불구하고 한글 글꼴은 이미 Windows 95 한글판과 동일한 한양 시스템 글꼴로 갈아탔다.
Windows NT의 역사에서 유니코드 1.1 방식 한글이 존재했던 적은 내가 아는 한 없다. 만에 하나 있다면 그건 조합형 코드를 잠깐 썼었다고 전해지는 MS-DOS의 초창기 한글판만큼이나 완전 전설 속에나 존재하지 싶다.

이렇게 95건 NT건 온전한 11172자짜리 유니코드 2.0 기반임에도 불구하고.. 95의 한글 IME를 써 보면.. 구버전인 Windows 3.1과 마찬가지로 여전히 2350자밖에 입력할 수 없었다. 다만, “있+ㅑ”일 때는 ㅆ이 뒷글자로 넘어가지 않도록 로직이 약간 개선돼 있었다.;; ㅎㅎ

사실, Windows 95의 한글 IME는 확장완성형을 기반으로 11172자를 모두 입력하는 기능도 구현은 돼 있었다. 하지만 그걸 기본적으로는 봉인해 놓았으며, 사용 여부를 별도의 유틸리티를 통해 따로 지정할 수 있었다!
바로, C:\Windows 디렉터리에 있는 iso10646.exe라는 30KB짜리 자그마한 프로그램이다. 역시 괜히 과도기였던 게 아니다.

사용자 삽입 이미지

프로그램 UI에는 유니코드니 완성형이니 같은 말은 없고 그냥 "ISO 10646 사용 여부"가 전부였다. 유니코드의 문자 집합을 가리키는 표준 규격 명칭이 ISO 10646이기 때문이다.
전체 사용 아니면 특정 프로그램에서만 사용.. 이런 걸 지정해 주면 타 프로그램에서 똠쌰 등등의 글자를 입력할 수 있었다.

신기한 것은 Windows용 프로그램뿐만 아니라 도스용 mshbios의 한글 입력기까지 이 설정의 영향을 받았다는 것이다. 설정값을 레지스트리가 아니라 파일에다 저장했던가 보다. 아니면 도스에서도 레지스트리 파일에 저수준으로 접근을 했던지..

확장 한자의 사용 여부를 옵션으로 지정하는 것처럼 2350/11172자 입력 범위도 그냥 IME의 옵션으로 지정하면 됐을 것 같은데 굳이 별도로.. 제대로 문서화되지도 않은 프로그램에다 저렇게 꽁꽁 숨겨 놨다.
부작용을 어지간히도 의식했는지 각종 프로그램별로 입력 범위를 달리 지정할 수 있게 신경을 썼다. 즉, 여느 평범한 IME 옵션이 아니라.. 날개셋으로 치면 응용 프로그램별 동작 보정 옵션과 비슷한 걸로 취급한 것이다.

훗날 MS Office 97이 나왔고.. 그 중 Word는 단품으로 따로 팔기도 했다.
마소 역시 한컴 진영의 조합형 한글 마케팅을 많이 의식했는지, 신문 광고에서 조그맣게.. "우리 마소 제품에서도 똠방각하 펩시콜라 찦차를 입력할 수 있습니다." 문구와 함께, iso10646 프로그램 사용법을 소개해 놓기도 했었다.

본인은 학창 시절에 그 광고를 직접 본 기억이 있다.
지금도 구글에서 iso10646.exe 라고 검색해 보면 옛날 흔적을 찾아볼 수 있다.

마소의 전략은.. 요런 프로그램을 몰래 집어넣은 뒤, 확장완성형이 계속 부정적인 피드백을 받으면 Windows 95는 그딴 거 지원한 적 없다고 발뺌 하면서 2350자 기존 완성형에만 머무르면 될 것이고,
한글을 2350자밖에 입력 못 한다고 욕먹는 게 더 크면, 저 비장의 프로그램을 음지에서 양지로 끄집어내려는 속셈이었던 것 같다. 쉽게 말해 간보기 전략이다.

그러다가 Windows 98부터는 이런 간보기가 없어지고 그냥 모든 프로그램에서 확장완성형까지 활용한 11172자 한글 입력이 되기 시작한 것이다. 나중에 Office 2000과 함께 옛한글 입력기가 도입됐을 때는 이제 마소의 제품이 옛한글의 표현 능력도 아래아한글 97과 한컴 2바이트 코드를 추월하게 됐다.

이상이다. “라떼는 말이야” 같은 얘기가 좀 길어졌다.. ^^
25년 전, Windows 3.1에서 95로 넘어간 것은 정말 엄청난 격변이었다. 하지만 Windows 95와 98 사이에도 컴퓨터 환경은 굉장히 많이 바뀌었다.
가정용 PC의 평균 램 용량이 4~16MB대이던 것이 그 짧은 기간 동안 32~128MB로 순식간에 뻥튀기 됐다. PC 규격도 이것저것 많이 바뀌고.. 또 무엇보다도 이 사이에 유니코드 2.0이 제정되었다. 운영체제 차원에서 UTF-8 인코딩이 직접 지원되기 시작한 최초의 Windows가 바로 98이다.

Windows에서 완성형 2350자에 구애받지 않고 한글 입력이 가능해지기까지 이런 우여곡절이 있었다.
Windows 98은 현대 한글이 완전히 해금됐고, 지난 Windows 8 (2012)부터는 옛한글까지 해금됐으니 참 격세지감이다. 그 사이의 XP는 입력 프로토콜이 IME에서 TSF로 넘어간 과도기였고 말이다.

그런데 정작 옛한글 말뭉치를 엄청나게 많이 구축한 21세기 세종 계획은 이것보다 미묘하게 일찍 진행된 바람에 비표준 한양PUA 방식으로 결과물을 산출해 버렸으니 타이밍이 안습했던 구석이 있다.

Posted by 사무엘

2020/11/09 08:35 2020/11/09 08:35
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1817

본인에게 30여 년 전의 어린 시절부터 친숙했던 비디오 게임 장르는 액션/아케이드 계열이다. 사람 주인공을 화살표 키로 움직이고, 장애물을 직접 뛰어넘고 적을 공격하는 형태 말이다.
그것 말고 다른 장르는 생소했다. 그나마 전략 시뮬은 듄, 워크래프트, 스타 때문에 알게 됐다. 그 전에 삼국지 같은 건 실시간이 아니라 턴 기반 전략 시뮬이었던가 보다.

롤플레잉은 내가 즐겨 하지는 않았지만 주변 친구 중에 좋아하는 사람이 워낙 많았기 때문에 알음알음 접했다. “RPG 쯔꾸르” 같은 툴로 자기가 직접 시나리오를 짜서 게임을 만드는 경우도 있었다. 그런 툴은 정교한 트리거 편집 기능을 갖춘 스타 캠페인 에디터보다도 customize의 자유도가 더 높고, 그렇다고 아예 코딩을 직접 해야 하는 게임 엔진 SDK보다는 폭이 좁은 수준인 것 같다.

그럼.. ‘어드벤처’라는 장르는? 잘 모르겠다. 남이 하는 것도 거의 못 봤다. 그 이름도 유명한 “인디아나 존스”, “원숭이 섬의 비밀”이 이 장르라고 하나.. 본인은 1990년대 컴퓨터 잡지를 통해 이름만 들어 봤지 해당 작품을 당대에 직접 구경해 보지 못했다.
다만, 본인의 기억에 남아 있는 건 1992년 말, 초딩 시절 모 컴퓨터 잡지에서 봤던 “어둠의 씨앗”(Dark Seed)라고 640*350 EGA에서 실행됐던 독특한 게임이다.

요런 게임은 주인공을 화살표 키를 누르는 게 아니라 마우스로 화면에 표시된 목적지를 찍어서 이동시킨다. 실시간 3D 그래픽이란 게 없던 관계로, 화면은 그냥 방 단위로 바뀌며, 모든 그래픽은 그냥 도트 스프라이트이다.
하지만 방 안에서 원근법이 구현돼 있기 때문에 카메라에서 멀어지면 주인공의 겉보기 크기도 작아진다. 게임이 실제로 돌아가는 모습은 먼 훗날 유튜브를 통해서나 구경할 수 있게 됐다.

사용자 삽입 이미지

그랬는데 그로부터 3년쯤 뒤인 1995년에는 ‘시에라 온라인’이라는 게임 개발사에서 Phantasmagoria(판타즈마고리아)라고.. 읽기도 힘들어 보이는 대작 어드벤처 게임을 내놓았다. 장르는 호러..;;

귀신 나오는 haunted house에 주인공이 들어가서 문제를 해결하는 것, 한 화면에서 주인공을 클릭 해서 이동시키는 것 등 전반적인 UI와 느낌은 어둠의 씨앗과 아주 비슷해 보였다.
하지만 얘는 온통 인게임 시네마틱으로 가득하며, 주인공 이동도 전~부 블루스크린 치고 영화 스튜디오에서 실사 촬영한 스프라이트로 구현했다..;; BGM 중에는 합창단 코러스도 있고.. 그야말로 반쯤 영화, 반쯤 게임을 표방한 듯하다.

사용자 삽입 이미지
사용자 삽입 이미지

지금이야 인게임 컷씬쯤은 몽땅 3D 엔진으로 처리했겠지만 저 때는 그게 가능하지 않았다. 그리고 비록 실사 추출 스프라이트라고는 하지만 겨우 256색 저해상도 비디오에서 많은 걸 바랄 수는 없다. 그저 그런 화질에다 배경과 스프라이트가 제대로 융합되지 못하고 붕 뜬다. ㅎㅎ

압축도 빡세게 하기 어려웠는지 저 게임은 7개 챕터(레벨)에 서너 시간 남짓한 플레이 분량임에도 불구하고 CD 7장..;; 분량이었다. 디스켓을 갈아 끼우듯이 CD를 갈아 끼워야 했다.
25년 전의 가정용 PC 환경이 그만치 열악했다. 그리고 실사 영상을 후처리해서 깔끔하게 256색용 스프라이트로 만드는 건 굉장히 노동집약적이며 쉬운 일이 절대 아니다.

기술 얘기가 좀 길어졌다만, 이 게임은 주인공이 나름 미녀이다(단, 유부녀). 나중에는 남편이 악마가 빙의하여 맛이 가 버리고, 주인공을 형틀에 묶어서 죽이려 한다. 우리의 주인공은 양손이 몽땅 결박당하기 전에 기지를 발휘해서 정당방위 차원에서 그 남편을 죽이고 초췌한 모습으로 집을 빠져나가게 된다. 이게 게임의 스토리이다.

사용자 삽입 이미지

얘는 기술적으로 꽤 근성어린 시도를 했지만, 스토리는 꽤 허접 빈약하고 남는 건 잔혹한 호러 컨텐츠밖에 없다면서 논란을 일으켰다. 똘끼어린 문제작 취급을 받긴 했어도 그래도 당시에는 유명세를 타서 물건이 많이 팔리기도 했다고 한다. 수지가 맞았으니 후속작까지 나올 수 있었다.

작중 주인공의 이름은 에이드리언(Adrienne)이다. 같은 발음이 스펠링을 저렇게 쓰면 여자 이름이 되고, Adrian이라고 쓰면 남자 이름이 되는 것 같다(에이드리언 카맥.. 남자). 실제 배우는 Victoria Morsell인데.. 그냥 무명 배우이고 현재까지 이쪽 일을 하지는 않는 것 같다.

Dark seed의 경우, Mike Dawson이라는 주인공 이름과 정체성을 개발자 자신에게서 그대로 따 온 반면, 저 작품은 그리하지 않았다.
Beyond: Two Souls (2013)이라는 게임에서는 유명 배우 엘렌 페이지의 얼굴을 차용한 주인공이 등장하지만, 3D 폴리곤 모델이지 옛날 같은 실사 스프라이트는 아니라는 차이가 있다.

이런 엄청난 게임을 기획한 사람은 시에라 온라인의 공동 창업자인 윌리엄스 ‘부부’ 중.. 남편 말고 부인인 Roberta Williams였다. 이 사람이 정말 여장부였던 것 같다. 평범한 주부이다가 갑자기 게임 기획 쪽으로 각성해서 90년대 어드벤처 장르의 여왕으로 등극했다.
판타즈마고리아 게임의 잔혹한 고어 묘사에 대해서도.. 우리 게임은 동시대의 Doom이나 Mortal Kombat 시리즈에 비해 그렇게 심할 것 없다면서 쿨한 반응을 보였다.

이들 부부는 결혼을 일찍 했고 소싯적에 게임 개발로 성공해서 돈도 많이 번 덕분에.. 2010년대에는 은퇴해서 여기 저기 크루즈 여행을 다니며 풍족한 노후를 보내고 있댄다. 누구처럼 아예 우주로 나간 정도까지는 아니지만, 어디 어설픈 사업이나 투자하다가 먹튀 하고 몰락하는 것보다는 나은 모습인 것 같다.

판타즈마고리아 이야기가 너무 길어졌구나.. 이걸 근성으로 플레이 하고 컷씬들의 대사와 스토리 진행을 리스닝만으로 친절하게 요약해 놓은 블로그 글이 있으니 관심 있는 분은 참고하시기 바란다. 저 게임 자체는 불친절하게도 자막이 나오는 게 없다.

마지막으로 하나 더 소개하고 싶은 게임은 왕년에 페르시아의 왕자로 스타 개발자에 등극했던 조던 메크너가 기획하여 1997년 초에 내놓은 또 다른 문제작 Last Express이다.

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지

얘는 3인칭이 아니라 1인칭 구도이다. 물론 3D 엔진 기반인 건 아니지만 시점이 그렇다는 것이다.
그리고 배경은 1914년 7월, 1차 세계대전이 일어나기 직전의 파리-이스탄불 오리엔트 급행 열차이다. 메크너 아재가 그 시절의 열차 인테리어와 운행 시각표까지 찾아가며 고증을 꼼꼼히 신경 써서 만들었다고 한다.

그리고 더 중요한 특징으로, 얘는 페르시아의 왕자 시절부터 로토스코핑 덕후였던 제작자의 취향이 고스란히 반영되었다.
위에 보다시피 모든 그래픽이 만화영화풍의 그림인데.. 전부 실사 영상을 본따서 디자이너들이 별도의 그림을 그린 것이다. 이 때문에 실사 사진을 보정하는 것 이상으로 많은 시간과 제작비가 소모되었을 것이다. 얘는 CD 3장 분량이었다.

얘는 전무후무하게 참신한 실험 시도로 인해 작품성과 비평 쪽으로 수작.. 혹은 긍정적인 의미로의 문제작 칭호를 받았다. 팔리기도 10만 카피 정도 팔렸다. 하지만 이건 수 년 동안 너무 많이 소모되었던 제작비를 건지기에는 역부족이었기 때문에 상업적으로는 흥행에 실패했다. 다만, 이렇게 된 것에는 제작사가 상황이 안 좋아서 제품의 홍보와 마케팅을 제대로 못 한 잘못도 있었다고 한다.

이상이다.
요약하자면, (1) 3D 없이 재래식 기술만으로 (2) 통상적인 액션/아케이드/롤플레잉 장르가 아니면서 (3) 영화 같은 서사와 스토리텔링을 집어넣은 어드벤처 게임이라는 주제로 몇 가지 대작 작품을 살펴보게 됐다.

그러고 보니 옛날에는 소설인데 1부터 N까지 수십 개의 짤막한 섹션으로 구성되어 있고, 각 섹션의 끝에는 “이 사람의 제안에 어떻게 반응하시겠습니까? ‘예’는 x번으로 가시오. ‘아니요’는 n번으로 가시오” 분기로 가득한 멀티엔딩 형태의 책도 있었던 것 같다. 이건 반쯤 게임, 반쯤 소설인 건지?
작가가 이런 거 만드는 게 굉장히 복잡하고 어려웠을 텐데 나름 참신한 구성이었다.

Posted by 사무엘

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

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

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

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/12   »
      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 31  

Site Stats

Total hits:
1698876
Today:
534
Yesterday:
499