거기에 온갖 가정들이 들어 있어요. 내 추론에 반응하기 전에, 내 의도를 먼저 물어봐 주세요.
1개의 좋아요
당신만이 그런 생각을 하는 것이 아닙니다. 프로젝트에 LLM이 사용되었는지 아닌지 아는 것도 저에게 중요합니다.
코드 품질을 떠나, LLM을 둘러싼 윤리적 문제도 충분히 많습니다. 사람들이 자신이 설치하는 소프트웨어와 지원하는 프로젝트에 대해 적어도 정보에 기반한 결정을 내릴 수 있어야 합니다. LLM을 사용해 충분히 세심한 주의를 기울여 좋은 소프트웨어를 만드는 방법이 있을까요? 아마도 있을 것입니다. 현재 업계와 정치의 상황을 고려할 때 LLM을 윤리적으로 사용하는 방법은 있을까요? 저는 그것이 훨씬 더 어렵다고 생각합니다.
하지만 여기서 또 다른 장황한 논쟁을 시작하기 전에, 부탁합니다: 이것은 오직 투명성에 관한 것입니다. 사람들이 무언가를 설치하기 전에 스스로 판단할 수 있도록 하기 위해서입니다.
3개의 좋아요
그럼 제가 어디가 잘못된 건지 설명해 주시겠어요?
아니면: 당신의 의도는 무엇이었나요?
이건 제가 원하는 것의 핵심이라고 확신합니다. 사람들이 무엇을 선택하는지 알 수 있도록 사전에 투명성을 확보하고 싶습니다. 윤리성에 관해서 말씀드리자면, 저는 수개월간 LLM 학습 데이터를 오염시키고 이 기술이 제 생활과 모든 코드베이스에 침투하는 것을 막기 위해 온 힘을 다해왔습니다. 따라서 제가 직접 앱을 만들거나 100% LLM으로 만든 앱을 사용하는 것이 완전히 괜찮다고 판단한다면, 그것은 본질적으로 위선적인 행동이 될 것입니다.
다행히도 정당한 조사를 하는 것은 그리 어렵지 않습니다. 현재 제 정책은 기여자들을 확인하고, LLM이 작성한 커밋이 많이 보이면 그냥 페이지를 닫고 사용하지 않는 것입니다. 제가 여기서 제안하는 것은 사람들이 알 수 있도록 스스로 붙이는 작은 라벨일 뿐이지만, 이 스레드에는 반대하는 몇 가지 그럴듯한 의견도 있습니다. 시간이 절약되고 더 많은 사람이 접근할 수 있게 된다는 점은 모두 이해하지만, 이 기술로부터 거리를 두기를 원하는 것이 부당하다고 생각하지는 않습니다. 
5개의 좋아요
그건 확실히 패스할게. 이번 사건의 먼지가 좀 가라앉는 걸 지켜볼 거야.
분명 일부는 결과에 꽤나 이해관계가 있는 것 같아. 내 의견은 이미 말했고, 몇 가지 생각을 나눠줬어.
남에게 내 의견을 강요하거나, 남이 자기 의견을 나에게 강요하는 건 관심 없어.
나는 여기서 빠질게. 먼지가 가라앉을 때까지 기다릴 거야.
이것이 걱정이라면 플러그인이나 테마에 대해서는 걱정하지 않아도 된다는 점을 덧붙이고 싶습니다. 더 이상 Discourse를 사용할 수 없기 때문입니다. 요즘 우리는 Discourse 개발에 AI를 광범위하게 활용하고 있습니다.
8개의 좋아요
그렇죠, 이상적인 세상이라면 LLM이 작성한 소프트웨어를 전혀 사용하지 않았을 겁니다. 하지만 세상은 이상적이지 않고, 항상 선택할 수 있는 것도 아니에요. 그래서 아직 선택할 수 있는 곳에서는 그 선택지를 지켜야 하는 이유가 더 클 수밖에 없죠.
6개의 좋아요
여기서 명확히 하고 싶은 점이 있습니다.
저는 에이전트를 사용하여 Discourse를 개발하고 있습니다. 약 10개월간 제가 직접 작성한 코드는 몇 줄에 불과합니다. 올해 상당한 기능을 추가하고 수많은 결함을 수정했습니다.
에이전트 기반 코딩이 금지된 프로젝트를 찾고 계시다면, 다른 곳을 찾아보셔야 할 것 같습니다.
9개의 좋아요
저는 금지를 요청한 적이 없으며, 원포스터도 마찬가지입니다. 이 주제는 "LLM으로 생성된 테마와 플러그인은 해당 사실을 태그로 명시해야 한다"입니다.
2개의 좋아요
코어는 무료로 제공되는데, 왜 테마는 필요합니까?
1개의 좋아요
추측컨대 그 논리는 이렇습니다. 코어가 AI로 생성된다는 사실은 피할 수 없지만, 나머지 부분에 대해서는 선택지를 제공할 수 있다는 것이지요?
무엇이 요구되고 있는지(그리고 왜 그런지)는 충분히 이해합니다. 하지만 이전에 제안된 대로 AI-free 태그를 만들어, 그 구분이 중요하다고 느끼는 사람들이 사용하도록 하는 것이 더 효율적이라고 생각합니다.
4개의 좋아요
그렇다면 AI-free란 정확히 무엇을 의미하는 걸까요? 저는 개발할 때 특정 사항에 대해 Ask Discourse나 Claude에 질문하긴 하지만, 프로젝트 전체를 vibe-code(생성형 AI로 코드를 작성하는 방식)로 만들지는 않습니다. 그렇다면 이러한 명칭은 AI 사용을 어느 정도까지 포괄하는 것일까요? AI를 전혀 사용하지 않는 0%인지, 설명을 위해 AI 채팅을 활용하는 수준인지, 아니면 완전히 AI로 생성하는 것까지 포함하는 건지요. 저는 이 구분이 명확히 이루어져야 한다고 생각합니다.
4개의 좋아요
개인적으로 저에게 AI-free는 다음과 같은 의미입니다:
“모든 코드를 직접 손으로 작성했으며, 이 프로젝트의 임의의 코드 줄에 대해 질문을 받으면 그것이 무엇을 하는지 알고 있습니다 – 아니면 적어도 간단히 다시 읽어본 후 기억을 떠올릴 수 있습니다.”
하지만 그렇습니다. 정의는 명확해야 하고, 모든 사람이 동일한 정의를 가지고 있지는 않을 것입니다.
다시 말하지만, 윤리적/환경적 우려에 관한 문제라면, AI에게 질문하는 것조차 문제의 일부일 수 있습니다…
복잡한 문제입니다.
4개의 좋아요
간단한 시작은 "이 프로젝트에는 LLM으로 생성된 코드를 사용하지 않는다"는 원칙일 것입니다. 이를 100% 완벽하게 지키기는 어렵겠지만, 대부분은 의도 표명에 가깝습니다. 저는 채식주의와 유사한 점을 자주 봅니다. 극단적으로 추구하다 보면 결국 모순과 불가능한 선택에 직면하게 되죠. 하지만 그것이 핵심은 아닙니다. 핵심은 불필요한 해를 최소화하는 것입니다.
저는 LLM 사용에서 비롯되는 많은 해를 보고 있습니다. 장기적인 코드 품질, 우리의 환경, 사회, 그리고 우리 자신의 정신 건강에 대한 해가 그렇습니다. 제가 의존하게 될 소프트웨어 프로젝트를 볼 때, 개발자가 그러한 해를 피하려는 노력을 기울이는지, 아니면 전면적으로 수용하는지 알고 싶습니다. 만약 그들이 이 문제를 충분히 중요하게 여겨 프로젝트를 "AI-free"로 라벨링한다면, 그 자체가 이미 저에게 도움이 되는 신호가 됩니다.
2개의 좋아요
이것이 이런 식이 될 수밖에 없다는 점이 안타깝습니다. AI 기업들이 인터넷에서 코드를 사실상 도용하고, 책을 파괴하며, 호스트 서버를 존중하지 않고(불필요한 DRAM 위기조차 무시하고) 모든 것을 훔치는 악성 크롤러를 운영한다는 점에서 여전히 강한 윤리적 우려를 가지고 있기 때문입니다. 모두는 원하지 않는 LLM 경쟁에서 먼저 나가기 위해 이런 짓을 하고 있습니다. 저는 이미 코드의 품질이 크게 저하되어 많은 앱을 사용하지 않게 되었습니다. 예를 들어 VS Code는 느려지고 메모리 비효율적이 되며 일반적으로 버그가 많아졌습니다. Formbricks의 업그레이드 패키지가 작동하지 않게 되었고, 제 음악 플레이어는 느려지고 부풀어 오르더니(기능 추가가 너무 쉬워지면 프로젝트 범위를 잃고 모든 것을 추가하게 됩니다) 절반의 시간에는 음악을 재생하지도 못합니다.
하지만 문제는 제가 Discourse를 좋아해서 사용을 중단하고 싶지 않다는 것입니다. IDE나 음악 플레이어처럼 애정이 없거나, 2024년에 사용을 중단하기 전부터 이미 싫어했던 제 OS(운영체제)와는 다릅니다. LLM으로 인해 소프트웨어가 극도로 버그가 많거나 느려지지 않는 한, 사용을 중단하기로 결정할 가능성은 낮습니다.
저는 이 전체 상황에 대해 완전히 "흑과 백"으로 나누고 싶지는 않지만, LLM 사용에 수반되는 윤리적 및 프라이버시 우려를 극복할 수 없습니다.
2개의 좋아요
저도 여러분의 일부 관찰에 공감합니다. 그리고 개인정보 보호를 중시하는 사람으로서, AI 사용을 피하려면 클리어넷(Clearnet) 사용을 중단해야 한다는 점을 이해합니다.
기술 자체를 떠나, 인터넷 사용이 기술적으로 가능하도록 하는 클라우드플레어(Cloudflare), 아마존(Amazon), 구글(Google), 메타(Meta), 마이크로소프트(Microsoft)와 같은 기업들과 본질적인 상업적 연결고리가 있습니다.
우리는 디지털 시대의 전환기를 맞이하고 있으며, 이는 결국 그 밝은 면과 어두운 면 모두를 더욱 깊게 만들 것입니다. 아직 ID 없이 웹을 탐색할 수 있는 한, 우리는 AI를 의식적으로 사용한다는 중도적 길을 선택할 수 있다는 점을 이해합니다.
그리고 저는 그것이 디스코urse가 하는 일이라고 생각합니다. 또는, 제가 언급한 플러그인이나 컴포넌트를 만드는 방법을 모르고도 그걸 설계하는 그룹의 일원인 저조차도 혼자서 그렇게 합니다. 저는 사적으로 그것을 수행하고, 테스트하며, 항상 배우고 있습니다. 왜냐하면 저는 수년간 자금 지원을 받지 못한 대안적이고 탈중앙화되며 틈새(niche) 프로젝트를 진행하고 있으며, 수천 달러보다 적은 금액으로 이것을 해 주려는 사람을 찾지 못했기 때문입니다.
분석해야 할 다양한 뉘앙스가 있으며, 저는 단순한 태그만으로는 이 문제의 근본이나 중심을 해결한다고 믿지 않습니다. 제 삶의 철학에서 '행하는 것’은 '말하는 것’보다 낫기 때문에, 궁극적으로 여러분이 실제로 어떻게 행동하는지, 그리고 그것이 이 문제와 어떤 관련이 있는지 알고 싶습니다.
3개의 좋아요
지적하려는 건 아니지만, 유능한 개발자들이 만든 잘 정립된 소프트웨어에서 AI의 사용이 기술적으로 일반적으로 문제가 된다고 생각합니까? 그리고 저는 앱의 효율성, 안정성, 보안에 대해서만 이야기하고 있습니다.
LLM이 존재하기 훨씬 전에도 앱이 느려지거나, 부풀어 오르거나, 악성 코드가 되거나, 고장 나는 것을 많이 봤습니다.
저는 일상생활에서 많은 애플리케이션을 사용하는데, 지금까지 AI 사용으로 인해 allegedly(주장된 대로) 발생한 기술적 문제를 발견하지 못했습니다. 그리고 요즘에는 그 앱들의 95%, 아니 그 이상도 어느 정도 AI를 사용하여 만들어졌을 것이라고 꽤 확신합니다.
유능하지 않은 개발자가 만든 앱을 사용하면, AI를 쓰든 쓰지 않든 당연히 나쁜 경험을 하게 될 것입니다.
누구나 “유명한 개발자가 만든 유명한 앱이 AI 때문에 고장 났다” 같은 드라마를 본 적이 있을 것입니다. 저는 그런 일이 실제로 일어났다고(그리고 다시 일어날 것이라고) 믿습니다.
또한 저는 이것이 드문 발생 사례라고 생각합니다. 재능 있는 개발자들은 AI를 기다릴 필요 없이, 어떤 이유로든 프로젝트가 언젠가 실패하는 것을 경험해 왔을 것입니다.
저는 당신이 언급한 이유를 포함해 여러 가지 이유로 AI에 대해 우려(때로는 혐오)하지만, "AI 때문에 내 음악 앱이 이제 나빠졌다"는 점에 대해서는 별로 우려하지 않습니다(그리고 다시 말하지만, 그런 일이 일어나지 않는다고 말하는 것은 아닙니다).
6개의 좋아요
이것은 자율 규제에 달려 있습니다. AI가 테스트 작성과 같은 단순한 작업을 수행하는 것은 전체 앱(이 경우 플러그인)을 구축하고 그것을 자신의 것으로 발표하는 것과 같지는 않습니다. 내일 아침에 깨어나서 "내가 뭘 생각하고 있었지, LLM은 정말로 윤리적이고 워크플로우에 큰 도움이 되잖아!"라고 결심한다면, 더 경험이 많은 다른 개발자들이 하는 것처럼 번아웃을 극복하고 더 빠르게 개발할 수 있을 것입니다. 하지만 개인적으로, 그렇게 하면 프로그래밍과 개발의 모든 재미가 사라집니다. 저는 취미와 직업으로서 프로그래밍을 즐깁니다. LLM에 작업을 위임하면 실제로 코딩하는 것이 아니라 하루 종일 프롬프트를 입력하는 것에 불과하므로, 즐거움이라는 요소가 방정식에서 완전히 사라집니다.
그것은 항상 문제였습니다(Windows 10은 2015년에 출시되었죠). AI가 프로그래밍에서 인기 있고 “좋아진” 것은 앱에 불필요한 요소를 추가하는 것을 너무 쉽게 만들어서 이를 가속화했을 뿐입니다. 예를 들어, 내비게이션 앱을 가지고 있다고 가정해 봅시다. 갑자기 하루는 내장 FLAC 플레이어와 수많은 통합 기능을 추가하고 싶다고 생각했다고 합시다. 당연히 이것은 존재할 필요가 없으며 내비게이션 앱의 범위를 크게 벗어나고 저나 제 개발자들의 시간을 낭비하는 것입니다. 하지만 대신 Claude에 가서 "제 앱에 x, y, z 기능이 있는 음악 플레이어를 추가해 줘"라고 말하기만 하면, 저는 그것을 추가하고 출시할 수 있습니다. "이건 멋질 수 있지만 쓸모없고 시간 낭비야"였던 것이 이제 제 가상의 사용자 모두가 가진 실제 기능이 되었고, 이는 앱의 크기를 늘려 더 느리고 RAM/저장소 부담을 가중시킵니다. 이것은 결국 가상의 시나리오이지만, 이 상황은 절대 가상이 아니며 많은 앱에서 실제로 일어나고 있습니다.
LLLM이 있든 없든, 좋은 앱을 만드는 것은 개발자의 책임입니다. 무책임한 개발자는 AI를 쓰든 쓰지든, 나쁜 앱을 만들거나 괜찮은 앱을 만들다가 과하게 달려들어 망치기 마련입니다. 저는 이미지 및 비디오 생성 모델에 대해 가지고 있는 것처럼 LLM에 대해 엄격하게 반대하는 것은 아니며, 단순히 그것들이 자리가 있고, 그 자리는 대부분의 사람들이 책임감 있게 기술을 활용할 수 없는 상황에서 코딩이 아니라고 믿습니다.
3개의 좋아요
대화에 뒤처져 있고, 적절한 참고 자료를 찾아볼 정도로 정신이 맑지 못하지만, 혹시 여러분이 아직 주목하고 있지 않다면 살펴볼 가치가 있는 몇 가지 « 라벨링 시스템 » 또는 « 공개 프레임워크 »를 발견했습니다. 오늘날의 핵심 질문은 AI가 사용되었는지 여부가 아니라, 어떻게 사용되었는지에 더 가깝습니다. LLM에게 지시문단을 던져 플러그인을 출력하게 한 뒤 « 오류를 테스트하고 수정하라 »고 말하는 것과, 개발 전반의 방향과 감독을 유지하면서 LLM이 통제된 방식으로 작업을 수행하도록 하는 것 사이에는 큰 차이가 있습니다. 제 생각에는 코드를 제공하는 사람들에게 자기 공개(self-disclosure)를 요청하는 것도 고려해 볼 만한 사안입니다.
(P.S. 물론 저는 이러한 문제들을 코딩보다는 글쓰기 분야에서 더 잘 알고 있습니다.)
3개의 좋아요
네, 이 문제에 대해서는 당신의 의견에 동의합니다. 이는 하나의 우려 사항이죠 
1개의 좋아요