* 과거 내지 현재의 컴퓨터와 관련하여 개인적으로 궁금한 것들 컬렉션이다.

1.
요즘 길거리나 건물 근처에서 쏘는 와이파이를 보면 처음에 접속하는 건 암호가 없는 public 형태이지만, 접속한 뒤에는 무슨 주소를 입력하더라도 로그인/요금 결제 페이지로만 포워딩되는 형태인 것들이 많다. 사실은 학교 와이파이도 보안 ActiveX 등등을 안 깔면 설치 요구 페이지로만 연결된다.

그런데 이 상태에서도 페이스북이나 유튜브에 접속하는 건 바로 되는 경우가 종종 있다. 얘들만 교신을 하는 방법이나 프로토콜이 달라서 그런지(https라든가.. 서버가 외국에 있어서?) 무슨 이유 때문인지는 모르겠다.

사실, 웹서버가 뭔데 내 컴퓨터의 운영체제와 브라우저라면 몰라도(http 헤더에 에이전트 정보가 들어가므로), 보안 솔루션의 설치 여부는 뭘 보고 판단하는지 모르겠다. 프록시인지 뭔지를 써서 warning.or.kr를 우회해서 각종 금지 사이트에 접속하는 것도 어떻게 하는지? 난 웹 쪽은 아는 게 거의 없음. 그 바닥은 너무 골치 아프다.

2.
디카나 폰을 PC에다 연결했을 때 보통은 여느 USB 메모리를 꽂은 것처럼 드라이브 문자가 하나 더 추가되고 해당 기기의 메모리 내부 파일 시스템에 접근이 가능해진다.
그런데 어떤 건 꽂으면 뭔가 파일 시스템이 생기기는 하는데 드라이브 문자가 추가되는 형태가 아니다. 여기는 탐색기로만 접근 가능하지, 어지간한 다른 프로그램에서 파일을 바로 열고 내용을 볼 수 없다. 하드디스크에 복사한 뒤에야 내용을 확인할 수 있다.

그러니 사용자의 입장에서는 불편한데, 오히려 더 나중에 등장한 디카나 폰이 PC와 연결됐을 때 더 이러는 경향이 있다.
이건 기술적으로 무슨 규격이나 프로토콜을 써서 동작하는 건지 모르겠다. 그리고 드라이브 문자가 추가되는 것보다 무슨 장점이 있어서 저렇게 동작하는지도 모르겠다. 혹시 보안?

3.
컴퓨터의 USB 포트에 어떤 기기를 연결하면 인식이 곧장 될 때가 있지만 "인식 실패" 에러가 뜨면서 잘 안 될 때도 있다. 폰이나 USB 메모리 부류 말고 외장 하드 같은 묵직한 물건은 전력이 부족해서 안 될 때도 있다. 이런 건 (1) 컴퓨터, (2) 케이블, (3) 해당 기기 중 어느 게 문제인 걸까..?
컴퓨터라는 건 절대적으로 확실하고 예측 가능한 결과만 나오는 물건일 텐데, USB 포트만은 뭔가 상황에 따라 복불복인 결과가 나오는 면모가 있다.

4.
이제 슬슬 레거시 얘기를 꺼내겠다.
요즘 아직도 빅 엔디언을 쓰는 컴퓨터가 현역으로 돌아가는 게 있는지(코볼 프로그램도 돌아가는 마당에 빅 엔디언이 하루아침에 전멸할 리는 없겠지만.. 엔드 유저가 실감 가능한 영역에 있는가?),
그리고 IA64 아이테니엄 컴퓨터가 아직 살아서 운용 중인 게 있는지 궁금하다.

1990년대 말과 2000년대 초에 인텔이 IA64, 그리고 펜티엄 4의 넷버스트 아키텍처 때문에. 그야말로 세기말과 새천년기에 컴퓨터계의 판도를 바꿀 정도로 큰 삽질을 하긴 했다. 물론 덕분에 경쟁사인 AMD는 큰 이득을 볼 수 있었다.
공교롭게도 이 시기가 무어의 법칙이 슬슬 약발이 다해 가는 시기이기도 했다. (싱글 코어 기반 클럭 속도 향상) 그러니 CPU 제조사의 입장에서는 미래를 내다보고 모험을 감수하고라도 판도를 근본적으로 바꾸는 큰 결정을 내려야 했을 것이다.

다음으로 엔디언 얘기를 하자면, 스마트폰용 최신 CPU는 아예 어느 엔디언으로도 네이티브 구동이 가능한 bi-endian 구조라고 하지만, 굳이 big 모드에서 실행될 일은 별로 없을 것 같다.
오늘날 빅 엔디언의 잔재는 예전에도 언급했듯이 트루타입 글꼴 파일, 그리고 네트워크 표준 스펙 정도에나 남아 있는 듯하다. 유니코드 텍스트도 UTF-16LE 아니면 차라리 UTF-8이지 UTF-16BE가 쓰일 일이 있나 싶다. 난 지금까지 한 번도 못 봤음.

5.
옛날 도스 시절에 상당수 프로그램들의 종료 단축키는 Alt+X였다. 아래아한글, 이야기, 그리고 Q-edit 계열이 이런 관행을 유지해 왔다.
지금 Windows에서는 Alt+F4가 단순히 대화상자 창을 닫는 ESC의 상위 호환이다. 대화상자만 닫는 게 아니라 응용 프로그램의 main window도 닫고 궁극적으로 시스템 종료까지도 가능하다. 하지만 도스 시절에 Alt+F4로 종료하는 프로그램은 본인은 정말로 MS DOS Shell밖에 못 봤다.

게임들은 대부분 ESC만 눌러도 원큐에 종료 가능했지만 페르시아의 왕자는 혼자 Ctrl+Q라는 독특한 단축글쇠로 종료했다(2편에서는 Alt+Q도 추가). 페르시아의 왕자 원판이 처음에 애플 기종용으로 개발되었고, 그쪽은 Cmd+Q가 종료이니 그거 영향을 받은 게 아닌가 싶다. 맥의 Cmd+Q는 창을 닫는 기능이 없이 그냥 원큐에 프로그램을 종료하는 용도로만 쓰인다. 그리고 내 기억이 맞다면 포토샵처럼 맥에서 이식된 프로그램은 Windows에서도 Ctrl+Q 종료 단축글쇠를 갖고 있었다.

그 외에 마소에서 만든 옛날 도스용 프로그램 중에는 웬 F3이 종료인 물건도 드물게 있었다. 주로 Windows 3.1 내지 9x 계열의 설치/setup 프로그램이 그랬던 것 같다. 이 관행은 오래 이어지지 못했다.

6.
옛날 자동차만큼이나 개인용 컴퓨터계에서도.. IBM 호환 PC라는 게 세상을 평정하기 전에 있었던 특히 1980년대의 8비트 구닥다리 컴퓨터들에 대해서 요즘 갑자기 좀 관심이 생겼다. 기계들 계보를 분류해 보고 싶다. 어떤 건 기계 자체의 명칭이지만 어떤 건 규격의 명칭이기도 하다. 이 당시 CPU의 제조사도 여럿 있었을 텐데.. 시간 나는 대로 인터넷 찾아 가며 차근차근 공부할 생각이다.

먼저 애플 II~III부터가 8비트였고 국산 컴퓨터로는 삼성 SPC-1000, 금성 패미콤이 있다. MSX는 특정 기종 이름이 아니라 규격명일 테고. Commodore 64에서 64는 메모리가 64KB라는 뜻이다 CPU는 64비트가 전혀 아니며 8비트임.
요런 컴퓨터들은 그냥 켜면 롬에 내장돼 있던 베이직 인터프리터가 떴고, 카트리지를 꽂으면 게임을 할 수 있었다. 테이프는 개인적으로 구경 못 해 봤다.

삼성의 경우 살인적인 공밀레에 공밀레를 거듭한 끝에 1983년 말에 최초의 국산 메모리 반도체인 64K D램을 개발하는 데 성공했다.
팀원: "저 다음 주에 결혼할 예정이어서 휴가 좀.." / 팀장: "야 왜 하필 이렇게 바쁜 와중에 결혼을 (쳐)하는 거야! 버럭"
거의 이런 분위기에서 개발한 것이었다. -_-;; 과장이나 주작이 아님. 저렇게 팀원을 실제로 갈궜던 당시 팀장이 신화창조던가 다큐에서 출연해서 증언을 했으며, 지금 생각하니 그 팀원에게 너무 미안하다고 회고했다.

더 부가가치가 높은 비메모리 반도체를 선점하지 못한 건 아쉬운 점이지만 일단은 그 열악한 환경에서 메모리 반도체 하나라도 저렇게 잡은 걸 다행으로 여겨야 할 듯하다. 그런데 삼성 전자에서 같은 1983년에 컴퓨터까지 만들었다는 게 대단하게 느껴진다. 그 옛날부터 이미 미래에 나라를 먹여 살릴 산업을 예견하고 리스크를 감수한 투자를 아낌없이 한 것이다.

나도 "IBM 호환 PC"에 속하는 컴퓨터를 접하기 전에 아주 잠깐 소위 8비트 컴퓨터라는 걸 집에서 접한 적이 있었다. 그건 정확하게 무슨 기종에 속한 물건이었을지 궁금하다.
프롬프트가 Ok 대신 READY라고 나오고, 입력한 문장에 문법 에러가 있으면 비프음과 함께 SYNTAX ERROR이라고 나왔는데.. 롬 베이직 인터프리터가 뜬 모습은 지금 생각해 보면 커모도어 64의 그것과 제일 비슷해 보인다. 하지만 실제로 그게 맞는지는 알 길이 없다.

사용자 삽입 이미지

넥슨 컴퓨터 박물관에서 이런 물건을 발견했다. 모니터는 내가 옛날에 집에서 써 봤던 그 기계와 정확하게 일치한다. 확실하다. 검은 테두리에다 오른쪽에 저렇게 작은 다이얼이 3개 있었고..  하긴, 옛날 아날로그 모니터들은 밝기 같은 걸 조절하는 게 저렇게 물리적인 다이얼 형태로 존재했었다. 검색을 해 보니 "금성 패미콤".. 아하, 메이커가 금성사였구나.

아무튼, 이런 원시적인 물건을 통해서 나는 프로그래밍이라는 행위의 짜릿함을 경험했고 무한한 신기함과 흥미를 느꼈다. 그래서 지금의 내가 있게 됐다. 어렸을 때 접한 컴퓨터가 처음부터 지금의 컴퓨터처럼 성능이 너무 좋고 시스템이 복잡하고 사용자가 개입할 여지가 없다시피한 형태였다면, 난 컴퓨터 말고 다른 진로를 갔을 가능성이 높다.

Posted by 사무엘

2017/03/22 08:34 2017/03/22 08:34
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1340

1. 색소폰 연주

아시다시피 본인은 Looking for you를 3천 번 들었다.
성경의 사무엘이 '사무엘아' 음성을 두 번 듣고 나서 세 번째 들은 뒤엔 출처를 공부한 뒤 들을 준비를 하고 잠자리에 누웠다. 네 번째 '사무엘아' 음성을 들은 뒤에야 하나님의 음성에 제대로 응답하게 됐다.

그것처럼 나도 새마을호에서 Looking for you를 두 번 듣고 나서 세 번째 들은 뒤엔 출처를 인터넷으로 검색했고, 다음엔 들을 준비를 하고 새마을호를 탔다. 네 번째 Looking for you가 흘러나왔을 때 나는 철도 안에서 거듭났고 철도를 내 개인의 교통수단으로 영접하는 놀라운 일이 벌어졌다.

그 뒤로 나는 Looking for you를 주선율, 주요 화음, 대략의 비트까지 다 청음 채보했다.
콩나물 대가리를 한땀 한땀 입력해 넣고 원곡과 대조하면서, 어느 기보가 원음에 더 근접한 정확한 기보인지를 고민하면서..
Looking for you 작곡자의 마음과 심정을 이해하는 자가훈련을 했다.

이 음악의 어느 부분이 나를 감화시켜서 나를 철덕으로 만들었는지, 왜 이런 결과가 야기될 수밖에 없는지를 연구했다.
그리고.. Looking for you의 주선율을 만든 악기 공부를 (잠깐 동안이지만) 시작했다.

사용자 삽입 이미지

작년 성탄절, 우리 교회 복음 전도 집회에서.
아, 교회에서 Looking for you 연주했다는 얘기는 아님. 오해 마시길..

2. 나의 등산 노트

사용자 삽입 이미지

조건부 서식이 있으니 올랐던 산들의 높이를 일목요연하게 파악할 수 있어서 매우 좋다.
이것도 중복 정보 없이 정규화가 잘된 구조로 구축하려면 산에 대한 테이블과 등산 세션과 관련된 테이블을 분리하긴 해야 하는데, 엑셀로 그것까지 하기에는 많이 귀찮지.

입산 지점에 최종적으로 어떤 교통수단을 이용해서 가서 어디로 하산했는지,
산 속에서 주로 본 게 무엇인지, 바깥 경치로 주로 무엇을 봤는지,
정상에는 무엇이 있었고 어떤 형태였는지, 산이 행정적으로 어떤 관리를 받고 있는지 같은 것을 일목요연하게 조회 가능하게 했다.

3. 코딩

그럼 이제 일상생활 얘기로 넘어가겠다.

사용자 삽입 이미지

(밝은 화면을 비추느라 명암차 때문에 주변이 어두워진 거지, 촬영 당시에 책상 주변은 실제로는 저 사진만치 어둡지 않았음)
화면이 미치도록 광활한 데스크톱 컴과,
눕든지 앉든지 편한 자세로 침대, 책상, 자동차 등 아무 데서나 사용 가능한 놋붉 컴 중
뭘로 코딩을 할지가 매우 고민된다. 일종의 행복한 고민.

참고로 노트북의 화면 전체와, 데스크톱 모니터의 오른쪽에 떠 있는 작은 프로그램 창하고 화면 크기(화소 수)가 동일하다. ㄲㄲㄲㄲㄲㄲㄲㄲ 미래의 리드미 문서를 작성하고 있는 날개셋 편집기의 화면임.
내가 지금까지 갖고 있던 그림과 동영상들이 화질이 얼마나 구린지를 까발리고 정죄하는 마법의 모니터다.

