오픈소스 활용 vs 자체 개발: 클라우드/인프라 시스템 전략 비교 by gpt

 

오픈소스 사용과 자체 개발의 장단점 요약

• 기술적 측면:
  • 오픈소스 활용 – 검증된 컴포넌트를 활용하여 빠르게 개발 가능하고, 커뮤니티의 기여로 지속적 개선이 이루어집니다 (동향정보 - IDG 블로그 | 클라우드 시대에 오픈소스가 ‘필수’인 이유). 다수 기업이 오픈소스 코드를 활용하는 것은 이제 “테이블 스테이크”로 여겨질 정도로 일반화되어 있습니다 (Corporate Open Source Programs are on the Rise as Shared Software Development Becomes Mainstream for Businesses - Linux Foundation). 하지만 기존 오픈소스 솔루션을 자신들의 특수한 문제에 맞게 적응시키는 데 어려움이 있을 수 있습니다. 종종 며칠을 들여 통합하고 나서야 차라리 처음부터 만드는 편이 나았다고 후회하기도 합니다 (Open-Source vs. Build-Your-Own – A Formula for Deciding). 또한, 공개 소스인 만큼 알려진 보안 취약점에 노출될 위험도 존재합니다 (Open-source vs proprietary software).
  • 자체 개발 – 필요한 기능만 정확히 구현하여 최적화된 성능을 낼 수 있고, 코드와 기능에 대한 완전한 통제권을 가집니다 (Open-Source vs. Build-Your-Own – A Formula for Deciding). 예컨대 Cloudflare는 트래픽 증가로 NGINX의 성능 한계에 부딪히자 새로운 프록시 서버를 직접 개발하여 CPU/메모리 자원을 3분의 1만 사용하면서도 1조 건 이상의 요청을 처리할 수 있게 만들었습니다 (How we built Pingora, the proxy that connects Cloudflare to the Internet) (How we built Pingora, the proxy that connects Cloudflare to the Internet). 그러나 분산 시스템의 복잡한 문제(예: 노드 장애, 이벤트 중복/순서 문제 등)를 제대로 해결하려면 초기 예상보다 훨씬 많은 노력이 들 수 있습니다 (Reinventing the Wheel. One consistent theme I have seen in… | by Randy Shoup | codeburst). 즉, 기본 동작하는 80% 정도는 빠르게 만들 수 있어도, 나머지 20%의 예외처리와 안정화에 전체 노력의 대부분이 필요해지는 경우가 많습니다 (Reinventing the Wheel. One consistent theme I have seen in… | by Randy Shoup | codeburst).

 

• 비용(경제적) 측면:
  • 오픈소스 활용 – 보통 라이선스 비용이 무료이므로 상용 솔루션 대비 비용 절감 효과가 큽니다 (Open-source vs proprietary software) (Open-source vs proprietary software). 또한 구매 절차 없이 바로 도입해 개발에 착수할 수 있어 시간 비용도 줄일 수 있습니다 (동향정보 - IDG 블로그 | 클라우드 시대에 오픈소스가 ‘필수’인 이유). 다만 기술 지원 비용이나 커스터마이징에 드는 내부 인력 비용은 고려해야 합니다. 인기 오픈소스의 경우 많은 온라인 자료와 커뮤니티 지원이 있지만, 즉각적인 공식 지원이 없을 때 문제 해결에 시간이 들 수 있습니다 (Open-source vs proprietary software).
  • 자체 개발 – 초기 개발에 상당한 시간과 인건비 투자가 필요하며, 그 기간에는 기회비용이 발생합니다 (Open-Source vs. Build-Your-Own – A Formula for Deciding). 상용 구매나 오픈소스 사용으로 몇 주만에 구축할 것을 자체 개발하면 몇 달을 소모할 수 있습니다. 반면, 운영 중 라이선스 비용은 없고(내부 인력으로 개발/유지), 외부 업체 종속 없이 유지보수 일정을 통제할 수 있습니다. 규모가 매우 커지면 오히려 자체 최적화로 장비/클라우드 비용을 절감하는 경우도 있습니다 (예: 자체 개발 시스템으로 동일 작업을 더 적은 서버로 처리) (How we built Pingora, the proxy that connects Cloudflare to the Internet). 하지만 전반적으로 기업 대부분은 자체 개발이 구매/오픈소스 대비 더 비용이 많이 들 수 있다고 인식합니다 (Open-Source vs. Build-Your-Own – A Formula for Deciding).

 

