현재 일부 사용자가 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 애드온 디렉터리에서 이러한 접근 방식을 채택했습니다.
저는 이 접근 방식을 환영하며, 이미 수행해야 할 필요가 있음을 알고 있던 것을 확인하는 데 유용했습니다. 또한 코드에 대한 신뢰도를 높이는 데에도 도움이 됩니다.
팀이 지나치게 큰 부담 없이 이곳에서도 유사한 것을 구현할 수 있을 것 같습니다.
저품질 플러그인과 컴포넌트에도 우려를 가지고 있으며, 프로그래밍에 대해 잘 모르는 사람이 99%는 직관(vibe)에 의존해 코딩한 것이라 생각되면 신뢰하기 어렵습니다.
하지만 여기저기서 경험 많은 프로그래머들이 AI 이전에도 나쁜 프로그래머들이 존재했다고 말하는 것에 동의합니다. 대충 작성되고 신뢰할 수 없으며 결함이 있는 코드는 예전부터 수작업으로 만들어져 왔으니까요.
제가 우려하는 것은 직관(vibe) 코딩으로 만들어진 앱/플러그인/그 외 무엇을 보고, 작성자가 코드를 검토하지 않았을 것이라 추측할 때입니다.
저는 프로그래밍에 대한 기본적인 지식은 있지만, 오랫동안 코딩을 하지 않았고, 예전부터 잘하는 편도 아니었습니다. 몇몇 프로젝트에 대해 직관 코딩을 시도해 보았습니다.
처음에는 메타에 공식적으로 공개하는 것에 매우 망설였지만, 각 코드 조각이 무엇을 하는지 검토하고 이해하는 데 시간을 할애하고, 또한 제 접근 방식을 제 주제에서 공개적으로 설명한 후에야 마침내 공개하게 되었습니다. 게시하기 전에 읽은 모든 것을 기억하는 것은 아니지만, 적어도 그 시점에 제 작업의 신뢰성과 안전성을 보장할 수 있었습니다.
직관 코딩이 얼마나 위험한 플러그인을 배포하게 만들 수 있는지 설명할 좋은 예시가 있습니다.
🖼️ Topic Gallery 작업을 시작하기 전에, 저는 여기서 유사한 플러그인의 개념 증명을 만들었습니다: A way to monitor user-uploaded files 🖼️ - #2 by Canapin
잘 작동했고, AI는 제 지시를 따랐습니다.
하지만 문제가 있었습니다: 해당 기능이 명확히 모더레이션 기능임에도 불구하고, AI는 권한을 고려하지 않았습니다. 방문자를 포함한 모든 사용자가 이 페이지를 열고 모든 사용자가 업로드한 파일을 볼 수 있었습니다. 제게는 관리자 전용이어야 한다는 것이 분명했지만, AI는 그렇게 "생각"하지 않았습니다. 그리고 제가 요청하지 않았기 때문에, 기본적으로 공개 페이지를 만들었습니다.
그래서 저는 계속 스스로에게 말합니다. 저와 AI가 이러한 보안 누락을 놓칠 수 있다면, 코딩을 모르는 사람들이 직관 코딩으로 TC와 플러그인을 만들 때 불행히도 같은 일이 일어날 수 있다고요.
소프트웨어에서 AI 코딩에 대한 의견은 극단적으로 양극화되어 있습니다. Claude가 최근 커밋의 공동 저자로 언급되는 인기 있는 오픈소스 프로젝트만 봐도 특정 사람들의 증오의 폭풍을 볼 수 있습니다.
저는 이런 것들을 신중하게 접근해야 한다고 확신하며, 우리의 의견은 더 정교해야 한다고 생각합니다.
잘 작성되고 안전한 커스터마이징과 그 작성자의 인기를 불필요하게 해칠 수 있는 vibe-coded 태그와 같은 것이 있는 것을 특별히 지지하지는 않습니다.
이제 누구나 커스터마이징을 만들 수 있고, 매일 더 많은 것이 등장하며, 이를 검토할 사람이 부족하다는 것을 알고 있습니다.
AI 리뷰가 해답일 수도 있습니다. 여러 이유로 제 직감은 이 아이디어를 별로 좋아하지 않지만, Sam이 이런 종류의 솔루션을 제안한다면 그것은 아마도 좋은 것일 것이라고 믿습니다. 왜냐하면 저는 그의 기술과 판단력을 매우 신뢰하기 때문입니다. 특히 저 자신은 아무것도 모르기 때문입니다. 
여기서 프로그래밍과 Discourse 생태계에 대해 잘 아는 개발자들이 이 분야의 전문성을 명시적으로 보여주는 칭호를 가질 수 있다면, 등록하지 않고 단순히 커스터마이징을 찾고 있는 방문자들도 신뢰할 수 있는 개발자로 인식할 수 있을 것입니다. 이는 darkpxlz님이 요청한 것의 정반대입니다. 잠재적으로 신뢰할 수 없는 커스터마이징을 “부끄럽게” 만드는 대신, 신뢰할 수 있는 것을 강조하는 것입니다.
단순히 생각의 소재일 뿐입니다. 
제가 소비하는 미디어와 매일 교류하는 사람들 사이에서 형성된 반-AI 에코 챔버에 갇혀 있을 수도 있습니다. 이 요청이 이렇게 인기가 없을 줄은 거의 확신하지 못했지만, 만약 여기 있는 모든 분들이 실제로 LLM을 활용한 코딩을 좋아하며 투명성을 위한 태그를 원하지 않는다면, 제가 그것을 막을 입장은 아닙니다. LLM 코드를 감지하는 것은 여전히 비교적 쉽기 때문에, 저처럼 그것을 정말로 피하고 싶은 사람은 이전에 제가 제안했듯이 기여자 목록에서 LLM이 스스로를 태그하는지 확인하면 됩니다.
논쟁적인 주제인 만큼, 저는 개인적으로 현재 더 회의적인 입장을 취하고 있는 커뮤니티의 일부(그것도 충분히 이해할 수 있습니다)를 위해 원래 요청하신 방향을 지지합니다.
하지만 거의 모든 것에 라벨을 붙이게 되면, 결국 그 의미가 퇴색되지 않을까 싶습니다?
또한 다른 분들 의견에 동의하듯, AI가 생성한 코드의 품질은 모두 동일하지 않습니다. 어떤 코드는 더 최신이고 비싼 모델에 의해, 경험 많은 개발자의 지휘 아래 작성되는 반면, 다른 경우에는 경험이 적은 사람이 덜 능숙한 모델을 사용하여 한 번에 생성한 것일 수 있습니다. 또한 저장소가 모범 사례를 따르지 않을 수도 있습니다. 이러한 점들을 판단하려면 저장소 자체를 검토하고, 사람들이 자주 문제를 겪고 있는지 관찰해야만 합니다.
인간과 AI 양쪽 모두의 철저한 리뷰는, 소프트웨어가 원래 인간에 의해 작성되었든 AI에 의해 작성되었든, 중요한 소프트웨어라면 모두 좋은 아이디어라고 생각합니다. 소프트웨어를 리뷰하고, 어떤 패키지의 어떤 버전을 누가 리뷰했는지를 추적하는 데 더 나은 도구가 있으면 좋겠습니다. 현재 Rust/Cargo에 대해 이와 유사한 것들이 몇 가지 있습니다: Crev, cargo-vet, 그리고 Thirdpass. 또한 Swift 포럼에서 토론을 시작했습니다.
저는 why 라벨을 지지하는 쪽입니다. 라벨을 붙일지 말지는 좀 부차적인 문제입니다. 제게 중요한 것은 플러그인 디렉토리의 코드/제품 품질을 확보하는 것이며, 이것이 최우선 과제입니다. 이 영역에 대해 Discourse가 최종적인 책임을 지지만, 커뮤니티도 도움을 줄 수 있습니다. 그 일환으로, 제 최신 BFF(가장 친한 친구)와 저는 DiscourseSkill.md를 만드는 작업을 했습니다. 원래 의도는 내부적으로 사용하는 것이었지만, 다른 분들도 유용하게 쓰실 수 있을 것 같습니다. 관심 있으시면 https://meta.discourse.org/t/discourseskill-md/412958을 한번 살펴보세요.