역시 프로그래머에게 화면이 큰 건 컴퓨터에게 램이 많은 것과 같다~! 정말 다다익선이다.
그도 그럴 것이 자꾸 창 전환이나 스크롤 하는 게(개발툴, 웹브라우저, 에디터, msdn 등등) 컴터로 치면 메모리 부족해서 하드디스크 스와핑 하는 것과 개념적으로 완전히 동일하기 때문이다.

무식하게 혼자 3~5K급으로 해상도가 너무 높은 모니터 하나냐, 혹은 걍 2K 해상도급 모니터 듀얼/트리플 중 어느 게 더 좋을지는 잘 모르겠다. 제각기 장단점이 있어 보인다.
참고로 배(선박)와 DLL(Windows 파일..;; )은 작은 놈 여럿보다는 큰 놈 하나가 성능면에서 더 효율적이다.

일체형 PC는 간지나고 공간 덜 차지하고 지저분한 선 없이 콘센트 하나만 꽂으면 모니터 본체 스피커가 전부 OK이니 정말 좋긴 하다.
다만, 이렇게 한번 세팅된 이후로 부품 업그레이드가 어려울 것이고 발열 제어도 곤란하니 엔드급 게임은 무리일 것이다.

구조적으로 볼 때 철도 차량의 동력분산 / 동력집중의 차이와 비슷해 보인다. 일체형 PC가 동력집중이 아니라 분산식에 대응한다. 그리고 트렁크· 캐빈· 엔진룸 따위의 구분이 없는 원박스 형태의 자동차도 일체형 PC와 비슷한 컨셉이라 볼 수 있겠다. (공간 활용 최대, 그러나 정비가 어렵다는 점에서 비슷)

4. 시간 부족과 일정 압박

CPU 클럭 속도 향상의 병목은 발열이고, 자동차 속도 향상의 병목은 공기 저항이다. 스마트폰 성능 향상의 병목은 배터리 용량이다.
그리고 날개셋 한글 입력기 개발에서 최악의 병목은 잠으로 인한 시간 부족 되시겠다.
난 오랜 경험상 매일 6시간이 정말 마지노선이고 그 이하로는 도저히 못 줄이겠다. 결국은 낮에 졸음과 집중력 저하로 인해 밤에 안 잔 것 이상의 대가를 치르게 되더라. -_-;;

어지간한 고시 준비생만치 시간을 분초 단위로 쪼개며 살아도 시원찮을 판에 이래 가지고 날개셋 9.0은 언제 완성할 것이며 박사 졸업은 도대체 언제 하나..;;
늦게 자고 늦게 일어나는 것보다는 일찍 자고 일찍 일어나는 것 선호함. 눈 감았다 뜨면 그냥 6시간이 싹 워프되고 개운 가뿐하게 일어나긴 한다. 천성적으로 남 눈치 안 보고 앞날 걱정을 미리 안 하는 체질이어서 그런지 스트레스는 적게 받는 편. 불면증 같은 게 어떻게 존재하는지 이해를 못 한다.

단지 잠을 더 줄일 수가 없을 뿐임.
이것도 기초체력 문제인가..? 잠 적으신 분이 굉장히 부럽다.

5. 덕질

논문 쓸 '꺼리, 아이템'들을 만들어내는 활동은 재미있지만 (코딩, 시스템 구현, 실험 등등)
그걸로 온갖 형식 갖춰서 실제로 논문을 쓰는 건 꽤 성가시고 번거롭다. =_=;;
그래도.. 잔인한 주인이 무자비하게 내린 온갖 복잡한 재귀호출 뺑뺑이와 자질구레한 메모리 할당· 해제 요청들을 컴퓨터는 진짜 순식간에 전광석화처럼 해낸다.

소프트웨어의 추상화 계층이 올라가면 코드를 유지보수하고 확장하기는 편해지지만 컴퓨터의 입장에서는 뭘 하나 하려 해도 포인터가 가리키는 대로 메모리를 여러 단계 요리조리 따라가야 하고, 캐시 미스가 나면 더 느린 메모리에 갔다가 와야 된다.

사용자가 '확인'을 누르거나 키보드를 하나 눌러서 화면에 글자 한 자가 찍힐 때까지 컴퓨터가 전자적으로 처리하는 일의 양이 도대체 얼마나 될까.
하물며 실존하지 않는 종이, 실존하지 않는 음악과 영상이 존재하는 것 같은 경험을 사람에게 제공하기 위해서 컴퓨터는 얼마나 많은 계산을 순식간에 해치우고 있을까?
프로그래머로서 이런 컴퓨터가 고맙고 대단하게 느껴질 때가 있다.

글자를 온통 배배 틀고 배경과 뒤섞어 놓은 일명 '캡챠'는 사람은 곧바로 알아보지만 컴퓨터가 알아보지 못하는 (걸 지향하는) 그림이다.
그러나 사람이 도무지 판독할 수 없는 랜덤 노이즈로 보이는 QR 코드 같은 건 컴퓨터가 곧바로 판독해 낸다.
예전에도 말했듯이 주석과 들여쓰기가 잘 된 코드와, IOCCC용 난독화 코드는 컴퓨터가 해석하는 데 아무런 차이가 없다.
이런 걸 생각해 봐도 사람과 기계는 근본적으로 특성이 달라도 이렇게 다르다는 걸 느낄 수 있다.

6. 컴퓨터 세팅

개인용 컴퓨터를 새로 지르거나 회사 같은 데서 내 업무용 컴터를 받았을 때 내가 기종을 불문하고 제일 먼저 하는 일은

  • 키보드 속도를 최고속으로 맞춘다. 보통 디폴트 값은 반복 속도가 늘 최고속에서 한 단계 낮은 걸로 돼 있는데.. 난 이게 최고속으로 돼 있지 않으면 답답하고 불편해서 못 쓴다. 키를 이 정도 시간 동안 눌렀으면 cursor나 선택 막대가 어느 정도로 이동해 있을 거라는 예상치와 기대치가 있기 때문이다. 지금 같은 '재입력/반복 키보드 속도 조절 체계'는 IBM PC AT 시절 이래로 변함없이 이어져 온 유구한 전통이다.
  • <날개셋> 한글 입력기를 설치한다. 내 홈페이지에 대외적으로 공개돼 있는 최신 버전이 아니라, 나 혼자만 갖고 있는 "개발 중"인 진짜 최신 버전이다. 한글을 내가 원하는 형태로 입력 가능하고 그 구닥다리 16*16 비트맵 폰트를 화면으로 좀 봐야 내가 심리적으로 안정된다.
  • Looking for you.mp3 복사해 넣는다. 음악 파일 중에서 묻지도 따지지도 않고 내가 무조건 제일 먼저 집어넣는 파일, 특히 사운드 테스트용으로 쓰는 파일은 답정너 looking for you이다. 이게 흘러나와야 내 개인용 컴퓨터라는 생각이 든다.

그나저나 노트북 내지 미니키보드들의 왼쪽 아래를 보면 Ctrl의 오른쪽에 Alt가 있는 것은 보장되지만 이것 말고 Fn, Win, 한자 키 같은 것은 생각보다 배치가 제멋대로이고 파편화가 심하다. 규격이 통일돼 있지 않다. 이것 때문에 한 키보드에 적응되고 나면 다른 키보드에서 modifier 키를 잘못 누르기 쉬워서 몹시 불편하다.

말이 나왔으니 하나 더.. 요즘 Windows 10은 사용자에게 선택의 여지를 안 주고 시도 때도 없이 강제 업데이트를 해서 꺼져야 할 때 바로 안 꺼지고, 켜져야 할 때 바로 안 켜지는 게 굉장히 싫다. 대규모 업데이트가 너무 잦고, 심지어 업데이트 후에 컴퓨터가 맛이 가는 것도 몇 번 겪어서 하기가 더욱 싫어진다. 그리고 컴퓨터를 오래 쓰고 나면 언제부턴가 시작 메뉴에서 앱들 검색이 제대로 동작하지 않기 시작한다. 나만 이러는 거 아니지?

그래서 인터넷을 뒤져서 이더넷 유선 랜도 데이터 요금이 부과되는 네트워크라고 속이는 레지스트리 패치를 적용시켰다. 그래야 운영체제가 제멋대로 깽판을 안 부린다. 제아무리 보안 업데이트도 인터넷 패킷 종량제 앞에서는 깨갱 할 수밖에 없으니까.

7. 삼각형의 오심을 그리는 프로그램

작년이니 엄청 옛날에 이미 작업된 사항이긴 한데, 막 중요한 건 아니어서 이제야 여기서 공지를 하게 됐다. 홈페이지의 '옛날 자료실'에 올라와 있는 '삼각형 오심을 그리는 프로그램'이 거의 10여 년 만에 기능이 크게 추가되고 보강됐다. 수학 강사인 교회 지인의 제안으로 행해진 작업이다.

삼각형의 오심이야 간단한 기하 알고리즘으로 (1) 두 직선의 교점과 (2) 두 변이 이루는 각을 이등분하는 변만 구할 줄 알면 컴퓨터로 아주 쉽게 구할 수 있다. 삼각형은 2차원 평면도형 중 가장 간단한 물건인데 얘의 모양에다 중심이라는 의미를 부여하는 방법도 이렇게 다양하다는 걸 알게 된다.

구체적인 개선 사항은 해당 웹페이지에도 나와 있지만, '구점원'이라는 걸 그리는 걸 추가했다. 삼각형 세 변들에 대해 변의 중점으로만 이뤄진 작은 삼각형의 외심원을 구한 것인데, 이게 또 방점과 접하고 수심을 지나기도 하는 등 기하학적인 의미가 장난이 아니다. 이걸 제6심이라고도 볼 수 있을지는 모르겠다.

그리고 내심을 제외한 수심, 구점원 중심, 무게중심, 외심 이렇게 네 점은 언제나 한 직선상에 있다는 게 보장된다..;; 이 오일러 직선을 그리는 기능도 추가했다.
또한 삼각형의 꼭지점만 마우스로 끌어서 이동시키는 게 아니라 삼각형 내부를 끌면 삼각형이 통째로 움직이게 했다. 한 점이 삼각형의 내부에 있는지 판별하는 건 세 점의 방향성 판별 공식을 이용해서 구현 가능하다.

웹브라우저에서 윤곽선 폰트 에디터까지 구동하는 세상인데 이런 간단한 그림을 그리는 프로그램쯤은 이제 플래시조차 필요 없고 HTML+(JS)로 다 만들 수 있을 것이다. 엔드 유저의 관점에서는 EXE 형태의 프로그램이 점점 필요 없어지고 있긴 한데, 일단 내가 아는 skill은 C++과 Windows API이니 저렇게 간다. GDI 말고 다른 API를 동원해서 선들을 안티앨리어싱도 좀 시킬 걸 하는 아쉬움도 남는다. 완벽하게 만들려고 욕심 부리면 뭐 한도 끝도 없다.

Posted by 사무엘

2017/02/26 19:33 2017/02/26 19:33
, , , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1332

오옷, 지금까지 내 블로그에서 데이터베이스에 대한 얘기가 거의 없었던 것 같다.
오늘날 정보화· 컴퓨터 세상의 근간을 담당하는 핵심 소프트웨어 기술을 꼽자면 (1) 운영체제(!!), (2) 컴파일러(컴퓨터에서 돌아가는 모든 프로그램들을 생성..), (3) 손실/무손실 압축 알고리즘, 그리고 (4) DB엔진이지 싶다. 딱히 무순으로 나열한 것임.

요즘은 전국민의 신분 근황, 학생들의 모든 학적 정보, 카드 거래 내역, 병원 진료 내역 등등등~ 모든 기록과 행적이 전산화됐다.
그리고 저기서 전산화라는 건 곧 DB화를 의미한다. DB 엔진 없이는 이 복잡한 세상이 돌아갈 수 없는 지경이 된 지 오래다. 또한 key-value 개념부터 시작해 삼라만상의 정보들을 다 표와 표를 융합해서 구축한다는 '관계형'이라는 모델, 그리고 정규화 계층 같은 DB 이론도 깊이 들어가면 생각보다 굉장히 심오하고 복잡하다.

똑같이 총이라 해도 권총부터 시작해 소총, 중기관총, 대포까지 다양한 크기가 있듯이 DB 엔진이라는 것도 스케일이 생각보다 매우 다양하다.
네트워크를 통해 들어오는 수백~수만~수백만 건의 동시 접속 트랜잭션을 소화하면서 방대한 양의 데이터를 극도의 안정성(그 대신 성능 오버헤드도..)을 보장하면서 처리하는 대형 DB 엔진이 있다.
이런 건 일반 사용자가 개인용 PC에서 돌릴 일은 없는 물건이다. 오라클 내지 MS SQL Server 같은 프로그램의 제일 고급 에디션이 이 범주에 해당할 것이며 이런 건 가격도 왕창 비싸다.

MySQL은 저 정도로 방대한 스케일은 아니지만 원격· 다중 접속을 지원하고 로컬 내지 중소규모 웹 서버에서 굴리는 용도로 가성비가 아주 좋다. 게시판이나 블로그 엔진들이 컨텐츠를 얘를 기반으로 구축하곤 한다.

MS Office에 포함돼 있는 Access 정도로 가면 다중 접속은 이제 없고, 서버가 아닌 클라이언트 지향 DB가 된다. 개인용 컴퓨터에서 엑셀로 처리하기엔 좀 방대한 양의 데이터를 엑셀보다 더 프로그래밍 지향적으로 전문적으로 처리하는 도구로 격이 더 낮아진다. 예전에 Visual C++ 책을 봐도 DB 관련 API는 꼭 한 챕터가 할당돼 있었으며, ODBC는 큰 DB, DAO는 좀 작은 DB라고 봤었다.

개인적으로는 성경을 DB로 구축하니 좋았다. 성경은 신구약 전체가 31000구절쯤 되고 역본을 10여 개 갖고 있으면 구절 수가 몇십만 개에 달한다. 그리고 내가 원하는 구절만 쿼리를 날려서 찾는 건 아무래도 스프레드 시트보다는 응당 DB가 제격이다.

또한, 먼 옛날에 컴퓨터 학원에서 dBase III+를 배우던 추억이 떠오른다. 얘도 그 당시로서는 Access에 준하는 체급의 개인용 DBMS라 볼 수 있겠다. SQL이 아닌 독자적인 문법 기반이었고, 명령 프롬프트 모드도 있고 메뉴를 띄워서 DB 파일을 관리하는 assist 모드도 있어서 UI가 독특했다. 또한 dBase가 생성하던 DBF 파일은 도스 시절에 아래아한글도 전화번호부에서 사용하고 DB Viewer를 제공할 정도로 옛날에 꽤 대중적인 파일 포맷이었다.

