Table of Contents
오픈소스가 과연 정답일까?
그런 경우도 많지만 그렇지 않은 경우도 많다.
일단 오픈소스를 신봉하면 안 되는 것은 확실하다.
오픈소스를 맹신하면 안 되는 이유
1. 책임 주체가 불명확 하다.
- 초대형 오픈 소스는 비영리지만 재단이 있고 후원이 있어 제대로 관리가 되긴 하지만 그렇지 못한 것들은 명확한 책임 주체가 없다.
- 개인 기여자는 100% 해당 오픈 소스에 전력을 쏟을 수 없다. 그도 생업이 있고 그 생업이 훨씬 중요하기 때문이다.
2. 기여자의 Quality를 보장할 수 없음.
- 모두에게 열려있는 오픈 소스: Issue를 열고 merge request를 해서 코드 리뷰가 통과되면 모두가 쓰는 코드에 실제로 반영되는 것이다. 이는 빠른 발전을 유도할 수 있으나 퀄리티를 유지할 수 없다는 단점을 함께 가지고 있다.
3. 진짜 고수는 높은 보상을 받으면서 회사 일에 기여하느라 오픈소스 쳐다볼 시간이 없음.
- 기업 내 기술 발전: 대부분의 기술은 회사 단위로 발전되어가고 회사에서 활용되며 그 가치를 인정받는다. 이를 인터넷에 공유하고자 하는 기업들이 많을까? 그 반대가 많을까?
- 지식 공유의 어려움: 불특정 다수에게 지식을 공유한다는 것은 생각보다 많은 공수가 들어간다. 관계가 없던 사람들은 문맥을 따라오지 못하기 때문에 그 문맥부터도 모두 설명해주어야 하기 때문이다. 그리고 컨텐츠 작성자도 남에게 보여지는 내용에 대해선 잘 써야 한다는 피로감을 느낀다.
4. 소스의 변경이 너무 심함.
- 최신 기술을 담은 오픈 소스: 많이 안정화된 오픈 소스 프로덕트는 괜찮은 편이지만, 최신 기술을 담은 오픈 소스들은 소스의 변경이 매우 심하다. Python pip 라이브러리들을 써본 사람들이라면 더 쉽게 이해할 수 있는 부분인데, 코드의 변경이 그냥 간단한 로직 변경이 아니고, 아예 함수 파라미터, 함수명, 프로젝트 구조 등이 확확 바뀐다. 이번 Otel 쪽 연구하면서도 크게 느꼈다. MSA 쪽은 여전히 활발하게 사용되고 있고, 발전해나가고 있는 영역이라 이게 더 심하다. 마이너 버전 하나 올릴 때 내 코드도 수정을 해야 하니 여간 스트레스가 아니다.
5. 오픈소스는 또다른 오픈소스에 종속되어 있어서 QC가 어렵다.
- 오픈 소스의 트렌드 변화: 예전에는 CS 커뮤니티 자체가 그리 크지 않았다. 그리고 오픈 소스의 프로덕트가 이렇게 다양하지도 않았다. 그래서 오픈 소스더라도 검증된 사람들의 검증된 기여가 소수의 오픈 소스 프로덕트에 집중될 수 있었다. 지금은 워낙 CS 커뮤니티가 커졌고 다양한 오픈 소스 프로덕트들이 있다 보니 점점 프로덕트의 개별 퀄리티는 낮아진다.
- 개별 퀄리티 조합의 어려움: 퀄리티가 낮은 개별 오픈소스 프로덕트들을 조합하여 큰 클러스터로 구축했을 때 상호 보완되며 하나의 시스템이 되는 구조가 되어가고 있다. 이는 당연하게도 리소스 낭비로 이어지지만 개별 프로덕트의 퀄리티를 올릴 시간과 비용을 리소스에 때려부으면 되니 이게 더 효율적이다.
- 구조적 문제: 오픈 소스 진영이 이런 구조를 점점 차용해나가니 퀄리티 유지가 더 어려워지고 있다. 내 시스템에 반영된 오픈 소스의 오류를 찾아가보면, 사실 한 단계 더 밑 단의 오픈 소스의 오류이고 이를 반복하는 경우가 많아지고 있다.
그럴 돈이 어딨어요?
그렇다고 오픈소스를 모두 버리고 다 돈주고 솔루션만 쓸까?
그러자는 건 아니다. 확실히 퀄리티 있는 오픈 소스를 사용해야 한다.
퀄리티 있는 오픈 소스를 구분하는 법은 다음과 같다
퀄리티 있는 오픈 소스 구별 법
- Github의 star와 fork 수를 확인: 집단지성에 의해 많을수록 좋을 확률이 높다.
- 공식 페이지에 들어가서 재단을 확인: Apache, linux, could foundry, open stack 등의 backed 재단을 확인해본다. 유명한 재단의 프로젝트라면 신뢰도가 좀 더 올라간다.
- Main sponsor를 확인: 우선 meta, google, microsoft라면 신뢰해라. 특히 microsoft는 무한 신뢰해라. 아무 오픈 소스에나 후원하지 않는다.
- 프로젝트가 release 된지 오래된 오픈 소스를 선택: 특히 메이저 버전이 1 이상인 것을 택하는 편이 좋다. 만년 beta release인 오픈 소스가 정말 많다.
퀄리티 있는 오픈소스만 쓰면 해결이 될까?
아니다. 퀄리티 있는 오픈소스가 왜 퀄리티 있는 오픈 소스인지 알아야 하며, 안 좋은 오픈소스가 왜 안 좋은 오픈소스인지 알아야 한다. 좀 더 근본적인 작동 원리와 활용 목적과 방법을 내가 능동적으로 파악하며 활용해야 한다는 소리다. 그래야만 오픈소스 프로덕트를 제대로 활용할 수 있고, 문제가 발생했을 때 원활하게 해결할 수 있다. 오픈 소스에 과연 문제가 없을 거라고 확신할 수 있나? 내가 주구장창 작동원리를 알아야 한다. 근본으로 돌아가야 한다는 지겨운 말을 하는 게 참 미안하지만 이게 사실이다.
결국은 돌고돌아 내 역량이 중요
문제를 해결하는 데 있어 어떤 오픈소스를 사용하느냐, 어떤 언어를, 플랫폼을, 클라우드를 사용하느냐는 것들은 사실 좀 부수적인 고민사항인 거 같다. 그냥 내 역량이 탄탄하다면 내 문제는 이런데, 해결 방법은 이게 최선인 것 같고, 이 최선을 구현하기 위해선 이런 언어, 이런 오픈소스, 이런 플랫폼, 이런 클라우드를 사용하는 게 맞아. 라고 판단할 수 있다. 역량을 쌓는 방법? 늘 이야기하는 작동원리와 근본을 이해하는 것이다. 특히나 로우레벨까지, 하드웨어 레벨까지 도달할 수록 좋다.
답글 남기기