오픈소스

오픈소스를 가져다 쓴다는것은 개발기간의 획기적인 단축을 뜻한다.

맨끝단의 실사용자들은 내가 뒤에서 무엇을 가져다쓰는지 알바가 아니다. 그냥 제품만 잘팔리면 되고, 고장만 안나면 된다.

유명한 오픈소스는 세계에서 야심있는 프로그래머들이 한번쯤 커밋을 해보고싶어하고 하고있으며, 심지어는 돈을 주지 않아도 아주 깔끔한 버전관리와 인풋아웃풋을 내준다. 

오픈소스가 품질이 떨어진다는 이야기는 그다지 설득력이 없으며 ERP에서 독점적인 영향력을 지닌 SAP의 프로그램들이 오픈소스로 풀려있다면 오히려 커밋을 찍으려는 개발자들에의해 엄청나게 빠른속도로 개선이 되기 시작할것이다. 

사실 어느정도 코딩을 하다보면 열심히 구현한것들이 벌써 누군가가 코딩을 해서 올려놓았다는 사실을 알게될때가 있다.

그래서 개발자는 사전 오픈소스 탐색에 공을 들여서 찾아보게 된다. 어 있을것같은데? 라는 기분이 조금이라도 드는 구현물은 항상 github에 별풍선 100개정도는 받아 있는 경우가 대부분이다. 빠르게 가져다쓰고 생각보다 빨리 끝난 그럴듯한 결과물은 오히려 처음부터 땀빼면서 만든 결과물보다 좋을수밖에 없다. 벌써 몇십 몇백의 사람들의 삽질이 반영된 결과이므로. 그리고 그 한명한명은 나너우리보다 코딩을 잘할 가능성이 음청 높다. 

예를들어 기존 빨강->핑크로 바꾸는 로직이 더럽게 되어있어서 10시간 걸릴 코드를 이를 대신 깔끔하게 5분만에 래핑해서 쓰게해주는 오픈소스는 더할나위없이 쓰면된다.

다만, 구현물을 받아보는 입장 말고, 실제로 개발하는 사람의 입장에서 한번 생각해보아야 할게 어플리케이션의 핵심기능이 될만한 유명한 오픈소스, Tensorflow, Spark, 등등 기업의 기술과 직결된 기술들은 개발자 입장에서는 가져다 쓰기만 하면 독이될수있다는 것이다. 핵심코어 로직을 오픈소스로 쓰고 이를 상업적으로 이용한다는것은 프로그램에 대한 책임을 져야 한다는것인데 하나의 프로그램에 대한 이해도가 떨어진 상태에서 그에대한 책임을 진다는것은 상식에 어긋난다. 해결능력또한 떨어질수밖에 없다. 

또한 오픈소스의 업데이트에 끌려다닐수도 있다. 보통 유명한 오픈소스라면 주도적인 그룹이 관리를 하게 되는데, 모종의 이유에 의해 관리가 안된다거나 -  혹은 버전업 또는 다른것을 준비하고 있어 핵심기능 추가를 하지 않는다거나 하면 차질이 생길수밖에 없다.

오픈소스가 업데이트를 안해서 우리도 못할것같아요~ 라고 말하는 순간 멋있음은 없어져 버린다. '오픈소스의 업뎃이 늦어서 해당모듈을 개발했고, 이번에 사회적 기업 차원에서 공개했습니다' 라고 생색을 내야하는게 상업적으로 이용하는 측에서의 도리인듯 생각된다.

결국 오픈소스를 쓰고 이를 위해 돈을 벌고있거나 계획을 한다면, 특히 프로그래머들이 이를 완벽히 이해해서 핵심기능을 커밋할 정도까지 실력을 키워놓아야한다. 이를 위해서는 대부분의 구성원들은 핵심이 되는 오픈소스를 자유자재로 가지고 놀수 있을정도까지 파놓아야 문제가 생겼을때의 해결력이 급상승할것이며, 구성원들또한 이를 파고드는과정에서 개선방향과 기반 이론의 발전방향에 대한 인사이트까지 받아올수있다고 생각한다. 

또한 하나의 상품에는 단순한 래핑, 모니터링, 패키지 기능외, 기존의 오픈소스가 하지 않는일 - 더욱 빠른 계산능력이라든지, 신규 논문의 반영으로 탄생한 새 알고리즘과 그에대한 공개되지 않은 결과물 등까지 모두 더해서 존재해야 조금더 고객에게 먹히는 섹시한 솔루션이 될것이다. 그리고 그래야 그 솔루션이 실제로 안풀리던 뭔가를 solve할것이다.

오픈소스의 사용의 전문가보다는 오픈소스의 기반기술에 대한 전문가가 되어야 한다는점을 명심하면서 오늘도 책을 든다...인데 좀 졸립다. 내일해야겠다. 라는 마음도 다시 다잡고 살아야겠다.