여느 워드 프로세서나 스프레드 시트와는 달리, DB 프로그램에서는 각 데이터에 속하는 속성들을 자료형과 크기까지 꽤 까다롭게 미리 지정해 놓고 데이터를 넣어야 한다. 프로그램 코딩을 할 때 말고 '자료형'이라는 개념을 따지고 생각해야 하는 분야는 아마 DB밖에 없지 싶다.

사실은 프로그래밍 언어 중에도 자료형이 엄격하지 않고 귀걸이 코걸이 식으로 변할 수 있는 언어가 있다. 그리고 DB 자료형은 엔진에 따라 다르긴 하지만 프로그래밍 언어의 그것과는 달리 딱히 기계 친화적으로 지정하지 않아도 되는 경우가 있다. 숫자형의 표현 범위를 2진법이 아닌 10진법 기준 자릿수로 지정하는 것처럼 말이다.
전화번호는 절대로 숫자형으로 지정하지 말고 문자열형으로 지정해서 넣어야 한다고 학원 선생님에게서 들은 기억이 남아 있다.

"명령줄 기반 + UI + 반쯤 절차형 프로그래밍 환경"이라는 점에서는 이런 DB 프로그램은 매쓰매티카 같은 수학 패키지와도 구조가 비슷한 구석이 있는 것 같다. 아무나 함부로 접근하기는 어렵다는 공통점도 있고 말이다.

그에 비해 엑셀은 어떤가? 대용량 데이터를 취급하는 성능은 DBMS보다 뒤쳐지고, 수식 계산은 수학 패키지에, 비주얼과 레이아웃 기능은 워드 프로세서에 밀린다. 엑셀은 심벌 연산이나 임의 자릿수 계산 기능이 없으며(수학 패키지), 성능을 위해 위지윅(워드 프로세서)도 포기했다.

그럼에도 불구하고 엑셀은 이들 이념을 어중간하게 절충해서 얻은 접근성과 성능, 가성비 덕분에 일반 사용자에게 최고의 업무 처리 앱이 되었다고 볼 수 있다. 일종의 포지셔닝을 잘해서 승리자가 됐다. 한 값이 바뀌었을 때 관련된 셀의 값들이 연달아 쫙 바뀌는 동적인 문서를 손쉽게 만들 수 있는 게 최고의 강점인 듯하다. 또한 피벗테이블/차트는 SQL 같은 거 하나도 몰라도 SELECT 쿼리에서 특히 GROUP BY를 적절하게 구현해 줬다고 볼 수 있다.

DBMS는 굳이 사람만 쓰는 건 아니고 다른 컴퓨터 프로그램이 로컬에서 내부적으로 사용하기도 한다. 에.. 그러니까, 사람이 관리하는 데이터 말고 프로그램이 자기 혼자만 취급하는 데이터를 관리할 목적으로 말이다. 이런 데에 미들웨어 컴포넌트처럼 쓰이는 DB 엔진은 덩치가 더욱 작고 백업· 응급 복구 같은 안전 기능이 없는 대신, 크기· 성능 오버헤드가 더욱 작고 빠르다.

예전에 파일 포맷에 대해서 글을 쓴 적이 있었다. 내 프로그램이 테이블 형태이고 수정이 빈번한 몇백만 개의 대용량 데이터를 다루는데, 파일 포맷을 새로 만들기는 심히 귀찮고 그렇다고 단순 선형적인 바이너리/텍스트 컨테이너 포맷을 쓰기에는 성능이 우려된다면, 범용성으로 인한 약간의 오버헤드를 감수하고라도 저런 내장형 소형 DB를 얹는 게 좋은 선택이 될 수 있다.

괜히 파일 내부에서 골치 아픈 청크가 어떻고 헤더가 어떻고 데이터를 바이너리 비트 수준에서 신경 쓸 필요 없이, 그냥 테이블 스키마.. 이건 프로그래밍 언어로 치면 C/C++ 쓰던 게 아주 고수준 언어로 바뀐 것과도 같다. DB 구조 자체가 일종의 파일 시스템에 대응하니까.

특히 데이터 전체를 무식하게 메모리에 다 올려서 작업하는 형태가 아니라면 DB의 가성비가 더욱 올라간다. 요즘 시대에 다 차려져 있는 밥상인 검증된 오픈소스 솔루션을 놔두고 개발자가 B+ 트리 같은 거 일일이 구현하면서 삽입 삭제 수정 케이스를 일일이 테스트 할 이유가 없기 때문이다.

이런 컴퓨터지향적인 DB는 DB가 하는 본연의 작업에다가 비교/정렬/데이터 변형 알고리즘 같은 일부 핵심 작업만 내가 custom으로 작성한 함수로 대체할 수 있어서 대단히 강력하고 편리하다. 당연히 C/C++로 작성하여 네이티브 코드로 빌드한 함수로 말이다. 파이썬이나 Lua처럼 C/C++ glue에 뛰어난 고급 언어가 있듯, glue에 최적화된 DBMS도 응당 있다.

Visual Studio의 경우 인텔리센스 엔진이 ncb 자체구현 DB를 쓰던 것이 2010부터는 자사의 SQL Server "Compact Edition" DB 기반으로 바뀐 것으로 유명하다. 그런 건 DB를 사용하기 꽤 적절한 용례로 보인다. C++ 문법이란 건 앞으로 또 뭐가 생기고 어떻게 변할지 모르는데 그런 것에 대응하는 것도 파일보다는 DB 지향이 더 유리하겠다.

MS 것 말고도 이 바닥의 유명한 오픈소스 소형 DBMS로는 SQLite가 있다. 리처드 힙이라는 아저씨가 만들었는데, 그냥 오픈소스로도 모자라 골치아픈 LGPL, MIT 라이선스 그딴 것조차 거부하고 소스를 걍 public domain으로 뿌렸다..;;; 그러면서 "님이 받은 만큼 님도 남에게 베풀어 주세요"를 저작권 notice랍시고 적은 게 전부이고.. 천재에다 신자이고 굉장한 대인배이신 듯하다.

The author disclaims copyright to this source code. In place of a legal notice, here is a blessing:
- May you do good and not evil.
- May you find forgiveness for yourself and forgive others.
- May you share freely, never taking more than you give.


모질라 재단의 이메일 클라이언트 유틸인 ThunderBird는 워낙 대용량 편지함을 관리하다 보니 내부 파일이 SQLite DB인 듯하며, 안드로이드 OS에서도 얘를 적극 활용 중이라고 한다. 그러고 보니 소형 DB들은 MS것과 오픈소스 모두 제품명에 compact, lite라는 '꼬마'를 나타내는 단어는 꼭 들어가 있다.

본인도 회사에서 SQLite를 좀 다룰 일이 있었다.
SQLite는 코드가 다양한 플랫폼에서 다양한 문자 인코딩(UTF-8, UTF-16 빅/리틀/디폴트)에 대비하여 API가 굉장히 세심하게 설계된 게 인상적이었다. 하긴, 인코딩에 따라 한글 같은 건 글자 수가 달라져 버리니 정보량에 매우 민감한 DB에서 그걸 민감하게 다루지 않을 수가 없다. 간단하게 단일 문자열로 통합· 추상화가 가능하지 않다는 얘기다.

콜백 함수는 자신이 받고 싶은 문자열의 형태를 지정해 줄 수 있으며, 콜백 함수 자체의 인자는 char도, wchar_t도 아닌 const void*로 돼 있다.
그리고 DB 내부에서 사용하는 문자열뿐만 아니라 열고 싶은 DB 파일을 지정하는 것도 16비트 문자열형 버전이 따로 있는데, 이건 Windows처럼 16비트 문자열을 네이티브로 쓰는 OS에서 CreateFileW 같은 W API를 쓰면서 제 성능을 낼 수 있게 한 배려로 보인다.

다음은 DB와 관련된 여러 문자열 처리 관련 잡설들이다.

1. 정렬

프로그래밍 언어들이 제공하는 문자열 비교는 정말 단순무식하게 숫자 비교의 연장선으로서 각 문자들의 코드값 비교 그 이상도 이하도 아니다. 허나 실생활에서는 오름차순/내림차순부터 시작해 대소문자 구분, 언어 정보를 고려한 비교 같은 복잡다양한 옵션이 필요하다.

대중적이고 자주 쓰이는 옵션은 SQL에서도 언어 차원에서 (1) 옵션을 제공한다. 하지만 좀 더 복잡한 정렬을 위해서는 값을 그대로 비교하는 게 아니라 (2) 사용자가 변조한 값을 비교한다거나 (3) 아예 비교 함수 자체를 customize할 수 있어야 한다.
물론 (3)만 있어도 (1)과 (2)는 다 처리가 가능하니 C 언어의 qsort 함수는 비교 함수만 인자로 받는다. 그러나 파이썬의 정렬 함수는 (1)~(3)까지 다양한 방식으로 운용 가능하다. SQL은 collation이라는 개념으로 정렬 알고리즘 자체를 customize할 수 있다.

2. 토큰화

구분자를 사이에 두고 여러 문자열들이 뭉쳐 있는 문자열을 토큰화해서 문자열(단어)들의 리스트로 뽑아내는 건 탈출문자 인코드/디코드만큼이나 이 바닥에서 굉장히 흔하게 행해지는 작업인 것 같다. 파이썬의 경우 split이라는 메소드가 있다.

그런데 토큰화라는 게 두 부류가 있다. 하나는 구분자가 whitespace 부류이기 때문에 "A    B"나 "A B"나 똑같이 A와 B로 분간되는 것이다. A와 B 자체는 빈 문자열이 될 수 없다.
다른 하나는 구분자가 콤마나 세미콜론 같은 부류이며, 한 구분자가 정확하게 한 아이템만을 분간한다. A,,,B라고 쓰면 A와 B 사이에 빈 문자열이 두 개 더 걸려 나온다..

C가 제공하는 오리지널 strtok는 컨텍스트를 받는 인자가 없어서 (1) 토큰 안에서 또 토큰 구분을 할 수 없으며 멀티스레드 환경에서 사용하기에도 위험하다. 그뿐만이 아니라 얘는 (2) whitespace형 토큰화만 지원하기 때문에 콤마형 토큰화에는 사용할 수 없다는 것도 단점이다. 그래도 뭔가 문자열을 또 복사하고 생성하는 게 없고 성능 하나는 나쁘지 않기 때문에 컨텍스트 인자만 추가해 주면 여전히 유용한 구석은 있다.

DB를 텍스트 형태로 덤프 백업하면 그냥 csv 형태로만 뱉는 게 아니라, 그대로 SQL을 실행만 하면 DB의 재구성이 가능하게 INSERT INTO xxx VALUES가 붙은 형태로 백업되는 것도 많다. DB 스키마는 그냥 CREATE TABLE ... 형태가 될 것이고.
코드와 데이터의 경계가 모호하다. DB 백업도 뭔가 JSON 같은 포맷과 연계 가능하지 않을까 하는 생각이 잠시 들었다.

3. 검색어의 전처리

SQL로 문자열을 검색하고 싶으면 그 이름도 유명한 LIKE 연산자를 쓰면 된다. 어지간한 프로그래밍 언어라면 함수 형태로 구현되었을 기능이 SQL에서는 연산자이다.
얘는 정규 표현식과 같지는 않은데 반쯤은 정규 표현식을 닮은 문법을 지원하여, A LIKE B는 A가 B라는 패턴을 만족하는지 여부를 되돌린다. 0개 이상의 임의의 문자열을 뜻하는 와일드카드가 *가 아니라 %이다. XXX로 시작하는 문자열, 끝나는 문자열, 중간에 XXX가 포함된 문자열 같은 게 다 이걸로 커버 가능하다.

그런데 탈출문자/와일드카드가 존재하는 모든 문자열 체계가 그렇듯이 그 탈출문자 자체는 어찌 표현하느냐가 또 문제가 된다. 이를 위해 SQL에서는 A LIKE B 다음에 ESCAPE C라고, '필요한 경우' 탈출문자를 사용자가 지정해 줄 수 있다. 그래서 \%, \_ 이런 식으로 와일드카드 자체를 표현할 수 있다. 탈출문자 자체는 역시 그 탈출문자를 두 번 찍으면 표현 가능.
탈출문자로는 C/C++처럼 역슬래시를 써도 되지만, 다른 걸 지정해 줘도 된다. SQL은 의외로 이런 데에 유도리가 있다. LIKE는 뒤의 ESCAPE와 합쳐져서 삼항 연산자 역할도 한다고 생각하면 되겠다.

다음으로, SQL에서 문자열 상수(리터럴)는 작은따옴표 또는 큰따옴표로 모두 표현 가능하다. 문자열 내부에 작은따옴표가 있으면 큰따옴표로 둘러싸면 되고, 그 반대의 경우를 사용해도 된다. 그런데 고약하게 문자열 내부에 두 종류의 따옴표가 모두 존재한다면 그 따옴표 자체는 따옴표를 두 번 찍어서 표현하면 된다. 이건 LIKE 연산자가 아니라 SQL 파서 자체에서 인식하는 탈출문자이므로 LIKE 연산자가 인식하는 탈출문자와는 성격이 다르다. C/C++로 비유하자면 위상이 \ 탈출문자와 printf % 탈출문자와의 관계와도 같다.

쿼리 내부에서 따옴표 탈출문자의 처리는 매우 철저하게 해야 한다. 안 그러면 이건 SQL injection이라는 보안 취약점이 되기 때문이다. SELECT ... WHERE id='A' 이런 식으로 쿼리를 작성했는데 A 내부에 또 작은따옴표가 존재해서 문자열 상수를 종결해 버리고, 사용자가 입력한 문자열이 쿼리의 실행에 영향을 줄 수 있다면.. WHERE 절을 언제나 true로 만들 수 있고 DB 내용을 몽땅 유출할 수 있기 때문이다. 이런 사건이 대외적으로는 '해킹' 내지 '개인정보 유출'이라고 보도된다.

Posted by 사무엘

2016/12/11 08:38 2016/12/11 08:38
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1304

