GPL 코드 격리의 네 가지 엔지니어링 패턴과 법적 경계
전염성 라이선스가 엔지니어를 골치 아프게 만드는 이유
GPL 계열—GPL v2, GPL v3, LGPL, AGPL—은 오픈소스 생태계 전반에 걸쳐 광범위하게 존재한다. 이들의 핵심 논리는 "동일 라이선스 전파"다. GPL 코드와 "결합 저작물"을 구성하는 모든 코드는 동일한 조건으로 공개되어야 한다. 상용 소프트웨어 팀 입장에서 이는 언제든 발동될 수 있는 레드라인을 의미한다.
문제는 "결합"의 경계가 법적 차원에서 한 번도 명확하게 정의된 적이 없다는 점이다. Free Software Foundation의 해석 문서가 현재로선 가장 권위 있는 참고 자료이지만, 여전히 상당한 해석 여지를 남겨 두고 있다. 법원 판례(Versata v. Ameriprise, BusyBox 시리즈 소송 등)는 위반의 대가를 드러낼 뿐, 명확한 컴플라이언스 경계를 제시하지는 않는다.
엔지니어링 팀의 흔한 반응은 "GPL 라이브러리를 써도 괜찮다, 격리를 적용했으니까"다. 그러나 "격리"라는 단어 뒤에는 엄청난 차이가 숨어 있다. 법적으로 충분한 근거를 갖춘 방안이 있는 반면, 엔지니어의 주관적 판단에 불과한 방안도 있다. 이 글의 목적은 네 가지 주요 격리 패턴을 낱낱이 분석해 각각의 전염 경계를 명확히 하고, 법적 논리상 유효한 격리로 볼 수 없는 접근 방식을 짚어내는 것이다.
---
네 가지 격리 패턴의 엔지니어링 구현과 전염 경계
### 패턴 1: 프로세스 격리
엔지니어링 구현: GPL 컴포넌트를 독립적인 운영체제 프로세스로 배포하고, 상용 코드와는 IPC(프로세스 간 통신)—파이프, Unix 소켓, 공유 메모리 메시지 큐 등—를 통해 상호작용한다. 양측은 독립 실행 파일 형태로 존재하며, 컴파일 시점에 완전히 분리된다.
전염 경계 분석: 프로세스 격리는 현재 법적 리스크가 가장 낮은 방안 중 하나다. FSF의 입장은 명확하다. 명확하게 정의된 프로토콜로 통신하는 독립 프로세스들은 "단일 프로그램"을 구성하지 않으므로 GPL 전염을 유발하지 않는다는 것이다. 핵심은 "독립성"의 엔지니어링 구현이다. 두 프로세스는 독립적으로 실행되고 독립적으로 배포될 수 있어야 하며, 인터페이스 프로토콜이 고도로 커스터마이즈된 사유 결합 구조로 설계되어서는 안 된다.
점검 항목: IPC 인터페이스가 범용 프로토콜로 문서화되어 있는지 확인한다. 양측 코드베이스가 독립적으로 컴파일·테스트될 수 있는지 확인한다. 배포 패키지가 실제로 분리되어 있는지 확인한다.
---
### 패턴 2: 동적 링킹
엔지니어링 구현: 상용 코드가 컴파일 시 정적 링킹 방식이 아닌, 런타임에 GPL/LGPL 라이브러리(.so / .dll)를 동적으로 로드한다.
전염 경계 분석: 여기서는 GPL과 LGPL을 구분해야 한다. LGPL은 동적 링킹을 명시적으로 허용하며, 바로 이 시나리오를 위해 설계된 조항이다. 반면 GPL v2/v3의 경우, 동적 링킹이 "결합"을 구성하는지에 대해서는 지속적인 논쟁이 있다. FSF의 공식 입장은 정적 링킹과 동적 링킹 모두 전염을 유발할 수 있으며, 차이는 입증 난이도에 있을 뿐이라는 것이다. 리눅스 커널 커뮤니티는 사용자 공간 프로그램이 시스템 콜을 통해 커널을 사용하는 것을 허용하는 "syscall 예외" 해석을 채택했지만, 이는 커널 커뮤니티의 특정 면제 조항이며 다른 GPL 라이브러리에 일반화할 수 없다.
고위험 오해: 많은 팀이 "동적 링킹 = 안전한 격리"라고 기본 가정하는데, 이는 가장 흔한 인식 오류 중 하나다. 링킹 대상이 LGPL이 아닌 GPL 라이브러리라면, 동적 링킹만으로는 유효한 격리를 구성하기에 충분하지 않다. 라이브러리의 구체적인 라이선스 버전, 예외 선언(classpath exception 등) 유무를 종합적으로 판단해야 한다.
---
### 패턴 3: 네트워크 인터페이스 격리
엔지니어링 구현: GPL 컴포넌트를 독립 서비스로 캡슐화하고, HTTP/gRPC/REST 등 네트워크 프로토콜을 통해 외부에 기능을 제공한다. 상용 코드는 클라이언트로서 이를 호출한다. 두 구성요소는 물리적으로 같은 호스트에 있을 수 있지만, 표준 네트워크 스택을 통해 통신한다.
전염 경계 분석: GPL v2와 GPL v3의 경우, 네트워크 인터페이스는 일반적으로 유효한 격리로 인정된다. 클라이언트와 서버는 독립적인 프로그램이며, 표준 프로토콜로 상호작용하므로 단일 저작물을 구성하지 않는다. 그러나 AGPL(Affero GPL)은 바로 이 지점을 보완하기 위해 만들어졌다. AGPL의 핵심 조항은 "네트워크 이용 = 배포"다. 네트워크를 통해 AGPL 소프트웨어 서비스를 제공하는 경우, 해당 서비스의 소스 코드를 네트워크 사용자에게 공개해야 한다. 따라서 캡슐화 대상이 AGPL 컴포넌트라면, 네트워크 인터페이스 격리는 전염을 차단하지 못하며, 전염 의무를 "링크된 코드"에서 "서비스 운영" 차원으로 이전시킬 뿐이다.
점검 항목: 캡슐화된 컴포넌트의 정확한 라이선스(GPL v2 / GPL v3 / AGPL v3는 본질적으로 다르다)를 확인한다. 서비스가 외부 사용자에게 개방되어 있는지 평가한다. 네트워크 인터페이스 정의가 충분히 범용적이고, 긴밀한 결합을 암묵적으로 내포하지 않는지 확인한다.
---
### 패턴 4: 독립 배포
엔지니어링 구현: GPL 컴포넌트를 완전히 독립적인 소프트웨어 패키지로 배포한다. 독립적인 버전 번호, 독립적인 설치 프로그램, 독립적인 문서를 갖춘다. 상용 제품은 사용자 매뉴얼에 의존 관계를 명시하고, 사용자가 직접 설치하도록 요구한다.
전염 경계 분석: 컴플라이언스 문서 부담이 가장 크지만, 이론적으로는 법적 리스크가 낮은 방안이다. 핵심은 "독립성"이 실질적이어야 한다는 점이다. 상용 소프트웨어의 설치 스크립트가 GPL 컴포넌트를 자동으로 다운로드·설치하거나, GPL 컴포넌트의 기능이 상용 소프트웨어와 너무 깊이 통합되어 사용자가 구분하기 어렵다면, 법원은 여전히 결합 저작물로 인정할 수 있다. 독립 배포의 유효성은 사용자 경험 차원에서 두 제품이 독립적임을 실제로 인지할 수 있는지에 달려 있다.
이 패턴은 임베디드 및 산업용 소프트웨어 환경에서 흔히 볼 수 있으며, 오픈소스 도입 전략에서 사전에 계획해야 할 아키텍처 결정 사항이기도 하다.
---
흔한 오해: 이런 방법은 유효한 격리가 아니다
엔지니어링 실무에서는 널리 통용되지만 법적으로 근거가 부족한 "격리"에 대한 믿음들이 존재한다. 아키텍처 리뷰 시 중점적으로 점검해야 한다.
- "인터페이스 추상화 계층을 사용했으므로 직접 의존성이 없다": 동일한 프로세스, 동일한 컴파일 단위 내에 추상화 계층(인터페이스 클래스, 어댑터 패턴 등)을 도입해도 링킹 관계는 변하지 않으며, 격리를 구성하지 않는다. GPL 전염은 아키텍처 패턴이 아니라 배포 시점의 링킹 상태를 기준으로 판단한다.
- "GPL 라이브러리는 테스트 코드에서만 사용하므로 프로덕션 패키지에 포함되지 않는다": 테스트 코드가 프로덕션 코드와 동일한 코드베이스를 공유하고 동일한 라이선스로 배포된다면 이 주장은 성립하지 않는다. 테스트 의존성이 배포 패키지에서 실제로 제외되는지 확인해야 한다.
- "우리는 SaaS라 소프트웨어를 배포하지 않으므로 GPL이 적용되지 않는다": GPL v2/v3에는 맞는 말이지만, AGPL에는 전혀 해당되지 않는다. SaaS 방식으로 AGPL 컴포넌트를 사용하는 경우에도 소스 코드 공개 의무가 발생한다.
- "코드를 복사했지만 대폭 수정했으므로 새로운 저작물로 봐야 한다": 이는 "파생 저작물"에 대한 오해다. GPL 코드를 수정하여 만든 저작물은 여전히 파생 저작물이며, 수정 정도는 전염성에 영향을 미치지 않는다.
- "상용 라이선스를 구매했으므로 GPL 버전을 사용하는 것이 아니다": 이 논리 자체는 틀리지 않지만, 상용 라이선스가 실제 사용 중인 모든 버전과 모든 사용 시나리오를 포괄하는지 반드시 확인해야 한다. 라이선스 충돌 탐지 실천에는 버전 누락으로 인한 컴플라이언스 실패 사례가 다수 기록되어 있다.
---
아키텍처 리뷰를 위한 점검 프레임워크
GPL 격리 리뷰를 아키텍처 결정 기록(ADR)에 통합하는 것이 체계적인 관리의 기반이다. 다음은 리뷰 시 반드시 다루어야 할 점검 차원이다.
의존성 식별 계층: 먼저 컴포넌트의 정확한 라이선스 버전을 파악해야 한다. 동일한 컴포넌트라도 버전에 따라 다른 라이선스를 사용할 수 있다(예: GPL v2 only vs GPL v2+). 이 단계에서 스니펫 수준의 탐지 능력이 핵심이다. 스니펫 수준 SCA와 매니페스트 스캔의 차이에서 설명했듯, pom.xml이나 package.json에만 의존하면 실제 코드 스니펫의 라이선스 귀속을 대량으로 누락하게 된다. CleanSource SCA의 스니펫 수준 탐지는 3T+ 코드 핑거프린트 데이터베이스를 기반으로, 컴포넌트 선언에만 의존하지 않고 수정되거나 복사·붙여넣기된 GPL 코드 스니펫까지 식별한다.
격리 유효성 계층: 본 글에서 다룬 네 가지 패턴을 기준으로, 아키텍처 문서에 명시된 격리 수단이 실제로 구현되어 있는지 하나씩 점검하고, 앞서 열거한 흔한 오해들을 배제한다.
배포 시나리오 계층: 소스 코드 배포, 바이너리 배포, 컨테이너 이미지, SaaS 서비스 등 제품의 모든 배포 형태를 리뷰한다. 각 형태에 따라 적용되는 컴플라이언스 의무가 다르다. 바이너리 배포 시나리오에서는 CleanBinary의 바이너리 구성 분석을 통해 소스 코드 없이도 GPL 컴포넌트의 존재를 식별할 수 있다.
의무 이행 계층: GPL 의존성이 존재하고 완전한 격리가 불가능하다고 확인된 경우, 의무 이행 경로를 계획해야 한다. 전체 대응 소스 코드의 확보와 보관, 서면 제공 의사 준비, 저작권 고지의 완전성 등이 이에 해당한다. 이 부분은 기업이 가장 소홀히 하기 쉬운 실행 환경이다.
지속 모니터링 계층: 라이선스 컴플라이언스는 일회성 리뷰가 아니다. 컴포넌트 업데이트로 라이선스가 변경될 수 있으며, 새로 도입된 의존성이 기존 격리 방안을 우회할 수 있다. CleanSource SCA CE 커뮤니티 에디션은 지속적인 의존성 모니터링 기능을 제공하며, CI 파이프라인에 자동화 컴플라이언스 게이트를 구축하는 데 적합하다. 관련 실천 사례는 CI/CD 컴플라이언스 게이트 실천을 참고한다.
---
격리는 엔지니어링 판단이자 법적 판단이다
GPL 격리에는 어디서나 통용되는 "안전한 방안"이란 없다. 프로세스 격리는 대부분의 시나리오에서 법적 논리가 가장 명확하지만, 운영 복잡도가 높아진다. 동적 링킹은 LGPL에는 친화적이지만 GPL에는 논란이 있다. 네트워크 인터페이스 격리는 GPL에는 유효하지만 AGPL에는 효력이 없다. 독립 배포는 문서상의 선언이 아닌 실질적인 독립성이 요구된다.
엔지니어링 팀이 받아들여야 할 현실이 있다. 법이 완전히 명확해지기 전까지, 유효한 GPL 격리에는 엔지니어링 구현과 법적 판단의 협력이 필요하다는 것이다. 아키텍처 결정은 제품 출시 직전 임시방편적인 컴플라이언스 보완이 아니라, 설계 단계에서부터 라이선스 요소를 고려해야 한다.
EU CRA가 2027년 12월 전면 적용되면, SBOM 완전성 요구사항으로 인해 라이선스 컴플라이언스의 입증 책임이 대폭 높아질 것이다. 격리 방안은 SBOM 차원에서 검증될 수 있어야 한다. 이는 구두로 주장하는 격리만으로는 더 이상 충분하지 않으며, 엔지니어링 팀이 감사 가능하고 추적 가능한 컴플라이언스 증거 체계를 구축해야 함을 의미한다.
---
*본 글은 Sectrend 리서치에서 제작했다. GPL 컴플라이언스 리뷰를 위한 도구 지원이 필요하다면 오픈소스 라이선스 거버넌스 모범 사례를 참고하거나 Sectrend 기술팀에 문의한다.*
