1. HTTP 통신 고수준 API

오늘날 운영체제의 GUI API가 qt 같은 별도의 프레임워크가 나온 걸 제외하면 통일된 게 없고(통일이 될 수가 없음..) 그래픽 API가 통합된 게 없듯이..
네트워크, 특히 HTTP/HTTPS 기반 통신 API 역시 내가 아는 한 뭔가 ANSI/ISO 차원의 표준이 나온 게 없이 운영체제마다 다 파편화돼 있는 것 같다. 물론 제일 저수준의 소켓 API는 그럭저럭 표준화가 돼 있지만 오늘날 그것만 써서 밑바닥부터 프로그램을 짜는 건 클라이언트건 서버건 무리이니 말이다. 그러니 Windows, 안드로이드, iOS/macOS마다 또 API를 새로 익혀야 하는 게 다소 번거롭다.

요즘 인터넷에서 다른 프로토콜들은 거의 듣보잡이 돼 가고 HTTP/HTTPS만 남은 것 같다.
통합 라이브러리는 스위치만 달리해서 동일한 정보를 (1) GET와 POST 두 방식으로 간편하게 보낼 수 있으며, 이때 argument를 적절히 배치해 줘야 한다. 전자는 주소에다가 넣고 후자는 헤더에다가 넣어야 할 것이다.

URL 인코딩 처리를 적절히 해 줘야 하며, 바이너리 데이터 덤프를 base64로 인코딩, 또는 디코딩 하는 라이브러리도 덤으로 제공하면 좋을 것이다. post로 보낼 때는 Content-Type, Content-Length 같은 상투적인 헤더를 당연히 자동으로 넣어 줘야 한다.

Windows에서는 메시지를 보내는 방식이 post의 반대가 send인데, HTTP에서는 요청을 보내는 방식이 post의 반대가 get이다. get은 어떤 정보를 얻어 오기만 하는 read-only operation용으로 쓰고, post는 서버다 데이터를 등록하고 변경하고 삭제하는 등 side effect가 남는 요청을 할 때 쓴다. 일단은 그러하지만 홍보가 부족해서 현실에서는 그 용도가 엄밀하게 지켜지지는 않고 있다.

POST 방식 요청의 연장선이겠다만 (2) 다운로드뿐만 아니라 업로드도 당연히 지원해야 할 것이고, 받는 데이터 내지 올리는 데이터는 (3) 메모리, 파일명, 임의의 스트림 형태로 자유롭게 공급이 가능해야 한다. 전부 다 필요하기 때문이다.

그리고 아주 짤막한 파일을 주고받을 때나 UI 없이 그냥 명령줄 프로그램을 만들 때를 대비해서 그냥 (4) 동기형(응답이 올 때까지 block) + 짧은 대기 시간 형태도 지원하고, 별도의 스레드에서 돌아가는 비동기 방식도 자체 지원해야 한다.
비동기 방식은 결과가 왔을 때 콜백 함수 호출 하나로 끝나는 간편한 것을 생각할 수 있고, 한편으로 수십~수백 MB짜리 파일을 주고 받으면서 전송 상태를 늘 확인할 수 있는 복잡한 형태도 생각할 수 있는데, 둘 다 가능해야 한다.

단순 업데이트 체크 같은 건 굳이 지금 당장 안 돼도 상관 없는 것이니 프로그램의 반응성에 영향을 줘서는 안 될 것이다. 스마트폰 앱 같은 게 비행기 모드이거나 3G 데이터를 사용하고 있을 때는 괜찮은데 외부의 희미한 와이파이에 접속해 있을 때는 굼뜨는 경우가 있다. 이런 일이 없어야 할 것이다.

Java는 네트워크 쪽 클래스를 사용할 때는 try catch로 예외 처리가 무조건 돼 있어야 하고 안 그러면 컴파일조차 되지 않는데, 안드로이드에서는 그것도 모자라서 네트워크 통신은 무조건 별도의 스레드에서만 동작하게.. main GUI 스레드에서는 쓸 수도 없게 만들어 놓았다. 네트워크 에러 때문에 프로그램 전체의 동작· 반응이 멎는 걸 원천봉쇄하기 위한 조치인데, 이것 때문에 아주 간단한 소규모 통신에 대해서까지 일일이 스레드 만들고 함수 분리하는 건 번거롭기도 한 게 사실이다.

통신 API로 할 수 있는 일을 생각해 보니 이 정도인 것 같다. 이 모든 상황에 대한 대처가 가능하고 크로스 플랫폼까지 지원한다면 훌륭한 통신 API가 될 수 있을 것이다.

2. Windows CE 프로그래밍

회사에서는 이것저것 찝적대느라 안드로이드, macOS 코코아에 이어 근래엔 골동품인 Windows CE까지 만질 일이 있었다.
도스 기반의 Windows (1985), NT 커널(1993)에 비해 CE는 임베디드 환경을 타겟으로 나름 제일 나중에(1996) 등장했다. PC용 OS들과는 달리 CE는 리얼타임 OS이다.

그리고 CE는 훗날 Embedded Compact라고 이름이 미묘하게 바뀌었다가 2010년대부터 Windows Mobile, Windows Phone 등 스마트폰 OS로 변모하는가 싶더니.. 그냥 Windows 10 자체가 ARM용으로도 나오면서 모바일 분야를 흡수해 버렸다. 또한, 스마트폰 OS는 마소가 판단하기에도 Windows가 안드로이드와 iOS의 적수는 도저히 안 되겠다고 여겨져서 그냥 접어 버리고.. 그 대신 Visual Studio가 무려 안드로이드 개발도 지원하는 식으로, 완전히 다른 형태로 변화하게 되었다.

아무튼, 이 와중에 지금으로서는 좀 구닥다리가 된 Windows CE를 만져 봤다.
GUI에서 본인에게 아주 익숙한 Windows API로 프로그래밍 가능한 건 좋은 점이었다. 단, 같은 API를 사용하더라도 헤더 파일 구조가 PC와 동일하지는 않았으며, 생성되는 바이너리도 비록 PE 방식의 실행 파일이긴 하지만, PC Windows 버전처럼 kernel32, gdi32, user32 이런 DLL들 import가 있지는 않는 게 흥미로웠다.

그 대신 coredll.dll에 API들이 한데 몰빵돼 있는 듯하다. 그리고 메모리 절약을 위해 함수들은 이름이 아니라 ordinal 번호만으로 import하게 돼 있다.

static 라이브러리 같은 걸 만들어도 PC용과 CE 기기용을 동일 소스 기반으로 유지하기는 좀 어려워 보였다. 글쎄, #include 부분에 조건부 컴파일 로직을 정교하게 잘 짜 놓으면 불가능하지 않을지도 모르겠지만.. 거기까지는 잘 몰라서 말이다.
그러고 보니 옛날엔 Visual C++도 Embedded VC++라고 CE 개발 전용 에디션이 있긴 했다가 그건 2000년대 이후로 본가에 흡수됐다.

Visual Basic 6이라든가 Visual C++ 6은 후대 버전과 단절이 커서 꽤 오랫동안 쓰인 개발툴이라는 공통점이 있다. 그런데 Visual C++ 2008도 비슷한 면모가 있다. 바로 Windows Phone이 등장하기 전의 Windows CE 시절, 더 정확히는 Embedded Compact 6.5와 그 이전 버전 레거시 플랫폼의 개발을 지원하는 마지막 버전이라는 것이다.

자동차 내비에서도 이 운영체제가 돌아가는 경우가 있다.
PC용으로 오랫동안 개발되어 온 C++ 코드를 이 플랫폼과 컴파일러용으로 포팅하려다 보니 지금까지 편하게 써 왔던 auto와 lambda, nullptr 따위를 몽땅 구 문법으로 다시 써 주는 불편을 감수해야 했다. 저기서는 2010년대 이후에 새로 도입된 C++ 문법이 지원되지 않기 때문이다.

이 특정 플랫폼만 그런지는 모르겠지만, 인상적인 점은 뭔가 듬성듬성 빠진 함수가 많다는 것이었다. 덩치를 줄이기 위해서 다른 우회 대체제가 있다 싶은 건 몽땅 빼 버린 모양이다.
일례로, DrawText와 ExtTextOut은 있지만 더 단순한 함수인 TextOut은 없다(더 범용적인 대체제가 있으니까..). 파일 시스템도 도대체 뭐 어찌 되는지 GetCurrentDirectory, GetWindowsDirectory 이런 거 없다.

칼질은 C 함수 쪽도 예외가 아니다. 엄연히 ANSI 표준인 time 함수가 없어서 Windows API를 이용한 대체 함수를 직접 만들어야 했다.
그리고 어찌 된 일인지 FILE* 스트림 기반의 fopen 계열 말고, 정수형 파일 핸들을 주고 받는 저수준 _create, open 계열의 함수도 없더라. PC에서 쓰던 코드를 곧장 포팅하는 건 생각만치 쉽게 되지는 않았다.

제일 압권인 건 CE는 9x와는 정반대로.. API 함수에 W 버전만 있고 A 버전이 깔끔하게 없다는 것이었다.
9x는 W 버전도 껍데기는 있지만 실행이 에러 코드와 함께 몽땅 실패한다. CE에서는 A 버전이 컴파일은 되지만 링크가 되지 않고 곧장 실패했다. 1996년에 첫 개발된 신흥 OS이다 보니, 안 그래도 용량도 부족한데 구닥다리 레거시인 A는 처음부터 배제해 버린 셈이다.

Windows CE에는 W만 있고 A가 없다는 건 먼 옛날에 제프리 릭터 아저씨의 책에서 처음으로 봤는데 실제로 그렇다는 걸 그로부터 10수 년 이상 뒤에야 실제로 확인할 수 있었다.

3. 라이브러리의 형태의 변화

도스 시절에 프로그래밍에 필요한 무슨 라이브러리, API, 또는 SDK라 하면..
어셈블리어로 도스의 각종 특이한 인터럽트를 호출해서 하드웨어를 직통으로 건드리는 마우스 라이브러리, 그래픽/사운드 라이브러리, 심지어 한글 라이브러리 같은 게 많았다. 이런 기능들은 타 언어도 지원했지만 가장 먼저는 C/C++용 헤더와 라이브러리의 형태로 제공되었다.

Windows로 넘어가서는 어지간한 하드웨어 제어는 운영체제의 자체 API만 써도 커버가 되니 3rd party 라이브러리 같은 건 필요가 크게 줄어들었다. 그냥 MS Office와 Visual Studio의 외형을 흉내 내 주는 GUI 툴킷이라든가.. 이미지 파일 처리 라이브러리가 쓰였다. 아 그리고, DirectX SDK는 Windows 플랫폼 SDK로부터 완전히 분리 독립했기 때문에 따로 설치해야 하는 물건이 되긴 했다.

그런데 요즘은 그런 API, 라이브러리라는 게 용도와 형태가 바뀌고 있다. PC 안에서 혼자 돌아가는 프로그램이 고차원적인 하드웨어 제어 기능을 사용하는 게 아니라.. 웹사이트나 스마트폰 앱에서, (1) 특정 대규모 서버에서 제공하는 각종 실시간 정보 제공 기능(날씨, 버스와 지하철 위치, 지리 정보 등등)이라든가 (2) 아주 고수준의 인공지능 내지 패턴 인식 기능(이미지에서 사람 얼굴 인식, 음성 인식 등) 같은 것을.. 1인 개미 개발자가 자기 앱이나 사이트에서 곧장 사용할 수 있게 해 준다.

방대한 인공지능 데이터 검색과 계산은 서버가 담당한다. 바둑 AI로 치면 AI 코드가 라이브러리에 담겨 있는 게 아니라, 별도로 돌아가는 알파고 서버와 통신만 하는 거다.
언어는 무겁고 부담스러운 C/C++과는 거리가 멀며, JavaScript, Go, 파이썬 같은 것을 곧장 지원한다.
과금 체계도 과거의 전통적인 형태와는 사뭇 다르다. 비싼 라이브러리 제품을 몇만~몇십만 원 일시불로 지불하고 사 오는 게 아니라.. 월 얼마씩~ 사용 트래픽이 얼마까지는 무료이고 그 뒤부터는 한 건당 얼마 이런 식으로 매겨진다. 구매 대신 임대 형태이다.

기술은 그 자체는 온통 오픈소스다 뭐다 하면서 무료에 가깝게 공개되고 상향평준화되고 있다. Google API의 기능들을 개발하는 데 컴퓨터공학· 전산학 박사들이 얼마나 많이 투입됐을까..? 그 다음으로는 그냥 자본과 데이터 물량전이 대세이다.
그리고 소프트웨어로 돈 버는 건 기술과 기능 자체가 아니라 그걸로 온통 사용자들의 감성을 사로잡고, 자아· 정체성을 표현해 주는 대가로 형태가 바뀌는 것 같다. 온라인 게임의 부분 유료화라든가 각종 아바타가 대표적인 예이고 말이다.

아, 그렇다고 지금이 전통적인 형태로 판매되는 라이브러리· 미들웨어가 전멸했다는 얘기는 아니다. 게임에서 주로 쓰이는 네트워크 라이브러리, 동영상 캡처 라이브러리 같은 것들은 전적으로 로컬에서 기능이 동작하며, 단품 또는 출시되는 제품 타이틀의 규모 단위로 판매되고 있다. 돈을 한번 지불하고 끝인 것도 있고, 일정 주기로 꼬박꼬박 로얄티를 내는 형태인 것도 있다.

4. 함수 호출과 금융의 관계

좀 엉뚱한 생각을 하자면, 금융을 프로그래밍에다가 비유하고 돈이 오가는 걸 함수 호출과 데이터 전달에다가 비유할 수 있을 것 같다.

현금이 오가는 건 데이터 실물을 통째로 스택에다 얹는 call by value이다. 제일 단순하고 확실하지만 거액의 현금을 매번 들고 다니는 건 번거롭고 귀찮고 위험하다.
그러니 현금, 또는 가까운 미래에 들어올 예정인 돈에 대한 포인터가 등장하는데, 이것들이 바로 수표나 어음이다. call by reference가 현실 세계에도 존재하는 셈이다.
부도는 당연히 잘못된 포인터 접근으로 인한 page fault 내지 access violation과 직통 대응이다.

컴퓨터에는 지금 물리적으로 실제로 있는 메모리보다 더 많은 주소 공간을 끌어다 쓰고, 공간이 없으면 디스크 스와핑이라도 하는 '가상 메모리'라는 개념이 있다. 이게 어찌 보면 '대출'과 비슷한 개념으로 보인다.
물론 컴퓨터의 동작에 경제 용어인 '신용'과 정확히 대응하는 개념이 존재하지는 않는다. 그러니 완전 동일하게 대응하지는 않겠지만.. 그래도 이런 식으로 비유해 보면 생각보다 그럴싸하고 씽크가 맞아 보인다.

참고로, 성경이 말하는 헌금 원칙은 철저하게 리얼 모드이다. 빚을 내거나, 없는 돈을 미리 작정하는 보호 모드 가상 메모리 같은 개념은 없다.

5. 보안 정책

오래된 일이긴 하지만 마이크로소프트는 회사가 돌아가는 방식이 2002년 1월 1일 이전과 이후가 서로 싹 달라졌다. 더 엄격한 보안 정책과 더 일관성 있는 제품 지원 주기 정책이 적용되기 시작했기 때문이다.
일단, 이때를 기점으로 해서 모든 마소 제품에서 이스터 에그가 사라졌다. 문서화되지 않은 특정 동작을 하면 프로그램 개발자 명단이 나타나고 숨겨진 게임이나 애니메이션이 뜨는 것 말이다.

그리고 (a) 일반 지원은 제품 출시 후 몇 년 또는 차기 버전이 나온 지 몇 년 중 짧은 기간까지, (b) 연장 지원은 일반 지원이 종료된 뒤부터 5년간.. 요런 식의 규정이 추가되어 오늘날에 이르고 있다. 그와 함께 도스, Windows 3.x/95 같은 구닥다리 제품들은 지금까지 알음알음 지원되어 오던 것이 2001년 12월 31일을 끝으로 지원이 완전히 끊겼으며, 공식적으로 abandonware 판정을 받았다.

인터넷 덕분에 소프트웨어를 배포하는 데 물리적인 장벽은 사라지다시피한 반면, 원격으로 프로그램을 조종하고 컴퓨터를 장악할 수 있는 보안 위협이 커졌기 때문이다. 결국 소프트웨어라는 건 한번 만들고 나서 끝인 게 절대 아니라 계속해서 지원을 해야 하며, 굳이 기능과 컨텐츠에 아무 변화가 없더라도 보안 취약점이 발견되면 계속해서 고치고 지원해 줘야 하는 반제품 정도로 위상이 바뀌었다.

그러니 소프트웨어의 판매 비용에는 이런 잠재적 사후 지원 비용도 포함되어야 하며, 지원을 한도 끝도 없이 영원무궁토록 해 줄 수는 없으니 구체적인 기간이 법적으로 명시될 필요도 생긴 것이다.

그 뒤로 마소에서는 2000년 중반에 프로그램 개발의 기본 블록이라 할 수 있는 C 라이브러리에서부터 보안 결함을 잡겠다고 strcpy, gets 같은 함수들에 칼질을 가했으며, Visual Studio 2005에서 이를 최초로 적용했다. 컴파일러에 /GS 같은 검사 기능도 추가했다.
재래식 도움말인 WinHlp32 엔진은 너무 구닥다리 기능으로 전락한 데다, 이런 새로운 보안 기준을 충족하게 개량을 하기에는 가성비가 너무 안 맞는 관계(시간과 예산..)로 Windows Vista에서부터는 짤렸다.

Vista에서는 프로그램의 실행 주소를 그때 그때 랜덤화하는 보안 기능이 추가되기도 했다. Windows는 애초에 position independent code를 쓰지도 않는 운영체제인데, 오로지 보안을 위해 그 이념을 근본적으로 부정하고 성능을 희생하는 기능을 넣은 것이다.

이렇게 런타임 환경에다가는 예측 불가능한 요소를 일부러 가미한 반면, 빌드 타임 환경에는 정반대의 정책이 적용되고 있다. 같은 소스 코드를 같은 컴파일러 제품으로 빌드했으면 시간과 장소를 불문하고 바이너리 수준에서 언제나 완전히 동일한 실행 파일이 나오게 하자는 것이다. 이름하여 Reproducible builds이다.

단순히 생성되는 기계어 코드를 넘어서 객체들의 명칭과 배열 순서라든가 내부적으로 생성되는 각종 시그니처까지 완전히 똑같게.. 상상할 수 없을 정도로 다양한 환경에서 실행되는 프로그램을 테스트· 디버깅 할 때 문제를 재연하기 어렵게 만드는 변화 요인를 털끝만치라도 줄이겠다는 의도로 보인다.

시범타로 예전에 실행 파일의 헤더 차원에서 timestamp가 들어가던 곳에도 Windows 10에 들어가는 바이너리들은 그냥 고정된 hash값으로 바뀌었다고 한다. 시간이야 난수의 씨앗으로도 쓰일 정도로 매번 달라지는 값이니 말이다.
이렇게 21세기 들어서 세월이 흐를 수록 마소는 내부의 보안 정책이 갈수록 엄격해지는 것이 느껴진다. 그 와중에 실행 주소 랜덤화와 Reproducible builds라는 두 이념이 본인이 보기에 흥미로운 대조를 이루는 듯해 보였다.

Posted by 사무엘

2018/04/13 08:25 2018/04/13 08:25
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1478

Trackback URL : http://moogi.new21.org/tc/trackback/1478

Comments List

  1. 비밀방문자 2018/04/15 14:39 # M/D Reply Permalink

    관리자만 볼 수 있는 댓글입니다.

    1. 사무엘 2018/04/15 17:49 # M/D Permalink

      숙달된 소프트웨어 개발자로 거듭나 있는 가이를 보니 훈훈하다? ㅋㅋ

Leave a comment

코딩을 하다 보면 한 자료형(타입)에 속하는 값 내지 개체를 다른 타입으로 변환해야 할 때가 있다. 아주 직관적이거나(C에서 정수와 enum), 작은 타입에서 큰 타입으로 가기 때문에 정보 손실 염려가 없는 상황에 대해서는 해당 언어의 문법 차원에서 대입이나 함수 인자 전달이 곧장 허용되곤 한다. 바이트 수가 대등하더라도 signed보다는 unsigned가 더 큰 타입이고, 정수보다 실수가 더 큰 타입으로 여겨진다.

그렇지 않고 정보 소실의 여지가 있거나 서로 호환되지 않는 타입에다 값을 집어넣는 건 컴파일러의 경고나 에러를 유발한다. 이 상황에 대비하여 프로그래밍 언어들은 여러 형변환 함수들을 제공하는데, 씨크하게 괄호 안에다가 타입 이름만 달랑 쓰면 형변환 연산자로 인식되는 C/C++이 여기서도 참 유별난 면모를 보이는 것 같다.

형변환이란 건 값의 초기 타입과 목적 타입이 무엇이냐에 따라 내부에서 벌어지는 일이 매우 다양한 편이다.

(a) 없음: LPARAM에서 void*, void*에서 char* 같은 무식한 형변환은 소스 코드상의 의미만 매우 과격하게 바뀔 뿐, 내부적으로 행해지는 일은 전무하다! (클래스 상속 관계를 신경쓸 필요 없는 간단한 것 한정으로)

(b) 그냥 뒷부분 짜르거나 늘리기: int와 char 사이의 변환

(c) 정수와 실수 사이를 변환: 내부적으로 일어나는 일이 분명 간단하지는 않지만, 요즘은 이런 건 CPU 명령 한 줄이면 바로 끝난다. x86 기준으로 cvtsi2sd이나 cvttsd2si 같은 인스트럭션이 있다.

