▲

"작은" 오픈소스의 운명

 (nolanlawson.com)
2P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • JavaScript의 소형 유틸리티 라이브러리들이 LLM의 코드 생성 능력으로 인해 점차 불필요해지고 있음
  • 일례로 blob-util은 10년 된 npm 패키지로, Blob 처리 도구 모음이지만 이제는 AI가 즉석에서 유사 코드를 생성 가능
  • 이러한 변화는 의존성 감소와 빠른 개발을 가능하게 하지만, 학습과 이해의 기회 상실을 초래
  • Node.js와 브라우저의 내장 기능 확장에 이어, LLM이 소규모 라이브러리의 종말을 가속화하고 있음
  • 향후 오픈소스의 가치는 창의적·대규모·전문적 영역에서 지속될 가능성이 있음

소형 오픈소스의 쇠퇴와 LLM의 영향

  • 10년전에 만들었던 blob-util은 JavaScript의 Blob 객체를 문자열이나 ArrayBuffer로 변환하는 간단한 유틸리티 모음으로, 주간 500만 회 이상 다운로드됨
    • 작성자는 PouchDB 사용자들이 Blob 처리에 혼란을 겪는 것을 보고 제작
  • 현재 개발자의 약 80%가 AI를 업무에 활용하고 있으며, 이로 인해 단순 유틸리티는 LLM이 대체 가능
    • 예시로 Claude가 Blob을 ArrayBuffer로 변환하는 TypeScript 함수를 즉석에서 생성
  • Claude의 결과물은 blob-util과 유사하지만, 더 장황하고 타입 검증이 과도하며, 오류 처리는 개선된 형태
  • 작성자는 이러한 변화가 의존성 감소와 코드 견고성 향상으로 보일 수 있다고 언급함

학습 중심 오픈소스의 가치 상실

  • blob-util의 README에는 Kirby 캐릭터를 활용한 튜토리얼이 포함되어 있으며, 단순 기능 제공을 넘어 JavaScript 학습을 돕는 목적이 있었음
  • LLM 중심 개발 환경에서는 즉각적 답변이 이해와 교육보다 우선하게 되어, 이런 학습형 오픈소스의 필요성이 줄어듦
  • 문서 자동화를 위한 llms.txt 같은 시도는 문서의 의미 자체를 재정의하게 만듦

오픈소스의 새로운 방향

  • 작성자는 여전히 오픈소스를 지속하지만, 소규모·저가치 라이브러리의 시대는 끝났다고 생각
    • Node.js와 브라우저의 내장 기능(node:glob, structuredClone 등) 확장으로 이미 감소 추세였음
    • LLM이 그 흐름을 결정적으로 가속화
  • 교육적 역할을 하던 라이브러리(예: Underscore.js)도 필요성이 줄어듦
    • 단순 배열 그룹화 같은 기능은 이제 표준 API로 해결 가능

가치가 남는 오픈소스의 조건

  • LLM이 쉽게 생성할 수 없는 대규모·창의적·전문적 프로젝트에 가치가 집중
    • 예로 fuite 프로젝트와 메모리 누수 탐지 연구는 LLM이 재현하기 어려운 창의적 작업
  • 향후 오픈소스의 의미는 새로운 아이디어와 인간적 창의성에 있음
    • 예시로 Dominic Gannaway가 개발한 Ripple.js 프레임워크를 언급하며, 인간의 실험정신을 강조

결론

  • LLM은 일부 오픈소스를 시대에 뒤떨어지게 만들었지만, 여전히 새로운 형태의 오픈소스 창작 기회는 존재
  • 인간 개발자의 창의성과 실험정신이 AI 시대의 오픈소스 생태계 지속성의 핵심 요소로 제시됨
▲
haytsir 22시간전  [-]

2024년 초에 작은 프로젝트를 만들면서
claude 3.5한테 pure javascript에서 쓸 수 있는 store state 모듈을 만들어달라 했는데
간결하면서도 마이그레이션 상황까지 대응되는 코드를 짜줘서 놀랐던 기억이 나네요

소형 라이브러리일수록 비슷한 생각을 하는 사람들이 공개한 코드가 많을테고 AI가 이를 정형화된 구조로 만들기 쉬울거라 생각하면 당연한 현상이라 생각합니다.