• 조직(운영) 측면:
  • 오픈소스 활용 – 도입 장벽이 낮아 개발팀이 필요할 때마다 가져다 쓸 수 있고 (동향정보 - IDG 블로그 | 클라우드 시대에 오픈소스가 ‘필수’인 이유), 개발자 채용이나 교육 측면에서도 익숙한 오픈소스 스택이면 인력 확보와 온보딩이 수월합니다. 오픈소스 프로젝트는 다수의 눈으로 코드 품질을 감시하므로 버그가 빨리 발견/수정되는 경향도 있습니다 (Open-source vs proprietary software). 실제 삼성전자는 내부 개발 제품의 90%에 오픈소스를 활용하고 있으며, 기업의 59%는 오픈소스 활용이 제품 개발 성공에 매우 중요하다고 답했습니다 (). 조직 내에 축적된 도메인 지식이 부족하더라도 커뮤니티의 도움을 받을 수 있다는 점도 장점입니다. 한편, 조직 차원에서 외부 커뮤니티 변화에 따른 영향(프로젝트 중단, 라이선스 변경 등)에 노출되는 단점도 있습니다. 예를 들어 엘라스틱서치 같은 오픈소스가 라이선스를 변경하자 AWS가 급히 자체 포크(OpenSearch)를 내놓는 일이 발생하기도 했습니다.
  • 자체 개발 – 자사 업무에 최적화된 노하우가 조직 내에 축적되고, 이를 바탕으로 한 독자적인 기술/IP 확보가 가능합니다. 남들이 못 가진 자체 시스템이 경쟁우위로 작용하거나, 오픈소스로 공개하여 업계 표준을 선도하는 전략적 효과도 얻을 수 있습니다 (예: 구글의 Kubernetes와 TensorFlow는 내부 기술을 공개해 생태계를 장악한 사례). 하지만 유지보수와 개선 책임이 전적으로 조직 내부에 있으며, 특정 개발자나 팀에 지식이 집중되는 리스크가 있습니다. 새로운 팀원을 뽑아도 사내 고유 시스템을 처음부터 배워야 하므로 러닝커브가 있습니다. 또한 “Not-Invented-Here(우리 것이 최고)” 증후군으로 불필요한 자체 솔루션을 남발하면 정작 고객 가치에 집중해야 할 자원을 소모하고 조직 생산성이 저하될 수 있습니다 (Reinventing the Wheel. One consistent theme I have seen in… | by Randy Shoup | codeburst) (Reinventing the Wheel. One consistent theme I have seen in… | by Randy Shoup | codeburst).

 

기업 규모별 오픈소스 vs 자체 개발 활용 사례

스타트업 및 소규모 팀 사례

초기 스타트업은 신속한 서비스 개발과 배포를 위해 성숙한 오픈소스 도구에 크게 의존하는 경향이 있습니다. 예를 들어 인스타그램(Instagram)은 창업 초기에 단 3명의 엔지니어로 수천만 사용자를 지원할 수 있었는데, 이것은 Django 웹프레임워크, PostgreSQL DB, Redis/Memcached 캐시, Gearman 큐 등 여러 검증된 오픈소스를 적절히 조합한 덕분입니다 (How Instagram Scaled Its Infrastructure To Support a Billion Users) (How Instagram scaled to 14 million users with only 3 engineers). 이처럼 레고 블록처럼 오픈소스를 조립함으로써, 소규모 인력으로도 대규모 트래픽을 감당하는 백엔드 아키텍처를 빠르게 구축했습니다 (How Instagram Scaled Its Infrastructure To Support a Billion Users). 인스타그램의 사례에서 보듯이 스타트업은 핵심 제품 개발에 집중하고 인프라나 기반기술은 오픈소스로 해결하여 시장 출시에 필요한 시간과 비용을 절약합니다. 또 다른 예로 왓츠앱(WhatsApp)도 초기 소규모 팀이었지만, 무료 오픈소스인 Erlang/OTP 기반 XMPP 서버를 활용해 별도 라이선스 비용 없이 신뢰성 높은 메신저 백엔드를 구현했습니다. 이처럼 좋은 오픈소스 기술을 선별하여 사용하면 스타트업은 적은 비용으로 안정적인 서비스 구축과 빠른 성장이 가능함을 보여줍니다.

