대중에게 소프트웨어 개발자란 어떤 느낌일까요? 대부분은 컴퓨터 앞에 하루 종일 앉아서 키보드를 두드리는 것을 상상하지 않을까 싶습니다. 문서를 작성하는 데 워드프로세서가 필요하듯이, 하루 종일 소스 코드를 작성하는 프로그래머에게도 특별한 저작 도구가 필요하죠. 이런 걸 통합 개발 환경(integrated development environment; IDE)라고 합니다.

IDE의 역할은 다양합니다. 프로그래머가 작성한 코드를 이해(!)하고, 가끔 조언도 해 주며, 자동 완성은 기본이고, 프로그램의 전체 구조를 요약해서 보여주기도 합니다. 버그가 발생하면 쉽게 고칠 수 있게 도와주기도 합니다. 이렇게 기능이 많기 때문에 IDE란 대체로 버튼이 많고, 창이 많이 떠 있고, 복잡합니다.


[대표적인 IDE인 '이클립스'(Eclipse). 수..수많은 버튼과 창에 가버렷!]
[마치 비행기 조종석 앞에 앉은 기분이랄까요.]

그런데 이런 최첨단 저작 도구를 두고도, 여전히 도스 창에서 작업하는 사이코 변태들이 있습니다. (어라, 대체한 용어도 별로 나아보이지 않는데...) 이들은 IDE의 복잡성을 증오하고, 그 대신 메모장과 유사하지만 '편집'에 특화된 기묘한 프로그램을 주로 사용합니다. 바로 vim과 Emacs라고 불리는 것들인데요. 이것을 ['편집기'](editor)라고 부릅니다. 이 편집기가 가지고 있는 중에 어떤 것들이 있냐면...

* ['특정 문자가 발견될 때까지 글자를 지운다']는 단축키가 있습니다. 예를 들면... '마도카와 호무라는 영원토록 행복하게 살았습니다.'라는 문장이 있고, 현재 커서가 '영원' 앞에 있다고 합시다. 이때 특정한 단축키(구체적으로는 d-t-.)를 누르면, '마도카와 호무라는'만 남습니다. 딱 세 키만 눌러서 문장 일부를 증발시켜 버릴 수 있는 것입니다. ("파워! 언리미티드 파워!")

* 현재 커서 위치로부터 ['5글자만 복사'] 내지는 ['5줄만 복사'] 같은 단축키가 있습니다. 보통은 마우스로 영역을 선택하든지 Shift 키를 누르면서 영역을 선택한 후에 Ctrl+C를 할 테지만, 이 편집기는 상식을 거부합니다. 각각 '5-y-l', '5-y-y'라고 치면 원하는 영역만큼 복사가 됩니다.

* 현재 커서에 위치한 숫자를 [5만큼 증가]시키거나 [5만큼 감소]시키는 단축키도 있습니다. 예를 들어 123 위에 커서를 올려 두고 '5-^A' 하면 128이 됩니다.

위 예시로만 봐도 느끼실 테지만, 처음부터 끝까지 [단축키에 목숨을 거는] 편집기라고 할 수 있습니다. 단축키를 많이 쓰면 메뉴나 도구 막대를 사용하는 것보다 빠르게 작업할 수 있다는 것은 다들 아실 것입니다. 하지만 이 편집기는 좀 지나치게(..) 단축키에 목숨을 걸어서 웬만큼 상상할 수 있는 모든 커서 이동 및 편집 작업에는 다 단축키가 있다고 생각하시면 될 것 같습니다.

왜 이렇게 됐느냐? 바로 [도스 창에서만 돌아가기 때문입니다.] 마우스는 애초에 안 되고, 당시에는 메뉴 개념도 없었으니 이런 식으로 진화한 거죠. 무척 불친절하지만 한번 익혀두면 내 애인에게는 따뜻한 그런 프로그램입니다.

그래서 사실 저도 도스 창 종자(..)입니다. 예쁘게 꾸미는 데 전력을 다했죠.


[예쁘죠? 예쁘다고 해 주세요. 이거 스킨질하는 데 20시간 넘게 썼는데... ㅠㅠ]

----

서론이 길었습니다. 지금까지는 왜 도스 창을 쓰는지에 대한 자기 합리화였고 (..) 이제 본격적인 이야기를 시작하려고 합니다. 도스 창을 띄워 보신 적이 있으시죠? 만일 없으시다면 지금 하나 띄워 보세요. 시작 메뉴에서 '명령 프롬프트'를 선택하거나, '윈도 키 - R' 을 누른 후 'cmd' 라고 치시면 됩니다.

