오픈소스 사용 시 법적 문제가 생기지 않나요?
외주로 서비스를 개발할 때 외주사가 "오픈소스를 활용해서 효율적으로 개발하겠습니다"라고 말하면 많은 창업자분들이 오픈소스 사용이 법적 문제를 일으키지 않을까 걱정하십니다. 또 어떤 분들은 오픈소스를 사용하면 서비스의 품질이 떨어지는 것은 아닌지 우려하기도 합니다. 오픈소스에 대한 올바른 이해와 실제로 주의해야 할 부분을 알아두는 것이 중요합니다.
오픈소스는 법적으로 안전하다
오픈소스는 누구나 일정한 기준 내에 무료 이용이 가능한 것으로 법적 문제가 발생하지 않습니다. 오픈소스 라이선스의 조건만 준수한다면 상업적 서비스에도 얼마든지 사용할 수 있습니다.
오히려 전 세계 개발자들이 검증하고 사용하는 오픈소스는 안정성과 보안성이 높은 경우가 많습니다. 많은 대기업과 성공한 스타트업들도 오픈소스를 적극적으로 활용하고 있으므로, 오픈소스 사용 자체는 전혀 문제가 되지 않습니다.
대표적인 오픈소스 사례
실제로 우리가 매일 사용하는 많은 서비스들이 오픈소스를 기반으로 만들어집니다. 웹사이트 개발에 가장 많이 사용되는 React는 페이스북이 만든 오픈소스이고, 안드로이드 운영체제도 오픈소스입니다. 넷플릭스, 에어비앤비, 우버 같은 글로벌 기업들도 오픈소스를 적극 활용합니다.
데이터베이스 분야에서는 MySQL과 PostgreSQL이 대표적인 오픈소스입니다. 수많은 웹서비스와 앱의 데이터를 저장하고 관리하는 데 사용되고 있으며, 대기업부터 소규모 스타트업까지 모두 신뢰하고 사용합니다. 웹서버 소프트웨어인 Apache와 Nginx도 전 세계 웹사이트의 대부분이 사용하는 검증된 오픈소스입니다.
오픈소스 라이선스의 종류
오픈소스에도 다양한 라이선스가 있습니다. MIT, Apache, BSD 같은 라이선스는 매우 자유로워서 상업적 이용, 수정, 재배포가 거의 제약 없이 가능합니다. 이런 라이선스의 오픈소스는 스타트업이 사용하기에 가장 안전합니다.
예를 들어 React는 MIT 라이선스를 사용하는데, 이는 누구나 자유롭게 사용하고 수정할 수 있으며 상업적 서비스에도 아무 제약 없이 사용 가능합니다. Node.js, jQuery, Bootstrap 같은 인기 있는 오픈소스들도 모두 이런 자유로운 라이선스를 사용합니다.
GPL 같은 라이선스는 조금 더 제약이 있어서, 이 라이선스의 소스코드를 수정하여 사용하면 수정한 코드도 공개해야 하는 의무가 있을 수 있습니다.
진짜 문제: 유료 소스를 오픈소스라고 속이는 경우
오픈소스 자체보다 더 큰 문제는 외주사에서 작업 시 오픈소스라고 하고 유료 소스를 사용한 경우입니다. 이것은 의도적이든 실수든 발주자에게 큰 피해를 줄 수 있는 심각한 문제입니다.
최초 1년 정도의 비용만 외주사에서 지불해 발주자는 오픈소스인 줄 알았다가 서비스 운영 중에 서비스가 작동을 멈추고 나서야 유료인 줄 아는 경우가 있습니다. 어느 날 갑자기 서비스의 핵심 기능이 작동하지 않거나, 관리자 페이지에 접속이 안 되거나, 라이선스 만료 경고가 뜨는 것을 보고 뒤늦게 알게 되는 것입니다.
유료 소스 숨김의 유형
외주사가 유료 소스를 숨기는 방식은 여러 가지입니다. 가장 흔한 경우는 유료 템플릿이나 컴포넌트를 구매해서 사용하면서 발주자에게는 알리지 않는 것입니다. 외주사가 자신의 계정으로 구매하고 1년 치 라이선스 비용을 지불한 후, 발주자에게는 그냥 "개발했습니다"라고만 이야기합니다.
또 다른 경우는 무료 체험 기간이 있는 유료 서비스를 사용하는 것입니다. 개발과 초기 운영에는 문제가 없다가 체험 기간이 끝나면 서비스가 멈추게 됩니다. 이때 외주사는 이미 프로젝트를 종료했고 연락도 잘 안 되는 상황일 수 있습니다.
라이선스 비용의 지속성
유료 소스의 가장 큰 문제는 비용이 지속적으로 발생한다는 점입니다. 월간 또는 연간 구독료를 계속 지불해야 하는데, 이 비용이 예상치 못한 운영비 부담이 됩니다. 때로는 사용자 수나 트래픽에 따라 비용이 증가하는 구조여서 서비스가 성장할수록 비용도 급격히 늘어날 수 있습니다.
더 큰 문제는 해당 유료 소스 없이는 서비스가 작동하지 않도록 개발되어 있다면, 비용이 부담스러워도 계속 지불할 수밖에 없다는 점입니다. 이것을 종속성이라고 하는데, 외주사가 의도적으로 이런 상황을 만들었다면 매우 비윤리적인 행위입니다.
계약 시 명시해야 할 사항
계약서에 오픈소스 사용을 원칙으로 한다는 조항을 넣으세요. 만약 유료 소스가 필요하다면 사전에 발주자의 승인을 받고, 해당 비용과 지속적인 라이선스 비용을 명시하도록 해야 합니다.
또한 프로젝트 완료 시 사용된 모든 오픈소스와 유료 소스의 목록, 각각의 라이선스 정보, 유료 소스의 경우 구독 기간과 갱신 비용을 문서로 제공받도록 계약서에 명시하세요.
깃허브 저장소 소유권 설정
요즘은 대부분의 개발이 깃허브를 통해 이루어집니다.
프로젝트 시작 시 깃허브 저장소의 소유권을 어떻게 설정하느냐가 매우 중요합니다. 가장 안전한 방법은 프로젝트 시작부터 발주자의 깃허브 계정이나 조직에 저장소를 만들고, 외주사에게는 개발을 위한 접근 권한만 부여하는 것입니다. 이렇게 하면 모든 코드와 개발 히스토리가 처음부터 발주자 소유가 되고, 외주사가 언제든 저장소를 확인할 수 있어 투명한 작업 관리가 가능합니다.
만약 외주사의 계정에 저장소가 만들어진 경우라면, 프로젝트 완료 시 저장소의 소유권을 반드시 발주자에게 이전해야 합니다. 단순히 코드를 복사해서 새 저장소에 올리는 것이 아니라, 깃허브의 저장소 이전 기능을 사용하여 모든 개발 히스토리, 브랜치, 태그까지 함께 이전받아야 합니다.
프로젝트 완료 시 인수해야 할 것들
서비스 제작이 완료되면 코드뿐만 아니라 서비스 운영에 필요한 모든 정보와 계정의 소유권을 발주자로 변경해야 합니다.
구체적으로 인수받아야 할 것들은 다음과 같습니다. 깃허브 저장소 소유권, 데이터베이스 백업 파일, 환경 변수 설정 파일(API 키, 비밀번호 등), 서버 접속 정보, 도메인 관리 계정, 호스팅 계정, 사용된 모든 외부 서비스(결제, 문자, 이메일, 지도, 클라우드 등)의 계정 정보입니다.
깃허브에는 소스코드가 저장되지만 데이터베이스는 별도로 관리됩니다. 따라서 개발 중 테스트로 입력된 데이터, 데이터베이스 스키마, 초기 설정 데이터는 데이터베이스 백업 파일로 별도로 받아야 합니다.
환경 변수 파일의 중요성
깃허브에는 보안상의 이유로 API 키, 비밀번호, 데이터베이스 접속 정보 같은 민감한 정보가 포함된 환경 변수 파일이 올라가지 않습니다. 이 파일들은 별도로 전달받아야 서비스를 실제로 운영할 수 있습니다.
외주사에게 환경 변수 파일의 전체 목록과 각 항목의 설명을 요청하세요. 어떤 외부 서비스의 키인지, 어디서 발급받았는지, 갱신이 필요한지 등을 문서로 받아두면 나중에 관리하기 훨씬 수월합니다.
계정 소유권 이전의 중요성
특히 중요한 것은 모든 외부 서비스 계정의 소유권을 완전히 발주자로 이전하는 것입니다. 단순히 비밀번호를 받는 것이 아니라, 계정의 소유자 이메일을 발주자의 이메일로 변경하고, 결제 정보도 발주자의 카드로 변경해야 합니다.
AWS, 네이버 클라우드, 카카오페이, 토스페이먼츠, 알리고 같은 외부 서비스가 외주사의 계정으로 남아있으면 나중에 외주사가 계정을 차단하거나 비밀번호를 변경하면 발주자가 접근할 수 없게 됩니다. 또한 외주사의 카드로 자동 결제가 되고 있다면, 외주사가 카드를 해지하면 서비스가 중단될 수 있습니다.
사용 중인 소스 목록 문서화
프로젝트 완료 시 사용된 모든 소스의 목록을 문서로 받으세요. 깃허브 저장소의 package.json이나 requirements.txt 같은 파일에 사용된 라이브러리 목록이 있지만, 별도로 정리된 문서가 있으면 더 좋습니다.
이 문서에는 각 소스의 이름, 버전, 용도, 라이선스 종류, 오픈소스인지 유료인지, 유료라면 월간/연간 비용이 얼마인지가 포함되어야 합니다. 이 문서가 있으면 나중에 서비스를 유지보수하거나 다른 개발자에게 인계할 때 매우 유용합니다.
유료 소스 발견 시 대응
만약 프로젝트 완료 후 또는 운영 중에 외주사가 숨긴 유료 소스를 발견했다면 어떻게 해야 할까요? 먼저 외주사에게 연락하여 이 사실을 알고 있었는지, 왜 알리지 않았는지 따져야 합니다.
외주사의 고의적인 숨김이라면 계약 위반이므로 해당 유료 소스를 오픈소스로 대체하는 작업을 무료로 요구할 수 있습니다. 이미 발생한 라이선스 비용도 외주사에게 청구할 수 있습니다. 합의가 안 되면 법적 조치도 고려해야 합니다.
오픈소스 대체 가능성
대부분의 유료 소스는 오픈소스 대안이 존재합니다. 지도 기능을 유료인 구글맵 대신 오픈소스인 Leaflet과 무료 지도 서비스를 조합하여 구현할 수 있습니다.
다만 이미 개발된 서비스에서 유료 소스를 오픈소스로 교체하는 작업은 시간과 비용이 들 수 있습니다. 따라서 처음부터 오픈소스를 사용하도록 하는 것이 가장 좋고, 불가피하게 유료 소스를 사용해야 한다면 발주자가 명확히 인지하고 승인하는 과정을 거쳐야 합니다.