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

1. 정보 저장, 상태 보관이란 걸 몽땅 실물로 해야 했음

세상에 컴퓨터와 정보 저장 매체라는 게 없던 시절엔..
길고 빽빽한 텍스트가 아니라 겨우 수 바이트, 수십 비트가 채 되지 않을 '객체 상태'도 일일이 다 실물로 관리해야 하니 참으로 번거롭기 그지없었다. 이게 무슨 말이냐 하면..

-- 보드 게임의 말들은 잡히면 몽땅 다 즉사이지, HP 같은 건 없다. 윷놀이, 바둑, 체스, 장기..
그도 그럴 것이 각 말들의 HP가 깎이는 걸 또 별도의 기물로 구현하는 건 무의미하기 때문이다.

-- 하다못해 죄수의 볼기를 줘 패도 매번 때릴 때마다 늘 "n대요~!!" 라고 크게 복명복창을 해야 했다. 정해진 횟수를 절대 틀리지 말라고.
(물론 단순 숫자 한두 개 정도는 마치 운동 경기 스코어 x:y처럼 종이 판떼기로도 표시할 수 있다. 그러나 오늘날 태형을 집행하는 국가에서 굳이 그런 물건까지 동원하지는 않을 것이다.;; )

-- 교통수단에서 환승 할인이란 걸 구현하는 게 참 난감했다. 기껏해야 승차권에다가 특수한 구멍을 뚫어서 인증하는 정도?

-- 고속도로 톨비도 말이다. 요즘 고속도로는 국영과 민영 구간이 오락가락이고, 대도시에서는 개방식과 폐쇄식이 왔다갔다 한다. 거기에다 차종과 이용 시간대별 할인이 있고, 심지어 차로 수가 적은 고속도로와 많은 고속도로 간에도 미세하게나마 요율이 다르다..!! 이거 정확한 계산을 재래식 종이 통행권으로 하려면 톨게이트를 엄청 많이 만들어 놓고 매번 차를 세워야 할 것이다.

-- 대중교통은 자리를 알아서 찾아서 앉는 자유석 형태로만 운용 가능할 것이다. 좌석 지정 탑승권은 거의 불가능. 1980년대에 새마을호 열차에서 전산 승차권(고정석) 발매가 그만큼 파격적이었던 조치였다. 그 반대급부로, 새마을호는 일부 객차만 자유석을 운영했었다.

그리고 우리나라 행정에서 이 복잡한 state 계산의 끝판왕은 운전자 벌점이지 싶다. 이건 3년이라는 유효기간이 존재하는 마일리지와 비슷한 개념이다.
유효한 벌점이 40점 이상이 되면 면허가 정지되는데, 면허정지에 기여한 벌점은 처분벌점에서는 빠지지만 누산벌점에는 남아 있고 이건 또 뭐 어떻게 해야 없앨 수 있고... 나도 제대로 이해를 못 했다.

게임에서 이렇게 하면 HP가 깎이지만 이렇게 하면 HP와 관계없이 즉사(면허 취소)...;; 이렇다.
행정 전산화가 되기 전엔 이런 거 어떻게 관리했을까...?? 경이롭다.

2. 오늘날 같은 획기적인 무선 고속 통신 인프라가 없었음

-- 휴대폰이 없었을 때는 차를 운전하다가 사고 나면 보험사에다 연락을 어떻게 했을까..??
고속도로의 경우, 일정 거리 간격으로 긴급 통화가 가능한 전화기가 비치됐으며 일정 시간 간격으로 순찰차가 다니기는 했다. 그러나 고속도로처럼 잘 관리되는 도로가 아니라 시골 깡촌 농로나 산길이라면 정말 난감할 것이다.

참고로 카폰은 아직 엄청난 사치품이었다.
기계값도 값이지만 지금처럼 제한된 주파수를 쪼개고 쪼개서 수많은 사용자들에게 효율적으로 분배하는 통신 기술과 인프라가 없었다. 카폰은 전화국과 교신하는 무전기보다 크게 나은 게 없던 지경..

그래서 지금처럼 전 국민이 무선 통화를 하는 게 구조적으로 불가능했다.
하긴, 더 옛날에는 유선 전화조차도 회선이 부족하고 자동 교환 기술이 부족해서 집집마다 개통하는 게 불가능했었다.

-- 쌍팔년도 시절, '브레인 바이러스'라는 악성 코드는 1985년에 파키스탄 사람이 만들었는데, 그게 1987년에 미국에서 첫 발견됐고, 우리나라에서는 1988년에야 발견됐다.
무선 인터넷이 없던 시절엔 컴퓨터로 뭔가가 퍼져나가는 속도도 정말 끔찍하게 느렸었다. 지금으로서는 상상도 할 수 없는 지경.

-- 좀 더 옛날 얘기를 꺼내자면 레이더나 무전기라는 것도 2차 대전 시기에 발명됐다.
그 전 제1차 세계 대전 때만 해도 아직 전령이라는 게 현역이었다! 목숨 걸고 발품 팔아서 전방 소식을 후방에다 전하는 병과 말이다. 히틀러가 이 시기에 전령병 출신이었고 그것만으로도 부상 당하고 훈장도 받았을 정도였다.
심지어 비둘기 발에다가 편지를 묶어서 전하는 구닥다리 테크닉까지 쓰였었다.

하긴, 2차 대전 때는 말 탄 기병이 아직 현역이었다. 자동차라는 게 있긴 했지만 아직 너무 비싸고 귀했기 때문.. 우리가 누리는 교통 통신 인프라가 지금 같은 가성비를 갖추게 된 건 생각보다 오래되지 않았다.

3. 금융 거래도 전산화되지 않았음

-- 월급을 직접 현찰로 봉투에 넣어서 나눠줬다. 월급날 시즌에는 회사들마다 현금을 수송하느라 분주했다.
심지어 국제선 여객기를 조종하는 기장들도.. 도착지 공항에서 유류비를 지불하려고 돈다발이 들어있는 가방을 조종실에 싣고 다녔다.;;;

-- 신용카드라는 게 있긴 했으나.. 지금 우리처럼 간편하게 긁고 통신이 되는 형태가 아니었다.
가게에서는 손님이 카드를 긁었음을 입증하는 종이 전표 실물 뭉치를 잘 보관했다가 카드사에다 직접 청구하고, 카드사는 그걸 보고 대금을 지급했다. 옛날 신용카드에 카드 일련번호가 양각으로 돌출됐던 이유는 이걸 일종의 도장처럼 쓰기 위해서였다.;;; ㄷㄷㄷㄷㄷㄷ

단순히 음성과 영상을 주고받는 통신뿐만 아니라 금융 거래가 전부 무선 자동화 전산화된 것도 세상을 정말 편리하게 바꿔 놓았다. 종이 없는 사무실보다는 현금 없는 세상이 더 많이 실현됐다.
물론 통신으로 돈 거래를 몽땅 가상화시킨 배후에는 디지털 서명을 가능케 한 비대칭 암호화라는 특급 보안 기술이 있었다. ^^
영상· 음성을 디지털로 주고받는 배후에는 압축 알고리즘(코덱..)이 있듯이 말이다.

4. 정보 검색 인프라

지금 같은 학술 정보 검색 인프라가 없던 시절에는 논문을 어떻게 쓰고 참고문헌을 어떻게 찾아봤을까??
뭐 그 시절에는 학계마다 분야별 최신 논문 목록이 마치 전화번호부처럼 종이책 형태로 주기적으로 발간되기는 했었다고 한다. 지금 우리가 보기에는 완전 골동품이겠지만..

그래서 그 시절 옛날 논문들은 참고문헌 목록이 21세기 이후 논문들처럼 풍부하지는 못했던 편이라고 한다.
이런 게 '정보 고속도로'니, 'information at your fingertip' 이런 90년대 구호가 실현되기 전의 모습이다. 유비쿼터스, IoT니 하는 구호는 2000년대 이후에나 등장했다.

하긴, 1980년대까지만 해도 학위논문들이 타자기로 작성되곤 했다. 타자기로 수학식을 표현하려면.. ㄷㄷㄷ
좀 얼리어답터인 사람이 몇백만 원짜리 컴퓨터를 장만해서 아래아한글 1.X로 논문을 써 보겠네 마네 하던 지경이었다.

갤럭시니 아이폰이니 하는 오늘날의 스마트폰은 "둥그런 브라운관 화면을 통해 상대방을 보면서 영상 통화" 정도를 상상했던 쌍팔년도 시절과는 많이 다른 모습이 됐다. ^^

Posted by 사무엘

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

1. 매킨토시

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

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

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

2. OS/2 2.x

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

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

3. Windows NT 3.x

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

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

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

4. NeXTSTEP

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

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

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

※ 번외: OpenGL과 화면 보호기

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

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

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

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

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

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

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

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

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

Posted by 사무엘

컴퓨터 업계에서 인텔의 경쟁사라고 하면 가장 먼저 (1) 동급의 x64 CPU를 만들어서 경쟁하는 AMD,
(2) 아키텍처 차원에서 x64에 도전하는 ARM 내지 애플, 혹은 심지어 (3) 울나라 삼성 전자까지 떠올릴 수 있다. 인텔이 메모리 반도체에도 손을 뻗치고 있기 때문이다.
그런데 인텔은 저것들보다는 대외 인지도가 낮은 분야에서 AT&T와도 경합한 게 좀 있었다.

1. 바이너리: 오브젝트 파일 포맷

C/C++ 언어로 코딩을 한 뒤에 컴파일을 돌리면 생기는 자잘한 obj 파일들 말이다. 기계어 코드를 담는 이 컨테이너 껍데기의 포맷은 누가 언제 제정했을까?
x86 진영에서는 CPU 본가인 인텔에서 제정한 OMF 방식이 16비트 시절부터 널리 쓰였다. 볼랜드니 마소니 컴파일러가 다르더라도 obj 파일은 호환됐기 때문에 툴을 달리하여 링크가 가능했다.

그러나 마소에서는 32비트 Windows NT를 개발하면서 실행 파일 포맷을 바꾸고(NE에서 PE), 빌드 툴체인도 싹 갈아치웠다. 단순히 OMF의 32비트 확장을 쓰는 게 아니라 obj/lib의 포맷도 AT&T에서 제정한 COFF 방식으로 바꿨다. 그 반면, 볼랜드 컴파일러들은 32비트에서도 여전히 OMF 방식을 쓰면서 서로 파편화가 발생하게 됐다.

그 시절에 마소에서는 빌드를 더 편하게 하기 위해서, 로딩을 더 빠르게 하기 위해서(메모리 매핑), 거기에다 이식성까지 고려해서 같은 여러 명분으로 COFF를 도입했었다. 다만, 지금은 그런 명분이 기술적으로 많이 옅어지고 사라지기도 했다.

그러고 보니 GNU 툴킷의 도스용 버전에 속하는 djgpp 컴파일러도 라이브러리· 오브젝트 파일 포맷은 COFF 방식이었던 걸로 기억한다. 바이너리 에디터로 들여다보면 arch! 앞에 이런 문자열이 있고.. "이건 마소 진영과 오픈소스 진영이 공통이네?" 이런 생각을 예전에 했었다.

2. 텍스트: 어셈블리어 문법

자기네 x86 기계어를 간단한 숫자와 영단어 나열만으로 풀어서 표기하는 어셈블리어 말이다. 이것도 인텔 식 문법과 AT&T 식 문법이 공존한다. 이건 단순히 '어셈블러' 제조사 간의 문법 차이가 아니라 '어셈블리어' 차원에서의 더 저수준 차이점이다.

간단하게는 숫자 앞에 $, 레지스터 이름 앞에 %가 막 붙어 있는 게 AT&T 문법인데, 본인 역시 Visual C++이 표시해 주는 인텔 문법에만 익숙하다. 하지만 역시 리눅스 진영 gdb 같은 데에서는 AT&T 문법이 주류이다.
현업에서 어셈블리어를 직접 짤 일은 없지만, 그래도 프로그램을 디버깅 하다 보면 디버거가 디스어셈블리해 준 어셈블리어 코드를 보게는 된다.

마소는 이거 문법은 딱히 AT&T 식으로 갈아타지 않았고 인텔 문법을 고수하는 듯하다. Macro Assembler 같은 기존 제품과의 호환 문제가 있기 때문인 듯하다.
뭐, 어차피 같은 CPU 아키텍처이고, 짜는 게 아니라 읽기만 한다면야 자잘한 표기 차이는 그렇게 심각한 차이점은 아닐 것이다.

