[지디넷코리아]오픈소스 영역은 공동체의 영향력이 얼마나 막대한지 잘 보여주고 있다. 그러나 이제는 다른 커뮤니티에 문호를 개방해야 할 때가 다가왔다.

오픈소스 사용성(Usability) 전문가 그룹이 과연 존재하나? 만약 데이터베이스나 글루 로직(glue logic), 그리고 운영체제 전문가를 구해야 한다면, 그러니까 전문 지식이 없는 사람들이 소프트웨어를 어떻게 설계해야 하는지 아는 이들을 구해야 한다면 어디서 찾아야 하나?

오픈소스의 세계에는 유용성과 소프트웨어 공학에 대해 서로의 생각을 교류하려는 움직임이 분명 존재한다. 그러나 순전히 모양만 다른 인터페이스를 새로 만드는 것과 같은 일에 자부심을 갖는 수준인 해커 정신이 아직도 오픈소스 전반을 지배하고 있는 형국이다.

오픈소스 진영은 아직도 더 나은 사상가를 끌어들여야 하며, 이젠 개성도 없는 모방품 제조와 같은 일들은 그만두고 심사숙고해서 경험과 지식을 어떻게 이용할 수 있을지 서로 교류할 수 있는 채널을 만들어야 한다.

오픈오피스의 스프레드시트인 칼크(Calc)를 보자. 칼크는 25년 넘게 우리 주변에 있어온 생각을 충분히 훌륭하게 구현해낸 작품이다. 사실 그 때 이래로 스프레드시트의 데이터 구조에 대해서는 전혀 진보가 없었다.

스프레드시트는 지금 잘못돼 가고 있다. 왜냐하면 사람들은 데이터를 함수에 연결된 집합으로 여기는 반면 스프레드시트는 데이터를 맵 레퍼런스로 연결된 집합으로 보기 때문이다. 해당 레퍼런스와 함수가 서로 동기화되지 않으면-즉 범위 레퍼런스를 갱신하지 않고 범위를 넓히면-짜증나고 디버그도 어려운 오류가 잔뜩 나타난다.

스프레드시트의 구조에 대해 좀더 연구를 한다면 분명 더 좋은 기능을 추가할 수 있을 것이다. ‘사용성’을 연구하는 이들은 앉아서 그런 일만 한다는 것도 사실이다. 그러나 오픈소스 개발자와 사용성 전문가들이 서로 대화는 하고 있는가? 이들은 공동체 지향적인 개발 환경에서 장점으로 인식되는 것들을 매우 당연한 부분으로 만들어줄 것이 분명한데 말이다.

MS가 오픈소스보다 잘하는 점, 분명 존재한다
오픈소스 공동체는 수십억달러 규모의 R&D 연구소가 없어도 더 나은 제품을 설계할 수 있는, 잠재력이 풍부한 곳이다. 또한 현 작업 환경을 개선할 수 있는 역량도 보유하고 있다. 그러나 MS가 시의적절하게 시작한 두 가지 메커니즘, 즉 월등히 크고 월등히 쉬운 사용성이 분명 주목을 끌 것이다. 둘 모두 MS가 제공하고 있는 환경 내에서 자체적으로 조정·개선하는 방법을 이용함으로써 실제로 시스템을 개선내고 있기 때문에 오픈소스의 큰 장점들이 무력화될 위기에 처해있는 것이다.

가장 단적인 예로 들 수 있는 것은 자동 업데이트다. 최근 발생한 파이어폭스 보안 위협은 48시간도 안돼서 해결돼 버전 업그레이드가 이뤄졌다. 반면 MS 사용자들은 한달마다 업데이트가 나오는 그날이 되기까지 무작정 기다린다. 오픈소스는 중요 지원에 대해 빠르고 정확하게 대응할 수 있고, 대응해오고 있다.

하지만 두 달이라는 시간동안 얼마나 많은 파이어폭스 사용자가 새 버전으로 업그레이드할까? 나나 독자들은 업그레이드하겠지만 내가 파이어폭스를 설치해줬던 10명은 하지 않을 것이다.

