마이크로소프트 인수 이후의 깃허브(GitHub)에 실망해 대안을 찾는 개발자는 적지 않다. 웹 인터페이스가 무겁고 굼떠졌다는 기술적 불만도 있지만, 더 근본적인 우려는 깃허브가 세계 소프트웨어 소스코드의 상당 부분을 보관하는 사실상의 '공공 인프라'가 되면서 한 기업이 지나친 영향력과 감시 능력을 갖게 됐다는 점이다. 정당한 개발자가 자의적 계정 정지를 당했다는 사례들도 '최소한 백업은 다른 곳에 두자'는 결심을 부추긴다. 비영리 협회가 운영하는 코드베르크(Codeberg)는 그런 이들에게 무료이면서 자유로운 대안으로 보였다. 그런데 최근 약관 개정이 바로 그 '자유'라는 지점을 흔들면서, 한 개발자가 이주 몇 달 만에 다시 떠나겠다고 선언했다.
두 개의 카테고리 금지
논란의 핵심은 두 건의 카테고리 금지다. LLM이 주도적으로 작성한 프로젝트 금지가 6월 29일, 암호화폐 관련 프로젝트 금지가 7월 2일에 각각 어셈블리(Assembly) 2026 제안으로 도입됐다. 특히 암호화폐 금지는 새 약관에서 '코드베르크의 평판을 해치는 콘텐츠'라는 항목으로 분류됐는데, 이는 명확한 근거나 축적된 악용 사례를 제시하지 못한 채 '평판'이라는 모호한 명분으로 통째로 배제하는 법률적 수사에 가깝다는 비판을 받는다. 글쓴이는 자신이 두 범주 어디에도 해당하는 프로젝트를 갖고 있지 않다는 점을 분명히 하면서도, 문제는 개별 금지가 아니라 '자유 소프트웨어'를 표방하는 플랫폼이 어떤 종류의 소프트웨어가 좋고 나쁜지를 스스로 재단하기 시작했다는 데 있다고 지적한다.
금지를 정당화한 공식 블로그 글, 그중에서도 '아무도 없는 개발팀(The development team of none)'이라는 대목이 특히 반발을 샀다. 코드베르크는 LLM으로 빠르게 개발하는 이른바 '바이브 코더'들이 실제로는 자기 주위에 커뮤니티가 없다는 사실을 모른다고 꼬집었다. 그러나 이는 자유 소프트웨어가 실제로 만들어지는 방식과 동떨어진 주장이라는 반론이 나온다. 대다수 FOSS 프로젝트는 1인 개발자의 결과물이며, 이들에게 '커뮤니티'란 기여는 하지 않으면서 기능 요청과 버그 신고만 하는 사용자들인 경우가 많다. LLM의 사용 여부가 '진짜 커뮤니티를 가진 진짜 프로젝트'와 가짜를 가르는 기준이라는 전제는, 소도구 하나가 어떻게 탄생하는지를 들여다보면 성립하기 어렵다.
더 뼈아픈 지적은 코드베르크가 딛고 선 소프트웨어인 포지호(Forgejo) 자체가 기테아(Gitea)에서 하드포크로 갈라져 나오면서 기존 커뮤니티를 물려받았다는 사실이다. 남의 커뮤니티를 분기해 자기 것으로 만든 프로젝트가 이제 와서 단독 개발자에게 '너에겐 커뮤니티가 없다'고 훈계하는 것은 설득력이 떨어진다. 무엇보다 개인 프로젝트의 기준은 동작하는 빌드와 라이선스, 가능하면 README 정도였지 활발한 기여자 채널이 아니었다. 개인의 코드를 호스팅한다는 것이 존재 이유인 포지가, 커뮤니티가 없으면 정당한 소프트웨어가 아니라는 식으로 논지를 펴는 것은 자기 정체성과 충돌한다.
금지가 아니라 자원 문제로 다뤘어야
글쓴이가 진짜 우려하는 것은 미끄러운 경사면이다. 어떤 카테고리가 '평판을 해친다'고 약관에 명시되는 순간, 판단 기준은 코드가 합법적인지·작동하는지·유용한지가 아니라 플랫폼의 입장과 부합하는지로 바뀐다. 실제 문제가 생기면 인기 없는 범주가 손쉬운 범인으로 지목되고, 플랫폼은 문제 자체가 아니라 범주를 금지하며, 그 선례가 다음 금지의 근거가 된다. 오늘 별 논란 없이 금지되는 대상은 내일 그 메커니즘이 작동하는 이유가 된다. 첫 금지에 박수를 친 사용자들이 두 번째 금지에 대해서는 의견을 요청받지 못하는 구조다.
물론 두 범주에 문제가 없다는 뜻은 아니다. LLM 기반 저장소가 인프라에 부담을 주고 저품질 이슈·PR을 대량 생성하며 저작권과 코드 출처 문제를 안고 있다는 점은 코드베르크 스스로도 지적했고, 암호화폐 영역이 유독 사기를 많이 낳았다는 것도 사실이다. 다만 리누스 토르발스조차 LLM을 '분명 유용한 도구'로 보고, 결과물을 다른 코드와 같은 기준으로 검증한다면 리눅스 커널 개발에도 정당한 자리가 있다고 말한다. 세계에서 가장 중요한 오픈소스 프로젝트의 관리자가 LLM을 눈에 띄는 즉시 금지할 범주가 아니라 결과로 판단할 도구로 다룬다면, 소규모 포지도 같은 태도를 취할 수 있다.
대안도 제시된다. 코드베르크가 스스로 진짜 문제라고 밝힌 자원 소비와 인프라 비용은 자원 문제로 다뤘어야 한다는 것이다. 저장소에 LLM 생성 코드나 암호화폐 관련 여부를 스스로 신고하는 체크박스를 두고, 해당 저장소를 별도 인프라 계층으로 분리해 할당량을 제한하거나 사용량만큼 비용을 물리는 방식이다. 정직하게 신고하면 처음엔 비용이 들지 않지만, 숨겼다가 적발되면 지금과 같은 영구 정지를 적용할 수 있다. 자동으로 표시되는 면책 문구를 붙여 코드베르크가 품질을 책임지지 않으며 그런 사용을 승인하지 않는다는 점을 명시할 수도 있다. 이렇게 하면 자원을 많이 쓰는 프로젝트의 비용을 그 제작자에게 지우면서, 어떤 범주가 이념적으로 허용되는지를 플랫폼이 결정할 필요가 사라진다.
결정 과정 자체는 어셈블리 2026을 거쳤다는 점에서 대다수 플랫폼보다 절차적이었다. 그러나 일반 사용자는 이미 결론이 난 날 사이트 상단의 파란 배너를 통해서야 사실을 알게 됐다. 아직 방향을 정하는 중일 때 배너가 떴다면, 그리고 그것이 토론 스레드나 최소한의 설문으로 연결됐다면, 특정 범주가 아니라 플랫폼 전체의 자유에 관한 우려를 표할 수 있었을 것이다. 결국 이 사례가 남기는 실무적 교훈은 분명하다. 코드 호스팅을 특정 플랫폼에 전적으로 의존하는 것은 그곳이 비영리든 상업 기업이든 위험을 동반하며, 약관이 예고 없이 바뀔 수 있는 이상 자체 호스팅을 포함한 백업 전략은 여전히 각자의 몫으로 남는다.