(d) 고정된 오프셋 보정: 단순한 형태의 다중 상속에서 제n의 부모 클래스 포인터를 얻으려면 이런 보정이 필요하다.

(e) 함수 호출: 해당 클래스에다 사용자가 구현해 놓은 operator 함수가 호출된다. 사실, 100과 "100"처럼 숫자와 문자열 사이의 변환도 컴퓨터의 관점에서 보면 이 정도의 cost가 필요한 작업이다.

(f) 상속 계층 관계 그래프 순회: 이건 객체지향 이념 때문에 형변환 연산이 언어 차원에서 가장 복잡해지는 상황이다. 위의 1~5와는 근본적으로 차원이 다르다. 가상 상속 체계에서 부모 클래스를 찾아가거나 dynamic_cast 형변환을 하려면 자기의 타입 정보 metadata를 토대로 주변 클래스 계층 그래프를 O(n) 시간 동안 순회해야 한다(n은 상속 단계).
사용자의 코드가 아닌 컴파일러의 코드만 실행됨에도 불구하고 런타임 가변적인 반복이 발생할 수 있으며, 객체와 메모리 상태가 어떤지에 따라서 형변환 결과가 dynamic하게 달라질 수 있다!

내부적으로 벌어지는 일은 대략 저렇게 분류 가능하고, 겉으로 소스 코드의 의미 차원에서도 형변환의 성격을 몇 가지로 분류할 수 있다.
처음에 C++에는 그냥 C-style cast밖에 존재하지 않았다. 그런데 그랬더니 형변환 연산이 발생하는 부분만 검색으로 뽑아내는 게 어려웠고, 또 단순한 형변환과 좀 위험한 형변환 같은 걸 따져 보기도 어려웠다. 표현 형태가 괄호와 타입 이름이 전부이니까..

그래서 1996~97년경, C++98의 발표를 앞두고 C++에는 길고 굉장히 기괴해 보이지만 용도별로 세분화된 형변환 연산자가 4종류나 추가되었다. namespace, bool, explicit, mutable 이런 키워드들과 같은 타이밍에 도입되었다. C++이 숫자는 몽땅 machine-word int로 어영부영 때우려던 C스러운 사고방식을 탈피하고, 예전에 비해 나름 type-safety를 따지기 시작한 그 타이밍이다. (예: C와 C++에서 sizeof('a')의 값의 차이는?)

새 연산자들은 모두 *_cast로 끝난다. 옛날의 재래식 형변환은 (NEWTYPE)value라고 썼고 C++ 문법으로는 NEWTYPE(value)도 허용되는 형태였다(NEWTYPE이 딱 한 단어 토큰으로 떨어지는 경우에 한해서).
그에 비해 새 연산자들은 *_cast<NEWTYPE>(value)라고 쓰면 된다. < > 안에다가 타입 이름을 쓰는 것은 템플릿 인자 문법에서 유래되었는데 나름 직관적이고 적절한 활용 같다.

1. static_cast

얘는 일상적으로 가볍고 큰 무리 없이 일어나는 일반적인 형변환을 거의 다 커버한다. (1) 큰 타입에서 작은 타입으로(실수에서 정수, UINT에서 int, long long에서 int 등..), 그리고 (2) 범용적인 타입의 포인터에서 더 구체적인 타입의 포인터로(void*에서 타 포인터, 기반 클래스*에서 파생 클래스 포인터) 말이다. 이게 대부분이다.

그리고 형변환 operator 호출이라든가, 다중· 가상 상속으로 인한 포인터 보정도 언어에서 보장돼 있는 메커니즘이므로 알아서 처리해 준다. 정말 대부분의 상황에서 앞서 나열했던 (a)에서 (f)까지, C-style cast를 대체할 수 있는 무난한 연산자이다. 단, f에서 typeid와 RTTI까지 동원되는 제일 비싸고 난해한 기능은 없으며, 이건 나중에 설명할 dynamic_cast가 전담하는 영역이다.

2. const_cast

얘는 값이 아니라 포인터/참조자형에서 C/C++ 특유의 한정자(qualifier) 속성만을 제거해서 더 범용적인 포인터로 만들어 준다. 그러므로 용도가 아주 제한적인 형변환 연산자이다.
C++에서 공식적으로 제공되는 qualifer는 const와 volatile이 있다. 이런 한정자는 가리키는 대상 타입과는 아무 상관 없고, 포인터를 이용해 그 메모리를 접근하는 방식 차원에서 제약을 부여할 뿐이다. 전자는 읽기 전용 속성이고, 후자는 멀티스레드에 의해 값이 언제든 바뀔 수 있음을 대비하라는 최적화 힌트이다.

Visual C++에는 __unaligned라는 확장 키워드도 저것들과 동급인 한정자이다. 이 포인터는 machine word 단위의 align이 맞춰지지 않은 주소가 들어올 수도 있으니 그렇더라도 뻗지 말고 보정하라는 뜻이다(성능 오버헤드 감수하고라도). align 보정을 알아서 너무 잘 해 주고 있는 x86 계열은 전혀 해당사항이 없고, 과거에 IA64를 지원하던 시절에 필요했던 키워드이다. 이것도 포인터 한정자 속성으로서는 굉장히 적절한 예이며, 이런 속성들을 const_cast로 제거할 수 있다.

3. reinterpret_cast

이건 의미론적으로는 제일 무식하고 생뚱맞고 위험하지만 내부 처리는 제일 할 것 없는 형변환 전문이다. (1) 정수와 포인터 사이를 전환하는 것, 그리고 (2) 서로 관련이 없는 타입을 가리키는 포인터끼리 전환하는 것.. 어디 범용적인 함수나 메시지로부터 아주 polymorphic한 데이터를 전달받아서 처리할 때에나 불가피하게 쓰일 법하다.

void*를 char*로 바꾸는 건 static_*으로도 되고 reinterpret_*으로도 된다. 하지만 const char*를 char*로 바꾸는 것은 static_*나 심지어 reinterpret_*로도 안 되고 반드시 const_*로만 해야 한다.
그런데 그래 봤자 reinterpret_*과 const_*는 어떤 경우에도 실질적인 내부 처리는 (a)뿐인(= 없음).. 참 허무한 연산자이다. 실질적인 처리가 없지만 이 숫자값을 해석하는 방식을 변경하는 이유는 분야별로 여럿 존재할 수 있다는 뜻이다.

재래식 C-style cast는 따지고 보면 1~3을 그냥 싸잡아서 구분 없이 수행해 준다. 그런데 가끔 드물게 다중· 가상 상속 관계의 타입 포인터끼리 형변환을 할 때 정석대로 보정 연산을 거친 포인터를 원하는지(static_*), 아니면 이것도 아무 보정 없이 동일한 메모리 주소에서 타입만 바꿔서 해석하고 싶은지(reinterpret_*) 모호해질 때가 있다.

이런 문제도 있고, 또 C++에다가 좀 제대로 된 객체지향 언어의 기능을 뒤늦게 갖추려다 보니 새로운 형변환 메커니즘이 필요해졌다. 이쯤 되니까 형변환 연산자도 별도의 예약어로 도입해서 구분하지 않고서는 도저히 버틸 수 없는 지경이 됐다. 그럼 다음으로 제일 괴물인 형변환 연산자에 대해서 살펴보도록 하자.

4. dynamic_cast

가상 함수를 쓰면 기반 클래스의 포인터를 주더라도 자신이 실제로 속한 파생 클래스에 해당하는 멤버 함수가 알아서 호출된다.
그리고 다중 상속 때 가상 상속을 쓰면, 여러 부모 클래스들이 동일한 조부모 클래스로부터 상속받았을 때 공통 조부모가 한 번만 상속되는 마술(?)이 일어난다. 물론 객체지향 언어에서 유연한 코드 재사용성을 보장하는 모든 마술에는 그에 상응하는 성능 오버헤드가 대가로 따른다는 점은 감안할 필요가 있다.

그런데 과거의 C++은 상속과 함수 호출에서 이렇게 언어 차원의 동적 바인딩이 지원되는 것과 대조적으로, 형변환에는 "동적 바인딩 + 무결성"을 보장하는 메커니즘이 딱히 없었다. 이놈이 A의 파생 클래스이긴 하지만 더 구체적으로 A의 자식들 중에 B가 아닌 C의 파생 클래스가 진짜로 맞는지, 이 멤버에 접근하고 이 함수를 호출해도 안전하겠는지 말이다.

C++은 void*가 있을지언정, 언어 차원에서 모든 클래스들의 공통 클래스(Java의 Object 같은)라는 개념이 없다. 그리고 클래스 내부의 vbtl에 직접 접근한다거나, 가상 함수의 포인터 값을 보고 클래스 종류를 판별할 수 있을 정도로 C++이 ABI가 몽땅 왕창 노출돼 있느냐 하면 그렇지도 않다(겉에는 공통의 썽킹 함수의 주소만 노출돼 있기 때문). 뭔가 어정쩡하다.

그러니 MFC 같은 옛날 라이브러리들은 자체적으로 CRuntimeClass 같은 타입 메타정보를 구비하고, 이놈이 CObject의 파생이긴 하지만 특정 클래스의 파생형이 정말 맞는지 런타임 때 확인하는 함수를 자체적으로 구현해야 했다.
C++이 아무리 C의 저수준 고성능 제어 이념을 계승했다 해도 명색이 객체지향 언어인데 그런 기능조차 없는 건 좀 아니라 여겨졌는지, 훗날 언어 차원에서 타입 식별 정보와 전용 형변환 연산자가 도입됐다. 그 결과물이 바로 dynamic_cast이다.

함수도 virtual, 상속도 virtual인 걸 감안하면 얘의 이름은 기술적으로 virtual_cast라 해도 과언이 아닐 듯하다. 하지만 static_* 이라는 단어가 이미 있으니 그것보다 더 값비싼 형변환이라는 의미로 dynamic_*이라는 이름이 최종적으로 붙었다. static_*은 이놈이 진짜 조상 관계가 맞는지 확인하지 않고 그냥 O(1) 복잡도짜리 기계적인 오프셋 보정만 해서(필요한 경우) 파생 클래스로 형변환해 주는 반면, dynamic_*은 타입 식별자를 직접 확인까지 한다는 것이다.

가상 함수의 구현을 위해서는 함수 포인터 테이블과 테이블의 포인터(멤버)가 필요하고, 가상 상속의 구현을 위해서는 기반 클래스의 포인터(멤버)가 필요하다. 그것처럼 동적 바인딩 형변환을 구현하려면 클래스 이름과 계층 관계를 기술하는 메타데이터와 함께 그놈의 포인터(멤버)가 필요하다.

가상 함수와 가상 상속 지원을 위한 데이터는 비공개로 꽁꽁 감춰져 있는 반면, 동적 바인딩 형변환을 위한 타입 식별자 데이터는 공식적으로 스펙이 공개돼 있고 일반 프로그래머들이 언어 요소를 통해 접근할 수 있다. 일명 RTTI (run-time type info)이다.
#include <typeinfo>를 한 뒤 typeid() 연산자로 const type_info&라는 구조체, 아니 클래스를 들여다보면 된다. typeid는...

  • sizeof와 마찬가지로 오버로딩 할 수 없다.
  • sizeof와 마찬가지로 타입 이름과 일반적인 값을 모두 받을 수 있다. 단, sizeof는 값이 올 때는 괄호를 생략할 수 있는 반면, typeid는 그렇지 않아서 언제나 뒤의 피연산자를 괄호로 싸야 한다.
  • sizeof는 결과값이 무조건 정적 바인딩으로 구해지는 반면, typeid는 바인딩이 정적과 동적 사이에서 어정쩡하다. 피연산자가 타입 이름이거나, 값이더라도 int 같은 primitive type 내지 상속이고 가상 함수고 아무것도 없는 구조체라면.. sizeof와 마찬가지로 수식을 실제로 evaluate하지 않는다. 그러나 뭔가 상속 관계 규명이 필요하다 싶은 개체라면 런타임 계산이 행해진다.

쉽게 말해 typeid는 MFC로 치면 obj->GetRuntimeClass()와 RUNTIME_CLASS(classnam)의 역할을 혼자 모두 수행한다는 뜻이다.
그럼 관련 타입들에 대해 DECLARE_DYNAMIC 내지 IMPLEMENT_DYNAMIC도 어딘가에 행해져야 할 텐데, 그건 C++ 컴파일러가 typeid 연산자가 쓰인 곳을 총체적으로 따져서 알아서 처리해 준다.

이런 RTTI 기능은 대다수의 C++ 컴파일러에서 사용 여부를 옵션으로 지정할 수 있게 돼 있다.
RTTI를 사용한 상태에서 dynamic_cast를 사용하면 실제 타입이 그게 아닌데 그 파생 타입으로 형변환을 시도하는 경우.. 피연산자가 포인터였다면 NULL이 날아오고, null이 가능하지 않은 참조자를 줬다면 예외(exception)를 날리게 된다.
이것도 다중 상속까지 생각한다면 상속 관계 그래프를 타고 오프셋을 보정하는 알고리즘이 가히 판타지가 될 것 같다.

이상.
객체지향 언어라는 게 그냥 구조체에다가 this가 자동으로 전달되는 함수가 같이 딸려 있고, 상속에 다형성 정도 지원되는 게 전부라고 생각하는 게 얼마나 순진한 생각인지 알 것 같다.
PC 환경에서 C를 초월하여 C++이 보급된 게 1990년대 초쯤인데, 이 무렵에 템플릿과 다중 상속도 도입됐다. 처음부터 있었던 게 아니다. 그리고 그때부터 C++은 뭐랄까, 괴물 같은 복잡도를 자랑하는 치떨리는 언어로 변모한 것 같다.

구리고 지저분한 면모가 많지만 그래도 그 정도 객체지향 이념에다가 고성능 저수준 제어까지 이만치 잡은 건 얘가 C++이 가히 독보적인 것 같다.
그러니 형변환 연산자도 언어를 따라 이렇게 복잡해진 것이다. 일례로, Java는 final이 있을지언정 포인터도 없고 const니 volatile 같은 건 신경 쓸 필요도 없는데 뭐 저런 구분이 필요하겠는가? 그러니 지금도 여전히 C-style cast만으로도 충분한 것이다.

Posted by 사무엘

2018/03/25 08:30 2018/03/25 08:30
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1471

Trackback URL : http://moogi.new21.org/tc/trackback/1471

Leave a comment

1. Java 언어가 쓰이는 곳

Java는 C++과 달리 로컬 환경용으로는 그다지 재미를 못 본 언어 및 런타임 환경이다.
콘솔(게임기 말고, 명령 프롬프트..)용 프로그램이 Java로 만들어진 건 거의 못 봤다. 오히려 Java는 한때는 표준 입력으로부터 숫자 한 줄 입력받는 것조차도 온갖 패키지를 import하고 예외 처리 try catch까지 갖춘 뒤에야 가능한 불편한 언어였다.

