라이선스 준수

License Compliance

관행

제품에 들어간 외부 소프트웨어를 목록으로 만들고 각각에 붙은 조건을 지키고 있는지 주기적으로 점검하는 일입니다.

등장 배경

공개된 소프트웨어를 가져다 쓰는 것이 기본이 되면서 제품 하나에 딸려 들어오는 외부 코드가 수백 개 단위가 됐습니다. 그중 사람이 직접 고른 것은 몇십 개뿐이고 나머지는 고른 것이 끌고 들어온 것입니다. 날짜를 다루는 도구 하나를 넣었더니 그것이 다시 여섯 개를 데려오는 식입니다.

문제는 공개돼 있다는 말이 조건 없이 써도 된다는 뜻이 아니라는 데 있습니다. 오픈소스 라이선스는 공개된 소프트웨어를 쓸 때 지켜야 할 조건을 적어 둔 문서이고, 만든 사람 이름과 라이선스 원문을 제품 어딘가에 남기라는 정도가 흔한 조건입니다.

그런데 조건의 세기가 하나가 아닙니다. 카피레프트는 이 코드를 가져다 만든 결과물도 같은 조건으로 공개하라고 요구하는 쪽입니다. 파는 제품 안에 이런 코드가 들어가면 우리가 쓴 코드까지 공개 대상이 될 수 있습니다. 이름표를 보지 않고 묶어 쓰다 보면 언젠가 센 것을 잘못 집게 됩니다.

페이지덱은 기업 고객 계약 막바지에 이걸 처음 겪었습니다. 상대 법무팀이 쓰고 있는 오픈소스와 각각의 라이선스를 목록으로 달라고 요구했는데 그런 문서가 없었습니다. 태오가 이틀을 들여 손으로 훑는 동안 계약은 멈춰 있었고, 훑고 나니 고지 화면에 빠진 항목이 열 개 넘게 나왔습니다.

진행 순서

목록을 먼저 만들고, 항목마다 조건을 붙여 판정한 다음, 새로 들어오는 것을 막는 검사를 겁니다.

  1. 제품에 들어간 외부 소프트웨어를 버전까지 적어 목록으로 만듭니다. 직접 고른 것과 그것이 끌고 온 것을 모두 담습니다. 수백 개를 손으로 세는 방식은 다음 배포에서 바로 틀어지므로 빌드 과정에서 뽑아냅니다.
  2. 항목마다 라이선스 이름표와 원문을 붙입니다. MIT 나 Apache 2.0 처럼 널리 쓰이는 이름은 대부분 자동으로 붙지만, 이름표가 비어 있거나 두 개가 겹쳐 붙은 항목은 사람이 원문을 열어 확인합니다. 실제로 사고가 나는 자리가 여기입니다.
  3. 조건을 세 갈래로 나눕니다. 고지만 하면 되는 것, 조건이 붙는 것, 제품에 넣을 수 없는 것으로 가릅니다. 항목마다 그 자리에서 판단하지 않고 회사가 미리 정해 둔 허용 목록에 대보는 방식이라야 판정이 사람마다 달라지지 않습니다.
  4. 걸린 항목을 처리합니다. 고지가 빠진 것은 고지 화면에 더하면 끝나지만, 넣을 수 없는 것으로 분류된 코드는 같은 일을 하는 다른 것으로 바꾸거나 제품에서 떼어 냅니다. 이미 팔고 있는 기능에서 발견되면 이 작업이 몇 주짜리가 됩니다.
  5. 내보낼 문서를 만들어 둡니다. 설정 화면 맨 아래의 오픈소스 고지와 기업 고객에게 낼 목록 파일 두 가지입니다. 요구받고 나서 만들면 늦습니다.
  6. 들어오는 길목에 검사를 겁니다. 새 항목이 추가될 때 라이선스를 자동으로 확인하고 허용 목록에 없으면 합치지 못하게 막습니다. 코드를 실행하지 않고 훑어 문제를 찾는 정적 분석 검사가 붙는 자리와 같은 곳에 겁니다.

참여자와 시점