프로그래밍 언어라는 건 적당히 고급 언어를 표방하면서 실용성을 갖춘 게 인기를 얻고 대중화되는 편이다.
그럼 실용성 대신에 한쪽으로 특화된 언어는 (1) 함수형처럼 수학 내지 순수주의 쪽으로 특화되거나, 아니면 (2) 어셈블리어처럼 기계 지향적인 쪽으로 특화되는 것 같다.

한 소프트웨어의 모든 코드를 저런 특화 언어만으로 작성하는 건 아무래도 무리이다.
그래서 기존의 실용적인(?) 다중 패러다임 언어들은 저 (1), (2)의 특성을 제한적으로 부분적으로 제공하곤 한다. 그게 (1) 람다 아니면 (2) 인라인 어셈블리인 셈이다.;;

요즘 세상에 대학교 컴공과에서 어셈블리어 코딩 실습을 하는 건 군대에서 총검술, 사관학교에서 승마 실습을 잠깐 하는 것과 아주 비슷한 모양새인 것 같다.
비록 현대의 전장이나 현대의 소프트웨어 개발 방법론과는 완전히 동떨어져 버렸지만, 코딩이라는 전투에서 백병전이 어셈블리어 실습이 아니겠나..;; =_=;; 실무에서는 쓸 일이 없지만 컴공 엔지니어를 양성한다는 학교에서는 컴퓨터의 밑바닥 모습을 이런 식으로라도 경험시켜 줄 필요가 있을 것이다.

Posted by 사무엘

1990년대 초에 바다 건너 미국에서는 바둑, 오목, 체스, 스크래블 같은 보드 게임의 AI 위주로 ‘컴퓨터 올림피아드’라는 대회가 잠깐 개최된 적이 있었다. 기억을 정말 오랜만에 다시 떠올린다. ㅠㅠㅠㅠ
IOI라고 불리는 '국제 정보 올림피아드'와 헷갈리지 마시길. 요즘은 저걸 검색하면 구글도 자꾸 IOI 쪽으로 안내하는 것 같은데 그거랑은 다르다. 컴올은 공식 명칭에 '국제 I'라는 말이 없다. ㄲㄲㄲㄲ

IOI는 대학에 진학하지 않은 중등 수준의 10대 청소년들이 문제 푸는 프로그램을 '즉석에서 작성'해서 그 코드의 성능과 정확도를 평가 받는 대회이다. 그 반면, 저건 현업에 종사하는 소프트웨어 개발자/개발사들이 오랫동안 미리 연구 개발해 놓은 자기 자기 제품의 AI 성능을 현장에서 겨루는 대회이다. 즉, 로봇 쥐 미로 찾기와 비슷하며, 저런 보드 게임을 사람이 아니라 컴퓨터끼리 대국한다는 차이가 있다.

근데 컴터 올림피아드도 첫 대회가 1989년부터 시작됐다니.. 그건 IOI와 동일하다. 그리고 가끔은 IOI에서도 간단한 게임을 진행하는 프로그램을 작성해서 주최측 AI와 대국하고 채점되는 형태의 문제가 나오기는 한다. 그러니 둘이 완전히 다른 별개 분야의 대회까지는 아니긴 하다.

본인이 저 대회에 대해 들어 본 건.. 한때 왕년에 영단어 보드 게임인 스크래블의 AI를 연구하느라 관련 자료를 많이 찾아봤었기 때문이다.
무려 1988년에는 World's fastest Scrabble program (by 앤드루 아펠, 가이 제이콥슨)이라는 논문이 CACM에 게재돼서 후대의 스크래블 AI 개발자에게 아주 큰 영향을 줬다. 모든 가능한 수를 찾는 기본 작업은 이 논문에서 소개된 알고리즘으로 해치우고, 그 뒤에 단순히 당장 점수가 가장 높은 수를 넘어 장기적인 이익을 따지는 건 전략과 휴리스틱의 영역으로..

오래된 생각이긴 하다만, 스크래블 게임의 컴퓨터 구현은 대학교 수준의 자료구조와 알고리즘 코딩 주제로 아주 적합하다. 만약 내가 학원이나 학교에서 저런 전공 과목을 가르칠 기회가 있다면 실습이나 과제로 저걸 꼭 넣었지 싶다. =_=;;
하긴, 석사 논문으로 두벌식 한글 연속입력 오토마타를 연구했던 모 교수님은 자기가 강의하는 형식언어와 오토마타 수업 시간에 한글 입력 오토마타를 구현하는 과제를 고정 편성으로 넣었더구만.. 그런 것처럼 말이다.

아무튼 그건 그렇고..
저 논문을 투고했던 연구진은 딱 이듬해인 1989년, 제1회 컴퓨터 올림피아드의 스크래블 부문에 참가해서 우승했다고 한다. 타이밍 절묘하군..

그 뒤 2회와 3회에서는 Jim Homan이라고 MIT 출신의 다른 엄친아 공돌이가 개발한 스크래블 AI가 2년 연속 우승을 차지했다. 정황상, 아마 저 논문 내용을 바탕으로 AI를 더 발전시킨 것 같다.
그리고 그 사람은 저 AI 엔진을 토대로 CrossWise라는 굉장히 깔끔한 크로스워드 게임(설정을 맞춰서 스크래블 게임도 가능한!!) 프로그램을 개발해서 판매했다.

그것 말고 브라이언 셰퍼드라는 사람이 개발한 Maven이라는 스크래블 AI도 유명했다. 얘도 개발 역사가 1980년대로 거슬러 올라갈 정도로 오래됐고, 스크래블 보드 게임의 총판사에서는 Maven을 공식적으로 밀었다고 하는데.. 얘에 대해서는 나도 더 아는 바가 없다. 이쪽은 딱히 컴올에 참가한 이력도 없는 것 같다.

뭐, 이것도 다 지난 얘기이다. 지금은 스크래블 게임쯤이야 폰이나 웹에서도 돌릴 수 있을 텐데.. 유행이 지난 것 같다.
하다못해 바둑조차도 세계를 석권해 버린 알파고 개발진이 "이젠 바둑은 더 연구할 게 없다~~" 명목으로 발을 뺐을 정도이니 말이다. -_-;;

저 컴퓨터 올림피아드는 스폰서 내지 운영진을 섭외할 수 없어서 1991년 이후부터 1990년대 내내 맥이 끊겼다. 그러다가 2000년대 이후부터 다시 개최는 되고 있지만.. 다들 아시다시피 인지도가 별로 없고 마이너하다는 냄새가 풍긴다. 고전적인 최적화나 휴리스틱 위주의 AI는 유행이 끝나고 닥치고 인공신경망이 대세가 돼서 그런지..??

우리나라에서 보드 게임 AI 외길을 가고 있는 제품은 '장기도사'가 유일하지 싶다. 의미 있는 연구이긴 하다만, 보드 게임이라는 장르 자체도 마이너해지고, AI 패러다임도 마이너해져서 수요가 무척 적을 것 같다. 뭐, 그런 식으로 염세적으로만 따지자면 본인의 주특기인 세벌식 자판도 마이너 중의 초 마이너이긴 하다만 말이다. -_-;;

고전적인 AI 대신 2010년대를 풍미했던 건 인공신경망들이었다. 2012년, 사물 인식을 기가 막히게 잘한다는 AlexNet부터 시작해서 VGG, ResNet, YOLO가 뒤를 잇고 chatGPT, transformer 등등이 쏟아져 나왔으니까.
컴퓨팅 패러다임이 싹 달라졌다. 이 과정에서 파이썬은 머신러닝 학계와 업계의 공용 언어가 되었고, 교육과 실무를 다 장악해 버렸다. ㄷㄷㄷㄷ 파이썬과 루아(Lua)가 처지가 극과 극으로 달라지게 될 줄은 20년 전엔 정말 예상할 수 없었다. 이것도 생각할 점이라 하겠다.

글을 맺기 전에 잠깐.. 그러고 보니 World Cyber games도 생각난다. 얘는 컴퓨터 AI가 아니라 사람이 겨루는 대회이지만, 그래도 E-스포츠 전문이니 뭔가 컴퓨터스럽고 사이버틱한 느낌이 나기 때문이다.
얘도 2001년에 처음으로 시작됐다가 2010년대엔 스폰서를 못 구해서 한동안 중단됐던 적이 있다. 그 뒤 지금은 재개되기는 했지만 권위나 인지도가 예전만 하지는 않다는 게 컴퓨터 올림피아드와 비슷해 보인다.

Posted by 사무엘

우리가 매체에서 접하는 옛날 풍경 모습이란 게 한때는 그냥 사람이 붓에다 물감 찍어서 그린 그림이 전부였다.
그러다가 그게 흑백 사진을 거쳐서 컬러 사진으로 바뀌었는데, 이제는 애초에 흑백 사진밖에 전해지는 게 없던 장면조차 컬러로 재구성된 게 늘고 있다.
컬러이더라도 화질이 안 좋았던 것을 리마스터링까지 한다. 이런 건 소실된 색/화소 정보를 AI의 힘으로 창작해서 복원한 것이다.

AI는 완전히 생판 무에서 유를 창조할 정도로 혁명적인 일은 절대 못 한다.
뭔가 패턴이 있고 생노가다 같긴 하지만, 진짜 노가다보다는 미묘하게 복잡하고 전문성과 창의성(?)이 필요해서 자동화가 안 되고 인력 수작업이 필요했던 일들.. 그러면서 법적 책임과 부담감이 크지는 않은 일.
AI는 딱 그런 업종을 0순위로 잠식할 것으로 보인다.

(1) 음악: 없는 곡을 AI가 작곡도 하는 세상인데, 기존 악보 멜로디를 읽고서 E G Fm 등 코드를 매긴다거나 반주를 넣는 건(편곡) 당연히 자동화될 것이다. 이것도 답이 한 가지만 있는 게 아니기 때문에 곡에 대한 해석과 창작이라는 범주에 든다!
코드를 만에 하나 좀 이상하게 넣었다고 해서 당장 인명· 재산 손실이 발생하는 것도 아니고.. AI화하기에 딱 좋아 보인다.

(2) 폰트: 한 폰트 패밀리로부터 다양한 굵기 내지 이탤릭 바리에이션을 자동 생성하기. 윤곽선을 단순히 기계적으로 산술적으로 부풀리기만 하는 게 아니라, 그로 인한 세밀한 공간 배치를 인간이 보기 좋게 알아서 하는 것 말이다. 힌팅을 더 똑똑하고 정교하게 생성하는 것도 포함이다.
그리고 한글· 한자의 경우, 샘플 몇 글자만 넣어 주면 그로부터 규칙성을 파악해서 나머지 수천 자의 글자 모양까지 알아서 유추해서 자형 생성하기.

AI는 한글· 한자에 대해서도 알파벳처럼 폰트들이 엄청 많이 넘치도록 개발되게 도와줄 것이다. 한글· 한자가 글자수가 수천 자나 된다고 해서 진짜로 문자로서 자형의 절대적인 정보량? 엔트로피가 알파벳의 수백 배 이상인 건 아니다. '가각간갇'이 무슨 알파벳의 ABCD 급으로 서로 완전히 다른 건 아니기 때문이다.

옛날엔.. 알파벳은 글자 수가 적어서 폰트도 크기가 작고 쉽게 만들 수 있는 반면.. 한글 한자는 너무 무겁고 뚱뚱하고 컴퓨터 자원도 많이 차지한다고.. 이러니 동양이 서양보다 국가 경쟁력이 떨어지고 열등하고 도태할 수밖에 없다는 식으로 극단적으로 생각하는 정서가 있었다. 100여 년 전, 공 병우니 최 현배니 하던 시절엔 기계식 타자기만 갖고도 문자의 우열이 비교될 지경이었으니 말이다.

지금은 그 정도로 강박관념을 가질 필요는 없다. 컴퓨터 자원이야 풍부해서 넘쳐나고, AI가 사람으로 하여금 진짜로 본질적으로 창의성이 필요한 작업만 하면 되게 나머지를 보조해 줄 것이기 때문이다.
다만.. 인간이 이런 AI를 만들기 위한 연구 개발은(코딩, 수학식, 논문 등)... 알파벳처럼 원초적으로 가볍고 취급하기 쉬운 tier 1급 문자로 행해졌음이 부정할 수 없는 사실이다.

(3) 코드 정적분석: 재래식 알고리즘만으로는 컴퓨터 프로그램을 정적분석만으로 실행 결과를 100% 정확하게 예측하고 논리 결함을 찾아내는 게 불가능하다. 그 이상부터는 그냥 휴리스틱/AI의 영역으로 갈 수밖에 없다.
그리고 코드뿐만 아니라 주석에 적힌 자연어 문구도 의미를 파악해서 "이거는 시스템 정보나 패스워드가 하드코딩된 거 아냐?" 같은 것도 정적분석이 찾아낼 수 있다. AI는 재래식 정적분석 툴의 쓸데없는 오탐들을 줄이는 데 기여할 수 있다.

