오픈소스는 누구를 위한 것인가?

AI 요약

Rich Hickey의 “오픈소스는 당신을 위한 것이 아니다”라는 주장에 글쓴이는 반론을 제기합니다. 사용자가 자원봉사 유지관리자에게 무리한 요구를 하거나 기업이 무료 지원을 당연하게 여기는 태도는 문제입니다. 그렇다고 오픈소스가 유지관리자의 선물을 사용자가 감사히 받는 일방적인 관계인 것은 아닙니다. 코드를 공개하는 일에는 양쪽이 주고받는 혜택이 있고, 사용자는 그 과정에서 유지관리자를 신뢰합니다. 글쓴이는 이 교환과 그에 따르는 책임을 더 분명히 말해야 한다고 주장합니다.

유지관리자가 얻는 것

오픈소스 유지 동기는 하나로 설명되지 않습니다. 글은 네 가지를 듭니다. 첫째는 평판입니다. 눈에 띄는 프로젝트에 기여하면 일자리를 구하기 쉬워지고, 컨설팅 회사라면 서비스 홍보에도 도움이 됩니다. 사용자는 코드를 얻고, 유지관리자는 관심과 신뢰, 잠재 고객을 얻습니다.

둘째는 영향력입니다. 유지관리자가 선호하는 인프라나 해결 방식을 공개하면 다른 개발자와 조직의 기술 선택에 영향을 줍니다. 기업은 채용 후보자가 코드를 미리 살펴보게 하거나, 직원이 내부 시스템을 익히는 데 활용해 채용·교육 비용을 줄일 수 있습니다. 셋째는 학습입니다. 코드를 공개하면 사용자의 버그 신고와 피드백을 받고, 일부 사용자가 공동 개발자로 참여할 수 있습니다. 넷째는 유지보수 부담의 공유입니다. 여러 조직이 같은 도구를 사용하면 각자 모든 변경과 호환성 대응을 떠안지 않아도 됩니다. 이때 주된 유지관리자는 코드를 내놓는 데 그치지 않고, 기여자가 모여 변경을 조정하고 배포하는 공간을 제공합니다.

이런 혜택은 회사의 회계에서도 드러나야 한다고 글쓴이는 말합니다. 오픈소스 유지보수를 특정 제품팀의 부수 업무로만 처리하면, 비용 절감 국면에 유지보수부터 삭감할 유인이 생깁니다. 채용, 마케팅, 평판, 전사 플랫폼 유지에 기여하는 정도를 고려해 비용을 배분해야 합니다.

신뢰는 거래 대상이 아닙니다

사용자가 오픈소스 코드를 설치하면 유지관리자에게 시스템 접근 권한을 내주는 셈입니다. 글은 악성코드나 백도어를 넣지 말아야 한다는 의무를 예로 듭니다. 패키지 배포 권한이 탈취되면 악성 업데이트가 사용자에게 전달될 수도 있으므로, 유지관리자는 배포 계정과 운영 보안을 지켜야 합니다. 사용자의 신뢰를 악용하지 않는 일은 코드와 교환하는 대가가 아니라 지켜야 할 책임이라는 설명입니다.

또 사용자는 소프트웨어가 계속 작동하리라는 기대를 품고 그 위에 작업과 데이터를 쌓습니다. 대체 도구를 만들거나 다른 데이터 형식을 유지하거나 새 도구를 익히는 투자를 미루기도 합니다. 글은 그림 프로그램 OpenPaint를 가정해 이 위험을 설명합니다. 유지관리자가 사용자가 의존하는 ‘블렌드’ 기능을 새 버전에서 없애고, 옛 버전은 운영체제 업데이트와 호환되지 않는데 새 버전만 고친다면, 사용자는 작업 방식을 바꾸거나 취약한 운영체제를 계속 써야 합니다. 오픈소스 라이선스가 있다고 해서 사용자의 의존과 전환 비용이 사라지지는 않습니다. 무한한 지원을 약속할 필요는 없지만, 변경 이유를 알리고 유지보수 종료를 공지하는 등 사용자의 의존을 고려해야 한다고 말합니다.