GUI(프레임워크 이름이 Swing이던가?)로 넘어오면 VirtualBox나 OpenOffice처럼 일부 크로스 플랫폼 프로그램이 GUI 껍데기를 Java로 만든 경우가 좀 있다. (Windows 한정으로는 C#의 Windows Form와 경쟁?) 아, 직장에서 일정 관리 용도로 사용하는 ProjectLibre도 흔치 않은 Java 기반 로컬 GUI 프로그램이다.
하지만 Java가 제공하는 GUI는 외형이 네이티브 GUI에 비해 이질적이고 느리고 런타임 오버헤드가 커서 범용성 말고는 가성비가 좋지 않았다.

한편, Java는 애플릿(Applet)이라는 이름으로 웹(클라이언트)에서 돌아간 적도 있다. 웹에서 꽤 고차원적인 수학 그래픽, 화면 왜곡과 전환 애니메이션, 시뮬레이션(특히 교육용) 등을 출력할 목적으로 플래시와 경쟁하는 구도로 한때 쓰였으나.. 그것도 다 지나간 일이다. 현재는 망했으며, 개발사로부터 지원도 끊긴 지 오래다.

오늘날 Java는 로컬 PC가 아닌 안드로이드 앱, 그리고 jsp 기반 서버사이드 언어(웹 서버)로 회생해 있다.
뭐, Java 런타임을 컴퓨터에 설치해 보면 설치 중에 '전세계 수십억 개의 기기가 Java를 기반으로 돌아가고 있습니다'라고 자랑하는 문구가 뜨기도 하는데, 그것도 임베디드보다는 모바일을 말하는 게 아닌가 싶다.

Java는 오늘날 그렇게 됐고 로컬 PC 환경에서는 지금도 수많은 프로그래밍 언어들이 난립해 있지만, 웹에서는 그야말로 Java에서 이름만 빌려온 JavaScript로 대동단결 천하통일이 이뤄진 게 신기하기 그지없다.

2. 새로운 언어

애플에서 Objective-C에 한계를 느끼고 Swift라는 언어를 만들었더니,
그에 질세라 안드로이드 진영에서도 Java 대신 '코틀린'이라는 완전히 다른 언어를 만들었다. 왕년에 C++ 컴파일러를 열심히 만들었던 사람이 D 언어를 개발했듯, Java 기반 안드로이드 개발 환경을 열나게 만들었던 JetBrains라는 회사에서 전용 언어도 만들고 이를 Google에서도 채택한 것이다.

오늘날 베이직은 마소에서밖에 만들지 않는 언어가 됐고, 파스칼은 그냥 델파이의 전유물이 됐고 이제는 델파이라는 이름 자체가 RAD 툴 겸 프로그래밍 언어의 이름으로 등극했다. 언어가 워낙 많이 마개조됐기 때문이다. 또한 옵씨의 경우는 애초부터 애플이 언어에 대한 일체의 권리를 언어 고안자로부터 사 버려서 사유화했다.
저런 언어들에 비해, C/C++은 너무 심하게 파편화가 됐을지언정--언어 문법 자체보다는 라이브러리나 ABI 계층에서--, 특정 기업에 의해 좌지우지된다는 느낌은 상대적으로 덜 든다.

Visual Studio 등 요즘 IDE들은 프로젝트 전체에 존재하는 클래스들을 쭉 보여주는 기능이야 당연히 기본으로 갖추고 있다. 그런데 클래스들을 namespace 계층 + 이름의 알파벳 순으로만 보여주는 게 아니라, 기반 클래스별로 분류해서 보여주는 기능이 있으면 프로젝트들의 성격을 파악하는 데 더 도움이 될 것 같다. 그러면 그 클래스들의 성격을 파악할 수 있으니 말이다.

3. 간단한 자료형과 복잡한 자료형 or 클래스 객체

오늘날 객체지향을 표방한다는 많은 고급 언어들이 int 같은 (1) primitive type과 (2) 클래스 객체, 혹은 (1) 스칼라와 (2) 복합 자료형(리스트 같은)을 서로 구분해서 다루고 서로 다르게 취급한다. 함수 인자와 리턴값을 주고받을 때 (1)은 값을 그대로 전달하고 (2)는 메모리에 한 인스턴스만 둔 뒤 주소값만 주고받고 레퍼런스 카운팅을 하는 것이 대표적인 차이점 되겠다. Java, 파이썬 등 여러 언어들이 이런 정책을 사용한다.

순수 극한 객체지향 언어 중에는 1과 2의 구분조차 없애고 모든 것을 객체로 취급하여 타입 식별자라든가 기반 클래스 소속을 부여하는 물건도 있다. 하지만 그렇게까지 하기에는 속도와 메모리 오버헤드가 너무 크고 실용성도 떨어지니 많은 언어들이 최소한의 primitive type 정도는 허용하는 타협을 한다.

C++이야 어느 타입이건 어느 방식으로 전달할지(값, 주소/참조)를 몽땅 명시적으로 수동 지정이 가능하다. 그러나 포인터를 노출하지 않는 언어에서는 그런 구분이 프로그래머의 지정 없이 자동으로 행해진다. 포인터가 없는 언어라고 해서 포인터가 원래 하던 일 자체를 안 하는 것은 전혀 아니니까 말이다.

그런데 1과 2의 얼추 중간쯤에 속하는 물건은 문자열, 그리고 단순 구조체 정도다.
문자열이야 언어 차원에서 상수 리터럴도 존재하고 정말 기본 자료형과 복합 자료형의 중간에 속하는 독특한 물건인지라, 각 언어와 라이브러리마다 구현 형태가 제각각이다.

그리고 생성자, 소멸자, 상속, 가상 함수 따위 전혀 없고 레알 int 같은 primitive type의 묶음으로만 이뤄진 레알 C 스타일 구조체를 프로그래밍 용어로는 POD(plain old data)라고 한다. C++의 경우 POD 구조체만이 중괄호 { }를 이용한 멤버 별 값 초기화가 가능하다.
물론 POD도 개당 수십~수백 바이트를 차지하는 덩치 큰 놈이 될 수도 있지만 이는 논외로 하고..

단순 구조체를 클래스와 구분시킨 것은 C#의 신의 한수로 보인다. 사실, POINT, SIZE, COMPLEX(복소수)처럼 숫자 둘로만 달랑 이뤄진 간단한 구조체는 상속이 뭐고 없고 함수 인자도 그냥 값 형태로 전달하고 싶은 그런 물건들이니 말이다.

4. sizeof 연산자가 없음

개인적으로 Java를 쓰면서 C++에 비해 굉장히 특이하다고 오래 전부터 생각했던 점은..
가장 먼저, (1) int를 함수에다 주소/참조로 전달을 할 수 없어서 swap 함수를 구현할 수 없다는 것이다. int는 무조건 값으로만 전달되니 말이다.

(2) 클래스에 소멸자라는 게 없다 보니, 메모리는 GC 덕분에 뒷일 생각할 필요 없이 new만 늘어놔도 되는데 파일은 닫는 코드를 수동으로 매번 써 줘야 하는 게 처음엔 아주 웃기게 느껴졌었다.

(3) 그리고 끝으로.. sizeof 연산자가 없는 것에서 한번 더 경악했다. 수동 메모리 할당이 없고 포인터도 없고, sizeof마저 없다는 건 어떤 개체의 메모리 내부 덤프 같은 건 꿈에도 생각하지 말라는 얘기다.
primitive type이야 개별 크기가 어떤 기기의 JVM에서도 불변 동일하니(가령, int 4바이트, long 8바이트..) 굳이 sizeof에다 요청하지 않아도 되고..

하긴, 특정 개체의 메모리 주소 같은 걸 어디에다 낼름 누설해 줄수록 프로그램의 엔트로피가 커지고 Garbage collector가 추적해야 하는 영역이 넓어지고, 메모리 누수와 잘못된 포인터 에러가 날 확률이 높아지니.. 그런 건 최대한 애초에 할 필요가 없게 만들어야 할 것이다.
하지만 바이너리 덤프를 바로 못 하면 파일을 읽고 쓰는 작업도 좀 불편할 것 같다. 하다못해 과거에 베이직조차도 포인터는 없어도 숫자의 binary dump를 문자열 형태로 얻거나 그걸 디코딩하는 함수는 있었거늘 말이다.

C#은 Java처럼 가상 머신 기반에 자동 메모리 관리가 제공되는 언어이지만 이런 것들이 Java보다는 융통성이 있다. ref라는 키워드가 있어서 primitive type도 call by reference가 가능하다.
그리고 sizeof 연산자가 제한적으로 지원된다. primitive type과 단순 구조체 한정으로만 사용 가능하며, 자동 관리를 받는 자기 객체(managed class)에 대해서는 sizeof를 여전히 할 수 없다.

C#의 초창기 구버전에서는 아예 unsafe 코드 안에서만 sizeof를 사용할 수 있었지만 나중에 제약이 완화되었다.
그래도 C#과 Java 어느 경우든, sizeof라는 건 저수준 메모리 접근과 관계가 있는 기능이지, 가상 머신 고수준 코드와는 어울리지 않는 건 공통인 듯하다.

5. 객체의 배열

그러고 보니 Java는 클래스 객체들이 다 기본적으로 포인터 단위로 취급된다는 특성상, 객체의 동적 배열을 만드는 것도 좀 불편하다.

MyObject[] arr = new MyObject[n];

이건 MyObject들을 담을 배열 객체부터 하나 만드는 것이다. 그 뒤에 arr[0]부터 arr[n-1]에다가 MyObject의 인스턴스를 new로 할당하는 건 사용자가 또 직접 해야 한다.
C++이야 Java처럼 행동하고 싶으면 MyObject **arr을 하면 되고, 아니면 MyObject가 default 생성자만 있다면 곧장 MyObject *arr = MyObject[n]으로 객체의 배열을 만들 수 있으니 융통성이 있다.

그리고 한 객체가 여러 클래스들을 돌아다니면서 쓰이다 보면, 이 오브젝트가 값만 일치하는 게 아니라 본질적으로 그 오브젝트가 맞는지.. C++로 치면 주소값이 같은지, Java조차도 문자열은 equals 대신 ==를 써서 행하는 그 비교 대상값이 일치하는지.. 주소를 직접 확인하고 싶은 경우가 있다.

C/C++은 & 연산자가 있으니 일도 아닌 반면, Java는 디버거 창이 아닌 로그 확인을 위해서는 toString을 일일이 해 줘야 하는 것이 불편한 점으로 남는다.
포인터라는 게 위험하다고 직접 노출을 금기시하다 보니, 포인터로 직통으로 할 수 있는 일까지 좀 불편하게 바뀌는 건 어쩔 수 없나 보다.

6. 클로저

C++은 수동 메모리 관리뿐만 아니라 pointer-to-member(더 나아가 함수 포인터라는 것 자체까지)라는 것도 오늘날의 타 언어들이 제공하는 깔끔한 클로저와는 전혀 관계 없는 원시적이고 지저분한 물건이다. C/C++은(정확히는 C가) machine word를 정말 좋아하는 언어이며, '포인터' 하나만으로 간편하게 구현 가능하지 않은 요소는 쿨하게 제공 안 하는 게 전통적인 설계 철학이었다.

그러니 함수 안에 함수를 만드는 걸 지원하지 않으며(당대의 경쟁 언어이던 파스칼과 달리), C++도 클래스 안에 클래스, 함수 안에 지역 클래스 같은 건 전적으로 접근성 scope 구분만 할 뿐, 자기 밖에 있는 클래스 멤버나 함수 지역변수에 자동으로 접근하는 메커니즘 같은 건 제공하지 않는다. 즉, Java 용어로 말하자면 static class만 지원한다는 것이다.

C++만 쓰다가 Java나 Objective-C 같은 타 언어에서 this 내지 상부 클래스 멤버에 접근 가능한 함수를 스레드 콜백 등으로 자유자재로 넘겨줄 수 있는 걸 보니 아주 신기했다. 요즘은 함수형 언어 영향을 받아서 함수 몸체를 이름조차 안 붙이고 바로 넘겨줘도 되니 더 편하다.

이것도 타 언어들이 더 객체지향 철학에 따른 것이고, C++이 기괴하고 경직된 구조의 언어인 셈이다. 물론, C++의 사고방식은 저런 유연한(?) 함수 포인터(C++ 용어), 셀렉터(옵C 용어), 클로저(???)를 구현하기 위해 내부적으로 부과되는 시공간 성능 오버헤드가 무엇인지 생각하는 데는 도움이 될 듯하다.

C++은 저게 없는 대신에 P2M을 갖고 있는 셈인데.. C++의 또 다른 괴물 기능인 다중 상속과 연계하려다 보니 P2M도 도저히 '날포인터' 하나만으로 간편하게 구현할 수가 없어졌으니 참 아이러니이다. 이건 언어 설계 차원에서의 결함이나 마찬가지라고 봐도 할 말 없을 정도이며, 이와 관련하여 본인이 몇 년 전에 글을 쓴 적이 있다.

그나저나 Java의 상속 "extends A"는 C++로 치면 ": public A", 다시 말해 언제나 public 상속과 같은 것이겠지?
난 부모 멤버들에 대한 접근에 더 많은 제약을 가하는 private, protected 상속은 사용해 본 적이 없다.

7. 자동 메모리 관리, 동적 배열 등, 나머지 생각들

뭐, 직장에서 Java 개발도 좀 해 보니 깔끔한 1파일 1클래스 구조에다 헤더와 소스 구분이 없고 코드 파싱과 빌드가 정말 광속인 것(C++ 외의 타 언어들이 대부분 그렇지만), throw IllegalArgumentException("value must be >=0") 예외 처리가 사실상 assertion failure이나 마찬가지이니 assert(0 && "error") 이런 테크닉이 없어도 되는 것들은.. 마음에 든다.

ABI 계층이 파편화 없이 딱 잘 통합돼 있고, 무식한 헤더 파일 대신 패키지로부터 추출· 복원된 프레임워크 소스와 코딩 컨벤션.. 매번 다시 컴파일 되면서 특정 타입과 완전히 결합해 버리는 C++의 템플릿 대신에, 진짜로 유연한 void*를 캡슐화했다고 볼 수 있는 제네릭.. 이런 건 부럽기도 하고 현대의 프로그래밍 언어와 프로그래밍 환경이 얼마나 발전했는지를 뒷북으로나마 느낀다.

프로그래밍에서 "네이티브 코드 + 메모리 100% 수동 관리"(C/C++) 아니면 "가상 머신 + garbage collector 기반의 메모리 자동 관리"(C#/Java)의 차이는, 자동차 운전으로 치면 수동 vs 자동 변속기와도 비슷할 정도로 큰 차이인 것 같다. 자동차에서는 면허 조건이 달라질 정도로 큰 차이를 만들며, 프로그래밍에서도 뒷일 생각 안 하고 마음대로 new를 남발해도 되냐 그렇지 않느냐의 차이는 매우 크다.

(그럼 메모리가 자동 관리되는 언어에서는... 무슨 서버나 GUI 프로그램이 아니고 일체의 아이들 타임이 없이, 자기 할 일만 일괄 처리하고 끝나는 콘솔(명령 프롬프트)+단일 스레드 프로그램이라면 GC가 언제 어떻게 개입하여 동작하는지 의문이 든다. 뭐 그냥 메모리 할당 부분에서.. 자원 반납 없이 지금까지 메모리를 사용한 양이 도를 넘어선다 싶으면 그때 동작할 수도 있긴 하겠다.)

C++을 까는 사람들의 심정은 이해한다. 하지만 C++이 그렇게 지저분하고 자비심이 없는 대신에 어떤 넘사벽급의 강력한 네이티브 코드를 생산할 수 있는지, 그리고 Java가 편한 대신에 내부적으로 성능을 얼마나 많이 희생했고 런타임 오버헤드가 더해졌는지를 전부 논하지 않고 단편적인 비교만으로 언어 호불호를 논하는 것은 바람직한 태도가 아니라고 여겨진다. 둘 다 장단점이 있고 고유한 주 용도가 있는 법이다.

옛날에 잠깐 써 봤던 파스칼은 포인터도 있고 자유로운 call by reference도 지원했지만 그 포인터가 C처럼 막강하고 배열과 연계되는 건 절대 아니며, 동적 배열을 못 만들었다. 아무리 파스칼이 교육용 언어를 표방하고 만들어졌다 해도 베이직으로도 가능한 기능이 없는 건 말이 안 되니 저건 후대의 파생 언어에서 개선되었지 싶다.

Posted by 사무엘

2018/03/13 08:34 2018/03/13 08:34
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1467

Trackback URL : http://moogi.new21.org/tc/trackback/1467

Comments List

  1. 비밀방문자 2018/03/15 00:46 # M/D Reply Permalink

    관리자만 볼 수 있는 댓글입니다.

    1. 사무엘 2018/03/15 06:46 # M/D Permalink

      그렇다? 이클립스(자바)를 능가한 이후로
      과연 근성으로 Visual Studio IDE와 Source Insight (C++)의 영역까지 넘보고 있구나?
      C++은 (1) 골치 아픈 전처리기, (2) 헤더와 몸체의 분리, (3) 그러면서 번역 단위와 클래스 사이에는 호응 관계가 전혀 없는 점으로 인해 C#, Java 수준의 구문 분석과 리팩터링 기능은 제공하기 꽤 난감한 언어였는데 그런 한계마저 넘어서고 있는 듯하다?

  2. 허국현 2018/03/16 15:51 # M/D Reply Permalink

    Atwood's Law라는 것이 있습니다. Stack Overflow 창립자인 Jeff Atwood가 한 말인데요.

    JavaScript로 작성될 수 있는 것은 JavaScript로 작성될 것이다.

    라는 법칙입니다.

    Node.js로 JavaScript를 웹 브라우저 밖으로 빼 내더니 이제는 JavaScript로 별걸 다 만드네요. Visual Studio Code도 JavaScript로 만들었습니다. Electron + TypeScript + React로 알고 있습니다.

    1. 사무엘 2018/03/16 17:37 # M/D Permalink

      스크립트란 게 웹페이지에서 간단한 계산 결과 같은 거 찍고, 폼의 입력값 범위 검증해서 메시지박스나 찍는 용도로
      그것도 HTML 주석 안에다가 몰래 집어넣는 물건이던 시절이 엊그제 같은데...
      지금은 정말 못 하는 게 없는 괴물로 성장했지요. 경악스럽습니다. ㄷㄷ

Leave a comment

1.
10여 년 전, 본인이 MMORPG 게임을 개발하던 회사에서 병특 복무를 하던 시절에는 주된 업무 주문이 기존 제품을 WOW와 더 비슷하게 고치는 것이었다. 그 당시에 WOW가 인기가 장난이 아니었기 때문에..
지금은 회사에서 어쩌다 보니 안드로이드 앱을 개발하게 됐는데, 주된 작업이 기존 제품을 다른 유명 SNS 앱과 더 비슷하게 고치는 것이다.

세상은 유행이 변하고 이런 식으로 돌고 도는 것 같다. 20년쯤 전에 Codeguru 같은 사이트에서 MFC CWnd 클래스를 상속받아서 온갖 기발한 UI 컨트롤 내지 MS Office 스타일의 도구모음줄을 만들어 올리고 테크닉을 공유하는 게 유행이었다면.. 지금은 안드로이드에서 더 현란하고 기가 막힌 화면 전환, GUI 컨트롤을 만드는 게 유행의 뒤를 물려받아 있다. 또한 소스포지라든가 다른 사이트들은 다 망하고 개발자 관련해서는 오로지 스택 오버플로우와 github만이 본좌이다..

요즘은 소프트웨어로 엔드 유저로부터 수익을 내는 방식이 "특정 기술과 기능, 컨텐츠 자체에 대한 접근성" 자체는 아니어 보인다. 기술과 기능, 컨텐츠는 이제 너무 넘쳐나고 저렴해진지라, 정말 획기적이고 새로운 게 아니면 그닥 변별이 안 되는 것 같다. id 소프트웨어가 1990년대 옛날처럼 없던 그래픽 기술을 새로 개발하고 선보이면서 주목받지는 않고 있는 것을 생각하면 된다.
그 대신 요즘은 다들 모바일에서 다들 내 자신의 정체성을 표현하는 데 드는 대가로 수익을 내는가 보다. 이모티콘, 아바타 같은 것 말이다.

2.
카카오톡에서 그냥 있으니까 정말 아무 생각 없이 기본 이모티콘들을 지금까지 써 왔다.
라이언인지 뭔지 알 게 뭐야? 난 그냥 개그만화 보기 좋은 날의 '쿠마키치'=_=;; 짝퉁이라고 생각해 왔는데.. 알고 보니 사자였구나. 갈기 없는 숫사자랜다~ ㅋㅋ

카카오프렌즈 이게 사이버 공간을 떠나서 봉제인형과 각종 캐릭터로 로얄티 받으면서 그야말로 돈을 빗자루로 쓸어담고 있다고 한다. 우리나라는 둘리· 호돌이처럼 옛날에 히트 쳤던 걸 제외하면 캐릭터 지지리도 못 만드는 나라인 걸로 본인은 알고 있는데..-_-;; 어째 이걸로도 돈줄을 성공적으로 텄구나.

영화나 만화처럼 뭔가 스토리가 있는 매체에서 유래된 캐릭터가 아니고,
앵그리버드의 동그랗고 눈썹 짙은 빨간 새처럼 인기 게임에서 유래된 것도 아니고..
그저 채팅 앱의 이모티콘에서 유래된 캐릭터가 이렇게 초대박을 치리라고는 난 절대로 예상할 수 없었다.

한낱 아스키 아트에 불과하던 이모티콘이란 게 그 다음으로는 찐빵 얼굴에 기하학적이고 추상적인 기호, 픽토그램 수준이었다가 이제는 거의 움짤 수준으로 변모하고 있다.
그리고 이게 말을 직접 하기 난감할 때, 얼굴 표정과 므흣한 감정을 대신 전달하는 용도로 생각보다 유용하기도 하다.

그리고 유튜브 동영상의 썸네일 이미지도 있다. 그냥 동영상의 임의 구간 스틸 영상을 썸네일로 지정하는 게 너무 당연하다고 생각해 왔고 문제 의식을 하나도 느끼지 않고 지냈는데.. 이것도 글자와 그림을 넣어서 귀신 같이 꾸며 주는 앱이 있다...;;

난 그냥 날개셋이나 우직하게 만들고 논문 써야지, 미래의 시장 판도를 예측하고 유행을 읽고 돈 벌 아이템 찾는 사업가 기질은 정말 아닌 것 같다.. ㅠㅠ

그나저나 애니메이션 이모티콘들은 gif도(꼴랑 256색) 아니고 플래시도 아니고(모바일에서 망함..) 도대체 무슨 기술을 써서 표현하는지 궁금해진다. 애니메이션 png 규격이 완성되기라도 했나..?

3.
프로그래밍 환경 내지 플랫폼을 처음부터 오랫동안 접하면 API나 방법론이 수시로 바뀌는 것 때문에 귀찮고 지저분한 일을 많이 겪게 된다. 안드로이드 내지 Cocoa API에서 숱하게 나오는 deprecated 경고들을 보니 그런 생각이 더욱 절실히 든다. 이러니 인터넷에 굴러다니는 코드들을 아무거나 선뜻 믿고 쓸 수가 없다.

그런 시절을 몽땅 건너뛰고 모든 게 그럭저럭 갖춰지고 안정화된 뒤에 프로그래밍을 시작하면 지저분한 일을 겪지는 않는다.. 하지만 이젠 모든 게 다 갖춰진 너무 방대하고 복잡한 프로그래밍 시스템 속에서 방황하게 된다. 오늘날의 웹 내지 앱 개발 환경과 30여 년 전 GWBASIC 내지 끽해야 도스 API 인터럽트 프로그래밍 환경은 얼마나 극과 극으로 다른가?
Windows는 그나마 초딩 시절부터 내가 오랫동안 써 왔으니까 익숙해진 것이지, 내가 2, 30년쯤 뒤에 늦게 태어났으면 프로그래밍을 진로로 정하지 않았을 가능성이 높아 보인다.

옛날에는 컴퓨터 성능이 빈약하고 각종 소프트웨어 시스템도 지금보다 훨씬 더 단순했겠지만.. 그게 아무 이유 없이 단순한 건 아니었다. 성능 대비 기계값이 지금보다 훨씬 더 비싸고 프로그래밍 관련 정보를 구하기도 더 어려웠다. 금수저 내지 최소한 중산층 집안이 아니면 아무나 컴퓨터를 접할 수 없었으며, 프로그래밍 저변이 지금처럼 널리 확대될 수 없었다. 그때나 지금이나 프로그래밍 여건에 관한 한 일장일단이 있다.

그 최첨단 문명의 이기인 컴퓨터가 그래도 기업· 연구소· 군대· 정부 기관의 전유물이 되지 않고, Google 같은 엄청난 검색 엔진이 부자들의 전유물이 되지 않고, 만민에게 정보 접근성이 주어지고 차별이 사실상 없어진 것은 매우 다행이고 축복이어 보인다. 비록, 그 반대급부로 어린애들에게 음란물과 폭력물에 대한 접근성까지 너무 올라간 것은 좀 심각한 문제이지만 말이다.

이건 컴퓨터가 진지하고 심각한 일뿐만 아니라 엔터테인먼트 도구로도 활용해도 돈벌이가 되니까 자본주의 내지 시장 경제 논리에 의해 대중화가 된 것일 뿐이다. 돈줄을 따라 자연스럽게 이뤄진 현상에 대해서 너무 지나치게 염세주의 음모론적으로 해석할 필요는 없을 것이다.

컴퓨터가 워낙 비싼 기계이니까 소수의 엘리트에게만 기회를 주는 게 아니라, 일단 컴퓨터 자체는 팍팍 뿌린다. 대량생산으로 가격을 낮추고 온갖 교묘한 우회 결제 수단으로(= 일시불로 기계값을 몽땅 내지 않아도 되게 오랫동안 찔끔찔끔..) 소비자 부담을 줄여서 말이다. 그 뒤 온갖 컨텐츠들로 더 많은 수익을 내는 게 소비자에게도 좋고 생산자에게도 좋은 것이다.

4.
미국이나 이스라엘, 인도 같은 나라 말고 유럽에서 나름 세계구급 IT 강국을 꼽자면 노키아와 리누스 토르발스를 배출한 핀란드가 떠오르는 편인데.. 옛날에는 불가리아도 한 끗발 했었다.
우리나라에서는 비슷한 이름의 요구르트 때문에 "생명 연장이라는 게 요구르트만 딥다 쳐먹는다고 되는 게 아닙니다" 같은 개드립의 원산지라는 이미지가 강한 편이다.;;

하지만 저 나라는 요구르트만 개발한 게 아니라, 1980년대에 국가적으로 컴퓨터 교육을 실시하고 나름 고급 IT 엔지니어 육성을 했다.
1989년 5월에 제 1회, 국제 정보 올림피아드라는 게 최초로 개최된 곳도 미국이나 다른 유명한 나라가 아니라 바로 '불가리아'였다. 이 역시 생각할 점이다.

그런데 문제는 그렇게 양성된 컴퓨터 똘똘이들이 자국에서 자기 재능을 좋은 방향으로 쓰면서 돈과 명예를 얻는 인프라가 없었다는 거다.
그래서 불가리아에서 컴퓨터와 관련해서 세계구 급으로 선한 게 개발되어 나온 게 없었다. 그 대신 불가리아 산 컴퓨터 바이러스들이 악명을 떨쳤다.
당장 떠오르는 건 DIR-II, 어둠의 복수자(dark avenger) 바이러스. 이들의 원산지가 바로 저 나라였다. 그러고 나서 1990년대 이후부터 불가리아의 존재감은.. 지금 다들 알려진 바와 같다.

그 먼 옛날에 컴퓨터 바이러스를 만들 정도의 사람이라면 그 비싸고 귀하던 IBM PC의 내부 구조와 도스 API, x86 어셈블리를 다 마스터 했고 컴공이 얼마나 대단했겠는가? 그랬는데 만들어 낸 건 고작 남에게 해를 끼치는 물건뿐이었던 거다.
지금도 북괴에서는 아무리 컴퓨터 똘똘이가 돼 봤자 하는 일은 당의 명령대로 오픈소스들 다 무단으로 베껴서 이상한 프로그램 만들거나, 중국으로 외화벌이 정보전사로 파견 나가서 사이버 범죄, 남조선 종북 여론몰이 같은 지저분한 짓밖에 없다. 그런 것과 비슷한 맥락의 안타까운 상황이다.

5.
전에 얘기한 적이 있던가?
본인은 초딩 저학년 때 8비트 컴, 중· 고학년 때 16비트 IBM 호환 PC, 중학교 때 Windows와 PC통신, 고등학교 때 인터넷, 대학교 때 휴대전화, 대학원 때 스마트폰을 순서대로 접했다.
대학교 때 기숙사에서 10Mbps 유선 랜을 처음으로 접했고, 2003년쯤에 무선 인터넷과 USB 메모리라는 걸 처음으로 접했다.

내가 대학을 졸업할 즈음부터 대학원 연구실을 시작으로 유선 랜의 속도가 100Mbps로 올랐으며, 그로부터 얼마 안 가 교내 네트워크 주소들이 공인 고정 class B ip 대신, 가변 사설 ip로 바뀌었지 싶다.
이제는 그냥 무선 인터넷으로도 신호가 좋은 곳에서는 늘 100Mbps까지는 아니어도 수십 Mbps의 속도가 나오고, 유튜브로 HD급 동영상을 실시간 스트리밍으로 보는 시대가 됐다. 개인적으로는 정말 충격적이다. PC통신으로 사진 한 장 받던 시절의 전송 속도와 지금 속도를 비교하면 말이다.

지금이 우주 정거장 관광 단가가 1억 원 근처까지 내려갔다거나, 스페이스 오딧세이 2001 영화가 묘사하는 세상이 오지는 않았다. 컴퓨터의 클럭 속도가 싱글 코어로 10GHz를 넘어간다거나 하지도 않았다. 하지만 과거에 상상하지 못했던 SNS 미디어, 고화질 동영상과 더 새끈해진 글꼴, 각진 게 아니라 날렵한 외형의 자동차들이 시대의 변화를 대신 말해 주고 있다. 이것 말고도..

  • 휴대전화가 없던 시절엔 오지에서 운전을 하다가 차가 퍼지거나 사고가 나면 보험사 연락을 어떻게 했을까?
  • CCTV와 블랙박스가 없던 시절엔 교통사고 과실 비율 산정이 얼마나 주먹구구식으로 진행됐을 것이며(바퀴가 굴러가는 이상 절대적인 100:0이란 존재하지 않는다.. -_-), 가해자와 피해자가 뒤바뀐 억울한 경우도 얼마나 많았을까?
  • 구글과 riss.kr, dbpia가 없던 시절에 도대체 학술 문헌 검색을 어떻게 하고 논문이란 걸 어떻게 썼을까? (일일이 도서관 찾아다니면서 실물을..)
  • msdn이야 그렇다 치더라도, 스택 오버플로우와 검색 엔진이 없던 시절에는 도대체 생소한 플랫폼에 대한 프로그래밍 자료 검색을 어떻게 하면서 코딩을 어떻게 했을까?
  • 15년 전이나 지금이나 그냥 이더넷 랜선을 꽂는 건 동일한데 랜 카드와 내부 기술 기반이 뭐가 바뀌었길래 인터넷 속도가 옛날보다 10배 이상으로 뻥튀기될 수 있었을까??
  • 전자기파의 물리적인 특성이 100년 전이나 지금이나 바뀐 건 없을 텐데 텔레비전의 화질은 어쩜 이렇게 좋아졌을까?

이런 걸 생각하면 과학 기술, 특히 정보 통신 분야의 기술이 세상을 얼마나 드라마틱하게 바꿔 놓았는지를 알 수 있다.

그 전까지 몇몇 얼리어답터들이나 쓰던 PDA, 휴대용 MP3 플레이어가 휴대전화와 결합해서 스마트폰으로 탄생한 건 정말 2000년대의 혁신 중의 혁신이 아닐 수 없었다. 그냥 크기도 작고 기능도 열악한 특수 목적 컴퓨터의 범주인 '임베디드'로부터 '모바일'이라는 완전히 새로운 범주가 파생돼 나왔다. Windows CE가 Phone, Mobile 등 갖가지 브랜드로 재탄생해야 한 것을 보면 이해하기 쉽다. 지금이야 그냥 10이라는 브랜드로 통합됐고, 스마트폰 OS로는 안드로이드가 지구를 평정했다만 말이다.

물론 냉동 기술이나 플라스틱, 의학· 생명 공학처럼 굳이 IT에 속하지 않는 획기적인 기술도 있다.
기술의 발달 덕분에 쿼츠 시계는 기계식 태엽 시계를 가격과 성능 모든 면에서 쳐발랐고, LED는 백열등은 말할 것도 없고 형광등까지 쳐발라서 인류가 발명한 가장 고효율 광원을 달성했다. 핵 무기는 같은 무게의 재래식 폭탄에 비해 위력 계수에 0을 몇 개 더 붙였다.

이런 정도의 혁신이 앞으로 어느 분야에서건 또 나올 게 있으려나 모르겠다.
무탄피총, 실리콘 반도체를 능가하는 컴퓨터 소자, 자동차에서 현행 기계들의 한계를 극복하는 무단 변속기나 반켈 엔진, 혁신적인 무선 송전이나 2차 전지, 핵융합 발전 같은 것 말이다.

6.
정보 통신 쪽 얘기를 계속하자면..
자동차의 번호를 자동으로 인식하는 무인 단속 카메라와 무인 주차 시스템도 지금이야 너무나 당연하게 여겨지고 있지만, 국내에 본격적으로 도입된 건 1990년대 중후반부터이다. 지금으로부터 20년이 채 되지 않았다. 이런 게 없던 시절에는 과속· 신호 위반 같은 건 경찰관이 숨어 있다가 위반 차량을 강제로 불러다 세우는 식으로 단속을 할 수밖에 없었다.

차량 번호판을 인식하는 기술은 길거리에서 도난· 수배 차량이나 세금· 통행료 상습 체납 차량을 즉시 잡아내는 데에도 아주 요긴하게 쓰이고 있다. 이게 없었으면 컴퓨터와 행정 전산망이 있더라도 사람이 일일이 차 번호를 입력해서 조회해야 했으니 일이 얼마나 불편했을지 모른다. 스피드건이 생각보다 속도를 굉장히 정확히 측정해 주는 것만큼이나 신기한 일이다.

단순히 편해진 것뿐만 아니라 세상 돌아가는 시스템이 더 객관적이고 공정하게 바뀐 것은 얼마나 축복인지 모른다. 모든 것이 전산화되고 컴퓨터가 통제하는 세상에 대해 무슨 666 짐승의 표인 것처럼 공포심만 가질 필요는 없을 것이다.

Posted by 사무엘

2018/03/07 08:26 2018/03/07 08:26
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1465

Trackback URL : http://moogi.new21.org/tc/trackback/1465

Comments List

  1. 재호 2018/03/07 13:23 # M/D Reply Permalink

    애니메이션 이모티콘은 WebP 라는 기술로 구현했을거에요.
    DIR 2 바이러스의 기억이 덕분에 오랜만에 생각 났습니다. ㅎㅎ

    1. 사무엘 2018/03/07 13:52 # M/D Permalink

      아하~ 새로운 이미지 겸 동영상 포맷이 있군요. 정보에 감사드립니다.
      그에 반해 Windows의 애니메이션 컨트롤은 아직도 RLE 기반 avi만 지원하는지.. 좀 변모해야 하지 않나 하는 생각이 드네요.
      재호 님, 정말 오랜만이고 반갑습니다. ^_^

  2. 덧붙임 2018/03/07 17:46 # M/D Reply Permalink

    애니메이션 PNG를 지원하는 확장자로 파이어폭스나 크롬, 사파리 등에서 APNG하는 형식도 있습니다.

    1. 사무엘 2018/03/07 20:59 # M/D Permalink

      예, apng라는 게 있다는 건 압니다만 완전히 표준화가 안 됐는지 지원하는 프로그램이 적고 인지도가 부족하다고 들었습니다.
      언제까지나 구닥다리 gif에 머무를 수는 없을 텐데, 실사가 아닌 애니메이션 영역도 좀 기술이 발전해야지요~ ^^

Leave a comment

1. 도스 시절 명령어

도스에서 파일(과 디렉터리)을 다른 곳에 복사하는 명령은 copy이다. 얘는 명령 셸인 command.com이 자체 지원하는 내장 명령이다.
그런데 도스에는 copy의 일종의 강화 버전이라 할 수 있는 xcopy라는 것도 있으며, 이건 별도의 프로그램을 통해 실행되는 외부 명령이다.

xcopy는 일반 copy와 달리 (1) 서로 다른 드라이브 사이에 서브디렉터리까지 재귀적으로 통째로 복사하는 걸 지원했으며, (2) 복사에 사용하는 메모리 버퍼 크기가 더 크고, 여러 개의 파일을 한꺼번에 읽은 뒤(대략 수백 KB 정도 크기까지) 타겟에다 쓰는 걸 지원했다. xcopy의 전치사 X는 일반적으로 cross라고 발음되었다.

지금 생각해 보면 이 둘은 차별화 요소가 전혀 될 수 없으며 굳이 분리할 필요가 없다. 그냥 copy가 원래 (2)처럼 동작하면 되고, (1)은 /s 같은 옵션을 추가해서 지원하면 될 일이다.
하지만 옛날에 xcopy가 외부 명령으로 존재했던 이유는 겨우 그 정도 고급 복사 옵션/기능마저도 command.com에다 상시 집어넣고 있기에는 메모리가 부족하고 아까웠기 때문이다. 옛날에는 베이직 인터프리터가 Ready 출력할 메모리조차 아까워서 프롬프트를 Ok로 바꾼 시절이 있었다는 것 기억하시는가? (단 3바이트를 아끼려고!) 검색을 해 보니 xcopy는 1987년, MS-DOS 3.2에서 첫 도입됐다고 한다.

하긴, 옛날에는 다단계 디렉터리를 재귀적으로 탐색하면서 뭔가를 하는 일이 쉽지 않아서 외부 유틸리티를 많이 이용해야 했다. 파일 찾기는 말할 것도 없고, 지우는 것도 옛날에는 deltree라는 명령이 따로 있었지 싶다. 그건 지금은 del에 /s옵션으로 통합됐지만 말이다.
유닉스 계열 셸은 내장과 외장 명령어 구분이 어찌 되나 모르겠다. cp, mv, rm은 외부 프로그램인 것 같던데 설마 pwd, cd 이런 것들도 다 외부 프로그램이려나?

그리고 옛날에는 플로피 디스크(일명 디스켓)란 게 쓰여서 파일 시스템 차원에서 완전히 똑같은 디스크 복제를 해 주는 diskcopy라는 외부 명령이 있었다. 얘는 굳이 외부 명령으로 만들 거면 디스크 이미지 파일을 만들거나 이로부터 복제 디스크를 만드는 기능도 같이 있었으면 좋았을 거라는 아쉬움이 남는다.

1.2~1.44MB짜리 디스크를 단일 드라이브에서 복사하려면 source와 target 디스켓을 여러 번 갈아 끼워야 했는데.. Norton Utilities 같은 다른 유틸리티들은 EMS 및 XMS 메모리를 활용하여 한 번만 갈아 끼우고 바로 복사가 된다는 걸 장점으로 내세우곤 했다. 프로그램을 하나 설치하려 해도 "제품의 이제 1~N번 디스크를 넣고 아무 키나 누르세요" 이러던 참 아련한 옛날 추억이다.

2. 16비트 Windows의 실행 모드

예전에 언급한 바와 같이, 1990년대 초중반에 Windows라는 운영체제가 32비트 플랫폼으로 처음 갈아타던 시절에는 Win32 API라는 것의 구현체가 Windows NT, Windows 95, Windows 3.1+Win32s라는 세 계통으로 나뉘었다. NT가 가장 이상적인 레퍼런스 구현체이고, Win32s는 제일 허접하다.

그리고 그 중간의 95는 비록 NT처럼 스레드도 지원하고 도스로부터 많이 독립했다고는 하지만, 도스로부터 완전히 독립했다기보다는 도스를 내부적으로 흡수· 합병한 것에 가깝다. Windows NT의 마이너 축소판이라기보다는 Win32s가 각종 한계 없이 제대로 구현된 형태라고 보는 게 더 타당하다.

그런데 95 계통의 전신이라 할 수 있는 Windows 3.0이 나왔을 때에는 동일 제품· 단일 바이너리 하에서 실행 모드가 세 갈래로 나뉘었다. 바로 8086 리얼 모드, 286 표준 모드, 386 확장 모드이다.
Windows NT 4가 가장 많은 아키텍처를 지원하는 32비트 운영체제였다면, Windows 3.0 (3.1 말고)은 실행 모드가 가장 다양했던 16비트 도스용 운영 환경(?)이었다.

원래 Windows 1과 2에서는 리얼 모드밖에 존재하지 않았으며, Windows는 진짜 도스 위의 덧실행 껍데기 그 이상도 이하도 아니었다. 리얼 모드에서는 메모리가 기본 640K밖에 없었으며, 그 번거로운 16비트 Windows 3.x보다도 프로그래밍 환경이 더 열악했다.

그러다 Windows 2.0의 후속 버전으로 2.1은 286 표준 모드를 도입한 Windows/286과, 386 확장 모드의 전신인 Windows/386 이렇게 두 갈래로 나왔다. 사실, 16비트 80286 프로세서에도 보호 모드가 있긴 했지만 프로그래밍에 애로사항이 많았는지 그걸 사용한 프로그램은 매우 소수였으며 여전히 거의 봉인돼 있었다. 그냥 EMS/XMS 같은 규격으로 메모리를 수백 KB 남짓 더 사용할 수 있다는 것에 의미를 둬야 했다. 386 확장 모드도 첫 버전답게 문제가 많았으며, 2.11이 더 나와야 했다.

그러다가 Windows 3.0은 리얼, 286 표준, 386 확장을 모두 통합하여 출시됐다. 이때는 DPMI 규격도 갓 제정되었기 때문에 2.x 시절보다 보호 모드 지원도 더 개선되었다.
이때는 3.0에다가 멀티미디어 API가 최초로 추가된 확장팩이 나왔으며, 3.1은 네트워크 API가 추가된 Windows for Workgroup 3.11, 그리고 중국어 입출력 지원이 추가된 3.2 이런 식으로 기능 확장팩이 많던 시절이었다. 지금처럼 인터넷을 통한 업데이트가 가능한 시절도 아니었으니 말이다.

Windows 3.1에서는 리얼 모드가 삭제되고 win /2 또는 /3을 통해 286 표준 모드만 지원하지만, 이것은 성능이 굉장히 많이 열화된 모드였다. 그리고 Windows 95부터는 표준 모드도 빠져서 기술적으로 언제나 386 확장 모드로만 동작하는 형태가 됐다.

이렇듯, Windows 3.x는 비록 순수한 32비트 운영체제는 아니지만 보호 모드라든가 도스용 프로그램을 내부에서 구동할 때처럼 일부 기능에서 80386 이상 CPU가 제공하는 가상화 기능을 사용하기 때문에 결과적으로 32비트 CPU가 필요했다. 386 확장 모드가 지원하는 기능이 그런 것이었다.
이는 과거에 존재하던 PIF 편집기가 확장 모드에서는 표준 모드에 비해서 지원하는 옵션이 얼마나 더 다양해지는지를 보면 얼추 짐작 가능하다. 286 표준 모드에서는 요게 전부이던 옵션이..

사용자 삽입 이미지

386 확장 모드에서는 XMS뿐만 아니라 EMS 규격, 그리고 멀티태스킹 우선권 등 다양한 옵션들이 별도의 대화상자와 함께 추가되는 걸 알 수 있다.

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

Windows 95 역시 순수 32비트 프로그램이 아니면 도스용 프로그램에 대해서만 제대로 된 가상 머신과 선점형 멀티태스킹을 지원했다. 16비트 Windows 프로그램을 강제 종료하면 운영체제와 얽혀 있는 스레드 동기화 오브젝트 같은 것이 얼어붙으면서 시스템의 안정성에 심각한 문제가 발생하곤 했다.

LimitEmsPages 이런 함수는 32비트가 아니라 이미 Windows 3.x 시절부터 deprecated돼 있었는데, 아마 리얼 모드 시절의 잔재이지 싶다.
Windows 1~2.x용 실행 파일은 후대 Windows와 실행 파일 포맷은 동일하지만(NE) 내부의 플래그로 구분되어 있어서 3.x에서 실행하면 "제대로 실행되지 않을 수 있음" 경고가 뜨곤 했다. 요컨대 Windows의 역사를 살펴보면, 16비트에서 32비트로 넘어갈 때만치 큰 변화는 아니지만, 같은 16비트 안에서도 1~2.x와 3.x 사이에 보호 모드가 도입되기 전과 후에는 기술적으로 나름 변화와 단절이 있었다고 볼 수 있다.

3. 외주로 제작되었던 보조 프로그램과 게임

Windows에 내장돼 있는 기본 프로그램들 중에는 마소에서 직접 만들지 않은 외주 프로그램도 있다. Windows 95 시절에 잠깐 있었던 하이퍼터미널이라는 터미널 접속 프로그램이 대표적인 예로, 스플래시 화면이라든가 각종 UI 외형이 대놓고 기존 마소 프로그램과는 어울리지 않아서 마소 자체 개발이 아니라는 걸 알 수 있었다.

또한 게임 중에서도 Windows XP에까지 제공되었던 3D 핀볼(시네마트로닉스 개발, 맥시스 유통)은 외부 프로그램이었으며, Vista/7 시절에 그래픽이 쇄신했던 지뢰찾기 등의 기본 게임들도 외주였다(Oberon games).

그런데 더 옛날에 Windows 3.1의 내장 프로그램들을 보면, 굉장히 단순하게 생겼고 이 정도면 자체 제작했을 법도 한 프로그램이 About 대화상자를 보면 외주인 경우가 은근히 더 있었다. 게다가 아래의 목록에서 보다시피 제작자/제작사가 프로그램마다 완전 제각각이었다.

  • 계산기: Kraig Brockschmidt
  • 터미널: Future Soft Engineering 사
  • 레코더: Softbridge 사
  • 지뢰찾기: Robert Donner & Curt Johnson
  • 카드놀이: Wes Cherry

그러니 Vista/7 이전에 제공되던 기본 게임들도 알고 보니 외주였던 셈이다. 특히 지뢰찾기는 Windows 1.0부터 3.0까지 존재하던 Reversi(일명 오델로)를 대체할 목적으로 3.1에서 처음 선보였던 게임이기도 하다.
레코더의 경우 Windows의 역사상 거의 전무후무하게 존재하던 키보드· 마우스 매크로 유틸리티인데 95와 그 이후로는 결코 재등장하지 않았으니 희소성이 크다.

물론 이것들 말고 프로그램 관리자, 파일 관리자, 제어판이라든가 간판 앱인 문서 작성기(오늘날의 워드패드)와 페인트(오늘날의 그림판)은 외주가 아니라 내부 자체 제작이다.

4. 색깔의 미묘한 차이

말이 나왔으니 옛날 추억 회상을 더 해 보자면,
컴퓨터의 주메모리가 아니라 비디오 메모리가 딱 1MB이던 시절에는 Windows 3.1의 비디오 모드를 (1) 꼴랑 640*480 저해상도인 대신에 트루컬러, (2) 800*600에서 적당하게 하이 컬러, 아니면 (3) 1024*768에서 256색.. 셋 중 하나로 골라 쓰는 재미(?)가 있었다.

그리고 Windows 3.1은 원래는 우리에게 익숙한 짙은 파란색으로 윈도우의 굵은 틀을 표현했지만, 하이 컬러 이상부터는 어인 일인지 은은한 하늘색으로 색깔을 바꿔 표시했다. 왜 무슨 근거로 색깔을 바꿨는지는 모르겠지만 개인적으로 아주 신기하게 느껴졌었다.

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

그 이전 3.0은 슈퍼 VGA나 트루컬러로 진입할 일이 있긴 있었는지, 그래픽 드라이버가 개발되거나 3.1 것과 호환되긴 했는지에 대해 본인은 아는 바가 없으며, 이에 대해서 회의적이다.

Posted by 사무엘

2018/03/04 08:30 2018/03/04 08:30
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1464

Trackback URL : http://moogi.new21.org/tc/trackback/1464

Leave a comment

C++ 다중 상속 생각

날개셋 한글 입력기 같은 Windows용 프로그램을 개발하다 보면 여러 개의 COM 인터페이스를 한꺼번에 상속받아 구현한 단일 클래스를 구현하게 된다.

그런데 하루는 이런 의문이 들었다. 각각의 인터페이스들이 다 IUnknown을 상속받았는데 어떻게 어느 인터페이스로 접근하든지 AddRef, Release 같은 공통 인터페이스들은 중복 없이 동일한 함수 및 동일한 숫자 카운터 인스턴스로 연결될까? 데이터 멤버 없이 인터페이스 상속만 하면 this 포인터 보정이 필요 없이 다중 상속과 관련된 문제들이 상당수 깔끔하게 해결될까?

그래서 클래스 A, 이로부터 상속받은 B와 C, 그리고 B와 C를 다중 상속한 D 이렇게 네 개의 클래스가 있을 때 일명 ‘죽음의 다이아몬드’ 현상을 해소하는 방법이 무엇이 있는지를 정리해 봤다. C++의 다중 상속과 관련해서는 이제 더 글을 쓸 게 없을 줄 알았는데 내가 지금까지 생각하지 못하고 있던 요소들이 더 있었다.

1. 가상 상속

클래스에서 상속이라는 건 기술적으로 어떤 구조체에다가 부모 클래스의 컨텐츠(데이터 멤버)들을 앞에 쭉 늘어놓고 나서 그 뒤에 나 자신의 컨텐츠를 추가하는 것과 같다. 그러니 부모 클래스와 자식 클래스 포인터를 형변환 하는 건 그냥 프로그래밍 언어 차원에서의 의미 변환일 뿐, 메모리 주소가 바뀌는 것은 전혀 없다. 아주 쉽다.

그런데 가상 상속은 부모 클래스의 컨텐츠를 그렇게 나 자신의 일부로서 고정된 영역에 배치하는 게 아니라, 포인터로 참조하는 것과 같다.
부모 클래스를 ‘가상’이라는 방식으로 상속한 자식 클래스는 부모 클래스와 자식 클래스가 굳이 메모리 상에 연속된 형태로 있지 않아도 된다. 그러니 동일 부모를 공유하는 다수의 클래스가 다중 상속되더라도 이들이 공통의 유일한 부모 하나만을 가리키게 하면, 한 부모 클래스의 데이터들이 불필요하게 여러 번 상속되는 것을 막을 수 있다.

여기서 중요한 것은, D가 B, C를 ‘가상’ 상속하는 게 아니라는 점이다. 부모인 B와 C가 A를 미리 가상으로 상속해 놔야 한다.
가상 함수도 자식이 아닌 부모 클래스에서 미리 지정해 놔야 하듯 말이다.

그러니 클래스 라이브러리 개발자는 공통 부모를 공유하는 여러 클래스들이 사용자에 의해 다중 상속되겠다 싶으면 그 공통 부모를 virtual로 상속하도록 설계를 미리 해 놔야 한다. 특히 그 클래스(공통 부모 말고)가 순수 가상 함수 같은 걸 포함하고 있어서 상속이 100% 필수라면 더욱 그러하다.
앞의 A~D의 경우, 혹시 A가 default constructor가 없어서 B, C의 생성자에 모두 A를 초기화하는 인자가 들어있었다 하더라도, D의 A는 D의 생성자에서 제공된 인자만으로 딱 한 번만 초기화된다.

가상 상속을 한 자식 클래스는 굉장히 이색적인 특징을 하나 갖게 된다.
자식 클래스의 포인터에서 부모 클래스의 포인터로 형변환을 하는 것이야 너무 당연한 귀결이며, 반대로 부모에서 자식으로 가는 건 좀 위험한 일이긴 하지만 어쨌든 가능하다. 단일 상속에서는 말할 필요도 없고, 다중 상속이라 하더라도 그냥 고정된 크기만큼의 포인터 덧셈/뺄셈만 하면 된다.
그에 반해, 부모 클래스에서 자신을 virtual 상속한 자식 클래스로 형변환은 일반적으로 허용되지 않는다…!

A *pa = new D; //자식에서 부모로 가는 건 당연히 되고
B *pb = new D;
D *pd;
pd = static_cast<D*>(pb); //부모에서 자식으로 가는 건 요건 괜찮지만
pd = static_cast<D*>(pa); //요건 안 된다는 뜻..

그 자식 클래스의 주소와 부모 클래스의 주소 사이에는 컴파일 타임 때 결정되는 관계 내지 개연성이 없기 때문이다.
자식에서 부모로 거슬러 올라가는 게 단방향 연결 리스트를 타는 것과 다를 바 없게 됐는데, 저런 형변환은 단방향 연결 리스트를 역추적하는 것과 같으니까 말이다.

물론, 가상 상속이라 해도 현실에서는 D라는 오브젝트 내부에서 A가 배치되는 오프셋은 고정불변일 것이고 컴파일러가 그 값을 계산하는 게 불가능하지 않을 것이다. 모든 자식 클래스들과 연속적으로 배치되지만 않을 뿐이다.
static_cast를 어거지로 구현하라면 구현할 수는 있다. 하지만 이 A가 반드시 D에 속한 A라는 보장도 없고, 포인터에 무엇이 들어있는지 확신할 수 없는데.. C++ 컴파일러가 그런 어거지 무리수까지 구현하지는 않기로 한 모양이다.

2. 가상 함수로 이뤄진 추상 클래스(인터페이스)들만 상속

죽음의 다이아몬드를 해소하기 위해서 요즘 프로그래밍 언어들은 C++ 같은 우악스러운 수준의 다중 상속을 허용하지 않고, 잘 알다시피 데이터 멤버 없고 가상 함수로만 구성된 추상 클래스들의 다중 상속만 허용하곤 한다.
그러면 문제의 복잡도가 크게 줄어들긴 한다. 효과가 있다. 하지만 그게 전부, 장땡은 아니다.

명시적인 데이터가 없는 클래스라 하더라도 가상 함수가 들어있는 클래스를 상속받을 경우, 2개째와 그 이후부터는 클래스 하나당 vtbl (가상 함수 테이블 v-table) 포인터만치 클래스의 덩치가 커지게 된다.

단일 상속 체계에서는 this 포인터의 변화가 전무하니 상속을 제아무리 많이 하더라도 한 vtbl의 크기만 커질 뿐, 그 테이블을 가리키는 포인터의 개수 자체가 늘어날 필요는 없다.
그러나 다중 상속에서는 D 같은 한 객체가 상황에 따라 클래스 B 행세도 하고 클래스 C 행세도 하면서 카멜레온처럼 변할 수 있어야 한다. 그렇기 때문에 A, B, D일 때의 vtbl, 그리고 C일 때의 vtbl 이렇게, 테이블과 테이블 포인터가 둘 필요하다.

클래스 D에 속하는 인스턴스 포인터(가령, D *pd)를 부모 C의 포인터로 변환해서 전달할 때는 pd는 A, B, D 같은 직통 상속 계열 vtbl이 아니라 C의 vtbl을 가리키는 형태로 오프셋이 보정된다. 그리고 여기서 가상 함수를 호출하면.. this 포인터가 C가 아닌 D를 기준으로, 보정 전의 형태로 복구된 채로 함수에 전해진다. 이 함수는 애초부터 C가 아닌 D에 소속된 함수이기 때문이다.

즉, 다중 상속에서 가상 함수를 호출하면 비록 겉으로 this 포인터는 바뀐 게 없지만 내부적으로 vtbl을 찾는 것을 부모와 자식 클래스가 완전히 동일하게 수행하기 위해서 보정이 일어나고, 그걸 함수에다 호출할 때는 보정 전의 값을 전하도록 일종의 thunk 함수가 먼저 수행된다.
한 클래스 오브젝트에서 여러 인터페이스 함수를 자유자재로 호출하는 polymorphism의 이면에는 이런 비용 오버헤드가 존재하는 셈이다. 무슨 숫자나 문자열로 메시지를 전하는 게 아닌 이상, 서로 다른 클래스에 존재하는 가상 함수는 vtbl의 종류와 오프셋으로 구분할 수밖에 없다.

3. 멤버로만 갖기

다중 상속의 지저분함을 회피하는 방법 중 하나는.. 원하는 기능이 들어있는 클래스를 내 아래로 상속하지 말고 그냥 멤버 변수로 갖는 것이다. 상속하더라도 걔만 따로 상속해서 확장 구현을 한 뒤에 그걸 멤버 변수로 갖는다. 이 개념을 유식한 용어로는 aggregation이라고 한다.

이 방법은 다중 상속의 각종 오버헤드는 피할 수 있지만 그만큼 다른 방면에서 불편을 야기한다. 그 클래스가 동작하는 과정에서 내 클래스의 함수 및 데이터를 빈번하게 참조해야 한다면(결합도 coupling가 높은 관계..) 그 통로를 억지로 트는 게 더 불편하며 코드를 지저분하게 만든다. 또한 서로 다른 클래스 간에 중복 없이 동일한 기능을 제공하는 일관된 인터페이스를 만드는 게 다중 상속이 아니면 답이 없는 경우도 있다.

이게 경험상 딱 떨어지는 답이 있는 문제가 아니다. 복잡한 클래스 계층이 필요한 대규모 개발을 한 경험이 없는 프로그래머라면 이런 부류의 문제는 배경을 이해하는 것조차 난감할 것이다. 그렇기 때문에 다중 상속이 무조건 나쁘기만 한 건 아니며, 그걸 억지로 우회하다 보면 결국 다른 형태로 불편함과 성능 오버헤드가 야기될 거라며 다중 상속을 옹호하는 프로그래머도 있다.

이상.
객체지향 프로그래밍 언어에서 다중 상속은 사람마다 취향 논란이 많은 주제이다. 비록 C++이 이걸 지원하는 유일한 언어는 아니지만, 네이티브 코드 생성이 가능한 유명한 언어 중에서는 C++이 사실상 대표격인 것처럼 취급받고 있다.

어떤 기능이 절대적으로 나쁜 것만 아니다면야 없는 것보다는 있는 게 좋을 것이다. 상술했다시피 다중 상속이 가능해서 아주 편리한 경우도 물론 있다. 한 오브젝트로 다수 개의 기반 클래스 행세를 자동으로 하는 것과, 그 오브젝트 내부의 구현 함수에서는 여러 기반 클래스를 넘나드는 게 동시에 되니까 말이다.

하지만 다중 상속은 가성비를 따져 보니 그 부작용과 오버헤드, 삽질을 감수하면서까지 굳이 구현하고 지원할 필요가 있나 하는 게 PL계의 다수설 대세로 흐르고 있다. this 포인터의 보정이라든가, 복수 개의 기반 클래스들이 또 공통의 기반 클래스를 갖고 있을 때 발생하는 모호성의 처리 등.. 템플릿 export만치 막장은 아니지만 컴파일러 개발자와 PL 연구자들의 고개는 설레설레 저어지곤 했다.

그래서 C++ 이후에 등장한 더 깔끔한 언어인 D, C#, Java 등은 다중 상속을 지원하지 않는다. 그 대신 다중 상속을 우회하고 복잡도를 완화하기 위해, 적어도 가상 상속만은 할 필요가 없게끔 static 내지 가상 함수 선언만 잔뜩 들어있는 인터페이스에 대해서만 다중 상속을 허용하는 것이다. Java는 두 종류의 상속을 extends와 implements라고 아예 구분까지 했다.

물론 이런 패러다임 하에서는.. 프로그램 구조가 간단해서 가상 함수로 만들 필요가 없는 것까지 일단은 인터페이스부터 만들어 놓고 구현 클래스를 내부적으로 또 만드는 식의 오버헤드 정도는 감수해야 한다. 하지만 Java는 final이 아닌 함수는 기본적으로 몽땅 가상 함수일 정도로.. 디자인 이념이 애초에 성능 대신 극도의 유연성이니, 그 관점에서는 그건 별 상관이 없는가 보다.

가장 대중적인 기술이 알고 보면 레거시 때문에 굉장히 지저분하고 기괴하기도 하다는 것은 CPU계에서 x86이 그 예이고, 프로그래밍 언어에서는 C++이 해당되지 싶다. 전처리기(+생짜 파일 기반 인클루드), 다중 상속, 클로저 없이 특유의 pointer-to-member 기능 같은 것 말이다. 후대 언어에서는 저런 게 결코 도입되지 않고 있다.

본인은 다중 상속을 굳이 의도적으로 기피하면서 코딩을 하지는 않는다. 다중 상속이 필요하고 당장 편하겠다 싶으면 한 클래스에다 막 엮었다. 그 상태로 막 복잡한 pointer-to-member나 람다를 구사하면서 컴파일러를 변태적으로 괴롭히지는 않을 것이고, 컴파일러가 그냥 this 포인터 보정을 알아서 해 주는 것만 원했으니까 말이다.

하루는 ", public"라고 검색을 해서 날개셋 한글 입력기의 소스 코드 내부에도 혹시 다중 상속을 쓴 부분이 있나 찾아 봤는데.. 그래도 2017년 현재 날개셋 한글 입력기의 소스 코드에는 데이터 멤버가 존재하는 클래스를 둘 이상 동시에 상속받은 부분은 없었다. 추가적인 상속처럼 보이는 것은 COM 인터페이스 내지, 내가 콜백 함수를 대신해서 내부적으로 만들어 놓은 추상 클래스 인터페이스들이었다.

한두 번 썼을 법도 해 보이는데.. 이 정도 규모의 프로그램을 만드는 데도 실질적인 다중 상속을 사용한 부분이 없다면 그건.. 정말로 가성비 대비 불필요하게 지원할 필요는 없을 법도 해 보인다.

Posted by 사무엘

2017/12/26 08:37 2017/12/26 08:37
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1441

Trackback URL : http://moogi.new21.org/tc/trackback/1441

Leave a comment

1.
과거 2010년대 초에는 제로보드 4를 쓰지 말자, IE6을 쓰지 말자, ActiveX를 퇴출시키자 이런 운동이 벌어졌다. 그때는 같은 PC 안에서 Windows에 종속되지 말고 맥, 리눅스까지 잘 지원하는 웹 표준을 지키자는 게 아젠다였다.

그러다가 2010년대 중반부터는 구시대 관행들이 추가적으로 없어지는 게 눈에 띈다. 웹 상으로 주민 등록 번호 13자리 전체를 수집하는 게 금지되었으며, 기술적으로는 영원불변할 것만 같던 플래시마저 웹에서 퇴출 수순을 밟고 있다. 이건 PC 운영체제 간의 연동이 아니라, PC와 모바일이라는 상이한 플랫폼 간의 연동이 아젠다이다. (플래시 없이 현란한 광고 애니메이션은 어째 만드나 싶다.)

사실, 기술과 이론만 따지자면야 모바일에서도 플래시를 지원하지 못할 이유는 없다. 그러나 플래시는 근본적으로 현란한 벡터 애니메이션을 출력하려고 만들어진 물건이니 설계 이념이 딱히 화면 작고 전력 소비에 민감한 모바일과는 친화적이지 않다. 기기와 무관한 접근성의 보장이라는 웹 표준과도 어울리지 않는다.

더구나 플래시도 따지고 보면 그 본질은 3rd-party plug in이고 IE의 용어로 표현하자면 ActiveX의 일종이긴 했다. 플래시를 집어넣을 때 쓰는 태그가 여느 ActiveX 컨트롤을 집어넣을 때 사용하는 태그와 다를 바 없다. 다만, 얘는 독보적으로 너무 유명하고 널리 쓰이다 보니 타 ActiveX와는 지위가 다른 예외적인 물건으로 취급되어 왔을 뿐이다.

그러니, 좀 웹 표준을 어겨도 PC에서는 큰 문제가 되지 않던 것이 완전히 차원이 다른 컴퓨팅 환경인 모바일에서는 더욱 부각되게 되었다. 거기에다 보안 문제도 불거지고, 또 모종의 이유로 인해 아이폰 제조사인 애플과 플래시의 제조사인 어도비가 사이가 나빠지는 악재까지 겹치면서 플래시는 인터넷에서 퇴물로 전락했다. 급속도로 몰락의 길을 가게 됐다.

플래시가 독자적으로 제공하던 고급 기능들은 그냥 웹브라우저가 직통으로 지원하는 HTML5 표준으로 몽땅 이동했다. 인터랙티브하게 싹 나타났다가 사라지는 웹사이트 메뉴, 인터랙티브한 게임, 간단한 이미지 편집 등등이 몽땅 말이다.
Chrome 브라우저의 경우 플래시는 자동 실행은 개뿔 물 건너 갔으며, 사용자가 수동으로 켜 줘야만 실행되는 legacy가 됐다. 음.. 예전에 흑역사로 사라졌던 MS Office의 길잡이를 보는 듯한 느낌이다. 웹 환경이 이렇게 변할 줄이야..

2.
인터넷 IPv4 주소 고갈과 주소 할당 중단은(이미 2011년의 일임!) 마치 유니코드에서 BMP 영역의 고갈과 비슷한 성격의 현상 같다.
결국 요즘 사람들은 대부분 공유기를 사용해서 인터넷을 하고 고정 IP라는 개념이 사실상 없어졌는데,
공인 IP와 사설 IP가 따로 노는 것 때문에 계층이 좀 헷갈리고 복잡해지고 골치 아파진 것도 있다. 이건 마치 분당선 서현 역이 지하철 출구 번호(안)와 백화점 출구 번호(밖)가 서로 완전히 따로 놀아서 위치 식별이 어려운 것과 비슷한 양상이다.

초기에 설계되었던 공인 IP 주소 영역들을 보면 class A~C 이런 거 말고도 공유기를 위한 영역을 따로 떼어 놓은 게 있는데.. 이게 유니코드로 치면 UTF-16에 존재하는 surrogate와 개념상 정확하게 일치한다. (처음엔 유니코드에 UCS2만 있었지 UTF-16 같은 게 있지는 않았듯이, IP 주소도 처음부터 공유기 영역에 있지는 않았었다.)
아니, 애초에 유니코드가 없던 시절에 지원 글자 수를 늘리려고 사용하던 multibyte, lead byte, tail byte 따위와도 비슷한 개념이라 볼 수 있다.
또는 16비트 시절의 far pointer하고도 비슷하고 말이다.

결국 32비트, 64비트, IPv6처럼 본질적으로 더 우월하고 넉넉하고 나은 것, 완전한 것이 오기 전에 컴퓨터에서 불완전한 것으로 임시땜빵을 하는 방법은 분야를 불문하고 방법론이 다 비슷해 보인다~!

3.
예전에 PC에서는 ICQ, MSN, 그리고 국내 한정으로 네이트온 같은 온라인 메신저가 있었다. 얘들은 시대가 시대이다 보니 PC 전용이었는데, 2010년대 들어서는 다들 망하고 스카이프만이 MS에 인수되어 살아 있는 듯하다.
2010년대에는 카카오톡이 스마트폰 앱과 PC 통합으로 메신저 시장을 사실상 평정했다. PC는 사람이 기계가 있는 곳으로 가서 기계의 전원을 넣어야만 쓸 수 있는 반면, 스마트폰은 365일 24시간 내내 켜져 있으며 사람이 늘 들고 다닌다. 이런 결정적인 차이로 인해 카카오톡은 과거의 메신저와는 달리, 자기 상태를 표시하는 기능이 없다~! (available, away, out to lunch 같은)

카카오톡은 PC용이 있기 때문에 PC와 모바일을 지원한다.
한편, SNS 웹사이트로 출발한 페이스북도 메신저 기능이 있으니, 모바일과 '웹'을 지원하는 셈이다.
예전에 잠시 있었던 Google Talk은 PC용 프로그램, 모바일용 앱에다가 gmail 같은 Google 계열 사이트에서 실시간 대화도 지원하여 드물게 PC, 모바일, 웹을 모두 커버했던 걸로 기억한다.
이렇게 애플리케이션들이 실행 양상이 다양해지고 있는 게 흥미롭다.

그리고 2010년대부터는 웹 자체도 사용자 상호작용과 반응성이 워낙 좋아진 관계로 PC용 네이티브 프로그램까지는 몰라도 모바일 앱의 정체성을 크게 위협하고 있다..
물론 기기의 물리적인 기능에 아주 특화된 기능이라든가 방대한 게임 같은 건 모바일 기기에서 직통으로 돌아가는 프로그램이 필요하겠지만, 단순 서버와의 교신과 정보 공유, 조회, 열람이 목적이면 웹 페이지와 자바스크립트 자체를 그냥 기계와 운영체제를 초월한 통합 GUI 플랫폼으로 쓰지 말라는 법이 없게 되는 셈이다.

순수 웹 애플리케이션은 서버 주소만 알려주면 앱스토어 심사 같은 것도 필요 없고 곧장 배포가 가능하다. 웹 전체를 검열하는 빅 브라더 같은 건 세상에 존재하지 않으니 말이다.
그러나 웹을 기반으로 안드로이드와 iOS를 모두 통합하고, 부분적으로 각 모바일 플랫폼에 종속적인 코드를 끌어다 쓸 수 있는 형태인 '하이브리드' 앱이 있다. 그리고 그런 걸 만들어 주는 프레임워크도 있다. qt가 PC에서 Windows/리눅스/macOS 통합이라면, 아이오닉 같은 모바일 프레임워크는 안드로이드/iOS 통합인 셈이다.

'아이오닉'은 하이브리드 자동차의 이름이기도 한데 컴퓨터에서도 나름 하이브리드 모바일 프레임워크의 이름이구나(비록 영어 철자는 차이가 있지만). 디스크와 드럼(브레이크 vs 메모리 기술), 엑셀(자동차 이름 vs 스프레드시트 이름)처럼 들린다.

4.
웹은 기계와 CPU 아키텍처에 구애받지 않는 정말 universal한 프로그래밍 환경이다. 그 누구도 처음에 상상하는 것조차 쉽지 않았다.
인터넷에서 다른 형태의 프로토콜로 제공되는 서비스들도 거의 다 웹이 몽땅 독식해 버렸다. 글과 그림과 하이퍼링크만 있는 문서에 불과하던 웹은 한 2, 30년쯤 전의 옛날 얘기이고, 지금은 이게 그냥 인터넷의 알파와 오메가요, 문서와 코드의 짬뽕인 광활한 프로그래밍 환경이다. 그러니 웹 프로그래밍을 하나 잘 공부해 놓으면 그야말로 모든 기계에서 똑같은 결과가 나오는 프로그래밍 스킬을 얻게 된다.

웹이 그런 공룡 같은 거대한 환경으로 발전하는 과정에서 브라우저, 언어 등 각종 규격들이 찢어졌다가 표준화된 과정도 살펴보면 참으로 격세지감이 느껴지는 한편으로, 인간 사는 바닥은 어디든 다 정치와 밥그릇 싸움, 돈지랄이 있구나 하는 병맛스러움이 느껴진다.

HTML4의 지저분함을 참다못해 1990년대 말에 엄격한 XHTML이 제정되었지만, 결국 망하고 HTML5가 다시 옛날 관행 기반에서 제정된 건.. 1990년대 말에 IA64가 너무 과격한 변화를 추구하다가 망하고 기존 x86 호환성을 유지한 amd64로 64비트 컴퓨팅의 판도가 기운 것과 비슷해 보인다. 시기도 서로 비슷한 편이다.

또한 Windows 10이 2015년 가을에 나온 첫 판이 지금까지 그대로 유지되고 있는 게 절대 아니듯, HTML5도 보아하니 한번 정하고 영원히 고정이 아니라 찔끔찔끔 계속 뭔가 추가되고 있긴 한 모양이다. 그렇기 때문에 전통적인 ACID 테스트 말고 또 2017년 현재까지 만점을 받은 브라우저가 전혀 없는 다른 HTML5 점수 테스트 사이트도 있다.

한편으로 HTML4 이래로 무려 15년 가까이 뒤에야 HTML5가 제정되고 HTML이 급격히 발전하고 있는 건 C++98 내지 C++03 이후로 C++이 2000년대에 정체돼 있다가.. C++1x 이후로 C++이 함수형 패러다임도 받아들이고 네이티브 코드 생성 언어가 갑자기 약 빤 듯이 발전하고 있는 양상과 비슷해 보인다.

웹이 MS Office 문서라면 자바스크립트는 VBA 매크로와도 같은 물건이다. 그리고 내가 HTML, CSS, JS를 삼권분립과 비슷한 구도라고도 비유한 바 있다. 게임 개발에다 비유해도 기획자, 디자이너, 개발자에 착착 잘 대응하는 것 같다.
아 그래..! 옛날에는 이런 스크립트 자체가 단일화되지 않아서 HTML 주석 안에다가 스크립트 코드를 몰래 집어넣어야 했다. 마치 프레임만큼이나 "이 웹페이지를 제대로 표시하려면 자바스크립트를 지원하는 브라우저가 필요합니다" 이런 말이 출력되도록 참 기괴하게 HTML 문서를 작성했었다. 이거 도대체 언젯적 얘기냐..;;

또한, 웹 프로그래밍에 스크립트는 클라이언트 쪽만 있는 게 아니라 서버 쪽도 있다. 클라이언트는 처리가 빠른 대신 대외적으로 프로그램 소스 코드가 몽땅 공개돼야 한다. (뭐, 난독화는 가능하지만) 서버 쪽은 소스가 노출되지 않지만 데이터 입출력에 서버와 네트워크 트래픽을 감수해야 한다. 이것도 컴퓨터 한 대에서만 돌아가는 프로그램을 만들 때에는 고려할 필요가 없는 흥미로운 면모이다.

이런 와중에 마소는 20여 년 전 1990년대 중반에 Bob이라든가 MSN 이런 거 만들면서 좀 삽질을 했었다. Windows 95를 만들어서 개인용 PC의 운영체제는 자기 뜻대로 세계정복을 했지만, 인터넷까지 자기 서비스만으로 호락호락 세계를 정복할 수 있으리라 생각했던 건 큰 오판이었다. 그래서 잘 알다시피 IE를 수단과 방법을 가리지 않고 운영체제에다 끼워넣어서 웹 브라우저의 전면무료화 관행을 정착시켜 버리기도 했다. 하지만 IE 자체는 경쟁 브라우저와 모바일 환경 때문에 세계정복까지는 이루지 못했다.

또한 마소는 2000년대 말에 와서는 PC에 너무 안주하고 모바일 환경에 대해서도 대수롭지 않게 예상하다가 스마트폰 플랫폼의 주도권을 안드로이드와 iOS에 완전히 뺏겨 버렸다. 그 시기에 LG전자가 피처폰에 안주하다가 지금 같은 처지가 된 것과 비슷한 실수이다.
그런데 2000년대 중후반엔 나조차도 솔직히 말해 사고의 구조가 "그냥 디카 쓰면 되지 폰에다가 카메라를 왜 얹어?" 이러던 수준이었다. 어지간한 전문가라도 스마트폰이 이렇게 뜨고, 그 스마트폰 OS를 오픈소스로 전세계에 뿌려 버리는 괴수 용자 대인배가 등장할 거라고는 예상할 수 없었다.

즉, <미래로 가는 길> 같은 베스트셀러 책을 이미 1990년대 중반에 썼던 천하의 빌 게이츠조차도 웹과 모바일에 대한 전망이 다 적중하지는 못했다. 뭐, "손가락 끝으로 모든 정보를" 같은 큰 그림이야 물론 적중했지만, 그런 기술이 언제나 자기가 원하는 형태로 보급되고 마소 주도적으로 이뤄지지는 않았다는 것이다.

그나저나, IA64 하니까 떠오르는데.. 소프트웨어 업계에서는 2000년 가을쯤 Windows ME와 아래아한글 워디안도 비슷하게 세기말의 흑역사 삽질을 좀 했다는 공통점이 있다.

Posted by 사무엘

2017/12/17 08:31 2017/12/17 08:31
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1438

Trackback URL : http://moogi.new21.org/tc/trackback/1438

Comments List

  1. Lyn 2018/02/02 02:28 # M/D Reply Permalink

    역시 세기말은 위험하군요

    1. 사무엘 2018/02/02 06:15 # M/D Permalink

      그러게 말입니다. 자기 실제 상황을 제대로 파악 못 하고 붕 뜬 분위기 쫓아가느라 분야별로 여기 저기 삽질이 속출했었습니다.
      (Lyn 님, 오랜만이네요~! 올해의 첫 댓글을 남겨 주셔서 고맙습니다~ ^^)

Leave a comment

오늘은 기초 전산학/컴공 상식을 좀 복습해 보고자 한다.

※ 지금과 같은 컴퓨터의 근간이 갖춰진 과정

1. 순 전자식

이로써 인간이 발명한 계산 기계는 엔진 달린 주판 수준을 넘어서 자신의 모든 내부 상태를 전자 신호만으로 광속으로 표현할 수 있게 됐다. 에니악이 순 전자식 컴퓨터로서는 거의 최초 원조라 여겨진다. 이거 이후로 컴퓨터는 진공관, 트랜지스터, IC, (V)LSI 회로 순으로 그야말로 엄청난 공간 워프를 거듭하면서 작아지고 빨라지기 시작했다.

전자식이 아니라면? 컴퓨터도 엔진이나 모터가 달린 채로 만들어졌을 것이다. 19세기에 영국의 수학자 찰스 배비지는 '프로그래밍 가능한 보편적인 계산 기계'인 '해석 기관'이라는 걸 제안하고 만들려 했다. 시대를 아득히 앞서 간 물건이었는데, 그걸 가동하기 위해서 무려 증기 기관을 접목할 생각까지 했었다. 지금 같은 눈부신 전자 공학 기술이 없던 시절이니 당연히 기계식밖에 선택의 여지가 없었던 것이다.

그리고 1940년대 초에 에니악 이전에 등장했던 '하버드 마크 1'이라는 기계는 '전자식 계산기'라기보다는 '전동식 계산기'에 더 가까웠다. 복잡한 배선과 릴레이뿐만 아니라 4마력짜리 모터가 달려 있었다. 이건 냉각팬 모터가 아니며 하드디스크 같은 기계식 보조 기억장치용 모터도 아니고, CPU의 실제 계산 동작을 위한 모터였다..;;

2. 2진법 기반

사람이나 열 손가락이 달려 있으니 10진법이 편하지, 기계는 단순한 2진법이 더 편하다. 컴퓨터가 전자식으로 바뀐 뒤부터는 그 차이가 더욱 두드러졌다.
하지만 극초창기에는 숫자 진법을 변환하는 것조차 쉬운 작업이 아니었고, 정수가 아닌 부동소수점으로 가면 숫자를 표현하는 난이도가 더 올라갔다. 더구나 컴퓨터는 처음부터 포탄 탄도 예측, 풍동 실험, 일기예보 시뮬, 모의 핵실험처럼 천상 실수 연산이 잔뜩 필요한 과학 영역에서 쓰였다.

그러니 에니악 같은 컴퓨터는 10진법 기반으로 만들어졌다. 4비트를 한 자리로 묶어서 0~9를 표현하는 BCD 코드 기반이었지 싶다. 하지만 10진법 숫자를 처리하기 위해서 어차피 2진법 기반의 각종 논리 연산 회로를 구현해야 했을 것이고, 후대의 컴퓨터들은 얼마 가지 않아 native 2진법 기반으로 다 바뀌었다.

3. 튜링 완전

프로그램이 하드코딩된 고정된 변수가 아니라 메모리에 기록된 값을 토대로 또 임의의 위치의 메모리를 읽고 쓸 수 있고(= 배열, 포인터 등을 이용한 복합 자료형. 공간 확장),
런타임 때 결정되는 값의 조건에 따라 반복과 분기가 가능하다면 (= 시간 확장)
그런 계산 모델은 Turing-complete하다고 여겨진다. 즉, 단순 계산기를 넘어 뭔가 본격적으로 프로그래밍이 가능해진다는 것이다.
그 열악한 에니악조차도 설계 구조는 튜링 완전한 형태였다고 한다.

4. 프로그램 내장형

컴퓨터에게 시킬 작업을 변경하기 위해 매번 회로 배선을 뜯어고치고 바꾸는 게 아니라, 한 메모리에서 코드와 데이터를 일체로 내장시킨다. 이 개념까지 정립됨으로써 비로소 컴퓨터는 정말 유연하고 무한한 확장성을 지닌 물건으로 변모했으며, 컴퓨터에서 하드웨어와 별개로 '소프트웨어'라는 것이 존재할 수 있게 됐다.
또한, 메모리가 컴퓨터의 성능에서 차지하는 비중이 아주 커졌다. 프로그램을 메모리에다 처음으로 입력시킬 때는 과거엔 천공 카드 같은 불편한 매체가 쓰였지만, 나중에는 더 간편한 키보드로 대체됐다.

저 아이템들 하나하나가 그야말로 병아리가 알을 깨고 세상으로 나오는 급의 대격변이고 혁신이었다.
인류 역사상 이런 네 조건을 모두 만족하는 컴퓨터가 발명되고 등장한 지 아직 100년이 채 지나지 않았다. 자동차와 비행기의 역사는 100년을 넘었지만 컴퓨터는 아직 그렇지 않고 오히려 2차 세계 대전 이후 냉전 때부터 발전해 왔다.
그 짧은 기간 동안 컴퓨터가 인류 역사상 유례가 없이 세상을 바꿔 놓은 걸 보면.. 정말 전율이 느껴지지 않을 수 없다.

※ 메모리 계층

컴퓨터는 모름지기 정보를 다루는 기계이다. 그리고 앞서 언급했던 프로그램 내장 방식의 특성상, (1) 실행할 코드와 (2) 그 코드가 처리할 데이터가 모두 메모리에 담겨 있어야 한다. 쉽게 말해 정보를 담을 그릇이 필요하다.
그런데 컴퓨터가 취급하는 메모리라는 게 여러 종류가 있고, 이들은 속도와 용량, 단위 용량당 가격이 극단적으로 반비례하는 관계이다. 그렇기 때문에 종류별로 일종의 '메모리 계층'이 존재한다.

1. 레지스터(수십~수백 byte)

CPU 구성요소의 일부이다. 당연히 CPU 차원에서 최고속으로 직통으로 값을 읽고 쓸 수 있다.
현재 프로그램이 실행되고 있는 지점(메모리 위치), 수만 번씩 실행되는 for 문 loop 변수, C++ 함수의 경우 this 포인터, 산술 연산 명령에 쓰이는 피연산자와 연산 결과 같은 정~말 원초적인 값들이 이곳에 저장된다.
실행되는 스레드의 context가 바뀌면 레지스터의 값도 자기 상태의 것으로 바뀐다.

2. 캐시 메모리(수백 KB~수 MB)

CPU 자체는 아니지만 여전히 CPU의 연장선 격이며 접근 속도가 매우 빠르다. CPU가 사람 두뇌이고 레지스터가 손의 손가락이라면 캐시는 의수 정도는 된다.
얘는 CPU 속도와 메모리 속도의 격차가 커지면서 메모리로 인한 병목을 줄이기 위한 버퍼 차원에서 도입되었다.

캐시도 레벨 1, 레벨 2로 나뉘긴 하는데, 인텔 x86 CPU에서 제일 원초적인 L1 캐시는 80486 때 8K짜리가 도입된 것이 최초이다. 반대로 펜티엄 2이 나왔던 시절에 셀러론 프로세서는 L2 캐시를 제거하거나 용량을 팍 줄인 저가형 모델이었다.

3. 일반 메모리(수십 GB)

CPU의 외부에 있기 때문에 위의 것들보다는 느리지만, 그래도 보조 기억장치보다는 여전히 훨씬 빠르다. 이들 메모리는 전원이 끊어지면 내용이 다 지워지는 휘발성 메모리이다. 이제 신체 접근성으로 치면 의수를 넘어서 핸들과 버튼으로 따로 조작하는 로봇 팔과 비슷하다고 볼 수 있겠다.

4. 하드디스크(수 TB)

디스크부터는 보조 기억장치이기 때문에 이건 CPU의 명령만으로는 직접 접근조차 할 수 없다. 운영체제라는 소프트웨어가 구현해 놓은 파일 시스템에다 해당 운영체제 API를 통해 요청해야만 데이터를 읽고 쓸 수 있다. 파일 시스템은 열고 닫는 상태를 따로 보관하고 관리해야 하며, 프로그램의 입장에서는 여는 작업이 실패하는 상황에 대한 대비가 필요하다.
사람으로 비유하면 내 손으로 뭔가를 직접 조작하는 게 아니라, 남에게 말로 부탁을 해서 간접적으로 뭔가를 요청하고 움직이는 형태가 된다.

그 대신 보조 기억장치는 전원이 끊어진 뒤에도 기록을 남기고 보존할 수 있다. persistency를 보장하려다 보니, 하드디스크는 컴퓨터에서 전자식이 아닌 기계식으로 동작하는 얼마 안 되는 부품 중 하나가 돼 있다. 플래시 메모리는 '일반 메모리'의 성격에 더 근접해 있는 기억장치이지만, 가격과 용량 문제 때문에 하드디스크를 완전히 대체하는 구도는 못 된다.

캐시 메모리에서 캐시 미스가 나서 더 느린 일반 메모리까지 내려가서 데이터를 가져오는 게, 아래의 운영체제의 가상 메모리 체계에서 페이지 폴트가 발생해서 디스크의 페이지 파일에서 데이터를 가져오는 것과 비슷한 구도이다. 메모리 공간 자체가 CPU의 일부는 아니지만, 보호 모드 가상 메모리 구현을 위한 주소 변환은 CPU 차원의 지원을 따로 받아서 이뤄진다.

메모리가 비싸고 귀하고 부족하던 옛날에는 가상 메모리라는 게 디스크를 메모리 보충분처럼 사용하는 메커니즘이기도 했다. 비록 속도는 안드로메다로 가 버리지만, 그래도 아예 안 돌아가는 것보다는 나으니 better late than never이다. 요즘 운영체제들은 memory mapped file이라고 디스크를 반쯤 메모리 다루듯이 포인터로 접근시켜 주는 API를 제공하는데, 가상 메모리를 구현하면서 내부적으로 구현된 기능을 사용자도 적절하게 활용하라고 떼어 준 것에 가깝다.

또한, 가상 메모리와는 별개 개념으로.. 레지스터와 메모리 사이에 '캐시 메모리'가 있듯이, 메모리와 디스크 사이에 '디스크 캐시'라는 계층이 존재한다. 이게 잡아먹는 메모리 양이 만만찮지만 도스 시절에 smartdrv 유틸로 수백 KB~2MB 남짓만 캐시를 잡았어도 체감 성능 향상 효과가 장난이 아니었다. 이거 없이 곧이곧대로 찔끔찔끔 디스크에 접근해서는 오늘날의 방대한 컴퓨터 시스템이 돌아가질 못한다. 그만치 메모리와 디스크 사이의 속도 격차 병목이 엄청나다는 뜻이다.

5. 자기 테이프(수백 TB~수 PB)

아주 극단적인 보조 기억장치이다. 느리고 랜덤(임의 위치) 접근이 안 된다는 엄청난 단점이 있지만, 용량이 가히 압도적이고 가격이 저렴하다. 그렇기 때문에 서버 전체 내지 매일 생성되는 방송국 동영상 같은 엄청난 양의 데이터를 오로지 백업· 보존만 할 목적으로 일부 연구소나 기업에서 테이프가 여전히 사용되고 있다. 마치 국제 화물 운송에서 선박이 차지하는 위상(느리지만 엄청난 수송량)과 비슷하고, 프린터계에서 도트 프린터의 먹끈 카트리지(원시적이지만 타의 추종을 불허하는 저렴함)와 비슷하다.

메모리야 컴퓨터 프로그램들이 맨날 하는 짓이 저걸 건드리는 것이고, 보조 기억장치는 파일을 읽고 쓰는 운영체제 API를 통해 사용 가능하다.
레지스터의 경우, C/C++ 언어에는 특정 정수 변수를 가능한 한 저기에 얹어 달라고 컴파일러에게 요청하는 register이라는 키워드가 있다. 함수에 inline이 있다면 변수는 저게 있는 셈이다. for문 loop 변수가 레지스터에 올라가면 좋다.
물론, inline 함수는 재귀호출을 해서는 안 되며, 레지스터 등재 변수는 주소 참조(단항 & 연산자)를 해서는 안 된다.

이렇게 타 메모리나 디스크나 레지스터와는 달리, 캐시 메모리만은 적중률을 올리기 위해 소프트웨어가 직접 접근하고 개입하는 방법이 딱히 존재하지 않는다. 멀티코어 병렬화를 위해서는 CPU 직통 명령인 인트린식 같은 것도 있는데 캐시는 활용 방식이 소프트웨어가 아닌 오로지 CPU의 재량인가 보다.
이렇게 존재감이 없음에도 불구하고 캐시 메모리의 양과 성능은 클럭 속도 다음으로 컴의 속도에 직접적인 영향을 끼치는 요인이다.

※ 인텔 x86

인텔 x86은 전세계의 PC 시장을 완전히 석권한 기계어 아키텍처이다. 애플 맥 진영이 x86으로 갈아탄 지 이미 10년이 넘었고, 슈퍼컴퓨터조차도 Cray 같은 슈퍼컴 전용 아키텍처가 진작에 다 망하고 x86이 코어 수를 늘려서 야금야금 파고들고 있다.

하지만 x86은 CPU를 만들던 기술과 방법론이 지금과 같지 않던 초창기, 특히 메모리 가격이 왕창 비싸던 시절을 기준으로 기반이 설계되었으며 16, 32, 64비트로 올라가는 과정에서도 하위 호환성을 잘 유지하고 있다. 그래서 넘사벽급의 범용성과 시장 경쟁력은 확보했지만, 내부 구조가 갈수록 왕창 지저분해지고 스마트폰용 ARM 같은 후대의 최신 CPU들의 유행과는 영 동떨어진 형태가 됐다.

  • 범용 레지스터 수가 유난히 매우 적음. R## 이렇게 수십 개씩 번호가 붙는 게 아니라 EAX EDX ESI EBP 등 꼴랑 8개로 끝인 건 x86이 예외적이고 특이하기 때문이다. 함수에다가 매개변수를 올리는 주 방식도 x86은 당연히 레지스터가 아닌 스택 기반이다. 이 때문에 컴파일러 백 엔드를 개발하는 방법론이 x86 타겟 계열과 타 아키텍처 계열은 서로 완전히 다르며, x86은 오늘날 컴공과에서 컴파일러 제작 교육용 교보재로 쓰이기에는 영 좋지 못한 타겟 아키텍처이다.
  • 메모리를 조밀하고 compact하게 쓰는 대신에, 디코딩이 복잡하고 더 어려운 CISC 가변 길이 방식으로 명령어를 기술한다. 한 인스트럭션으로 연산에다 메모리 조작까지 몽땅.. 이런 식으로 많은 지시를 함축하고 있는 편이다. 자동차 엔진으로 치면 회전수가 낮은 대신 실린더의 스트로크가 긴 디젤처럼..
  • machine word align이 맞지 않은 메모리 주소의 값을 fetch하는 것을 굉장한 비효율(여러 클럭수 소모)을 감수하고라도 CPU 차원에서 아무 문제 없이 잘 처리해 준다. 요즘 CPU 같았으면 그냥 예외 날리고 끝이었을 텐데.. 이 역시 메모리를 아끼기 위한 조치이다.

레지스터가 부족하면 나중에라도 더 보충하면 되지 않냐고?
레지스터는 추가로 더 꽂기만 하면 되는 메모리가 아니라 CPU 그 자체이다. 그걸 뒤늦게 확장한다는 건 CPU의 아키텍처, 세부 설계와 생산 라인이 다 바뀐다는 뜻이다. 컴파일러도 그에 맞춰 바뀌고 프로그램도 몽땅 다시 빌드되어야 추가된 레지스터 덕을 볼 수 있다. 사람으로 치면 가방 크기를 더 키우는 게 아니라 생물의 유전자 차원에서 손의 크기, 손가락 개수를 더 키우고 늘리는 것과 같은 엄청난 변화이다.

x86이 너무 지저분하다는 건 제조사인 인텔도 누구보다 잘 알고 있었기 때문에 과거 2000년대 초, 64비트 CPU를 내놓는 김에 애플처럼 하위 호환성을 싹 버리고 현대적인 디자인 트렌드를 따라 과감한 물갈이를 하려 했다.
마소 역시 새천년 Windows 2000에 맞춰 64비트 에디션을 당당히 내놓으려고 벼르고 있었다. Windows SDK 헤더 파일에서 INT_PTR, INT64 이런 typedef가 등장하고 GetWindowLong이 GetWindowLongPtr로 감싸진 게 이 시기의 준비 작업이었다.

하지만 모두의 예상을 깨고 IA64 Itanium라는 새 아키텍처는 CPU와 컴파일러 개발이 제대로 되지 않고 호환성도 안습했기 때문에 철저히 망하고 실패했다.
결국 지금은 기존 x86을 그대로 수용하면서 Itanium보다 훨씬 더 현실과 절충한 x86-64라는 다른 아키텍처를 기반으로 64비트 컴퓨터가 쓰이게 됐다. 이 아키텍처는 인텔이 아니라 경쟁사인 AMD가 최초로 개발했다.

Windows 2000은 과거 NT 3~4 시절에 지원했던 한물 간 구형 CPU들의 지원은 다 끊었고(Alpha, PowerPC, MIPS 등), IA64는 베이퍼웨어이고, 지금 같은 ARM이나 x64는 아직 안 나왔다 보니 NT로서는 이례적으로 사실상 x86 전용으로만 출시되어야 했다.

그런데.. 인텔 x86이 저렇게 메모리 아끼려고 CPU 본연의 효율까지 희생하면서 헝그리하게 설계된 건 과거 PC의 역사를 살펴보면 충분히 이해가 된다.
32비트 80386 CPU가 이미 1985년에 개발됐는데도 Windows NT, OS/2 같은 이상적인 32비트 운영체제의 도입과 보편화가 10년 가까이 너무 늦었고 Windows 9x 같은 요물이 몇 년간 쓰여야 했던 이유는 32비트 가상 메모리를 운용하고도 남을 정도로 컴의 메모리가 충분치(못해도 수~십수 MB) 못했기 때문이다. (CPU 말고 그래픽 카드는 1987년에 VGA가 개발되자 못해도 2~3년 안으로 프로그램들이 다 지원하기 시작함)

64비트로 넘어갈 때도 마찬가지다. IA64가 개발되던 1990년대 말엔 아직 가정용 컴의 메모리는 100~200MB대에 불과했다. 32비트를 벗어나야 할 이유가 전혀 없었다. 64비트 CPU는 대용량 데이터 처리 분야에서 속도가 좀 더 올라갈지는 모르지만, 같은 명령과 데이터를 수행하더라도 메모리 소모가 훨씬 더 많아지는 건 피할 수 없었다. 이러니 가정용 PC에서 64비트의 대중화는 Windows 2000/XP 시기는 어림도 없고, 본격적으로 램 용량이 4GB를 넘어선 2000년대 후반 Vista/7급은 돼서야 이뤄지게 됐다.

Posted by 사무엘

2017/12/11 08:31 2017/12/11 08:31
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1436

Trackback URL : http://moogi.new21.org/tc/trackback/1436

Comments List

  1. 비밀방문자 2017/12/11 18:28 # M/D Reply Permalink

    관리자만 볼 수 있는 댓글입니다.

    1. 사무엘 2017/12/13 00:42 # M/D Permalink

      우와.. 펫졸드 아저씨가 Windows 프로그래밍 책만 썼는 줄 알았는데,
      역시 올드 타이머 프로그래머답게 컴퓨터라는 기계가 밑바닥에서 처음부터 만들어져 온 과정을 고찰한 입문서도 몇 년 전에 썼구나?
      아주 흥미로운 내용일 것 같고 나도 책 내용이 궁금해진다? 우와아앙??

  2. 경헌 2017/12/12 19:17 # M/D Reply Permalink

    윗 댓글의 책이 뭘지 저도 알 것 같군요 ㅎㅎ
    오랜만에 생각난 김에 다시 한 번 읽어봐야 겠습니다.

    레지스터 - 캐시 - 메모리 - 디스크의 메모리 계층에서, 반드시 가격만이 용량을 결정한 요소인가 하는 의심이 들더군요.
    레지스터나 캐시의 경우에는 필요 이상으로 크게 만들면 어쩔 수 없이 속도가 떨어지게 되는 구조상 문제도 있지 않을까 싶어요.

    그리고 최근 들은 세미나에서, 미래의 아키텍처에서는 3. 일반 메모리와 4. 하드디스크의 경계가 희미해져 갈 것이라는 이야기를 들었습니다. SSD 에서 시작해서 비휘발성 메모리가 점점 싸고 빨라지고 있기 때문인데, 굳이 프로그램을 휘발성 고속 메모리에 올리고 실행할 필요 없을 정도로 빨라지고 나면 OS 수준에서 많은 것들이 달라지게 되지 않을까 이야기 하더군요.

    1. 사무엘 2017/12/13 00:49 # M/D Permalink

      하하! 경헌 님도 대단하십니다. ^^
      레지스터와 캐시는 제가 그 정도 본질까지 논할 수 있는 실력이 못 됩니다만, 일반 메모리와 하드디스크는.. 흥미롭네요. 일반 메모리의 속도와, 하드디스크의 비휘발성에서 일장일단이 아니라 두 토끼를 다 잡는 메모리가 나온다면 두 계층 구분이 당연히 사라지겠죠.
      SSD 때문에 전통적인 조각 모음이라는 게 의미가 없어졌듯이, 그런 미래의 모델에서는 memory-mapped file이라든가 디스크 캐시라는 것도 개념이 재정립될 듯합니다.

Leave a comment

1. Windows 부팅

Windows 8 내지 10부터던가.. 요즘 Windows에서는 예전까지 오랫동안 쓰이던 통상적인 부팅 전 F8 메뉴가 사라졌다. 하긴, 메뉴가 여럿 있긴 했지만 고르는 건 안전 모드(F5) 또는 네트워크 되는 안전 모드 둘 중 하나밖에 없긴 했다.
그 대신, 부팅 후에 컴을 팩토리 리셋 초기화시키는 메뉴가 곧장 들어간 것은 일단 꽤 유용하며, F8을 눌러야 할 필요를 이걸로 상당수 대체하긴 했다.

하지만 뭐가 꼬여서 애초에 부팅이 안 되고 있을 때는 이 기능에 접근할 수 없어서 더 불편해졌다. 부팅 전의 OS 재설치 및 복구 UI는 사용자가 특정 글쇠를 눌렀을 때 바로 뜨는 게 아니라, 수차례 컴퓨터를 혹사시키면서 부팅이 실패한 것을 얘들이 인지했을 때에 그제서야 슬그머니 띄워 준다. 로직을 왜 이런 식으로 만들었나 모르겠다.

전에도 얘기했듯이, 본인은 업데이트를 받은 뒤에 운영체제가 꼬이고 커널 패닉 뜨는 걸 몇 번 겪은 뒤부터는 진절머리가 나서 업데이트 받는 걸 레지스트리까지 조작해서 강제로 끊어 버렸다. 지금 네트워크는 유료 종량제이니 니 멋대로 함부로 업데이트 받아서 설치하지 말라고 말이다.

CPU와 메모리와 네트웍 트래픽 잡아먹고 하드디스크 용량 잡아먹고, 컴퓨터를 꺼야 할 때 바로 곧이곧대로 꺼지질 않고.. 민폐가 너무 심한 데다, 그런 민폐가 시도 때도 없이 너무 자주 발생하고.. 설치 후에도 뭐가 크게 달라지고 좋아지기는커녕 저런 부작용만 있으니 이 상황에서 누가 업데이트 꼬박꼬박 받고 싶은 마음이 들겠는가?

그거 안 하고도 내 컴은 악성 코드고 뭐고 지금까지 보안 문제 같은 건 하나도 없었다. 이러다가 업데이트에 대해서조차도 현대 서양 의학 불신, 백신 불신 같은 이상한 풍조가 생기지는 않으려나 모르겠다만.. 브라우저를 선택할 권리 운운하면서 웹 표준 외치는 것만큼이나, 필요하지 않은 업데이트를 안 받거나 원하는 타이밍에만 받을 권리도 좀 보장됐으면 좋겠다.

2. 바이오스

뭐, 이건 운영체제 얘기였고 그 전에 롬에 탑재된 컴퓨터 고유의 소프트웨어 계층을 일명 BIOS라고 부른다. 이것도 2010년대에 와서는 UEFI라는 새로운 규격으로 바뀌었다.
운영체제 부팅 전에 BIOS 셋업(CMOS 셋업이라고도 불렀던 듯..)을 들어가려면 ESC, F2, F10, Del 이런 글쇠를 죽어라고 누르곤 했는데, 이 글쇠도 좀 Ctrl+Alt+Del 재부팅처럼 통일이 됐으면 하는 생각이 든다. 바이오스는 어차피 만드는 업체도 피닉스나 아메리칸 메가트렌드 요렇게 아주 소수이지 않던가?

살면서 BIOS setup으로 들어가야 하는 상황은 몇 년에 한 번꼴로 운영체제 변경· 재설치를 위해 부팅 매체 선택 순서를 변경할 때.. 혹은 하이퍼-V 가상화 같은 옵션을 켜고 끌 때 정도이지 싶다. 살다가 병원이나 법원, 경찰서, 주민센터 같은 델 들르는 빈도와 비슷한 격이다.

옛날에는 컴퓨터를 켠 직후에 숫자가 쫘르륵 올라가면서 주 메모리 테스트를 하는 게 관행이었는데 그 광경도 참 오래 전에 사라졌다. 램의 용량이 수백 MB 수준으로 넘어간 시기, 대략 21세기 초쯤부터 없어진 것 같다. 글쎄, 카운트만 안 보여줄 뿐, 내부적으로 여전히 테스트는 하는 걸 수도 있음.

그리고 요즘 컴퓨터는 바이오스 셋업 화면도 텍스트가 아닌 그래픽 모드로 바뀌었고 마우스가 지원된다. 저기는 한글화의 영원한 불모지라고 여겨졌는데 이젠 그것도 아니다. 마소처럼 11172자 완성형 글립을 다 때려박은 게 아니라 이야기체 같은 8*4*4 조합형 비트맵 글꼴을 쓴 것도 있어 더욱 반갑다.

바이오스 차원에서 하드디스크에 predefined type이 40몇 가지 정도 있던 시절도 있었는데.. 안 변하는 것 같아도 이 바닥도 하드웨어의 발전을 따라서 많이 변하고 있다.
그나저나 애플 제조 컴퓨터들은 바이오스 계층도 자체 개발인 거겠지? (켠 직후에 흰 화면에 빵~~! 소리, 그리고 alt 눌러서 부트캠프 동작..)

3. 글꼴

수 년 전부터 개인적으로 '감지'는 했던 현상인데, 어떤 컴퓨터는 글꼴 대화상자를 열어 보면 황당하게도 Times New Roman이나 Courier New 같은 필수 기본 글꼴이 목록에서 빠져 있고 선택 가능하지 않았다. 물론 그 컴퓨터에 실제로는 해당 글꼴이 멀쩡하게 잘만 설치돼 있다.
게다가 더 황당하게도 MS Word 같은 프로그램에서는 그 글꼴을 선택할 수 있었고 메모장이나 워드패드에서만 안 나왔다. 내 경험상 이건 컴퓨터마다 케바케로 발생하는 듯하고 Windows 7 이상 2010년대부터 종종 보였다.

처음엔 글꼴 목록에 영향을 끼치는 악성 코드가 있기라도 한지 의심을 했다. 하지만 알고 보니 이 현상에 대한 해답이 따로 있었다.
"제어판-글꼴-글꼴 설정"으로 들어가서 "언어 설정에 따라 글꼴 숨기기" 옵션을 끄면 사라졌던 Times, Courier 같은 글꼴을 다시 선택할 수 있다. (Designed for your language settings)

Windows 7부터 등장한 옵션은 맞아 보인다. 그런데 멀쩡한 글꼴을 선택할 수 없게 만드는 옵션은 대관절 도대체 왜 도입됐는지 모르겠다. 그런 옵션을 굳이 넣을 거면 글꼴 선택 대화상자 내부에다가 넣거나 show all 같은 버튼이라도 넣어야지 왜 제어판 깊숙한 곳에다가 짱박아 놓았는지도 알 길이 없다.

4. PNG

한때 GIF라는 그림 파일 포맷이 있어서 웹에서 정말 많이 쓰였다. 압축률 좋고 투명색과 애니메이션, progressive 렌더링 같은 독보적인 장점 기능이 많았다. 그러나 GIF는 내부의 압축 알고리즘에 특허가 걸려 있어서 아무나 활용하기가 곤란했다.

물론 이미 만들어진 그림 파일을 보기만 하는 사용자 입장에서는 제약이 걸리는 게 전혀 없고, GIF 파일을 생성하거나 디코딩하는 프로그램을 상업용 제품에다 직접 얹는 제조사의 입장에서 로얄티 같은 게 들었던 것 같다. 휴대용 MP3이나 WMA 재생기를 만들 때처럼 말이다. 전자는 프라운호퍼 연구소에, 후자는 마소에 특허든 저작권이든 뭐든 걸려 있다.

그래도 이 특허는 저작권 자체의 보장 기간(70년)보다는 기간이 훨씬 짧았던 모양이다. 2005년경에 특허가 풀리긴 했다. 그러나 gif는 트루컬러를 지원하지 못한 채 256색에서 발전이 멈춰 버렸기 때문에, 오늘날은 대체제인 PNG에 밀려 서서히 사장되는 중이다. 웹에서 사진용 손실 압축은 JPG가, 그 밖의 범용적인 비손실 이미지는 PNG가 시장을 나란히 양분하는 중이다.

PNG는 GIF보다 압축률이 더 좋고 트루컬러도 지원하며, 단순 color key 기반 투명보다 더 발전한 알파채널도 지원한다. 심지어 고화질 아이콘을 저장하는 컨테이너로도 이용되고 있다.
그러니 GIF의 대체물이 되기에 손색이 없다. 다만, 알파 채널은 1990년대 PNG의 첫 버전과 동시에 등장한 게 아니라 나중에 추가된 확장 규격이기라도 한지, 제대로 지원하는 프로그램이 여전히 적어서 아쉽다.

또한 PNG도 애니메이션 기능은 없다. APNG라는 규격이 있기는 하지만 웹 표준이 아니기 때문에 파이어폭스 같은 극소수의 브라우저 말고는 지원하지 않는다. 플래시가 없어지고 브라우저 자체의 동영상 코덱 규격조차 표준화가 논의되고 있는 와중에 애니메이션용 이미지도 더 늦기 전에 표준이 마련되고 모든 브라우저들이 지원해 줘야 하지 않나 생각이 든다. 하긴 옛날에는 동영상도 코덱 파편화가 무진장 심해서 '통합 코덱' 이러면서 혼란이 말도 아니긴 했었다.

5. high DPI 관련

Windows에서 high DPI 지원 정책은 한번 만들어 놓은 걸로 끝이 아니고 버전을 거듭할수록 마개조를 거듭하고 있다. 심지어 같은 Windows 10에서도 새 업데이트에서는 새 기능이 들어갔다.

8.1에서인가 그때부터 per-monitor high DPI이라는 게 도입된 걸로도 모자라서 이제는 아예 스레드별로 high DPI-aware 여부를 지정하고 그걸 on-the-fly로 변경하는 기능까지 추가됐다.
DPI의 변경은 너무 파격적인 변화여서 원래는 재부팅이 필요했으며, Windows Vista 시절에는 믿어지지 않지만 관리자 권한까지 필요하던 작업이었다. 그리고 어차피 제대로 대비가 돼 있는 유연한 프로그램도 매우 드물기 때문에 변경이 권장되지 않기도 했다.

그랬는데 그게 그래픽 카드의 성능 발달 덕분에 실시간 변경이 가능한 기능으로 서서히 바뀌어 간다. 그래도 마소는 레거시 호환성에도 목숨을 거는 곳이니, DPI 변화의 대비가 안 돼 있는 레거시 프로그램은 그냥 가상화 샌드박스빨로 통째로 속이고 말이다. Windows의 역사상 동일 기능이 위상이 이렇게 드라마틱하게 변한 다른 예는 찾기 어려울 것이다.
원래 화면 해상도나 색깔수를 바꾸는 것조차 먼 옛날에 Windows 3.x 시절에는 재부팅이 필요한 작업이었지만 9x/NT부터는 실시간 변경이 가능해졌지 않던가? DPI 변경도 그렇게 바뀌었다.

그도 그럴 것이, high DPI라는 게 원래는 시력 나쁜 사람을 위한 장애인 접근성에 가까운 잉여 기능이었다. 하지만 21세기에 모니터의 해상도가 급격히 올라가면서 이건 모든 사람에게 필요한 편의 기능이 됐다.

이 점에서 high DPI는 마치 자동차의 자동 변속기와도 비슷한 구석이 있다. 원래 자동 변속기 전용 면허는 왼발용 페달, 오른손용 다기능 스위치, 시청각 장애인용 볼록 거울처럼 장애인의 운전을 위한 여러 면허 조건 중 하나였다. 자동 변속기가 운전하기가 훨씬 더 쉬우니 장애인에게도 더 유리하니까 말이다. 그랬는데 자동 변속기가 워낙 대중화되고 나니 자동 전용 면허만은 1997년부터 일반인도 취득 가능하게 바뀐 것이다.

원래 화면 확대 배율이 기본값인 동시에 최소값일 때의 DPI 값은 96이었다. 이건 사실상 하드코딩된 채 쓰여 온 값인데, 언제부턴가 Windows SDK 헤더 파일을 보니 요게 USER_DEFAULT_SCREEN_DPI 라는 상수 명칭으로 추가되었다. 마치 마우스 휠의 기준값인 WHEEL_DELTA (120)과 성격이 비슷해 보이는데, 아무튼 GetDeviceCaps(hDC, LOGPIXELSX)의 리턴값과 저 96의 비율을 계산하면 확대 배율을 얻을 수 있다.

그런데 Windows가 존재하는 한 LOGPIXELSX와 LOGPIXELSY의 값이 서로 달라질 일은 설마 없겠지..?
모니터가 일부러 종횡비가 더 큰 와이드 화면으로(4:3 → 16:9) 바뀐 와중에, 논리적인 화면 종횡비를 또 보정해야 하는 건 옛날 CGA 640*200이나 허큘리스 720*348 해상도 시절 이래로 이제 없으리라 여겨진다.

옛날에는 멀티 모니터조차 예견을 못 하고 WM_CONTEXTMENU 메시지에서 마우스 클릭이 아닌 키보드 글쇠는 x, y 좌표가 모두 -1인 것으로 구분하게 스펙을 설계한 적이 있었는데.. 그때와 지금은 참 격세지감이다.
또한, 해상도 차이가 많이 나는 모니터를 둘 이상 연결해서 사용할 때를 대비해서, 이제는 두 모니터가 DPI 설정이 서로 다른 것까지 다 지원해야 한다. 그러니 high DPI를 제대로 지원하는 일이 더욱 복잡해진 것이다.

6. 네트워크가 안 될 때

집에서는 이런 현상이 없는데 회사에서는 가끔씩 멀쩡히 랜선이 꽂혀 있는데도 유선 인터넷이 안 되는 경우가 있다. 이때는 ipconfig /renew를 해 주면 문제가 해결되는 편이다.
때로는 /release도 해야 하고, 한번은 '설정'(제어판 말고)으로 들어가서 네트워크 관련 메뉴 맨 아래의 '전면 초기화'+재부팅까지 한 뒤에야 문제가 해결된 적이 있었다. 그 당시에 무엇이 정확하게 문제였는지 나로서는 알 길이 없지만, 아마 공유기 쪽 문제인 듯하다.

7. USB 메모리 관련

USB 메모리를 꽂아 쓰다 보면.. 분명히 작업을 마쳤고 관련 프로그램들을 다 종료한 뒤, 메모리를 빼려고 하는데 안전하게 분리가 안 된다고 운영체제가 꼬장을 부려서 난감해지는 경우가 있다.
Windows 2000 시절에만 해도 USB 메모리를 무단으로 뽑으면 경고 메시지가 나왔지만, 그게 그렇게까지 위험하지는 않고 괜히 사용자를 불안하게 만들 필요는 없다고 판단되었는지 XP와 그 이후부터는 경고 메시지가 사라졌다. 그러나 그렇다고 해서 무단 분리가 전혀 위험하지 않다는 얘기는 아니다.

USB 메모리를 분리하는 명령은 시스템 트레이에만 있는 게 아니라 의외로 해당 드라이브의 셸 우클릭 메뉴에도 존재한다. 마치 CD롬 드라이브의 우클릭 메뉴에 '디스크 꺼내기' 명령이 있는 것처럼 USB 메모리 드라이브도 우클릭하면 'eject'가 있으며, 이 명령을 이용해서 분리하면 트레이 메뉴 명령보다 성공률도 더 높다고 그런다.

경험상 macOS는 지금까지 쓰면서 USB 메모리 제거가 바로 안 되는 경우를 거의 못 본 거 같다.
그런데 pkg 파일을 열어서 설치하는데.. USB 메모리의 것을 바로 여니까.. insert the "(null)" disc to continue installation 이러면서 설치가 제대로 되지 않았다.
저건 %s 포맷 문자열에다가 null 포인터를 주기라도 했는지 메시지의 형태도 비정상일 뿐만 아니라, 배포 패키지 파일이 깨지고 문제가 있을 때에나 나타날 법한 메시지이다.

하지만 파일이 실제로 깨진 건 전혀 아니었으며, pkg 파일을 하드디스크에다 복사한 뒤에 설치하니까 아무 문제 없이 됐다.
왜 저런 현상이 있는지는 잘 모르겠다.

8. USB가 없던 시절의 컴퓨터 단자

그러고 보니 먼 옛날에.. USB 포트가 없던 시절에는 컴퓨터에 주변기기를 인식시키는 용도로 직렬 포트와 병렬 포트라는 게 있었다.
정확하게 뭐가 직렬 내지 병렬이어서 이런 명칭이 붙었고 서로 어떤 장단점이 있는지 잘 모르겠다. 라디오에 AM과 FM, 인터넷 프로토콜에 TCP와 UDP처럼 일장일단이 있는 관계가 아닌가 생각된다.

직렬 포트는 COMn 이런 이름이 붙어서 주로 마우스나 모뎀이 연결되었다. 그리고 병렬 포트는 LPTn 이런 이름과 함께 프린터나 스캐너 같은 기기가 연결되었으며, 과거에 쓰이던 하드웨어 방식 불법 복사 방지 장치 '락'도 대체로 병렬 포트에다 꽂는 형태였던 것 같다.

으음.. 그럼 외장 하드는 어디에다 꽂았지? 옛날에 하드 디스크끼리 꽂아서 데이터를 복사하는 건 정말 아무나 할 수 있는 일이 아니었다.;;
꽂고 나서는 바이오스 설정을 들어가서 이게 무슨 기기인지 설정을 수동으로 해 줘야 했다. plug and play 그런 건 없었다. 코덱이 너무 난무해서 동영상 보는 데 애로사항이 꽃폈고, 유니코드가 없어서 문자 인코딩이 어느 장단에 맞춰 춤을 춰야 할지 알 수 없던 그런 열악하던 시절의 추억이다.

Posted by 사무엘

2017/11/09 08:37 2017/11/09 08:37
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1425

Trackback URL : http://moogi.new21.org/tc/trackback/1425

Comments List

  1. 김 기윤 2017/11/09 09:13 # M/D Reply Permalink

    1. 평소 단순 업데이트할때는 문제가 없는데 가끔 대형 업데이트 할 때마다 입력기 설정이 리셋되어서 당황하는 경험이 종종 있었습니다. 재부팅 여러번 하고 Windows.old 폴더가 생기는 것을 볼때 이름만 업데이트고 내부적으로는 아예 새 OS 를 설치하는 동작을 하는게 아닌지 추정합니다.

    2. 지난달까지 2009년에 맞춘 PC 를 사용하다가 이번에 새 PC 를 조립하면서 드디어 UEFI 로 된 바이오스를 처음 사용해 보았습니다.(..) 이에 맞추어(레거시 부팅이 아닌 UEFI 부팅을 위해) SSD도 MBR 에서 GPT 로 다시 맞추어 포맷하고 이것저것 세팅했군요. 가끔 파워 유저는 오버클럭때문에라도 BIOS 들어갈 일이 많다고 하기는 합니다....만 이것도 안정화되면 들어갈 일이 사라지기는 마찬가지군요..;

    4. 트위터에서는 gif 를 올리면 그걸 그대로 저장하고 보여주는게 아니라, 동영상으로 인코딩해서 보여준다고 하는군요. gif 보다도 오히려 동영상이 더 유리하다고 판단했겠지만, 기술 발전이 느껴지기도 하는 부분입니다.

    1. 사무엘 2017/11/09 10:20 # M/D Permalink

      기윤 님! 정말 오랜만에 뵙네요. 반갑습니다. ^^;; 잘 지내시죠?
      1. 네, 그 정도면 서비스 팩 설치 이상급의 중대한 업데이트라고 봐야겠네요.

      2. PC는 최신 사양 게임을 돌린다거나 특별히 생업용으로 왕창 큰 동영상· 이미지(2D/3D) 편집하는 게 아니면, 이제 자주 업데이트 할 일이 없어졌지요. 저도 지금 맥북을 언제 교체하게 될지 모르겠습니다. ^^

      4. 미디어 플레이어 ActiveX 없이, 플래시 우클릭 메뉴 없이 아무 브라우저에서나 웹페이지에서 동영상을 볼 수 있게 된 지가 얼마 안 됐지요. 신기한 일입니다.
      gif만큼이나 Windows의 애니메이션 컨트롤도 위치가 굉장히 어정쩡해진 감이 있습니다. (무압축 또는 완전 초간단 런렝쓰-_-;; 방식으로만 압축된 avi..)

Leave a comment

본인은 평소에는 15년 넘게 개발하고 있는 날개셋 한글 입력기의 개발에 대부분의 역량이 집중되기 때문에 타 유명 프로그래머 고수들에 비해 타 플랫폼· 언어· 최신 프로그래밍 기술에 대한 개인적인 관심은 덜한 편이다. 뭐, 자주 언급을 안 할 뿐이지 직장에서는 아무래도 갑님이 시키는 대로 해야 하니, 무엇이건 업무와 생존에 필요한 최소한의 맛보기 정도는 한다. 다만 그런 생소한 분야는 본인이 특장점이 없이 그냥 여느 평범한 프로그래머 A, B의 역량과 다를 바 없다.

먼 옛날에 Windows API와 MFC, Visual C++를 처음으로 공부할 때 그러했고, macOS나 안드로이드 개발을 처음으로 익힐 때도 마찬가지이다. 코드와 리소스가 어떤 방식으로 연결되는지 감을 잡는 게 참 어려웠다. 이건 그야말로 프로그래밍 언어뿐만 아니라 각 플랫폼별 바이너리 실행 파일(DLL/EXE)의 구조, 개발툴의 기능에 대한 총체적인 이해가 필요한 부분이니까 말이다.

그래도 리소스(대표적으로 대화상자/화면 레이아웃)의 기술을 위해 XML을 쓰는 요즘 플랫폼에 비해, Win32 API의 rc 파일은 정말 구닥다리이구나 싶은 생각이 든다. 뭐, resource.h와 R.java처럼 개념상 일말의 공통점이 발견되는 것도 있다(개발툴이 자동으로 생성해 주는 리소스 ID 리스트).

또한 안드로이드의 경우, 굉장한 뒷북이긴 하다만 Eclair니 Froyo니 하던 시절과 비교했을 때 개발 환경이 몇 년 사이에 정말 엄청나게 달라져 있었다. 여전히 이클립스를 쓰는가 했더니 Android Studio라고 전용 개발툴로 진작에 갈아탔으며, 무엇보다 에뮬레이터도 x86과 arm이라는 엄청난 CPU 구조 차이를 어떻게 극복했는지 속도가 꽤 빨라졌다.
그도 그럴 것이 그 구글 내부에서 안드로이드 OS에만 달라붙어 있는 세계구급 날고 기는 프로그래머 엔지니어들이 도대체 얼마나 되며, 이들이 매일 생산하는 코드의 양은 또 얼마나 될까?

2010년대 이후에나 등장한 IDE가 copyright이 왜 엄청 옛날인 2000부터 시작하는지 궁금해서 검색을 해 봤더니.. 이건 그 옛날부터 개발되어 온 타 회사의 IDE를(이클립스 말고) Google이 인수해서 자체적으로 발전시킨 것이어서 그렇다고 한다. 으음..

이럴 때마다 늘 드는 생각인데, 새로운 문물이나 지식을 아주 빨리빨리 잘 익히고 남에게 가르치는 것까지 가능할 정도로 머리가 좋은 사람들이 개인적으로 굉장히 부럽다. 난 굳이 말하자면 애초에 남이 안 하는 짓을 골라서 하는 일에 일가견이 있다. 그래서 정보 올림피아드도 공모 부문에서만 입상하고, 코딩과 논문으로 그럭저럭 지금까지 지내 왔다.
그게 아니라 남과 똑같은 조건에서 뭔가를 빨리 달달 외우고 응용하는 능력이라면 본인은 남들 평균보다 못하면 못하지 결코 뛰어나지는 않다.

컴퓨터 쪽에 우글거리는 수많은 고수 괴수들 중에.. 김 상형 님이라고 한때 winapi.co.kr 이라는 사이트를 운영했고 지금은 '소프트웨어 공학'을 일본어 스타일로 축약한 '소엔'이라는 사이트로 여러 유용한 프로그램 개발 정보를 무료로 공유 중인 대인배가 계신다.
사이트 이름에서 유추할 수 있듯 한때 이분의 전문 분야는 Windows API였다. 텍스트 에디터를 그냥 C++만으로 혼자서 처음부터 끝까지 다 만들었고, 그 테크닉을 소스까지 통째로 책을 출간한 바 있다..;;

한 분야의 기술만 통달하기에도 벅찬데 이분은 안드로이드, HTML, 자바스크립트 등 온갖 분야를 다 탐독해서 책을 쓰고 학원 강사로 뛰고 있다.
그냥 위에서 내려오는 회사 업무나 감당하기 위해서 여러 기술들을 찔끔찔끔 서바이벌 수준으로 익히는 게 아니다. 그야말로 남을 가르치고 책을 쓸 정도로 전문가가 되기 위해서 혼자서 도대체 공부를 어떤 방식으로 얼마나 한 걸까? 비결이 궁금해지지 않을 수 없다.

이렇게 강의와 저술만으로 먹고 사는 데 지장 없는 분들은 굳이 회사 들어가서 조직에 매일 필요가 없다. 물론 프리랜서는 월급쟁이보다야 소득이 훨씬 불안정하고 복불복이 심하다. 보통은 자기 친구들에게도 "걍 회사에서 월급 받으며 지내는 게 짱이야, 아무리 엿같은 동료나 상사가 있더라도 어지간해서는 거기서 절대로 뛰쳐나올 생각 마라" 이렇게 권유를 할 정도라고는 하지만..
이것도 자기 하기 나름이다. 엄청난 능력자라면 을임에도 불구하고 여러 기업들을 상대로 갑질을 하면서 자유롭고 편하게 일을 할 수도 있을 것이다.

그리고 컴퓨터가 나왔으니 영어도 빠질 수 없다.
지금보다 자료 접근성이 훨씬 열악했던 옛날에 독학으로 이를 악물고 영어를 마스터해서 198, 90년대에 이미 유명 영어 교재의 저자로 등극한 사람들이 참 대단하다는 생각이 든다.
최 은경 어린이 영어, 오 성식 생활 영어/pops English, 김 인환, 정 철 ... 그리고 최근에는 Arrow English로 유명한 최 재봉 이런 분들.

난 무슨 영문과 교수나 영어 교사, CNN 리포터-_-;; 이런 거 지향하는 게 아닌 이상, 국내에서 영어 때문에 스트레스 받을 일은 없는.. "반도 토박이치고는 뭐 그럭저럭 하네" 딱 그 정도까지만 영어가 된다. 자막 없이 영화를 다 알아듣거나, 토익 만점 이런 경지는 아니다. 그리고 그마저도 나이는 자꾸 먹고 있는데 영어를 당장 쓸 일은 없으니 감이 점점 쇠퇴-_-하는 중이다.
도무지 들리지가 않는 것, 그리고 아무리 머리를 짜내도 독해 속도를 도저히 더 올릴 수 없는 건 그냥 내 머리의 한계인 것 같다.

영어를 잘하려면 뭐 영어식 사고방식과 어순 감각을 익혀야 되고 무슨 발상의 전환을 해야 하고.. 이런 것들은 그냥 기초가 없고 첫 단추부터 완전 잘못 끼운 생짜 영어 포기자한테는 꽤 유효한 조언일지 모른다. 영어 점수 2~30점을 6~70점으로 올리는 데는 도움이 될 것이다.

하지만 90점을 95점으로 올리는 건 무리임. 저런 기초적인 문법과 어순 감각은 이미 다 갖춰져 있고, 거기서 상위권에서 최상위권으로 가려면 그냥 닥치고 영어라는 빅데이터에 수시로 많이 노출돼서 감을 유지하는 것밖에 답이 없다. 외국 어학 연수는 개나 소나 아무나 가는 게 아니라 딱 이 정도 기초가 갖춰진 애들이 가야지 효과가 높아진다.

그런데, 저런 여러 영어 전문가들이 공통으로 말하는 영어 마스터 비결은.. 학창 시절에 영어 교과서 텍스트들을 몽땅 통째로 암송· 암기했다는 것이다. 사실 인간의 언어에는 굉장히 무작위하고 arbitrary하고, 그냥 문맥이 곧 용례를 결정하는 그런 정보가 많다. 암송· 암기는 학습자에게 괴로운 과정이긴 하지만 그래도 그거 효력은 확실한가 보다.
나도 테이큰의 전화 통화 대사 40초 분량은 통째로 줄줄 외우고 있긴 하다만.. -_- I don't know who you are ... I will find you. And I will kill you. 같은 거.. 그런데 영어를 잘하려면 그런 거 암기를 더 많이 해야 한다.

일본은 개개의 국민들이 다 영어를 못 하더라도 국가 차원에서 번역을 엄청 많이 잘 해 놨다고 그런다. 하지만 우리나라는 모든 국민들이 다 영어를 잘하는 것도 아니고, 번역을 깔끔하게 잘한 것도 아니니 뭔가 문제가 있어 보인다.

끝으로, 어려운 과목의 끝판왕인 수학이 있다. 수학은 영어와 달리 유행을 별로 안 탄다. 한편으로는 노력한 만큼 그대로 결과가 나오는 참 정직한 과목 같으면서도, 한편으로는 타고난 머리 지능빨을 타니 불공평한 면모가 느껴지기도 하는 과목이다.
수학에는 '정석' 책 하나로 그야말로 억만장자가 되고 우리나라에서 최고로 성공한 사람이 있다. 물론 이분 역시 머리가 공부벌레 괴수급이었으며, 굳이 책 안 쓰고 학원과 과외 강사료만으로도 그 옛날에, 겨우 20대 나이로도 왕창 잘나갔을 정도로.. 비범했다.

그런 정석의 저자가 말하는 수학 잘하는 비결은.. 수학은 처음에 느리고 시간이 걸리더라도 직접 계산해 보고 손으로 일일이 쓰면서 감을 익혀야 한다는 것이다. 그런 감이 생겨 있지 않은 사람이 눈으로만 보고 넘어가서는, 그리고 덥석 해설과 풀이를 봐서는 진짜배기 수학 실력이 절대 늘 수 없다고.. 참 너무 원론적이고 당연한 조언을 한다. 그건 게임으로 치면 그냥 무한 맵에 치트키 쓰는 것이나 마찬가지니까.

그리고 저 말을 프로그래밍에다가 적용하자면.. 일일이 직접 코딩해 보고 돌려 봐야 실력이 는다는 말과 일맥상통한다. 그 점은 본인 역시 적극 동의한다.
아무 감도 없는 사람이라면 노가다 코딩이라도 해 봐야 된다. 그런 경험을 많이 해 봐야 노가다 코딩을 왜 '노가다'라고 부르는지 그것부터 좀 알게 된다.

개발자, 프로그래머로 먹고 살려면 솔까말 트리 구조 순회 같은 재귀호출을 스택 배열로 직접 구현하기, 포인터 조작으로 연결 리스트의 원소 배열을 역순으로 바꿔치기 정도는 머릿속에서 로직이 어느 정도 암산이 돼야 하고, 굳이 컴퓨터가 없이 화이트보드 앞에서도 의사코드를 쓱쓱 적을 수 있어야 하지 않는가?

사실, 유수의 IT 업체들이 학-석사 급의 엔지니어를 뽑을 때 코딩 면접도 딱 이 정도 수준의 난이도가 나온다. 무슨 "B+ 트리를 구현하시오, 동영상 압축 알고리즘의 모든 과정을 설명하시오"가 아니다. 그리고 크고 유명하고 재정 넉넉한 기업일수록 당장 현업에서 쓰이는 HTML5니 자바스크립트니 언어 문법 지식보다는 저런 미래의 잠재성과 응용력, 새로운 기술을 더 본다. 능력 함수에서 현재의 f(x) 값보다 도함수 f'(x)를 말이다.

다시 말해, 최신 자바스크립트나 HTML5 API 지식이 필요하지 않으니까 당장 그런 걸 모르는 사람도 OK 하고 뽑는 게 아니다.
오히려 그 반대로.. 하나도 모르는 상태로 입사했더라도 현업에서 그런 것쯤은 30분 만에 즉석에서 공부하고 숙달될 능력이 있으니까 뽑는다는 뜻이다. 요구 사항이 훨씬 더 고차원적이다.

컴공과 수학의 관계는 어떨까? 물론 완벽하게 동치는 아니다. 기하 알고리즘을 구현하고 있는데 삼각형 넓이나 세 점의 방향을 구하는 공식, 3차원 공간에서 두 벡터에 대한 나머지 기저를 구하는 세부적인 외적 공식 같은 거야 당연히 까먹을 수 있다. 하지만 기억이 안 나면 당장 검색이라도 할 수 있으면 아무 문제될 것 없다.

단지, 수학은 그렇게 문제를 쓱쓱 풀어 나갔던 경험, 단 한 가지 경우라도 놓쳐서는 안 되고 논리적으로 완벽해야 한다는 그 관념이 나중에 프로그램을 짜는 데 낯설지 않은 정신적 자산으로 작용할 수 있다고 본다.
물론 그런 관념이 오로지 반드시 학창 시절의 수학 문제 풀이를 통해서만 형성될 수 있다는 건 아니겠지만 말이다. 기본적인 머리가 있고 필요를 느끼면 결국은 나중에 다른 경로를 통해서라도 적응은 하게 돼 있다.

어휴.. 나도 말은 이렇게 써 놨지만.. 당장 어떻게 풀어야 할지 모르는 어려운 문제를 대면하면 이게 도대체 지금까지 수업 시간에 배웠던 기본 수학 공식이나 법칙과 무슨 관계가 있고 무엇부터 적용해야 할지 막막한 게 많다. 맨날 이런 기억과 경험만 쌓이다 보면 그 누구라도 수학이 싫어질 수밖에 없고 수학을 포기할 수밖에 없을 것이다.. -_-;; 세상에는 나랑 나이 차이도 별로 안 나던 시절에 그런 문제를 생각해 내고 '만든' 사람도 있구만.. 참 자괴감이 든다~!!

Posted by 사무엘

2017/10/22 19:35 2017/10/22 19:35
, , , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1419

Trackback URL : http://moogi.new21.org/tc/trackback/1419

Comments List

  1. boolsee 2017/10/23 09:11 # M/D Reply Permalink

    사무엘님께서 이런 글을 쓰실 줄이야! 조금 당황스럽습니다. :) 제 관점에서는 사무엘님도 대.단.하.신 네임드 중 한 분이십니다만....
    글 내용에는 많은 부분에서 공감합니다. 나이가 들어가면서 나만 정체되어 있다거나 특별한 성과가 없다고 느껴지거든요.사실이 그런가는 차치하고 내 스스로가 한없이 작아지는 느낌? :)
    사람 사는 생각이 비슷한가 봅니다.

    1. 사무엘 2017/10/23 11:00 # M/D Permalink

      제가 본문에서 언급된 다른 사람들만치 공부 잘하고 머리가 빨리 잘 돌아갔으면 지금 겨우 날개셋 정도의 프로그램은 10년 안에 10.0까지 다 만들고 학위도 다 마치고 현재는 딴 일을 하고 있지 싶습니다.. ^^;;
      저도 제 자신이 한없이 작다는 느낌을 늘 받습니다.

  2. 허국현 2017/10/28 17:25 # M/D Reply Permalink

    1. 전에 친척 분이 "IT는 매번 바뀌는데 도대체 어떻게 그걸 하는 거냐?"라는 질문을 하신 적이 있습니다. 구원 받으신 분이라 이렇게 답했습니다.

    "해 아래 새 것이 없다는 성경 구절처럼 기술은 바뀔 지 몰라도 사람은 바뀌지 않습니다. 사람에 집중하면 생각보다 어렵지 않습니다.

    또한 새로운 것이 계속 추가되는 것 같아 보여도, 기존에 있던 것을 개선하거나, 서로 베끼는 경우도 많습니다. 너무 새로울 경우 배울 게 많아져서 오히려 시장에서 죽어 버립니다."

    이해하시는 눈치는 아니었습니다.

    사실 이것처럼 프로그래밍에도 중복되는 것이 워낙 많다 보니 김상형님 책 수집하다 보면, 봤던 예제 또 나오고 또 나오고 합니다. 플랫폼과 언어만 바뀌어서...

    오히려 요즘 나오는 책들은 C언어나 Windows API 책들에서 보이는 "경험해 보지 않고서는 절대 적을 수 없는 조언들"이 별로 없어서 많이 아쉽습니다.

    김상형님이 그게 가능한 것은 프로그래밍 언어 습득 능력보다도 글을 쓰고 책을 쓰는 능력이 있기 때문이 아닐까 합니다.

    2.

    이 글의 요약본(?) 내지 시작이었던 페북 글에도 말씀 드렸던 것처럼, 지금보다 10배 정도 머리가 좋아진다고 해도, 후회하고 자신이 작다고 느껴지는 시점만 늦어질 뿐일 것입니다.

    지금 고민하는 거야 쉽겠지만, 더 어려운 것을 고민하고 있겠지요.

    솔로몬도 공부가 힘들다는데 내가 쉬우면 그게 공부인가? 그러면 내가 공부를 열심히 안 하고 있는 거겠지... 그게 제 생각입니다.

    1. 사무엘 2017/10/28 19:43 # M/D Permalink

      이 글보다 수 개월 이상 먼저 페북에 올라왔던 요약본(?)을 다 기억하고 있고, 김 상형 님 책을 그렇게 다 수집해서 반복 패턴을 파악하실 정도이니.. 허 국현 님의 학습 능력과 기억력도 정말 남다른 것 같습니다..! ㄷㄷㄷ
      요즘은 어떻게 지내시나 궁금하네요..!

Leave a comment
« Previous : 1 : 2 : 3 : 4 : 5 : ... 8 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

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

Site Stats

Total hits:
944195
Today:
46
Yesterday:
399