(4) 그 밖에 이런 AI 기술로 내 생각엔 인쇄된 글자 모양을 보고 그냥 OCR을 하는 게 아니라 이게 무슨 폰트인지를 알아맞힌다거나, (산돌, 윤~~ ㅋㅋㅋ) 거대한 인파 사진을 보고 여기 사람 머리가 몇 개인지 카운트 하는 것.. 아 이건 딥러닝 AI까지는 아니라 그냥 컴퓨터 비전이려나.. 이런 기술이 개발되면 일상생활에 도움이 될 것 같다.

(5) 그리고 식당· 카페의 무인 키오스크가 아예 커맨드라인 콘솔이 도입될 게 아니라면 진짜 사람 말을 빨랑빨랑 알아들었으면 좋겠다. 지금 터치스크린 인터페이스는 너무 느리고 답답한 반면, 단순 주문 접수는 지금 정도의 NLP로도 그렇게 어렵지 않을 테니 말이다. 확실히 AI 덕분에 단순 안내 데스크나 전화 상담 직원은 많이 없어질 것 같다.

다만, AI는 저렇게 창의성이 필요한 분야, 참고· 보조용 도구로서 강세이다. 법적 책임까지 수반되는 분야에 진입하는 건 많이 더디지 싶다. 그래서 의료 법조 쪽은 그냥 자문· 상담부터 시작할 것으로 보이며, 자동차의 완전 자율주행은 아직 갈 길이 멀어 보인다.

* 철도는 통제가 너무 잘 된 환경이니 AI 없이 재래식(?) 로직만으로 이미 무인 자동운전이 가능할 지경이다. 차량 번호판 숫자나 QR코드를 인식하는 것과 비슷한 수준이다. (이 정도로 잘 통제된 이미지의 인식은 AI가 아니라 그냥 통상적인 컴퓨터 비전 분야..)
그러니 자동차와 철도의 중간 난이도인 비행기나 선박의 운항에 AI 기반의 자동 운항이 먼저 파고들지 않을까 싶다. 허나, 승객 수백 명이 타는 여객기에 무인까지는 아니어도 부기장이 없어지고 1인 조종이 가능해질지는 과연..?? 저비용 항공사에서 작은 기종부터 1인 조종을 시킬 수는 있겠다.

* 미용· 이발은 굳이 AI화 자동화하자면 못 할 건 없지만.. 굳이 그럴 필요가 없다고 여겨진다. 사람이 직접 가위 들고 사람 머리 깎는 건 가까운 미래에도 변함없을 것 같다. ㄲㄲㄲㄲㄲㄲ

* 빌 게이츠는 무려 25~30년 전부터 제품에다가 자연어를 알아듣는 AI 비서? 에이전트를 넣으려고 애썼던 사람이다.
마소 Bob이라든가 Office 길잡이..;;는 좀 무리한 흑역사였긴 하지만.. 반대로 저 아저씨가 시대를 앞서간 시도를 한 거라고 볼 수도 있다. 그런 귀요미를 겨우 램 16MB, 150MHz짜리 펜티엄 컴터에다 집어넣으려 했으니 욕 먹었던 거지..;; 현실의 기술이 아이디어를 뒷받침하지 못했다.

* 미국 말고 의외로.. 중국이 2010년대 이후부터 머신러닝, 언어모델 쪽 연구를 많이 하는 것 같다. 외국의 최신 논문을 찾아 보면 중국 사람 이름이 엄청 많이 보인다.
그런데 중국은 그런 첨단 AI 기술을 이용해서 인터넷의 불온 컨텐츠를 검열하고 인민들 행동패턴을 감시하는 데도 적극 활용한다는 게 함정....

지난 1990년대 중반까지 기계번역 프로그램이 잠깐 나오다가 유행이 식은 적이 있었다. 일한이라면 모를까 영한은 이거 뭐 도저히 실용적인 결과가 나오지 않았기 때문이다. 하물며 한영은.. 난 지구가 멸망할 때까지 절대 개발되지 못할 거라고 생각했었다.
그런데 인공신경망 기반 AI로 언어 장벽이 이 정도까지 무너지고 낮아진 건 참으로 놀라운 일이다.

물론 무슨 기업간 회의나 대통령 연설, UN 컨퍼런스를 기계번역으로 때워도 되는 건 아니지만, 일상적으로 뭔 말인지 내용 파악하는 용도로는 기계번역이 정말 쓸 만해졌다.
게다가 이게 텍스트를 읽는 것에만 국한되지 않는다. waveform 형태의 말소리를 받아 적은 transcript를 생성하고 그걸 번역까지 하다니.. 유튜브에서 자기 동영상의 음성에서 자막을 아주 정확하게 실시간 생성해 주는 것만 해도 신기하기 그지없다.

암호 해독을 위해 언어학자가 아니라 수학자가 필요한 시대는 이미 20세기 중후반에 찾아왔다. 이제는 기계번역이나 자연어 처리 영역도 언어학자가 아니라 수학자와 데이터 과학자의 차지가 됐다.
2020년대가 되니 인간이 달이나 화성이나 해저에 기지를 만드는 건 전혀 가망이 없고, 그 대신 쌍팔년도 SF에서 거의 상상하지 못했던 스마트폰과 유튜브가 대세가 됐다. 그래서 카폰이라는 게 완전히 사라졌고, 무전기는 군· 경· 소방 같은 특수 직종에서나 쓰이는 물건이 된 거다. 뭐, 언어 자동 통번역기는.. 그 시절에도 상상은 했었고 얼추 실현돼 간다.

머신러닝에서 모델이라는 건 코드와 데이터의 성격을 모두 지니고 경계가 참 애매한 것 같다. =_=;; 물론 순수하게 데이터에 속하는 건 훈련용으로 먹이는 텍스트나 그림들이겠지만 저런 신경망 자체도 머신러닝 라이브러리 코드의 관점에서는 데이터일 것이다.
그리고 훈련시키는 건 뭔가 압축하는 것과 비슷하고, 이를 바탕으로 현실의 문제를 풀이하는 건(추론) 압축을 푸는 것과 비슷해 보인다.

이런 AI는 참 엄청나고 대단하긴 하지만.. 공짜로 평범한 계산량으로 돌아가는 물건이 아니다. AI를 돌리기 위해 동원되는 컴퓨팅 자원을 보면 정말 억소리 난다.
chatGPT가 저렇게 답을 '즉시' 뱉어내기 위해서 지구 반대편에서는 상상을 초월하는 고성능 슈퍼컴이 전기를 있는 대로 잡아먹고 열을 펑펑 내뿜으며 돌아가야 한다. 살인적인 분량의 신경망 연산이 행해지기 때문이다. 저기 서버가 하루 유지 비용이 원화로 몇 억? 몇십 억이니 그런다. 이때 컴퓨터 내부의 신경망 상태는 상상을 초월하게 너무 복잡하기 때문에 훈련이나 추론 과정의 추적이 도저히 불가능할 지경이다.

인간은 오랫동안 절대 불가능하다고 여겨졌던 유인 달 착륙과 귀환을 몇 차례 성공하긴 했다. 그러나 그건 정말 위험하고 어렵고 힘들고 비싸게 가까스로 해낸 것이었다. 민간인의 대중적인 달 여행이라든가 달· 화성 기지로 이어지는 건 지금 관점에서도 가까운 미래엔 요원하다.

그리고 AI의 발달 추세에도 이런 우주 개발과 비슷한 면모가 있는 것 같다. 과거에 불가능하다고 생각했던 자연어 처리가 가능해지기는 했지만.. 그걸 가능케 하는 컴퓨팅 환경이 저 우주 로켓 같은 물건이라는 거다. 물론 컴퓨터 업계도 가만히 앉아서 손가락만 빠는 건 아니니.. 그 연산에 특화된 CPU를 만들어 간다.

30여 년 전, 486이니 펜티엄이니 하던 시절엔 멀티미디어 지원이 컴터 업계의 최대 관심사였던 것 기억하시는가?
크게 (1) 동영상 아니면 (2) 게임용 3D 그래픽 실시간 렌더링이라는 두 분야이다.
하긴 그 시절엔 MPEG 동영상을 감상하기 위해서 전용 카드를 꽂네 마네 했던 것 같다. 요즘은 재생이 아니라 컴터 화면을 실시간으로 녹화하고 인코딩할 때에나 전용 카드가 필요한 듯하다.

나중에는 엄청난 물량을 자랑하는 멀티미디어 연산에 특화된 명령이 CPU에 추가되고, GPU라는 건 그래픽 가속기라는 이름으로 도입되곤 했었다.
그랬는데 이제는 단순 그래픽 처리를 넘어 머신러닝 신경망 연산에 특화된 CPU가 대세이다. 당연히 서버에 접속해서 API를 호출해서 구현된 거라고 생각한 통· 번역이 핸드폰에서 비행기 모드까지 켰는데도 동작한다는 게 정말 신기하다.

저런 컴퓨터에 비해 인간의 두뇌는? 환경에 끼치는 부작용이 없고 당분 몇 스푼만 공급해 주면 한 나절을 거뜬히 돌아간다.
물론 두뇌와 컴퓨터가 서로 비교 가능한 존재는 아니지만 어떤 면에서는 생체라는 게 참 경이롭다. 두뇌와 컴퓨터는 다리와 바퀴가 다른 것만큼이나 다른 건지도 모른다.

그러고 보니 우리나라의 이스트소프트는 맨 처음 1990년대엔 21세기 워드라는 평범한(?) 업무용 프로그램을 만들었다가 알툴즈로 명성 내지 악명을 떨쳤고.. 그러다가 게임이 더 돈 된다고 생각했던지 '카발'이라는 온라인 게임을 만들었고 지금 와서는 AI 기업을 표방하고 있다. (게임과 AI 모두 GPU가 쓰인다는 공통점이..)
각각의 제품들이 어떤 평을 받는지에 대해서는 논란의 여지가 있지만, 어쨌든 시류를 따라 참 다양한 분야를 개척하면서 생존하려고 애쓴다는 것 하나는 확실해 보인다.

Posted by 사무엘

사용자가 자기 머신에(PC 내지 폰) 직접 설치해서 구동하는 그 exe / apk야 클라 개발자의 작품이다.
현란한 그래픽을 구현하고, 같은 하드웨어에서 화면 프레임 수를 늘리려고 고생하는 애들 역시 클라 개발자이다.
그러나 수많은 사용자들을 동시에 수용하고 계정 정보를 관리하고, 이것들이 해킹당하지 않게 보호하고, 클라가 뿌릴 게임 내부 상태를 전해 주는 건.. 서버 및 서버 개발자의 몫이다.

클라 프로그램이 뻗는 건 그 사용자만의 문제이지만, 서버가 뻗는다면....;;;; 뭐 그렇다.
조금 어설프게 비유하자면 클라는 또박또박 보도를 하는 뉴스 앵커이지만, 서버는 뉴스 대본을 생성하고 보도 순서와 분량을 정하는 보도국뻘 된다.

그런데 데스크톱이나 모바일 '앱' 말고 웹 개발로 가면.. 프런트 엔드와 백 엔드라는 계층 구분이 있다.
웹 프로그램은 머신에 설치되는 게 아니라 웹브라우저 화면에서 바로 구동된다. 그렇기 때문에 개념적으로는 클라라는 게 없고 서버 프로그램만 있는 것 같다.

하지만 거기서도 계층 구분이 있다. 사용자한테 보이는 부분, 더 기술적으로는 js html css처럼 서버로부터 받기는 했지만 사용자의 웹브라우저에서 구동되고 사용자가 소스를 직접 볼 수 있는 부분은 프런트 엔드이다.
그 반면, 저런 html을 생성하는 프로그램이라든가 DB처럼.. 진짜로 서버에서만 돌아가고 사용자가 코드를 볼 수 없는 부분은 백 엔드라고 불린다.

프런트 엔드 웹 개발자는 웹 '디자이너'와 영역이 겹치며 같이 작업하게 될 수 있다.
그러나 백 엔드는 디자이너와의 접점이 없으며, 그 대신 Java, C#, 심지어 C++처럼 머신 종속적인 데스크톱용 프로그래밍 언어와 접점이 있을 수 있다. (사용하는 프레임워크가 무엇이냐에 따라)

글쎄, php는 딱히 기계 종속적이지 않으면서 백 엔드 개발에 최적화된 언어인 듯하다.
JavaScript야 웹 개발계의 유니코드요 세계공용어로 등극했으며, 프런트와 백에서 모두 쓰이고 있다.

