우리가 알던 오픈소스는 죽었다

오픈소스는 유지보수자에게 골칫거리가 됐지만, 역설적으로 에이전트 코딩은 최종 사용자에게 엄청난 혜택을 줌. 비개발자는 직접 소프트웨어를 수정할 수 없어 오픈소스의 이점이 주로 간접적이거나 이론적인 수준에 머물렀음. 버그 하나를 피하거나 기능을 조금 바꾸려고 프로그래밍을 배우기에는 시간과 노력이 너무 많이 듦.
이제는 “Claude, 고쳐 줘”라고 하면 개인이 쓰기에는 충분한 수준으로 해결되는 편임.

GPL의 전염성은 바로 이런 이유에서 나온 것임. 대부분의 사용자는 직접 수정할 수 없지만, 다른 사람에게 수정을 의뢰하거나 공개된 수정본 중 원하는 기능을 갖춘 것을 골라 혜택을 누릴 수 있어야 함. 이론적으로는 직접 작업하지 않아도 그 이점을 누리게 하는 장치임.
다만 실제로 소프트웨어를 수정할 때 소스 코드 확보는 전체 작업의 아주 작은 부분에 불과한 경우가 많음.

신중하게 사용하는 개발자에게도 유용함. 내 디버깅 시간은 거의 0으로 줄었음. 로그와 충돌 당시의 gdb 역추적을 주고 원인을 찾으라고 하면, 10분 뒤에는 오류로 이어지는 코드 경로와 수정안이 나옴.
수정안은 약 20%가 엉터리지만, 무엇을 고쳐야 하는지 알면 어떻게 고칠지는 쉽게 파악할 수 있음.

GitHub 덕분에 모두가 마침내 같은 방에 모인 듯해졌다는 것이, 누군가에게는 장점이 아니라 결함임.

전 세계를 아우르는 하나의 광장은 없음을 끝없이 다시 배우게 되는 듯함.

개인적으로 GitHub의 프로젝트 발견 기능은 거의 쓰지 않았음. 지난 10년간 프로필 피드에서 흥미로운 저장소를 찾은 건 한두 번 정도이고, 대개 HN 같은 외부 사이트나 다른 저장소의 댓글에 달린 링크로 발견함. 목적지 도메인이 바뀐다고 이런 발견 경로가 사라지지는 않음. 계정을 새로 만드는 건 조금 번거롭지만 GitHub 이전을 포기할 이유는 못 됨.
오픈소스를 좋아하고 좋은 소프트웨어를 만들 수 있다고 믿으며, 어떤 종류의 소프트웨어는 반드시 오픈소스여야 한다고 봄. 다만 어느 순간부터 모든 기여가 원본 프로젝트로 돌아가야 한다는 생각이 지나치게 강조됐음. 핵심은 의존하는 소프트웨어를 이해하고 수정할 자유이지, 유지보수자가 기여를 검토해 준다는 보장이 아님. 글쓴이가 그렇다는 뜻은 아니지만, 이를 당연한 권리로 여기는 태도는 늘 이상하게 느껴짐. 포크도 전면 재작성처럼 처음부터 배제되는 선택지가 됐지만, 둘 다 필요하고 유익할 때가 있음.
협업을 장려하되 소유권과 거절할 권리도 그만큼, 때로는 더 존중해야 함.

비밀번호 관리자가 널리 보급되면서 새 계정을 만드는 부담도 줄어듦. 서버 침해 시 유출될까 걱정되는 이메일 주소를 쓰지 않아도 된다면, 나중에 자동 입력될 인증 정보를 하나 더 등록하는 것은 별로 상관없음. 여러 소규모 Git 호스팅 서비스에 분산되는 것도 이제는 큰 장애물이 아닌 듯함.

GitHub에서 프로젝트 검색은 사용해 왔음. 하지만 링크 모음을 갖춘 정적 웹사이트로 옮겨 간다면, 과거 여러 차례 처음부터 만들었던 것처럼 웹 전반의 저장소를 검색하고 색인하는 체계가 다시 생길 수도 있음. 정적 사이트는 봇 유무와 관계없이 소형 VPS로 저렴하게 운영할 수 있음.

