오픈 소스

오픈 소스, 어렵지 않아요 코드를 공개하면 뭐가 달라질까요

1. 오픈 소스가 대체 뭐예요?

오픈 소스(Open Source)는 소프트웨어를 만든 '설계도'에 해당하는 소스 코드(사람이 읽고 고칠 수 있는 프로그램의 원본 코드)를 모두에게 공개하는 방식이에요. 그래서 누구나 자유롭게 그 코드를 들여다보고, 쓰고, 고치고, 다시 나눠 줄 수 있어요. 반대로 소스 코드는 숨긴 채 실행 파일만 주는 방식을 폐쇄형(독점) 소프트웨어라고 하는데, 오픈 소스는 이것과 정반대 개념이에요.

그렇다고 아무렇게나 막 쓸 수 있는 건 아니에요. GNU GPL, MIT, Apache 2.0 같은 여러 '오픈 소스 라이선스'(코드를 쓸 때 지켜야 할 규칙을 정한 사용 약속)가 권리와 의무를 정해 둬요. 이 약속이 정한 조건만 지키면 코드를 마음껏 활용할 수 있어요.

오픈 소스의 큰 특징은 여러 개발자가 공개된 코드를 함께 살펴보고 고쳐 나가는 협업 방식이라는 점이에요. 코드가 투명하게 드러나 있으니 오류나 보안 취약점(공격에 뚫릴 수 있는 약점)을 여러 사람이 쉽게 찾아 고칠 수 있고, 특정 회사나 사람에게만 매달리게 되는 상황(벤더 락인)도 줄일 수 있어요. 리눅스(Linux) 운영체제, 웹 서버 소프트웨어, 각종 개발 도구처럼 요즘 IT의 바탕을 이루는 많은 것들이 오픈 소스로 만들어져 있어요.

오늘날 오픈 소스는 단순한 배포 방식을 넘어 하나의 개발 문화이자 협업 모델로 자리 잡았어요. 클라우드, 인공지능, 블록체인 같은 최신 기술 분야의 기반이 되고 있죠.

이렇게 보면 쉬워요 · 요리 완성품만 파는 게 아니라 레시피까지 통째로 공개해서 누구나 따라 만들고 고쳐 볼 수 있게 한 것이에요.

2. '공개'만 하면 오픈 소스인가요?

오픈 소스라고 하려면 단순히 코드를 볼 수 있게 하는 것만으로는 부족해요. 몇 가지 자유가 함께 보장돼야 하는데, 보통 다음 네 가지를 핵심 요건으로 꼽아요.

첫째는 열람(access)이에요. 소스 코드 자체를 주거나 쉽게 구할 수 있어야 해요. 둘째는 사용(use)으로, 어떤 목적이든 어떤 분야든 차별하지 않고 누구나 쓸 수 있어야 해요. 셋째는 수정(modify)이에요. 코드를 고쳐서 새로운 파생물(원본을 바탕으로 바꿔 만든 것)을 만들 수 있어야 해요. 넷째는 재배포(redistribute)로, 원본이든 고친 것이든 다시 나눠 줄 수 있어야 해요.

오픈 소스는 사실 '자유 소프트웨어(Free Software)' 운동에 뿌리를 두고 있어요. 자유 소프트웨어 진영은 사용자의 '자유'라는 윤리적 가치를 강조해요. 반면 1998년 등장한 '오픈 소스'라는 표현은 기업과 산업계가 받아들이기 쉽도록, 개발 방식과 실용적인 이점을 앞에 내세운 말이에요. 두 개념은 강조하는 지점이 다르지만, 실제로 다루는 소프트웨어의 범위는 상당 부분 겹쳐요.

3. 어떻게 시작돼서 널리 퍼졌나요?

오픈 소스의 역사는 자유 소프트웨어 운동에서 출발해요.

먼저 자유 소프트웨어 운동이 있었어요. 1983년 리처드 스톨먼(Richard Stallman)은 누구나 자유롭게 쓸 수 있는 운영체제를 만들겠다는 목표로 GNU 프로젝트를 시작했어요. 1985년에는 이를 뒷받침하려고 자유 소프트웨어 재단(FSF)을 세웠고요. 1989년 발표된 GNU GPL은 '고치거나 다시 나눠 준 코드도 똑같은 자유를 유지해야 한다'는 카피레프트(copyleft) 원칙을 라이선스로 공식화했어요.

그다음은 리눅스와 대중화예요. 1991년 리누스 토르발스(Linus Torvalds)가 공개한 리눅스 커널(운영체제의 심장 역할을 하는 핵심 부분)은 GNU 도구들과 합쳐져 완전한 자유 운영체제를 이뤘어요. 그리고 인터넷을 통해 여러 사람이 대규모로 함께 개발하는 대표적인 사례가 됐어요.