원래 컴퓨터 업계에서 '프런트/백 엔드' 이런 말은 컴파일러에서 주로 쓰이던 용어였다. 구문 해석해서 parse tree 내지 IR(중간 표현)을 생성하는 게 프런트이고, 이걸로부터 실제 머신 코드를 생성하고 최적화도 하는 게 백이었는데.. 2000년대 이후부터는 웹 개발에서의 계층을 구분할 때도 저런 용어가 쓰이게 된 것이다.

1990년대.. 웹의 초창기에는 웹만을 위한 프로그래밍이라는 개념이 아주 희박했다. 프런트/백의 엄밀한 구분도 없었고 온갖 비표준 파편화 기술들이 난립했었다.
프런트 엔드에 속하는 건 사용자가 폼에 입력한 값이 올바른지 로컬에서 체크해서 에러 메시지 띄우는 수준의 아주 간단한 코드?? 이런 코드는 html 코드의 주석 안에 자그맣게 짱박혀 있곤 했다.;; html이라는 문서가 main이지, 이런 코드는 약간의 동적 요소만 가미해 줄 뿐, 조연에 지나지 않았다.

하긴, html 자체를 동적으로 생성하는 기술을 공부해서 DB 만지고 게시판 같은 거 자작하는 게 지금으로 치면 백 엔드 개발이었겠다. CGI 역시 백 엔드의 범주에 드는 초창기 기술일 테고. =_=;; 옛날 제로보드 스킨은 일종의 프런트 엔드 개발이었겠다. ㄲㄲㄲ
플래시니 Java 애플릿 같은 건 물론 프런트이고, 지금의 관점에서는 특정 기업 솔루션에 종속적인 비표준 기술이 됐다.

프런트 엔드에서 돌아가는 웹 프로그램 코드는 특정 기계어로 컴파일되지는 않는다. 무슨 C/C++ 프로그램처럼 저수준 메모리 문제나 보안 문제 같은 것도 존재하지 않는다.
만약 특정 JavaScript 코드를 실행함으로써 메모리· 보안 문제가 발생한다면 그건 그 브라우저에 내장된 js 엔진의 버그이지, js 코드의 버그라고 여겨지지는 않는다. 문제 있는 js 코드는 다른 부작용 없이 깔끔하게 실행이 거부되고 에러 메시지와 함께 튕기기만 돼야 할 테니 말이다.

그 대신 그 코드는 보통 난독화 처리가 돼 있을 것이다. 그렇기 때문에 코드가 노출돼 있다고 해서 사용자가 그 코드를 읽어서 뭔가 로직을 파악하기는 매우 난감할 것이다.;;

그렇기 때문에 웹 프로그래밍에서 보안의 최대 관심사는 buffer overrun 같은 부류가 아니라.. 신뢰할 수 없는 임의의 외부 문자열이 코드나 태그, SQL 따위로 인식되어 실행되지 않게 하기 위주인 것 같다. C로 치면 % format 문자열에다가 동적 생성된 외부 문자열을 공급하지 말라는 것과 비슷하다.

문득 드는 생각은.. 웹 개발을 위한 전용 IDE가 있을까?
옛날에 나모나 드림위버, FrontPage 같은 위지윅 html 에디터가 있었고.. Visual Studio 6 시절엔 Visual InterDev라고 비베 냄새가 나는 웹 개발 IDE가 있긴 했다. 하지만 그런 건 2000년대 중반 이후로 유행이 지나고 한물 갔다. 심지어 마소에서 Expression Studio라고 새로 만들던 웹 개발 저작도구도 2010년대 초반에 개발이 중단됐다.

웹은 과연 IDE의 무덤인지.. 개발에 이클립스 내지 Visual Studio Code 같은 범용적인 에디터/IDE만 쓰이는 것 같다.

※ 비유 개드립

• "웹 디자인 - 웹 프런트 엔드 개발 - 웹 백 엔드 개발"은 뭔가 "장갑차 - 전차 - 자주포" 순으로 성향이 바뀐다고 생각하면 될 것 같다. ㄲㄲㄲㄲㄲㄲ
• 프런트 엔드에서 css / js / html라는 역할 구분 세분화는 입법 사법 행정 삼권분립과 비슷한 느낌이 든다.
• PC용 앱은 일반 봉지 라면, 모바일 앱은 컵라면 사발면.. 그리고 웹사이트를 구동하는 프로그램은 식당 납품용으로 대량 판매하는 라면 사리 내지 스프와 비슷하게 느껴진다.
• 웹 개발이나 컴파일러뿐이겠는가. 인공위성은 프런트 엔드, 발사체는 백 엔드 기술인 것 같고.. 자동차에서도 주행과 관련은 없지만 탑승자가 대면하고 사용하는 부품들은 프런트요, 엔진룸 안에서 차량을 굴리는 데 기여하는 부품은 백에 대응하는 듯.. 이런 식의 구분은 다른 여러 분야에도 존재한다.

※ 모바일 관련

mobile이라는 말이 원래는 물리적인 이동, 교통과 관련된 단어였다. 미술 조형물 모빌이라든가, automobile 자동차처럼 말이다. 하지만 지금은 스마트폰 관련 '통신' 뉘앙스가 더 짙어졌다.
그리고 우리말은 참 희한하게도 '모빌'은 통상적인 의미, '모바일'은 통신 의미로 분화됐다. 마치 '도트/닷', '네트/넷'의 뉘앙스 변화와 비슷한 재미있는 현상이다.
'통신사'가 지금이야 SK 텔레콤 같은 게 먼저 떠오르지만 원래 연합뉴스 같은 언론사 용어였다는 것도 생각해 보자.

Posted by 사무엘

1. 거대한 실행 파일

전통적으로 Windows 운영체제가 깔린 PC에서 볼 수 있는 엄청 큰 DLL 중 하나는.. 마소 Office 제품들이 사용하는 공용 라이브러리인 mso.dll 이다.
Program Files\Common Files\microsoft shared\OFFICExx 디렉터리에 있는 파일인데, 20여 년 전에 이미 크기가 10수 MB가 됐고, Office 2013의 64비트 버전 기준으로 36MB를 넘었다.

저 파일은 리소스나 데이터가 별로 없고, 대부분이 순수하게 코드만으로 저 크기이다.
오피스의 경우, 리소스들은 언어별로 별도의 리소스로 분리가 잘 돼 있기 때문이다.

그 뒤, 요즘은 웹 브라우저의 렌더링 엔진이 왕창 거대한 단일 DLL 자리를 차지하는 편이다.
Windows의 system 디렉터리에 있는 mshtml.dll 도 64비트 기준 20MB를 넘는다. 얘는 Internet Explorer 브라우저의 Trident 엔진 파일인데.. IE는 요즘 죽었으니까 제끼고.

많은 사람들이 사용하고 있을 크롬 브라우저의 코어 엔진인 chrome.dll은 거의 220MB에 달한다.
이게 내가 현재까지 알고 있는 제일 큰 DLL이다. 파일에서 적어도 3/4 가까이는 코드가 차지하고 있는 DLL 중에서 말이다.
그도 그럴 것이 요즘 웹 브라우저 엔진은 단순히 HTML을 파싱하는 문서 렌더러가 절대 아니고... 거의 독자적인 운영체제, 가상 머신, 프로그래밍 언어 런타임 급이 됐기 때문이다. 미치도록 거대할 수밖에 없다.

Visual Studio Code도 주 실행 파일인 code.exe가 160MB가 넘으니 엄청 큰 편이다. 얘도 파일 안을 들여다보면 무식한 리소스빨이 아니며, 전체의 3/4 가까이는 순수 기계어 실행 코드이다. 심지어 1년쯤 전엔 150MB대였던 걸로 기억하는데 업데이트를 거듭하면서 더 커졌다~!
그에 비해 내 한글 입력기는 코어 dll이 딱 1MB가 될까말까이다.;; 거기에다 기본 플러그 인 로딩까지 하면 1.5MB 정도 된다.;;

2. 버전 넘버링

마소의 Visual Studio와 Office는 Windows와 더불어 마소를 먹여 살리는 핵심 제품이다.
그런데 얘들은 2010년대 중반, Windows 10 무렵부터 버전을 크게 올리지 않고 깨작깨작 소수점 둘째 자리만 건드리는 게 관행이 됐다. 겉으로 크게 표시되는 연도 버전 말고, 내부의 번호 버전 말이다.

VS는 2015부터, Office는 2016부터 16.x 버전이 유지되고 있다. 그나마 VS는 2022가 출시되면서 번호가 17.x로 올라가긴 했지만, _MSC_VER의 값은 여전히 19xx대 고정이다.
뭐, Windows 역시 10부터 내부 파일들의 버전 역시 10.x 고정이긴 하다. 얘는 10을 끝으로 새 버전 브랜드를 더 만들지 않을 것처럼 얘기했다가 결국 11, 12를 내면서 입장을 번복하게 됐는데.. 그래도 11도 겉으로만 그럴 뿐, 내부 번호는 여전히 10이다.

10년 넘게, 거의 20년 가까이 1.0도 아니고 0.x대 버전을 유지하고 있는 건 DOSBox 내지 putty 정도인 것 같다.
그 반면, 웹브라우저 쪽은 크롬이 주 버전 번호를 팍팍 올리는 관행을 만들었다. 얘는 버전이 12도 아니고 이미 12x을 넘어섰다. 무려 백 자리..

Java의 경우, 한때 1.3, 1.4 이렇게 번호를 올리다가 2010년대부턴가 그냥 7, 8, 9로 넘버링 방식을 바꿨다. 주 번호를 계속 1로 유지하는 게 별 의미가 없다고 판단한 듯하다.
애플 진영도 macOS X이라고 해서 한때 10.1, 10.2, 10.3 ... 이러다가 나중에는 11, 12, ..., 14.x로 주 번호를 올리기 시작했다. Windows와 macOS 모두 버전의 주 번호에서 10을 떼어냈는데.. 내 한글 입력기는 언제쯤 10을 졸업할지? =_=;;

3. UI 트렌드

(1) 소프트웨어에서 자신의 종합적인 옵션/preference를 설정하는 명령이 있는 메뉴는? 보통은 '도구' 메뉴의 맨 끄트머리에 있는 게 관행인데, (마소 UI 디자인 가이드라인) 이게 약간 케바케 성향이 있는 것 같다. 크로스 플랫폼 제품 중에는 편집이나 심지어 파일 메뉴에 배치된 경우도 있다.

Windows 3.1 시절 옛날에는 아예 '옵션'이라는 메뉴가 따로 있기도 했다. 하지만 그런 관행은 95의 도입과 함께 거의 사라졌다. 수십-수백 개에 달하는 옵션들을 지정하는 단일 대화상자가 탭이나 웹페이지 형태로 거대하게 바뀌었을 뿐.
옛날에 아래아한글 2.0은 1.5x 이후로 기능 추가와 구조 변화가 워낙 많았던 제품인지라, 새로 추가된 옵션들이 '선택사항 - 기타'의 부메뉴로 중구난방으로 쭈루룩 달렸던 게 개인적으로 인상적이었다.;;;

(2) 데스크톱 프로그램이건, 웹사이트건.. '다크 모드'를 제공하는 게 요즘 완전 유행이 됐다.
글쎄, Windows에서 이거 전신은 '고대비 검정'이 아닐까 싶은데.. 이건 사용자 취향보다는 장애인 접근성이나 특수한 디스플레이 환경을 고려한 기능이었다.
아울러, 아이콘들의 디자인이 알록달록 대신 단촐해지면서 그림보다는 픽토그램에 더 가까워진다. 표현 형태도 벡터 폰트에 더 가까워졌다.

(3) SNS가 발달하면서 어디서나 사람 언급은 @, 키워드 태그는 #.. 이게 관행이 됐다.
이모지에다 별도의 문자 코드를 배당한다니 이게 도대체 무슨 일인가 싶었다만.. 이제는 게시글에 대한 피드백(좋아요, 놀라워요, 화나요 등등)조차도 거의 국제 표준을 제정해도 될 것 같다. 정말 2, 30년 전에 ICQ니 msn 메신저니, 네이트온 쓰던 시절에는 상상도 못 했던 관행이 생겼다.

(4) 리눅스 셸이 GNOME이냐 KDE냐 하는 건, 통신사를 SKT 쓰냐 KT 쓰냐 하는 것처럼 느껴진다. ㄲㄲㄲㄲ
개인적으로는 우분투+GNOME 말고 딴 건 접해 보지 못했다. 우분투가 대세인 듯..