1.
예전에도 한번 이런 비유를 꺼낸 적이 있었는데.. 라면을 소프트웨어 플랫폼에다 비유하자면 봉지 라면은 PC, 사발면은 태블릿, 컵라면은 스마트폰 정도에 대응하는 것 같다. 그래서 한 플랫폼에서 잘나가던 라면이 다른 플랫폼으로 종종 포팅되곤 한다(카카오톡 PC 버전, 오피스 안드로이드 버전처럼). 비록 둘이 맛이 완전히 동일하지는 않지만 말이다.

식당에서 주문해서 먹는 라면은 집 밖의 거대한 다른 가게에 들어가서(서버 접속) 먹는 것이니 서버 사이드 웹 애플리케이션일 것이며..
분식점 같은 식당 납품을 목적으로 라면 제조사가 면이나 스프만을 대량으로 따로 파는 건 '엔진' 같은 미들웨어 컴포넌트 내지 라이브러리에 대응한다고 볼 수 있겠다.

2.
스마트폰은 컴퓨터와 달리.. (1) 특별한 일이 없는 한 24시간 켜져 있고, (2) 열받고 뜨거워질지언정 그래도 팬 돌아가는 소리가 안 나고, (3) 보조 기억장치가 있지만 하드디스크 돌아가는 것 같은 소리는 전혀 없다.
그래서 (2)와 (3)을 종합하면 스마트폰은 아주 조용하다. 게다가 얇기까지 하다.
어찌 보면 세상에 어떻게 이런 컴퓨터가 존재 가능해졌는지 신기한 노릇이 아닐 수 없다. 그것도 화면은 옛날 구닥다리 액정 같은 단색이 아니라, 고해상도 천연색 그래픽을 찍어 낸다. CPU뿐만 아니라 디스플레이나 메모리까지 총체적으로 왕창 발전했기 때문에 스마트폰이 만들어질 수 있었다.

옛날에는 뭔가 영상이 표시되는 기계 자체가 굉장히 미래 하이테크의 상징이었다. 집 현관을 표시해 주는 인터폰이나 자동차 내비 같은 거 말이다.
텔레비전이나 컴퓨터 모니터는 아날로그 신호에 둥그런 브라운관 형태로나마 진작부터 천연색을 표현할 수 있었다. 하지만 들고 다닐 수 있는 소형 텔레비전이나 인터폰, CCTV 같은 건 원가 때문인지 무엇 때문인지, 의외로 흑백 버전이 2000년대까지 쓰였다. 본인은 몇 차례 이사를 다니며 집을 옮긴 적이 있지만, 컬러 화면이 나오는 인터폰 실물을 태어나서 지금까지 한 번도 구경을 못 해 봤다.

그런데 어느 샌가 갑자기 CCTV의 화질이 급격히 향상되고 차량들이 개나 소나 내비에 블랙박스까지 달고 다니면서 블랙박스에 찍힌 사고 영상만 모아서 보여 주는 TV 프로가 큰 인기를 모을 정도가 됐다. 사진과 동영상을 즉각 생성해서 남들 보는 사이버 공간에 용량과 트래픽 걱정 없이 올리는 게 너무 금방, 쉽게 가능해졌다. 이건 1980년대의 SF물들이 제대로 상상하지 못한 너무 엄청난 변화임이 틀림없다.

그리고 컴퓨터 자체도.. 이젠 스마트폰 내부에서 가상 머신을 돌려서 도스는 말할 것도 없고 과거의 Windows 9x를 구동할 수도 있게 됐다. 머리만 비교하면 스마트폰의 CPU가 일반 데스크톱 PC의 CPU와도 성능이 호각이 됐으며, 단지 PC에 비해 부족한 건 입력 장치와 하드디스크 정도밖에 없다고 한다. 발열이나 전원의 한계는 차치하고라도 말이다.

모바일 플랫폼이 등장하면서 PC에서 x86 계열 CPU + Windows 계열 운영체제를 총칭하는 '윈텔' 독점 구도도 상당 부분 흔들리게 됐다. 완전히 새로운 형태의 시장 수요를 창출해 냈으니까. x86은 30년을 넘게 거슬러 올라가는 유구한 하위 호환성을 자랑하지만, 그 때문에 저전력 모바일에서 빠릿빠릿 움직이는 용도로는 상당히 부적합한 CPU가 돼 버려서 말이다. Windows도 마찬가지다.

다만, 단순히 이미 만들어진 정보들을 받아 보기만 하는 인터넷 단말기 이상으로, 뭔가 글쓰기나 코딩 같은 생산적인 활동을 하기에는 스마트폰은 문자 입력이 너무 불편한 게 흠이다. 구닥다리 타자기의 인터페이스를 답습하고 있지만 그래도 문자 입력 분야에서 키보드만 한 가성비를 제공하는 물건은 아직까지 없다.

예전에 그나마 전화기 버튼이라도 있던 시절에는 3*4 배열이라는 틀은 고정돼 있었는데..
요즘 스마트폰은 화면의 절대적인 크기나 종횡비까지 전부 그냥 흰 도화지 수준인 거 같다. 인간에게 가장 적합한 글쇠 scheme은 어떤 형태일까? 블루 오션이다 보니 먼저 연구해서 표준 틀을 정착시키는 사람이 그냥 장땡이 돼서 혼자 다 해먹을 수 있을 것 같은 생각이 드는데.. 난 잘 모르겠다. 난 한글 입력 쪽은 글쇠배열이 아니라 일단은 근본 메커니즘 연구가 주 관심 분야인지라..

글쇠 수가 너무 많으면 안 그래도 작은 화면에 너무 작은 글쇠 버튼을 잘못 찍어서 오타를 내기 쉽고, 반대로 글쇠 수가 너무 적으면 타수가 늘어나고 이것저것 모드를 바꾸는 빈도가 잦아져서 그것대로 또 입력이 불편해진다.
구글 단모음을 한동안 써 보다가 불편해서 다시 나랏글로 돌아왔다. ㅎ, ㅔ 같은 자모를 한 번에 바로 입력할 수 있어서 편한 것보다, 오타가 나서 불편한 게 더 크게 느껴졌다. 개인적으로는 나랏글을 거의 2004년부터 10년 넘게 쓰기도 했고 말이다.

3.
스마트폰이 폭발적인 인기를 끌면서 오늘날과 같은 사진· 동영상 업로드 문화를 만들어 낸 건 두 말할 나위 없이 '디지털 카메라' 기능까지 전화기 안에 쏙 들어간 덕분에 가능했다.
오늘날 폰의 카메라가 단순 화소수와 색감만 따지자면 어지간한 보급형 디카의 성능을 다 따라잡고도 남는다. 하지만 폰 카메라가 전용 디지털 카메라를 결코 따라잡지 못하는 게 크게 둘 있는데, (1) 줌과 (2) 부팅 속도이다.

근본적으로 카메라의 형태로 적합하게 설계되지 않은 그 얇은 몸체에다 두꺼운 다기능 렌즈까지 우겨넣는 건 아무래도 무리다. 그렇기 때문에 폰 카메라는 줌 기능이 전문적인 카메라의 적수가 될 수 없다. 시야각도 한계를 받기 때문에 이걸 극복하려면 별도의 파노라마 합성 앱 같은 것의 도움을 받아야 한다.

또한 디지털 카메라는 사진을 찍을 때에만 잠시 켰다가 끄는 걸 스마트폰보다 훨씬 더 간편하게 할 수 있기 때문에 밖에서 사진을 몇백 장씩 산발적으로 찍을 일이 있을 때 전력 소모 부담이 훨씬 덜하다. 부팅도 아예 범용 컴퓨터인 스마트폰보다야 비교할 수 없이 더 빨리 되며, 전원을 켜자마자 거의 곧장 촬영 ready 상태가 된다. 그 반면 스마트폰은 이런 특성을 전혀 갖고 있지 못하다.

하긴, 피처폰이 스마트폰으로 바뀌고 스마트폰에 온갖 복잡 다양한 기능들이 추가될수록 사용자가 알게 모르게 치르는 대가로는 배터리 시간이라든가 폰의 물리적 내구성 같은 게 있다. 이와 비슷한 맥락에서 스마트폰도 켠 직후에 수 초 이내로 바로 쓸 수 있는 게 아니라, PC에 준하는 급의 부팅이 필요하고 엄청난 양의 초기화와 캐싱, pre-fetching을 해 줘야 쓸 수 있는 물건이 되고 있다. 예전에 PDA나 공학용 계산기가 그렇게 부팅 시간이 긴 물건은 아니었으니 말이다. 부팅이 존재하고 악성 코드 걱정을 해야 하는 기기는 다른 전자 기기와는 성격이 근본적으로 다르며 훨씬 더 능동적인 물건이다.

한때는 이런 작은 화면에 찍히는 글자는 초간단 비트맵 글꼴 기반인 게 당연시되었는데 그게 힌팅까지 적용된 미려한 윤곽선 글꼴로 바뀌었다는 것 하나만으로도 소프트웨어적으로는 예전에 비해 그야말로 엄청난 부담이 추가된 거나 다름없다. 윤곽선 글꼴은 캐싱 없이는 도저히 쓸 물건이 못 되며, 캐싱이라는 건 굉장한 양의 메모리를 요구하기 때문이다.

오늘날 컴퓨터 프로그램들이 같은 일을 해도 예전보다 메모리와 CPU를 훨씬 더 많이 요구하는 이유는 유지 관리 차원에서의 범용성과 추상성을 높인 대신에 오버헤드가 더 커지고 성능 희생을 감수한 게 매우 크게 작용한다(가상 머신, 가상 함수, 등등등등). 스마트폰의 전력 소비나 부팅 속도도 그런 맥락에서 살펴볼 수 있을 듯하다.

Posted by 사무엘

2016/11/05 08:37 2016/11/05 08:37
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1290

오늘날이야 우리들의 눈을 현혹하는 온갖 사진과 짤방, 동영상들이 인터넷을 통해 컴퓨터로 현기증 날 정도로 범람하고 터져 나가는 시대이다.
하지만 불과 2~30년 전만 해도 PC는 글이 아닌 그림을 처리하기에는 용량과 성능이 꽤 버거운 물건이었다. 컴퓨터로 뭔가 실사 사진 자체를 구해다 보기가 쉽지 않았다. PC 통신으로 인기 연예인 사진을 단 한 장 다운로드 해서 보는 것조차도 단단히 작정하고 기다릴 준비를 하고서 해야 했다. 그리고 그것도 출처는 종이 화보나 필름 사진 스캔, 또는 아날로그 TV 화면 캡처였다..

21세기에 태어난 애들이 이런 얘기를 듣는 건.. 우리 세대가 부모님에게서 1950, 60년대에 나라가 얼마나 폐허였고 못살았는지를 듣는 것과 비슷한 느낌일 것이다. 아아~ 나도 이런 식으로 올드 타이머 꼰대의 대열에 합류하는구나..;;
그래도 난 옛날 컴퓨터 환경 회상이 좋다. 그러니 얘기를 계속하겠다.

그 시절엔 bmp, pcx를 넘어 gif 정도만 돼도 디코딩이 만만한 작업이 아니었다. 아래아한글 도스용에서 그림을 삽입해 보면 gif는 유독 렌더링이 더뎠다. 그런데 하물며 jpg는... 전용 뷰어가 필요하고 386에 램 얼마 이상, 부동소수점 코프로세서는 필수 이런 걸 요구하는 엄청난 포맷이었다. png 역시 그 당시로서는 신생인 만만찮게 무거운 포맷이었고.

이런 이유로 인해 도스에서 그래픽 뷰어는 나름 단순 텍스트/헥스 뷰어 이상의 유니크함과 전문성(?)을 지녔고 또 그래픽 에디터와는 별개의 입지를 가진 프로그램이었다. GUI 운영체제의 셸이 제공하는 기본 중의 기본, 필수 중의 필수 기능이 그때는 그렇게나 특별한 기능이었다. 도스까지 갈 것도 없이 무려 Windows 95 시절, 웹 브라우저 같은 게 없던 때엔 운영체제 차원에서 jpg 파일을 바로 볼 수 있지 않았다. 그림판은 bmp/pcx 전용이었으니까.;;

그래픽 뷰어는 완전 상업용 제품이라기보다는 셰어웨어로 만들기에 좋은 소재였다. 디렉터리 이동 + 파일 리스트 선택 기능을 구현한 뒤, 사용자가 엔터를 누르면 그 그림을 표시해 주는 게 기본 형태이다.
그런데 그것만으로는 좀 단조로우니 그래픽 뷰어에는 여러 장의 그림을 슬라이드 쇼처럼 보여주는 기능이 응당 추가됐다. 현란한 화면 전환 효과는 덤이고. 요즘 같으면 화면 보호기와 역할이 비슷해졌다.

비주얼 쪽 말고 다른 방면으로는.. 파일 관리 기능이 있다는 점에 착안하여 단순히 뷰어 이상으로 많은 그림 파일들을 일괄적으로 포맷을 변환하고 크기를 보정하고 효과를 주는 기능이 들어갔다. 이건 전문적인 그래픽 에디터와도 기능이 겹치는 구석이 있지만, 이쪽은 드로잉 기능이 없으며 한 파일이 아니라 여러 파일들에 대한 일괄 편집에 더 최적화되었다.
이런 분야에 속하는 프로그램으로 본인은 현재까지 다음과 같은 제품들을 기억하고 있다.

1. Graphic Workshop

사용자 삽입 이미지

모 컴퓨터 잡지/서적을 통해 알게 됐다. 1990년대 초인 꽤 옛날부터 개발되어 온 프로그램이며, 내 기억이 맞다면 GIF를 굉장히 일찍부터 지원해 온 걸로 유명했다.
스크린샷을 보면 알 수 있듯, 전반적으로 셸은 파란 배경의 단순한 텍스트 모드에서 동작했고 단순 표시뿐만 아니라 포맷 변환, 크기 조절 같은 그림 파일 관리 기능도 갖추고 있었다.

1989년에 처음 개발됐는데 91년에 벌써 버전이 6을 넘어간 건 도대체 개발과 버전업이 어떻게 돼 왔다는 뜻인지 모르겠다. MS Word는 다른 제품과 번호를 맞추기 위해서 2에서 바로 6으로 넘어가긴 했다만..;;
개발사인 Alchemy Mindworks라는 회사는 지금도 살아 있으며, 이 프로그램은 Windows용으로 계속 개발 중이다.

2. SEA

사용자 삽입 이미지

