오픈소스

오픈소스란?

오픈소스를 이해하면 '직접 만들까, 사올까'라는 이분법이 깨집니다. 업무 시스템의 상당 부분은 새로 짜는 것도, 패키지를 통째로 구매하는 것도 아니라 이미 검증된 부품을 골라 조립하는 일이 되기 때문입니다. 그래서 실무에서 더 중요한 능력은 코딩 실력이 아니라 어떤 부품을 쓸지 고르는 판단력입니다. 전 세계 개발자가 몇 년간 고쳐 온 로그인·차트·결제 모듈을 가져다 쓰면, 우리 팀은 우리 회사에만 있는 문제에 시간을 쓸 수 있습니다.

실제 판단의 기준은 라이선스입니다. MIT·Apache 2.0 같은 허용형은 조건이 느슨해 상업 제품에 넣고 소스를 공개하지 않아도 됩니다. 반면 GPL·AGPL 같은 카피레프트형은 그 코드를 쓴 결과물까지 같은 조건으로 공개하라고 요구합니다. 여기에 코드는 볼 수 있지만 상업적 재배포를 막는 '소스 공개형(source available)'이 섞여 있어 혼란이 생깁니다. 무료 프로그램이라도 소스가 없으면 오픈소스가 아니고, 반대로 오픈소스이면서 기술지원을 유료로 파는 상용 배포판도 흔합니다.

쓸 만한 오픈소스인지 보는 신호는 의외로 단순합니다. 최근 몇 달 안에 코드 수정 기록이 있는지, 사용자가 올린 오류 문의에 관리자가 답을 다는지, 새 버전이 일정한 주기로 나오는지를 봅니다. 인기 표시(별) 개수보다 최근 6개월의 활동 기록이 훨씬 정확한 지표입니다. 관리가 끊긴 라이브러리는 공짜가 아니라, 훗날 우리 개발자가 통째로 떠안게 되는 빚에 가깝습니다.

현장에서 가장 자주 터지는 사고는 "무료니까 법무 검토는 건너뛰자"입니다. AGPL 계열 라이브러리를 고객 납품 솔루션에 넣었다가 고객사 보안 심사에서 걸려 해당 모듈을 다시 걷어내는 일이 실제로 벌어집니다. 오픈소스에는 책임져 줄 판매사가 없다는 점도 잊기 쉽습니다. 보안 취약점이 공지돼도 전화로 알려주는 영업 담당자가 없으니, 어떤 라이브러리를 몇 버전으로 쓰는지 적어 둔 부품 목록과 패치 담당자가 없는 회사는 공지가 뜬 지 반년이 지나도 그대로 방치하게 됩니다.