그런데 이 도스 창은 이상한 특징이 있습니다. 가로 크기가 죽어도 안 늘어나는 것입니다. 수치로 말하면, [가로 80글자로 고정되어 있습니다.] 왜 이러는 걸까요? 맥북 프로 레티나 해상도가 2560x1600인데, 이런 광활한 공간에서 고작 가로 80글자만 차지하고 있으니 얼마나 답답합니까. 저 같이 도스 창에서 작업하길 즐기시는 분들께 이 불합리성에 대해 물어 보면, 여러 가지 변명(?)이 나옵니다.

* 텍스트가 가로로 길면 가독성이 떨어져. 특정 길이로 제한하는 게 좋지.
* 한 번에 창 여러 개를 띄워 놓고 비교할 수 있으니 좋잖아.
* 이단이다!

좋습니다. 이런 이유가 타당하다고 치죠. 그래도 의문은 남습니다. 왜 하필 80글자입니까? 70글자나 90글자는 안 되나요? 좀 넉넉하게 100글자는? 실제로 어떤 회사는 사내 표준으로 '소스 코드의 가로 길이는 120글자를 넘기지 못한다'라는 기준을 정해 놨다고 하더군요. 80! 80이어야 하는 이유가 뭐죠?


[42 * 콩 - 콩 * 콩 = 80, 그래서 가로 80글자]

그래서 몇 가지 조사를 해 보았습니다. 우선, 도스 창의 선조격으로 여겨지는 ['VT100 비디오 터미널']이라는 고대적 유물이 있습니다. 78년에 나온 이 물건은 80x24(가로 80글자, 세로 24글자)라는 크기를 제시했고, 이후로 개발된 터미널들이 [VT100과 호환되게 만들려다 보니 80x24라는 규격이 굳어졌다]는 것입니다.

그렇군요. 하지만 아직 의문은 풀리지 않았습니다. 왜 VT100은 80x24를 채택했을까요? 뭔가 이유가 있었을 것 아닙니까. 그냥 자다가 갑자기 꿈에서 산신령이 나타나서 '가로 80글자로 하도록 하여라'라고 하진 않았을 테니.

이 문제에 대한 대답은 비교적 빠르게 나왔습니다. 검색해 보니, 한때 컴퓨터에 자료를 입력하는 유일한 수단이었던 [천공 카드(punched card)가 최대 80글자까지 입력] 받을 수 있기 때문이라는 것입니다.


[Z(1) = Y + W(1) 를 입력시키기 위한 천공 카드. 보시다시피 OMR 카드랑 원리가 똑같습니다. 저런 식으로 한 땀 한 땀 소스 코드를 입력하는 거죠... 고대의 프로그래머들에게 묵념을.]

아하. 그렇군요. 이제야 궁금증이 좀 풀리는 것 같습니다. 그런데 마지막으로 호기심이 생겼습니다. [그럼 왜 천공 카드는 80글자 크기였을까?]

정답은 60초 후에... 가 아니라, 그건 이런 이유입니다.

[당시 사용되던 1달러 지폐의 크기가 그 정도였거든요.]



천공 카드를 만들긴 해야겠는데, 이걸 보관하는 상자를 따로 개발하느니 그냥 기존 지폐 상자에 넣어 보관할 수 있도록 동일한 크기로 만들자는 생각을 한 것이죠. 그래서 1928년에 그 유명한 [IBM]이 달러 크기랑 천공 카드 크기를 똑같이 설정했고, 그게 지금까지 전해 내려 온 겁니다.

즉, 요약하면...

IBM이 1달러 지폐 크기에 맞춰 천공 카드를 만듦 -> 천공 카드 크기에 맞춰 구멍을 뚫다 보니 80글자가 적절함 -> 50년 후에 VT100이라는 유명한 비디오 터미널이 이 크기에 맞춰 80x24 규격을 만듦 -> MS가 도스를 만들면서 이 규격을 채용 -> 윈도 8.1 시절인 지금도 여전히 똑같은 크기의 도스 창 크기가 사용되고 있음

그렇습니다. [만악의 근원은 1달러 지폐]였던 거죠... 그러니까 이건 미국의 조폐 공사에 가서 따져야 하나..?

IT의 역사를 보다 보면 (아마 다른 분야도 그렇겠지만) 관계 없어 보이는 부분의 유산이 영향을 미쳐 지금처럼 된 경우가 많습니다. 물론 각 단계 하나 하나는 충분한 이유가 있지만, 여러 단계를 종합해 보면 뜬금 없어 보이는 것이죠. 나비 효과라고나 할까요.

제품 디자인할 때 기존 사용자에게 친숙해 보일 목적으로 기존의 질감을 흉내 내는 것을 스큐어모피즘(skeuomorphism)이라고 하죠. 기술 표준을 제정할 때 비슷한 게 있다면 이런 느낌이지 않을까 싶군요.

오늘의 결론: 표준을 정의할 때는 신중히. 최소 50년 앞은 내다보고 정의하도록 하자. (..) 그리고 [1달러 지폐를 좀 더 크게 만들지 않은 미국을 원망하자.]