그래픽 뷰어 중에서는 느낌이 굉장히 인상적이었다. 일단, 왓콤 C/C++ 32비트 에디션으로 만들어진 덕분에, 게임도 아닌 것이 첫 실행 때 DOS/4GW(도스 익스텐더) 로고가 떴다.
성능면에서는 jpg 파일의 디코딩이 경쟁 프로그램들 중 가장 빠르다고 자처했다. 그림뿐만 아니라 소리 파일 재생이 됐으며, 동영상도 AVI 중에 1990년대 중반 런렝쓰 정도의 간단한 방식으로 압축 된 건 바로 재생 가능했다.

스크린샷을 보면 알 수 있듯 일괄 변환과 슬라이드 쇼 기능 정도는 물론 갖추고 있었으며,
이 모든 것에 더해서 전반적인 GUI 껍데기도 NextStep 운영체제를 흉내 낸 듯한(바탕에 검정 제목 표시줄) 상당한 고퀄이었다.
여러 모로 인상이 좋고 장인 정신이 느껴지는 잘 만든 프로그램이었다. 비등록 셰어웨어 버전도 첫 실행 때 '등록 해 주세요. press any key'가 뜨는 것 말고는 별다른 제약이 없어서 상당한 대인배이기까지 했다.

3. ACDSee

운영체제에 gif/jpg/png급 그림 파일을 보는 기능이 자체적으로 없던 Windows 95~98/2000 시절에는 개인적으로 이 프로그램을 유용하게 썼다. 이름이 똑같이 '씨'인데 앞의 도스용 프로그램은 sea이고 요 프로그램은 see이다.
얘도 한때는 내가 운영체제를 새로 설치한 뒤에 MDIR만큼이나 곧장 설치하는 필수 프로그램 중 하나였다. 굉장히 유용하게 썼다. SEA의 Windows 버전이나 마찬가지였는데, 해당 기능을 운영체제가 흡수한 뒤에는 정말 자연스럽게 존재감이 싹 없어져 버렸다.

그 첫 신호탄은 Windows에 IE 웹브라우저가 포함돼 들어가면서 기본적인 그래픽 뷰어 문제는 사실상 제공되기 시작한 사건이다. 월드 와이드 웹이라는 게 글과 그림으로 이뤄져 있으며 웹브라우저는 그 자체가 훌륭한 단백질 공급원은 아니고 훌륭한 그래픽 뷰어였기 때문이다. 단, IE는 옆 파일을 바로 열람하는 기능조차 없고 진짜 보는 것 하나만 가능하기 때문에 전문 뷰어/슬라이드 쇼 프로그램이 여전히 존재 의미가 있었다.

한 디렉터리 안에 있는 그림 파일들을 IE 창에서 쭈욱 열람하기 위해서 그 디렉터리를 기준으로 <img src="...."/> 태그를 쭈욱 나열하는 html 파일을 '생성하는 프로그램'을 짜서 개인적으로 활용했던 기억이 있다. 물론 이건 썸네일만 읽어들이는 게 아니라 파일들을 몽땅 한 페이지에다 읽어들이는 것이니 성능면에서는 좀 안습한 짓이긴 하다.

그리고 둘째 확인사살은 Windows XP이다. 얘부터는 탐색기 내부의 파일 리스트에서 그림 썸네일을 보는 편의 기능이 크게 강화되었으며, 그럭저럭 가볍고 괜찮은  그래픽 뷰어까지 내장됐기 때문이다. 그러니 별도의 싸제 그래픽 뷰어 프로그램에 대한 필요는 거의 사라졌다. 이런 이유로 인해 기존의 그래픽 뷰어들은 생존을 위해서 포토샵 같은 이미지 보정 기능을 더 강화한다거나 디지털 카메라 사진 관리 같은 더 차별화되고 전문적인 영역으로 넘어갔으며, 내 기억 속에는 현업에서 다들 물러나고 추억의 영역만 남게 되었다.

한때는 Paint Shop Pro에 내장돼 있는 Browse 기능도 유용하게 썼던 것 같은데 지금은 그냥 MS Office에서도 2003부터 Picture Manager라는 유틸리티가 생겨 있다. 예전에는 희귀했던 기능들이 지금은 다 기본으로 내장되고 대중화가 된 것이다.
단, Windows XP의 기본 그래픽 뷰어는 애니메이션 GIF를 재생하는 것까지도 지원했는데 Vista 이후부터는 그 기능은 없어졌다. 왜 빠졌는지는 알 길이 없다.

여기까지가 그래픽 뷰어 프로그램에 대해 본인이 갖고 있는 추억이다.
하긴, 음악을 듣는 것도 한때 꽤 먼 옛날엔 거원 제트오디오, WinAmp 같은 프로그램을 따로 썼다. 그러다 언제부턴가 그냥 WMP만 쓰지 다른 건 안 쓰게 됐다.
그래도 동영상은 WMP가 코덱과 자막 등 부족한 구석이 많이 있어서 팟/곰 같은 제3자 프로그램이 여전히 살아 있다. 내가 알기로 마소에서 WMP도 거의 IE11만큼이나 이제 더 만들 게 없는지 별로 육성은 안 하는 것 같다.

Posted by 사무엘

2016/05/16 08:32 2016/05/16 08:32
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1227

지금 와서 가만히 생각해 보니, 컴퓨터 알고리즘을 동원하여 푸는 문제들은 다음과 같은 세 범주로 나눌 수 있는 것 같다. 뒤로 갈수록 설명이 길어진다.

1. 최적해를 다항 시간 만에 구할 수 있으며, 직관적인 brute-force 알고리즘과 뭔가 머리를 쓴 알고리즘이 시간 복잡도 면에서 충분히 유의미한 차이를 보이는 문제

간단한 발상의 전환으로 인해서 속도가 드라마틱하게 빨라질 수 있고, 알고리즘에 대한 정량적인 분석도 어렵지 않게 다 되는 경우이다. 요런 게 알고리즘 중에서는 가장 무난하다. 정보 올림피아드에도 이런 부류가 가장 많이 나온다.
가장 전형적인 예는 시간 복잡도 O(n^2)가 O(n log n)으로 바뀐다거나, 지수함수 복잡도가 O(n^2)로, 혹은 O(n^3)이 O(n^2)로 바뀌는 것이다. 물론 시간 복잡도를 줄이기 위해서는 공간 복잡도가 시공간 trade-off 차원에서 추가되는 경우가 대부분이다. 중간 계산 결과들을 모두 저장해 놓는 다이나믹 프로그래밍 문제가 대표적인 예이다.

정렬, common subsequence 구하기, 그래프에서 최단거리 찾기 같은 깔끔하고 고전적인 문제들이 많다. 기하 분야로 가면 convex hull 구하기, 거리가 가까운 두 점 구하기도 있다. 하지만 세상에 산적한 문제들 중에는 이 1번 부류에 속하지 않는 것도 많다.

2. 최적해를 다항 시간 만에 구하는 것이 가능하지 않은 (것으로 여겨지는) 문제

P에는 속하지 않지만 NP에는 속하는 급의 문제이다. 이건 다항 시간 만에 원천적으로 풀 수 없는 문제를 말하는 게 아니며 개념과 관점이 사뭇 다르다. 비결정성 튜링 기계라는, 실물이 없는 이론적인 계산 기계에서는 그래도 다항 시간 안에 풀 수 있다는 뜻이다.

입력 데이터의 개수 n에 비례해서 상수의 n승 내지 n 팩토리얼 개수의 가짓수를 일일이 다 따져야 하는 문제라면 다항 시간 만에 풀 수가 없다. 그런데 실생활에는 이런 무지막지하게 어려운 문제가 은근히 많이 존재한다. 진짜 말 그대로 n!개짜리 뺑이를 쳐야 하는 외판원 문제가 대표적이고, 그래프에도 '해밀턴 경로 문제'처럼 이런 어려운 문제가 산적해 있다. 이런 분야의 문제는 소위 말하는 NP-complete, NP-hard이기도 하다.

요런 문제는 brute force 알고리즘으로는 대용량 데이터를 도저히 감당할 수 없고 그렇다고 다항 시간 최적해 알고리즘이 있는 것도 아니기 때문에, 이런 문제는 100% 최적해는 포기하고 그 대신 95+n%짜리로 절충하고 시간 복잡도는 O(n^2)로.. 뭔가 손실 압축스럽게 tradeoff를 하게 된다.
국제 정보 올림피아드에는 이런 문제가 많이는 안 나오지만 전혀 안 나오는 건 아니다. 출제된다면 답은 최적해와의 비율로 점수가 매겨지며, 프로그램 실행이 아닌 그냥 제출형으로 출제되기도 한다.

P와 NP 사이의 관계는 전산학계에서 만년 떡밥이다. 현실에서는 마치 장기간 실종자를 법적으로 사망한 것과 마찬가지로 간주하듯이 P와 NP는 서로 같지 않다고 여겨지고 있다. 이를 전제로 깔고 발표된 연구 논문들도 수두룩하다. 하지만 그게 정말로 딱 그러한지는 전세계의 날고 기는 수학자들이 여전히 완벽하게 규명을 못 하고 있다.

엔하위키에는 P!=NP임을 증명하는 사람은 전산학 전공 서적에 이름이 실릴 것이고, P=NP임을 증명하는 사람은 아예 초등학생 위인전에 등재될 것이라고 얘기를 했는데... 적절한 비유인 것 같다. 지수함수 brute force 말고는 답이 없는 문제가 좀 있어야 암호와 보안 업계도 먹고 살 수 있을 텐데..!

3. 최적해를 다항 시간 만에 구할 수 있음이 명백하고, naive 알고리즘도 실생활에서 그럭저럭 나쁘지 않은 결과가 나오지만, 그래도 미시적· 이론적으로는 최적화 여지가 더 있는 심오한 문제

말을 이렇게 어렵게만 써 놓으면 실감이 잘 안 가지만 이 그룹에 속하는 문제의 예를 보면 곧장 "아~!" 소리가 나올 것이다. 이 분야에도 어려운 문제들이 은근히 많다.

(1) 문자열 검색
실생활에서는 그냥 단순한 알고리즘이 장땡이다. 원본 문자열을 한 글자씩 훑으면서 그 글자부터 시작하면 대상 문자열과 일치하는지 처음부터 일일이 비교한다. 실생활에서 텍스트 에디터는 대소문자 무시, 온전한 단어 같은 복잡한 옵션들이 존재하며 각 글자들의 변별성도 높다(대상 문자열과 일치하지 않는 경우 첫 한두/두세 글자에서 곧바로 mismatch가 발생해서 걸러진다는 뜻). 그 때문에 그냥 이렇게만 해도 딱히 비효율이 발생할 일이 없다.

하지만 문자열 검색이라는 건 실무가 아닌 이론으로 들어가면 생각보다 굉장히 심오하고 난해한 분야이다. 원본과 대상 문자열이 자연어 텍스트가 아니라 오로지 0과 1로만 이뤄진 엄청 길고 빽빽하고 아무 치우침이 없는 엔트로피 최강의 난수 비트라고 생각하자. 그러면 예전에 패턴이 어디서부터 어긋났는지를 전혀 감안하지 않은 채 오로지 1글자씩만 전진하는 방식은 효율이 상당히 떨어진다. 이제야 좀 더 똑똑한 문자열 검색 알고리즘이 필요해진다.

퀵 정렬의 중간값(pivot) 선택 알고리즘을 의도적으로 엿먹이는 '안티' 데이터 생성 알고리즘만큼이나..
특정 문자열 검색 알고리즘을 엿먹여서 언제나 최악의 경우로 한 글자씩만 전진하게 만드는 문자열 데이터를 생성하는 안티 알고리즘도 있을 것이다.

(2) 팬케이크 정렬
a1부터 a_n까지 임의의 수 배열이 존재하는데, 우리가 이 수열에 대해 취할 수 있는 동작은 여느 정렬 알고리즘처럼 임의의 두 원소끼리의 교환이 아니다. 1~2, 1~3 또는 1..m (m<=n)처럼 첫째부터 m째의 원소들을 모조리 역순으로 뒤집는 것만 가능하다. 1 7 4 2였으면 2 4 7 1로 바꾼다는 것. n개의 임의의 수열이 있을 때 수열을 정렬하기 위해 필요한 이론적인 최대 뒤집기 횟수는 정확하게 얼마나 될까? 한꺼번에 몇 개를 뒤집건 한번 뒤집는 데 걸리는 시간은 무조건 상수라고 가정하고, 뒤집기 자체 외에 다른 계산의 비용(가령, 현 구간에서 maximum 값을 찾는 것)은 전혀 고려하지 않아도 된다.

본인은 아주 어렸을 때 GWBASIC 교재에서 이 팬케이크 정렬 문제와 같은 방식으로 수열을 뒤집어서 "사람으로 하여금 문제를 풀게 하는" 프로그램을 본 기억이 있다. 프로그램의 이름이 REVERSE였다.
이 문제는 마치 선택 정렬과 비슷한 방식으로 명백한 해법이 존재한다. 가장 큰 수가 m째 원소에 존재한다면 m만치 뒤집어서 가장 큰 수가 맨 처음에 오게 한 뒤, 판 전체를 뒤집어서(n만치) 그 수가 맨 뒤로 가게 하면 된다. 이 과정을 그 다음 둘째, 셋째로 큰 수에 대해서 계속 적용하면 된다.

그렇게 명백한 해법의 계산 횟수는 최대 2*n-3으로 알려져 있다. 하지만 이것은 그렇게 뒤집은 여파가 다음으로 큰 수들을 정렬하는 데 끼치는 영향이 감안되어 있지 않다. 물론 여기서 좀더 머리를 써 봤자 2n이던 계수가 1.xx 정도로나 바뀌지 그게 n 내지 심지어 log n급으로 확 바뀌지는 못한다. 비록 O(n) 표기상으로는 동일하지만 그렇게 상수 계수를 조금이라도 줄이는 최적화이다 보니, 알고리즘이 더 까다롭고 머리가 아프다.

마이크로소프트의 창립자인 그 빌 게이츠가 1979년에 바로 이 문제의 계산 횟수를 최적화하는 알고리즘을 (공동) 연구하여 이산수학 학술지에다 투고했었다. 이 사람의 기록은 그로부터 거의 30년이 지난 2008년에야 더 정교한 알고리즘이 나옴으로써 깨졌다. 이것은 빌이 단순히 비즈니스맨이기만 한 게 아니라 엔지니어 기질도 얼마나 뛰어났고 수학 쪽으로도 얼마나 천재였는지를 짐작케 하는 대목이다. 학부 중퇴 학력만으로도 이미 전산학 석· 박사급의 걸출한 리서치를 했으니 말이다.

