이것은 논리적으로 꽤 큰 도약입니다.
인턴을 고용하거나 본인이 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가 작성한 코드보다 인간이 완전히 작성한 코드에서 더 자주 저질의 코드를 목격했습니다.
맞습니다. 무언가의 품질을 파악하는 전통적인 방법은 그 것을 만든 주체의 평판을 확인하는 것입니다. 개인 평판은 오픈소스에서 활동하는 경우 잘 작동합니다. 일반적으로 누군가가 이전에 좋은 작업을 해왔고 응답성이 좋았다면, 앞으로도 그럴 가능성이 높습니다.