(7) 오픈소스와 참여의 이득

오픈소스 프로젝트가 참여자에게 어떤 이득을 주느냐는 질문을 받을 때 마다 할 말이 많지가 않다. 그러한 경우 사람들은 자신이 어떻게 그 마약에 빠졌는지 경험을 이야기 하는 경우가 보통인 듯 하다. 사실 겪어보기 전에는 알 수가 없는 ,특별한 답이 없는 문제이다. 세상엔 그러한 문제들이 너무나도 많다. 결국 이야기를 해 보려고 하면 나의 경험에서 나오는 이야기가 되고, 또 그 이야기는 지극히 사변적이 될 것이다. 그래도 한 번 간단하게 수많은 사람들의 이야기 더미에 한 줄을 더 얹어본다. 세상에는 혼자 누리기에는 너무 아까운 것들도 많다.

텍스트큐브를 많은 사람과 함께 의견을 나누고 개발하면서 어떠한 것을 얻었는가 하는 부분은 개인적인 차이가 클 것이다. 나의 경우 크게 요약해 보자면 하나는 새로운 언어나 코드에 대한 이해이고, 다른 하나는 추상화된 목표를 이루기 위한 협업의 경험이다.

언어나 코드에 대한 이야기부터 해 보자. 어느새 일 년 반이 흘렀지만 처음 태터툴즈 코드를 들여다 보기 시작할 때 PHP라는 언어에 익숙하거나 좋아하지는 않았었다. 웹 프로그래밍이라는 표현도 생소했었다. 웹에서 프로그램을 돌리기 위해서는 C로 CGI를 짜서 돌리는 방식이 익숙했었다. 시대에서 한발짝 비켜나 있었다. (참여하는 연구 분야에서는 아직 포트란이나 C가 대세이다)

언제나 시작은 사소하다. PHP는 잘 모르지만 물어물어 태터툴즈를 사용하고 있었고, 당연히 그렇듯이 내 블로그에서 마음에 들지 않는 부분들이 하나둘씩 보이기 시작했다. 처음부터 태터툴즈라는 도구를 수정하려고 한 것은 아니었다. 그냥, ‘내 블로그’를 더 낫게 만들고 싶었다. ‘내 것’을 더 좋게 만드는 과정이었기 때문에 온갖 고생을 다 해가며 어설프게나마 PHP도 배우고, MySQL도 배우기 시작하였다. ‘웹 코딩의 팔 할은 구글이 키웠다’

거대한 프로젝트의 일원이 되기 위한 마음이 코드를 들여다보고 싶은 동기가 되기도 하고, 자의 또는 타의에 의하여 얻어지는 명예가 그 과정을 증폭하기도 한다. 그렇지만 기업 주도로 만들어지는 프로젝트와 오픈소스의 가장 큰 시작의 차이점은 ‘남이 필요해서’ 와 ‘내가 필요해서’ 인 듯 하다. ‘내가 쓸 프로그램’을 손댄다는 것은 프로젝트의 초반에는 다른 모든 이유를 능가하는 동인이 된다.

그 과정에서 생판 모르던 PHP와 MySQL이라는 DBMS (MySQL 3는 개인적으로는 이게 DBMS면 엑셀도 DBMS라고 하고 싶을 정도로 좌절스러웠다.)에 익숙해지고, 그 창을 통하여 웹 어플리케이션과, 극단적인 이벤트 드리븐 기반의 프로그램의 설계에 대해서도 자연스레 배우게 되었다. 구글링으로는 갑갑해서 책을 사게 되고, 책으로 부족해서 논문들을 찾아 읽게 되었다. 관심이 행동을 낳고, 행동이 지적 호기심을 가지고 오는 순환구조는 오픈소스가 ‘목적’과 ‘예제’의 역할을 동시에 채워주었기 때문에 가능했다. 어느새 TNF라는 커뮤니티가 만들어졌고, 커미터였고, 조금더 높은 목표를 위해서 고민하는 사람들을 많이 만나게 되고, needlworks가 생겼다.

오픈소스를 통해 겪었던 협업의 경험에 대해서 이야기하려면 여러가지가 생각난다. 대학이나 기업에서 프로젝트를 진행하거나 하면 항상 싫어도 만나게 되고 배우게 되는 것이 협업이다. 태터툴즈와 텍스트큐브를 개발하며 겪은 협업의 개념은 굉장히 새로웠다. 일반적인 프로젝트에서 이루어지는 협업들과 구분되는 여러 특징들이 있다.

구성원이 정해지고 규칙이나 역할을 정하는 일반적인 프로젝트와는 다르게, 열려있는 오픈소스 프로젝트의 경우 (그렇지 않은 프로젝트들도 많지만) ‘기여도’가 발언권에 지대한 영향을 끼친다. 기여를 많이 할수록 애착이 생기게 되고, 자연스레 할 말이 많아지기도 한다. 또한 기여를 많이 하거나 ‘원하는 부분을 마음대로 뜯어 고치기 위해서’는 소스의 여러 부분을 많이 파악해야 하고, 아는 부분이 많을 수록 할 수 있는 말도 많아지게 마련이다.

그러다보니 코드에 대한 발언권이 커지는 사람들은 대부분 적어도 그 프로젝트의 코드에 대해서는 수많은 부분을 이해하고 있는 사람이거나 실력이 뛰어난 사람들이다. 이러한 특성 때문에 어떠한 면접 과정이나 심사가 없더라도 개발하는 사람들은 저절로 ‘적합한 사람들’로 끊임 없이 갱신된다. 이러한 개발 프로세스 부분이 회사 주도의 프로젝트와 비교하였을 때 가장 큰 차이점이 아닐까 싶다. 커미터로서 맡게 되는 주 분야는 끊임없이 갱신되고, 그 분야를 결정하고 갱신해 나가는 것은 각자의 관심이며, 관심이 커지면 들여다 보게 되고 실력이 생기고 실력이 생기면 자연스레 그 부분에 대한 발언권이 올라간다.

온라인 기반의 사람들이 모여 코드를 수정하다 보면 포럼을 넘어 메일링 리스트나 메신저로 토론을 한다. 그런데 위에서 이야기한 그 점 때문에, 희한한 이야기이지만 백마디 말 보다. 한 줄의 코드가 때로는 더 큰 의미를 전달한다. 우리들끼리는 ‘코드로 대화한다’고들 하는데, trac의 로그를 보지 않아도 코드가 커미터의 의도를 대신 표현해 주는 경우들이 종종 발생한다. 때로는 코드로 농담을 하고, 가끔은 코드로 싸운다. 그 과정에서 커다란 충돌이 발생하지 않는 것은 연결이 계산적이 아니라 즐거움으로 연결되었기 때문이기도 하고, 프로젝트 매니저가 정리를 하기 때문이기도 하다. (한참 빠져 있다 보니 어느새 정리를 하는 사람이 되어 버렸다...) 너무 코더스러운 이야기이기도 하지만, 인간미가 비집고 들어갈 틈이 없을 것 같은 코드로도 시간이 지나면 이야기를 나누게 된다. 굉장히 특이한 소통의 경험을 하게 된다. 이건 정말 설명이 어렵다.

참여로 얻은 것들은 이 정도로 정리해 보고, 다른 이야기는 다른 글로 따로 정리를 해 보아야 겠다.