마지막으로 '오픈 소스'라는 용어가 등장했어요. 1998년, 실용적인 면을 강조한 '오픈 소스'라는 표현이 채택되고 오픈 소스 이니셔티브(OSI)가 세워지면서 산업계 전반으로 퍼지기 시작했어요. 이후 웹 서버, 데이터베이스, 프로그래밍 언어, 클라우드 인프라에 이르기까지 오픈 소스는 소프트웨어 산업의 표준 구성 요소로 자리 잡았어요.

4. 라이선스는 왜 꼭 확인해야 하나요?

오픈 소스 소프트웨어의 권리와 의무는 라이선스로 정해져요. 코드가 공개돼 있더라도 라이선스가 정한 조건을 벗어나 쓰면 법적 책임을 질 수 있어요. 그래서 각 프로젝트가 어떤 라이선스를 쓰는지 확인하는 게 중요해요. 대표적인 라이선스는 이런 것들이에요.

GNU GPL은 대표적인 카피레프트 라이선스예요. 이 코드로 만든 파생물도 똑같이 GPL로 공개해야 한다는 강한 의무를 지워요. MIT 라이선스는 저작권 표시와 라이선스 고지만 남겨 두면 거의 제약 없이 쓰고 고치고 상업적으로 팔 수도 있는 허용적(permissive, 조건이 느슨한) 라이선스예요. Apache License 2.0은 이 허용적 성격에다 특허 관련 조항을 분명히 밝혀 둬서 기업 환경에서 널리 쓰여요.

라이선스는 크게 두 갈래로 나눌 수 있어요. 파생물에도 공개 의무를 지우는 카피레프트 계열과, 조건이 느슨한 허용적 계열이에요. 서로 다른 라이선스의 코드를 함께 쓸 때는 조건이 부딪히지 않는지, 즉 라이선스 호환성을 확인해야 해요.

5. 여럿이 어떻게 함께 개발하나요?

오픈 소스는 코드를 공개된 저장소(코드를 모아 두는 온라인 창고)에 두고, 여러 개발자가 함께 검토하고 개선하는 협업 방식이에요. 깃허브 같은 코드 호스팅 플랫폼과 버전 관리 시스템(코드가 언제 어떻게 바뀌었는지 기록하고 관리하는 도구)이 이런 협업을 받쳐 주는 핵심 바탕이에요.

보통 참여하는 흐름은 이래요. 먼저 원본 저장소를 복제(포크)하거나 내려받아요. 그다음 기능을 더하거나 버그를 고치는 등 바꾼 뒤에, 변경 제안(풀 리퀘스트 등, '이렇게 고쳤으니 반영해 달라'고 올리는 요청)을 올려요. 그러면 다른 참여자와 관리자가 그 코드를 검토하고 논의해요. 마지막으로 검증을 통과한 변경이 본체에 합쳐져요(머지).

이 과정에서 '충분히 많은 눈이 지켜보면 버그는 드러난다'는 협업의 장점이 발휘돼요. 다만 실제 품질은 참여자가 얼마나 많은지, 검토를 얼마나 성실히 하는지, 유지보수가 얼마나 꾸준한지에 크게 좌우돼요.

6. 좋은 점과 아쉬운 점은 뭔가요?

먼저 장점이에요. 투명성이 있어요. 코드가 공개돼 있어 어떻게 작동하는지, 데이터를 어떻게 다루는지 직접 확인할 수 있어요. 협업과 개선 속도도 빨라요. 여러 사람이 오류와 취약점을 빠르게 찾아 고칠 수 있죠. 종속성도 줄여요. 특정 회사나 사람에게만 매달리는 상황(벤더 락인)을 덜고, 프로젝트가 중단돼도 코드를 넘겨받아 계속 유지할 수 있어요. 비용 면에서도 좋아요. 라이선스 비용 없이 도입하고 시험해 볼 수 있어서 기술이 널리 퍼지기에 유리해요.

한계도 있어요. 공개에는 양면성이 있어요. 취약점 역시 누구나 볼 수 있으니, 공개했다는 사실만으로 안전이 보장되지는 않아요. 유지보수 부담도 있어요. 소수의 자원봉사자에게 기댄 프로젝트는 관리가 끊기거나 업데이트가 늦어질 수 있어요. 라이선스 준수 문제도 있어요. 조건을 어기고 쓰면 법적 분쟁이 생길 수 있죠. 지원의 불확실성도 있어요. 상용 제품과 달리 공식 기술 지원이 보장되지 않는 경우가 많아요.

7. 블록체인에선 왜 특히 중요한가요?

암호화폐와 블록체인 분야에서 오픈 소스는 특히 중요한 자리를 차지해요. 주요 블록체인 프로토콜(블록체인이 지켜야 할 규칙 묶음)은 대부분 소스 코드를 공개해요. 왜냐하면 중앙에서 관리하는 사람이 없는 탈중앙화 시스템에서는, 코드 공개가 신뢰를 얻기 위한 핵심이기 때문이에요. 누구나 코드를 직접 검증할 수 있어야, 화폐를 얼마나 발행하는지, 어떻게 합의(여러 컴퓨터가 무엇이 맞는지 서로 맞춰 보는 방식)하는지, 거래를 어떻게 처리하는지가 공표된 대로 돌아간다는 걸 확인할 수 있어요.