(3) 행렬의 곱셈
갑자기 팬케이크 정렬 얘기가 좀 길어졌는데 다음 항목으로 넘어가자면.. 계산 관련 알고리즘도 이런 급에 속한다. 대표적으로 행렬.

일반적으로야 두 개의 n*n 정방행렬끼리 곱셈을 하는 데 필요한 계산량, 정확히 말해 두 수 사이의 곱셈 횟수는 정확하게 O(n^3)에 비례해서 증가한다. 그러나 거대한 행렬을 2*2 형태의 네 개로 쪼개고, 덧셈을 늘리는 대신 곱셈을 줄이는 방식으로 최적화를 하는 게 가능하다. 게다가 쪼개진 행렬이 여전히 크다면 그걸 또 재귀적으로 쪼갤 수 있다.
a+bi와 c+di라는 복소수의 곱셈을 위해서 통상적으로는 ab, ac, bc, bd라고 곱셈이 총 4회 필요하다고 여겨지지만 실은 덧셈을 더 하는 대신에 곱셈은 ac, bd와 (a+b)*(c+d)로 3회로 줄일 수 있지 않은가? 그런 식으로 줄인 것이다.

그렇게 해서 O(n^3)보다 이론상 작은 시간 복잡도가 최초로 제안된 게 1969년에 나온 슈트라센 알고리즘이다. 대략 O(n^2.8). 정확하게 2.8인 건 아니고 지수 자체가 로그 n 이런 형태로 떨어진다. 프랙탈의 차원 수가 로그로 표현되는 것처럼 말이다.
여기서 2.8x의 정확한 의미는 log[2] 7이다. 원래 2*2 행렬 두 개를 곱하기 위해서는 상수 곱셈이 8회 필요한데, 중간 과정의 공식들을 궁극의 캐사기 테크닉을 동원하여 변형했다. 어마어마한 양의 우회 연산을 통해 덧셈은 횟수가 왕창 늘었지만 곱셈이 8회에서 7회로 딱 1회 줄었다! (도대체 무슨 약 빨고 연구해서 이런 걸 생각해 냈을까? ㄷㄷ) 이 여파가 분할 정복법의 특성상 재귀· 연쇄적으로 적용된 덕분에 전체 시간 복잡도가 감소한 것이다.

그리고 이 바닥도 발전에 발전을 거듭한 덕분에 오늘날은 무려 O(n^2.4)대까지 곤두박질쳤다. 덧셈과는 달리 곱셈은 이런 최적화의 여지가 존재한다는 사실 자체가 아주 신기하지 않은가? 크기가 서로 다른 행렬들의 최소 곱셈 횟수를 구하는 다이나믹 프로그래밍 문제하고는 완전 별개의 영역이다.

아래의 그림을 보자(움짤임). RGB라는 세 대의 차량이 서로 부딪치지 않고 G는 그대로 위로, R과 B는 서로 좌우가 엇갈리게 빠져나가려면 어떻게 하면 좋을까? 아래의 중앙은 길이 막혔기 때문에 횡단을 할 수 없다.
결국 가운데 G는 곧이곧대로 위로 나가서는 안 되며, R과 B의 경로를 피해서 몇 배나 더 긴 우회를 해야 한다. 하지만 그래도 RGB 모두 신호 대기가 없이 서로 엇갈리는 방향으로 술술 소통이 가능하다.

사용자 삽입 이미지

자연에는 관성이라는 게 존재하니, 다리가 아니라 바퀴가 달린 자동차나 열차에게는 우회를 하더라도 이게 훨씬 더 나은 방법인 것이다.
행렬도 덧셈이라는 우회가 아무리 몇 배로 더 늘어 봤자, 아주 큰 행렬(차량 소통이 엄청 많을 때)에 대해서는 곱셈이 눈꼽만치라도 줄어드는 게 도로로 치면 신호 대기가 없어지는 것에 맞먹는 이익이 될 수 있다는 생각이 든다.

물론 행렬의 곱셈 시간 복잡도가 O(n^2)보다 더 낮아질 리는 없으며, 저런 알고리즘들은 지수를 줄이는 대신 공간 복잡도(스택 사용..) 같은 다른 오버헤드가 왕창 커졌다는 점을 감안해야 한다. 크기가 몇십~몇백 정도 되는 초대형 행렬에서 두각을 발휘하지, 그냥 3차원 그래픽용으로나 간단히 쓰이는 3*3이나 끽해야 4*4 행렬에서 적용할 만하지는 않다.

Posted by 사무엘

2016/01/12 08:30 2016/01/12 08:30
, , ,
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1181

오늘은 코딩으로 먹고 사는 사람이라면 기억할 만한 가치가 있는 전설적인 인물을 좀 소개하고자 한다.

사용자 삽입 이미지

이 예쁘장하게 생긴 아가씨는 무려 아폴로 11호 우주선을 총괄 제어하는 컴퓨터 프로그램을 개발한... 열혈 공순이 되시겠다. 이름은 마가렛 해밀턴(1936~). (마가렛 대처..는 영국의 정치인 이름이고.)

지금은 이미 80을 바라보는 할머니가 되었지만 저 사진은 1968~1969년경에 촬영되었으니, 지금 내 나이 때 저런 일을 해낸 것이다.
IBM PC도, 인텔 마이크로프로세서도, C/파스칼도 없던 시절에 프로그래밍을 도대체 어떻게 했다는 건지 실감이 안 감. 기껏해야 어셈블리어, 포트란, 코볼 정도나 있었을 텐데.
우주선이나 전투기에는 Ada 언어가 많이 쓰인(쓰였)다고 하지만 이마저도 거의 1980년대는 돼서야 등장한 언어이다.

저기 옆에 있는 서류더미는..;; 프린트된 전체 소스 코드 리스트라고 한다.
그녀는 노가다 코딩만 한 게 아니라 수학자· 과학자· 공학자의 영역을 넘나들면서 아폴로 우주선의 달 착륙을 가능하게 했으며, 그 까마득한 옛날에 사실상 소프트웨어 공학이라는 학문 영역을 새로 개척했다고 한다. 이런 사람의 숨결을 받아서인지 NASA가 예로부터 컴퓨터 프로그램 최적화의 종결자 소리를 듣게 된 건지도 모르겠다.

한 마디로 여군 장성인 그레이스 호퍼의 뒤를 이은 미국의 천재 여성 프로그래머 정도로 생각하면 되겠다.
그녀는 나중엔 자기 이름을 따서 Hamilton Technologies라는 회사도 차렸다.
주요 솔루션이 Universal Systems Language이라고 하는데.. 말만 들어서는 PL과 SE 분야의 융합 같기도 하고 도대체 핵심 기술이 무엇인지가 봐도 모르겠다. 너무 추상적이어서 그런지...

저 때는 <2001 스페이스 오디세이>가 개봉한 지 얼마 되지 않았을 시절이니, 그 당시에 딱 현업에서 종사하고 있었던 저분은 그 영화를 보는 눈이 남달랐을것이다. 아니 아예 영화 제작 과정에서 기술 자문도 해 주지 않았을까.

이 사람과 대등한 레벨의 괴수를 우리나라에서 찾자면 아무래도 성 기수 박사를 꼽을 수 있겠다.
일단 1934년생으로 연령도 비슷하고, 하버드 최단기 박사 졸업에다 우리나라 컴퓨터 역사의 산 증인인 분이기 때문이다.
우주선 시스템은 아니지만 88 서울 올림픽의 전산 운영 시스템을 총괄 개발했다. 게다가 이분 역시 원래 전공은 항공 우주로 NASA 입사를 지망하기까지 했으며, 1960년대의 컴퓨터와 프로그래밍 환경을 접했던 분이기 때문에 일치하는 면모가 많다.

저런 천재들을 보면 난 지금까지 도대체 뭘 하고 살았나 싶은 자괴감이 든다.

그리고 여담.

  • 저 사진에 있는 마가렛 해밀턴의 옷차림처럼, 무릎까지 올라오는 미니스커트(!)가 세상에 첫 등장한 것도 1960년대 후반의 일이다. 그러니 저 복장은 그 당시로서는 최신 패션이었다..!
  • '그레이스 호퍼(Grace Hopper)'는 grasshopper(메뚜기)와 단어 발음이 참 묘하게 비슷하다..;;

Posted by 사무엘

2015/12/26 08:39 2015/12/26 08:39
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1175

※ 메모리 단편화

컴퓨터에서 무작위 읽기/쓰기가 가능한 모든 기억장치.. 즉 RAM, 파일 시스템, 데이터베이스 따위에는 모두 구조적으로 단편화라는 문제가 존재한다.
메모리를 10바이트씩 찔끔찔끔 요청했는데 최소 할당 단위 제약 때문에 실제로는 수백 바이트 단위로 성큼성큼 용량이 짤려 나간다거나(내부 단편화),
전체 남은 용량은 1000바이트인데 한 600바이트 정도 연속된 구간이 없어서 메모리 할당이 실패하는 외부 단편화가 모두 존재한다.

메모리라는 게 1차원적인 공간이기 때문에 이건 뭐 어쩔 수 없다.
그래서 컨텐츠가 실제로 차지하는 용량보다 전체 소모 용량이 더 커지게 되고, 이런 걸 관리하는 프로그램이나 유틸리티에는 조각 모음(defrag), shrink, compact 같은 동작을 강제로 수행하는 기능이 있다. (뭐, 디스크 중에서 SSD는 예외적으로 조각 모음이 필요하지 않은 구조라고는 하지만.)

디스크는 애초부터 파일 시스템의 지배 하에 있으며 그 시스템이 제공하는 방식대로 디렉터리와 파일 이름을 통해서만 내용에 접근 가능하다. 일반적인 응용 프로그램이 디스크를 무슨 실린더 번호 x, 트랙 y, 섹터 z 같은 형태로 무식하게 접근하는 경우는 거의 없다. 그런 방식은 오늘날의 운영체제에서는 더욱 금기시되고 있다.

그렇게 파일명이라는 고수준 추상 계층이 있는 덕분에 디스크는 내부적으로 막 조각 모음을 해도 딱히 파일을 못 찾는 일이 발생하지는 않는다. 저수준 처리는 운영체제의 파일 시스템이 알아서 다 처리해 준다. 또한 디스크 정도면 물리적으로 액세스를 하는 데서 발생하는 병목이 소프트웨어적인 추상화 계층을 거치는 시간보다 훨씬 더 길기도 하고 말이다. 사용자에게는 외부 단편화보다는 클러스터 최소 단위로 인한 내부 단편화가 현실적으로 더 와 닿는다.

그런데 RAM은 디스크와는 사정이 다르다. 단편화를 예방한답시고 함부로 컨텐츠들을 재배치하면 memcpy 오버헤드는 둘째치고라도 그 메모리 주소를 직접 가리키고 있던 수많은 포인터들이 작살이 나 버린다.
메모리 자원이 극도로 가난하고 열악하던 16비트 Windows 시절에는 운영체제의 global/local heap으로부터 메모리를 할당받고 나면 곧바로 포인터가 돌아오는 게 아니라 핸들 하나만이 돌아왔다. 이 핸들이 가리키는 메모리는 운영체제의 사정에 따라 수시로 재배치될 수 있는데, 메모리를 실제로 사용할 때만 lock을 걸어서 위치를 고정시킨 뒤, 포인터를 얻어와서 메모리를 참조하곤 했다. 사용이 끝나면 다시 unlock을 해 줘야 한다.

이것이 바로 GlobalAlloc - GlobalLock - GlobalUnlock - GlobalFree 사이클이다. 재배치를 하는 이유는 당연히 메모리 단편화를 극복하고, 연속된 긴 메모리 공간을 언제나 확보하기 위해서이다. 16비트 시절에 메모리 블록이나 리소스 같은 데에 discardable, resident, non-resident 같은 속성이 달려 있던 이유는, 수시로 재배치 내지 재로딩 같은 빡센 메모리 관리에 대응하기 위해서이다.
운영체제가 자동으로 무슨 garbage collect를 해 주는 것도 아니고, 저런 일을 해야만 했다는 게 참 안습하다.

여기서 우리가 알 수 있는 점은, 32비트 정도 되는 주소 공간에서 가상 메모리가 제공되는 게 프로그래머의 관점에서 얼마나 축복이냐 하는 것이다. 4기가바이트 정도 넉넉한 공간이 있으면, 단편화 문제는 주소빨로 어느 정도, 상당 부분 극복이 가능해진다. 어지간히 단편화가 심한 상태라 해도, 또 대용량 메모리 요청이 들어오면 걍 다음 주소를 끌어다가 물리 메모리에다 대응시켜 쓰면 되기 때문이다.

그 연속된 가상 메모리 주소를 실제로는 여기저기 흩어졌을 가능성이 높은 지저분한 물리 메모리로 대응시키는 건 운영체제와 CPU의 몫이다. 물리 메모리가 부족하면 하드디스크 스와핑까지 알아서 해 준다. 가상 메모리 덕분에 프로세스간에 보안이 더 향상된 것도 덤이고 말이다.

이것이 RAM과 디스크의 차이이다. 디스크에 파일명이 있다면 RAM에는 가상 메모리 메커니즘이 있다. 한 주소 공간 안에서 스레드가 여러 개 있는 경우 가상 메모리의 필요성은 더욱 커진다.
물론, 세상에 공짜는 없으니, 가상 메모리는 메모리를 관리하기 위한 추가적인 메모리도 적지 않게 소요하는 테크닉인 걸 알아야 한다. 물리적인 메모리뿐만이 아니라 가상 메모리 주소 영역 자체도 떼먹는다.
오늘날 64비트 운영체제라 해도 어마어마하게 방대한 공간인 64비트 전체를 사용하는 게 아니라 40비트대 정도만 사용하는 것도 이런 이유 때문이다.

※ 옛날 이야기

옛날의 프로그래밍 언어나 소프트웨어 플랫폼을 살펴보면, 메모리와 관련하여 오늘날 당연한 기본 필수라고 여겨지는 요소가 대놓고 빠진 것들이 적지 않아 놀라게 된다.

