LLM이 생성한 테마와 플러그인에 해당 태그를 부여해야 합니다

현재 일부 사용자가 LLM에 의해 완전히 생성된 플러그인, 테마 또는 컴포넌트를 업로드하면서 이를 명시하지 않는 경우가 있을 수 있습니다. 어떤 것이 LLM에 의해 완전히 생성되었는지 아는 것이 유용한 이유는 여러 가지가 있으며, 현재로서는 해당 플러그인이 LLM 생성임을 공개할 의무는 없습니다. 개인적으로는, LLM 플러그인에서 흔히 발생하는 성능/최적화/UX 문제를 가진 저품질 플러그인을 설치하지 않도록 하기 위해 사전에 알고 싶습니다.

물론 이는 사람들이 솔직하고 투명하게 정보를 제공해야 한다는 전제에 달려 있습니다(AI 생성된 주제를 가진 사람들은 해당 내용이 무엇을 의미하는지 정확히 알지 못할 수도 있지만요). 그러나 주로 AI로 생성된 자산에 #ai-generated와 같은 태그를 붙이는 것은 모든 사람에게 유익할 것입니다.

1개의 좋아요

LLM이 생성한 플러그인이 본질적으로 저품질이거나 반드시 성능, 최적화 또는 UX 문제를 겪는다는 주장에 동의하지 않습니다. 결과물의 품질은 LLM을 활용하고 그 출력을 검토하는 사람의 역량에 크게 좌우됩니다.

저는 지난 40년간 개발해 온 소프트웨어에 자부심을 갖고 있으며, 워크플로우에 LLM을 도입한 것은 제 작업의 품질을 떨어뜨린 것이 아니라 오히려 향상시켰습니다.

반대로, 수동으로 작성된 플러그인 중에는 보안 취약점, 성능 문제, 잘못된 설계 결정으로 가득 차 있어 개발자가 LLM을 활용했으면 좋았을 것이라는 생각이 드는 경우를 많이 봤습니다. 결국 중요한 것은 개발자의 역량과 그 결과로 나오는 코드의 품질이지, LLM이 작성 과정에 관여했는지는 아닙니다.

6개의 좋아요

LLM이 생성한 코드를 검토하거나 업데이트하는 방법에 대해, 새로운 기능을 구현하거나 실제로 배포된 기능을 커스터마이징하기 위해 바이브 코딩(vibe-coding)에 입문하는 우리에게 어떤 조언을 주실지 궁금합니다.

공개 저장소에서 이루어지는 집단적 리뷰가 이상적이라는 것은 알고 있지만, 먼저 제 할 일을 제대로 해보고 현재 제 역량을 모두 발휘한 버전만 공개하고 싶습니다.

앞서 언급된 댓글에 동의합니다. AI를 반대하는 것은 아니지만, 동시에 AI가 생성한 모든 것이 반드시 인간에 의해 감사(audit), 검증 및 업데이트되어야 한다는 점을 인식하고 있습니다.

관련해서 흥미로운 사례가 하나 있습니다:

1개의 좋아요

이 의견은 전적으로 타당하며, 결국 저는 제 자신에 대해서만 발언할 수 있습니다. 제가 관찰해 온 것은 모두 똑같이 보이며 기능과 보안 모두에서 전반적으로 품질이 낮은 저품질 ‘슬롭(slop)’ 앱들입니다. 또한, LLM으로 작업을 대거 외주화하기 시작한 이후 품질이 심각하게 하락한 기존 앱들(예: Visual Studio Code와 Formbricks. 저는 이 둘을 모두 더 이상 사용하지 않습니다)도 포함됩니다. 앱이 완벽하더라도 여전히 윤리적 우려가 있으므로, 제안된 바와 같이 이러한 생성물에 대한某种 형태의 알림이 있다면 좋겠습니다. 이는 누구나 해당 태그를 근거로 무언가를 해야 한다는 의무를 지우는 것은 아니지만, 그렇게 원한다면 해당 옵션이 있는 것은 좋은 일입니다.

