이번 글에서는 레이먼드가 오픈소스 소프트웨어를 개발하거나 사용해야 한다고 주장한 ‘5가지 경우’에 대해 하나하나 반론을 편다. 먼저, 레이몬드가 주장한 다섯가지 가운데 처음 2가지는 서로 밀접하게 연관돼 있으므로 한꺼번에 다룬다.
a) 신뢰성/안정성/확장성이 필수적인 분야b) 설계의 정확도와 구현이 독립적인 등위 검토에 의한 방법 이외에는 쉽게 검증될 수 없는 분야(역자 주 : kldp의 ‘마법의 솥’ 번역 인용, 아래 계속 언급되는 레이먼드의 주장도 모두 kldp 번역을 인용합니다)
a)는 오픈소스가 제품의 신뢰성이나 안정성 그리고 확장성을 실현하는데 더 용이하다는 가정을 하고 있다. 이는 공개적으로 이루어지는 오픈소스 개발 과정의 특성상 수천명의 개발자들이 코드를 점검한다는 사실을 근거로 하고 있는데, 만약 소프트웨어에 문제가 있다면 독점 소프트웨어에 비해 더 쉽게 발견하고 수정해 완벽한 코드를 기대할 수 있다는 것이다.확장성은 시스템 확장과 관련된 좋은 아이디어를 적절히 설계하고 적용하는 것이 중요하다. 일부 이견도 있겠지만 이와 같은 훌륭한 설계 능력을 갖춘 개발자가 오픈소스 진영에만 있는 것은 아니다. 훌륭한 프로그램을 개발하기 위해서는 프로그램의 성패가 개발자의 경제적 이해와 직접 관련되지 않아야만 하는 것일까? 필자 개인의 경험담을 이야기하자면 오히려 독점 소프트웨어 기업들의 애플리케이션이 확장성이 더 좋은 경우가 있었다. 예를 들어 상용 유닉스는 최근까지도 최고의 확장성으로 유명하며, 대형 유닉스 업체들은 기업용 컴퓨팅 환경에서 리눅스 소프트웨어보다 확장성이 더 뛰어나다고 주장한다.물론 특정 기업이나 개인보다는 개발자 커뮤니티가 확장성과 신뢰성과 관련된 코드 에러를 더 확실하게 찾아낼 수 있다. 그러나 이것은 대형 프로젝트에 적용되는 이야기다. 소규모 프로젝트에는 참여하는 개발자가 적어 코드 에러를 찾아내는 것이 쉽지 않다. 소스포지(sourceforge.com) 데이터베이스에 고아처럼 공중에 뜬 오픈소스 프로그램이 넘쳐나는 것도 이 때문이다. 즉 소규모 프로젝트의 경우 오픈소스라는 점이 곧 프로그램의 신뢰성이나 확장성을 보증하는 것이 아니라는 것이다.게다가 지금까지의 개발 사례로 보면 독점 소프트웨어가 오픈소스 프로그램보다 일반 사용자들이 중요하게 여기는 기능을 더 충실히 제공해 왔다. 지난 컬럼에서 언급한 것처럼, 독점 소프트웨어 개발업체는 새로운 기능을 포함시키기 위해 소비자들과 밀착하고, 개발자가 이를 구현하도록 재정적인 지원을 할 수 있는 여력이 있기 때문이다.그렇다면 기업들이 중요시하는 보안 측면은 어떤가? 필자는 오픈소스가 독점 소프트웨어에 비해 뛰어난 점이 없다고 주장하는 것이 아니다. 오픈소스에도 분명 이점은 있으나 어떤 문제를 가능한 빠르게 해결하고자 할 때는 재정적 지원이 가능한 기업이 더 앞서갈 수 밖에 없다. MS가 대표적인 사례로, MS는 자사 소프트웨어에 어떤 문제가 생겼을 때 그 해결 방안을 내놓는 시간을 최소한으로 줄여왔다. ‘신뢰할 수 있는 컴퓨팅 정책’ 역시 이윤을 추구하는 소프트웨어 개발업체가 이를 기반으로 더 안정적인 운영체제를 개발하고자 하는 전례없는 시도라고 평가된다.필자는 오픈소스가 독점 소프트웨어에 비해 기본적으로 더 안정적인가를 둘러싼 논쟁이 아직 끝나지 않았다고 생각한다. 오픈소스에는 나름대로의 장점이 있고, 또 MS와 같은 대기업들도 소스 공개 확대를 통해 얻을 수 있는 이점이 있을 것이다. 독점 소프트웨어는 인터넷 때문에 보안 강화의 필요성을 느끼는 고객들의 요구를 반영해 더 안전한 독점 운영체제를 개발할 것이다.c) 사업을 제어하는데 있어서 소프트웨어가 결정적인 역할을 하는 분야
레이몬드는 이 문제에 관하여 다음과 같이 언급하고 있다.독점 공급 업체에 종속되는 것을 피하고자 하는 소비자의 합리적인 욕구는 오픈 소스에 대한 관심을 보다 증가시킬 것이다.
특정기업이 개발한 소프트웨어에 독점적으로 종속되는 것을 우려해 오픈소스를 선호하게 될 것이라는 것이다. 그러나 이미 언급한 것처럼 오픈소스로 전환한다고 해서 선택의 폭이 더 넓어지는 것은 아니다. 세부적으로 보면 웹서버는 아파치, DB는 MySQL 등 거의 대부분의 영역에서 특정 프로그램이 지배적인 위치를 점하고 있다. 이것은 자연스런 현상으로, 호환성의 문제가 발생할 수 밖에 없는 시장내에서 일정한 표준을 마련하는 과정이다.오픈소스를 이용한다고 해서 프로그램간의 전환이 더 용이한 것도 아니다. 리눅스를 단순하게 표준화한다고 해서 매킨토시로 쉽게 마이그레이션 할 수 있겠는가? 일단 한 가지 운영체제를 선택하는 순간, 사용자들은 애플리케이션을 구입하거나 이를 관리하는 직원을 채용할 때 이미 특정 시스템의 테두리 안으로 제한을 받게 된다.이것은 리눅스 안으로 범위를 좁혀도 마찬가지다. 레드햇에서 데비안으로의 전환 역시 쉽지 않으며, 시간이 지나 각 버전에 새로운 기능이 추가될수록 다른 리눅스 버전으로 전환하는 것은 점점 더 어려워질 것이다. 데비안이 레드햇의 일부 추가기능을 이용하고 복제할 수는 있겠지만, 레드햇의 모든 기능을 다 지원할 수는 없을 것이다.레이몬드는 레드햇의 비즈니스 모델이 상용 가능하며 같은 브랜드에서는 상호 호환이 용이한 운영체제를 만들고 테스트하는 것이라고 주장한다. 그러나 리눅스 배포판이 항상 호환가능한 것은 아니며 MS나 애플처럼 정확히 동일한 버전을 배포하는 것은, 사용자들의 기본적인 욕구를 서로 다른 방식으로 충족시키는 것만큼이나 불가능한 일이다. 업무 소프트웨어에 핵심적으로 요구되는 품질과 업무 적합성 또한 이미 신뢰성, 안정성, 확장성과 관련해 언급한 것처럼 독점 소프트웨어가 오픈소스에 크게 뒤지지 않는다.또한 레이몬드는 오픈소스의 장점 중 하나로, 오픈소스는 독점 소프트웨어처럼 출시일을 앞당기기 위해 데드라인에 쫓기지 않는다고 말한다. 그러나 사용자가 원하는 대로 제때에 프로그램을 수정할 수 없다는 점은 오히려 오픈소스의 단점이다.특히 오픈소스 소프트웨어를 이용하는 기업들은 이 때문에 직접 코드를 유지하고, 직접 혹은 다른 개발자에게 용역을 주어서 필요한 방향으로 코드를 발전시킨다. 이 경우 독점 소프트웨어처럼 개발 시한이 필요하게 된다. 모든 기업들이 독자적으로 개발할 수 있는 재정적 여력을 가지고 있는 것은 아니다. 그러나 독점 소프트웨어 업체는 본질적으로 사용자들이 이들에게 개발업무를 아웃소싱하고 있는 것과 다를 바 없다.독점 소프트웨어 업체들의 일부 부족한 면에도 불구하고, 이들은 그 부족한 면이 무엇인지를 찾아내려는 정책을 갖고 있다. 필자는 사람들이 윈도우의 핵심코드를 변경할 필요가 있다고 말하는 경우를 거의 보지 못했다. 오픈소스 커뮤니티가 제기하는 가장 흔한 불만은 윈도우에 너무 많은 기능이 통합돼 있다는 점이다.소스코드가 공개되면 기업들은 기능 확장을 위해 재정적으로 뒷받침할 수 있는 유연성이 그만큼 커진다. 그러나 이러한 유연성에는 대가가 있으며, 그 대가로 개발된 코드들은 점점 호환이 어려운 방향으로 나아간다. 이러한 일이 절대 발생하지 않는다고 믿지는 말자. 필자는 고객이 오픈소스 프로그램을 독자적으로 개발해 더 이상 핵심코드와 연관된 업데이트를 적용할 수 없는 경우를 본 적이 있다. 이것은 초기 오픈소스 프로그램의 확장성의 문제로, 원하는 기능을 추가하기 위해 불가피하게 프로그램을 수정했기 때문이다.이런 점에서 보면 독점 소프트웨어는 적절한 기능 연장성을 유지한다는 점에서 의외의 장점이 있다. 독점 소프트웨어 업체들은 사용자들이 본래의 소스코드를 변경할 수 없도록 하기 때문에, 내부적으로 기능 연장성을 고려해 차기 버전을 개발할 의무가 있다. 필자는 MS의 경우 자사가 개발하는 대부분이 애플리케이션에 마치 운영체제처럼 고도의 기능 연장성과 기능 재생성을 고려하고 있음을 확인할 수 있었다. 물론 오픈소스도 이와 비슷한 개발 모델을 따를 수 있지만, 소스를 공개해 누구나 수정할 수 있도록 하는 과정에서 전체적인 호환성은 떨어지기 마련이다.d) 일반적인 컴퓨터의 사용과 통신 하부 구조를 확립하거나 가능하게 한 소프트웨어 분야
d)는 이전에 언급한 것처럼 오픈소스가 언제 어디서나 컴퓨팅이 가능한 유비쿼터스를 구현한다는 명제이다. 오픈소스가 유비쿼터스 환경을 구현한다는 데는 필자도 동의한다. 기술을 널리 보급하는데 있어서 오픈소스는 매우 효율적인 방법이다. 코드는 무료인데다가 기업들은 필요에 따라서 코드를 수정할 수 있다. GPL이 아닌 BSD 스타일 라이선스를 따를 경우 독자적 소프트웨어에서도 자유자재로 사용할 수 있다.그러나 소스코드 공개가 유비쿼터스를 구현하는 유일한 방법은 아니다. 윈도우가 유비쿼터스 환경에 적합하지 않다고 생각하는 사람은 거의 없을 것이다. MS는 하드웨어 판매업체들에게 비교적 저렴한 가격에 윈도우를 제공해 유비쿼터스를 구현한다. 윈도우는 일반 소비자 시장을 대상으로 한 최초의 범용 운영체제로 시작해, 그래픽 운영체제 분야에 먼저 진출했던 기업들을 제치고 큰 성공을 거뒀다.이처럼 새로운 기술이 나왔을 때 인기를 끌기 위해서 무료(혹은 저가) 클라이언트 소프트웨어를 출시하는 것은 매우 흔한 일이다. 애플의 퀵타임과 어도비의 애크로뱃 리더 등도 이런 종류의 소프트웨어들이다. 특징적인 것은 이 중에 어느 것도 오픈소스가 아니라는 점이다. 즉 유비쿼터스를 구현하는 가장 중요한 요인은 오픈소스인지 여부가 아니라는 것이다. 바로 ‘무료’여야 한다는 것이다.e) 핵심적인 방법 (또는 기능상 동일한 것)이 일반적인 공학 지식의 일부분인 분야
이것은 모든 개발자들이 쉽게 이해할 수 있는 기술을 사용해야만 오픈소스 소프트웨어 제품으로 적합하다는 것이다. 필자 역시 이 말에 전적으로 동의한다. 지금까지 주장한 것처럼 오픈소스가 제 역할을 할 수 있는 분야는 다름 아닌 쉽게 이해할 수 있는 기술의 영역이다.그러나 사람들에게 널리 활용되기 위해서는 자금이 충분한 기업들이 뛰어들어 소비자의 요구를 만족시키기기 위해 같은 연구 개발을 동시다발적으로(병렬로) 진행해야 한다. 이때 채택되는 것은 아마도 ‘제대로 된’ 기술일 것이다. 그리고 시간이 지남에 따라 이 솔루션에 이용된 지식은 더 넓은 시장으로 확산될 것이며 결국 오픈소스 제품에도 통합될 것이다.물론 이렇게 되면 최초로 기술혁신을 이룬 장본인은 이 혁신적인 기술에 대한 ‘사용료’를 받지 못할 수도 있다. 그러나 이것이야말로 ‘굿씽(Good Thing)’이다. 소프트웨어란 일반인들이 사용할 수 있도록 넓은 영역으로 퍼져나가는 좋은 아이디어들이 있어야만 개발되는 것이다. 필자가 소프트웨어 특허를 반대하는 것도 바로 이 때문이다. @필자소개존 캐롤은 아일랜드에 살고 있는 소프트웨어 엔지니어로, 자바와 닷넷을 이용한 분산 시스템의 설계와 개발 분야를 전문적으로 하고 있다. 그는 터틀넥 소프트웨어의 설립자이기도 하다.