기대를 말하고 대화할 공간을 마련해야 합니다

프로젝트마다 유지관리자의 의도와 여력이 다릅니다. 글쓴이는 그 차이를 미리 밝히고, 사용자가 의견을 내거나 기여할 수 있는 범위를 설명하자고 제안합니다. 라이선스의 보증 면책 조항만으로는 기대가 정리되지 않습니다. 사용자는 오픈소스라는 말에서 피드백과 협업 가능성을 기대할 수 있기 때문입니다.

AI 생성 코드 논쟁도 이 문제를 드러냅니다. 일부 사용자는 프로젝트가 LLM 생성 코드를 받아들이는 정책에 반발하지만, 유지관리자에게 불만을 전달할 알맞은 통로가 없으면 항의가 여러 포럼과 소셜미디어로 번집니다. GitHub Issues는 비기술 사용자에게 낯설 수 있고, 개발자 포럼은 대규모 항의를 감당하기 어렵습니다. 사용자끼리 대화하고 의견을 전달하는 커뮤니티 공간은 필요하지만, 이를 만들고 운영할 인력도 부족합니다. 글은 AI 논쟁을 기존의 소통·운영 문제를 키우는 사례로 봅니다.

유지관리자에게도 책임 범위는 명확해야 합니다. 사용자의 모든 요구를 받아들일 의무가 있는 것은 아니지만, “아무것도 약속하지 않았고 빚진 것도 없다”고 선언하는 것만으로는 이미 형성된 기대가 사라지지 않습니다. 유지관리자가 무엇을 얻으려 프로젝트를 공개하는지, 사용자에게 어떤 의무를 느끼는지, 사용자는 어떻게 의견을 전달할 수 있는지 함께 정리해야 한다는 것이 글의 제안입니다.

Lobsters 반응

• @sjamaan — 글쓴이의 주장에 동의하지만, 이런 기대는 번아웃으로 이어질 수도 있습니다. 그 생각을 끝까지 따라가면, 정신 건강을 희생할 만한 일은 없고 특히 무급 취미라면 더 그렇다는 점에서 Rich Hickey에게 동의합니다. 좋은 절충안은 프로젝트를 계속 유지할 수 없거나 원하지 않는 시점에 분명히 알리는 일입니다. 그러면 사용자도 기대치를 알고 계획을 세울 수 있습니다.
  • @technomancy — 정신 건강을 희생할 만한 일은 없고 특히 무급 취미라면 더 그렇다는 점에서 Rich Hickey에게 동의합니다. 프로젝트를 계속할 수 없거나 원하지 않는다고 알리는 방법도 있고, 다른 사람의 의견과 관계없이 원하는 방식으로 계속 개발하겠다고 알리는 방법도 있습니다. 저는 Clojure 커뮤니티에 깊이 참여했고 Clojure 프로젝트에 기여하려다 좌절해 그만둔 경험이 있습니다. 일찍 입장을 알렸다면 갈등과 번아웃을 피할 수 있었을 겁니다. 당시 Rich는 커뮤니티에 무엇을 원하는지 물었고, 사람들은 GitHub로 옮기길 원한다고 답했습니다. 커뮤니티는 Clojure에 풀 리퀘스트를 보내고 싶다는 뜻이었지만, Rich는 개발 절차는 그대로 두고 호스팅 서비스만 바꾸라는 뜻으로 받아들였습니다.
  • @ubernostrum — 사람들이 서로 엇갈려 말하는 이유는 오픈소스 프로젝트가 달리 밝히지 않는 한 피드백과 협업, 기여에 열려 있다는 암묵적 기대가 있기 때문이라고 봅니다. 면책 조항을 근거로 아무것도 약속하지 않았다고 말하는 사람도 있지만, 커뮤니티는 코드 묶음만 공개하는 대기업을 진정한 오픈소스라고 보지 않곤 합니다. 많은 사람이 오픈소스에 양방향 또는 다자간 협업을 기대하기 때문입니다. 프로젝트를 공개할 때 기대를 명확히 알리면 갈등을 줄일 수 있습니다. 보증 면책 조항이 있다는 사실만으로 협업 가능 여부가 설명되지는 않습니다.
  • @zetashift — 글이 사용자 권리만 편드는 내용일 줄 알았는데 그렇지 않았습니다. 좋은 점을 짚었고 댓글도 잘 설명하고 있습니다. 소통이 어렵더라도 기대를 정하는 일은 중요합니다. 또 무례한 사용자의 성의 없는 댓글은 작고 좋은 상호작용보다 훨씬 더 마음에 남을 수 있습니다.
  • @k749gtnc9l3w — 이 글은 작은 프로젝트일수록 어떤 기여를 환영하는지 분명히 밝혀야 한다는 점을 설득력 있게 설명합니다. 프로젝트는 기여자들의 것이고 그들을 위한 프로젝트이며, 기여자는 혼자일 수도 있고 바뀔 수도 있습니다. 사용자 커뮤니티가 반드시 필요하다는 주장은 과장된 듯합니다. 평판도 포크하고 잘 유지할 수 있는 사람들 사이에서만 얻고 싶을 수 있습니다. 버려진 오픈소스 프로젝트 중에는 제가 직접 고쳐 계속 쓸 수 있어 고마운 것도 있습니다.
