Yonghwan's Blog

자유소프트웨어의 본질은 무료, 자유도, 또는 기술이 아닌 나와 공공의 안전에 있다.

이미 지난 10년을 "오픈소스"라고 씌인 머리끈을 묶고 밥 벌어 먹고 살아오는 동안, 어느 틈엔가 그 속에서 삶, 직업이라는 관념 속에 희석되어버린 나의 모습을... 얼마 전, 이 주제와는 별로 관련도 없는 대화 속에서 발견해버렸다. 자유소프트웨어 정신.

요즘은 자유소프트웨어라는 용어보다 오픈소스 소프트웨어라는 용어를 더 많이 쓰고 접하게 되는데, 내가 몸 담고 있는 팀의 이름도 그렇고... 오픈소스 라는 용어의 포괄성 때문인지, 대부분의 매체나 기관에서 이 용어를 사용하고 있는 상황이다.

음... "오픈소스, 그것으로 어떻게 돈을 벌 수 있는가?" 라는 해묵은 질문이 그 순간 나를 자극한 것일까? "그래, 과연 오픈소스가 돈이 되는 거야?", "아니, 그렇다면 오픈소스라는 것의 본질은 무엇인데?", "도대체 왜 소스를 공개하겠다는 것이야?" (본질을 모른 채 그것을 이용하여 돈을 벌겠다는 것은 우끼지 않은가?)

내 주관적 기준으로 이 질문의 답을 찾아 거슬러 올라가다 보니, 내가 왜 이 일을 하게 되었는지, 내가 어쩌다가 이 길을 걷고 있는지를 다시금 생각해보지 않을 수 없었다. 누가 나의 마음을 흔들어 놓았나? 왜 내가 만든, 당신이 만든 소스를 열어야 하는가? ... 어쨌든,

업무 속에서 오픈소스에 대하여 이야기하거나 또는 이야기를 듣게 되면, 대체로 무료라는 점과 공급자에게 얽메이지 않는다는 점, 공개소프트웨어 개발 방식에 의한 장점, 자꾸 열려만 가는 세상 돌아가는 분위기 등의 "현상"에 집중하여 이야기되는 듯 하다. 자본주의 체제 안에서 돈을 조금이라도 더 모으기 위하여 투자를 줄이려는 것도 맞는 얘기고 경제적으로든 결정권에 대한 부분이든 누군가에게 끌려다니고 싶지 않다는 것도 맞는 얘기다. 물론, 소수의 재능있는 사람들이 만드는 물건보다 (그들을 포함해서) 수많은 눈들이 부릅뜨고 보고 있는, 수없이 다양하고 심도있는 개발자들의 역량이 자율(또는 과시, 존재감의 발로)에 의하여 녹아나오는 방식의 장점 역시 오픈소스 소프트웨어를 강하게 만드는 힘이 되고 있고, 이렇한 방식 또는 유사한 개념이 세상을 더 강하게 만드는 것도 그렇다. 그런데 이것이 "본질"일까? 글쎄... 이것은 단지 "현상"일 뿐이지 않을까? 그럼 왜! 열어야만 하는가?

소프트웨어는 딱히 모양을 갖추고 있거나 손에 잡히지 않는 특징이 있긴 하지만 기존의 음식물, 건축물, 생활 필수품 등과 마찮가지로 이미 우리 사회에서 없어서는 안되는 "중요한 부품"이 되어버렸다. 음식물이 그렇듯, 건축물이 그렇듯, 흔들려서는 안되는, 어쩌면 생존의 문제와 직결되는 성격을 분명히 가지고 있다는 얘기다. 따라서, 우리가 음식에 대한 안전성을 소비자에게 확인시키고 건물의 설계도를 숨기지 않듯이, 소프트웨어 역시 그것이 어떤 구성요소로 이루어져 있는지, 어떻게 만들어졌는지 최종 사용자로 하여금 필요한 경우에 확인할 수 있도록 길을 열어두어야 하는 것이다.

내가 간식으로 먹을 음료수에 내 몸을 파괴할 가능성이 있는 발암물질이 함유되어있지는 않은지 확인하고 싶듯이, 집의 구조를 바꾸고 싶을 때 어떤 벽이 내력벽인지 설계를 확인해야 하듯이, 천정에서 물이 떨어지기 시작했을 때 어디를 손봐야 하는지 들여다 봐야 하듯이, 소프트웨어가 우리 삶의 중요한 부분 곳곳에 녹아들어 있다면 그것 역시, 어떤 구성요소로 개발되었는지, 어떻게 씌여져 있는지, 필요한 경우에는 리버스 엔지니어링까지도 가능하도록 되어있어야 한다. 내 집을 지은 회사가 아니더라도 가까운 주택 수리 업체로부터 집 수리 서비스를 받을 수 있어야 하듯이, 소프트웨어 원 저작자나 제작사가 곁에 없더라도 (망했든, 유지보수 계약이 끝났든) 지금 도움을 받을 수 있는 다른 개발자나 회사로부터 (대체로 잘 돌아가고 있는) 소프트웨어의 문제 부분을 찾아 수정할 수 있어야 한다. (물론, 그 소프트웨어의 소스가 열려있다고 하더라도 쉬운 일은 아니지만 최소한 가능성은 있다.)

소프트웨어라는 것이 특수 분야의 것이 아닌 이상, 또는 우리 생활에 밀접한 소프트웨어일수록 그것은 이미 공공의 영역에 있다고 봐야 할 것 같다. 공공 영역에 있다는 말은 주인이 없다는 뜻이 아니라 모두가 주인이라는 뜻이다. 다시 말해서, 모두에게 그것이 어떻게 만들어졌는지 알 수 있도록 열려있어야만 한다. 그렇다면, 오히려 속이 가려져 있어서 문제가 있더라도 그 내용을 확인할 수 없고 공공의 이익을 위하여 문제의 수정이 필요하더라도 원 저작자가 아니면 어찌할 수 없는 소프트웨어는 이미 그 존재부터가 공공의 적이 아닐까?