비트코인은 사토시 나카모토가 코드를 오픈 소스로 공개하면서 시작됐어요. 이후 작업증명을 기반으로 한 여러 프로젝트가 이 코드를 참고하거나 갈라내어(포크) 만들어졌고요. 이더리움 같은 스마트 컨트랙트 플랫폼과 솔리디티 같은 개발 언어, 그리고 지갑 소프트웨어의 상당수도 오픈 소스로 배포돼요. 개발자들은 공개된 코드를 테스트넷(실제 돈 없이 미리 시험해 보는 연습용 네트워크)에서 검증한 뒤 메인넷(실제로 운영되는 본 네트워크)에 반영하는 식으로 협업해요.

블록체인에서 공개된 코드는 디앱과 탈중앙화 금융 서비스가 서로의 코드를 다시 쓰고 조합하는 바탕이 되기도 해요. 그리고 프로토콜을 바꾸는 일은 탈중앙화 자율 조직을 통한 공개 논의로 결정되는 경우가 많아요.

8. 실제로 어디에 쓰이나요?

오픈 소스는 오늘날 거의 모든 IT 영역의 토대를 이뤄요.

운영체제와 서버 쪽에서는 리눅스를 비롯한 오픈 소스 운영체제와 웹 서버 소프트웨어가 인터넷 인프라의 큰 부분을 맡고 있어요. 개발 도구와 언어 쪽에서는 여러 프로그래밍 언어의 처리기, 라이브러리(미리 만들어 둔 코드 묶음), 빌드 도구가 오픈 소스로 제공돼요. 데이터와 클라우드 쪽에서는 데이터베이스, 컨테이너·오케스트레이션 도구(여러 프로그램을 담아 나르고 자동으로 관리하는 도구) 등 클라우드 기술의 상당수가 오픈 소스예요. 인공지능 쪽에서는 머신러닝 프레임워크(기계 학습을 만들기 위한 기본 틀)와 일부 모델이 오픈 소스로 공개돼 연구와 응용을 이끌어요. 블록체인 쪽에서는 앞서 본 대로 프로토콜, 지갑, 디앱 같은 핵심 요소가 오픈 소스로 배포돼요.

이렇게 오픈 소스 구성 요소가 다른 소프트웨어 곳곳에 널리 들어가 쓰이면서, 어떤 오픈 소스 코드를 어떤 라이선스로 쓰고 있는지 관리하는 일도 점점 중요해지고 있어요.

9. 공짜로 공개하면서 어떻게 돈을 버나요?

소스 코드를 무료로 공개하면서도 사업을 이어 가기 위해 여러 수익 모델이 발전했어요.

기술 지원·구독 방식이 있어요. 소프트웨어 자체는 공개하되, 설치·운영을 돕고 보증해 주는 서비스를 유료로 파는 거예요. 호스팅형 서비스도 있어요. 오픈 소스 소프트웨어를 클라우드에서 알아서 관리해 주는 서비스로 제공하는 방식이에요. 오픈 코어(open core)도 있어요. 핵심 기능은 오픈 소스로 공개하고, 추가 기능이나 기업용 기능은 유료로 파는 거예요. 후원·재단 방식도 있어요. 개인이나 기업의 후원, 또는 비영리 재단을 통해 프로젝트 운영을 돕는 거죠.

블록체인 분야에서는 프로토콜 코드를 오픈 소스로 공개하면서도, 네트워크의 토큰과 생태계를 통해 개발과 운영을 이어 가는 방식이 나타나기도 해요.

10. 오픈 소스면 무조건 안전한가요?

오픈 소스라는 사실 자체가 보안이나 안전을 보장해 주지는 않아요. 코드가 공개돼 있다는 건 취약점도 누구나 볼 수 있다는 뜻이니까요. 그래서 실제 안전성은 코드의 품질과, 이를 검토하고 감사(꼼꼼히 살펴 문제를 찾아내는 일)하는 커뮤니티가 얼마나 활발한지에 달려 있어요.

또 공개된 코드라도 라이선스 조건을 어기고 쓰면 법적 책임을 질 수 있으니, 각 프로젝트가 채택한 라이선스 내용을 반드시 확인해야 해요. 특히 블록체인 프로젝트를 살펴볼 때는 다음을 함께 확인하는 게 좋아요. 코드가 정말로 공개돼 있고, 실제 배포된 버전과 일치하는지 봐야 해요. 유지보수가 활발하게 이뤄지고 취약점에 잘 대응하는지도 확인해야 해요. 필요하다면 외부 감사나 정형 검증(수학적으로 코드가 규칙대로 작동하는지 엄밀히 따져 보는 방법) 같은 검증을 거쳤는지도 살펴야 하고요.

공개된 코드는 검증할 '가능성'을 열어 줄 뿐이에요. 그 가능성을 진짜 신뢰로 바꾸는 건, 커뮤니티가 꾸준히 검토하고 이용자가 직접 확인하는 일이에요.