Trace foward

백업하는 중에 문득

요즘은 하드 용량이 커져서 백업에 꽤나 시간이 오래 걸린다. 처음에는 저 많은 공간을 뭘로 채우나 했는데, 하드 용량이 늘어난 비율로 데이터에 거품이 생기는 듯도 하고. ㅎ

원격 스토리지로 백업중. 두시간여 후에는 눈내린 레오파드로 업그레이드할 예정.

혹시 Ars Technica의 존 시라큐사나 존 스토크스의 연재 챙겨보는 분들 계시면 댓글이나 이메일로 기척 좀 주시라. 언제 맥주 한 잔 하면서 OS/CPU 이야기로 수다나 떨어봅시다.

[연재] 프로그래밍 언어 이야기 2 - 파스칼

"프로그래밍 언어 이야기" 연재

  1. [연재] 프로그래밍 언어 이야기 1 - 베이직
  2. [연재] 프로그래밍 언어 이야기 2 - 파스칼

-----

80년대만 하더라도 마이크로소프트는 IBM 호환 컴퓨터용 공식 운영체제인 MS-DOS를 공급하는 그냥그런 소프트웨어 회사에 불과했다. MS-DOS는 SCP사의 86-DOS를 인수해서 이름만 바꾼 것이었고, 86-DOS 또한 Digital Research사의 CP/M을 배껴 만든 클론 제품이었다. (86-DOS의 원래 이름이 QDOS = "Quick and Dirty Operating System" = "대강 빨리 개발한 운영체제"였다는건 시사하는 바가 적지 않다.)

평상시 유닉스 쉘을 쓰다가 가끔 윈도우에서 DOS 창을 띄울 일이 있으면 한숨부터 쉬는 이들이 많을텐데, 그런게 30년전 누군가가 "대강 빨리 개발한 운영체제"의 한계인 것이다. 시장에서 성공하는게 꼭 좋은 기술이지 않다는건 늘 모두의 불행이니까. 물론 마이크로소프트는 MS-DOS를 "Microsoft Disk Operating System"의 줄임말로 홍보했고 오늘날 대부분의 사람들은 DOS를 "디스크 운영체제"라는 의미로 기억하고 있다.

마이크로소프트가 오늘날의 종합 소프트웨어 회사로 입지를 굳히기 시작한 것은 90년대 중반 DOS가 윈도우로 대체되면서 부터였다. DOS 시절엔 워드 프로세서는 워드 퍼펙트사, 스프레드시트는 로터스사, 소프트웨어 개발 도구는 볼랜드사 등이 각각의 시장에서 독주하고 있었다. 로터스의 총 자산 규모가 마이크로소프트를 상회했던 시절이다. 이후 마이크로소프트는 윈도우 운영체제 공급자로서의 위계를 지렛대삼아 이들 회사 모두를 시장에서 사장시켜 버렸다.

내가 파스칼을 처음 접한 것은 1994년, 그러니까 정확히 15년전의 일이다. 아직 윈도우와 DOS가 병행으로 사용되던 시기였고, 나의 파스칼 개발 환경도 볼랜드의 터보 파스칼이었다. 아래는 터보 파스칼의 실행 화면이다.

간단한 파스칼 코드도 한 번 살펴보자. 코드 첫째줄의 "uses crt;"는 crt 라이브러리를 사용하겠다는 의미이고, var 섹션은 변수 선언, 그리고 begin/end는 코드 섹션이다.

uses crt;

var
  Name : String;
begin
  Clrscr;
  Write('What is your name? ');
  Readln(Name);
  Writeln;
  Writeln('Hello, ', Name, '.');
end.

당시 프로그래밍에 푹 빠져 지내던 나는 "개인적인 목적으로 프로그램을 만들어 쓰는게 과연 실용적인 일일까?"라는 질문에 답을 찾고 있었다. 수십명의 프로그래머가 여러해에 걸쳐 개발하는 거창한 프로그램 보다는 혼자 만들어서 일상에서 쓸 수 있는 프로그램을 만드는 것에 관심이 더 많았기 때문이다.

왠만큼 파스칼이 손에 익었을때 나는 탁구 게임 하나를 만들기 시작했다. 그건 프로그래밍의 ROI 효율성을 가늠해 보려는 일종의 테스트였다. 얼마나 오래걸릴까? 3개월, 6개월, 1년? 탁구대 위로 탁구공이 원근효과를 내며 날아가는 모션을 모델링하는데만 꼬박 2주가 걸리더라. 그런 속도라면 1-2년은 족히 걸릴 듯 했다. 그 이후로 나는 프로그래밍의 실용성에 다소 회의적인 인식을 갖게 됐고, 이 중독성 강한 취미를 자중하느라 애썼다.