제시된 예시는 설득력 있지만 결론에는 회의적임. 사람들은 함께 소프트웨어를 만드는 것을 좋아하고, 앞으로는 오픈소스가 아닌 상태를 유지하기가 더 어려워질 것으로 봄.
게임 업계와 레트로 커뮤니티에서 오래된 게임을 대규모로 디컴파일하거나 x86_64용으로 재컴파일하는 모습을 놀랍게 지켜보고 있음. 누군가는 Halo를 이식해 128인 서버까지 운영함. https://techspot.com/news/….
이는 폐쇄형 소스의 종말을 예고하는 징후처럼 보임. LLM과 Ghidra로 어떤 폐쇄형 소프트웨어든 내부를 열어 보고 원하는 플랫폼용으로 재컴파일하는 시대로 접어들고 있으며, 예전의 막대한 수작업 부담도 사라졌다고 봄. 누군가 주말 만에 디컴파일하고 복제·이식할 수 있다면 아예 소스를 공개하거나, 반대로 폐쇄형 소프트웨어를 모두 클라우드 서버로 옮기는 두 방향으로 갈 듯함.

직장에서 오픈소스 프로젝트 운영을 돕고 있음. 올해는 LLM 사용 정책을 명확히 하는 등의 조정이 필요했고 사용도 허용했지만, 이제는 LLM으로 만든 기여도 품질이 괜찮아 환영할 수 있는 균형점에 도달하는 느낌임.
커뮤니티에서는 정기 온라인 모임으로 기존 관계를 다지고 새로운 인연도 만듦. 오픈소스도 단순한 풀 리퀘스트보다 진정한 인간적 교류를 더 중시하는 방향으로 갈 수 있지 않을까?

인간적 교류를 추구하다 장애인, 프로젝트의 주 사용 언어에 능숙하지 않은 사람, 시간대가 겹치지 않는 사람 등을 배제하지 않도록 주의해야 함. 비동기 텍스트는 가장 포용적인 소통 수단임. LLM까지 참여할 수 있다는 것은 양날의 검이겠지만, 사람을 배제하는 것보다는 그쪽 위험을 감수하겠음.

이 글의 깊은 쓸쓸함에 공감함. 오픈소스의 변화를 오랫동안 지켜본 사람이 아니라, 일을 잘하고 싶고 인간적 연결을 간절히 원하는 신입 개발자로서 느끼는 감정임. 우주를 바라보는 별처럼, 모든 것이 가속하며 멀어져 점점 더 붉어지는 느낌임.
기술적으로는 더 쉽게 접근할 수 있어 보이지만, 사회적으로는 누구도 내게 시간을 쓸 가치가 있는지 알 수 없으니 굳이 관심을 기울일 이유가 있을까? 프로그래밍은 기술적이면서도 사회적인 활동임. LLM은 사람처럼 말하고 디지털 공간을 차지하지만 사람이 아니며, 누가 영향을 받는지가 아니라 지시받은 작업만을 “신경 씀”.
그래도 요즘 참석하는 코딩 모임의 사람들이 정말 친절해서 다행임.

기술 분야 안팎에서 대면 관계와 우정을 계속 가꿔 가길 강력히 권함. 온라인 기술 세계는 지금 거세게 흔들리고 있지만, 현실에는 여전히 좋은 사람들이 가득함.

사람이 직접 작성한 PR만 받는 것을 고려 중임. LLM을 쓸 생각이라면 차라리 좋은 명세를 주면 좋겠음. 내 설계 취향에 맞춰 직접 생성할 수 있기 때문임.

결국 좋은 명세를 만드는 방법은 LLM으로 먼저 코딩한 뒤, 변경 내역에서 명세를 역으로 뽑아내게 하는 것이 될 듯함.

저품질 PR을 제출하면 차단하겠다고 공지했더니 제출 건수가 꽤 줄었음.
엉터리 작업에는 무관용으로 대응해야 함. 누군가 시간을 낭비하게 만든다면 게으름 때문인지, 어리석음 때문인지, 악의 때문인지는 크게 중요하지 않음. 모두 서비스 거부(DoS) 공격이나 마찬가지이며 용납해서는 안 됨.

낯선 사람이 보낸 300줄의 요청하지 않은 변경을 받아들인 것이 단순히 “모험을 감수한 것”은 아닌 듯함. 아마 코드를 읽고 테스트한 뒤 받아들였을 것임.