• @pgeorgi — OSD를 따르는 라이선스로 코드를 공개했지만 사용자나 커뮤니티에는 관심이 없다면, 오픈소스를 하는 게 아닌가요? 오픈소스 도구만 이용하는 건가요, 잘못하고 있는 건가요, 아니면 이 글의 논의 범위를 벗어나나요?
  • @henderson — 글을 호의적으로 읽으면, 평판이나 영향력, 유지보수 도움 같은 개인적 이익을 얻으려 공개하는 개발자는 잠재적 사용자와 거래를 제안하는 셈이고, 그에 따른 의무도 생긴다는 주장으로 볼 수 있습니다. 이 관점은 사용자가 프로젝트에 애착을 느끼는 이유와 라이선스 변경, AI 사용, 텔레메트리 등에 분노하는 이유를 설명하는 데 유용합니다. 다만 “오픈소스”를 하나의 뜻으로 단정하는 도입은 관심을 끌려는 표현처럼 보입니다. 사람들은 개발 방식, 커뮤니티, 라이선스를 모두 오픈소스라고 부르면서 맥락을 분명히 하지 않을 때가 많습니다.
• @square_usual — 아닙니다. 무료로 배포한 앱을 쓰는 사용자는 개발자에게 어떤 의무도 부과할 수 없습니다. 개발자가 공짜로 준 것이니 마음에 들지 않으면 사용을 멈추면 됩니다. 공짜로 준 사람에게 의무를 강요할 권리는 없습니다.
  • @tonyarkles — “망가뜨렸으면 두 조각 다 가지세요. 마음에 안 들면 환불해 드리겠습니다.”
• @carlana — 닫힌 저장소보다 오픈소스 저장소를 쓰는 편이 쉽고, 직장을 옮겨도 제 작업물에 계속 접근하고 싶어서 코드를 공개합니다.
  • @technomancy — 좋은 글이지만, 모든 주장은 “오픈소스를 공개하는 경우”가 아니라 “사람들에게 사용을 권하는 오픈소스를 공개하는 경우”를 전제로 합니다. 글이 반박하는 글에서도 실제로 사용을 권하는 상황이 많았으니 여전히 관련이 있지만, 예외도 있습니다.

원문: Glyph 블로그 / 번역·요약: Trawling