흔히 파스칼을 교육용 프로그래밍 언어라고 말하는데, 그건 역설이 아니었나 하는 생각을 해본다. 교육용으로 특화된 언어가 되려 프로그래밍에 대한 열정과 흥미를 반감시켰으니. 10년쯤 지나서 그때 펄(Perl)을 접했으면 어땠을까 하는 생각이 들었던건 아쉬움일거다.

개인적인 목적으로 프로그램을 만들어 쓰는게 과연 실용적인 일일까? 이 질문은 지난 15년간 내게 중요한 화두였다. 그 막연한 가능성 하나가 내가 이 시간 먹는 하마 같은 취미를 놓지 않았던 이유였으니까.

어찌됐든 나는 파스칼을 3년간 잡고 있었다. 이후 파스칼은 객체지향 프로그래밍을 지원하는 옵젝트 파스칼, GUI 프로그래밍을 지원하는 델파이 등으로 발전해갔다.

[연재] 프로그래밍 언어 이야기 1 - 베이직

"프로그래밍 언어 이야기" 연재

  1. [연재] 프로그래밍 언어 이야기 1 - 베이직
  2. [연재] 프로그래밍 언어 이야기 2 - 파스칼

-----

1989년, 그러니까 지금으로부터 정확히 20년 전이다. 동네에 컴퓨터 학원이 처음으로 문을 열었고, 나는 그곳에서 베이직(BASIC)을 처음 접했다. 개인용 컴퓨터는 아직 8비트 컴퓨터가 주류였고, 최소한의 컴퓨팅 자원을 필요로하는 베이직이 널리 사용되던 시기였다. 당시의 내 컴퓨터는 애플 IIe였는데, 메모리 용량이 아마 64KB였을 것이다.

베이직의 가장 큰 특징은 행번호였다. 프로그래머가 소스코드를 작성하면서 행마다 직접 번호를 매겨줘야 했다. 행번호가 필요했던 이유 중 하나는 텍스트 편집기가 없어서 코드를 수정할 일이 생기면 특정 행을 새로 입력해야 했기 때문이다.

] 10 PRINT "HELLO, WORLD"
] 20 END
] LIST
  10 PRINT "HELLO, WORLD"
  20 END
] 10 PRINT "HELLO, DAESAN"
] LIST
  10 PRINT "HELLO, DAESAN"
  20 END
] RUN
HELLO, DAESAN

당시 학원에서는 순서도(Flow Chart) 그리는걸 가르쳤는데, 소스코드 수정이 쉽지 않으니까 처음부터 설계를 잘하라는 의미였던 듯 하다. ㅎ

행번호로는 아무 숫자(정수)나 사용할 수 있는데, 보통 10 단위로 사용하는게 관례였다. 만약 나중에 새로운 코드를 추가하려면 여유치가 필요했기 때문이다. 행번호가 필요한 또다른 이유는 GOTO 문 때문이었다.

10 INPUT "ENTER A NUMBER", N
20 IF N = 1 THEN GOTO 40
30 IF N = 2 THEN GOTO 60
40 PRINT "YOU HAVE ENTERED ONE"
50 GOTO 70
60 PRINT "YOU HAVE ENTERED TWO"
70 END

위와 같이 GOTO 문에 의존해서 프로그램의 실행 플로우를 제어하는 프로그래밍 패러다임을 "비구조적 프로그래밍"이라 부른다. 프로그래밍의 초창기에는 프로그래밍 언어가 GOTO 문을 지원하는 것이 옳으냐 그르냐를 가지고 적지 않은 논쟁이 있었다고 한다. 이 논쟁에 종지부를 찍은 것이 그 유명한 에츠허르 데이크스트라의 "위험한 GOTO 문(Go To Statement Considered Harmful)" 에세이이다.

베이직은 GOTO 문과 같이 거의 어셈블리어 수준의 로우레벨적인 특성과 초보자도 익힐 수 있는 하이레벨 언어의 모습을 동시에 가진 프로그래밍 언어였다. 어찌됐든 잘 설계된 언어는 아니었고 베이직에 노출된 프로그래머는 뇌가 영영 망가진다는 악담도 있었다. 다행히 이름이 "초보"를 연상시키는 베이직(BASIC)라서 마초 성향이 강한 프로그래머들로서는 처음 프로그래밍을 배울때 한 번 거쳐가는 언어인 경우가 많았다.