말씀드린 바와 같이, 이는 본질적으로 신뢰에 기반한 시스템이며, 해당 사항을 그렇게 태그하는 것은 전적으로 개발자의 책임입니다. 물론 LLM이 git 로그에 스스로를 태그하는 경우(대부분 그렇습니다)가 있으므로, TL3 이상은 원할 경우 GitHub를 확인하여 조치를 취할 수 있습니다.

답변해 주셔서 감사합니다. 제 질문은 여러분 모두에게도 해당되며, 현재 LLM이 생성한 코드를 검증하는 데 사용할 수 있는 도구에 관한 것입니다.

저는 개발자가 아니지만, Discourse에 존재하지 않던 기능을 구현하는 데 성공했습니다. 그리고 제 능력 범위 내에서 최선의 방식으로 일을 하고 싶습니다.

저장소를 공개하게 된다면 태그를 붙이는 것을 고려해 보겠습니다. 현재는 테스트 중이므로 의도적으로 비공개로 유지하고 있으며, 커뮤니티에 배포하기 전에 올바르게 진행하는 데 관심이 있습니다.

대부분의 Core 코드(코어 플러그인 포함)가 이제 코딩 에이전트를 사용하여 개발되지 않았다면 극도로 놀라울 것입니다. 개발 방식이 얼마나 변했는지를 생각하면 당연한 일입니다.

개인적으로, 대부분의 작업에서 코딩 에이전트를 사용하지 않는 것을 정당화하기는 이제 매우 어렵습니다. 효율성이 크게 떨어지는 것은 사업적으로 의미가 없기 때문입니다.

플러그인이 어떻게 형성되었는지, 장인(匠人)이 연필을 썼는지 펜을 썼는지에 대해서는 전혀 신경 쓰지 않습니다.

"AI는 사용하지 않습니다"라는 말은 테마나 플러그인을 설치할 때 제게 조금이라도 더 신뢰감을 주지 않습니다.

그러나… CDCK에서 우리가 반드시 해결해야 할 훨씬 더 심각한 문제가 있습니다.

Discourse의 코어 플러그인과 소스 코드는 정기적으로 보안 스캔을 받으며, 지원되는 채널을 설치하는 사용자는 해당 코드의 보안 수준에 대해 어느 정도 신뢰를 가질 수 있습니다.

하지만 여기의 서드파티 플러그인과 테마는 '야생의 서부’와도 같습니다. 누구나 기여할 수 있고, 우리는 이들을 보안 스캔하지도 않으며 모범 사례를 따르고 있는지 확인하지도 않습니다. 이는 커뮤니티에 위험을 초래합니다.

테마의 "버전 XYZ"가 최소한 자동으로 스캔되어 셀프 호스터들이 최소한의 신뢰를 가질 수 있는 세상이 되기를 바랍니다.

따라서 제 비전은 정반대입니다. :slight_smile: 서드파티 테마와 플러그인의 버전이 여기에서 광고되기 전에 어떤 형태의 AI 스캔을 통과하도록 요구하는 것입니다.

1개의 좋아요

LLM을 이용한 코드 리뷰는 "클로드, 이 앱을 만들어줘. 실수하지 마"라고 시킨 뒤, 스스로 거의 검증이나 수정을 하지 않은 채 출력을 그대로 게시하는 것과 완전히 다릅니다. 적어도 윤리적 측면에서 저는 그렇게 생각합니다. 불행히도 최종 사용자에게 책임감을 강요할 수는 없으며, 아무리 노력해도 누군가는 악성 코드를 다운로드하는 방법을 찾아낼 것입니다. 하지만 어쨌든 LLM의 윤리성은 별도의 논의 사항이며 이 스레드와는 직접적인 관련이 없습니다.

그리고 그것은 괜찮습니다! 저는 Customization 게시판에서 AI가 관여된 모든 것에 대해 전면적인 금지를 주장하는 것이 아닙니다. 다만, 제대로 태그를 달아주셔서 그 '거북이 통’을 열고 싶지 않은 분들이 우연히 열어보지 않도록 하고 싶을 뿐입니다.