작은 npm 패키지 하나를 관리한다. 무료고, 광고도 없고, 아무도 돈을 안 준다. 지난달에 나는 긴 EU 규정을 붙들고 앉아, 이게 그 패키지의 보안에 대해 나를 법적으로 책임지게 만드는지 알아내려 하고 있었다. 사이드 프로젝트 하나 하다가 도달하기엔 이상한 지점이고, 그 답이 뻔하지 않다는 사실이 바로 사이버 복원력법(Cyber Resilience Act) 이야기의 전부다.
CRA는 2024년 12월 10일에 발효됐다. 대부분은 2027년 12월 11일, 메인 의무가 떨어질 때까지 물지 않는다 — 근데 첫 진짜 데드라인은 사람들이 생각하는 것보다 이르다. 2026년 9월 11일부터, “디지털 요소를 가진 제품”의 제조사는 실제 악용 중인 취약점과 심각한 사고를 자국 CSIRT와 ENISA에 신고해야 한다: 24시간 안에 조기 경보, 72시간 안에 정식 통지, 수정 후 14일 안에 최종 보고. 먼 데드라인이 아니다. 내년이다.
그래서 유럽의 모든 메인테이너가 조용히 던지는 질문은 이거다: 내가 제조사인가?
2022년 버전은 진짜로 판을 깰 뻔했다
이게 어디서 시작됐는지 알아야 한다. 지금 조문은 첫 초안이 얼마나 나쁘게 착지했는지에 대한 반작용이니까.
2022년 제안은 소프트웨어를 토스터처럼 취급했다. 누군가 만들고, 시장에 내놓고, 그게 사람을 다치게 하면 책임진다. 라우터를 파는 회사엔 괜찮은 모델이다. 그런데 그 라우터 펌웨어가 서로 만난 적도 없고 상대의 법적 이름도 모르고, 세 단계 아래 다운스트림 스마트홈 벤더의 제품에 책임지겠다고 동의한 적은 더더욱 없는 자원봉사자들이 쓴 오픈소스 라이브러리 마흔 개를 끌어온다는 걸 떠올리는 순간, 모델은 무너진다.
열몇 개 오픈소스 단체가 공개서한을 썼다. 요지는 대략 “이건 기여를 죽인다”였다. 과장이 아니었다. 인기 라이브러리를 관리하는 게 EU 제조물 책임에 노출되는 거라면, 돈 못 받는 메인테이너의 합리적 선택은 그만두거나, 유럽을 지오블록하거나, 상용 사용자는 알아서 하라는 라이선스 조항을 붙이는 거다. 이 초안은 자기가 지키려던 생태계를 떠받치는 바로 그 사람들을 위협하는 데 성공했다.
Commission이 귀를 기울였는데, 이건 마땅한 것보다 드문 일이다. 최종 조문은 다른 짐승이다.
두 단어가 모든 걸 결정한다: “상업적 활동”
핵심 예외는 한 문장이다. 상업적 활동의 과정 밖에서 개발·공급된 자유·오픈소스 소프트웨어는 대상이 아니다. 상업적으로 하는 게 아니라면 CRA는 당신에게 적용되지 않는다. 끝.
당연한 후속 질문 — 뭐가 상업적인가? — 은 recital(전문 조항)이 무거운 일을 하는 지점인데, 예상보다 안심된다. Recital 18은 정기 릴리스를 낸다는 것만으로 상업적이 되지 않는다고 한다. 이익을 낼 의도 없이 기부를 받는 것도 아니다. 공개 저장소에 호스팅되는 것도 아니다. 심지어 회사가 당신 프로젝트에 기여하거나, 제조사가 당신이 이익을 내지 않는 선에서 돈을 주는 것도, 자동으로 당신을 “제조사”로 뒤집지 않는다.
그러니까 주말에 프로젝트 하나 만들어 공유하는 취미 개발자는 안전하다. 매달 릴리스를 끊고 GitHub Sponsors 후원함을 둔 메인테이너도 안전하다. 매출 없는 내 무료 npm 패키지는, 어떻게 정직하게 읽어도 대상 밖이다.
진짜 좋은 결과다. 근데 이게 뭐 위에 서 있는지 보라: 의도와 이익. “상업적 활동”은 당신의 코드나 그 도달 범위가 아니라 동기와 돈 주위에 그어진 선이다. 그리고 동기라는 건 쉬운 경우엔 명확하고 어려운 경우엔 변호사들 놀이터가 되는, 딱 그런 종류다. 지원 계약을 팔기 시작한 메인테이너. 유료 호스팅 버전을 띄운 프로젝트. 무료 티어가 수백만 기업이 의존하는 바로 그 바이너리인 오픈코어 회사. 규정은 양 극단은 알려준다. 흥미로운 중간은 다퉈 보라고 남겨둔다.
발명품: “오픈소스 스튜어드”
여기가 내가 진짜 영리하다고 보는 부분이자, 동시에 하나의 방증이다.
CRA는 전에 없던 법적 범주를 만들었다: 오픈소스 스튜어드(open source steward). 제조사가 아닌 법적 실체로서, 상용 제품을 위한 오픈소스 소프트웨어에 지속적인 지원을 제공하는 주체다. 읽자면: 재단들. 메인테이너를 고용하고, CI를 돌리고, 상표를 쥐고, 기부로 핵심 인프라를 살려두는 조직들.
스튜어드는 일부러 가벼운 레짐을 받는다. CE 마킹도, 적합성 평가도, 기술 문서도 필요 없다. 세 가지만 진다: 문서화된 사이버보안 정책, 당국과의 협조, 스튜어드하는 프로젝트의 취약점 신고. 그리고 — 입안자들이 지형을 이해했음을 보여주는 대목 — 스튜어드는 행정 벌금에서 면제된다. 공짜로 내준 코드의 버그로 비영리 단체를 벌금 물려 파산시킬 수는 없으니까.
스튜어드 역할이 이 규정 전체에서 제일 똑똑한 물건이라고 본다. “돈 안 받는 개인”과 “제품을 파는 회사” 사이에 제3의 행위자 — 공유 인프라를 지탱하는 기관 — 가 있고, 거기에 제조물 책임 규칙을 들이대면 그 기관이 그냥 무너진다는 걸 인정한 거니까.
근데 새 법적 종(種)을 발명했다는 건, 당신의 분류 체계가 틀렸었다고 자백한 거다. 스튜어드가 존재하는 이유는 제조사 모델이 소프트웨어가 실제로 만들어지는 방식을 기술하지 못했기 때문이다. 패치다. 좋은 패치지만, 더 깊은 불일치 위에 덮은 패치. 규제 당국은 여전히 식별 가능한 제작자가 있는 개별 제품의 세계를 집어 들지만, 현대 소프트웨어는 저자 대부분이 아무 보수도 못 받는 의존성들의 공급망이다.
코드를 배포하는 사람에게 이게 실제로 뜻하는 것
노이즈를 걷어내면 이 글을 읽는 대부분에겐 그리 복잡하지 않다.
당신의 오픈소스 프로젝트에 상업적 의도가 없다면 — 제품도, 유료 티어도, 지원 사업도 없다면, 기부는 있어도 — CRA의 제조사 의무는 당신 것이 아니다. 계속 배포하라. 이 예외는 당신을 염두에 두고 쓰였고, 넓다.
당신이 남들을 위해 오픈소스를 체계적으로 지탱하는 재단이나 회사라면, 스튜어드에 해당하는지 진지하게 보고 지금부터 취약점 처리 정책을 적어두라. 값싼 보험이고, 어차피 있어야 했을 문서가 대부분이다.
그리고 EU에 디지털 요소를 가진 뭔가를 판다면 — 이게 당신이고, 2026년 9월 신고 시계는 이미 돌고 있다. 실제 악용 취약점에 대한 24/72/14 리듬이 근시일 의무인데, 사람들은 2027년 날짜에 꽂혀서 이걸 자고 있다.
정직한 요약은, CRA가 목표는 제대로 잡았다는 거다. 사람들이 돈 주고 쓰는 것의 보안은 누군가 책임져야 하고, “오픈소스 위에 지었다”는 건 부주의한 제품을 파는 벤더에게 애초에 변명이 못 됐다. 규정은 그 책임을 대체로 돈을 가져가는 쪽에 겨누고, 그 아래 자원봉사자들은 일부러 비껴갔다. 하마터면 통과될 뻔한 법보다 나은 법이다.
그래도 메인테이너의 책임 여부가 “상업적 활동”이라는, 누군가 이걸로 법정에 끌려가기 전엔 진짜 정의를 못 받을 문구에 달려 있다는 게 나는 여전히 싫다. 내 작은 패키지에겐 답이 충분히 명확하다. 선이 어디인지 알게 될 사람은 git commit 하나 차이로 지원 계약 앞에 선 그 메인테이너고, 아마 비싼 방식으로 알게 될 거다.