기업의 승패를 좌지우지할 수 있을 정도로 커진 오픈소스, 하지만 그 이면에는 고려해야 할 사항들이 많은데..

IT 시장에서 서비스를 만들거나 솔루션을 만들 때 보면 처음부터 끝까지 새로 다 만드는 경우가 있고 만약 기존에 만들었던 솔루션이나 서비스가 있다면 그 솔루션이나 서비스를 커스터마이징이나 업그레이드해서 새 서비스나 솔루션으로 만드는 경우가 있다. 또 아무것도 없는 상황에서 서비스나 솔루션을 만들려고 할 때에는 앞서 얘기했던 것처럼 아예 새로 모든 것을 다 만들거나 아니면 오픈소스 프로젝트의 솔루션들을 가져와서 커스터마이징 하는 경우가 있다. 요즘은 새로 만들기 보다는 기존에 있던 솔루션을 기반으로 커스터마이징, 혹은 업그레이드를 하던지 아니면 오픈소스를 이용하는 경우가 많은 듯 싶다. 내 경우에도 회사에서 서비스를 만들 때 오픈소스부터 먼저 뒤져보고 그것을 모티브로 만들거나 오픈소스를 가져다가 커스터마이징해서 서비스로 만들곤 한다.

생각보다 오픈소스를 활용해서 서비스로 만드는 기업들이 많이 생기고 있다. 이전같아서는 오픈소스의 경우 이미 공개되어있는 소스이기 때문에 보안에 대한 헛점이 있을 것이라고, 소스가 공개되어 있기 때문에 타사에서 얼마든지 비슷한 서비스를 만들 수 있을 것이라고 해서 잘 채택을 하지 않았는데 요 몇년간 분위기가 바뀌어서 오픈소스를 적극적으로 이용하는 분위기로 바뀌었다. 아마도 만들고자 하는 서비스의 개발 시간 단축이 주 목적이었을 것이다. 처음부터 만든다면 기획, 설계, 개발의 모든 과정에 들어가는 기간, 비용, 인력 등의 자원 관리가 어려워지는데 오픈소스를 이용한다면 적어도 필요한 파트에 대해서는 그 기간 및 비용을 줄일 수 있다고 생각하기 떄문이다. 그리고 서비스의 경우 코어는 오픈소스를 이용하더라도 실제로 돈을 벌어다주는 것은 그 오픈소스를 이용해서 만든 서비스 안의 컨텐츠들이기 때문에 크게 문제는 안된다고 보는 시각도 있다. 간단히 말하면 오픈소스를 이용해서 만든 솔루션 자체를 판매하는 경우라면 오픈소스 라이센스로 인해 문제가 될 가능성도 있지만 예를 들어 쇼핑몰의 경우 워드프레스를 이용해서, 혹은 제로보드 XE나 그누보드를 이용해서 만들었을 떄 쇼핑몰 자체가 돈을 벌어다주는 것이 아닌 그 안에서 파는 상품이 돈을 벌겠끔 하기 때문에 만든 서비스의 소스 중 오픈소스에 관련된 부분이 오픈된다고 하더라도 문제가 되지 않는다고 생각할 수 있다. 이런 마인드로 기업들도 바뀌어가고 있기 때문에 오픈소스를 적극 서비스나 솔루션에 도입해서 만드는 경우가 많아졌다.

그 덕분인지 최근 오픈소스 프로젝트의 규모도 엄청 커졌다. 아파치 그룹에서 관리하는 오픈소스 프로젝트 중 대박치는 오픈소스 프로젝트들이 많아지고 있다. 그리고 성능 좋은 오픈소스를 고르는 능력과 그것을 파악해서 커스터마이징하는 능력이 기업의 서비스, 솔루션 생산성에 막강한 영향을 미치는 시기가 되었다고 본다. 하둡이나 몽고 DB와 같은 빅데이터 시스템의 요소들이 오픈소스로 되어있기 때문에 가져다가 원하는 스타일로 커스터마이징해서 사용하고 있으며 쇼핑몰의 경우 워드프레스에 우커머스와 같은 플러그인을 붙여서 사용하거나 제로보드 XE, 그누보드와 같은 게시판 오픈소스에 쇼핑몰 플러그인을 사용해서 만드는 경우도 많아졌다. 과거에는 그냥 개발자들의 자기 만족을 위한 프로젝트로 여겨져왔던 오픈소스가 이제는 기업의 핵심 서비스 코어로 자리잡고 있는 셈이다. 리눅스로부터 확장된 오픈소스의 영향력은 이제는 기업의 승패를 좌우할 수 있을 정도로 커졌다고 보여진다.

