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 코드 조각은 그렇지 않다는 점이 단점임
  • 결국 문제는 도구가 아니라 검증 없이 복붙하는 습관임. 무책임한 개발자는 어떤 도구를 써도 같은 결과를 냄