copyparty처럼, 누구나 생각할 수 있지만, 개인이 오래 유지하기는 힘든.
그런 프로젝트들을 끝까지 밀어붙여서 나오는 깔끔하게 정제된 프로젝트들을 앞으론 보기 힘들어질 수 있다는 부분에는 아쉽기는 합니다.

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 요즘 개발자의 약 80%가 AI를 업무에 활용하고 있음
    blob-util 같은 유틸은 이제 대부분 LLM으로 바로 생성할 수 있음
    하지만 이런 접근은 양날의 검임. 검증되지 않은 코드가 유지보수 부담을 남기고, 엣지 케이스에서 실패할 수도 있음
    그래서 Java 생태계에서는 Apache Commons처럼 신뢰할 수 있는 표준 유틸 모음이 자리 잡았음

    • 오래된 유틸 라이브러리는 이미 다양한 환경에서 검증되어 안정적임
      반면 LLM이 생성한 코드는 겉보기엔 논리적이지만 이상한 버그가 숨어 있을 가능성이 큼

  • AI가 코드와 튜토리얼을 대량으로 생성하면서 품질 저하와 스팸화가 가속되는 시대에 진입했음
    개인 블로그나 소규모 라이브러리를 만들 동기가 줄어듦

    • 사실 웹은 이미 오래전부터 저품질 튜토리얼 스팸으로 넘쳐났음
      LLM이 만든 글도 비슷한 수준이라, 오히려 필터링하기 쉬워졌다고 느낌
      나는 devcontainer 안에서 코드 실행으로 튜토리얼의 진짜 가치를 테스트함. 작동하면 볼 가치가 있고, 아니면 버림
    • 오늘 유튜브에서 특정 주제를 찾다가 AI 생성 영상만 끝없이 나와서 놀랐음
    • “저품질 스팸의 시대가 온다”는 말은 이미 현실이 되어 있음
    • 어떤 웹 개발자는 “이제 10배 빨라졌으니 인류에 나쁠 리 없다”고 농담함
    • 누군가는 농담처럼 어셈블리 코드를 던지며 “이걸 설명 못 하면 진짜 개발자가 아니다”라고 비꼼

  • JS의 마이크로 의존성 지옥은 악몽이었음
    이제 그 시대가 끝나가고, 개발자들이 다시 코딩을 배우는 시대로 돌아가길 바람

    • jQuery나 lodash처럼 작은 유틸 모음을 하나의 패키지로 묶은 게 가장 좋은 결과였음
    • 하지만 “이제 다 끝났다”는 말에 의문을 제기함. 오히려 AI 생성 코드의 홍수로 더 나빠질 수도 있음
    • LLM 코드가 늘어나면, 동일 기능을 하는 함수가 여러 버전으로 흩어지고, 버그 수정도 각자 따로 해야 함
    • LLM을 쓴다고 해서 사람들이 더 배우게 되진 않음. 문제 생기면 LLM에 리팩터링을 맡길 테니까
    • “이제 vibe coder 시대가 왔다”고 짧게 덧붙임

  • “이진 트리를 뒤집는 문제”가 실제로 존재하냐는 질문이 나옴

    • 이는 Homebrew 창시자가 Google 면접에서 실패했던 문제를 가리키는 듯함
    • 아마 저자의 단순한 실수일 가능성이 높고, 굳이 한다면 비교 연산자를 반대로 바꾸는 무의미한 연습일 뿐임

  • “작고 가치 낮은 라이브러리의 시대는 끝났다”는 주장에 공감함
    Go 언어는 애초에 의존성 지옥이 없었음, npm의 문제는 문화적 요인 때문임
    이제는 유틸보다는 실제 동작하는 제품을 만드는 게 더 가치 있고 재미있음

    • Go의 격언처럼 “조금의 복사는 조금의 의존성보다 낫다”는 철학이 있음 (Go Proverbs)
    • Go의 어떤 기능이 이런 의존성 문제를 막았는지 궁금해하는 질문도 나옴

  • 나는 마이크로 의존성 자체가 무의미하다고 생각함
    차라리 함수 목록을 Markdown에 적어 복사하게 하는 게 낫다고 봄
    C의 헤더 파일 기반 소형 라이브러리 접근이 더 실용적임

    • “그렇다면 왜 이런 헤더 라이브러리를 표준 C 라이브러리에 포함하지 않느냐”는 농담 섞인 반응이 있었음
    • 하지만 “복붙 방식이면 보안 업데이트는 어떻게 하느냐”는 현실적인 반론도 나옴

  • “이제 어떤 형태의 오픈소스가 의미가 있을까”라는 질문이 제기됨
    공개한 코드가 결국 AI 학습 데이터로 흡수되기 때문임
    그래서 완전한 FOSS 대신 source-available 모델이 대안이 될 수 있다고 봄

    • “더 많은 사람이 쓸 수 있다면 그게 바로 오픈소스의 이점 아닌가?”라며 반박함
      저자는 기여의 의미가 단순한 이름 표기보다 크다고 강조함
    • 하지만 “source-available도 결국 학습에 쓰일 것”이라며 회의적인 의견도 있음
    • “세상에 공짜로 지식을 줄 의무는 없다”며 상호성 없는 공유를 거부해야 한다는 주장도 나옴
    • “비자유 코드를 배포하는 건 비윤리적”이라며 자유 소프트웨어 원칙을 지켜야 한다는 의견도 있었음
    • 어떤 이는 “이제 오픈소스에 흥미를 잃었다”며 모든 프로젝트를 비공개로 전환했다고 밝힘

  • 나는 오픈소스가 사라지지 않고 오히려 더 강해질 것이라 믿음
    진짜 창의적인 개발자들이 AI를 활용해 기업이 못 만드는 혁신을 만들어낼 것임
    오픈소스는 여전히 진짜 가치 검증의 장이며, AI를 통해 한계를 넘어 배우는 공간임

    • 진정한 혁신은 오픈소스에서 나올 것임
      하지만 정부와 대기업은 로컬 AI 시스템을 규제하려 할 것이고, 곧 “시민이 사용할 수 있는 AI”의 경계가 생길 것이라 예측함
    • 반면, 오픈소스 프로젝트는 이미 AI 생성 코드 제출로 골머리를 앓고 있음
      검토와 정책 논의에 시간 낭비가 늘고, 특히 컴파일러 같은 복잡한 분야에서는 AI가 전혀 도움이 되지 않음

  • 어떤 이는 “패키지로 추가되지 않아도, 코드를 공개하는 행위 자체가 여전히 가치 있다”고 강조함

    • 나도 작은 코드 조각을 발견하면 복사해 내 표준에 맞게 수정함. 과학의 공유 정신과 같다고 느낌
      LLM이 대신 코드를 짜주면 학습 부담이 줄고, 더 깊은 주제에 집중할 수 있음
    • Copyleft 라이선스가 더 낫다고 봄. 기업이 함부로 가져다 쓰지 못하게 하고, 대신 직접 인력을 고용하게 만듦
    • 실행하지 않아도 남의 코드를 읽으며 배우는 건 큰 가치임. 문제 해결 자체가 선물이라고 생각함
    • 하지만 오픈소스는 결국 시간과 노동의 투자임.
      예를 들어 14년간 rubygems.org를 유지하다가, 기업화된 구조에 실망해 떠났다고 밝힘

  • “AI로 코드를 작성하는 것도 결국 의존성의 한 형태”라는 지적이 나옴
    검증 없이 붙여넣는 건 외부 라이브러리를 추가하는 것과 다르지 않음

    • 하지만 LLM이 생성한 코드는 필요에 맞게 좁게 설계될 수 있어, 불필요한 기능이 줄고 효율적일 수 있음
    • 또, 공급망 공격이나 잦은 업데이트 부담이 없다는 점에서 장점이 있음
    • 반대로, 라이브러리는 시간이 지나도 자동으로 현대화되지만, LLM 코드 조각은 그렇지 않다는 점이 단점임
    • 결국 문제는 도구가 아니라 검증 없이 복붙하는 습관임. 무책임한 개발자는 어떤 도구를 써도 같은 결과를 냄
답변달기