AI 도구 사용 기여 시 공개 필수

• 오픈소스 프로젝트 Ghostty의 PR 토론에서, AI 도구 사용 여부를 명시적으로 공개해야 한다는 의견이 제기됨
• 제안자는 AI가 여전히 낮은 품질 코드를 생성하는 경우가 많고, 특히 미숙한 사용자가 검토 없이 제출할 때 문제가 크다고 지적함
• 공개 목적은 유지보수자가 PR의 신뢰도를 평가하고, 인간 기여자에게는 교육적 피드백을 주지만 단순 AI 생성물에는 불필요한 노력을 줄이기 위함임
• 또 다른 참가자는 PR 템플릿을 통해 AI 사용 여부를 포함한 체크리스트를 추가할 수 있다고 제안함
• 한편, AI 도구가 자동으로 특별한 byline을 표준화해 GitHub 커밋 메시지에 기록되도록 하면, 투명성과 도구 노출이 동시에 보장된다는 아이디어도 제시됨

---

AI 사용 공개 필요성

• Mitchellh는 AI 도구 사용을 좋아하고 본인도 활용하지만, 현재는 동등하거나 더 나은 품질을 보장하지 못하는 상황이라고 평가
  • 특히 검토 능력이 부족한 초보자가 AI 코드를 그대로 PR에 올리는 경우, 품질이 매우 낮음
  • 이런 상황에서 유지보수자가 불필요한 검토와 피드백에 시간을 쓰게 되는 것은 “속이는 행위” 라고 비판
• 따라서 AI 사용 여부를 명시적으로 공개하면 유지보수자가 어느 정도 주의 깊게 검토해야 할지 판단할 수 있음

PR 템플릿 도입 제안

• Yawaramin은 GitHub의 PR 템플릿 기능을 활용해 AI 사용 여부를 포함시키자고 제안
  • 동시에 Developer Certificate of Origin(DCO) 같은 체크리스트도 포함 가능
• 이를 통해 모든 기여자가 일관된 방식으로 AI 활용 사실을 알릴 수 있음

GitHub 표준화 아이디어

• Tobi는 GitHub 차원에서 AI 전용 byline 표준을 만들 것을 제안
  • AI 도구가 사용될 때마다 .git 스테이징 파일에 기록되고, 커밋 메시지에 자동 추가
  • GitHub은 이를 목록화하고 도구에 링크 제공 → 유지보수자는 출처를 확인할 수 있음
  • 동시에 AI 도구들은 현재처럼 co-authors를 스팸처럼 남용하지 않아도 됨
• 이 방식은 투명성 보장, 도구 홍보, 유지보수 효율성을 모두 충족하는 방안으로 평가됨

[GN⁺]

Hacker News 의견

• "AI"를 사용할 때에도 지적 재산권 오염 문제가 발생함을 지적함, 우리는 이 사실을 외면하고 있음, 누군가가 모든 오픈소스 프로젝트 코드를 외우고 필요할 때마다 그대로 써줄 수 있다면 그런 사람을 우리 회사에선 당연히 금지해야 함, 그런데 AI의 경우엔 여러 합리화와 핑계를 대면서 그 사실을 부인하고 있음, 실제로 GPL을 포함한 다양한 코드를 느슨하게 세탁하는 식이며, 이건 지식재산권(IP) 기반 기업엔 치명적인 위험을 내포함
  • 미국 법원들은 학습 데이터 사용이 변형적(transformation) 용도임을 이미 판결한 바 있음, 세부 조율할 일은 많겠지만 결국은 돌이킬 수 없는 변화임, IP 창출이 경제적으로 지속 가능한 활동이 되길 원한다면 관련 법 체계도 바꿔야함
  • 이 논리를 따르면 StackOverflow나 거의 모든 분야의 교과서 또한 금지해야 함, 현실적으로는 프로그래머들은 어쩔 수 없이 다른 사람의 코드를 보게 됨
  • 실제로 금전적으로 연관된 사람 외에는 AI 관련 법적 이슈를 심각하게 생각하지 않는다고 봄, 다행히 대부분의 경우 이 이슈를 무시하고 있으며, 법체계도 진보를 막지 않는 선에서 잘 작동하고 있음
• mitchellh의 "신입 기여자들을 끝까지 도와주고, PR이 머지되도록 돕는다"는 부분을 아주 인상 깊게 생각함, 피드백을 줘서 신입 개발자가 성장하는 건 정말 값진 일임, 하지만 만약 PR 제출자가 그 피드백을 AI에 바로 던져서, 본인은 아무것도 배우지 않는다면 그건 시간 낭비임
  • 이제 신입 개발자들은 AI 없이 일하는 환경 자체가 없게 될 것임