베이직은 이후에 텍스트 편집기 기능을 지원하는 GW 베이직, 객체지향 프로그래밍을 지원하는 리얼 베이직, GUI 프로그래밍을 지원하는 비주얼 베이직 등으로 발전하게 된다.

[연재] 프로그래밍 언어 이야기, 연재를 시작하며

왜 프로그래머들은 끊임없이 새로운 프로그래밍 언어를 만들어내는 것일까? 기존의 언어에 뭔가 부족한 면이 있기 때문이다. 때로는 후퇴하는 듯도 보이지만 크게 보면 프로그래밍 언어는 꾸준히 발전해 왔다.

지난 20년간 내가 하나의 언어를 접하고 뭔가 아쉬운 점을 느끼고 또다른 언어를 찾아나섰던 반복의 과정을 한 번 회고해볼까 한다. 내 생각을 정리해보는 동시에 다른 이들과 담론을 나눌 기회가 됐으면 하는 바램이다.

  1. 베이직
  2. 파스칼
  3. C++
  4. HTML
  5. XML
  6. C
  7. 자바
  8. 어셈블리어
  9. 해스켈
  10. 리스프
  11. PHP
  12. SQL
  13. CSS
  14. 애플스크립트
  15. 자바스크립트
  16. 액션스크립트
  17. Objective-C
  18. 스몰토크
  19. 루비
  20. 파이썬
  21. 얼랭

바람직한 URL 설계

URL(Uniform Resource Locator)은 "자원(Resource)을 가리키는 고유한(Uniform) 지표(Locator)"를 말한다. 웹의 경우, 자원은 "웹 페이지"이고 지표는 "http://"로 시작하는 웹 주소다. 즉, 웹 URL은 특정 웹 페이지를 가리키는 고유한 주소인 것이다.

여기서 주목해야할 단어는 "고유한(Uniform)"이다. 예를 들어 주민등록 번호는 고유하다. 이는 주민등록 번호로 한 사람을 특정할 수 있으며, 한명의 사람은 한개의 주민등록 번호를 가진다는 의미이다. 다시말하면, URL을 통해 우리는 그에 해당하는 웹 페이지를 특정할 수 있으며 한 웹 페이지는 하나의 URL만을 가져야 한다는 의미다. 실제로 그러한가?

인터넷 한겨레 사이트를 한번 살펴보자. 이 매체의 홈페이지 URL은 "http://hani.co.kr/"과 "http://www.hani.co.kr/" 두가지이다. 문제는 "hani.co.kr"로 들어가면 모든 기사의 URL이 "http://hani.co.kr/..."로 시작하고, "www.hani.co.kr"로 들어가면 모든 기사의 URL이 "http://www.hani.co.kr/..."로 시작한다는 것이다. 어느 쪽이 정확한 URL 주소일까? 구글에서 "인터넷 한겨레"로 검색해보니 주소가 "www.hani.co.kr"로 나온다. 아마도 인터넷에는 이 주소로 링크된 경우가 더 많은가 보다.

나의 경우는 한겨레 사이트를 자주 방문하는 편이라, URL을 기억해서 웹 브라우저 주소창에 "hani.co.kr"이라고 입력하는 것이 보통이다. 때문에 한겨레 사이트에 방문하거나 특정 기사를 링크할 때, 자연스럽게 "http://hani.co.kr/..."로 시작하는 주소를 사용하게 된다.

이 문제는 비단 한겨레 뿐만 아니라, 조선일보, 동아일보, 프레시안 등 언론사 사이트를 포함한 여러 국내 사이트에 공통적으로 나타나는 현상이다. 사소한 부주의 때문이겠지만, 이 문제의 파급은 의외로 크다.

특정 페이지의 URL이 여럿인 경우, 외부 사이트에서 이 페이지에 링크가 걸릴 때도 제각각의 URL이 사용된다. 대부분의 검색 엔진은 웹 페이지를 인덱스할때 외부 사이트에서 얼마나 많은 링크가 걸린 지를 주요 지표로 사용하는데, 동일한 페이지가 다른 URL로 링크된다면 당연히 검색 인덱싱에 있어 불리할 것이다.

데이터를 활용하는 입장에서도 불편함이 있다. 예를 들면, URL의 도메인 부분을 기준으로 링크 데이터베이스를 만드는 경우이다. 실제로는 같은 페이지인데 도메인(서브도메인)이 다르기 때문에 다른 사이트의 페이지로 인식이 되는 문제가 있다.

해결법은 뭘까? 해당 페이지의 공식 URL이 어떤 것인지를 명확히 정하고, 비공식 URL로 접근시 "301 moved permanently" HTTP 헤더를 사용하여 공식 페이지로 리디렉트 시키는 것이다.