(1) 예를 들어 옛날에 포트란 언어는 함수 호출은 가능하지만 초기에는 동일 함수에 대한 중첩/재귀 호출이 가능하지 않았다. 세상에 뭐 이런 언어가 다 있나 싶다..;; 함수 안에서 지역 변수의 사용이 스택 기반으로 되어 있지 않고 늘 고정된 주소로만 접근하게 돼 있어서 그랬던 모양이다.

오늘날의 프로그래밍 언어에서야 지역 변수는 스택의 기준 주소로부터 상대적인 위치를 건드리게.. 일종의 position independent code 형태로 접근된다. 재귀 호출 지원뿐만 아니라 코드 실행 주체가 증가하는 멀티스레드 환경에서는 각 스레드가 또 독립된 스택을 갖고 있으니 절대 고정 주소가 더욱 의미를 상실하기 때문이다. 멀티스레드는 thread-local이라는 일종의 새로운 scope까지 만들었다.

(2) 한편, 프로그래밍 언어 쪽은 아니지만, Win32의 구현체 중에 제일 허접하고 불안정하고 열악하던 Win32s는..
멀티스레드도 없고 각 프로세스마다 독립된 주소 공간이 없는 건 그렇다 치는데... DLL은 자신이 붙는 각 프로세스별로 자기만의 독립된 데이터 공간마저도 보장받지 못했다. 16비트 DLL과 다를 바가 없다는 뜻.

옛날에 아래아한글 3.0b는 윈도 95나 NT 말고 3.1 + Win32s에서 돌아갈 때는 무슨 자기네 고유한 메모리 서버 프로그램을 먼저 실행한 뒤에야 실행 가능했다. 이제 와서 다시 생각해 보니, 그 메모리 서버가 하는 일이 바로 DLL별로 고유한 기억장소를 할당하는 것과 관련이 있지 않았나 싶다. 아래아한글의 소스를 모르는 상태에서 그냥 개인적으로 하는 추측이다.

아시다시피 16비트 Windows는 가상 메모리 같은 게 없다 보니, 콜백 함수의 실행 context를 레지스터에다 써 주는 것조차 소프트웨어가 수동으로 해야 할 정도로 진짜 가관이 따로 없었다.

※ 쓰레기(다 쓴 메모리) 수집

끝으로 garbage collector 얘기다.
heap으로부터 할당하는 메모리는 너무 dynamic한지라 언제 얼마만치 할당해서 언제 해제되는지에 대한 기약이 없다. 그걸 소스 코드만 들여다보고서 정적 분석으로 완벽하게 예측하는 건 원천적으로 불가능하다.

하지만 정해진 scope이 없는 동적 메모리를 잘못 건드려서 발생하는 소프트웨어 버그는 마치 자동차의 교통사고처럼 업계에서 상당히 심각한 문제이다.
memory leak은 당장 뻑이 나지는 않지만 프레임 단위 리얼타임으로, 혹은 수 개월~수 년간 지속적으로 돌아가는 소프트웨어에서는 치명적이다. 또한 다른 메모리/포인터 버그도 단순히 혼자만 뻑나는 걸로 끝나면 차라리 다행이지, 아예 악성 코드를 실행시키는 보안 문제로까지 상황을 악화시킬 수 있다.

이 동적 메모리 관리를 사람에게 수동으로 맡겨서는 안전하지 못하니, 메모리 자원 회수를 프로그래밍 언어 런타임 차원에서 자동으로 보장되게 하는 기법이 연구되어 왔다.
고전적인 reference counting 테크닉은 C++의 생성자/소멸자 패러다임과 맞물려서 일찍부터 연구되어 왔으며 smart pointer 같은 구현체도 있다.

이건 원리가 아주 간단하며, 언어 차원에서 포인터의 scope가 벗어나는 족족 메모리가 칼같이 회수되는 게 컴파일 시점에서 보장된다. 그래서 깔끔한 것 하나는 좋다.
허나 이 기법은 생각보다 비효율과 단점도 많다. 대표적인 논리적 결함인 순환 참조는.. 서로 다른 두 객체가 상대방을 서로 참조하여 똑같이 참조 횟수가 1보다 커지고, 따라서 둘이 메모리가 결코 해제되지 않아서 leak으로 남는 문제이다.

즉, 레퍼런스 카운팅이 잘 동작하려면, 참조를 받은 피참조자는 자신을 참조하는 놈을 역참조하지 말아야 한다. 이걸 어기면 객체간의 레퍼런스 카운트가 꼬여 버린다.
문제는 이걸 일일이 조심하면서 코드를 작성하는 게 상황에 따라서는 차라리 걍 메모리 자체를 수동으로 관리하는 게 나을 정도로 효율이 떨어질 수 있다는 것이다. 게다가 고리가 어디 A-B, B-A 사이에만 생기겠는가? A-B, B-C, C-A 같은 식으로 더 골치 아프게 생길 수도 있다. 참조 관계는 정말로 cycle이 없이 tree 형태로만 가야 한다.

그러니 이 문제는 예상 외로 굉장히 심각한 문제이다. 멀티스레드에서의 '데드락'하고 다를 바가 없다! 서로 뭔가 꼬여서 끝이 안 난다는 점, 잡아 내기가 극도로 어렵다는 점이 공통점이다.
성능을 더 희생하고라도 메모리 leak 문제를 완전히 다른 방식으로 접근한 전용 garbage collector가 괜히 등장한 게 아니었겠다 싶다.

가비지 컬렉터라고 해서 무슨 용 빼는 재주가 있는 건 아니다. 기본적으로는 당장 접근 가능한 메모리로부터 출발해서 그 메모리로부터 추가로 접근 가능한 메모리 블록을 줄줄이 순회하여 표시를 한 뒤, 표시가 없는 메모리를 죄다 해제한다는 아이디어를 기반으로 동작한다. 동적으로 할당받은 메모리 내부에 또 동적 할당 메모리의 포인터가 있고, 그게 또 이상하게 얽히고 배배 꼬인 걸 어떻게 일일이 다 추적하는지 더 구체적인 방법은 잘 모르겠지만.

어찌 보면 단순무식하다. 주인 없이 주차장에 장기간 방치되어 있는 폐자전거들을 일괄 처분하기 위해 모든 자전거에 리본을 달아 놓은 뒤, 일정 날짜가 지나도록 리본이 제거되지 않은 자전거를 갖다 버리는 것과 개념적으로 비슷하다! 혹은 기숙사의 공용 냉장고에서 주인에게로 접근(?)이 안 되는 장기 방치 식품을 주기적으로 제거하는 것과도 비슷한 맥락이다. 단지 좀 더 성능을 올리기 위해, 메모리 블록들을 생존 주기별로 분류를 해서 짬이 덜 찬 메모리가 금방 또 해제될 가능성이 높으므로 거기부터 살펴보는 식의 관리만 하는 정도이다. 자바, .NET의 가상 머신들도 이런 정책을 사용한다.

이건 즉각 즉각 자원이 회수되는 게 아니며, 리얼타임 시스템에서는 적용을 재고해야 할 정도로 시공간 오버헤드도 크다. 그러나 한번 수집이 벌어질 때 랙이 있다는 말이지, 매 대입 때마다 시도 때도 없이 카운터 값을 변화시키고 그때 스레드 동기화까지 해야 하는 레퍼런스 카운팅도 성능면의 약점은 상황에 따라 피장파장일 수 있다.

언어 차원에서 이런 가비지 컬렉터가 제공되어서 delete 연산자와 소멸자 자체가 존재하지 않는 언어가 요즘 추세이다. 자바나 C#처럼. 하지만 메모리는 그렇게 자동으로 수집되지만, 파일이나 다른 리소스 핸들은 여전히 수동으로 해제를 해야 할 텐데 무작정 소멸자가 없어도 괜찮은지는 잘 모르겠다. 본인은 그런 언어로 대규모 프로그램을 작성한 경험이 없다. C++ 이외의 언어에서는 RAII 개념이 아예 존재하지 않는 건지?

Posted by 사무엘

2015/09/20 08:28 2015/09/20 08:28
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1140

※ 컴퓨터 & 프로그래밍

1.
예전에 본인은 시스템 종료 중에라도 사용자가 무슨 동작을 취하면, 컴을 아주 꺼 버리는 시스템 종료가 아니라 그 뒤 '재시작'으로 종료 모드를 바꾸는 기능이 있으면 좋겠다는 제안을 한 적이 있다. 그것과 비슷한 제안인지도 모르겠는데, 또 하나 아이디어를 내자면 이렇다. 사용자가 한동안 컴퓨터를 건드리지 않아서 모니터가 꺼지거나 컴퓨터가 절전· 최대 절전· 종료 등으로 바뀌게 되면, 그 모드로 진입하기 전에 화면에 10초나 5초 정도 카운트다운을 좀 띄웠으면 좋겠다.

프레젠테이션을 할 때처럼 화면을 빤히 보고 있으면서 키보드· 마우스만 안 건드리고 있는데 화면이 갑자기 꺼져 버려서 당황한 적이 여러 번 있었다. 화면 보호기 정도는 카운트다운 없이 바로 진입해도 상관 없겠지만 아예 하드웨어적인 변동이 생기는 저런 모드는 예고가 있으면 좋겠다.

2.
동영상 엔진인 '코덱'과 과거의 컴퓨터 통신 장비인 '모뎀'이 정확히 같은 조어법에 의해 거의 같은 구조의 이니셜을 가진 단어이구나.

3.
식당에서 주문을 한 뒤에야 "아 손님, 죄송하지만 재료가 떨어져서 그 메뉴는 지금 제공이 안 됩니다" 이런 메시지를 받으면 허탈하잖아. 애초에 메뉴판에 그런 메뉴는 disable된 상태로 시각 피드백이 있으면 좋겠다.

4.
공동 작업을 하는 코드의 명칭에 영어 스펠링이 틀린 게 많아서 작업에 지장을 적지 않게 받은 적이 있었다. 검색이 안 되기 때문이다. 이쯤에서 분명 availableItem이런 단어가 있는 걸 봤었는데 나중에 보니 avalible이라고 돼 있는 식.
이건 당장 버그나 성능 같은 동작과 직접적인 관련이 있지는 않지만, 그래도 또 다른 형태의 민폐이다. 도서관으로 치면, 책을 보고 나서는 자기 분류 코드상으로 있어야 할 곳이 아닌 엉뚱한 곳에다 책을 꽂은 것과 같다. "잘못 꽂힌 책은 없는 책과 같습니다. 정리는 사서가 알아서 할 테니까 열람하신 책은 그냥 여기에 놔 두세요" ;;;;

5.
관광 가이드를 매뉴얼과 스케줄 대로 승객들을 안내하는 컴퓨터 프로그램에다가 비유한다면, 이 사람이 수행하는 프로그램의 소스 코드는 정말 그야말로 try ... catch문으로 빽빽이 무장하고 있어야겠구나 하는 생각이 들었다.
누군가가 갑자기 아플 때, 뭔 물건을 놔 두고 왔을 때, 여권을 잃어버렸을 때, 긴급한 사고가 발생했을 때, 일행 중 일부가 없어져서 못 찾을 때 등등.. 그 어떤 예외 상황에서도 패닉과 스케줄 펑크를 최소화하는 방향으로 의연히 대처가 가능해야겠다.

6.
Windows 환경에서 응용 프로그램이 자기 영역으로 사용할 수 있는 메모리 주소는 64KB 이상부터이다. NULL 포인터인 0자체뿐만이 아니라 첫 64KB는 가상 메모리 영역 설계 차원에서 봉인되어 있으며, 이 주소에 메모리를 읽거나 쓰는 건 무조건 에러가 난다. 사실, 0 자체뿐만 아니라 64KB 정도까지는 막혀 있어야 NULL포인터 자체뿐만 아니라 NULL로부터 구조체 멤버를 참조한 포인터도 에러로 처리될 수 있을 것이다. ((POINT *)NULL)->y처럼.

아울러, 과거의 Windows 9x는 이보다 제약이 더 커서 64KB가 아니라 상위 4MB까지가 추가로 막혀 있었다. 64K부터 4M까지의 영역은 16비트 프로그램(도스용 & Windows용 모두)이 사용한다. (☞ 이에 대한 더 자세한 설명)

이런 이유로 인해 전통적으로 32비트 Windows 프로그램들은 시작 주소(preferred base)가 딱 4MB로 맞춰지곤 했다. NT 계열에서는 꼭 4MB가 아니라 64KB 이상 아무 지점이어도 상관이 없지만, 4MB 이상이어야 윈도 9x와 NT계열에서 모두 실행 가능하기 때문이다.

그런데 이건 오늘날까지도 하드디스크가 C로 시작하는 디스크 드라이브 관행과도 정확히 일치하는 것 같다.
플로피 디스크가 완전히 없어졌음에도 불구하고 A, B 드라이브는 사실상 결번으로 남아 있으니 말이다. 요즘은 하다못해 USB 메모리 드라이브를 거기에다 할당해도 될 것 같은데!

※ 알고리즘

7.
longest common subsequence를 구하는 문제와 longest increasing subsequence를 구하는 문제는 서로 관련이 있는 무척 흥미로운 문제인 것 같다.
가만히 생각해 보니, 후자는 임의의 sequence와, 그 입력을 오름차순으로 정렬한 sequence와의 longest common subsequence를 구하는 것과 같다. 그러므로 후자는 전자 문제로 다항 시간 만에 변환 가능한 special case이다.

두 문제는 일단 다이나믹 프로그래밍으로 O(n^2)의 복잡도로 풀 수 있지만, 더 작고 특수한 케이스인 후자는 O(n log n)의 해법도 있다.
전자 문제는 문장의 정확도를 구하는 알고리즘, 소스 코드의 diff 툴 등 활용되는 분야가 굉장히 많다. 지금은 어떤가 모르겠는데 내 때에는 국제 정보 올림피아드의 첫째 날 1번 문제가 해법이 이 형태로 귀착되는 경우도 종종 있었다. 1999년도의 꽃병 문제는 대놓고 저런 타입이었고, 2000년도의 palindrome 문제도 자신과 자신을 역순으로 뒤집은 단어와의 longest common subsequence를 구하는 것과 동일하다.

8.
엑셀에서 파이 모양 차트를 그리면 아이템별로 파랑, 빨강, 주황 등 알록달록한 색깔이 배당되어 차트가 그려진다.
그런데 최초의 색깔인 파랑부터 아이템 N에 이르기까지, 색깔을 선별하는 방식이 과연 무엇일까?
Office 2003까지는 뭔가 보라색 위주의 우중충하고 칙칙한 색깔 위주였는데 2007부터는 그래도 예전보다 훨씬 더 세련되게 바뀌었다.