• 오늘의 HN 첫 페이지가 현실적인 경험 위주의 좋은 콘텐츠들로 채워져서 기분이 매우 좋음, 쓸데없는 공포나 과장 없이 솔직한 이야기가 많음, 개인 컴퓨터에선 AI 어시스트를 꺼두고, 회사에서도 정말 필요한 상황에만 아주 제한적으로 사용함, AI 어시스트는 작은 단위의 작업(atomic work)에 아주 강점이 있으나 복합적인 작업(compound work)엔 형편없음, 결론적으론 AI는 결국 인간이 어떻게 활용하느냐에 달림, 인간 지능이 핵심임
  • "AI는 인간이 다루는 만큼만 똑똑하다"는 말에 점점 동의하게 됨, 같은 AI를 두고 완전히 다른 결과가 나오는 것이 이해 안 됐었지만, 진짜로 AI가 마법은 아니라는 걸 체감함, 팀원끼리 설명도 못하는 사람들이 AI에게 가치를 끌어낼 수 있을 것이라 기대했었던 자신이 naïve했다고 생각함, 오히려 AI가 평범한 엔지니어와 뛰어난 엔지니어 간의 격차만 더 벌릴 듯함, 아직 기분이 복잡하지만 왜 어떤 사람들에게 AI가 무용하다고 느껴질 수 있는지 이해하게 됨
  • Frederik P. Brooks의 “No Silver Bullets, Refired” 에서, 소프트웨어 개발이 본질적으로 복잡하며, 혁명적 해법을 마냥 기다리기보다 점진적 생산성 향상을 추구해야 한다는 결론을 인용함, 이 관점은 현실적이고 희망적으로 다가옴
  • "AI는 인간이 다루는 만큼만 똑똑하다"는 말에 흥미로움을 느낌, 결국 "나 AI로 하루 만에 쿨한 라이브러리 만들었어"라는 포스팅의 주인공들은 애초에 실력이 좋은 개발자였음
  • 자신도 공감함, 회사에서 해킹 주간이라 AI 툴을 전사적으로 실험하고 있는데, 분석적 어프로치, 가드레일, grounded generation 등 실제 적용에서 좋은 결과가 주로 나옴, 최근에는 쓸데없는 챗봇 열풍이 지나고 머신러닝 본질로 패러다임이 리셋된 느낌임
  • 인간이 핵심 결정을 내리고, 그 다음 AI가 나머지를 연결해준다고 생각함, 핵심 결정이란 게 무엇인지, 점만 단순히 연결만 하는 작업이 무엇인지 도메인마다 다르지만, 실제로 대부분의 코드(80~90% 정도)는 단순 반복/연결 작업임, 이 경계만 잘 지키면 생산성 상승이 아주 큼, 반대로 AI에게 핵심 결정을 맡기면 더 큰 손해가 남, 오히려 버리고 다시 하는 게 나음, 핵심 결정 예시로는 데이터베이스 설계, 타입 정의, 의존성, 시스템/인프라/화면 설계, 테스트 항목 선정, 코드 조직 구조 등이 있음, 반면 AI가 잘 할 수 있는 일은 CRUD, API 핸들러, 간단한 데이터 구조 변환, 배포 스크립트, 테스트 구현, UI 컴포넌트 코드, 스타일링, 임시 데이터 정리 등임, 역시 AI가 리서치와 아이디어 탐색, 대안 탐구 등에서 도움 되나, 결론과 실제 구현은 인간이 직접 챙겨야 함
• 자신은 AI를 대단히 좋아하는 사람은 아니나, 그냥 도구 중 하나로 봄, 누가 PR을 어떻게 준비했든 결과만 괜찮으면 신경 안 씀, 다만 PR 제출 전에 메인테이너가 뭔가 요구하면 그에 맞춰주는 게 예의라고 생각함
  • PR이 어디에서 왔는지, 어떻게 나왔는지는 중요함, 리뷰어도 실수하고 한계가 있기 때문에 신뢰가 중요해짐, 신뢰가 없으면 아예 리뷰 프로세스에 받아들여선 안 됨, 리눅스 커널 팀이 미네소타대학을 실험 때문에 차단한 것도 이와 같은 이유임
  • 글의 핵심 논거, 즉 "신입 기여자가 성장할 수 있도록 도와주는 게 목표이나, 만약 상대가 AI라면 시간 낭비일 뿐이다"라는 부분에는 제대로 답하지 않은 것 같음
  • AI로 하루에 1,000개 PR도 만들 수 있음, AI로 잘 만든 PR만 생각하는 듯하지만, 현실에선 AI로 프로젝트 메인테이너를 엄청나게 힘들게 할 수도 있음
  • 미국 저작권 사무소에 따르면, AI가 생성한 결과물은 저작권 보호 대상이 아님, 그렇기에 라이선스 목적으로라도 AI 사용 사실 공개가 필요함, 이를 위반하면 전체 작업물의 저작권을 잃을 수 있음, 자세한 내용은 보고서와 메인페이지 참고
  • AI를 사용하고 해당 사실을 묻는다면 항상 공개할 것임, 다만 구체적으로 묻지 않았다면 '관례적인 예의상 미리' 밝히진 않겠음, 대부분의 사람들이 AI 사용을 당연시하거나 신경도 안 쓴다고 생각하며, 오히려 주의를 분산시키는 사소한 표시라고 느낌, dependabot처럼 알림이 와도 실제 관심이 안 생김
