이것은 논리적으로 꽤 큰 도약입니다.
인턴을 고용하거나 본인이 10박을 새우며 작업했다면, 가상의 앱에 FLAC 플레이어를 추가할 수도 있었을 것입니다. 잘못된 제품 결정을 내리는 것은 LLM 사용에 내재된 문제가 아니며, 쓸모없는 기능을 추가하는 것이 개발 노력의 낭비인지는 항상 논쟁의 대상이었습니다.
추가 기능이 반드시 앱을 더 느리고 RAM 사용량을 더 많이 먹게 만드는 것은 아닙니다. 그 문제는 40년 전 동적 로딩(dynamic loading)이라는 개념으로 이미 해결되었습니다.
정확합니다. 강조한 부분은 제 생각입니다 
아니요, 이 구분은 이루어져서는 안 됩니다.
다시 제 원래 주론으로 돌아가겠습니다.
테마에 보안 문제가 있다면 검토 시스템을 논의해 봅시다.
테마에 품질 문제가 있다면 검토 시스템을 논의해 봅시다.
하지만 저는 게시글에 “맥에서 개발됨”, “빨간 키보드에서 개발됨” 또는 “AI 93.2%로 개발됨” 같은 스티커를 붙이지 않을 것입니다. 그런 일은 절대 일어나지 않을 것입니다.
제가 AI를 얼마나 많이 사용하는지에 대해서는, 별도의 게시글에서 워크플로우를 공유할 수는 있지만, 저는 더 이상 vim으로 수동으로 코딩하지 않습니다.
AI가 작성했다는 이유만으로 AI 생성 플러그인을 모두 거부하는 것은 유전적 오류(genetic fallacy)에 해당합니다. 과거에는 AI 생성이라는 점이 낮은 품질(슬랍)을 가늠하는 데 쓸 만한 휴리스틱이 될 수 있었지만, 모델이 개선되면서 인간과 AI의 출력물을 구별하기가 점점 더 어려워지고 있습니다. 품질이나 보안에 대한 우려라면, 어떤 형태의 크라우드소싱 동료 검토 시스템에 의해 검토되기 전까지는 모든 코드를 안전하지 않다고 가정하는 것이 더 안전하다고 생각합니다.
디자이너부터 코더, 심지어 법무, 마케팅 및 기타 분야까지 현재 팀이 AI와 함께 일하는 방식을 공유하면 많은 분들이 관심을 가질 것 같습니다.
저처럼 AI에 대해 조금 아는 것은 회사가 일상적으로 AI를 실제로 어떻게 활용하는지 알고 이해하는 것을 의미하지는 않습니다.
여기 있는 내용을 모두 읽어 보았고, 양쪽 입장을 모두 이해할 수 있습니다. 사람들이 단순히 플러그인을 만들어 여기에 게시할 수 있다는 점은 좋은 점이자 동시에 나쁜 점이라고 생각합니다. 특히, 디스코urs 설치 환경을 위협할 수 있는 ‘잠재적’ 보안 취약점을 포함하고 있는 경우 말입니다.
조금 주제에서 벗어난 이야기이긴 합니다.
예를 들어 WoltLab 같은 다른 포럼 소프트웨어 제공업체는 플러그인 스토어를 갖추고 있습니다. 이 업체에서는 모든 릴리스 전에 팀이 플러그인과 테마를 검토합니다. 여기서도 비슷한 제도를 도입하는 것이 아이디어가 될 수 있겠다는 생각이 듭니다. 다만, 누가 검토를 맡을 것인지에 대한 질문이 항상 제기되며, 상당한 시간과 인력 투자가 필요할 것이라고 상상해 볼 수 있습니다.
제3자 플러그인과 테마를 모두 검토하는 것은 실현 가능한 아이디어가 아니라고 100% 자신 있게 말할 수 있습니다. (적어도 사람이 수동으로 하는 것은 불가능합니다.)
LLM이 생성한 플러그인이나 TC를 테스트하기 위한 도구 세트를 팀이 감독하고, 유지보수하며, 업데이트하는 방식은 어떨까요?
각자가 개별적으로 테스트를 실행할 수 있다는 점은 알고 있지만, 솔직히 모든 사람이 방법을 알고 있는 것은 아닙니다.
간단하고 신뢰할 수 있는 실행 방법은 저에게 가장 이상적인 해결책으로 보입니다.
이 스레드의 핵심은 바로 이것입니다:
도덕적, 보안적 측면에서 이것이 왜 중요한지에 대한 사람들의 다양한 의견을 지켜보는 것은 흥미로웠습니다. 개인적으로, 그 앱이 수년간 루비를 해온 30년 경력의 소프트웨어 엔지니어가 만들었든, 코딩 경험이 전혀 없는 어린 팀미가 만들었든 상관없습니다. 만약 그것이 100% 대충 작성된 코드[1]라면, 저는 그것을 사용하지 않을 것입니다. 그렇게 하면 위선적이기 때문입니다. 왜 이것이 인기 있는지는 이해하지만, 저는 이에 동의할 수 있는 입장이 아닙니다.
플러그인에 대한 보안 우려는 전 세계적으로 유효하며, "이것이 AI가 만들었다"는 사실에 국한되지 않습니다. 그러나 이는 해결하기 어려운 문제이며, 이 주제의 범위를 벗어납니다. 이 주제는 단순히 LLM이 완전히 생성한 자산에 태그를 요구하는 것을 제안하는 것에 불과합니다.
"바이브 코딩"나 “에이전틱 개발” 같은 표현은 제가 거부하는 단어입니다 ↩︎
아직도 이 문제가 해결하려는 것이 무엇인지 이해가 안 됩니다. 바이브 코딩으로 만들어진 플러그인 중 엉성하거나, 보안에 취약하거나, 성능을 크게 저하시키는 사례를 하나만 예로 들어 주실 수 있나요? 완전히 쓸모없고 모두의 시간을 낭비하게 만들어서 여기에서 홍보되어서는 안 될 그런 플러그인 말이죠.
만약 실제로 그런 사례가 있다면, 그것이 문제가 될 만큼 충분한가요?
테마에 대해某种種の 자기 인증 체크리스트를 도입하는 것도 꽤 유용할 것 같다는 생각이 듭니다. 얼마나 많은 테스트를 수행했는지, 품질과 보안에 대한 보고를 받을 준비가 되어 있는지, 피드백에 신속하게 대응할 것인지 등을 확인할 수 있죠.
또는, 개발 프로세스를 3문장 이내로 설명해 달라고 하는 것도 방법입니다.
답변의 진실성은 크게 의미 없을 수 있지만, 자기 인증을 받은 테마와 그렇지 않은 테마 사이의 차이는 해당 테마를 설치하려는 사용자에게는 꽤 의미 있는 신호가 될 수 있습니다.
저는 제가 만드는 어떤 애플리케이션, 프로젝트, 소프트웨어에서도 절대 바이브 코딩을 하지 않습니다. 아이디어를 나누거나 명확성을 위해 AI 채팅을 사용하긴 하지만, 프로젝트 전체를 맡기지는 않습니다. 훨씬 수동적인 방식이지만, 적어도 제가 무엇을 하는지 알고 있고, 다른 엔티티에게 눈감고 맡기지는 않습니다.
하지만 지난 몇 달간 AI 지원 코딩이 크게 성장하는 것을 지켜보았습니다. 처음에는 코드가 엉망이거나 취약점이 많았을 수 있지만, 그 이후로 매우 많이 개선되었다고 생각합니다. 바이브 코딩으로 만든 디자인은 여전히 꽤 특징적으로 보입니다(그라데이션, 테두리, 이모지 등). 제가 메타에서 본 일부 플러그인에서도 마찬가지였습니다. 하지만 중요한 것은, 저자가 자신의 관심사와 커뮤니티의 관심사를 위해 그것을 공유했다는 점입니다. 누군가가 그것을 짓밟고 '슬롭(slop)'이라고 라벨을 붙이게 하기 위해서가 아니라, 그 플러그인에서 진정한 성공을 거두었기 때문에, 동일한 기능을 원하는 다른 포럼에 공유하고 싶었던 것입니다.
AI에 대한 윤리적 우려에 대해서는 동의하지만, 그것은 AI 전반에 초점이 맞춰져 있는 것 같습니다. 예를 들어 기업들이 책을 조각내고, 대량의 물과 전력을 사용하는 등의 문제 말입니다. 당신은 이렇게 언급했습니다:
하지만 그것이 AI로 만든 플러그인이나 TC(토픽 컨트롤)의 사용과 어떻게 관련이 있나요? AI를 싫어한다면, 물론 사용하지 않으면 됩니다. 하지만 AI의 도입으로 프로그래밍 환경이 극적으로 변했기 때문에, 플러그인과 TC 같은 것들도 변할 것입니다. 일부 코드가 AI의 도움을 받아 작성되었다는 것을 알고 있기에, 이제 디스코르스(Discourse) 사용을 완전히 중단하시겠습니까? 저는 그렇게 하지 않을 것입니다. 왜냐하면 그 뒤에는 여전히 사람들이 있기 때문입니다.
그래서 여전히 그것을 '대충 짠 코드’라고 부르고 '바이브 코딩’이라는 용어의 사용을 거부하는 것이(개인적으로 저는 후자의 표현에 문제가 없다고 봅니다) 정확할까요? 아마도 그렇지 않을 것입니다. 너무 가혹한가요? 네. 당신이 이것을 싫어할 것이라고 생각하지만, 때로는 우리는 적응해야 합니다. 그렇다면 이제 제가 AI 생성 TC를 만들어 공유할까요? 제 경우엔 아닙니다. 하지만 그것을 대안으로 보고, 경멸하거나 무시하지 않을 것인가? 네. 그리고 저는 그렇게 하려고 노력하고 있습니다. 그러니 당신도 그렇게 해주시길 바랍니다.
이 주제와 관련된 큐레이션된 기사를 공유합니다:
Trail of Bits는 AI 에이전트가 버그를 찾는 것뿐 아니라 커스텀 툴링을 구축하는 데 감사(audit) 과정에서 가장 유용하다고 주장합니다. Miden zkVM 감사에서 그들은 Claude와 Codex를 사용해 LSP 서버, 디컴파일러, 정적 분석기, Lean 모델을 생성했으며, 이를 통해 고심도 서명 위조 버그와 두 가지 미묘한 문제를 포착한 95개의 Lean 증명을 발견했습니다.
에이전트가 야심 찬 사이드 프로젝트를 저렴하게 만들 수 있게 되었기 때문에, 감사의 경제학은 이전보다 훨씬 더 철저하게 복잡한 시스템을 보호할 수 있는 툴 기반 리뷰로 이동하고 있습니다.
저는 플러그인과 컴포넌트 개발 시 AI를 보조로 활용합니다. 사용은 전적으로 본인의 책임이지만, 디스커스 코어가 그러하듯 어떤 면책 조항이나 태그를 붙이지 않을 것입니다. 에이전트를 직접 관리하고, 코드를 검토(때로는 다른 에이전트나 LLM의 도움을 받아)하며, 테스트까지 수행합니다. 사용하지 않으셔도 무방하지만, AI가 작성한 코드보다 인간이 완전히 작성한 코드에서 더 자주 저질의 코드를 목격했습니다.
맞습니다. 무언가의 품질을 파악하는 전통적인 방법은 그 것을 만든 주체의 평판을 확인하는 것입니다. 개인 평판은 오픈소스에서 활동하는 경우 잘 작동합니다. 일반적으로 누군가가 이전에 좋은 작업을 해왔고 응답성이 좋았다면, 앞으로도 그럴 가능성이 높습니다.
여전히 상당한 노력이 필요합니다. LLM을 사용하여 결정론적 도구를 만들더라도, 해당 도구가 실제로 올바른 작업을 수행하는지, 단순히 통계적으로 자주 맞는 결과만 내놓는 것이 아닌지 검증해야 합니다. 마크다운 파일을 LLM에 프롬프트로 입력하여 결과가 동일하기를 바라는 것보다(여전히 법적, 윤리적 문제가 존재하지만) LLM을 사용해 결정론적 도구를 만드는 것이 더 나은 방법입니다. 그러나 해당 결정론적 도구를 LLM을 이용해 무비판적으로 유지 관리하게 되면, 새로운 릴리스가 시간이 지남에 따라 결정론적 특성을 잃을 위험이 있습니다.
Snyk가 VulnBench 보고서에서 보여주었듯이, LLM을 이용한 감사(auditing)는 실제로 신뢰할 수 없습니다:
AI 에이전트를 사용해 Discourse 테마를 작성하는 것은 매우 적절한 방법이라고 생각합니다.
그것은 정말 좋겠습니다. 또한, 프로그래밍 배경이 없는 사용자를 위한 이상적인 설정을 파악하는 것도 가치가 있을 것입니다. 제 생각에는 개발용 Discourse 인스턴스에 접근할 수 있는 AI 에이전트와 잘 구성된 스킬 파일, 그리고某种의 자동화된 보안 검토가 필요할 것 같습니다.
물론 Sam과 팀은 논쟁의 여지 없는 권위자이며 제가 틀렸다면 수정해 주실 수 있지만, 제가 많은 실험을 해본 결과 그리고 그 대가로 무언가를 돌려줄 수 있어 기쁘게 생각합니다. 지난 몇 달간 제가 배운 바에 따르면, Discourse Vibe와 harness의 적절한 사용이 권장되며, 시작하기에 최적인 상황입니다.
Github의 특정 테스트를 사용하거나 Discourse Container를 사용하는 것도 가능하지만, 개발 역량은 제한적이며, 제 경우처럼 경험이 적은 사람들에게는 특히 더 그렇습니다.
AI를 사용하여 Discourse를 위한 코드를 'vibe’하는 것은 가능하며, 작업물을 제출하거나 프로덕션에서 사용하기 전에 최종 검증을 수행하거나 위임하기만 하면 됩니다.
제 경우, 코드를 검토할 기술적 자격은 없지만, 기능의 방향을 제시하고 어떻게 어디서 적응해야 하는지, 그리고 구체적으로 무엇을 생성하거나 연마해야 하는지 질문하는 정도는 가능합니다. 따라서 누군가가 코드에 공개적으로 기여하여 보안과 신뢰성(항상 인간 검토 포함)을 보장하고, 코드가 전체 커뮤니티에서 사용될 수 있도록 할 것이라고 상상합니다. Meta뿐만 아니라 Discourse 전체에 걸쳐서요. 그것은 제 첫 프롬프트부터 늘 제 목표였습니다.
어제 이 주제를 읽고 모든 것이 어떻게 진화했는지 놀랐습니다: How hard would it be for non programmers to be able to use the Discourse AI - AI bot to help them create plugins and/or themes
몇 년 전만 해도 AI를 지시하여 코드를 만들어달라고 요청하는 것조차 불가능할 것이라고 생각했습니다. 그리고 오늘, 이 주제에 대한 주의사항과 정당한 논란이 존재하지만, 그것은 현실이 되었습니다.
네, 지난 1년간 상황이 많이 변했습니다. 저는 AI 에이전트와 코딩하는 것을 좋아하므로 편견이 있을 수 있습니다.
이 주제의 진정한 문제점으로 돌아가자면, AI가 사회에 미치는 영향에 대해 사람들이 우려할 만한 이유가 많다고 생각합니다. LLM(또는 더 정확히 말하면 AI 에이전트)이 코드 작성에 서툰다는 주장은 시간이 지나면 크게 설득력을 잃을 것이라고 생각합니다. 제 우려는 주로 많은 작업이 몇몇 대형 기술 기업들을 통해 처리될 때 발생하는 일과 관련이 있습니다. 그러나 여기서는 에세이 분량이 필요할 정도로 깊이 다루기 어렵습니다.
시대가 변하고 있으며, 오픈 웨이트 모델이 빠르게 격차를 줄이고 있습니다. 한때 프런티어 모델과 오픈 모델 사이의 12개월 격차가 지금은 3~6개월로 줄었습니다.
앞으로 몇 년간 AI가 훨씬 더 고르게 확산될 것으로 예상합니다. 로컬 AI는 현재로선 예외적인 사례이지만, 점차 보편화될 것입니다. 또한 우리 Discourse가 그러하듯, 더 많은 기업들이 자체적으로 인텔리전스를 호스팅하게 될 것입니다.