(5) 어떤 컴퓨터를 원격으로 접속해서 사용하는 방법이란 게 전통적으로 (1) 명령 프롬프트(터미널), (2) 파일 시스템(FTP)으로 나뉘는 편이었다. 하지만 요즘은 컴터 성능과 네트워크 속도의 향상 덕분에 GUI 셸, 데스크톱을 통째로 가져와서 원격으로 쓰기도 한다. 이를 구현하는 프로토콜은 표준으로 채택된 게 있는지, 아니면 제품별로 다 찢어져 있는지 궁금하다.
이건 '텍' 같은 전산 조판 언어로 코딩하듯이 문서를 만들던 게, 그냥 GUI 위지윅 워드 프로세서로 바뀐 거나 마찬가지다.

(6) 크롬 브라우저에 있는 adblock 애드인은 단순히 웹사이트 한구석에 붙은 구글 광고만 차단하는 줄 알았더니만.. 유튜브의 짜증나는 6초~15초짜리 광고들까지 몽땅 차단 박고 스킵시켜 주는구나.. 오오~ 매우 놀랍다.
그런데 유튜브의 엔지니어들도 바보가 아닐 것이고 광고주의 자기들 밥줄을 끊는 짓은 단속하지 않을까..?? 창과 방패의 싸움이 계속될 듯하다.
유튜브를 exploit하는 두 가지 방법이 광고 차단이랑 동영상 다운로드인 셈이다.

4. 소프트웨어 업데이트

요즘은 소프트웨어의 보안 취약점 내지, 이를 이용해 증식하는 악성 코드가 야기하는 문제가 심각하다. 특히 랜섬웨어한테 자기 컴터나 심지어 직장 업무용 컴터가 털렸다는 소식은 본인조차 주변 지인으로부터 심심찮게 들었을 정도이다. 교통사고로 지인 누구가 다쳤다는 소식에 근접할 정도로 꽤 가까워지고 흔해졌다.

마소에서 보안, 보안 노래를 부르면서 모든 사용자에게 보안 업데이트를 끄지도 못하는 반강제로 주입시키고, 심지어 정품 인증에 실패한 불법 복제 Windows에다가도 보안 업데이트만은 무료로 꼬박꼬박 시켜 주는 건 다 이유가 있다.
악성 코드한테 털려서 좀비가 된 컴터는 다른 멀쩡한 컴터한테도 해를 끼치기 때문이다.

소프트웨어가 단순히 기능 추가나 자기 동작 차원의 버그 수정만 필요하다면 업데이트를 이렇게 귀찮을 정도로 강요할 필요가 없다. 하지만 지금은 보안 업데이트가 인간한테 주요 전염병 백신과 비슷한 존재가 돼 버렸지 말이다.

하지만 그럼에도 불구하고 요즘 Windows 업데이트는 너무 과한 구석이 있다. 악성 코드가 아니라 업데이트 서비스 네놈이 평소에 컴터 CPU를 과도하게 잡아먹고, 긴급히 컴터를 쓰고 싶은 상황에서도 세월아 네월아 재부팅을 강요한다.
그래서 요즘은 Windows를 부팅시켜 놓고 몇 주~몇 달째 계속 부팅 상태를 유지하며 켜 놓는 게(완전히 끄지 않고 절전 모드 전환도 포함) 사실상 불가능하다. 업데이트 설치 핑계로 지들이 제멋대로 재부팅을 해 버리기 때문이다.

옛날에 Windows 9x 시절이야 운영체제가 불안정하고, 16비트 영역의 메모리 리소스가 고갈됐기 때문에 컴을 오래 켜 놓을 수 없었다. 그때는 재부팅 정도가 아니라 운영체제 재설치까지 주기적으로 해야 했을 정도였다.
지금이야 그런 미개한 요인들이 당연히 전혀 존재하지 않는다. 그런데도 컴을 오래 켜 놓지 못한다는 거다. 이게 말이나 되냐?

5. 터미널 환경에서의 동작

개발자? 프로그래머? 소프트웨어 엔지니어? 암튼 이 바닥 종사하는 사람은 일반인들보다는 컴퓨터에서 GUI가 아니라 '명령 프롬프트'를 다룰 일이 더 많다.
Windows의 명령 프롬프트는 말할 것도 없고 PowerShell, Visual Studio Code, putty, Windows Terminal, 리눅스의 명령 프롬프트 등.. 다양한 프로그램에서 터미널을 쓰다 보면..

화면에 뜬 텍스트를 블록 잡고 복사하는 간단한 조작을 좀 하고 싶은데 키보드나 마우스 동작이 미묘하게 서로 달라서 불편을 겪곤 한다.
putty는 우클릭만으로 명령어 붙여넣기가 되는 반면, 어떤 데서는 그게 휠 클릭이고 우클릭은 일반적인 컨텍스트 메뉴 표시이다.

어떤 곳에서는 블록을 잡고 나서 Ctrl+C로 복사를 시키는 반면, 어떤 데서는 그랬다가는 실행 중지 Ctrl+C가 곧이곧대로 전달된다. 한 프로그램의 단축키와 동작에 익숙해졌는데 딴 프로그램에서는 그게 통하지 않아서 개인적으로 혼란스러웠다. =_=;;
개인적으로는 터미널의 GUI 차원에서 특정 문자열이 등장했을 때 highlight 시키는 기능, 그리고 구획을 나눠서 clear을 시키면 최신 구획의 텍스트만 다 날리는 기능 같은 게 있었으면 좋겠다.

터미널은 컴퓨터에 접근해서 뭔가 조작을 하는 제일 저렴하고 효율적인 방법임이 틀림없다. 이거 아니면 파일 시스템만 다루는 FTP.. 하지만 요즘은 컴터 성능과 네트워크 속도가 받쳐주다 보니 아예 원격 데스크톱 GUI 화면을 통째로 쏴 주는 가상화도 가능해졌고, 이게 터미널과 FTP 기능까지 상당 부분 흡수한 상태이다. 인터넷이 괜히 WWW가 닥치고 짱이 된 게 아니듯이 말이다.

6. 나머지 불편하거나 궁금한 거

(1) 10여 년 전, Windows 7쯤이었나? SSD 하드라는 게 처음 도입됐을 때 말이다. 하드디스크가 통째로 램 드라이브로 바뀌는 거나 마찬가지였기 때문에 부팅 속도가 획기적으로 빨라져서 신기하다고 난리였다.
그러나 Windows 10이니 11이니 하는 지금은..?? C 드라이브에 다들 SSD를 쓰고 있는 세상인데도 부팅 시간이 옛날에 재래식 하드로 Windows XP나 7을 부팅하는 것과 비슷하게 느껴진다.

디스크 속도가 올라간 것 이상으로 Windows도 더 무거워지고 이것저것 불러들이는 게 많아졌기 때문일 것이다. 에휴~
옛날에 디지털 카메라가 싸구려 기종이라도 폰카보다 좋은 게 물리적인 zoom 기능 말고도.. 부담 없이 끄고 켜는 게 가능하고 부팅이 아주 신속하게 된다는 것이었다. 디카에는 컴퓨터가 들어있긴 하지만 '범용 컴퓨터'가 들어있는 건 아니었기 때문이다.;;

(2) Windows 10/11의 시작 메뉴에서 검색란에다가 타이핑을 했는데 원하는 프로그램 검색이 안 되고 멀뚱멀뚱 있는 버그 말이다. 정말 악명 높지 않았는가?
글쎄, 내가 완전 최신 버전을 쓰고 있지는 않아서 잘 모르겠지만, 설마 아직까지 그 버그를 달고 다니지는 않으리라 추측한다.
이건 개인적으로 Win10의 사용 경험을 크게 악화시킨 버그였다. 사용자가 현실에서 엄청 자주 사용하게 될 기능이 이 따위로 동작하다니, 품질 관리를 도대체 어떻게 한 건지?

(3) Windows 8 시절부터 전통적으로 전해 내려오던 메트로 앱 '메일'이 요 근래에는 New Outlook으로 몰래, 쓰윽 대체된 듯하다. 수십 년 전에 있었던 Outlook Express의 후신이 등장한 것 같다만.. 개인적으로는 내가 관심 없고 사용하지 않는 프로그램이 제멋대로 설치되는 건 비호감이다. 이건 그놈의 보안하고도 아무 관련 없는 사항이지 않은가.

그리고 마소에서도 화상 회의 앱에 관심이 생겼는지 Microsoft Teams라는 걸 만들었는가 보다. 내가 실행하지도 않은 녀석이 제멋대로 깔려서 CPU를 잡아먹고 있길래 바로 강제 종료하고 제거해 버렸다.
악성코드를 빌미로 지들이 악성코드처럼 구는 거는 난 절대 용납 못 한다.

(4) 이건 PC가 아니라 잠시 스마트폰 얘기이다만.. 사용자가 입력하는 텍스트를 자동 완성 내지 오타 교정한답시고 사용자가 진짜로 의도한 문자열까지 제멋대로 바꿔 버리는 거 말이다. 아이폰이 여전히 악명 높은가 보다.
주변에서 이렇게 의도하지 않은 오타를 내는 사람을 많이 봤고, 나도 아이폰 쓰던 시절엔 이것 때문에 난감한 일을 몇 번 겪어 봤다.

난 내가 입력한 텍스트에는 내가 직접 책임을 지고 싶어서.. 마소 워드가 기본 제공하는 자동 고침 기능조차도 오지랖 불편함을 느끼는 사람이다. (대소문자, 줄표 등등~~) 자동 고침을 할 거면 그걸 철회하고 사용자의 원래 텍스트로 되돌리는 UI라도 주변에 눈에 띄게 넣든가.. 아이폰은 내 기억으로 그런 게 없었다.

(5) 어느 컴퓨터에나 프로그램 설치/제거 리스트를 보면.. 서버 개발자도 아닌 엔드 유저한테 MS SQL server는 누가 언제 왜 잔뜩 설치하는지 모르겠다. 도대체 어디에 쓰이는 물건인 걸까..??? 최신 버전도 아니고 그냥 2008인데 말이다.
옛날 win7 시절에는 '실버라이트'라는 제품도 슬그머니 깔리곤 했는데 그건 망했기 때문에 요즘은 눈에 띄지 않는다.

(6) Visual Studio라든가 아래아한글 같은 프로그램은 자체적인 설치 관리자 내지 업데이터를 보유하고 있는 제품이다. 그런데 뭔가 새 마이너 버전이 나와서 업데이트를 찍으면.. 업데이터 자기 자신부터 업데이트 되는 경우가 엄청 잦다. 그냥 심심하면 업데이트 된다.
업데이터는.. 일관된 체계로 버전 체크를 하고 새 패키지를 다운로드하고 파일 복사, 덮어쓰기, 삭제하는 기능이 전부일 텐데.. 한번 잘 만들어 놓고 나면 고칠 일이 거의 없을 텐데?? 내부적으로 뭐가 그렇게 자주 바뀔 게 있는지 개인적으로 매우 궁금하다.

Posted by 사무엘

1. 언어 고안자의 부고

일본에서 지진이 났던 올해 1월 1일 말이다.
파스칼 언어를 고안한 스위스의 컴퓨터 과학자 '니클라우스 비르트' (취리히 연방 공대 교수, 튜링 상 수상자)가 세상을 떠났다. ㄷㄷㄷㄷ
이거 뭐 뒷북 부고 소식을 연달아 전하는구나..;; 이번에는 분야가 신앙 쪽이 아니라 컴공이라는 점만 다르고 말이다.

지난 2011년 가을엔 C 언어를 고안한 '데니스 리치'가 세상을 떠났었다.
C야 워낙 대중적인 언어이고, 또 저 시기는 무려 스티브 잡스의 부고와도 시기가 비슷했다. (딱 1주일 차이) 그래서 데니스 리치의 부고는 이때 작게 잠깐이나마 주목을 받기도 했다.
그러나 지금은? 시기가 별 개연성 없고, 파스칼 언어도 C에 비해 아주 마이너하다 보니, 저 사람의 부고는 아무 존재감 없이 묻혀 지나간 것 같다. =_=;;;

파스칼과 C는 1970년을 전후한 비슷한 시기에, 비슷한 패러다임을 반영하여 만들어진 언어이다. 물론 C가 근소하게 더 나중이긴 하다만.
파스칼은 진짜 순수 학자가 만든 반면, C는 AT&T니 벨이니 유닉스니 하면서 학계보다는 더 실무 엔지니어 지향적인 사람이 만들었다. 물론 이것도 상대적인 차이일 뿐, 데니스 리치도 튜링 상 수상자이고 일반인 입장에서 넘사벽 천재인 건 마찬가지이다.

2. 파스칼 언어 구조에 대한 생각

(1) 파스칼은 블록을 begin end로 표현하는 반면, C는 간단히 중괄호 { }로 때운다. 그리고 C는 세미콜론이 문장을 종결하는 부호인 반면, 파스칼에서는 문장을 '구분'하는 부호이다.