이건 뭔가 RGB나 hue 같은 색공간에서 최대한 균등하게, 마치 흑에서 백으로 디더링 픽셀을 하나씩 채워 나가듯이 색깔을 뽑아낸 것 같다(관련 링크). 그 구체적인 알고리즘이 궁금하다.
그리고, 이런 픽셀 채우기 문제의 domain을 2차원 평면이 아니라 3차원 공간으로 확장하면 문제의 난이도가 어찌 되는지도 궁금하다.

※ 자동차

9.
자동차 차량 취급 설명서의 각종 선택사양에만 적용되는 설명들은 C/C++ 코드에서 #if #endif 전처리기에 대한 아주 좋은 예시라 여겨진다.

10.
오늘날 "일찍 나는 새가 벌레를 잡는다"보다 훨씬 더 현실적으로 와 닿는 말은 "일찍 움직이는 차가 주차 자리를 차지한다"라고 해도 과언이 아닐 것이다.

※ 기타 미분류

11.
공항 안에 개인 물품 보관함 같은 게 있으면 단독 여행 시에 유용하겠다는 생각이 든다. 이곳과 계절이 크게 다른 지역을 여행 갈 때 지금 입은 옷을 보관해 놓는다거나, 반입 금지 내지 무게 제한에 걸린 물건을 귀국 때까지 임시로 보관할 수 있게 말이다. 물론 후자의 경우는 당사자가 보관함까지 갔다가 돌아오는 게 곤란하니, 추가 비용을 부담해서 보관 대행을 맡길 수 있어야 하겠다.

12.
비행기와 열차의 큰 차이:
열차는 출발 15분 전부터 승강장으로 입장이 가능한 반면, 비행기는 출발 15분 전에 탑승이 종료된다는 것이다.
그리고 여담인데, 내 경험상 인천 공항을 출발한 비행기는 견인차에 끌려 터미널을 떠난 순간부터 활주로에 진입하여 이륙을 시작할 때까지도 거의 정확히 15분이 소요된다.

13.
"바탕체 레귤러"라는 서체 이름을 보고는 바탕체 볼드가 아니라
"바탕체 라지"가 순간적으로 먼저 떠올랐다.
요즘 커피를 너무 많이 마셨나 보다....? =_=;;
하긴, 아메리카노가 생각이 안 나서 순간 "아프리카노요"라고 주문을 했다는 사람 얘기도 있으니..;;

14.
몇 년 전부터 우리나라에서는 우측통행, 도로명 주소 등 일상생활과 직접적인 관계가 있는 여러 규범이 바뀌었으며, 이런 차원에서 단위도 비표준 단위가 통상적으로 쓰이던 곳까지 SI 단위가 강제 추진되었다.
고기의 무게는 오래 전부터 '근'이 거의 전멸하고 100그램 단위로 다 정착을 한 것 같지만 여전히 오락가락하는 곳은 부동산에서 다루는 건물이나 땅의 면적이다.

그런데 내가 보기에도 '1평'을 '3.3제곱미터'로 바꿔서 실생활에서 유리한 게 없다. 부자연스러울 뿐만 아니라 음절수도 너무 많아서 발음하기가 불편하다. 바꿀 거면 사람이 실제로 생각하는 넓이의 덩어리도 1제곱미터나 10제곱미터 단위로 업데이트가 돼야 할 텐데.
참, 그나저나 화면의 크기를 표기할 때 으레 쓰이는 '인치'는 센티미터로 바뀌기라도 했는지 궁금하다. 여기도 평이나 근 만만찮게 좀 이상한 단위가 관습적으로 쓰여 온 곳이니까 말이다.

Posted by 사무엘

2015/04/19 08:36 2015/04/19 08:36
, , , , ,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1084

이번에 소개하는 세 개의 고전 게임들은 다음과 같은 공통점이 있다.
  • 지금으로부터 무려 30년도 더 전에 만들어진 엄청난 옛날 물건이다. 나이가 본인과 맞먹는다~!
  • 게임기(오락기 포함)이 아닌 PC용이다. 그래서 비주얼이 겨우 4색 CGA로 맞춰져 있는지라 당대의 게임기용 게임들보다는 그래픽이 다소 초라해 보인다.
  • 본인은 옛날에 컴퓨터 학원에서 구경했던 적이 있다. 그런 인연이 있기 때문에 이렇게 내 블로그에다 소개도 하는 것이다.
  • 개인 작품이다.
  • 프로그램은 롬/카트리지 이미지 따위가 아니라 COM 파일 하나로 존재한다. 그래서 도스박스 정도의 에뮬레이터에서 간단히 실행 가능하다.
  • 딱히 이렇다 할 엔딩이 없다. 단지 인간이 도저히 감당할 수 없을 정도로 게임 진행이 점점 더 빨라지고 어려워질 뿐이다.
  • PC용이지만 그래도 여전히 게임기용 게임을 표방하는지, 실행을 종료하는 명령도 없다.
  • 오늘날은 다들 '리메이크' 작품이 나와 있다. 특히 모바일용으로. 게임 목표와 방식은 동일하지만 그래픽과 사운드를 월등히 더 고퀄로 끌어올려서 말이다.

"아~ 이거! 그때 그랬지" 하면서 공감하는 old-timer들이 많이 계시기를 기대하며 글을 시작하겠다.

1. Paratroopers (1982)

우리는 화면 하단 중앙의 포탑의 각도를 좌우 화살표로 조종할 수 있다. 하늘 위로는 헬리콥터들이 수시로 드나드는데 총알을 맞혀서 떨어뜨려야 한다. 총알을 한 발 쏠 때마다 점수를 1 잃지만 목표물을 맞히면 그보다 더 많은 수의 점수를 얻는다. 단, 0점이라도 총알 보급 자체는 무한임.

사용자 삽입 이미지

가끔은 헬리콥터에서 낙하산을 탄 군인이 떨어지는데 얘는 반드시 쏴 죽여야 한다. 좌나 우 한 방향에 군인이 4명이 생기면 이 군인은 포탑 위로 기어 올라와서 포탑을 부수며 이로써 게임이 끝난다.
또한 주기적으로 헬리콥터 대신 제트기가 날아오면서 폭탄을 일직선으로 투하하는데, 이 폭탄도 요격해야 한다. 안 그러면 포탑은 폭탄에 맞아 박살 난다. 폭탄을 요격했을 때의 점수가 가장 높다.

재미있는 것은 사람의 경우 사람 자체가 아니라 낙하산만 맞히는 게 가능하다는 점이다. 그러면 그 사람은 땅바닥으로 운지-_-하는데, 아래에 다른 사람이 있다면 그 사람도 같이 죽는다. 이것이 포탑 아래에 이미 내려간 군인을 제거하는 유일한 방법이다.

나름 아기자기한 요소가 여기저기 담겼고 상당히 재미있는 시간 죽이기용 게임이다.
다만 실제로 게임을 해 보면 조작이 굉장히 불편하다는 게 아쉬운 점이다. 폭탄 요격도 생각보다 잘 안 돼서 첫 제트기 씬 때 죽어 버리는 경우가 허다하다.
포탑이 돌아가는 속도, 총알이 날아가는 속도도 그리 빠른 편이 아니어서 군인들이 좌우로 사정없이 떨어질 때 신속하게 대응하기 어렵다.

이 게임의 개발자는 폴란드계 미국인인 Greg Kuperberg인데.. 이 사람은 1967년생이다. 즉, 저 게임을 중3~고1쯤 되는 나이일 때 어셈블리어를 혼자 뚝딱거리며 만들었다는 뜻이다. 그리고 이 글에서는 소개하지 않지만, 저 사람은 비슷한 시기에 이것과 비슷한 타입의 다른 게임도 여럿 개발한 경력이 있다.

10대 중반의 나이에 엄청난 프로그램을 개발한 괴수야 이 세상에 한둘만 있는 건 아니니, 이것만으로는 그렇게까지 대단한 이야기가 아닐 수 있다. 하지만 저 사람은 좀 더 무서운 가정사와 내력이 있는데, 바로 부모가 모두 영문 위키백과에 등재되어 있을 정도로 저명한 수학자이다. (대학교 수학과 교수) 그리고 저 사람 자신도 나중에 미국의 유수의 명문대에서 박사 학위를 받은 뒤 나중에 수학과 교수가 되었고, 수학은 아니지만 물리학과 교수인 여자와 결혼했다.

이 정도면 우리나라의 홍 성대 씨에 맞먹는 수학 명문 가문이 아닐 수 없다.
수학 덕후가 만든 덕분에 헬리콥터나 대포가 박살날 때 날아가는 파티클들의 모양과 움직임이 상당히 고퀄이었던 건지도 모르겠다. 다시 말하지만 저건 중삐리~고삐리 급 애가 만든 게임이다.

2. Bouncing Babies (1984)

화면의 왼쪽엔 5층짜리 건물이 온통 불길에 휩싸여 있으며, 미처 지상으로 대피를 못 한 어린 아기들이 수시로 창문에서 떨어진다. 그리고 당신은 안전 낙하용 매트를 든 2인조 구급대원이다. 아기는 한번 매트에 떨어지면 오른쪽으로 세 번 통통 튀는데, 이때도 아기를 매트로 받아서 구급차가 있는 데까지 안전하게 보내야 한다. 게임 진행이 하도 엽기적이어서 머리에서 잊혀지지가 않는다. (걍 구급차를 좀 더 건물에 가까이 주차시켜 놓지 그래..?? 같은 건 묻지 말자..ㅋ)

사용자 삽입 이미지

게임의 기술 수준은 그렇게 높지 않다. 건물의 불은 불꽃 애니메이션이 있는 것도 아니고 그냥 무작위로 불 스프라이트를 xor 연산한 것이 나타났다가 사라지기를 주기적으로 반복하는데, 그래도 기술적인 단순함에 비해 불 같은 느낌이 살짝은 난다. 색깔을 나타내는 숫자의 한 비트만을 xor시킨 것으로 보인다.

또한 구급대는 일체의 스프라이트가 존재하지 않으며, 좌우 화살표를 누를 때마다 좌중우 세 위치 중 하나로 곧바로 워프할 뿐이다. 이 정도 게임은 걍 GWBASIC으로도 만들 수 있지 않을까 싶을 정도.

그리고 그런 의심이 더욱 강하게 드는 이유가 뭐냐 하면.. 이 프로그램은 실행 직후에 불, 아기, 구급대 같은 그래픽만 화면에 잠깐 나타났다가 사라지기 때문이다.
도스 시절의 BASIC 프로그래머라면 이건 화면에 그려진 그래픽 내용을 버퍼에다 저장하는 GET 명령을 호출하는 준비 과정과 유사함을 눈치 챌 수 있을 것이다.

난이도가 올라가서, 한 아기가 완전히 구급차로 가기 전에 또 5층에서 아기가 떨어지기 시작하면 구급대는 그야말로 좌우로 축지법을 써야 하게 된다. 옛날 도스용 라이온 킹 게임의 스테이지 중간 보너스 게임으로 있던 Bug Toss와 비슷한 방식이다.

게임 화면에서 고개를 좀 갸웃거리게 하는 것은.. 잔기를 표시한 방식이다.
저 게임에서 미스는 두 말할 나위 없이, 떨어지는 아기를 하나라도 놓쳐서 땅에 떨어뜨리는 것이다. 그런 사고를 낼 때마다 잔기가 하나씩 줄어들며, 모든 잔기가 떨어지면 게임 오버가 된다.

그런데 게임에서는 그 잔기를 아기 모양으로 표시해 놓았다. 아기 모양은 차라리 한 스테이지당 구해야 하는 아기의 수를 나타내고, 스테이지가 진행될수록 그 남은 수가 줄어들게 하는 게 자연스럽지 않을까? 아기 모양으로 "허용되는 미스의 수"를 표기한 건 좀 직관적이지 못해 보인다.

물론 나도 말은 그렇게 했지만 근본적으로 아기를 떨어뜨린다고 해서 저 구급대원이 당장 다치거나 죽는 건 아니기 때문에, 이런 게임 체계에서는 뭔가 다른 대안을 떠올리기도 쉽지 않아 보인다.

뭐, 이런 게임도 있다 싶어서 소개해 보았다.
개발자는 Dave Baskin이라고 알려져 있으나, 동명이인이 많을 뿐만 아니라 직접적으로 이 게임과 프로필이 연결되어 있는 사람을 찾지 못해서 개발자가 지금은 뭘 하고 있는지 알기가 어렵다.

3. Alley Cat (1983)

그리고 그 이름도 유명한 Alley Cat. 얘는 게임 자체와 개발자 모두에 대해서 본인이 이미 심층분석을 한 적이 있기 때문에 이 글에서 또 상세히 다루지는 않겠다.

비슷한 시기에 나온 위의 두 게임과 비교해 보니 Alley Cat이 당시로서는 창의적인 명작 대작이었는지가 실감이 가지 않는가? (비록 Alley Cat은 전적으로 1인 기획은 아니었고, 다른 사람이 만들던 것을 Bill Williams가 물려받은 형태이지만)
다른 게임에 비해 얘는 일단 길거리, 집안, 최종 보스 퀘스트 등 현실 세계과 초현실 세계를 드나들면서 장면 내지 컨텐츠 자체가 엄청 많이 존재한다.

예전 글에도 적혀 있듯, 이 게임의 개발자는 훗날 게임 업계를 은퇴한 뒤 신학을 시작했다. 그러나 유전병을 갖고 있던 게 도져서 30대 후반의 나이로 세상을 떠났다. 생년과 몰년이 pkzip의 개발자인 필립 카츠와 비슷해서 비교된다는 점까지 언급한 바 있다.

* 그나저나 옛날에는 마우스가 없어도 조이스틱은 있었는지.. 그 시절엔 조이스틱을 어느 포트에다 연결해서 어떻게 썼는지 참 궁금해진다.
도스용 고전 게임들 중에서도 조이스틱을 지원 안 하는 물건은 거의 없다시피했기 때문이다.

Posted by 사무엘

2015/03/05 08:31 2015/03/05 08:31
, , ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1069

« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ... 9 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/10   »
          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:
1674418
Today:
80
Yesterday:
622