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

• 프로그래밍 언어 이야기, 연재를 시작하며
• 프로그래밍 언어 이야기 1 - 베이직
• 프로그래밍 언어 이야기 2 - 파스칼
• 프로그래밍 언어 이야기 3 - C 언어

-----

바쁘다는 핑계로 한동안 쉬었던 "프로그래밍 언어 이야기" 연재를 8개월만에 재개해 봅니다. 미네르바 사건 등 사회적 이슈에 주로 관심있으신 분들께는 아무래도 많이 생소한 주제일 것입니다. 프로그래밍 분야에 특별히 관심이 없는 분들은 그냥 건너뛰시기 바랍니다. ;)

-----

C는 1972년 유닉스에서 사용하기 위해 벨 연구소의 데니스 리치가 만든 프로그래밍 언어로, 프로그래밍을 공부하는 과정에서 대개 한 번 쯤은 거쳐가는 언어이다.

나는 대학생때 "The C Programming Language" 책으로 C 언어를 공부했는데, 270페이지의 책 두께가 보여주듯이 C는 꽤나 간결한 언어이다. ("The Ruby Programming Language"가 450페이지, "Core Java, Vol. 1"과 "Core Java, Vol. 2"가 합쳐서 1,900페이지인 것과 비교해보라!)

C의 주요 특징/장점은 아래와 같다.

1. 포인터를 통해 (할당받은) 메모리 영역을 직접 조작할 수 있다.
2. 실질적으로 현존하는 모든 운영체제의 ABI가 C를 기준으로 설계돼 있다.
3. 모든 시스템 프로그래밍 레벨 라이브러리들은 항상 C API를 제공한다. (그리고 타 언어 API는 늘 해당 C API를 기반으로 구현된다.)
4. 다른 프로그래밍 언어들이 대부분 C로 구현돼 있기 때문에, 해당 언어의 익스텐션 개발도 C로 이뤄진다.

1번은 이미치 처리 등과 같이 메모리의 효율적 사용이 필수적인 종류의 알고리즘에서 매우 중요하게 작용한다.

2, 3, 4번은 현재의 (그리고 지난 30여년간의) 프로그래밍 환경에서 추상계층 하부구조가 가진 특성을 반영한다. (아마도 새로운 운영체제와 시스템 프로그래밍 언어가 동시에 만들어지지 않는 이상, 이러한 하부구조는 앞으로도 쉽게 변하기 어려울 것이다.)

나는 프로그래머들이 C에 대해 두가지의 태도를 견지해야 한다고 생각한다.

C는 소프트웨어 추상계층의 하부를 장악하고 있는 언어이다. 그런 점에서 C를 잘 다루는 것은 실용적인 관점에서도 매우 중요하다. 주 언어가 C가 아닌 프로그래머라도 C를 사용할 줄 모른다면 소프트웨어적 문제해결에 있어 여러가지 한계에 부닥치게 된다.

하지만 다른 관점에서 C는 만들어진지가 40년이나 된 낡은 언어이기도 하다. 그같은 구닥다리 언어가 여전히 소프트웨어 추상계층의 하부를 장악하고 있는 현상은 프로그래밍 환경의 발전에 있어 여러 제약 사항으로 작용하고 있는 것 또한 사실이다.

지난 10년여간의 "프로그래밍 언어 르네상스"의 시기를 거치면서, 함수 리터럴(클로져), 메타프로그래밍, 병렬 프로그래밍 등에 대한 프로그래머들의 새로운 관심은 이들 기능에 대한 지원을 어떻게 좀더 소프트웨어 추상계층의 하부로 이동시킬 지에 대한 논의 또한 유발시키고 있다. (실제로 애플의 경우는 맥 OS X 10.6에서 C 언어에 비표준 클로져 익스텐션을 추가하고 이를 이용해 새로운 병렬 프로그래밍 API를 구현해냈다.)

눈여겨 볼만한 사실은 지난 10여년간 로우레벨을 능숙히 다루는 프로그래머들의 숫자가 급감하면서 소프트웨어 추상계층 하부에서의 혁신이 무척 더뎌졌다는 점이다. 오히려 그래서 시스템 프로그래밍 언어 구현, 운영체제 설계 등의 로우레벨 분야에서 앞으로 흥미로운 기회들이 많이 생겨날 것으로 보인다.

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

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

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

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

• 프로그래밍 언어 이야기, 연재를 시작하며
• 프로그래밍 언어 이야기 1 - 베이직
• 프로그래밍 언어 이야기 2 - 파스칼
• 프로그래밍 언어 이야기 3 - C 언어

-----

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 - 베이직
• 프로그래밍 언어 이야기 2 - 파스칼
• 프로그래밍 언어 이야기 3 - C 언어

-----

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 프로그래밍을 지원하는 비주얼 베이직 등으로 발전하게 된다.

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

• 프로그래밍 언어 이야기, 연재를 시작하며
• 프로그래밍 언어 이야기 1 - 베이직
• 프로그래밍 언어 이야기 2 - 파스칼
• 프로그래밍 언어 이야기 3 - C 언어

-----

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

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

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