# 오픈소스 레지스탕스: 업무 시간에 오픈소스를 지키자 > Clean Markdown view of GeekNews topic #29509. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29509](https://news.hada.io/topic?id=29509) - GeekNews Markdown: [https://news.hada.io/topic/29509.md](https://news.hada.io/topic/29509.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-15T06:36:23+09:00 - Updated: 2026-05-15T06:36:23+09:00 - Original source: [ossresistance.com](https://ossresistance.com/) - Points: 1 - Comments: 1 ## Topic Body - **Open Source Resistance**는 기업이 의존하는 오픈소스 소프트웨어의 유지보수를 **업무 시간 내에 조용히, 전문적으로 수행**하자는 직접 행동 선언문(매니페스토) - 모든 기업이 오픈소스 없이는 사업을 운영할 수 없음에도, 메인테이너에게 **별도 허가나 기부 버튼, 금요일 오후 시간**을 구걸하게 만드는 구조를 거부 - 기존에도 **Open Source Pledge** (개발자 1인당 연 $2,000 지급 요청)나 **Open Source Friday**(매주 금요일 최소 2시간 기여) 같은 대안이 존재했지만 더 직접적인 실행을 내세움 - “시간 절도”라는 반론에는 회사가 이미 무료 OSS 보조금을 받아 왔고, 의존 OSS 유지보수는 **공유 인프라 작업**이라고 답변 가능 - 고용 계약서의 **IP 양도 조항**을 반드시 확인하고, 오픈소스 카브아웃을 서면으로 협상해야 함 --- ### 매니페스토: 이미 필요한 일을 고치는 데 허가를 구하지 말 것 - Open Source Resistance는 회사가 의존하는 **오픈소스 소프트웨어(OSS)** 유지보수를 야간·주말 취미로 밀어내지 말고, 조용하고 전문적으로 **업무 시간**에 수행하자는 직접 행동 제안 - 오픈소스 소프트웨어는 여가 시간의 "취미"가 아니며, 기업들은 매 시간 오픈소스에서 가치를 추출하면서도 메인테이너에게 **금요일 오후 한 번, 기부 버튼 하나, 전체 회의에서의 감사 인사** 정도만 제공 - 메인테이너는 기업 내부에서 회사가 이미 의존하는 OSS 코드에 대한 작업을 **서류 작성, 내부 프로그램, 관리자 승인 없이** 업무 시간에 수행해야 함 - 이는 새로운 아이디어가 아니라, 대부분의 오픈소스가 항상 이뤄져 온 방식을 **공개적으로 말하는 것** - 메인테이너들은 회의, 스프린트, 프로덕트 매니저의 허가를 기다리지 않고 인터넷을 유지해 왔음 ### 핵심 행동 원칙 - ## 자신을 보호할 것 - 고용 계약서를 확인하고, **기밀 정보는 회사 내에 유지**하며, 자신이 배포하는 오픈소스 IP의 소유권을 확보해야 함 - ## 작업을 수행할 것 - PR 리뷰, **의존성 업데이트**, 이미 OSS인 부분의 버그 수정을 실행 - ## 무모하지 말 것 - 업무 시간의 100%를 OSS에 쓰고 해고당한 뒤 남을 탓하는 행위 금지, **균형**이 핵심 ### 기존 대안들 - **[Open Source Pledge](https://opensourcepledge.com/)**: 기업에 메인테이너 지급 요청(개발자 1인당 연 US$2,000) - **[Open Source Friday](https://opensourcefriday.com/)**: 기업에 시간 기부 요청(매주 금요일 최소 2시간) - 고용주를 먼저 설득하는 **[정중한 경로](https://opensource.guide/getting-paid/)** 도 존재하며, 모두 긍정적이고 지원할 가치가 있음 - Open Source Resistance는 이 흐름의 다음 단계로, 의존성 체인 유지보수가 관리자가 명명하지 않더라도 **이미 업무의 일부**임을 선언 - 회사의 예산 배분은 통제 범위 밖이지만, **자신의 업무 시간 사용 방식**은 통제 가능 ### 예상 반론과 답변 - ## "시간 도둑질이다 / 주주에 대한 절도다" - 기업은 이미 매일 오픈소스 메인테이너로부터 가치를 추출하고 있으며, 주주들은 수십 년간 **무료 오픈소스 보조금**을 받아 왔음 - 고용주가 OSS에 의존한다면 이를 유지보수하는 것은 **공공재 인프라 작업**이지 절도가 아님 - ## "허가를 구해야 한다" - 허가 요청은 **권력 불균형**을 유지하는 행위 - 고용주가 이미 의존하는 인프라를 유지하는 데 관리자의 축복이 필요하지 않음 - ## "조용한 퇴직(quiet quitting)과 같다" - 조용한 퇴직은 업무량을 줄이지만, 이것은 인터넷이 구축된 **OSS 인프라를 생산**하는 행위 - 문제는 작업 자체가 아니라 기업이 이를 업무로 분류하기를 **거부**하는 것 - ## "좋은 고용주도 피해를 본다" - 좋은 고용주는 업무 시간 내 오픈소스 유지보수를 허용하고, 메인테이너에게 자금을 지원하거나 **Open Source Pledge에 참여**함으로써 이 문제를 회피 ### [Mike McQuaid](https://mikemcquaid.com/)의 경험 - Open Source Friday와 **GitHub Sponsors**의 공동 창시자이자, Homebrew 프로젝트 리더(2009년부터 메인테이너) - 어떤 직장에서도 Homebrew 같은 오픈소스 프로젝트 작업이 **주요 업무로 급여 지급된 적 없음** - 그럼에도 모든 고용주에서 이를 수행했으며, IP 계약을 협상해 합법화하고 업무 약속도 이행 - 자녀를 가진 이후 오픈소스 작업의 **90% 이상이 업무 시간에 수행**됨 - [Open Source Maintainers Owe You Nothing](https://mikemcquaid.com/open-source-maintainers-owe-you-nothing/)에서처럼, 어떤 회사의 비즈니스 모델이 자신의 코드에 의존한다는 이유로 누구도 유지보수자의 무급 야간·주말·가족 시간을 요구할 권리는 없다고 봄 ### 주의사항 및 법적 고지 - ## 법률 조언이 아님 - 이 내용은 **법률 조언**이 아니며, 계약·고용주·이민 신분·라이선스 의무·개별 상황에 대한 조언이 아니라고 명시함 - 위험이 크다면 행동하기 전에 자격 있는 사람과 상담해야 함 - [대부분의 오픈소스 라이선스](https://opensource.org/license/mit)처럼 어떠한 보증도 없으며, “있는 그대로” 제공됨 - ## 계약, 정책, 소유권 - 고용계약, 핸드북 정책, 발명 양도 조항은 고용 중 생성된 작업, 고용주 장비에서 만든 작업, 담당 업무 범위 안의 작업에 대해 권리를 주장할 수 있음 - 일부 주에서는 개인 시간과 개인 장비로 만든 작업에 대한 이런 권리 주장을 제한하지만, 세부사항이 중요함 - 실행하기 전에 **고용계약**을 읽고, 공개하려는 오픈소스 IP를 고용주가 소유하지 않는지 확인해야 함 - 기기, 네트워크, 계정이 소유권 위험을 바꾼다면 자신의 것을 사용해야 함 - ## IP 계약 협상 - IP 양도는 종종 협상 가능하며, 채용 제안을 받을 때 서명 전에 오픈소스 예외 조항을 **서면**으로 요청하라고 권함 - 먼저 [직원 IP 계약](https://opensource.guide/legal/)을 읽어 어떤 부분에 반대해야 할지 알아야 함 - Mike McQuaid는 거의 모든 고용주와 표준 계약에서 벗어난 변경을 협상했으며, 대부분 예상보다 훨씬 적게 반발했다고 밝힘 - GitHub의 [Balanced Employee IP Agreement](https://github.com/github/balanced-employee-ip-agreement)를 잠재 고용주에게 보여줄 수 있음 - 이 계약은 CC0로 오픈소스화됐고, 대형 상장사가 실제 사용했으며, 고용주는 비용을 지불한 것을 보유하고 직원은 사업과 경쟁하지 않는 오픈소스 작업을 보유하도록 설계됨 - ## 기밀 유지 및 보안 - 비공개 레포지토리, 자격 증명, 인시던트, 고객 데이터, 로드맵, **미공개 취약점**, 내부 논의를 공개해서는 안 됨 - 보안 통제를 우회하거나, 허용되지 않은 접근 권한을 사용해서는 안 됨 - 직접 행동은 회사 기밀 정보를 공개할 구실이 아니라, **공개 작업을 공개로 유지**하고 상업적 비밀과 명확히 분리하는 것 - ## 조용함은 부주의를 의미하지 않음 - 정책, 계약, 고객 의무, 안전 규칙이 리스크를 변경할 때는 **자체 판단**이 필요 - 자신의 장비, 계정, 네트워크에서 작업해야 할 수 있음 - 회사에서 "도둑질"하는 것이 아니라, 회사가 오픈소스에서 가져가는 것과 자신이 줄 수 있는 것의 **균형**을 맞추는 것 - 동료보다 낮은 인사평가를 받을 수 있으나, 지속 가능한 B 등급이 내일이면 해고할 수 있는 회사에서 **A 등급을 위해 삶을 소진**하는 것보다 건강함 - ## 적용 한계 - 시간이 특정 고객, 보조금, 정부기관, 방위 프로젝트, 규제 환경에 청구되는 경우 이 주장은 가장 약해짐 - 불이익을 감당할 영향력이 없는 **주니어 또는 불안정한 엔지니어**에게도 가장 약함 - 고용주가 이미 사용하는 공개 의존성을 고치는 **시니어 유지보수자**에게 가장 강함 - 가장 깔끔한 형태는 “업무 시간에 하고 싶은 일을 하라”가 아니라, **오픈소스 유지보수를 엔지니어링 업무의 일부로 다루는 것**임 - 이미 유지보수하는 프로젝트를 유지보수하고, 업무가 닿는 공유 도구를 개선하며, 관련 없는 일·독점 코드·실제 약속을 놓치게 만드는 일은 피해야 함 ### 출처와 프로젝트 - [Mike McQuaid](https://mikemcquaid.com/)가 만들었으며, 소스는 [GitHub](https://github.com/MikeMcQuaid/open-source-resistance)에 공개돼 있음 ## Comments ### Comment 57492 - Author: neo - Created: 2026-05-15T06:36:23+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48123015) - 회사들이 특정 오픈소스 프로젝트에 기여하는 것에 대해 포괄적 허가를 주는 경우가 대체로 많았음 표현 방식이 중요함. “기분 좋아지려고 자선 활동 좀 해도 될까요?”가 아니라, “이 분야 전문가들에게 **무료로 엄격한 리뷰**를 받고, 수정 사항을 업스트림 오픈소스 프로젝트에 반영해서 회사의 향후 유지보수 비용을 없애도 될까요?”라고 말해야 함 실제로 그게 본질이고, 그렇게 말했을 때 거절한 고용주는 없었음. 회사 이익에 완전히 부합하니 그걸 보이게 도와주면 됨 - 예전 직장에서 해고된 게 여러모로 아쉬운데, 큰 이유 중 하나는 내가 **Kafka Streams** 라이브러리에 만든 꽤 큰 변경을 오픈소스로 공개할지 논의 중이었기 때문임 API는 대부분 호환되게 유지하면서 많은 부분을 다시 썼고, 필요하면 백프레셔 의미론을 쓸 수 있는 비차단 입출력을 강조하는 방향이었음. 상태 저장소와 차단/비차단 입출력을 섞어 쓰면서도 꽤 성능을 유지할 수 있어 흥미로운 것들을 가능하게 했고, 눈에 잘 안 띄는 여러 지점에서 성능을 끌어낸 프로젝트라 특히 자랑스러웠음 GitHub에 공개하거나 업스트림 Kafka Streams 프로젝트에 PR을 보내게 해달라고 밀어붙였지만, 그 전에 정리해고가 있었고 이후에는 그 일을 밀어줄 **챔피언**이 없어 독점 코드로 묶여 버림 아직도 처음부터 다시 만들어 자유 오픈소스로 공개할까 생각함. 시간이 꽤 지났으니 다시 작성해 공개해도 문제는 없을 것 같고, 특허 같은 것도 없었으며, Vert.x 의존성을 없애는 등 바꾸고 싶은 것도 있음. 언젠가 일주일쯤 쉬게 되면 해볼지도 모름 - 이런 걸 허용해주던 곳에서 일하던 때가 그리움 어떤 회사들은 단지 법무 검토 절차만으로도 꼬여버림 한 번은 어떤 프로젝트에 패치를 보내도 되는지 허가를 요청했는데, 흥미로운 이메일 스레드가 이어졌음. 결국 질문은 하나였음: 고객에게 청구되는 시간에, 납품 제품의 버그를 고치기 위해 작성한 패치이고, 패치된 라이브러리를 다시 컴파일해 소스 코드와 함께 납품해야 하며, 계약서에는 제품과 관련된 모든 작업물과 지식재산권이 고객에게 이전된다고 되어 있다면, 그 패치를 **퍼블릭 도메인**으로 공개할 권한이 우리에게 있는가? 법무팀은 답하고 싶어 하지 않았음 - 대체로 좋은 접근이고, 일을 전문적으로 프레이밍하는 훌륭한 예시라고 봄. 다만 문제의 핵심을 해결하진 못함. 특히 공학 중심 회사의 리더십이라면 이런 이점을 즉시 이해해야 하는데 그렇지 않다면 문제임 어떤 방식으로 접근할 수 있는지는 고용주 운도 크게 좌우함 - “좋아요, 이걸 **컴플라이언스 팀**에 한번 돌려볼게요. 지식재산권 침해가 없는지 확인만 하려고요. 정확히 어느 저장소와 이슈인가요?” - “그리고 배포하는 오픈소스 지식재산권을 확실히 소유하라”는 말에 대해, 내가 일해본 관할권에서는 근무 시간에 작성해 배포하는 코드는 내가 아니라 고용주 소유였음 근무 시간에 기여할지 혼자 결정할 수 없고, 오픈소스 코드 작업을 하려면 정식 합의가 필요했음. 요청할 때마다 법무 부서를 거치는 데 몇 달씩 걸려서 결국 포기하거나, 그 사이 다른 기여자가 PR을 이미 올려서 더 이상 요청하지 않게 됐음 - 아마 “자기 것이 아닌 작업물을 마음대로 기부하려 하면 안 된다”는 뜻이었을 것 같음. 아래에 관련 섹션이 따로 있지만, 위쪽 글머리표만 보면 혼란스러움 경험 많은 개발자에겐 당연한 내용이지만, 몇몇 회사의 주니어 개발자들에게는 실제 문제가 되었음. 회사가 내부 프로젝트에서 멋진 걸 하고 있으면, 그걸 어떤 오픈소스 프로젝트에 기여하면 좋겠다고 생각하면서도, 비공개 코드 지식을 이용해 실질적으로 유사한 코드를 제출하거나 때로는 복사해 붙여넣는 문제가 생긴다는 점을 고려하지 않음 - 직접 조사해본 건 아니지만, 독일에서는 기본적으로 근무 시간에 만든 모든 소스 코드를 고용주가 소유한다고 알고 있었음 IT 중심이 아닌 고용주 대부분은 **오픈소스**가 무엇인지, 어떻게 작동하는지도 이해하지 못할 것임. 그래서 많은 사람에게 허가를 받는 건 절망적일 수 있음 링크된 사이트는 우선 고용주를 대상으로 오픈소스의 이점을 설명하고, **고용주용 법적 가이드라인**을 옹호하는 데 초점을 맞추는 편이 좋겠음 - 회사가 프로덕션에 들어가는 부분을 제외하고는 허용적 라이선스 코드로 공개하지 않는다면 그런 직장은 안 갈 것 같음. 나에겐 의욕을 꺾는 일이고 정신적으로 한계까지 몰릴 듯함. 차라리 가난한 편을 택하겠음 - 좋은 생각이고, 심지어 훌륭한 생각이지만, 이를 **저항**으로 포지셔닝하는 게 좋은지는 모르겠음 직무의 목적은 보통 어떤 목표를 달성하는 것임. 그 목표를 어떻게 달성할지는 전문가인 개발자가 결정할 수 있음. 그 결정에 오픈소스 소프트웨어가 포함된다면, 그것을 유지보수하는 일도 그 결정의 일부여야 함 급진적인 일이 아니라, 업무에 의존하는 것들의 미래 안정성과 유지보수성을 지키며 자기 일을 하는 것일 뿐임 - 이것은 그냥 **좋은 비즈니스 감각**이기도 함. 오픈소스를 통한 협업을 장려하는 회사는 자기 사업을 먹여 살리는 생태계를 키우는 셈임 - 말한 내용에는 모두 동의하지만, 요즘 대부분의 기술 회사 현실은 내가 겪기엔 다름. 강제되지 않는 한 자기들 인프라와 라이브러리 유지보수에도 시간을 투자하지 않는데, 하물며 오픈소스는 더 어려움 지표 게임용 쓸모없는 기능, **엔시티피케이션**, 다크 패턴, 악성코드에 가까운 유행 통합 같은 것이 기반 인프라나 라이브러리 투자보다 우선됨 - 동의함. 이런 식의 묘사는 누군가가 소셜 미디어에서 더 많은 관심을 끌려는 것처럼 보이게 함. 모든 것이 과장되어야 하는 지점까지 온 게 안타까움 - 일반론으로는 전적으로 동의하지만, 실제로 해내기는 까다롭다고 봄. 변호사는 아니지만, 일반적으로 고용주가 지식재산권을 소유하므로 오픈소스로 공개하려면 명시적 허가가 필요하다고 알고 있음 그리고 그 허가를 받는 과정은 종종 어렵고, 끝없는 절차와 법무 부서를 거쳐야 함 “미국, 영국 및 여러 관할권에서는 직원이 직무의 일부로 저작물을 만들면 고용주가 법적 저자 또는 최초 저작권자로 간주된다” [https://en.wikipedia.org/wiki/Work_for_hire]() 그래도 오픈소스 작업, 즉 유지보수와 개발은 기부를 구걸하는 자원봉사자가 아니라 **급여를 받는 전문가**가 해야 한다고 생각함. 핵심 질문은 그걸 어떻게 실현할지, 회사들이 오픈소스 기여를 개별 협상이 필요한 예외가 아니라 표준 관행으로 받아들이게 만들 방법임 - 설명한 문제들은 “실무상의 문제”라기보다 이론적 문제에 가까움 실제로는 그냥 하면 됨. 컴퓨터 안에 `git push`를 막는 서브루틴은 없음. 실제로 고용주는 고용계약서에 온갖 내용을 써넣음. 모든 방향에서 책임을 피하려고 가능한 한 많이 적어둠. 그들이 마음대로 적을 수 있다면, 왜 우리는 그냥 할 수 없나? 아무것도 중요하지 않음 실제로 이런 기술적 이유로 지식재산권에 도전받은 오픈소스 프로젝트는 거의 0에 가까움 - 그 작업이 직무와 관련되어 있다면 고용주가 지식재산권을 가진다는 말은 맞음 직무와 관련이 없다면 주마다 다름. 많은 주에는 고용주가 자기 지식재산으로 주장할 수 있는 범위에 제한이 있음. 일반 계약서는 문구를 넓게 잡아 모든 것을 주장하려 하지만, 법은 종종 고용주와 관련 없는 자유 시간 작업까지 회사가 가져갈 수 없다고 함 근무 시간에 하거나 회사 노트북을 쓰면 회사가 권리를 주장할 여지가 생김. 대부분 회사는 신경 쓰지 않겠지만, 분쟁이 생겼을 때 깔끔하게 유지하려면 방심하면 안 됨 **개인 시간**, **개인 장비**로 작업하고, 고용된 업무나 회사에서 접한 것과 겹치지 않게 해야 함 - 변호사는 아니지만, 동료에게 실행해보라고 복사본을 줬다면 그 자체로 오픈소스 라이선스를 사용한 것 아닌가 싶음. 그 동료는 라이선스가 부여한 법적 권리를 갖게 되고, 변경 사항을 재배포할 권리도 갖는 것 아닌가? 변경 사항을 업스트림에 올리는 것이 유지보수를 보장하는 가장 좋은 방법인데, 이 모든 게 매우 우스워 보임. 내부 독점 포크를 유지하는 데 따르는 법적 불확실성도 마찬가지임 - 글은 **저항이 가장 적은 경로**를 따르라고 제안하는 것 같음. 회사 시간에 작업하고, 큰 파장을 만들지 않는 것임. 들키면 용서를 구하면 됨. 회사 입장에서는 용서하는 게 쉬운 길임. 변호사를 끌어들이면 비용이 매우 커지고, 홍보 악몽이 될 수도 있음 - 현재 프로그래밍 상태가 보여준 게 있다면, 지식재산권과 저작권법은 더 이상 존재하지 않는다는 것임 - 꽤 큰 회사에서 일함. 우리 회사의 **오픈소스 정책**은 대략 “먼저 매니저에게 물어보고, 회사 이름으로 하지 말고, 기밀 정보를 공개하지 말라”로 요약됨 문제가 된 적은 없고, 큰 틀에서 완전히 합리적이라고 느낌 - 근무 시간에 제3자 오픈소스 프로젝트에 버그 수정 같은 기여를 하는 건 문제없다고 보지만, **자기 오픈소스**는 어떻게 처리해야 할지 모르겠음 예를 들어 개인적으로 만든 작은 라이브러리가 있고, 그걸 회사에서 쓰다가 근무 시간에 버그를 발견했다고 하자. 그 근무 시간에 기여하면 회색지대일 것 같음 면접 중에 이런 걸 협상해본 사람이 있나? 어떻게 했는지 궁금함 - 실제로 이걸 신경 쓰는 회사에서 일해본 적은 없음. 그냥 필요한 일을 했음. “제대로” 하려면 어떻게 해야 하냐고 물어봤을 때도 답을 받은 적이 없었음 - 대기업에서 일할 때는 대체로, 회사 코드베이스에 직접 코드를 쓰는 것 외의 작업 요청은 근거를 제시해도 직속 매니저가 “자유 시간에 하라”고 답했음 이익 지향 환경에서는 즉각적인 가치만 추구할 만한 것으로 여겨짐. 태도는 꽤 **기생적**이고, 위에서부터 내려오는 더 높은 효율과 지표 경쟁이 그렇게 만듦 - 업무 문제를 해결하려고 포크해서 고친 뒤, 그 결과를 업스트림에 PR로 보낸 적이 분명히 있음 오픈소스를 사용하고 접근할 수 있다는 점에서 좋은 부분 중 하나임. `package.json`과 `cargo.toml`에서 **git**이 거의 일급 선택지인 이유도 여기에 있음. 변경이 업스트림되기 전까지 포크를 직접 가리킬 수 있기 때문임 - 시니어가 되면 면접 과정에서 “우리에게 질문 있나요?”라는 단계가 왔을 때, “이 회사가 의존하는 **오픈소스 프로젝트**에 제 시간 일부를 기여하는 것에 대해 어떤 입장인가요?”라고 묻는다 답을 보고 계속 남을지 결정하면 됨