남의 코드 가져다 쓸 때
공개된 코드는 값이 0원일 뿐이고 조건은 0이 아니에요. 이름만 적어 주면 되는 조건도 있고, 내 코드까지 같이 공개하게 만드는 조건도 있어요. 갈리는 지점은 정해져 있어요.
쉽게 말하면
상인회 공용 창고를 떠올려 보세요. 문이 늘 열려 있고 누구나 부품을 꺼내 씁니다. 대신 선반마다 종이가 한 장 붙어 있어요. 어떤 선반은 "가져가서 쓰고, 여기서 가져갔다고 적어 두세요" 한 줄이 전부예요. 어떤 선반은 "이 부품을 넣어 만든 물건은 설계도까지 같이 공개하세요" 라고 적혀 있어요. 문이 열려 있다는 것과 조건이 없다는 것은 다른 말이에요. 종이를 안 읽고 집어 오는 게 사고의 시작이에요.
이 종이가 라이선스예요. 코드를 만든 사람이 "이런 조건이면 써도 좋다"고 미리 써 둔 허락서예요. 돈을 안 받는 대신 조건을 걸어 둔 거라, 조건을 안 지키면 값을 안 낸 것과 같은 상태가 돼요.
이름이 없으면 확인을 안 한 거예요. 나중에 세려면 코드를 처음부터 다시 뒤져야 해요.
이름이 있으면 판단이 돼요. AGPL 한 줄이 어디에 쓰였는지 오늘 물어볼 수 있어요.
조건은 몇 갈래로 갈려요
라이선스 이름은 수백 종이 있지만, 사장님이 실제로 마주치는 갈래는 몇 개뿐이에요. 이름을 다 외울 필요는 없어요. 어느 갈래인지만 알면 판단이 서요.
| 갈래 | 대표 이름 | 내가 지킬 것 | 내 코드도 공개? |
|---|---|---|---|
| 느슨한 쪽 | MIT, BSD, Apache 2.0 | 저작권 표기와 라이선스 전문을 결과물에 함께 싣기. Apache 2.0 은 고친 곳을 표시하는 조항이 더 붙어요 | 없어요. 그래서 사업에서 제일 많이 써요 |
| 옮겨 붙는 쪽 | GPL 2.0, GPL 3.0 | 이 코드를 넣은 프로그램을 남에게 건네주면, 그 프로그램 전체를 같은 조건으로 내줘야 해요 | 네. 이게 문제가 되는 갈래예요 |
| 서비스까지 미치는 쪽 | AGPL 3.0 | 파일로 건네주지 않고 웹서비스로만 제공해도, 그 서비스를 쓰는 사람에게 소스를 제공해야 해요 | 네. 웹서비스 사업에는 가장 무서운 갈래예요 |
| 선을 그어 둔 절충 | LGPL, MPL 2.0 | LGPL 은 그 부품을 갈아 끼울 수 있게 붙였다면 내 코드는 안 열어도 돼요. MPL 은 내가 고친 그 파일만 같은 조건으로 유지해요 | 부분만요 |
| 열려 있지만 오픈소스는 아닌 쪽 | SSPL, BUSL | 소스는 보이는데 "이걸 그대로 서비스로 팔지 말라" 같은 제한이 붙어요. BUSL 은 만든 회사가 정해 둔 날짜가 지나면 열린 조건으로 바뀌는 구조예요 | 다른 종류의 제약이에요 |
| 소프트웨어가 아닌 것 | CC BY, CC BY-SA, CC BY-NC | 사진·글·아이콘에 붙는 조건이에요. NC 는 비상업 전용이라 사업에는 못 써요 | SA 는 같은 조건 유지 |
| 종이가 없는 선반 | LICENSE 파일 없음 | 허락이 없다는 뜻이에요. 공개돼 있다고 해서 써도 된다는 뜻이 아니에요 | 쓰면 안 돼요 |
이름을 처음 봤을 때
낯선 이름이 나오면 승인된 오픈소스 목록(opensource.org)과 국제 라이선스 목록(SPDX)에서 그 이름을 찾아보세요. 둘 다 없으면 원문을 읽어야 하고, 원문이 애매하면 쓰지 않는 게 답이에요. 애매한 걸 안고 가는 비용이 대체품을 찾는 비용보다 늘 커요.
왜 남의 조건이 내 코드까지 미치나
여기가 이 문서의 핵심이에요. 원리를 알면 표를 안 봐도 판단이 돼요.
- 1코드는 만들어진 순간 저작권이 생겨요. 공개했다고 권리가 없어지지 않아요.
- 2라이선스는 권리를 포기하는 문서가 아니라 조건부 허락서예요. "이 조건이면 허락한다"는 문장이에요.
- 3조건을 어기면 허락이 사라져요. 남는 건 허락 없이 남의 저작물을 쓴 상태예요.
- 4그래서 옮겨 붙는 쪽 라이선스는 "내 부품을 쓴 결과물도 같은 조건으로 나눠라"를 조건으로 걸 수 있어요. 그 조건을 지키기 싫으면 부품을 쓰지 않으면 돼요. 강제가 아니라 거래예요.
- 5정리하면 이건 전염이 아니라 계약 구조예요. 옆 파일이 자동으로 물드는 게 아니라, 하나로 합쳐진 하나의 결과물을 내보낼 때 그 결과물에 조건이 따라붙어요.
그래서 다툼의 실제 쟁점은 늘 하나예요. 어디까지가 하나의 결과물인가. 갈래마다 이 선이 다르고, LGPL 과 MPL 은 그 선을 문서에 못 박아 둔 절충안이에요.
무너지는 지점은 정해져 있어요
조건은 코드를 넣는 날 발동하지 않아요. 특정 행동을 하는 날 발동해요. 그 행동 목록이 짧아서, 미리 알면 대비가 돼요.
| 이 일을 하는 순간 | 무엇이 발동하나 | 지금 확인할 것 |
|---|---|---|
| 웹사이트를 공개한다 | 화면을 그리는 코드는 손님 컴퓨터로 그대로 내려가요. 이게 건네주는 행동이에요. 옮겨 붙는 쪽이 화면 코드에 섞였다면 이 순간부터 의무가 생겨요 | 손님에게 내려가는 코드와 서버에만 있는 코드를 갈라서 보기 |
| 서버에만 두고 웹으로만 서비스한다 | GPL 계열은 대개 잠잠해요. 건네준 게 아니니까요. AGPL 은 이때도 발동해요 | 목록에 AGPL 이 한 줄이라도 있는지 |
| 앱 스토어에 올린다 | 스토어 약관과 GPL 조건이 충돌해 앱이 내려간 사례가 알려져 있어요. 심사에서 막히거나 등록 후 문제가 돼요 | 앱으로 낼 계획이면 GPL 계열은 시작부터 배제 |
| 무료였던 걸 유료로 바꾼다 | 비상업(NC) 조건은 그날부터 위반이에요. 코드는 그대로인데 쓰임새가 바뀌어서 걸려요 | 요금제를 붙이기 전에 NC 가 섞였는지 |
| 투자나 매각 실사를 받는다 | 검사 도구로 전체 목록을 자동으로 뽑아요. AGPL 한 줄이 발견되면 조건 조정이나 재작업 요구가 붙고, 거래 일정이 밀려요 | 실사에서 처음 세지 말고 지금 세기 |
| 회사 안에서만 쓴다 | 건네준 게 아니라 대부분 조건이 잠잠해요. 다만 협력사나 관계사에 넘기는 것은 건네준 것으로 볼 수 있어요 | "우리끼리"의 범위가 어디까지인지 |
손으로 세는 건 불가능해요
직접 고른 부품이 열 개라도, 그 열 개가 데려오는 부품이 수백 개가 돼요. 부품이 또 부품을 쓰기 때문이에요. 그래서 목록은 눈으로 세지 않고 도구로 뽑아요. 정확한 개수는 내 프로젝트에서 뽑아 봐야 알아요. 사람이 할 일은 그 목록에서 옮겨 붙는 쪽과 NC 를 골라내는 것뿐이에요.
쓰면 안 되는 경우
쓰는 법보다 이게 더 중요해요. 아래는 검토 없이 그냥 안 하는 쪽이 싼 경우들이에요.
- 1유료로 팔 제품의 심장에 GPL·AGPL 계열을 넣지 않아요. 곁가지라면 조건을 지키며 쓸 수 있지만, 심장에 들어간 건 나중에 빼는 게 아니라 다시 만드는 일이 돼요.
- 2비상업(NC)은 사업에서 아예 후보에서 빼요. 지금 무료로 운영해도 사업 홍보 목적이면 다툼의 여지가 있고, 언젠가 돈을 받으면 그날부터 확실한 위반이에요.
- 3LICENSE 파일이 없는 저장소는 쓰지 않아요. 별이 많고 유명해도 종이가 없으면 허락이 없어요. 정말 필요하면 만든 사람에게 직접 물어보고 답을 문서로 남겨요.
- 4라이선스 전문을 지우거나 만든 사람 이름을 바꾸지 않아요. 조건을 없애는 행동이 아니라 위반을 만드는 행동이에요. 표기를 유지하는 건 대부분 조건 중 가장 쉬운 항목이에요.
- 5AI가 짜 준 코드도 그대로 믿지 않아요. 유명한 공개 코드가 통째로 들어오는 경우가 있어요. 낯설게 잘 짜인 큰 덩어리가 나오면 출처를 물어보고, 핵심 부품은 사람이 한 번 확인해요.
- 6애매한 상태로 손님에게 내보내지 않아요. 한 번 내려간 코드는 회수할 수 없어서, 뒤늦게 고치면 이미 나간 것에 대한 정리가 따로 필요해요.
실제로 겪는 장면
장면 1 · 외주 개발자가 말했다
“오픈소스 쓰면 기간이 반으로 줄어요. 라이선스는 문제없습니다.”
맞는 말이고, 실제로 안 쓰는 게 더 위험해요. 다만 "문제없다"는 확인 가능한 형태로 받아야 해요. 어떤 것을 썼고 각각 라이선스 이름이 무엇인지 목록으로 적어 달라고 하세요. 이름을 적지 못하면 확인을 안 한 거예요. 이 요청은 개발 기간을 늘리지 않아요. 도구로 몇 분에 뽑히는 목록이에요.
장면 2 · 투자 실사 담당자가 요구했다
“쓰신 오픈소스 목록 주세요. AGPL 있으면 조건 조정하고 넘어가야 합니다.”
실사에서 처음 세면 늦어요. 개발을 시작할 때 목록을 만들어 두는 비용은 거의 0인데, 다 만든 뒤에 바꾸는 비용은 재작업이에요. 순서를 바꾸는 것만으로 아끼는 돈이라, 이 문서에서 가장 실용적인 한 줄이에요.
장면 3 · 권리자 쪽에서 메일이 왔다
“귀사 서비스가 해당 라이브러리를 사용하면서 저작권 표기와 라이선스 전문을 포함하지 않았습니다. 조치를 요청합니다.”
첫 연락은 대개 소송이 아니라 시정 요구예요. 이 사례처럼 표기를 빠뜨린 것뿐이면 고지 화면을 만들어 넣는 것으로 끝나는 경우가 많아요. 사고를 만드는 건 위반 자체보다 무시예요. 답을 안 하면 요구 수준이 올라가요.
남에게 맡길 때
외주에 맡기든 직원이 만들든, 나중에 책임은 사장님 이름으로 남아요. 그래서 계약 단계에서 요구할 것과 납품 때 확인할 것을 나눠 두면 편해요.
| 발주·계약 때 요구할 것 | 납품 때 확인할 것 |
|---|---|
| 쓴 남의 코드 목록(이름과 라이선스가 적힌 부품 명세서)을 납품물에 포함 | 목록 파일이 실제로 있고, 코드에 든 것과 개수가 대충이라도 맞나 |
| GPL·AGPL 계열은 사전 승인 없이 쓰지 않는다는 조항 | 목록에 그 계열이 있나. 있다면 심장인가 곁가지인가 |
| 라이선스 고지 화면(또는 페이지) 포함 | 그 화면이 실제로 열리고, 목록이 비어 있지 않나 |
| 원본 LICENSE·NOTICE 파일을 지우지 않고 유지 | 파일이 남아 있나. 지웠다가 나중에 복구하는 게 더 번거로워요 |
| 제3자 권리 침해가 없다는 보증과, 문제가 생겼을 때의 대응 책임 | 말이 아니라 계약서 문장으로 남았나 |
| 폰트·아이콘·사진은 코드와 별도 목록으로 | 시안에만 유료 글꼴이 쓰이고 라이선스는 안 산 상태가 아닌지 |
내 결과물에서 직접 확인하는 게 정확해요
말로 듣는 것보다 내려받은 코드 안을 보는 게 정확해요. 바이브캠퍼스에서 만든 것도 내려받아 다른 곳으로 옮길 수 있으니, 무엇이 섞여 있는지는 그 폴더 안에서 확인하면 돼요.
자주 묻는 것
- Q. 오픈소스는 공짜인 줄 알았어요
- 돈은 대개 안 내요. 대가가 조건 지키기예요. 값이 0원인 것과 의무가 0인 것은 다른 말이에요. 그리고 실제로 가장 많이 쓰이는 갈래는 조건이 아주 가벼워요.
- Q. 그럼 결국 대부분은 표기만 하면 되는 건가요?
- 네. 사업에서 실제로 쓰는 것들 상당수가 저작권 표기와 라이선스 전문 동봉이 조건의 전부예요. 그래서 고지 화면 하나를 만들어 두는 게 가장 값싼 대비예요. 한 번 만들면 계속 쓰니까요.
- Q. 내 코드를 공개하게 되면 남이 베끼는 거잖아요
- 공개 의무가 있는 갈래를 골랐을 때만 생기는 일이에요. 안 고르면 안 생겨요. 그래서 무엇을 쓸지 고르는 시점이 유일하게 값싼 결정 지점이에요.
- Q. 이미 넣어버렸어요. 어떻게 하나요?
- 순서가 있어요. 어디에 얼마나 들어갔는지 확인 → 대체품이 있는지 → 조건을 지키면서 갈 수 있는지 → 만든 쪽이 유료 상업 라이선스를 따로 파는지. 마지막 방법이 의외로 흔해요. 같은 코드를 조건 없이 쓰게 해 주는 유료 라이선스를 파는 프로젝트가 많아요.
- Q. 회사 안에서만 쓰면 안전한가요?
- 건네주는 행동이 아니라 대부분 잠잠해요. 다만 관계사나 협력사에 넘기는 것, 그리고 웹으로 외부에 서비스하는 것은 다르게 볼 수 있어요. AGPL 은 웹 제공만으로도 발동해요.
- Q. 위반하면 얼마를 물어야 하나요?
- 여기서 단정하지 않아요. 사안마다 다르고 나라마다 달라요. 실제로 요구를 받았다면 한국저작권위원회 상담 창구나 저작권·IT 계약 경험이 있는 변호사에게 확인하세요. 확실한 건 하나예요. 초기 대응으로 끝나는 경우가 압도적으로 많아요.
확인해 보세요
내 서버에서만 돌리고 손님에게는 웹으로만 보여줘요. 소스를 내줘야 하는 쪽은?
하나 더
무료로 운영해 온 서비스에 유료 요금제를 붙이려고 해요. 코드에 비상업(NC) 조건이 하나 섞여 있어요.
직접 해보기
내 결과물 안에 무엇이 섞였는지 보세요
스튜디오에서 만든 결과물은 내려받아 다른 곳으로 옮길 수 있어요. 내려받은 폴더에서 LICENSE 나 license 라는 이름을 찾아보세요. 하나도 없다면 아직 남의 코드가 안 섞였다는 뜻일 수도 있고, 목록을 아직 안 만든 상태일 수도 있어요. 어느 쪽인지 아는 것이 시작점이에요.
스튜디오 열기더 깊이 (안 읽어도 괜찮아요)
"전염"이라는 말이 오해를 만들어요 · 옆에 있는 파일까지 자동으로 물드는 게 아니에요. 하나로 합쳐진 하나의 결과물을 내보낼 때, 그 결과물 전체가 같은 조건으로 나가야 한다는 뜻이에요. 그래서 실제 쟁점은 늘 "어디까지가 하나인가"예요. 부품을 갈아 끼울 수 있게 느슨하게 붙였는지, 아예 한 몸으로 녹여 넣었는지에 따라 답이 달라져요. 개발자에게 물어볼 정확한 질문은 "이거 어떻게 붙였어요"예요.
비유가 어디부터 다른가 · 공용 창고 비유는 "조건이 붙는다"까지만 맞아요. 창고에서 빌린 물건은 반납하면 끝인데, 코드 조건은 이미 내보낸 결과물에 계속 붙어 있어요. 한 번 손님 컴퓨터로 내려간 코드는 회수할 수 없거든요. 그래서 뒤늦게 고칠 때는 앞으로 나갈 것을 고치는 일과 이미 나간 것을 정리하는 일이 따로 생겨요.
고지 화면은 한 번 만들면 자산이에요 · 설정 안쪽에 오픈소스 라이선스 목록이 들어 있는 앱을 본 적 있을 거예요. 그게 이 문서의 결론이에요. 목록을 도구로 뽑아 한 화면에 넣어 두면 느슨한 쪽 조건은 사실상 전부 충족돼요. 앱을 스토어에 낼 때도 이 화면을 요구받는 경우가 많아서, 미리 만들어 두면 두 번 일하지 않아요.
확인처 · 라이선스 이름 확인은 opensource.org 승인 목록과 SPDX 라이선스 목록. 조건 원문은 각 저장소의 LICENSE 파일. 국내 상담은 한국저작권위원회. 계약 조항과 실제 분쟁은 저작권·IT 계약 경험이 있는 변호사예요. 라이선스 해석을 블로그 요약으로 끝내지 않는 게 이 주제의 유일한 안전장치예요.
이것만 기억하세요
- ·공개된 코드는 값이 0원일 뿐이고 조건은 0이 아니에요
- ·느슨한 쪽은 표기만, 옮겨 붙는 쪽은 내 코드까지 공개하게 만들어요
- ·조건은 넣는 날이 아니라 내보내는 날 발동해요. AGPL 은 웹 제공만으로도요
- ·유료로 팔 제품의 심장과 비상업(NC)은 처음부터 후보에서 빼요
- ·맡길 때는 부품 명세서를 요구하고, 납품 때 고지 화면이 열리는지 확인해요