현재 일부 사용자가 LLM에 의해 완전히 생성된 플러그인, 테마 또는 컴포넌트를 업로드하면서 이를 명시하지 않는 경우가 있을 수 있습니다. 어떤 것이 LLM에 의해 완전히 생성되었는지 아는 것이 유용한 이유는 여러 가지가 있으며, 현재로서는 해당 플러그인이 LLM 생성임을 공개할 의무는 없습니다. 개인적으로는, LLM 플러그인에서 흔히 발생하는 성능/최적화/UX 문제를 가진 저품질 플러그인을 설치하지 않도록 하기 위해 사전에 알고 싶습니다.
물론 이는 사람들이 솔직하고 투명하게 정보를 제공해야 한다는 전제에 달려 있습니다(AI 생성된 주제를 가진 사람들은 해당 내용이 무엇을 의미하는지 정확히 알지 못할 수도 있지만요). 그러나 주로 AI로 생성된 자산에 #ai-generated와 같은 태그를 붙이는 것은 모든 사람에게 유익할 것입니다.
LLM이 생성한 플러그인이 본질적으로 저품질이거나 반드시 성능, 최적화 또는 UX 문제를 겪는다는 주장에 동의하지 않습니다. 결과물의 품질은 LLM을 활용하고 그 출력을 검토하는 사람의 역량에 크게 좌우됩니다.
저는 지난 40년간 개발해 온 소프트웨어에 자부심을 갖고 있으며, 워크플로우에 LLM을 도입한 것은 제 작업의 품질을 떨어뜨린 것이 아니라 오히려 향상시켰습니다.
반대로, 수동으로 작성된 플러그인 중에는 보안 취약점, 성능 문제, 잘못된 설계 결정으로 가득 차 있어 개발자가 LLM을 활용했으면 좋았을 것이라는 생각이 드는 경우를 많이 봤습니다. 결국 중요한 것은 개발자의 역량과 그 결과로 나오는 코드의 품질이지, LLM이 작성 과정에 관여했는지는 아닙니다.
LLM이 생성한 코드를 검토하거나 업데이트하는 방법에 대해, 새로운 기능을 구현하거나 실제로 배포된 기능을 커스터마이징하기 위해 바이브 코딩(vibe-coding)에 입문하는 우리에게 어떤 조언을 주실지 궁금합니다.
공개 저장소에서 이루어지는 집단적 리뷰가 이상적이라는 것은 알고 있지만, 먼저 제 할 일을 제대로 해보고 현재 제 역량을 모두 발휘한 버전만 공개하고 싶습니다.
앞서 언급된 댓글에 동의합니다. AI를 반대하는 것은 아니지만, 동시에 AI가 생성한 모든 것이 반드시 인간에 의해 감사(audit), 검증 및 업데이트되어야 한다는 점을 인식하고 있습니다.
관련해서 흥미로운 사례가 하나 있습니다:
이 의견은 전적으로 타당하며, 결국 저는 제 자신에 대해서만 발언할 수 있습니다. 제가 관찰해 온 것은 모두 똑같이 보이며 기능과 보안 모두에서 전반적으로 품질이 낮은 저품질 ‘슬롭(slop)’ 앱들입니다. 또한, LLM으로 작업을 대거 외주화하기 시작한 이후 품질이 심각하게 하락한 기존 앱들(예: Visual Studio Code와 Formbricks. 저는 이 둘을 모두 더 이상 사용하지 않습니다)도 포함됩니다. 앱이 완벽하더라도 여전히 윤리적 우려가 있으므로, 제안된 바와 같이 이러한 생성물에 대한某种 형태의 알림이 있다면 좋겠습니다. 이는 누구나 해당 태그를 근거로 무언가를 해야 한다는 의무를 지우는 것은 아니지만, 그렇게 원한다면 해당 옵션이 있는 것은 좋은 일입니다.
말씀드린 바와 같이, 이는 본질적으로 신뢰에 기반한 시스템이며, 해당 사항을 그렇게 태그하는 것은 전적으로 개발자의 책임입니다. 물론 LLM이 git 로그에 스스로를 태그하는 경우(대부분 그렇습니다)가 있으므로, TL3 이상은 원할 경우 GitHub를 확인하여 조치를 취할 수 있습니다.
답변해 주셔서 감사합니다. 제 질문은 여러분 모두에게도 해당되며, 현재 LLM이 생성한 코드를 검증하는 데 사용할 수 있는 도구에 관한 것입니다.
저는 개발자가 아니지만, Discourse에 존재하지 않던 기능을 구현하는 데 성공했습니다. 그리고 제 능력 범위 내에서 최선의 방식으로 일을 하고 싶습니다.
저장소를 공개하게 된다면 태그를 붙이는 것을 고려해 보겠습니다. 현재는 테스트 중이므로 의도적으로 비공개로 유지하고 있으며, 커뮤니티에 배포하기 전에 올바르게 진행하는 데 관심이 있습니다.
대부분의 Core 코드(코어 플러그인 포함)가 이제 코딩 에이전트를 사용하여 개발되지 않았다면 극도로 놀라울 것입니다. 개발 방식이 얼마나 변했는지를 생각하면 당연한 일입니다.
개인적으로, 대부분의 작업에서 코딩 에이전트를 사용하지 않는 것을 정당화하기는 이제 매우 어렵습니다. 효율성이 크게 떨어지는 것은 사업적으로 의미가 없기 때문입니다.
플러그인이 어떻게 형성되었는지, 장인(匠人)이 연필을 썼는지 펜을 썼는지에 대해서는 전혀 신경 쓰지 않습니다.
"AI는 사용하지 않습니다"라는 말은 테마나 플러그인을 설치할 때 제게 조금이라도 더 신뢰감을 주지 않습니다.
그러나… CDCK에서 우리가 반드시 해결해야 할 훨씬 더 심각한 문제가 있습니다.
Discourse의 코어 플러그인과 소스 코드는 정기적으로 보안 스캔을 받으며, 지원되는 채널을 설치하는 사용자는 해당 코드의 보안 수준에 대해 어느 정도 신뢰를 가질 수 있습니다.
하지만 여기의 서드파티 플러그인과 테마는 '야생의 서부’와도 같습니다. 누구나 기여할 수 있고, 우리는 이들을 보안 스캔하지도 않으며 모범 사례를 따르고 있는지 확인하지도 않습니다. 이는 커뮤니티에 위험을 초래합니다.
테마의 "버전 XYZ"가 최소한 자동으로 스캔되어 셀프 호스터들이 최소한의 신뢰를 가질 수 있는 세상이 되기를 바랍니다.
따라서 제 비전은 정반대입니다. 
서드파티 테마와 플러그인의 버전이 여기에서 광고되기 전에 어떤 형태의 AI 스캔을 통과하도록 요구하는 것입니다.
LLM을 이용한 코드 리뷰는 "클로드, 이 앱을 만들어줘. 실수하지 마"라고 시킨 뒤, 스스로 거의 검증이나 수정을 하지 않은 채 출력을 그대로 게시하는 것과 완전히 다릅니다. 적어도 윤리적 측면에서 저는 그렇게 생각합니다. 불행히도 최종 사용자에게 책임감을 강요할 수는 없으며, 아무리 노력해도 누군가는 악성 코드를 다운로드하는 방법을 찾아낼 것입니다. 하지만 어쨌든 LLM의 윤리성은 별도의 논의 사항이며 이 스레드와는 직접적인 관련이 없습니다.
그리고 그것은 괜찮습니다! 저는 Customization 게시판에서 AI가 관여된 모든 것에 대해 전면적인 금지를 주장하는 것이 아닙니다. 다만, 제대로 태그를 달아주셔서 그 '거북이 통’을 열고 싶지 않은 분들이 우연히 열어보지 않도록 하고 싶을 뿐입니다.
LLM 기반 도구(그리고 그 결과물)에 대해 많은 문제를 제기합니다. 보안, 법적, 신뢰성 및 환경적 문제뿐만 아니라 말입니다. 하지만 여기서는 그 문제가 핵심이 아닙니다.
여기서 중요한 문제는 넓은 의미의 보안입니다. 코드가 AI로 생성되었든 아니든 상관없이 말입니다.
CDCK은 보안 검사를 위해 어떤 도구를 사용합니까? 그중 일부는 서드파티 제작물에도 중요할 것입니다.
그러나 확인해야 할 것이 더 많습니다. 서드파티 제작물이 어떤 외부 시스템과 통신하는지 확인해야 합니다. 대부분의 보안 분석 도구는 소프트웨어가 하트비트(heartbeat) 없이 외부 서버와 통신하는 것을 허용합니다. 하지만 순수하게 장식적인 테마 컴포넌트는 외부 서버에 대한 호출을 수행해서는 안 됩니다. 따라서 서드파티 제작물은 보안 구멍을 포함하거나 가용성을 해칠 수 있는 문제를 포함할 수 있습니다. 또한 데이터를 탈취(exfiltrate)할 수도 있습니다.
저는 이 의견에 95% 동의합니다. 그리고 지금 우리는 Discourse에 대해 이야기하고 있는데, 만약 우리가 WordPress 세계에서 같은 상황을 마주하게 된다면 어떨지 상상해 보세요!
(남은 5%에 대해: ‘야생의 서부’라고 생각하지는 않습니다. 보안 문제는 메타를 통해 해당 제3자 개발자에게 보고되며, 일반적으로 꽤 빠르게 수정됩니다.)
하지만 동시에, 제 경험상 LLM(대규모 언어 모델)은 (요즘에는) 평균적인 인간 플러그인 작성자보다 더 안전한 코드를 생성합니다. 그리고 어떤 괜찮은 LLM에게도 플러그인을 던져서 “보안 문제를 찾아서 수정해 줘”라고 요청하면, 인간이 보안 지식이 거의 없더라도 LLM은 이를 수행합니다.
지난 10년간 저는 수동으로 플러그인을 검토해 왔으며, 많은 것을 보았습니다: (ActiveRecord가 너무 복잡하다고 생각한 사람들이 만든) SQL 인젝션, client: true가 설정된 API 키 설정, 인증 및 접근 제어의 완전한 부재, 레이트 리미팅의 부재. 이 모든 것은 LLM이 거의 노력 없이 순식간에 찾아서 수정합니다.
따라서 다시 말하지만: 저는 LLM이 이를 더 나쁘게 만든 것이 아니라 더 좋게 만들었다고 생각합니다.
여전히 LLM이 생성한 코드를 ‘그 통(can of worms)’과 연관짓고 있는데, 그건 너무 흑백논리입니다.
Jack McDade는 Statamic 애드온 디렉터리에서 이러한 접근 방식을 채택했습니다.
저는 이 접근 방식을 환영하며, 이미 수행해야 할 필요가 있음을 알고 있던 것을 확인하는 데 유용했습니다. 또한 코드에 대한 신뢰도를 높이는 데에도 도움이 됩니다.
팀이 지나치게 큰 부담 없이 이곳에서도 유사한 것을 구현할 수 있을 것 같습니다.