자유소프트웨어의 핵심 원리는 사회적 책임이다.

소프트웨어 엔지니어라는 표현 속에는 엔지니어로써의 사회적 책임과 의무가 포함되어 있다. 사회적 책임이란 무엇일가? 자신이 한 일의 품질을 책임져야 함은 물론, 그로 인하여 발생하는 부가적 문제에 대한 책임이 포함되어 있는 것이다. 그렇다면 소프트웨어 엔지니어 개인 또는 그들이 속한 집단, 회사가 책임질 수 있는 범위와 한계는 어디까지일까? 교통사고로부터 자유로운 사람이 있을가? 회사의 지속적인 존재를 보장할 수는 있을까? (최소한 소프트웨어의 생명주기 범위 내에서라도...) ... 오픈소스 기업이 주장하는 "소유 및 사용권 판매가 아닌 서비스"라는 사업 형태는 그러한 모습을 가짐으로써 이러한 문제로부터 기업과 사회가 서로 자유로와 지는 것이 아닐까? 그렇다면 사용자 입장에서는 베일에 가린 소프트웨어의 "사용권 구매"가 안전한 것인가 속이 훤히 보이는 소프트웨어에 대한 "서비스 구매"가 안전한 것인가?

잊고 지냈던 초심을 다시금 기억하게 해준 한 동료에 대한 진정어린 감사를 마음에 담고...

기술자들이여, 왜 screen을 사용하지 않는가? 싸잡아서 "기술자들이여" 라고 말한 부분은 좀 문제가 있다. 공격적인, 과격해보이는 과장이랄까? 그런데 정말, 근래에 만난 기술자들 중에 screen을 사용하는 사람을 보지 못했다. 왜지?

스크린은 여러 프로세스, 특히 대화형 쉘 들이 물리적 터미널을 함께 사용할 수 있도록 해주는 전체화면 창관리자이다. 각각의 가상 터미널은 DEC VT100 터미널의 기능과 더불어 ANSI X3.64와 ISO 2022 표준의 몇몇 제어 기능(예들 들어 줄의 삽입/삭제와 다중문자셋 지원 등)을 제공한다...

GNU 소프트웨어인 screen 에 대한 소개 중 일부분이다. (소개문 전문은 아래에 인용해뒀다.) 이 프로그램에 대한 정의를 내리자면 위의 소개문처럼, "물리적 터미널의 공유를 위한 전체화면 모드의 창관리자"이다. 사실, "창"이라는 표현이 좀 애매할 수 있다. "창"에서 떠올리는 이미지는 그래픽 환경에서 데스크탑위에 떠있는 네모들이겠지만, 여기서 말하는 창은 화면, 또는 터미널을 의미하는 것이다. 다시 말해서, 단일 물리적 터미널을 가상의 여러 터미널로 변신시켜주고, 그래서 여러개의 비 그래픽 모드 프로그램을 하나의 물리적 터미널 안에서 동시에 실행할 수 있게 해주는 녀석이라고 정리할 수 있다.

GNU Screen - GNU Project - Free Software Foundation (FSF)

Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells. Each virtual terminal provides the functions of the DEC VT100 terminal and, in addition, several control functions from the ANSI X3.64 (ISO 6429) and ISO 2022 standards (e.g., insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows the user to move text regions between windows. When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out of your way so that you can use the program as you normally would. Then, at any time, you can create new (full-screen) windows with other programs in them (including more shells), kill the current window, view a list of the active windows, turn output logging on and off, copy text between windows, view the scrollback history, switch between windows, etc. All windows run their programs completely independent of each other. Programs continue to run when their window is currently not visible and even when the whole screen session is detached from the users terminal.

아마도 대부분의 기술자들은 여러 이유에서 다양한 형태의 원격작업을 하게 될 것이다. 자신의 사무실에서 사내 서버실의 장비에 접속하기도 하고, IDC에 위치한 서버에 접속하여 작업을 해야하는 경우도 있다. 그런데, 가끔 원격 작업이 힘들 때가 있다. 가령,

• 여러 프로그램을 동시에 실행하기 위하여 여러개의 접속(telnet이나 ssh 등)을 만들어야 한다.
• 작업이 오래 걸리는 프로그램의 실행을 유지하기 위하여 접속을 끊을 수 없다.
• 대화형 작업이기 때문에 스크립트로 처리할 수 없다.

뭐, 이유는 많겠지만 지금 말하려는 것은 위의 세 가지로 충분할 것 같다. 바로 위와 같은 상황에서 screen이 힘을 발휘한다. 즉,

• 여러개의 접속 대신 단일 접속 안에서 여러 가상 터미널을 만들 수 있다.
• 가상 터미널을 살짝 떼어 놓았다가 다시 새 연결(새 물리적 터미널)에 붙일 수 있다.

가령, 회사에서 IDC 에 연결하여 작업하던 중, 외근 일정에 의하여 다른 장소로 노트북을 끄고 이동해야 한다. 그럼 작업을 멈추고 쉘을 닫고 접속을 끊어야 하나? screen을 사용한다면 작업을 유지하고 터미널과 쉘을 분리하여 두고 접속만 끊으면 된다. 그리고 외근 후에 다시 연결하여 분리해둔 터미널에 다시 연결하면 만사 OK.