개발자가 목록을 뽑고 법무를 맡는 쪽이 판정 기준을 정하는 구조입니다. 판정까지 개발자에게 맡기면 사람마다 기준이 갈리고, 목록까지 법무에 맡기면 빌드 구조를 모르는 채로 세게 됩니다.

  • 개발자 — 목록을 자동으로 뽑고, 검사를 빌드에 붙이고, 걸린 항목을 바꿉니다.
  • 법무를 맡는 쪽 — 허용 목록을 정하고 애매한 라이선스를 판정합니다. 초기 조직에서는 대표가 외부 자문을 받아 이 자리를 겸합니다.
  • 세일즈 — 고객사가 요구하는 문서의 형식과 기한을 가져옵니다.
  • 프로덕트 매니저 — 걸린 항목을 바꾸는 작업을 어느 주기에 넣을지 정합니다.

시점은 넷입니다. 코드를 합칠 때마다 자동 검사가 돌고, 출시 전에 고지 화면이 최신인지 확인하고, 기업 고객과 계약 실무를 진행할 때 목록을 내놓고, 투자를 받기 전 실사 과정에서 같은 목록을 다시 요구받습니다. 앞의 둘은 자동으로 돌아가게 해 두고 뒤의 둘에서 꺼내 쓰는 것이 목표입니다.

실무 용례

"이 라이브러리 라이선스가 뭐예요? 카피레프트면 이 자리에는 못 씁니다."

제품에 직접 들어가는 코드라 조건이 센 쪽이면 다른 것을 찾아야 한다는 뜻입니다.

"고객사 법무팀에서 오픈소스 목록을 달라는데 언제까지 드릴 수 있을까요?"

계약 조건으로 목록 문서가 걸려 있어 기한이 계약 일정에 묶여 있다는 말입니다.

"고지 화면에 이 세 개가 빠져 있어요. 다음 배포에 넣어 주세요."

목록과 실제 고지 내용이 어긋난 것을 찾아 맞춰 달라는 요청입니다.

페이지덱은 그 계약을 겪고 나서 순서를 뒤집었습니다. 규원이 외부 자문을 받아 허용 목록을 한 장으로 정리했고, 태오가 빌드에 검사를 붙여 목록에 없는 라이선스가 들어오면 합치지 못하게 막았습니다. 지현은 그때 걸려 있던 카피레프트 코드 두 개를 바꾸는 작업을 다음 주기에 넣었고, 수아는 이후 기업 계약에서 목록을 먼저 보내는 것으로 순서를 바꿨습니다.

검사를 붙인 뒤로 달라진 것은 걸리는 시점입니다. 예전에는 팔고 있는 기능에서 발견돼 몇 주짜리 교체 작업이 됐지만, 이제는 합치기 전에 걸리므로 다른 라이브러리를 고르는 30분으로 끝납니다.

흔한 오해

공짜로 쓰는 것이니 조건도 없다고 읽는 경우가 가장 많습니다. 돈을 내지 않고 받았으니 그 뒤로는 자유롭다고 느끼기 쉽습니다. 공짜인 것은 값이고 조건은 따로 붙어 있습니다. 만든 사람 이름과 라이선스 원문을 남기라는 조건을 지키지 않으면 저작권을 침해한 상태가 되고, 이건 돈을 안 냈다는 문제가 아니라 허락 없이 남의 창작물을 쓴 문제로 다뤄집니다.

한 번 점검해 두면 끝이라고 보는 것도 흔합니다. 외부 소프트웨어 목록은 매주 바뀝니다. 새 기능을 붙이면서 라이브러리가 들어오고, 버전을 올리는 과정에서 만든 쪽이 라이선스를 바꾸는 일도 있습니다. 지난 분기에 통과한 목록으로 이번 분기를 설명하면, 정작 문제가 된 항목은 그 목록에 없던 것입니다.

같이 보면 좋은 페이지

  • 지식재산권

    이 점검이 어느 권리 체계 안에서 하는 일인지 먼저 봅니다

  • 오픈소스 라이선스

    점검 대상인 조건 자체를 읽으면 판정 기준이 잡힙니다

  • 정적 분석

    같은 자리에 붙는 자동 검사라 함께 설계하면 한 번에 붙습니다

마지막 업데이트 2026-09-16