# 하드웨어가 단종될 때, 기업은 소프트웨어를 오픈소스로 공개해야 한다 > Clean Markdown view of GeekNews topic #25814. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25814](https://news.hada.io/topic?id=25814) - GeekNews Markdown: [https://news.hada.io/topic/25814.md](https://news.hada.io/topic/25814.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-15T01:32:58+09:00 - Updated: 2026-01-15T01:32:58+09:00 - Original source: [marcia.no](https://www.marcia.no/words/eol) - Points: 4 - Comments: 1 ## Topic Body - **하드웨어 제품이 단종(EOL)** 될 경우, 기업이 해당 소프트웨어를 **의무적으로 오픈소스로 공개해야 한다는 주장** - **Right to Repair 운동**이 진전을 이뤘지만, 유럽연합 차원에서 **EOL 시 소프트웨어 공개를 법적으로 강제**해야 한다고 제안함 - 예시로 **스마트 체중계**가 앱 지원 중단으로 기능을 잃은 사례와, **Spotify의 Car Thing**이 단종 후 전자폐기물로 전락한 사례 언급 - 기업이 전체 코드베이스를 공개할 필요는 없으며, **하드웨어 사양과 연결 프로토콜만 공개**해 커뮤니티가 자체 앱을 개발할 수 있게 해야 함 - **지속가능성과 사용자 권리**를 위해, 단종된 하드웨어를 살릴 수 있는 오픈소스 접근이 필수적임 --- ### 하드웨어 단종과 오픈소스의 필요성 - 하드웨어 제품이 **EOL(End of Life)** 상태에 도달하면, 기업이 **소프트웨어를 오픈소스로 공개해야 함** - 단종된 제품이 여전히 작동 가능한데도, 소프트웨어 지원 중단으로 쓸모없게 되는 문제 지적 - 이러한 상황을 방지하기 위해 **법적 강제력**이 필요하다고 주장 - **Right to Repair 운동**이 이미 소비자 권리를 강화했지만, 이를 넘어 **유럽연합(EU)** 이 **EOL 시 소프트웨어 공개를 의무화**해야 한다는 제안 - 기업이 제품 단종 시점에 소프트웨어를 공개하도록 **유럽위원회(European Commission)** 가 규제해야 한다는 입장 ### 개인 경험과 문제 사례 - **스마트 체중계** 사례에서, 하드웨어는 정상 작동하지만 앱이 중단되어 **데이터 저장 기능이 사라짐** - 블루투스 연결은 가능하지만, 앱이 더 이상 개발되지 않아 **사실상 무용지물**이 된 상황 - 완벽한 하드웨어가 기업의 지원 중단으로 ‘죽은’ 상태가 되는 현실에 대한 **불만과 낭비 문제** 제기 - **Spotify의 Car Thing** 단종 사례 언급 - 2024년 말 서비스 종료로 **200달러짜리 하드웨어가 하루아침에 전자폐기물로 전락** - **Bose**가 EOL 전에 **SoundTouch 스피커를 오픈소스로 공개한 사례**는 긍정적으로 평가되지만, 여전히 **드문 예외적 사례**로 지적 ### 현실적 대안 제시 - 기업이 **전체 코드베이스를 공개할 필요는 없음** - 대신 **GitHub 저장소에 하드웨어 사양과 연결 프로토콜**만 공개하면 충분 - 커뮤니티가 이를 기반으로 **자체 앱을 개발**할 수 있음 - **vibe-coding** 등 새로운 개발 접근법으로 인해, **비전문가도 손쉽게 참여 가능** - 일반 사용자도 하드웨어를 직접 다루고 개선할 수 있는 시대가 도래 ### 지속가능성과 사용자 권리 - 단종된 하드웨어를 살릴 수 있는 **오픈소스 접근이 환경적·윤리적으로 필요** - 불필요한 전자폐기물 발생을 줄이고, **지속가능한 기술 생태계**를 유지할 수 있음 - 이미 ‘벽돌’이 된 하드웨어라면, **소프트웨어를 공개해 커뮤니티가 재활용할 기회**를 주는 것이 최선임 ## Comments ### Comment 49225 - Author: neo - Created: 2026-01-15T01:32:59+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46609492) - 가장 확실하게 **EOL(End-of-Life)** 프로젝트가 오픈소스로 전환되게 하는 방법은 처음부터 **오픈소스로 시작하는 것**임 “목표 달성 후 공개하겠다”는 약속이나, 회사가 망하면 공개하겠다는 선언은 의미가 없음 오픈소스로 시작해야 투자자와 커뮤니티가 신뢰할 수 있음 오픈소스 제품과 하드웨어를 만드는 회사에 돈을 쓰고, 자유롭게 배포하는 예술가를 지원해야 함 기업이 EOL 후에 공개하지 않는다고 비난하는 건 결국 보여주기식 행동에 불과함 - 동시에 소비자용 하드웨어는 단순한 **취미 시장**이 아니라는 점도 고려해야 함 - 소비자가 연대해 **지갑으로 투표**하면 시장을 바꿀 수 있음 대기업도 단결된 소비자 요구에는 버티기 어려움 FSF가 자유 소프트웨어를 보편화시킨 것처럼, 소비자 교육과 문화적 전환이 필요함 전문가의 의견이 빠르게 공유되는 **소비자 커뮤니티 문화**를 만들어야 함 냉소적인 태도보다 실질적 변화를 만드는 노력이 중요함 - 하지만 현실적으로 시장은 **폐쇄형 소스**를 보상하는 구조임 소비자 압박만으로는 어렵고, **규제**가 필요함 - 대부분의 시스템은 코드 서명 체인에 의존해 “**fail closed**”로 동작함 하지만 원래 서명 주체가 사라졌을 때, 새로운 주체에게 서명 권한을 위임할 수 있도록 “**fail open**” 구조가 필요함 - 단순히 하드웨어 사양과 프로토콜을 공개하자는 제안은 현실성이 낮음 대부분의 기기는 단순한 연결 프로토콜이 아니며, PCB 분석으로도 사양은 알아낼 수 있음 - 핵심은 “**재사용에 필요한 최소한의 정보**”를 제공하는 것임 펌웨어 플래시 방법과 최소 펌웨어 정도만 공개해도 충분함 다만 제품마다 상황이 달라 **사례별 접근**이 필요함 - 라우터처럼 **보안 부트**가 e-fuse에 박힌 장치는 단순한 오픈소스 공개로 해결되지 않음 이런 경우 제조사가 서명 키를 **에스크로(escrow)** 형태로 보관해, EOL 이후에도 새로운 소프트웨어를 실행할 수 있게 해야 함 - 하지만 서명 키 공개는 **보안 재앙**이 될 수 있음 만료된 도메인을 탈취한 공격자가 봇넷을 만들 수도 있음 대신 사용자가 명시적으로 3rd-party 펌웨어 설치를 승인하는 **물리적 버튼 조작** 같은 절차가 필요함 - “프로토콜만 공개하라”는 접근이 모든 기기에 충분하지 않다는 점을 보여줌 - 부트로더 잠금 자체를 **금지**해야 한다는 의견도 있음 사용자는 제조사 허락 없이도 자신의 기기를 수정할 **권리**가 있음 - 혹은 **물리 버튼을 통한 키 등록**을 허용하는 방법도 있음 - 나도 EOL로 인해 여전히 쓸 수 있는 하드웨어를 버려야 하는 상황이 답답함 하지만 “전자 폐기물 생산을 불법화하자”는 식의 접근은 현실성이 부족함 - 완전한 해결이 아니라면, **기능 상실 시 환불 의무** 같은 간단한 법으로도 개선 가능함 예: 제품이 주 기능을 수행하지 못하면 전액 환불, 단 제조사가 필요한 소프트웨어를 **공개 도메인**에 올리면 면제 이런 법은 구글처럼 서버 종료로 제품을 무력화시키는 대기업을 견제할 수 있음 - 하지만 이런 논리라면 **EOL된 Windows**도 공개해야 하는가? Windows 10을 오픈소스화하면 Microsoft의 장기 전략이 무너질 것임 - 이 아이디어는 “오픈소스” 자체보다도 흥미로운 발상임 예를 들어 UBNT가 EOL 부트체인을 공개해 Cambium이 그 펌웨어를 쓸 수 있게 된다면, 결과는 커뮤니티 지원이 아니라 **영원한 제품 업데이트 경쟁**이 될 수도 있음 - 현실적으로 완전한 오픈소스는 어렵고, 제조사는 제3자 IP를 공개할 권리가 없음 최소한 사용자가 원하는 **대체 소프트웨어 실행을 방해하지 않도록** 해야 함 - 하지만 그 정도로는 부족함 대부분의 사용자는 서버가 사라지면 펌웨어를 새로 설치하지 않고 그냥 버림 따라서 **외부 서버 의존성 없는 설계**가 필요함 예: 스마트 스피커는 로컬 네트워크 스트리밍을, 전구는 표준 프로토콜 페어링을 지원해야 함 다행히 **Matter over Thread** 같은 표준이 이런 방향으로 발전 중임 - **Google Nest Thermostat 1·2세대**가 대표적 사례임 [No Longer Evil](https://nolongerevil.com/) 프로젝트가 이 기기를 **오픈소스 펌웨어**로 되살림 구글 클라우드 의존성을 제거하고, 사용자가 직접 서버를 호스팅하거나 독립적으로 제어할 수 있게 함 덕분에 고가의 하드웨어가 다시 생명을 얻음 - 지금은 일종의 **암흑기**에 있다고 느낌 예전 난로는 단순히 핀 하나를 접지하면 작동했지만, 이후 모델은 **폐쇄형 프로토콜**로 바뀌어 접근이 어려워졌음 그러나 최신 모델은 다시 **OpenTherm** 표준을 지원해 해킹이 쉬워짐 요즘은 ESP32나 Raspberry Pi 기반의 오픈 하드웨어가 많아, 직접 **ESPHome + LVGL**로 GUI를 만들어 홈오토메이션에 통합함 친구들이 브랜드 제품인 줄 착각할 정도로 완성도가 높았음 - “그건 일어나지 않을 것”이라 생각함 다행히 **AI와 Android** 덕분에 프로토콜 리버스엔지니어링이 쉬워짐 APK 분석만으로도 많은 정보를 얻을 수 있어, Meta 인수 전 구입한 Limitless Pendant용 앱과 서버를 직접 만들고 있음 코드 한 줄도 직접 안 썼음 - 아무도 **평생 지원**을 기대하지 않음 하지만 앱 백엔드나 로드맵이 사라졌다는 이유로 **기본 기능**까지 죽이는 건 납득하기 어려움 기기가 전기·기계적으로 멀쩡하다면, 최소한의 사용은 보장되어야 함