오픈소스 라이선싱: 중급 개발자가 법적 문제를 피하기 위해 알아야 할 사항

발행: (2026년 1월 16일 오후 02:00 GMT+9)
5 min read
원문: Dev.to

Source: Dev.to

Permissive Licenses (The “Do Almost Anything” Bunch)

Examples: MIT, Apache 2.0, BSD

What they mean:
코드를 자체 프로젝트에 사용할 수 있습니다. 프로젝트가 독점적이고, 폐쇄형이며, 상당한 수익을 창출하더라도 가능합니다.

Your only obligation:
원본 저작권 및 라이선스 텍스트를 애플리케이션 문서(예: “감사의 말” 화면) 어딘가에 포함하십시오.


Copyleft Licenses (The “Viral” Bunch)

Examples: GPL v2, GPL v3, AGPL

What they mean:
GPL 라이선스가 적용된 라이브러리를 애플리케이션에 포함하면 전체 애플리케이션이 파생 작업으로 간주됩니다.

The consequence:
전체 애플리케이션의 소스 코드를 동일한 GPL 라이선스로 공개해야 합니다. 이 “바이럴” 효과는 기업이 독점 코드를 공개하도록 강제할 수 있습니다.

Example scenario

  1. 당신은 독점적인, 수백만 달러 규모의 알고리즘을 개발하고 있습니다.
  2. GitHub에서 GPL v3 라이선스가 적용된 작은 명령줄 파서 라이브러리를 발견합니다.
  3. 이를 사용하여 제품을 배포합니다.
  4. 경쟁자가 GPL 구성 요소를 발견하고 소송을 제기합니다.
  5. 법원은 제품 판매를 중단하거나 알고리즘의 전체 소스 코드를 무료로 공개하도록 요구할 수 있습니다.

이 실수는 기업에 치명적일 수 있습니다.


Affero GPL (AGPL)

Used by: MongoDB (historically), Grafana, and many “open core” tools.

What it means:
AGPL은 GPL과 유사하지만 네트워크 사용 조항을 추가합니다. 서버에서 AGPL 프로그램을 실행하고 사용자가 이를 이용할 경우(예: SaaS 제품), (수정된 경우) 소스 코드를 해당 사용자에게 제공해야 합니다.

The rule:

  • 수정하지 않은 AGPL 구성 요소만 사용한다면(예: 애플리케이션이 표준 MongoDB 데이터베이스와 통신), 일반적으로 문제 없습니다.
  • AGPL 코드를 수정한다면, 해당 수정 사항을 모든 사용자에게 공개해야 합니다.

Practical Steps for Mid‑Level Developers

Check before you install

npm install(또는 기타 패키지 매니저 명령) 실행 전에 몇 초 정도 시간을 내어:

  • 저장소를 방문합니다.
  • LICENSE 파일을 검토합니다.

Know your company’s policy

대부분의 성숙한 기술 기업은 ‘승인된’ 라이선스 목록을 유지합니다—보통 MIT, Apache, BSD. 그 외, 특히 GPL이나 AGPL은 법무팀의 승인을 받아야 합니다.

Use tooling

다음과 같은 도구를 사용해 CI/CD 파이프라인에서 라이선스 준수를 자동화하십시오:

  • Snyk
  • FOSSA
  • WhiteSource

이 스캐너들은 모든 의존성을 분석하고 고위험 라이선스를 표시하며, 문제 있는 코드가 main에 병합되는 것을 방지합니다.


Conclusion

오픈소스 라이선스를 이해하는 것은 OSS를 회피하는 것이 아니라 전문가가 되기 위한 것입니다. 목수가 못과 나사의 차이를 아는 것처럼, 개발자는 MIT와 GPL의 차이를 알아야 합니다. 이 지식을 숙달하는 것은 경력 성장의 중요한 이정표이며, 단순 코더가 아닌 신뢰받는 엔지니어가 되는 데 도움이 됩니다.

For more information, please refer to our blog.

Back to Blog

관련 글

더 보기 »