Hacker News 의견들

• 평생 코딩을 해왔지만 손목 부상으로 타이핑이 거의 불가능해진 이후, LLM과 AI 자동완성, 에이전트 기반 개발 덕분에 다시 고품질 코드를 낼 수 있게 되었음
  AI의 환각(hallucination) 도 오히려 프롬프트를 다듬고 의도를 명확히 하는 데 도움이 됨
  접근성 측면에서 AI는 나에게 필수적인 도구이며, “좋음이 나쁨을 상쇄하느냐”보다 생태계에 통합적으로 받아들이는 태도가 중요하다고 생각함

  • 네 말처럼 AI를 합리적으로 쓰는 사람도 있지만, 모든 사용자가 그렇다고 가정하는 건 위험함
    일부 프로젝트는 저품질 PR이 넘쳐나고, 기여자들이 단순히 GitHub 프로필을 채우려는 경우도 많음
    결국 중요한 건 “선의(good faith)”로 기여하는가의 문제이며, 프로젝트는 그 허용 범위를 명확히 해야 함
  • 나도 비슷한 접근을 함. AI에게 어려운 문제를 맡기기보다, 이미 내가 구현하려던 기술적 해법을 주고 코드를 생성하게 함
    이렇게 하면 리뷰 피로도가 줄고, 예상과 다른 부분만 집중적으로 검토할 수 있음
  • 나도 손목 통증이 있어 Whisper + LLM 조합으로 음성 입력과 정리를 함. 이메일, 문서 작성, 영수증 분류까지 자동화되어 건강에도 도움이 됨
    이제는 이런 기능을 막는 회사에서는 일하고 싶지 않을 정도임
  • 나도 RSI가 있어 AI 자동완성이 큰 도움이 되었음. 다만 에이전트형 AI는 실시간 C++/Rust 환경에서는 별로 유용하지 않음
    접근성 측면은 매우 중요하지만, 저작권과 책임 문제는 여전히 복잡함
  • 코드에 서명하고 자신의 전문성과 평판을 걸 수 있다면, AI는 단순한 고급 자동완성 도구일 뿐 “no AI” 규칙의 예외로 봐야 함

• PR(풀리퀘스트) 리뷰는 결국 신뢰의 문제라고 생각함. 제출자가 최선을 다했다고 믿는 것임
  AI 사용 여부보다, 그것을 책임감 있게 사용하는가가 핵심임

  • 물론 악의적인 행위자도 존재함. XZ 공격처럼 지속적 위협(APT) 이 오픈소스에도 현실임
    여러 가짜 계정이 하나의 공격자일 수도 있고, LLM이 만든 코드는 LLM이 보기엔 괜찮아 보이기 때문에 검증이 더 어려움
    결국 PR을 평가하는 게 만드는 것보다 더 어렵게 된 상황임
  • 하지만 나는 여전히 모든 코드를 잠재적 트로이 목마로 보고 검증해야 한다고 생각함
  • 리뷰 과정이 인간이든 AI든 오류를 잡아낼 만큼 견고해야 함

• AI 기여의 품질 논쟁은 이상함. 품질은 언제나 제출자의 책임임
  AI를 썼다고 해서 면책이 되는 건 아니며, 오히려 AI 사용 제한 정책이 선의의 기여자만 해칠 수 있음

  • 문제는 LLM 코드가 겉보기엔 좋아 보여도 실제로는 이해 없이 구현된 코드일 수 있다는 점임
  • 중요한 건 도구가 아니라, 기여자가 리뷰에서 자신의 코드를 설명하고 방어할 수 있는가임
    나는 AI로 300커밋짜리 포크를 유지하지만 모든 라인을 검토하고 설명할 수 있음
    결국 참여의 질이 핵심이지, 도구의 종류가 아님
  • 진짜 불변 조건은 책임감임. 패치를 제출했다면 그 설계와 유지보수까지 책임져야 함
  • 하지만 AI는 사람들에게 그 책임을 회피하게 만들 위험이 있음

• 장기적으로 AI가 발전하면 인간과 AI의 산출물을 구분하기 어려워질 것 같음
  결국 “충분히 좋은” 수준이 되면 인간이 만든 것처럼 보일 텐데, 그때는 어떤 일이 벌어질까 궁금함

  • 완벽히 막을 수는 없지만, 정책을 세워두는 것이 아무것도 안 하는 것보다 낫다고 생각함
    지금은 대부분의 AI PR이 저품질이지만, 품질이 높아져도 법적·이념적 이유로 거부할 수는 있음
  • AI 기여는 결국 개인의 확장으로 봐야 함. 계정이 실제 사람에게 속하고, 그 평판이 걸려 있어야 함
  • 갑자기 방대한 코드가 올라오면 AI 사용을 의심할 수 있음. 중요한 건 AI 사용 여부가 아니라 문제를 이해하고 있는가임
  • AI는 여전히 토큰 단위 예측에 머물러 있어서 인간이 설계한 코드와는 구별됨
    지나치게 세분화된 추상화나 불필요한 리팩터링이 흔함
    인간이 AI를 도구로 쓰는 건 괜찮지만, AI가 인간을 대체하는 수준은 아직 멀었다고 봄
    다만 vibecoding 남용은 리뷰와 유지보수 비용을 급격히 늘리고 있음
  • 결국 올바르게 사용하는 사람의 코드는 인간 코드와 구분되지 않음. 문제는 도구가 아니라 사용법임

• “작동하면 그걸로 충분함”이라는 입장임
  코드가 기능·문서·테스트·정확성 기준을 충족한다면 AI가 썼든 사람이 썼든 상관없음
  중요한 건 “작동의 정의”를 명확히 하고, 유능한 리뷰 체계를 갖추는 것임

• AI가 수천 줄의 코드를 한 번에 생성해 PR을 올릴 수 있지만, 결국 리뷰 가능한 크기로 제한해야 함
  AI가 테스트를 통과하더라도 작성자가 내용을 이해하지 못한다면 위험함
  작업 범위 제한과 이전 수작업 기여 이력이 필요함

• Debian의 정책은 단순함 — “누구도 상처받지 않게 하자”는 것임. 좋은 원칙임

• Debian이 다른 사람의 코드를 자기 것처럼 제출하는 걸 금지하는 규칙이 있느냐는 질문이 있었음
  사실상 저작권 침해로 불법이기 때문에 명시되지 않아도 암묵적으로 존재함
  LLM은 사람이 아니지만, 그 코드의 저작권은 여전히 불분명함

• 웹앱이나 모바일앱의 vibecoding은 상관없지만, 커널·컴파일러·운영체제 같은 핵심 인프라 소프트웨어에 AI를 쓰는 건 위험함
  이런 영역에서는 Ada/SPARK 같은 형식 검증 언어가 필요함
  언젠가 AI가 만든 제동 시스템을 단 자동차를 타게 될까 두렵다고 느낌

  • 동의함. 핵심 시스템에는 세심한 주의가 필요하고, LLM은 주의와 저작권 리스크 모두 부족함
  • 사실 자동차 업계는 이미 AI 이전부터 자동 생성 코드가 많았다고 들음

• “YOLO식 코드 제출”보다 “AI를 썼지만 최대한 검증한 코드”가 훨씬 더 받아들여질 만함