중견기업 및 스케일업 사례

기업이 성장하여 트래픽과 데이터가 폭발적으로 증가하면, 기존에 도입한 오픈소스에 대한 한계가 드러나거나 추가적인 요구사항이 생기곤 합니다. 이를 해결하기 위해 오픈소스를 커스터마이징하거나 새로운 시스템을 자체 개발하는 결정을 내리는 사례가 중견 규모의 기술 기업에서 나타납니다. 예를 들어 차량 공유 서비스 기업 우버(Uber)는 초창기엔 모니터링에 Nagios, 시계열 DB에 Graphite 등 오픈소스 도구들로 인프라를 구성했습니다 (Metrics Collection at Scale: Learning from Uber's M3 - InfoQ). 그러나 마이크로서비스로 아키텍처가 바뀌고 컨테이너 환경(Mesos, Kubernetes)이 도입되자, 기존 모니터링 툴들이 동적 환경에 맞지 않는 한계를 보였습니다 (Metrics Collection at Scale: Learning from Uber's M3 - InfoQ). 우버는 결국 M3라는 자체 모니터링 플랫폼을 개발했고, 초기에 Cassandra와 Elasticsearch 같은 OSS 컴포넌트를 사용했다가 점차 이를 대체하는 전용 저장소(M3DB) 등을 만들어 성능과 확장성을 높였습니다 (Metrics Collection at Scale: Learning from Uber's M3 - InfoQ). 그 결과 우버는 폭증하는 메트릭 데이터와 쿼리 부하를 감당할 수 있는 맞춤형 모니터링 시스템을 확보하게 되었습니다.

또 다른 사례로, 클라우드플레어(Cloudflare)는 전 세계 트래픽을 프록시하는 CDN 기업으로서 오랜 기간 오픈소스 웹서버 NGINX를 개조하여 사용해왔습니다. 그러나 사용자가 기하급수적으로 늘고 요구 기능이 복잡해지면서 NGINX의 구조로는 한계가 분명해졌습니다. 이에 Cloudflare는 Rust 언어로 새로운 프록시 서버인 Pingora를 자체 개발하였고, 기존 대비 성능과 효율을 크게 개선했습니다 (How we built Pingora, the proxy that connects Cloudflare to the Internet) (How we built Pingora, the proxy that connects Cloudflare to the Internet). Pingora는 Cloudflare 내부 용도로 시작되었지만 완성도 높게 구축되어, 이후 오픈소스로 공개되기도 했습니다 (대규모 Rust 기반 프록시 프레임워크로 공개됨).

이처럼 중견/스케일업 단계의 기업은 오픈소스로 시작하되, 규모가 커지면서 생기는 공통 요구사항(예: 모니터링, 데이터 처리)을 충족하기 위해 내부 역량을 투입해 새로운 솔루션을 개발하거나 기존 오픈소스를 대체하는 경향이 있습니다. 핵심은, 이러한 자체 개발이 명확한 필요에 근거할 때 성공적이라는 것입니다.

 

대기업 및 실리콘밸리 선도 기업 사례

대기업들은 방대한 사용자와 데이터를 처리하며, 이 과정에서 자사의 특수한 요건에 맞춘 독자 기술 스택을 만들어온 역사가 있습니다. 구글(Google)은 그 대표적인 예로, 초창기 시절 상용 DB나 기존 분산시스템이 없던 검색 인프라를 구축하기 위해 Google File System, MapReduce, Bigtable 등의 시스템을 내부에서 직접 설계/구현했습니다. 이들은 나중에 학계나 업계에 개념을 공개하여 하둡(Hadoop) 에코시스템이나 NoSQL 열람 테이블 등 오픈소스 프로젝트들의 탄생을 이끈 촉매가 되기도 했습니다. 최근 구글은 내부 Borg 시스템을 모델로 한 Kubernetes를 오픈소스로 공개하고 주도하여 클라우드 시대의 사실상 표준으로 만들었고, 머신러닝 분야에서도 내부 TF로 만든 TensorFlow를 오픈소스로 풀어 생태계를 장악했습니다. 메타(페이스북) 또한 PHP로 시작한 서비스를 확장하는 과정에서 PHP 엔진(HHVM), 분산 그래프 DB(TAO), 실시간 로그 시스템(Scribe) 등을 자체 개발했고, Cassandra, Hive, Presto, React, PyTorch 등 수많은 내부 개발 기술을 오픈소스로 내놓았습니다. 이러한 빅테크 기업들은 내부에서 충분히 검증된 기술을 공개함으로써 업계 영향력을 높이고, 동시에 커뮤니티의 참여로 기술을 더욱 발전시키는 선순환을 만들고 있습니다 (Corporate Open Source Programs are on the Rise as Shared Software Development Becomes Mainstream for Businesses - Linux Foundation) (Corporate Open Source Programs are on the Rise as Shared Software Development Becomes Mainstream for Businesses - Linux Foundation).

일부 대기업은 오픈소스에서 시작해 자체 솔루션으로 갈아탄 경우도 있습니다. 트위터(Twitter)는 초기엔 루비 온 레일즈(RoR)와 MySQL 등 일반적인 오픈소스 스택으로 서비스했지만, 급격한 성장으로 성능 문제가 불거지자 핵심 시스템을 대대적으로 갈아엎었습니다. 트위터는 Scala 기반의 분산 시스템으로 전환하며, 데이터 저장도 MySQL에서 Cassandra(오픈소스 NoSQL)를 도입했다가, 최종적으로 Manhattan이라는 자체 분산 데이터베이스를 구축했습니다 (The Distributed Database Behind Twitter | YugabyteDB) (The Distributed Database Behind Twitter | YugabyteDB). 현재 트위터는 Manhattan 클러스터 수십 개로 수 페타바이트의 데이터를 처리하지만, 이는 바로 이러한 과감한 자체 개발 투자로 가능해진 것입니다 (The Distributed Database Behind Twitter | YugabyteDB). 넷플릭스(Netflix) 역시 마이크로서비스 아키텍처의 선구자로서, 오픈소스 기술(Cassandra, Elasticsearch 등)을 광범위하게 사용하면서도 필요한 경우 Hystrix(서킷브레이커), Eureka(서비스 디스커버리), Chaos Monkey(장애 테스트) 같은 독자 툴을 만들어 활용하고 모두 오픈소스로 공개했습니다. 이로써 넷플릭스는 서비스 신뢰성을 높이는 혁신적 기법을 업계에 전파하며 기술 리더십을 확보했습니다.

종합하면, 실리콘밸리의 선도 기업들은 오픈소스를 적극 활용하여 개발 속도를 높이되, 자사 규모에서 요구되는 기능이나 성능을 충족하기 위해서는 주저하지 않고 자체 기술을 개발합니다. 그리고 그렇게 축적한 기술을 다시 오픈소스로 공유함으로써 산업 전반의 발전을 이끄는 동시에 자신들의 입지도 강화하는 전략을 취하고 있습니다.

오픈소스에서 자체 개발로 전환된 사례와 배경

규모가 커지면 처음엔 잘 맞던 오픈소스 기술도 병목이나 한계가 발생하여 자체 개발로 전환하는 일이 종종 있습니다. 주요 사례들을 살펴보면 다음과 같습니다:

• 트위터 – 데이터스토어의 진화: 앞서 언급했듯 트위터는 MySQL로 시작해 Cassandra로 확장성을 도모했으나, 운영상의 문제(클러스터 관리 복잡성 등)로 결국 Manhattan이라는 사내 분산DB를 개발했습니다 (The Distributed Database Behind Twitter | YugabyteDB). 2012년 자체 구축한 Manhattan은 수천 노드에 수십억 요청을 처리할 만큼 성장했으며, 이후에도 RocksDB 백엔드 도입 등 지속적으로 개량되고 있습니다 (The Distributed Database Behind Twitter | YugabyteDB) (The Distributed Database Behind Twitter | YugabyteDB). 트위터 사례는 오픈소스 → 자체 개발로의 전환이 단번에 이뤄진 것이 아니라, 증가하는 요구사항에 따라 단계적으로 이루어졌음을 보여줍니다 (단일 DB → 분산 NoSQL → 전용 분산DB).
• 우버 – 모니터링 시스템의 재구축: 우버는 초기의 Nagios/Graphite 기반 모니터링에서 출발해, 컨테이너화된 마이크로서비스 환경에서는 이 접근이 한계가 있다고 판단했습니다 (Metrics Collection at Scale: Learning from Uber's M3 - InfoQ). 그래서 내부 프로젝트로 M3라는 새 플랫폼을 만들었는데, 처음에는 Cassandra/Elasticsearch 같은 오픈소스 부품을 조합했으나 서비스 이용량이 폭발적으로 늘어나자 핵심 구성요소들을 자체 기술(M3DB 등)로 교체했습니다 (Metrics Collection at Scale: Learning from Uber's M3 - InfoQ). 이는 “일단 오픈소스로 만들고, 한계가 보이면 교체”하는 접근으로, 우버가 운영하면서 점진적으로 교체해나간 사례입니다. M3는 현재 우버 내부에서 수백 명의 엔지니어가 매일 사용하는 핵심 툴로 자리 잡았으며, 나아가 우버 출신들이 창업한 Chronosphere 등을 통해 외부에도 그 철학이 전파되고 있습니다 (Metrics Collection at Scale: Learning from Uber's M3 - InfoQ).
• Cloudflare – 웹 서버/프록시의 교체: Cloudflare는 수년간 웹 트래픽 프록시로 오픈소스 NGINX를 수정해 사용했지만, 커넥션 처리 모델의 한계와 원하는 커스터마이징의 어려움에 부딪혔습니다 (How we built Pingora, the proxy that connects Cloudflare to the Internet) (How we built Pingora, the proxy that connects Cloudflare to the Internet). 결국 Pingora라는 완전히 새로운 프록시 엔진을 Rust로 구현했는데, 이는 Cloudflare의 특정 요구 (장기 지속 커넥션 최적화, 멀티테넌시 등)을 반영한 결과물이었습니다. Cloudflare는 Pingora 개발 배경에 대해 “NGINX는 우리에겐 훌륭했지만, 우리 규모에서 필요한 성능과 기능을 제공하지 못하게 되어 직접 만들게 됐다”고 설명합니다 (How we built Pingora, the proxy that connects Cloudflare to the Internet). 이처럼 자신들의 트래픽 패턴과 환경에 최적화한 자체 솔루션으로 전환함으로써 오픈소스의 한계를 극복한 사례입니다.
• 페이스북 – 인프라 컴포넌트 교체: 페이스북도 오픈소스와 자체개발 전환 사례가 여럿 있는데, 그 중 하나가 채팅 시스템입니다. 초창기에는 XMPP 기반의 오픈소스 서버를 활용했으나, 수억 사용자 동시 접속을 처리하는 데 어려움이 있어 Erlang으로 자체 구축한 채널 서버로 교체했습니다 (Chat Stability and Scalability - Engineering at Meta) (Chat Stability and Scalability - Engineering at Meta). 또한 이미지 저장소도 NFS → 자체 개발한 Haystack 파일시스템으로, PHP 엔진도 Zend → 자체 개발 HHVM으로 대체하여 성능을 크게 높였습니다. 이들 교체의 공통된 배경은 “상용/오픈 기술이 처리하지 못하는 페이스북만의 규모 문제를 해결하기 위해”였습니다.

이러한 사례들의 배경은 결국 비슷합니다. 오픈소스로 빠르게 시작하되, 서비스가 폭발적 성장을 이루거나 특수한 요구사항(초저지연, 초대용량, 특수 워크로드 등)이 나타날 때 자체 기술로 교체하거나 보완한 것입니다. 다만 모든 기업이 이런 전환을 선택하는 것은 아닙니다. 전환에는 높은 비용과 리스크가 따르기 때문에, 선도 기업들도 불가피할 때에만 자체 개발로 나아갑니다.

 

오픈소스의 한계와 자체 개발의 필요성이 드러나는 상황

위 사례들을 통해 오픈소스 활용의 어떤 한계가 자체 개발을 필요로 만드는지 정리하면 다음과 같습니다:

• 확장성 및 성능 한계: 오픈소스 소프트웨어가 설계된 범위를 넘어서는 초대형 스케일에서는 성능 저하나 병목이 발생할 수 있습니다. Cloudflare의 경우 NGINX가 수천만 동시 연결을 효율적으로 관리하지 못해 직접 새 엔진을 작성했으며 (How we built Pingora, the proxy that connects Cloudflare to the Internet), 트위터도 Cassandra로 수평 확장했지만 특정 워크로드에서 성능 문제가 있어 Manhattan을 개발했습니다 (The Distributed Database Behind Twitter | YugabyteDB). 낮은 자원 소모로 더 높은 처리량을 내기 위해 자체 개발을 선택하는 것입니다.
• 특화 기능 부재: 기존 오픈소스에 원하는 기능이 없거나, 우리 서비스에 맞게 정밀하게 최적화된 기능이 필요할 때입니다. 예를 들어 넷플릭스가 만든 Chaos Monkey 같은 장애 주입 테스트 도구는 당시 시중에 대안이 없어서 탄생한 것이고, 페이스북이 개발한 GraphQL도 클라이언트에 맞춤형 데이터 쿼리를 지원하기 위해 자체 고안한 기술입니다. 오픈소스 솔루션이 “원하는 것의 80%”만 제공하고 20%의 간극이 있을 때, 그 20%를 채우려 자체 개발에 나섭니다 (Reinventing the Wheel. One consistent theme I have seen in… | by Randy Shoup | codeburst) (Reinventing the Wheel. One consistent theme I have seen in… | by Randy Shoup | codeburst).
• 아키텍처/환경 부조화: 우버 사례처럼 기존 모니터링 툴이 동적 오케스트레이션 환경(컨테이너/클라우드)에 맞지 않아 새로 설계한 경우가 해당됩니다 (Metrics Collection at Scale: Learning from Uber's M3 - InfoQ). 또 하나의 예로, 전통적 RDBMS나 파일시스템은 분산 클라우드 환경에서 제약이 많아, 구글이 Spanner와 Colossus 파일시스템 등을 개발한 것처럼 새로운 아키텍처에 부합하는 도구를 만드는 경우입니다. 기술 스택의 변혁(모놀리식→마이크로서비스, 온프레미스→클라우드 등)이 있을 때 오픈소스가 그 변화를 못 따라오면 자체 개발로 채워넣게 됩니다.
• 커뮤니티/지원 한계 및 라이선스 이슈: 오픈소스가 활발히 유지보수되지 않거나 지원이 부족할 때도 문제가 됩니다. 예를 들어 사내 핵심 시스템에 사용하던 OSS 프로젝트가 중단되면, 포크해서 자체 유지보수를 하거나 처음부터 다시 써야 할 수 있습니다. 라이선스 변경이나 제약도 고려 요소인데, 앞서 언급한 Elastic 사례처럼 라이선스가 바뀌어 더 이상 자유롭게 사용할 수 없게 되면 기업은 자체 대안을 모색합니다. AWS가 Elasticsearch를 포크해 OpenSearch를 만든 것이 한 예이며, MongoDB의 라이선스 변경(SSPL) 이후 이를 피하기 위해 호환 DB 서비스를 자체 개발하는 움직임도 있었습니다. 즉 법적/정책적 리스크가 현실화될 때도 자체 솔루션 필요성이 대두됩니다.

요약하면, “현재의 오픈소스 도구로 우리의 요구를 만족시키기에 부족한가?”를 질문했을 때 그 격차(gap)가 크고 핵심적이면 자체 개발의 필요성이 커집니다. 반대로, 오픈소스의 한계를 비교적 작은 불편이나 타협으로 수용 가능하다면 굳이 자체 개발로 갈 이유는 줄어듭니다. 많은 기업들이 핵심 비즈니스와 직접 관련되지 않은 부분(예: 로그 수집, 인증 시스템 등)은 웬만하면 오픈소스로 해결하려는 것도 이 때문입니다 – 큰 문제없이 쓸 수 있는 한은 검증된 휠을 다시 발명하지 않으려는 것입니다.

엔지니어 역량과 오픈소스/자체개발 선호에 대한 고찰

사용자 질문에 포함된 “프로그래밍 실력이 좋을수록 자체개발 선호, 엔지니어링 실력이 좋을수록 오픈소스 선호”라는 견해는 흥미로운 대비인데, 이를 입증하는 명확한 통계자료가 존재하지는 않습니다. 다만 업계 경향과 사례를 토대로 판단해보면 다음과 같습니다.

우선, 높은 역량의 엔지니어일수록 오픈소스를 선호하는 경향이 분명히 관찰됩니다. 실제로 포춘 2000대 기업의 72%는 내부에서 오픈소스를 적극 활용하고 있고, 절반 이상이 제품에도 오픈소스를 포함하고 있으며, 관리자들의 59%가 오픈소스 프로그램이 엔지니어링 성공에 핵심적이라고 응답했습니다 (Corporate Open Source Programs are on the Rise as Shared Software Development Becomes Mainstream for Businesses - Linux Foundation) (Corporate Open Source Programs are on the Rise as Shared Software Development Becomes Mainstream for Businesses - Linux Foundation). 이는 세계 유수의 기업 (곧 최고의 엔지니어들을 보유한 기업)일수록 오픈소스 활용을 전략적 필수 요소로 보고 있다는 뜻입니다. 뛰어난 엔지니어들은 새로 휠을 만드는 것보다 기존 훌륭한 휠을 활용하여 더 먼 거리를 갈 수 있음을 잘 알고 있으며, 오픈소스 참여를 통해 지식 공유와 협업의 이점을 얻고자 합니다. 또한 자기 실력을 과시하기 위해 함부로 내부 솔루션을 만드는 대신, 검증된 솔루션을 활용하고 필요시 기여/개선하는 것이 효율적임을 경험으로 체득한 경우가 많습니다.

반면, 일부 뛰어난 개발자들은 자신의 통제 범위 내에서 모든 것을 구축하려는 성향을 보이기도 합니다. 특히 해결하려는 문제가 회사의 경쟁력을 좌우하는 핵심 영역일 때, 최고의 인재들은 오픈소스에 없는 혁신적인 솔루션을 직접 만들어내곤 합니다. 예를 들어 구글, 아마존 등의 세계적인 기술기업들은 남들이 시도하지 않았던 규모의 문제들을 자체 기술로 풀어왔고, 이로 인해 업계를 선도하는 위치에 올랐습니다. 이러한 경우는 “실력이 좋기 때문에 자체 개발로 승부”를 본 사례라고도 할 수 있습니다. 다만 이들은 어디까지나 불가피하거나 전략적 필요에 의해 자체 개발을 택한 것이지, 단순히 실력이 있어서 무조건 자체 개발을 고집한 것은 아닙니다. 성숙한 리더일수록 언제 구축하고 언제 받아쓸지 구분하며, 오픈소스에 없는 진짜 새로운 가치를 제공할 때에만 직접 만들고 그렇지 않으면 있는 것을 활용하는 결정을 내립니다 (Reinventing the Wheel. One consistent theme I have seen in… | by Randy Shoup | codeburst) (Reinventing the Wheel. One consistent theme I have seen in… | by Randy Shoup | codeburst).

요컨대, 엔지니어의 역량보다는 문제의 성격과 필요성에 따라 오픈소스를 쓸지 자체 개발할지가 결정되는 경우가 대부분입니다. 물론 개인이나 조직의 성향도 약간의 영향을 줄 수 있습니다. 가령 어떤 문화에서는 “우리 실력으로 새롭게 만들어보자”는 도전을 중시하기도 하고, 또 다른 문화에서는 “검증된 것을 우선 쓰자”는 실용주의를 중시하기도 합니다. 그러나 오늘날에는 오픈소스 활용이 워낙 일반화되어 있고, 자체 개발은 선택과 집중의 문제이기 때문에, 뛰어난 개발자일수록 오히려 언제 오픈소스를 활용하고 언제 직접 만들어야 할지 판단을 잘 내린다고 보는 편이 타당합니다. Randy Shoup 등 업계 베테랑들도 “많은 개발자와 조직이 이미 있는 툴을 재구현하는 데 시간을 낭비하는 것을 봐왔다. 나 역시 그 유혹에 빠진 적 있지만, *남이 만든 것을 차용하지 않고 처음부터 만들 때 치르게 될 기회비용*을 잊지 말아야 한다”고 조언합니다 (Reinventing the Wheel. One consistent theme I have seen in… | by Randy Shoup | codeburst) (Reinventing the Wheel. One consistent theme I have seen in… | by Randy Shoup | codeburst).

 

결론적으로, 오픈소스 vs 자체개발의 선택은 엔지니어의 실력 수준보다 프로젝트의 목표, 시급성, 규모, 그리고 기존 솔루션의 성숙도에 달려 있습니다. 뛰어난 엔지니어들은 자신만의 코드를 함부로 자랑하기보다 필요한 곳에만 자기 실력을 투입하고, 나머지는 커뮤니티의 지혜를 빌리는 현명한 선택을 합니다. 그래서 스타트업부터 대기업까지 대부분의 성공적인 팀은 “기존에 잘 돌아가는 것은 가져다 쓰고, 차별화 요소에만 개발 역량을 집중”하는 전략을 취하고 있습니다. 이를 뒷받침하듯, 전 세계 기업들의 오픈소스 이용은 지속적으로 증가해왔고 (Corporate Open Source Programs are on the Rise as Shared Software Development Becomes Mainstream for Businesses - Linux Foundation), 동시에 특정 기업 규모나 특수한 요구에 따른 자체 개발 사례도 꾸준히 나타나고 있습니다. 양쪽의 장단점을 정확히 이해하고 상황에 맞게 활용하는 것, 그것이 실력 있는 엔지니어와 조직의 모습이라 할 수 있습니다.

Sources: 각 사례와 통계는 인용된 자료를 참고하였으며, 기업 기술 블로그, 엔지니어링 보고서, 설문조사 결과 등을 기반으로 정리되었습니다. (Open-Source vs. Build-Your-Own – A Formula for Deciding) (동향정보 - IDG 블로그 | 클라우드 시대에 오픈소스가 ‘필수’인 이유) (How we built Pingora, the proxy that connects Cloudflare to the Internet) (The Distributed Database Behind Twitter | YugabyteDB) (Metrics Collection at Scale: Learning from Uber's M3 - InfoQ) (Corporate Open Source Programs are on the Rise as Shared Software Development Becomes Mainstream for Businesses - Linux Foundation) 등 인용 표기를 통해 출처를 확인할 수 있습니다.