오픈소스, 얼마 전부터 참 많이 듣는 소리이다. 어느 순간인가 오픈소스라는 이야기가 여기저기서 나오고 또 몇몇 프로젝트들이 오픈소스 프로젝트로 진행이 되기 시작하면서 오픈소스에 많은 관심이 쏟아지고 있는 것 같다. 매스컴에도 오픈소스라는 말이 나오는 것을 보면 예전에 비해 오픈소스 진영에 많은 변화를 가져온 것 같다.

관심이 높아지면서, 많은 사람들이 이 오픈소스 프로젝트라는 것에 많은 기대를 하고 있는 것처럼 보인다. 사실 그렇지 않겠는가. 내가 쓰는 프로그램의 소스가 공개되고 그걸 내 마음대로 바꿀 수 있다는데, 컴퓨터를 조금이라도 한다는 사람, 혹은 프로그래밍을 조금이라도 한다는 사람이라면 관심을 가진다는 것이 당연할 것이다.

점차 오픈소스에 대한 관심이 높아지면, 그 관심의 방향이 가끔은 이상한 쪽으로 흐르는 듯 보인다. 오픈소스가 절대적인가? 아니면 오픈소스가 모든 것을 다 해결해줘야 하는가?

오픈소스라는 것은 말 그대로 오픈소스이다. 즉, 누구에게나 참여가 열려있고, 누구나 그 프로젝트 혹은 프로그램에 기여를 할 수 있다는 말이다. 오픈소스 프로젝트에 참여하거나 기여하는 방법에는 여러가지가 있을 것이다. 버그 리포팅이나 제안, 혹은 프로그램 패치를 제공하거나 아니면, 프로그램 코드 수정에 직접적으로 참여하는 방법들이 있을 수 있다.

오픈소스 프로젝트 참여자들 혹은 매니저들도 사람이다. 이 사람들도 자신의 일이 있고, 짜투리 시간을 내서 오픈소스 프로젝트에 참여하고 있는 것이다. 또한 전문적인 프로그래머도 있으며 아닌 경우도 있다. 이 사람들이 모든 것을 해결할 수는 없는 것이다.

내가 원하는 것이 있다면 그것을 프로젝트 매니저나 개발자들에게 전달할 수는 있다. 하지만, 그것이 항상 받아들여질 것이라는 생각은 하지 말자. 내가 생각하는 일의 우선 순위와 매니저나 개발자가 생각하는 일의 우선 순위는 다를 수 밖에 없다. 우리는 가끔 그걸을 잊는 것 같다. 그리고, 그것이 불만을 낳고 프로젝트에 대한 불신을 낳고, 또 오픈소스 전체에 대한 오해와 선입관을 갖도록 한다.

오픈소스 프로젝트라고 해서 이런 저런 제안을 했는데, 이 제안이 받아들여지지 않고 혹은 이 제안에 대한 답변도 없다고 해서 그것이 매니저나 개발자의 잘못이라고만은 할 수 없다. 위에서도 말했지만, 매니저나 개발자나 시간의 한계가 있고 또 나름대로의 일의 우선 순위가 있는 것이다. 우리는 그것을 이해해줘야만 한다.

한 가지 예를 들어보자. 우리가 많이 사용하고 있는 운영체제인 Microsoft Windows 라는 프로그램이 있다. 이 프로그램을 쓰다가 어떤 문제점이나 기능의 개선을 생각해내서 내가 이 제안을 Microsoft에 제출했다. 과연 내 제안 제출이 Microsoft에 의해 받아들여질까? 혹은 내 제안에 대한 답변을 받을 수 있다고 장담할 수 있을까? 어쩌면 답변을 받을 수 있을 지는 모르겠다. 이들은 고객을 상대로 하는 회사이고 그들에게는 그럴 의무가 있으니 말이다. 하지만, 내 제안이 받아들여진다는 보장은 하지 못한다. 우리는 그 문제를 해결하는데 얼마만큼의 시간이 소요될지 혹은 그 제안이 어느 정도의 우선 순위를 가질 지 알 수 없기 때문이다.

만약 Microsoft Windows 라는 프로그램이 오픈소스로 개발되고 있다고 가정해보자. 그렇다면 우리의 제안이 받아들여질까? 그 제안에 대한 답변을 항상 들을 수 있을까? 물론 이것도 장담 못한다. 제안에 대한 답변을 해줄 담당자가 정해져있다면 우리가 답변을 받을 확률은 올라갈 수 있겠지만, 그렇다고 해서 그 제안이 수용되고 내 제안이 프로그램에 적용될 것이라는 장담할 수는 없다.

물론 이런 제안도 오픈소스 프로젝트에 참여할 수 있는 한 가지 방법은 될 수 있다. 어디까지나 참여이다. 이 참여에 대한 보상은 누구도 책임져주지 않는다. 그럼 내 제안에 대한 보상은 누구의 책임인가? 그건 본인에게 달려있다.