그렇기 때문에 C에서 { 1,2,5 } 이렇게 5 다음엔 ,를 붙이지 않듯,
파스칼에서는 begin a(); b(); c() end. end 직전의 마지막 문장에는 세미콜론을 붙이지 않아도 된다.
아주 흥미로운 차이점이다. 세미콜론 ; 은 .와 ,로 이루어진 부호인데 C는 거기서 .의 특성을 더 중시한 반면, 파스칼은 ,의 특성을 더 중시했다고 볼 수 있다.

글쎄, 파스칼은 개념적으로 알골이라는 초창기 언어에서 영향을 받았고, Ada라는 엄청난 언어와도 유사점이 많다고 하는데.. 특히 이 begin end 말이다. 허나, 이 2000년대 관점에서는 저것들도 다 한물 간 언어가 돼 버리긴 했다.

(2) 파스칼은 program, unit, label, const, type, var 등 파트가 언어 문법 차원에서 나뉘어 있는 게 좀 구시대적이고 고지식하게 느껴지지만.. 한편으로 아주 깔끔하고 명료하게 느껴지기도 한다.
const도 말이다. C/C++에서는 그냥 type modifier의 일종일 뿐인 반면, 파스칼에서는 읽기 전용 상수값들만 선언하는 구간을 나타낸다. 의미는 같지만 용법은 요즘 언어들과는 완전히 다르다는 게 흥미롭다.

C++은 블록 아무 데서나 중구난방으로 타입 선언, 변수 선언, 실행문이 막 섞일 수 있다. 같은 문장이 명칭의 의미가 무엇인지에 따라서 변수(객체) 선언일 수도 있고 함수 선언일 수도 있다. 당장 타이핑 하기에는 간결하지만, 지저분하고 정신 없게 느껴질 수도 있다.

그에 비해 파스칼은 실행문이 있는 곳과 비실행 선언문이 있는 곳이 더 엄격하게 구분돼 있다. 여느 타입이나 변수뿐만 아니라 goto문 라벨조차도 선언을 미리 쭉 한 뒤에야 실제 문장에서 써먹을 수 있다.
이런 구조 덕분에 파스칼은 컴파일러를 만들기가 더 편하다. 언어 문법 차원에서 소스 코드를 두 번이 아니라 처음부터 끝까지 한 번만 쭉 읽으면서도 최적화 계획을 미리 세우면서 컴파일이 가능하다고 한다.

이런 특성이 있고, 또 파스칼은 C/C++ 같은 텍스트 인클루드가 난무하는 언어도 아니다 보니, 비슷한 분량의 코드를 컴파일하는 속도가 C/C++보다 훨씬 더 빠르다. 이런 점에서는 파스칼이 같은 네이티브 코드 생성 언어이면서 생산성이 더 뛰어나다.

(3) 파스칼은 C/C++ 계열 언어처럼 main 함수라는 게 따로 있는 게 아니며, 그냥 코드의 맨 마지막에 등장하는 begin end. 가 제일 먼저 실행된다. 요 begin end가 HTML로 치면 <body> </body> 태그나 마찬가지인 것 같다. 앞의 여러 uses, const, type 등의 선언들은 <head></head> 에 대응하고 말이다.

그리고 파스칼은 이 코드가 단독 실행형 프로그램인지, 아니면 라이브러리(= 파스칼 언어 용어로는 유닛)인지를 소스 코드 차원에서 명시하고 있다.
main 함수가 없는 대신, 맨 첫줄에 program 어쩌구; 아니면 unit 어쩌구; 이런다.
이건 Windows 프로그래밍의 관점에서 보면 모듈 def 파일의 내용을 일부 포함하는 거나 마찬가지이다. 신기하지 않은가?

그 뒤, 마지막 end 다음에 이어지는 마침표는 프로그램 코드의 완전한 끝을 의미한다. end.
이거 다음에 등장하는 텍스트들은 컴파일러가 몽땅 무시하고 짤라 버린다. 그렇기 때문에 주석이라고 감싸지 않아도, 파스칼 문법에 맞지 않은 텍스트가 등장해도 에러 처리되지 않는다!! 컴파일러에 따라서는 end. 이후에 또 whitespace가 아닌 문자가 있다고 경고 정도나 찍어 줄 뿐이다.

(4) 파스칼의 소스 코드는 C/C++처럼 헤더와 몸체의 구분이 없다. 그래도 단독 실행 프로그램이 아닌 유닛의 소스 코드는 내부적으로 선언부와 구현부의 구분이 존재한다. 그렇잖아도 파스칼은 모든 명칭에 대해서 사전 선언을 요구하는 언어이니.. 이런 구분이 존재하는 것이 자연스럽다.

그 구획을 나누는 키워드가 interface와 implementation이라는 길고 어려운 단어이다. 본인은 저 단어를 중학교 시절에 파스칼 언어의 예약어 명목으로 처음으로 접했었다.;;

(5) 표준 입출력 말고.. 텍스트의 입출력과 관련해서 플랫폼 종속적인 비표준 기능을 제공하는 라이브러리가 Turbo C에서는 conio.h였다. 그리고 Turbo Pascal에서는 uses crt.. 즉 CRT라는 이름의 모듈이었다.
그런데 C/C++에서는 CRT라는 게 C runtime library의 약자이며 conio는 console I/O를 뜻한다. 그럼 파스칼에서 저 CRT는 무엇의 이니셜일까?

그건 화면이라는 뜻에서 그냥 브라운관 CRT를 의미하는 듯하다.
그나저나 C건 파스칼이건 함수를 호출하는 건 동일할 텐데.. 역사적으로 함수 호출 컨벤션에 왜 PASCAL이라는 명칭이 붙어 있는지는 개인적으로 의문이다. 잘 모르겠다.;;

아무쪼록.. 파스칼은 이대로 묻히기에는 좀 아까운 독특한 언어이지만, 어쩌다 보니 오늘날 주류에서 밀려난 비운의 언어가 된 듯한 느낌이다.;;

3. 여담: 관련 타 언어들

(1) 안드로이드 진영에서 새로 채택한 언어인 Kotlin, 그리고 애플 진영에서 새로 채택한 언어인 Swift에서 모두 함수의 인자 나열을 C/Java 스타일인 (Type1 val1, Type2 val2)가 아니라..
파스칼 같은 (val1: Type1, val2: Type2)
요 문법을 채택해 있다. 따끈따끈 신흥 언어에서 나름 복고풍 파스칼이 느껴지는 것 같다. ㄷㄷㄷ

그리고 Kotlin은 변수를 선언할 때는 파스칼처럼 var 키워드를 쓰는데, 상수 명칭을 선언할 때는 그냥 '값'이라는 뜻에서 val 키워드를 쓴다.
정작 변수(var)는 L-value라고 여겨지는 반면, 값(var)은 R-value인데도 말이다~! L과 R의 교묘한 언어유희가 아닐 수 없다.

(2) 프로그래밍 언어 분야에는 의외로 미국 말고 유럽.. 그것도 서유럽 영프독이 아닌 다른 마이너(?) 국가 출신들이 기여한 게 많다.

• 파스칼은 저렇게 뜬금없이 스위스.
• 파이썬은 네덜란드 (귀도 반 로섬!!)
• C++은 덴마크 사람인 비야네 스트롭스트룹!!
• 그리고 볼랜드와 마소에서 펄펄 날았던 PL 전문가 겸 엔지니어인 Anders Hejlsberg도 덴마크!!

애초에 터보 컴파일러 씨리즈로 왕년에 이름을 날렸던 '볼랜드' 사 자체가 덴마크계 사람이 창립한 기업이었다.
한편, Lua는 브라질인지 포루투갈인지 아무튼 그쪽 바닥이다.

Posted by 사무엘

디지털 컴퓨터가 취급하는 데이터라는 건 (1) machine word 하나에 다 들어가고 함수 인자에 값이 그대로 전해지는 primitive type이 아니면.. (2) 별도의 메모리를 할당해서 저장하고, 평소엔 그 메모리 주소를 가리키는 포인터만 대신 취급하는 complex type 이렇게 둘로 나뉜다.
그럼 primitive type은? (1) 정수, (2) 포인터, (3) 아니면 부동소수점으로 종류가 크게 나뉘는 것 같다.

문자열은 complex type이고, 문자 하나는 정수라는 primitive type에 속한다.
포인터는 물리적인 형태는 정수와 다를 바 없지만 그 숫자값의 성격, 의미와 용도가 여느 정수와는 전혀 다르다. 그리고 특정 프로그래밍 언어 이념이나 프로그래머의 편의를 구현하기 위해, 무슨 오프셋이나 카운터 같은 부가 정보를 곁들인 약간 뚱뚱한 포인터도 있다. (스마트 포인터, 자기 함수나 클래스의 바깥 문맥도 지원하는 포인터, 다중 상속을 지원하는 멤버 함수 포인터 등등~)

다음으로 부동소수점이 있다. 얘 역시 완전 별개의 영역이다. 얘는 잘 알다시피 과학 시간에 배우는 x.xxxx * 10^yy 이러는 숫자 표기법을 2진법 기반으로 컴퓨터에다 구현한 것이다. x를 mantissa, y를 exponent라고 한다.
얘는 딱딱 떨어지는 이산적인 정보를 좋아하는 컴퓨터에다가 현실의 연속적인(실무 또는 수학 계산) 계산값을 표현하려 애쓴 근성의 산물이다.

부동소수점은 자리수와 관계 없이 유효숫자가 일정하게 보장된다. 그렇기 때문에 -1 ~ 1 사이의 0.xxx 구간이 압도적으로 제일 정밀하다. 32비트건 64비트건, 부동소수점으로 표현 가능한 수의 무려 절반이 -1과 1 사이에 치우쳐 있다. 절대값 1 이상인 양수 지수부와, 그렇지 않은 음수 지수부가 반반씩이니까 말이다~!!

그리고 그 안에서도 0과 0.5 사이에 표현 가능한 수와 0.5와 1 사이에 표현 가능한 수는..?? 지수부의 크기에 비례해서 수백 배 이상 폭발적으로 차이가 난다. 이게 부동소수점의 심오한 세계이다. =_=;;
숫자가 커질수록 표현 가능 구간이 급격히 듬성듬성해지니.. 가장 흔히 쓰이는 축에 드는 32비트 single 부동소수점 기준으로 숫자가 1700만 정도로 커지고 나면 정밀도가 1이 되어 정수와 다를 바 없어진다.

또한, 1/2^n 형태가 아닌 모든 소수점은 원래 형태 그대로 정확하게 표현되지 못하고 유효숫자 이후의 뒷부분이 버려진다. 이 점 역시 감안해야 한다.
부동소수점 숫자를 하나 받아서 이 수의 바로 다음 크기인 수를 구하는 알고리즘을 구현해 보면 어떨까 싶다..;;

이 외에도.. x86에서는 정수끼리 나눗셈을 시키면 몫과 나머지가 같이 구해져서 레지스터에 저장된다. 그리고 0으로 나누는 건 CPU 차원에서의 오류/예외로 처리된다.
그러나 부동소수점에서의 나눗셈은 나머지라는 개념이 없다. 그리고 0으로 나눈 결과는 그냥 NaN이라는 값으로 처리된다. 이런 식으로 서로 관점과 동작이 차이가 있다.

초기화되지 않은 부동소수점 변수는 프로그래밍 언어 차원에서 NaN으로 초기화하는 게 한 가지 방법일 것 같다. NaN이 '쓰레기값' 역할을 수행하는 셈인데.. 내 기억으로 D 언어가 이걸 실제로 수행한다고 한다.
그리고 IEEE754 부동소수점 규격을 보면 NaN도 아직 에러까지는 아닌 quiet NaN, 그리고 에러인 signalling NaN으로 나뉘어 있다.

현실의 프로그래밍 언어에서는 IEEE32 (single, float) 내지 64 (double) 이 둘만을 제일 많이 볼 것이다. 당장 마소 Excel이 취급하는 숫자의 자료형만 해도 64비트 double이다.
그러나 사실은 표준 규격으로나 역사적으로는 이보다 더 다양한 부동소수점 규격이 존재한다.

같은 공간 안에서 유효숫자 개수와 표현 가능한 자리수 구획을 정하는 건 꽤 미묘한 고민거리인 것 같다. 한 가지 확실한 건 전체 공간이 커지더라도 exponent는 그에 비례해서 쭉쭉 커질 필요가 없으며, 로그함수 급으로 아주 느리게 증가해도 된다는 것이다. (비율이 갈수록 작아짐) 말 그대로 2의 exponent 승만큼의 자리수를 표현할 수 있기 때문이다.
exponent가 8만 돼도 0이 38개나 붙은 자리수를 표현할 수 있고, 바이트 경계가 딱 나뉘어서 처리하기 편하다. 그렇기 때문에 어지간한 부동소수점 규격들이 얘를 8비트로 잡은 걸 볼 수 있다.

