AI가 폐쇄형 소프트웨어를 끝낸다는 오픈소스 운동가

AI 요약

오픈소스 운동가 Eric S. Raymond는 대규모 언어 모델(LLM)이 폐쇄형 소프트웨어의 종말을 앞당긴다고 주장합니다. 과거에는 폐쇄형 소프트웨어가 서서히 약해지고 일부 영역에는 남을 것으로 봤지만, 이제는 특허와 클라우드 기반 소프트웨어(SaaS)만 독점 사업 모델을 지탱할 수 있다고 전망합니다. 예외로는 계속 바뀌는 규정을 반영하는 일이 제품 가치의 상당 부분인 세금 소프트웨어를 꼽습니다. 다만 이 전망에는 동의하지 않는 반응도 적지 않습니다.

DOS 게임을 역공학한 실험

Raymond는 AI 보조 도구로 DOS 셰어웨어 게임 ‘Firefighter’를 디컴파일한 뒤 Rust로 옮긴 실험을 근거로 듭니다. 그는 AI가 데이터 배치를 보고 원래 코드가 Borland Pascal로 작성됐다고 알아낸 뒤, 함수와 변수에 의미 있는 이름을 붙인 읽기 쉬운 Pascal 코드를 출력했다고 설명합니다. Raymond는 처음에는 농담처럼 시작한 실험이었으며, 실제 대형 프로그램에 적용되리라고는 생각하지 않았다고 합니다. 이후 AAA급 게임 전체에도 비슷한 작업이 이뤄졌다는 이야기를 들었다고 덧붙였지만, 해당 규모의 사례는 기사에서 확인된 사실로 제시하지 않습니다.

이 논의는 AI로 새 프로그램을 만드는 바이브 코딩에만 국한되지 않습니다. 기존 바이너리를 분석해 동작을 재현하고, 독점 소프트웨어의 보호를 우회하는 데 AI가 쓰일 가능성도 쟁점입니다. Raymond는 Photoshop 대체 프로그램이 디컴파일을 거쳐 만들어졌다고 주장했지만, 기사에서는 아직 검증되지 않은 주장이라고 선을 긋습니다.

역공학과 법적 경계

Raymond는 미국에서 클린룸 역공학(clean-room reverse engineering) 절차를 밟으면 법적으로 방어할 여지가 있다고 봅니다. 한쪽 팀이 바이너리에서 명세를 만들고, 다른 팀이 디컴파일된 코드를 보지 않은 채 새 코드를 작성하는 방식입니다. 그는 Phoenix Technologies가 IBM PC BIOS를 역공학한 사례와 비슷한 접근이라고 설명합니다. LLM을 쓰면 이런 과정이 하루 만에 가능해졌고, 배포 뒤 모든 사용자를 추적하기도 어렵다는 것이 그의 주장입니다.

특허는 이 방식으로 피하기 어렵다고 Raymond는 봅니다. Linux가 특허로 보호되는 코덱을 기본 구성에 넣지 않고, 사용자가 나중에 불러오도록 하는 관행을 예로 듭니다. 유럽연합(EU)은 규제가 더 엄격합니다. 기사에 따르면 EU 소프트웨어 지침은 다른 프로그램과의 상호운용성에 필요한 범위에서 디컴파일을 허용하며, 유럽사법재판소(ECJ)는 2021년 판결에서 오류 수정 목적도 인정했습니다. AI가 이 절차를 바꾸더라도 법적 허용 범위가 자동으로 넓어지는 것은 아닙니다.

클라우드 전환의 한계와 방어 수단

Raymond는 게임조차 역공학할 수 있다면 다른 소프트웨어도 안전하지 않다고 말합니다. Adobe와 Microsoft 같은 대기업이 독립 실행형 제품을 클라우드로 옮기는 전략에도 회의적입니다. 사용자의 반발이 있고, 의료기기나 공작기계처럼 네트워크 장애가 허용되기 어려운 분야도 있기 때문입니다. 그는 Microsoft의 오픈소스 행보 역시 고객을 클라우드 서비스로 유도하려는 목적과 연결해 봅니다.

보안 연구자들의 관점은 더 제한적입니다. 코드 난독화는 LLM 덕분에 뚫는 비용이 내려가도 방어 효과가 완전히 사라지지는 않습니다. 코드 서명과 보안 부팅(secure boot)은 잠긴 하드웨어에서 수정된 소프트웨어가 실행되는 것을 막을 수 있지만, 바이너리를 읽는 일까지 막지는 못합니다. Raymond는 역공학이 제조사 사이의 지식재산권 침해 같은 숨겨진 관행을 드러낼 수 있다고도 예상합니다.

Reddit 반응

토론에서는 폐쇄형 소프트웨어가 코드 비밀만으로 팔리는 게 아니라는 반론이 나옵니다. 기업 고객은 지원, 책임 소재, 대체 제품의 부재 때문에 비용을 낸다는 의견입니다. 오픈소스도 Red Hat이나 Canonical처럼 지원과 서비스로 수익을 낼 수 있지만, 지원만으로 보편적인 사업 모델을 만들기는 어렵다는 반박도 이어집니다. 반대로 일부 기업은 비싼 SaaS에서 필요한 기능만 골라 내부 도구로 대체하려 한다는 경험을 공유했습니다.

AI가 오픈소스에 미칠 영향도 엇갈립니다. 한쪽은 바이브 코딩 결과물과 부실한 PR이 늘어 유지보수 부담을 키운다고 우려합니다. 프로젝트의 코딩 규칙과 리뷰 절차는 코드 일관성뿐 아니라 기여자가 장기적으로 프로젝트를 이해하고 참여할지 확인하는 역할도 한다는 설명입니다. 다른 쪽은 품질이 좋은 프로젝트는 살아남고, AI가 코드 작성과 보안 점검을 돕는다고 봅니다. 다만 AI가 만든 코드의 라이선스와 저작권이 불분명하고, GPL 같은 카피레프트 라이선스와 충돌할 가능성도 논쟁거리로 제기됐습니다.

역공학의 법적 범위를 두고도 의견이 나뉩니다. 일부 이용자는 소스 코드를 보지 않고 기능을 다시 구현하면 저작권 침해가 아니라고 주장합니다. 다른 이용자는 분석팀과 구현팀을 분리하는 클린룸 절차 없이 AI가 바이너리를 직접 분석해 코드를 만들면 법적 위험이 커진다고 봅니다. 댓글에서는 AI 도구가 역공학 지원에 쓰일 때도 같은 기준이 적용되는지 질문이 나왔습니다.

원문: heise / 번역·요약: Trawling