예를 들어보자면, "이런 버그가 있습니다"라고 리포팅하는 것은 그 버그가 치명적이지 않다면 개발 순위에서 뒤로 밀려날 수 밖에 없다. 이 보고를 받은 개발자는 그 버그의 원인이 무엇이고 어디에서 발생하는 것이며, 프로그램 코드의 어느 부분을 어떻게 수정해야 하는지 직접 찾아내야만 한다. 하지만, 일의 우선 순위에서 밀려나 있는 경우에는 이 버그 보고가 언제 해결될지는 아무도 모른다. 우선 순위가 더 높은 일들이 계속 늘어난다면 이 보고는 상당히 오랜 시간을 기다려야 해결될 것이다. 물론 그 보고를 받은 개발자는 이에 대해 적절한 답변을 해주는 것이 좋을 것이다. 하지만, 그걸 개발자에게 강요할 수는 없다고 생각한다. 어찌 보면 자원봉사자인 오픈소스의 개발자에게 그런 의무까지 지울 수 있을까?

보고나 제안을 하는 사람의 입장에서 보면 내가 보고한 혹은 제안한 것이 아직도 적용되지 않았고, 또 그에 대한 답변도 없다고 생각할 수 밖에 없다. 그러나 개발자나 매니저의 입장에서는 이런 보고나 제안이 수시로 들어온다. 그리고, 한꺼번에 여러 가지의 일을 처리할 수는 없기 때문에 개발자의 주관에 따라 일의 우선 순위를 결정해 처리할 수 밖에 없다.

그렇다면 보고 혹은 제안한 사람은 무시된 것인가? 그건 아니라고 생각한다. 분명 언제인가는 그 내용이 처리될 것이고, 프로젝트 전체로 본다면 그 제안이 받아들여지든 아니든, 분명 그 제안은 프로젝트에 기여한 것이다. 제안을 하고 그 결과를 당장 봐야 한다고 생각하는가? 그렇다면 적극적으로 프로젝트에 참여하는 것이 좋을 것이다.

단순히 증상을 설명하는 말보다는 해당 부분의 패치를 제출하는 편이 개발자들에게는 더 큰 도움이 된다. 또는 프로젝트 개발자로 정식으로 인정받아 자신이 제안한 부분을 직접 프로그램 코드에 수정을 하는 것도 좋을 것이다. 바로 이것이 오픈소스 프로젝트이다. 참여의 문을 굳건히 닫고 있는 상용 프로그램들에서는 절대 찾을 수 있는, 누구나 어떤 방법으로든 참여할 수 있다는 것! 이것이 오픈소스 프로젝트의 장점이다.

난 프로그래밍을 못하므로 이런 참여는 할 수 없다? 이건 핑계일 뿐이다. 본인이 그렇게 생각한다면 자신의 제안이 받아들여지지 않는 것에 대한 불만은 갖지 말아야 한다. 그런 직접적인 기여를 할 수 없으면 오픈소스 프로젝트에 참여할 수 없다고? 물론 위에서도 말했지만, 그건 아니다. 아이디어 제안이나 버그 리포팅도 오픈소스 프로젝트에 참여하는 아주 좋은 수단이기는 하지만, 그에 대한 보상을 기대하지는 말자는 것이다. 그냥 마음 편하게 난 이런 저런 제안을 해서 그 오픈소스 프로젝트에 기여를 했어! 라고 생각하는 편이 좋지 않겠는가? 꼭 그게 받아들여지고 지금 당장 적용되는 것을 보고 싶다면 적극적으로 참여하는 것이 좋다는 말이다.

또 그런 보고나 제안을 할 때는 상세하게 해줘야 한다. 두리뭉실하게 이야기해서는 그걸 선뜻 이해하기도 힘들 뿐더러 그 말의 본의를 파악하기 위해 개발자는 다시 한번 더 생각해야 한다. 누구나 그러지 않을까? 이해하기 힘든 글은 읽고 무시할 수 밖에 없다. 시간과 정력에 여유가 있는 상황이라면 차근차근 살펴보겠지만, 그럴 정신적 여력이나 시간이 없다면 무시할 수 밖에 없다. 개발자도 사람이므로.


앞으로도 보다 많은 프로그램들이 오픈소스로 개발되기를 희망한다. 그래서 내가 기여할 수 있는 프로젝트도 많이 늘어나고, 그로 인해 좀더 좋은 프로그램으로 우리 앞에 나타나기를 바란다. 오픈소스 프로젝트라는 것은 번개불에 콩 볶아 먹듯 하루 아침에 이루어지는 것이 아니다. 아랫목에서 천천히 숙성되어지는 청국장과 같은 기다림이 필요하다.