MBF는 오늘날 같은 IEEE754 표준 규격이란 게 등장하기 전, 1980년대 마소의 BASIC 언어에서만 독자적으로 쓰였던 규격이다. 빌 게이츠와 폴 앨런이 젊은 시절에 나름 이런 것까지 독자적으로 만들어서 구현했다니..
MBF32는 IEEE32와 공간 크기와 분배 배율이 동일하지만, 비트 배치 순서가 다르다. 그렇기 때문에 서로 바이너리 차원에서 곧바로 호환되지는 않는다.

mantissa와 exponent 모두 내부적으로 부호 비트가 존재한다. 전자의 부호는 표현하는 숫자 자체의 양-음 여부를 결정하며, 후자의 부호는 숫자가 1보다 큰지 여부를 결정하게 된다.
저 표에서 mantissa-1을 3.3으로 나누면 (3.3의 의미는 ln(10)/ln(2)의 근사값) 10진법 기준의 유효숫자 개수가 나온다.
그리고 표현 가능한 범위도 exponent-1을 3.3으로 나누면 10진법 기준의 표현 가능 최대 자리수가 나온다.

맨 위의 16비트 부동소수점은 half-precison floating point라고 불리는데, 유효숫자가 3개밖에 안 되고 5비트짜리 exponent로는 최대 자리수도 겨우 10000대밖에 안 된다. 그러니 실용적인 가치는 매우 낮지만 이런 숫자도 머신러닝 계산용으로는 쓰이는가 보다. 그렇기 때문에 FP16이라는 옵션도 있는 거겠지?
그리고 볼랜드의 16비트 파스칼 컴파일러에만 전무후무 존재했던 6바이트 Real은 존재가 참 독보적이다. 4도 8도 아닌 그 중간.;;

부동소수점은 그 구조상 숫자 2개를 조합해서 한 숫자를 표현하니, 각종 산술 연산이나 비교 따위가 정수를 취급하는 것보다 무겁고 부담스럽다. 특히 자칫 잘못하면 동일한 숫자를 표현하는 방식이 여러 개 존재할 수 있게 되니, 이를 방지하기 위해서 자리수를 일정하게 맞추는 '정규화'라는 규칙이 필요하다.
그리고 부동소수점 연산은 초딩 시절에 배웠던 어림셈과 비슷한 면모가 있다. 아주 큰 수에다가 아주 작은 수를 많이 더하면 오차가 쌓이고 결과가 안 좋아진다.

쌍팔년도 시절엔 부동소수점 연산을 하드웨어 가속으로 보조해 주는 CPU 애드온이 별도로 존재했다. 일명 FPU, 코프로세서.. 그 시절엔 이거 하나만으로도 존재감과 가격이 지금으로 치면 고급 게임용 GPU나 마찬가지였다.

286~486 시절엔 모든 컴퓨터에 코프로세서가 있는 게 아니었다(486은 제일 저가 깡통 모델인 SX만). 그렇기 때문에 그 시절의 컴파일러들은 부동소수점의 처리 방식을 지정하는 옵션이 있었다. 무슨 x87을 지원할지, 그런 FPU 코프로세서가 없는 경우를 대비한 소프트웨어 연산 처리 코드를 넣을지를 말이다. =_=;;

자고로 컴퓨터 프로그램이라면 정수나 포인터를 어떤 형태로든 취급하지 않고 동작한다는 건 거의 불가능하다.
그러나 부동소수점을 전혀 취급하지 않는 프로그램은 분야에 따라서는 얼마든지 있을 수 있다. 그러니 부동소수점을 더 빠르게 다루는 건 소프트웨어로나 하드웨어로나 오랫동안 추가 옵션으로 간주되었던 것이다.

하드웨어 현질 없이 소수점 연산을 빠르게 하기 위해서 고정소수점이라는 편법도 쓰였다. 기존 정수에다가 자리수만 기계적으로 옮기고 곱셈과 나눗셈 결과를 보정하는 것 말이다. 32비트 정수를 16:16 내지 26:6 이런 식으로 분할했다. 단점과 한계가 명백하지만 이게 성능 하나는 워낙 탁월하니.. 옛날 게임이나 폰트 엔진 같은 일부 분야에서 제한적으로 쓰였다. ㄲㄲㄲㄲㄲ

그러다가 펜티엄이 돼서야 부동소수점 명령이 CPU에 기본 내장되고 지원되게 됐다. 그랬는데 그 펜티엄에서 바로 FDIV 나눗셈 결함이 발견되기는 했지만.. 가정용 컴에서까지 걱정해야 할 무슨 심각한 보안 문제 급은 아니었다. 아주 극단적으로 크거나 작은 수를 다룰 때 아주 미세하게 발생하는 문제이기 때문에.

80비트 long double의 경우, x87 프로세서에서도 지원 자체는 한다. 심지어 더 작은 32/64비트 부동소수점을 다룰 때도 중간 계산 결과는 다 80비트로 취급하기도 한다. 그러나 x87 이후에 도입된 SIMD 명령은 80비트 부동소수점을 지원하지 않기 때문에 80비트가 사실상 봉인돼 버렸다.

이거 무슨 분당선 전철이 훗날 8량 편성으로 고정되면서 처음에 미리 만들어졌던 수서-오리의 10량 기준 승강장의 일부 영역이 봉인된 것과 비슷한 것과 비슷한 느낌이다.;; ㅋㅋㅋㅋㅋ
하물며 128이나 256비트짜리 초대형 부동소수점은 어디 쓰이는 곳이 있기는 한지 잘 모르겠다.

본인이 과거에 만들었던 프로그램 중에 부동소수점 연산을 많이 하는 축에 드는 놈으로는 "3차원 그래픽 시연 프로그램"이 있다. 빌드된 실행 파일을 들여다보면 x87 명령이 많이 쓰인 게 눈에 띄었다.
그런데 얘를 컴파일러를 업글해서 다시 빌드하니 코드의 레이아웃이 싹 바뀌었다. x87의 구닥다리 fmul fld fadd fstp 대신, addsd movaps mulsd 처럼 SIMD 명령이 쓰인 것이다.

얘는 부동소수점 한둘의 연산을 넘어, 벡터· 행렬 같은 여러 데이터의 연산을 한 명령으로 한꺼번에 처리해 주는 확장 명령이다. 1999년, 펜티엄 III에서 도입됐다.
이미 Visual C++ 200x 시절부터 이 명령을 사용해서 컴파일하는 옵션이 /arch에 딸려 있긴 했다. 그러다가 2012부터는 별다른 옵션이 없으면 이 명령 세트를 사용하는 게 디폴트가 됐다~!!

이게 예전 198~90년대에 x87 명령 사용 여부와 비슷한 컴파일 옵션인 셈이다. 2012에서는 Windows XP 지원도 공식적으로는 최초로 끊겼는데 참 많은 변화가 있었다.

이상이다. 부동소수점과 관련하여 할 말한 얘기가 생각보다 많았다. ^^
x87에는 사칙연산뿐만 아니라 제곱근, 삼각함수, 2를 밑으로 하는 지수와 로그 같은 간단한 초월함수까지 CPU 명령 하나로 해치워 준다. 그러나 그렇다고 모든 수학 함수를 지원하는 건 아니어서 e를 밑으로 하는 지수와 로그는 지원하지 않는다. 2는 지원하고 e는 지원하지 않는다니.. 진짜로 수학 대신 컴퓨터 지향적인듯. ㅎㅎ

그러니 CPU빨이 없는 수학 함수는 C 라이브러리에서 어떻게 구현돼 있을까..?? 궁금해진다.
그리고 부동소수점을 10진법 문자열로 변환하거나 vice versa하는 것 말이다. 이거 은근히 어렵고 번거로울 텐데? exponent와 mantissa를 다 진법 변환하면서 두벌일을 해야 하니까..
에니악 같은 초창기 컴퓨터가 그 비효율 삽질에도 불구하고 숫자를 처음부터 10진법 단위로 묶어서 표현한 이유도 이와 무관하지 않았지 싶다.

여담: 숫자 자체를 컴퓨터가 primitive로 지원하는 숫자 unit들 여러 개를 묶어서 complex type처럼 취급하는 분야는 다음과 같다.

• 수십~수백 자리 어마어마하게 큰 정수: 공개(비대칭) 키 암호화 라이브러리에서 필요하다. 금융 거래 같은 데서..;; 얘만 기막히게 빠르게 처리해 주는 정수 연산 라이브러리도 있다.
• 유리수: 부동소수점 단독으로는 유리수 하나도 정확하게 표현이 안 되니 정수 2개 분자/분모를 따로 취급한다. Windows 계산기가 내부적으로 이렇게 동작한다고 알려져 있다.
• 복소수: 부동소수점 2개를 묶어서 실수/허수를 표현한다. 수학· 과학 일부 분야에서 쓰인다. C++에 complex라는 클래스가 있는데, 템플릿 형태여서 정수만으로 구성된 복소수도 만들 수는 있다.
• 소수점만 임의의 자리수로: 전용 수학 패키지에서 쓰인다.
• 행렬· 벡터, 사원수: 더 이상의 자세한 설명은 생략한다. 게임을 포함해 컴퓨터그래픽 분야에서 쓰인다.

Posted by 사무엘

1. Windows의 컴퓨터 비트 수 변화

과거에 주류 PC 환경이 (1) 16비트에서 32비트로 바뀌면서 소프트웨어 개발 환경이 크게 바뀌었다.
int와 WPARAM, handle, 포인터가 모두 4바이트 크기로 바뀌었고, 이로 인해 메시지도 몇몇은 스펙이 불가피하게 바뀌었다.
좌표계의 기본 단위도 다들 32비트로 확장됐고, 이로 인해 GDI 함수들이 상당수가 Ex 버전으로 바뀌었다. 왜냐하면 예전처럼 x, y 좌표 둘을 long 하나에다 묶어서 전달할 수가 없어졌기 때문이다.

하지만 선점형 멀티스레드가 지원되고 그 전에 모든 프로세스들이 자기만의 독립된 주소 공간을 갖는다는 건.. 과거엔 정말 상상도 못 할 혜택이다.
8비트야 거의 임베디드 급의 열악한 환경이니 멀티태스킹 따위는 별나라 얘기였다. 16비트 시절엔.. 어정쩡하게 아주 불편하고 힘들게 가능했던 반면.. 32비트가 되니 주소 공간도 넉넉하고 이제 좀 그럭저럭 할 만해진 것이다.

그리고 32비트에 와서는 예전에 깐깐하게 구분해야 했던 게 이제는 구분이 필요 없어지고(예: HINSTANCE vs HMODULE, far vs near), 예전에는 꼭 할당하고 해제해 줘야 했던 게 지금은 그럴 필요가 없는 등(resource 관련 API, MAKEPROC 따위).. 프로그래밍 하기가 전반적으로 더 간편해지고 편리해지기도 했다.

그에 비해 (2) 32비트에서 64비트로의 변화는 뭐.. int와 포인터의 크기가 달라진 것으로 인한 자잘한 충돌과 이식성 문제가 고작이다. 4GB 한계가 없어지기만 했을 뿐, 체감되는 변화는 아주 미미하다.
Windows의 경우, int는 물론 long조차도 여전히 32비트 크기로 유지된다. 그러나 WPARAM은 64비트로 확장됐다.

전에도 한번 얘기했듯이 게임기는 1990년대 후반, PC는 2000년대 후반, 스마트폰은 2010년대 후반이 돼서야 슬슬 64비트 시대에 들어섰다.
이런 곳은 비트 수가 점진적으로 늘어났기 때문에 기존 코드와의 호환성이 중요했다. 그렇기 때문에 포인터만 빼고 int나 long은 4바이트로 할지 8바이트로 할지 고민이 많은 편이었다.

그 반면.. 슈퍼컴퓨터 전용 아키텍처가 있던 시절 말이다. 197, 80년대에 처음부터 64비트로 시작했던 컴터 환경에서는 레거시 고민 따위 없었다. Cray 같은 플랫폼에서는 쿨하게 처음부터 int고 포인터고 몽땅 다 무식하게 64비트 모델을 채용한 곳도 있었다고 한다. 물론 오늘날이야 int까지 8바이트인 컴퓨팅 환경은 없다고 봐도 되지만..
그리고 저런 옛날 컴퓨터들은 데이터를 취급하고 연산하는 단위만 64비트였다. 아무리 슈퍼컴이라 해도 자기네 메모리 용량이 4GB에 미치지는 못했기 때문에 64비트 컴퓨팅이 곧 64비트 addressing을 의미하지는 않았다고 한다. addressing까지 다 되는 64비트 CPU는 1990년대가 돼서야 등장했다. (MIPS, DEC Alpha 따위) 아하~