하지만 오픈소스가 마냥 다 좋다고는 할 수는 없을 듯 싶다. 해외도 그런지 모르겠지만 국내의 경우 오픈소스 프로젝트를 가져다가 고객의 입맛에 맞게 커스터마이징해서 사용하는데 해당 오픈소스의 코어 소스까지 건드려서 커스터마이징을 하는 경우가 많다. 오픈소스의 장점은 그 프로젝트에 참여하는 개발자, 혹은 기업들로 인해 지속적으로 업그레이드가 된다는 점이다. 성능적으로, 또 보안적으로 업그레이드가 진행된다. 버그 패치도 자주 일어나기도 한다. 그런데 해당 오픈소스를 가져다가 코어 부분까지 건드려서 커스터마이징해서 제품을 만들었을 경우 기반이 되는 해당 오픈소스가 업그레이드가 되었을 떄 그 업그레이드 된 것을 그대로 사용할 수 있는 것이 아닌 커스터마이징 한 부분을 다시 다 걷어내고 반영을 한 후 그 기능에 맞춰서 또 커스터마이징을 하던지, 아니면 업그레이드를 포기하는 수 밖에 없다. 오픈소스 프로젝트를 활용하여 제품을 만드는 기업들이 많이 겪는 문제가 바로 이런 기반이 되는 오픈소스의 업그레이드 후 처리가 어렵다는 점이다. 특히나 보안적으로 취약점이 생겨서 패치를 해야 하는 경우 코어까지 건드려서 커스터마이징을 한 제품들은 제대로 보안 패치를 적용하기가 어렵고 그것은 그 제품의 단점으로 지적될 수 있다. 치명적인 문제를 일으킬 수도 있다는 얘기다.

이런 의미에서 오픈소스를 다루는 기업의 제품 개발자들, 혹은 기획, 설계자들이 고민을 해야 할 부분이 생긴다. 제품을 만들기 위해서 오픈소스를 가져다가 쓰는 것은 좋은데 코어가 되는 오픈소스는 그대로 두고 외관, 즉 UI 부분을 더 만들어서, 이른바 껍데기만 씌워서 제품을 만들 것인지, 아니면 코어부분까지 다 뜯어고쳐서 원하는 모양의 제품을 만들 것인지에 대해서 고민을 해야 한다. 전자의 경우 오픈소스 자체에서 제공하는 UI, UX가 많이 불편할 수 있기 때문에 좀 더 편한 UI, UX를 제공하는 서비스로 만들 수 있고(물론 성능은 오픈소스의 성능 그대로를 제공하겠지만), 후자의 경우에는 UI, UX  뿐만이 아니라 어쩌면 성능 부분도 개선할 수 있을 것이다. 하지만 앞서 얘기한 것처럼 각종 버그 및 보안 패치, 업그레이드 등이 일어났을 때 적용의 용이성은 전자가 훨씬 좋을 것이며 후자의 경우 상황에 따라서 패치를 못하고 개발자가 따로 만들어서 보안이나 버그 패치를 해야 하는 상황도 생길 수 있다. 이 부분을 잘 생각하면서 오픈소스를 도입하고 적용해야 하지 않을까 싶다.

오픈소스가 갖고 있는 2가지 측면을 잘 생각하고 고민해야 한다는 얘기다. 무작정 가져다쓰고 도입만 한다고 해서 다 해결된다고 생각하면 안된다. 그리고 해당 오픈소스가 적용되는 라이선스 역시 생각을 해야 한다. 아파치 라이선스냐 GPL 라이선스냐, 혹은 다른 오픈소스 계열 라이선스냐에 따라서 상용화 시 문제가 될 수 있기 떄문이다. 오픈소스라고 해서 무작정 다 공짜는 아니라는 얘기며 권리에 대해서는 그 의무와 책임도 따른다는 점을 생각해야 한다. 그리고 해당 오픈소스에 대해서 상용기업이 그 소유권을 가져갔을 때에는 또 문제가 될 수 있다. 최근 계속 소송이 이어지고 있는 자바, 그리고 오라클의 소송이 그런 맥락에서 이해할 수 있는 부분이다. 오픈소스가 훌륭하고 좋은 소스이기는 하지만 마냥 좋다고 덮어높고 가져다가 그냥 쓰면 뒤통수 맞을 수 있다는 점을 생각해야 한다.

위의 글은 CIO 메일링에 나온 '오픈소스의 두 얼굴··· 탁월한 가치, 만만치 않은 맹점'라는 글을 보고 생각이 나서 그냥 두서없이 적어본 것이다.