• "내 오토컴플릿은 어떡하냐"라는 질문이 몇 번 나왔는데, 단순 탭 오토컴플릿처럼 키워드, 짧은 구절이면 공개 안 해도 된다고 정책 문서에서 명확히 예외 규정이 있음, 문서(혹은 PR)을 제대로 읽어보라고 권함
• 이번 정책은 추가 맥락 설명이 들어 있어서 납득이 감, 이전에 봤던 여러 AI 관련 정책들은 이념 선언에 가까웠는데, 여기는 요구 이유와 앞으로의 방향을 제시해 줘서 훨씬 현실적임, 이런 방식이 더 많아졌으면 좋겠음
• 이 정책이 결국 정직한 사람이 AI를 쓰기 힘들게 만들지 않겠냐는 걱정이 있음, 어차피 AI 썼다고 하면 PR이 덜 주목받을 테니 다 숨기려 하지 않겠냐는 질문임
  • 그렇게 단순하지 않다고 생각함, 정책을 낸 사람(mitchellh) 본인도 LLM을 쓰기 때문에, 본인이 한 작업에 대해 충분히 이해한 상태에서 편의용으로 AI 썼음을 설명할 수 있다면 크게 신뢰를 잃지 않을 것이라 봄
  • 우려가 현실이 될 수 있음, AI가 "대충 맞는 것처럼 보이지만 실제로는 엉망"인 코드를 대량으로 만들어내기 때문에, 만약 AI 코드에 불신이 쌓이면 그건 AI 문제이지 사람 문제는 아님, 더 발전된 AI 코딩 툴이 필요함
  • "chat-gpt 사용했다"고 밝히면 바로 묻히고, 아무 말 없이 지식 있는 척하면 칭찬받음, 이미 모두가 AI 사용을 숨기는 방향으로 가고 있음
  • 이걸 문제로 보는 것 자체가 별 의미 없다고 생각함
  • "AI 쓰지 말라"는 게 아니라, 사용했다면 솔직하게 PR에 밝히라는 취지임
• "ChatGPT로 코드베이스를 이해하는 데 도움 받았으나, 실제 코딩은 직접 함" 같은 상세 공개도 요구하는 이유가 뭔지 궁금함
  • 이런 설명을 남기면, 리뷰어 입장에서 "코드베이스 이해"라는 부분에서 오해/착오가 리뷰 포인트가 될 수 있으니 집중할 수 있음
  • 본인은 개발자가 아니지만, 이런 AI 어시스턴트 덕분에 코드 탐색 시간이 현저히 단축됨, 개인적으로 AI가 정말 큰 도움을 줬음
• PR 생성에 사용한 각 프롬프트를 포함하는 패턴이 좋다고 생각함, LLM은 완전히 결정적인 도구는 아니지만, 어떤 단계/프롬프트를 거쳐 결과에 도달했는지 맥락을 남긴다는 데에 의의가 있음
  • 현실적으로는 매우 비실용적임, AI 기반 PR 하나 만드는 데에도 10~20개 프롬프트, 테스트, 수동 문맥 조정, 수동 코딩 등 여러 절차가 섞이기 때문임, 차라리 화면 녹화가 낫다고 생각함
  • 본인은 vscode 플러그인(specsytory)과 cursor 조합으로, 모든 LLM 상호작용 로그를 md로 남기고 Pull Request에 함께 제출, 코드 리뷰 때 참고함
• 개인 프로젝트에서는 에디터 오토컴플릿 사용 여부까지 공개하도록 규칙을 정함
  • 의도 전달 방식은 흥미로우나, 지금 AI는 기존 오토컴플릿과는 완전히 다름, 오토컴플릿처럼 쓸 수도 있지만 AI가 할 수 있는 일은 훨씬 다양하고 깊음, AI를 단순 자동완성 정도로만 생각하는 건 개인적인 관점일 뿐, 많은 사람들은 그렇게 쓰지 않음
  • 탭 오토컴플릿은 정책에서 명확히 예외로 인정하고 있음
  • 오토컴플릿은 대부분 문법적 도구에 불과하지만, AI는 코드의 의미와 구조까지 가이드하려고 시도함