여기에서 MS의 자동 업데이트가 시사하는 바가 크다. 오픈소스의 대응 속도가 빠르다고 개개 사용자들까지 도달할 수 있다는 건 아니라는 점이다. 그리고 이것이 더욱 중요한 점이다.

이것 말고도 MS는 또다른 실용적인 것에 집중함으로써 앞서가는 면모를 보이고 있다. 바로 버그 리포트다. 윈도우 애플리케이션이 잘못돼 MS의 버그 수정·제안 데이터베이스에 연결되는 동안 비정상적으로 종료된 당시 애플리케이션의 ‘잔해물’을 끌어올려 꾸러미로 만듦으로써 과학적으로 분석할 수 있도록 하는 자동화 과정이 제공되고 있다.

이 과정은 세 부류의 사람들 모두에게 도움이 된다. 사용자는 적합한 도움을 자동으로 받게 되며 MS는 문제 해결의 실마리가 끊임없이 갱신되는 효과를 볼 수 있다. 또한 애플리케이션 개발자와 드라이버 작성자는 각 버그에 대해 빠른 피드백을 얻을 수 있을 뿐 아니라 어떤 걸 수정해야 하는지 알 수 있는 채널을 확보하게 된다. 확실한 장점이라 할 수 있다.

오픈소스에서도 버그 리포트를 자동화하려는 노력이 있지만 특정 배포판에 국한돼 왔다. 오픈소스 공동체가 이런 면에서 장점을 최대한 끌어내려면 문제 탐지, 문제점·시스템 상태 취합·요약, 공개 데이터베이스 제출 등 일련의 과정에서 공통적인 방법을 결정해야 한다. 이렇게 된다면 동일 메커니즘을 이용해 제안과 같은 좀더 기능적인 내용을 쉽게 추가할 수 있게 된다.

버그라는 게 단지 잘못 코딩된 것만을 의미하는 건 아니다. 업데이트와 버그 리포트에서 보듯, 개선 제안을 할 수 있는 메커니즘이 없는 게 문제라기보다는 평범한 사용자들 입장에서 볼 때 표준도 없고 어려우며, 물론 가끔은 환영받지 못한다는 점이 더 큰 버그라 할 수 있다.

오픈소스는 독점적 소프트웨어에 비해 위대한 장점이 있다. 지금까지 언급한 생각이 모두 다 잘 이뤄져 폭넓게 적용된다면 개발자가 최소한의 노력만으로, 혹은 어떤 종류든 추가로 노력을 기울이지 않아도 새로 나올 모든 소프트웨어에 이용될 수 있는 이상적인 공통 시스템을 끌어낼 수 있다는 것이다. 바로 오픈소스가 그 일을 할 수 있을 것이다.

서로 좋은 생각을 공유하는 것이 법적, 그리고 실질적으로 막혀있다는 점에서 독점적 시스템은 엄청난 단점을 지니고 있다. MS는 운영체제 기능에 대한 예외 리포팅을 통해 이를 해결해나가고 있지만 별로 중요하지 않은 문제에 이 메커니즘이 확장될 리는 없다. 오픈소스는 이런 점들을 훨씬 더 쉽게 다룰 수 있다.

오픈소스는 서로 적대적이며 자금 공급이 원활하게 이뤄지는, 합법적이며 냉혹한 생존 경쟁의 장에서 번영을 누리기 위해 소프트웨어 개발자들의 재능과 혁신적인 사상가, 최신 전문 기술 등을 빠르게 받아들여왔다. 그러나 오픈소스는 지금까지 배운 걸 교훈삼아 필수적으로 코드를 짤 수 있어야 하는 것이 아니라, 오픈소스가 알아야 하는 점들을 이미 숙지하고 있는 전문가들이 모인 공동체로 거듭나기 위해 동기와 수단을 찾아야 한다.

그런 전문가 집단 중 가장 큰 것이 바로 사용자 기반 공동체다. 오픈소스 공동체가 이런 사실을 이용할 때다. @