얘기가 좀 옆길로 샜는데.. 아무튼 Windows는 16비트에서 32비트로 넘어갈 때 변화가 좀 있었고, 32에서 64비트로의 변화는 미미한 편이었다. 그럼 Windows의 역사상 16비트에서 32비트로의 전환만이 대격변이었던 것일까?
꼭 그렇지는 않았다. 오히려 더 옛날, (3) Windows 1 (+2)과 3 사이는 플랫폼 SDK의 변화, C 컴파일러의 변화 등의 단절이 더 심했다.

Windows 1과 2는 아직도 리얼 모드 내지 끽해야 286 표준 모드에서 멀티태스킹을 구현하던 정말 암울한 시절이다.
Windows의 오랜 역사를 좀 아는 guru라면, 20세기에 Windows에서 가장 혁신적인 변화는 바로 95나 NT도 아니고 3.0에서 "386 확장(enhanced) 모드"가 정식 도입되었던 사건이라고 말할 정도이다. (☞ 링크)

그랬기 때문에 Windows 1과 3은 같은 16비트 기계어에 같은 NE 포맷임에도 불구하고 1용 프로그램이 후대의 3 내지 9x에서 제대로 실행되지 않을 가능성이 매우 높았다.
게다가 저 1980년대의 구닥다리 C 컴파일러는 함수를 정의하는 문법조차 ANSI가 아닌 기괴한 K&R 방식이었다니.. 소스 레벨의 호환성도 기대하기 어렵겠다. 더 자세한 건 여기 글을 참고하시라. (☞ 링크)

2. 마소의 16비트 P-code 기술

마소와 관련된 옛날 이야기가 계속 이어진다. 이 블로그에서 본인이 지금까지 이 얘기를 한 번도 꺼낸 적이 없었다니 놀랍다.;;
네이티브 기계어가 아니라 다른 중립적인 바이트코드 기반으로 돌아가는 '가상 기계 프로그램'이라 하면 흔히 Java (JVM)나 C# (.NET, CLR) 같은 것만 떠올리기 쉽다. 이런 건 최소 32비트 이상의 컴퓨팅 환경에서 등장한 런타임 환경이다. 고유한 클래스 라이브러리도 갖고 있고 쓰레기 수집기도 제공한다.

하지만 마소는 창립하자마자 그 허접한 197, 80년대 8비트 컴퓨터로 제일 먼저 만들었던 게 BASIC 인터프리터였다. 현대적인 가상 머신 정도로 거창하지는 않지만, 그래도 고유한 바이트코드 가상머신 기술을 보유해서 16비트 컴퓨팅 시대까지 잘 써먹었다.

마소에서는 그 바이트코드를 스스로 P-code라고 불렀다. P는 pseudo-, portable, packed(조밀) 등을 뜻했다고 한다. 그리고 그걸 Basic뿐만 아니라 C/C++ 언어 컴파일러에다가도 접목했었다. 아니, 베이식은 그렇다 치지만 기계어 직통 컴파일이 당연시되는 언어이던 C/C++에다가는 성능(= 실행 속도) 희생까지 감수하면서 도대체 왜..?

이 바이트코드는 크기가 작았기 때문이다. 이게 packed의 의미이다.
같은 프로그램 소스를 비슷한 최적화 수준으로 컴파일 했을 때, 네이티브 x86 기계어 코드보다 훨씬 더 작은 크기로 표현할 수 있었다. 심지어 P-code를 해독하는 가상머신 코드의 오버헤드(9K 남짓?)를 포함시키더라도 수지맞는 장사였을 정도라니.. 이건 뭐 실행 파일 압축 기능까지 약간이나마 겸한 셈이었다.

컴퓨터 역사의 관점에서 볼 때 x86 자체도 골수 CISC 구조로서, 현대적인 아키텍처 대비 기계어 코드가 조밀하고 크기가 아주 작은 축에 드는 아키텍처라고 여겨진다. (그 대신 읽어들이고 디코딩하는 난이도가 쥐약이고, 저전력 모바일과 상극)
그런데 마소의 P-code는 그 악명 높던 x86 기계어보다도 더 조밀하고 작다니.. 그 시절에 얼마나 메모리가 비싸고 귀했고 메모리를 어떻게든 아껴야 했는지가 실감이 간다. PC에서도 386 486 같은 32비트 CPU는 진작에 등장하고 값도 내려갔지만.. 메모리가 아직 병목이었다. 이게 더 싸지고 풍부해진 뒤에야 본격적으로 Windows 95/NT가 쓰일 수 있었다.

Visual Basic이야 exe를 생성한다 해도 런타임 dll이 따로 필요하고 내부 코드는 P-code 기반이었다. 1997년에 출시된 5.0.. 최초로 32비트 전용으로 출시된 이 버전에 이르러서야 네이티브 코드 컴파일 기능이 도입됐다.
C/C++의 경우, MS C/C++ 7.0과 Visual C++ 1.x 시절.. 16비트 한정으로 이런 기능이 있다가 32비트부터는 폐기됐다. 그 대신, 16비트이기만 하면 플랫폼은 DOS와 Windows를 모두 지원했다.

따지고 보면 Windows NT의 32비트 PE (portable executable)는 저런 P-code와는 접점이 없었던 셈이다. 32비트 Visual Basic 5나 6을 쓰지 않는 한 말이다
자세한 것은 이 링크의 설명을 참고하시라. 마소의 전설적인 P-code에 대해서 구체적으로 소개한 글은 "Microsoft P-Code Technology" by Andy Padawer이 유일한 것 같다.

QuickBasic이나 GWBASIC은 소스 코드를 고유한 바이너리 포맷으로 저장하는 기능이 있었다. 이건 세상 그 어느 프로그램 개발 환경에서도 없는 기능이었지 싶다.
그 반면, 저 P-code는 소스 코드가 아니라 나름 기계어를 표방하고 컴파일된 코드였다는 차이가 있다.

3. 마소와 볼랜드 프로그래밍 툴의 Windows 지원 내력

(1) 아마 예전에 이 얘기를 한 적이 있었을 텐데..
1980년대 말부터 마소와 볼랜드에서는 주요 프로그래밍/개발툴을 내놓으면서 뭔가 교육용 저가 보급형 제품군에다가는 각각 Quick과 Turbo라는 스피디한 브랜드명을 붙였고, 기업용 기함급 모델에다가는 그냥 자기 회사 이름을 붙였었다.

(2) 1990년대 초엔 C 컴파일러에는 C++의 지원이 추가되었다. 그래서 지원 언어 표기가 C/C++이라고 바뀌었다.
마소의 경우, QuickC는 Microsoft C를 먼저 만들다가 곁다리로 병행하며 잠깐 만들었던 제품이다. 이건 C++ 지원 없이 겨우 2.0에서 맥이 끊겼다. 그 대신 이전부터 만들어 오던 MS C 6의 다음 버전이 MS C/C++ 7이 되었다(1992). 그리고 이거 다음 버전부터는 그 이름도 찬란한 Visual 브랜드가 시작됐고, C는 떼어낸 채 Visual C++ 1로 넘어갔다.

저 때는 1993년 무렵이었다. Visual C++은 Windows NT와도 역사를 함께한다. 이게 마소에서 최초로 내놓은 32비트 C/C++ 컴파일러이며, Windows NT 내부의 각종 프로그램들을 빌드하는 용도로, 즉 자체적으로도 쓰였기 때문이다.
물론 Visual C++도 1.5까지는 16비트 버전이 같이 나오긴 했었다. 그리고 대외적인 버전 번호는 1로 리셋됐지만 얘 역시 MS C를 계승한 제품이라는 흔적은 MSC_VER이던가 그 매크로 상수의 번호에 남아 있다.

(3) 한편, 볼랜드 진영에서는 Turbo C 2.0의 다음 작품이 Turbo C++ 1.0이 되었다. 제품명과 버전이 다 리셋됐다니 좀 이례적이다.
그리고 그 다음 버전인 Turbo C++ 2때부터 같은 버전의 Borland C++도 나란히 나오기 시작했다고는 하는데.. 실질적으로 Turbo와 Borland의 구분이 생겼다고 일반인들이 존재감을 인지하는 첫 버전은 3이다.
Turbo C++은 3인가 3.1에서 맥이 끊겼다. 그 뒤 적어도 4~5 버전부터는 Borland C++만 나오다가 RAD 툴인 C++ Builder 1로 넘어갔다.

(4) 그 시절 C/C++ 컴파일러 업계에서는 C++ 지원뿐만 아니라 Windows 플랫폼의 지원도 중요한 이슈였다.
마소는 DOS에 이어 Windows를 만들던 본가였고, C는 어셈블리어와 더불어 자기들 제품을 만들 때 사용되는 주력 언어이기도 했다. 그러니 MS C는 처음부터 Windows를 지원하는 게 너무 당연한 일이었다.

1980년대 중반, 정말 구닥다리 MS C 4~5 시절부터.. 그야말로 전설적인 Windows 1.x, 2.x 프로그램을 만들 수 있었다. 단, QuickC는 DOS용 버전 2.x대와 별개로 QuickC for Windows 1.0이 딱 한 번만 나오고 말았던 듯하다. 요컨대 마소는 QuickC의 Windows 버전만이 버전 리셋을 했고, 볼랜드는 C++ 컴파일러를 구현할 때 버전 리셋을 했다.

그에 비해 볼랜드 제품에서 Windows 지원이 추가된 건 버전 3.x부터로, C++까지 지원되고 난 이후의 일이다. 심지어 Win32의 지원은 Windows 95가 출시되고 4.x 정도는 된 뒤부터다. 후발주자 3rd-party 업체이니 이런 것 수용은 한 발 늦을 수 있다지만.. Windows용 32비트 extender까지 미리 만들었던 Watcom 같은 업체하고는 개발 방향이 많이 달랐던 것 같다. 그 대신 볼랜드에서는 OWL이라고 꽤 잘 만든 객체지향 프레임워크를 연구 개발했다.
이렇듯, Windows 지원과 관련해서는 볼랜드와 마소 개발툴 간에 이런 내력의 차이가 있었던 셈이다.

(5) 자, 그럼 C/C++ 다음으로 파스칼의 세계로 가면..
볼랜드에서 Turbo Pascal을 내놓으면서 1980년대를 호령하고 재미를 봤다. 도스 아니면 기껏해야 OS/2에서 말이다. 그러다가 1990년대 초, Turbo Pascal 6 타이밍 때 TP for Windows를 1.0과 1.5 두 차례 내놓았다. 아마 5.x던가 6이던가..
이때 ObjectPascal이라는 객체지향 문법이 언어에 도입되기도 했지만 이건 TP의 버전에 영향을 주지 않았다. 그 대신 Windows용을 1.0부터 다시 내놓았다는 점이 Turbo C++과는 다르다.

그러다가 Turbo Pascal 버전 7이 Borland Pascal 7과 나란히 출시됐으며.. 이 BP7은 TP for Windows 2를 통합· 포함한 형태가 됐다. 제품 라인업 한번 복잡하네..;;
TPW는 about 대화상자에 수학자 파스칼 얼굴이 그려져 있는 반면, BPW는 그렇지 않다는 차이가 있다.;;;

1992년에 출시된 Borland C++ 3.1, 그리고 Borland Pascal 7이 도스와 Win16을 풍미했던 장수만세 안정판으로 여겨진다.
Borland C++은 C++ Builder로 넘어가기 전 1993~1995년 사이에 자체적으로 버전이 4~5까지 올라가기도 한 반면, BP는 델파이로 넘어가기 전에 딱히 버전업이 없었다.
심지어 Delphi도 1995년의 첫 버전 1은 Win16, 16비트용이었고 버전 2부터 Win32로 넘어갔으니, 32비트화도 C++보다 늦은 셈이다.

한편, 마소는?? 처음에 Microsoft Pascal을 1980년대에 4.x 버전까지 개발했었다. 하지만 이건 Turbo Pascal과의 경쟁에서 승산이 없다고 판단했는지 접었다. 그렇게 접기 직전에 경쟁사 제품처럼 뽀대나는 IDE를 얹은 QuickPascal 1.0을 최후의 발악 차원에서 한번 내놓았을 뿐이다. Windows 지원 같은 것도 당연히 없었고 제품의 맥이 끊겼다.
볼랜드에서는 Turbo Basic을 만들었다가 반대로 마소의 QuickBasic 대비 승산이 없다고 생각해서 포기해 버렸으니.. 행보가 서로 정반대인 셈이다.

Posted by 사무엘