콜로라도주 연령 인증 법안, 오픈소스 프로젝트는 제외로 수정됐다

오픈소스 개발자에게도 영향을 줄 뻔한 법안

미국 콜로라도주에서 진행 중인 SB051이라는 연령 인증 법안이 최근 수정됐는데, 오픈소스 프로젝트를 적용 대상에서 제외하는 조항이 추가됐어요. 한국에서 코드를 짜는 우리와 무슨 상관이냐 싶을 수 있지만, 이 사안은 글로벌 오픈소스 생태계 전반에 영향을 줄 수 있는 사례라서 한 번 짚어볼 만해요.

사건의 배경부터 보면, 미국 여러 주에서 최근 온라인 서비스에 연령 인증(age verification)을 강제하는 법안들이 줄줄이 통과되고 있어요. 18세 미만 이용자를 보호한다는 명분으로, 일정 규모 이상의 온라인 플랫폼은 사용자의 신분증이나 얼굴 인식 등으로 나이를 확인하라는 거죠. 텍사스, 유타, 루이지애나 같은 주에서 이미 시행 중이거나 시행 예정이고, 콜로라도의 SB051도 비슷한 흐름의 법안이었어요.

왜 오픈소스가 문제가 됐나

문제는 이런 법안이 흔히 '온라인 서비스 제공자' 같은 모호한 표현을 쓴다는 점이에요. 이게 뭐냐면, 글자 그대로 해석하면 GitHub에 코드를 공개한 1인 개발자도 '서비스 제공자'에 포함될 수 있다는 거예요. 예를 들어 누군가 취미로 만든 채팅 라이브러리, 이미지 갤러리 컴포넌트, 게임 엔진 같은 오픈소스 프로젝트가 어떤 식으로든 사용자 콘텐츠를 다룬다면, 그 코드를 GitHub에 올린 것만으로 연령 인증 의무를 져야 한다는 해석이 가능해지거든요.

현실적으로 보면 이건 말이 안 되는 얘기예요. 무료로, 봉사 정신으로 라이브러리를 공개한 개인 개발자가 신분증 검증 시스템을 갖추라는 건 사실상 '오픈소스 그만둬라'와 같은 말이거든요. 더 큰 문제는 법적 책임의 무게예요. 위반하면 벌금이 부과될 수 있고, 미국 거주가 아닌 해외 개발자도 미국 사용자가 자기 코드를 쓰면 잠재적으로 노출될 수 있어요.

이런 우려가 오픈소스 커뮤니티 안에서 점점 커지자, 콜로라도주 입법자들이 SB051 수정안에 오픈소스 프로젝트 예외 조항을 넣은 거예요. 정확히 어떤 정의로 '오픈소스'를 규정했는지는 법안 본문을 자세히 봐야 하는데, 통상 OSI(Open Source Initiative) 승인 라이선스 하에 공개된 소프트웨어를 의미해요. MIT, Apache 2.0, GPL 같은 익숙한 라이선스들이 포함돼요.

비슷한 사례, 그리고 미해결 과제

사실 오픈소스가 정부 규제에 휘말릴 뻔한 사건은 처음이 아니에요. 작년에 유럽연합(EU)에서 추진한 사이버 회복력 법안(Cyber Resilience Act, CRA) 도 비슷한 논쟁을 일으켰어요. 처음 초안은 모든 소프트웨어 제공자에게 강력한 보안 의무를 부과하는 내용이었는데, '그러면 오픈소스 개인 메인테이너들이 다 손 떼야 한다'는 거센 반발이 나왔어요. 결국 비영리 오픈소스 프로젝트는 의무에서 제외되는 방향으로 수정됐죠.

공통점이 보이세요? 처음엔 입법자들이 '큰 플랫폼'을 겨냥해서 법을 만드는데, 법조문의 표현이 너무 넓다 보니 의도치 않게 오픈소스 개인 개발자까지 그물에 걸려 들어가는 패턴이에요. 그래서 커뮤니티가 항의하고, 그제야 예외 조항이 들어가는 식이죠.

다만 이번 콜로라도 사례도 완전히 끝난 얘기는 아니에요. '오픈소스의 정의'를 어떻게 정확히 쓰느냐에 따라 누군가는 보호받고 누군가는 못 받을 수 있거든요. 예를 들어 'source-available' 라이선스(코드는 볼 수 있지만 OSI 정의의 오픈소스는 아닌 경우)는 어떻게 처리되는지, 오픈소스 프로젝트에 상업적 부가 서비스를 붙인 경우는 어떤지 등이 모호하게 남아 있어요.

한국 개발자에게 시사하는 점

첫째, '이건 미국 일이야' 하고 넘기기 어려운 시대라는 걸 알아두는 게 좋아요. 우리가 GitHub에 올린 코드는 자동으로 전 세계에서 접근 가능하고, 미국이나 유럽 사용자가 쓰면 그 지역의 법이 적용될 여지가 있어요. 특히 사용자 데이터를 다루거나 미성년자가 접근할 수 있는 서비스성 오픈소스라면 더 신경 써야 해요.

둘째, 자기 프로젝트의 라이선스를 명확히 해두세요. MIT나 Apache 2.0처럼 OSI가 인정하는 표준 라이선스를 쓰면, 이번 콜로라도 케이스 같은 예외 조항의 보호 범위에 들어갈 가능성이 커져요. '그냥 LICENSE 파일 안 넣었어요'라거나 자체 작성 라이선스를 쓰면 법적 회색지대에 놓일 수 있어요.

셋째, 한국 안에서도 비슷한 입법 흐름이 올 수 있다는 점을 인지하면 좋아요. 한국 역시 청소년 보호, 딥페이크 대응, AI 콘텐츠 규제 같은 이슈로 입법이 활발한 편이거든요. 그 과정에서 '오픈소스를 어떻게 다룰 것인가'가 충분히 논의되지 않으면, 콜로라도 SB051 초안 때처럼 의도치 않은 피해가 발생할 수 있어요. 개발자 커뮤니티가 입법 과정에 의견을 내는 채널을 가지고 있는지 한 번쯤 살펴볼 만한 시점이에요.

넷째, EFF(전자프런티어재단)나 OSI, Linux Foundation 같은 단체들이 이런 법안에 대해 어떤 입장을 내는지 한 번씩 보면 시야가 넓어져요. 그들이 정리한 우려 사항을 보면, 단순히 '법이 나쁘다' 수준이 아니라 어떤 조항의 어떤 표현이 문제인지 매우 구체적으로 짚어주거든요. 우리가 비슷한 한국 입법에 의견을 낼 때도 참고가 돼요.

마무리

한 줄 정리: 오픈소스는 더 이상 법적 무균실이 아니에요. 우리가 짠 코드 한 줄도 글로벌 규제의 영향권 안에 있고, 그 균형을 잡는 일은 개발자 커뮤니티의 목소리에 달려 있어요.

여러분은 본인 오픈소스 프로젝트에 라이선스를 어떻게 붙이고 계세요? 그리고 한국에서 개발자 커뮤니티가 입법 과정에 더 적극적으로 의견을 내려면 어떤 채널이 필요할까요? 평소 잘 다뤄지지 않는 주제지만 한 번 같이 생각해볼 만한 문제 같아요.