FSF의 라이선싱·컴플라이언스 랩이 2025 GNU Tools Cauldron에서 대규모 언어 모델(LLM)과 자유 소프트웨어 라이선스의 상호작용을 논의했다. 저작권성, 침해 위험, 비자유 모델과 훈련 코드 문제, 메타데이터 수집 지침, 프롬프트 공개 등 쟁점과 토론을 정리했다.
URL: https://lwn.net/Articles/1040888/
Title: The FSF considers large language models
FSF가 대규모 언어 모델을 검토하다 [LWN.net]
사용자: 비밀번호: | |
LWN 구독자 혜택 LWN 구독의 가장 큰 가치는 저희가 발행을 계속할 수 있도록 돕는 것입니다. 그 외에도, 구독자는 사이트의 모든 콘텐츠에 즉시 접근할 수 있고 여러 추가 기능을 이용할 수 있습니다. 오늘 가입해 주세요!
작성: Jonathan Corbet
2025년 10월 14일
자유 소프트웨어 재단(FSF)의 라이선싱 및 컴플라이언스 랩은 소프트웨어 라이선스의 여러 측면을 다룬다고 Krzysztof Siewicz는 자신의 2025 GNU Tools Cauldron 세션 시작에서 말했다. 여기에는 라이선스 문제에 직면한 프로젝트 지원, 저작권 양도 수집, GPL 위반 대응 등이 포함된다. 하지만 이 세션에서 청중이 가장 알고 싶어한 주제는 단 하나였다. 바로 자유 소프트웨어 라이선스와 대규모 언어 모델(LLM)의 상호작용이다.
![Image 4: [Krzysztof Siewicz]](https://static.lwn.net/images/conf/2025/cauldron/KrzysztofSiewicz-sm.png)
LLM이 만든 코드의 법적 지위에 대해 명확한 답을 얻고자 이 세션에 온 사람들은 실망했을지도 모른다. FSF 역시 이 환경이 어떻게 생겼는지 아직 파악 중이기 때문이다. 현재 이 단체는 LLM이 작성한 코드에 대해 자유 소프트웨어 프로젝트들이 어떤 입장을 취하고 있는지를 파악하기 위한 목적으로 자유 소프트웨어 프로젝트 대상 설문을 진행하고 있다. 그 정보(와 더 많은 자료)를 바탕으로, FSF는 궁극적으로 자체 가이던스를 내놓기를 희망한다.
Nick Clifton은 FSF가 LLM이 생성한 코드를 고려한 새로운 GNU 일반 공중 라이선스, 즉 GPLv4를 작업 중인지 물었다. Siewicz의 답변은 현재로서는 라이선스 변경을 검토하지 않고 있으며, 대신 먼저 자유 소프트웨어 정의의 조정을 고려하고 있다는 것이었다.
Siewicz는 계속해서, LLM이 생성한 코드는 자유 소프트웨어 관점에서 여러 이유로 문제적이라고 말했다. 그중에는 모델 자체가 대개 비자유적이며, 이를 훈련시키는 데 사용되는 소프트웨어 역시 비자유적이라는 점이 포함된다. Clifton은 훈련 코드가 왜 중요한지 물었다. Siewicz는 지금 시점에서는 일부가 느끼는 우려를 강조하는 것뿐이라고 답했다. 다른 이가 실행하는 것일지라도 독점 소프트웨어를 피하고 싶어 하는 사람들이 있다는 것이다.
Siewicz는 또 중요한 질문 중 하나가 LLM이 만든 코드에 저작권이 성립하는지, 그렇지 않다면 저작권을 성립시킬 방법이 있는지라고 말했다. 명시적으로 언급되지는 않았지만, 핵심 쟁점은 이 소프트웨어를 신뢰성 있게 카피레프트 라이선스로 배포할 수 있느냐인 듯하다. 동등하게 중요한 것은 그러한 코드가 타인의 권리를 침해하는지 여부다. 저작권 성립 가능성에 관해서는 여전히 미해결 상태다. 현재 법원을 통해 진행 중인 사건이 일부 있다. 그럼에도 그는 LLM 출력물에 대해 사람이 결과 코드를 보강하는 노력을 가함으로써 저작권을 보장할 수 있을 듯하다고 말했다. "창의적 프롬프트"를 사용하는 것도 코드를 저작권 보호 대상이 되게 만들 수 있다.
오래전에 사진은 일반적으로 저작권의 대상이 아닌 것으로 여겨졌다. 그러나 시간이 지나며 사람들은 그 기술로 무엇을 할 수 있는지, 그것이 어떤 창의성을 가능케 하는지 알아냈고 상황은 바뀌었다. 그는 사진이 LLM에 대한 좋은 비유가 될 수 있다고 제안했다.
물론 LLM이 생성한 코드에서의 저작권 "침해" 문제도 있다. 보통 훈련 데이터가 모델 출력으로 새어 나오는 형태다. 어떤 생산자의 "스타일로" 출력을 요구하도록 프롬프트하면 그런 일이 더 자주 발생할 수 있다. Clifton은 LLM이 생성한 코드를 제출할 때, 생성에 사용한 프롬프트를 함께 제출해 다른 이들이 저작권 침해 가능성을 평가할 수 있어야 한다고 제안했다.
Siewicz는 라이선스된 데이터를 포함하는지 여부를 명시적으로 밝히는 모델을 알지 못한다고 말했다. 일부가 제안하듯, 허용적(permissive) 라이선스로만 독점적으로 학습시켜 모델 출력을 배포 가능하게 만드는 것도 가능할 수 있다. 하지만 허용적 라이선스조차 저작권 고지 보존을 요구하며, LLM은 이를 수행하지 않는다. 관련된 우려로, 일부 LLM은 서비스 약관을 통해 모델 출력에 대한 저작권을 주장하기도 한다. 그러한 코드를 자유 소프트웨어 프로젝트에 포함하면 해당 프로젝트가 저작권 주장의 대상이 될 수 있다.
Siewicz는 자신의 발표를, 해당 프로젝트가 LLM 생성 코드를 아예 수용한다는 전제하에, 이를 수용하는 어떤 프로젝트에도 권할 만한 몇 가지 주의사항으로 마무리했다. 이 제안은 주로 코드에 대한 메타데이터 수집 형태를 취한다. 제출물에는 어떤 LLM이 사용되었는지, 버전 정보와 모델 학습에 사용된 데이터에 관한 이용 가능한 모든 정보가 포함되어야 한다. 코드를 생성할 때 사용한 프롬프트도 제공해야 한다. LLM 생성 코드는 명확히 표시해야 한다. 모델 출력물에 사용 제한이 있다면 그것도 문서화되어야 한다. 이러한 모든 정보는 코드가 수용될 때 기록되고 보존되어야 한다.
청중 중 한 명은 LLM과 보조(접근성) 기술의 경계가 모호할 수 있으며, 전자를 전면 금지하면 보조 기술이 필요한 개발자들을 막는 결과가 될 수 있는데 이는 누구도 원하지 않는 일이라고 지적했다.
일부 기여자가 자신의 모델 사용을 솔직히 밝히지 않을 수 있다는 점을 고려할 때, LLM 생성 코드와 사람 작성 코드를 어떻게 구분할지에 대한 질문도 있었다. Clifton은 항상 인간이 루프에 있어야 하며, 결국 그들이 제출한 코드에 책임을 져야 한다고 말했다. Jeff Law는 많은 프로젝트에 코드가 제출될 때 적용되는 개발자 기원 증명서(Developer Certificate of Origin)에는 기여자가 해당 코드를 제출할 권리가 있다는 진술이 포함되어 있다고 덧붙였다. 그 권리가 실제로 기여자에게 있는지 여부를 판단하는 문제는 새로운 우려가 아니다. 예를 들어 개발자가 자신의 고용주 소유의 코드를 제출할 수도 있기 때문이다.
Siewicz는 실제로 우려되는 점은 기여자들이 위험이 어디에 있는지 충분히 교육받았는지 여부라고 말했다.
Mark Wielaard는 개발자는 보통 자신이 작성한 코드에 영감을 준 출처를 인용할 수 있는데, LLM은 분명 다른 코드에서 영감을 받았지만 그러한 인용을 전혀 할 수 없다고 말했다. 따라서 LLM이 생성한 코드가 어디에서 왔는지 진정으로 알 방법이 없다. 개발자는 그 빈틈을 메우기 시작하려면 LLM과의 전체 세션을 공개해야 할 것이다.
이 세션은, 어쩌면 참가자들이 우려가 어디에 있는지 더 잘 이해하게 되었을 수는 있지만, 답을 알게 되었다고 확신하며 나간 사람은 아무도 없는 상태로 끝이 났다.
이 세션의 영상은 YouTube에서 볼 수 있다.
[이 행사에 대한 저의 이동을 후원해 준 LWN의 여행 스폰서인 리눅스 재단에 감사드립니다.]
| 이 글의 색인 항목 |
|---|
| 컨퍼런스 |
댓글을 게시하려면
2025년 10월 14일 16:43 UTC (화) 게시자: gwolf (구독자, #14632) [링크]
우리가 프로그래머로서 실제로 "우리가 작성한 코드에 대한 어떤 영감이든 인용"할 수 있을까요? 그런 일을 자주 하나요?
제가 학교나 책으로 프로그래밍을 배웠든, "부트캠프"를 수료했든, 특정 구성 요소를 어디에서 가져왔는지 보통 말할 수 없습니다. 물론 저는 K&R 스타일로 C를 쓴다고 말할 수는 있습니다 — 하지만 그게 Siewicz가 뜻한 바라고는 의심스럽습니다. 물론 Perl 덕후들은 "Schwartzian transform"을 알아볼 것입니다. 하지만 일반적으로 저는 _코딩하는 방법_을 배웠고, 제 프로그래밍의 특정 구성을 특정 코드 조각에 귀속시키지 못합니다. LLM과 마찬가지로요.
제 프로그래밍의 대부분이 StackOverflow에서 제 문제와 관련된 질문에 대한 답을 찾는 것으로 이뤄진다면... 저는 포함한 각 스니펫 앞의 주석에 문제의 게시물 링크를 다는 쪽으로 설득될 수도 있습니다. 하지만 그것도 흔히 보이는 일은 아닙니다. 그리고 해당 스니펫을 포함한 그 순간 그 주석을 쓰지 않았다면, 아마 저는 영원히 쓰지 않을 것입니다.
그래서... 여기에는 논증상의 문제가 있다고 생각합니다 :-)
2025년 10월 15일 2:13 UTC (수) 게시자: Baughn (구독자, #124425) [링크] (21개 응답)
ChatGPT만 써 본 게 아니라면, LLM이 만든 코드는 단일 프롬프트의 결과도, 심지어 한 번의 대화의 결과도 아니며, 보통 다음과 같은 워크플로의 결과라는 것을 알 것입니다:
LLM과 문제를 논의한다. 이때 LLM은 대화 중에 여러분이 작업 중인 리포지토리의 큰 부분을 자율적으로 읽는다.
계획을 써 달라고 한다. 그 계획을 편집한다. 편집한 계획에 대해 LLM에 묻는다. 더 편집한다.
LLM을 여러 번 재시작하고, 계획의 다른 부분을 코딩해 달라고 요청한다. 결과를 디버깅한다. 직접 코드를 좀 쓴다. 리포지토리를 만들고, 리베이스하고, 이리저리 가지고 논다. 잠재적 코드의 여러 브랜치를 유지한다.
무엇이 통할지 알게 되었으니 원래 계획으로 돌아가 수정한다. 때로는 일부 단위 테스트를 과거 시점으로 포팅한다.
완료될 때까지 반복한다.
프롬프트는 있다. 사실 프롬프트가 아주 많다. 모두 장황한 JSONL에 편리하게 저장되며, 이해하려면 여러분이 작업 중인 리포지토리의 시점별 스냅샷도 필요하다.
누군가 그것을 요구한다면, 저는 어디서부터 시작해야 할지 모르겠습니다. 마치 제 데스크톱 녹화를 요구해 제가 그들이 못마땅해할 일을 하고 있지 않음을 확신하려는 것처럼요.
2025년 10월 15일 4:21 UTC (수) 게시자: mussell (구독자, #170320) [링크] (9개 응답)
그건 표준적인 편집-컴파일-디버그 사이클과 비교하면 너무 많은 노력처럼 들리고, 전력 소모도 몇 자릿수 더 큽니다. 이런 것들의 이점이 도대체 뭐였죠? 정말로 우리의 사고를 그 정도까지 외주 주고 싶은가요?
2025년 10월 15일 14:25 UTC (수) 게시자: Baughn (구독자, #124425) [링크] (7개 응답)
그렇게 많이 드는 노력이 아닙니다. 일을 제대로 하고 있다면, 여러분은 이미 구현하려는 기능에 대한 설계를 작성해 두었어야 합니다.
LLM은 설계를 강제할 뿐입니다. 계획 없이 잘 작동하지 않거든요. 여러분이 마음을 읽어주길 기대할 수는 없습니다.
그리고 글쎄요. 프로젝트 범위가 5배 늘어나는 게 가치가 있나요? 제 경우에는 그 정도 성과를 얻고 있습니다.
2025년 10월 15일 21:18 UTC (수) 게시자: SLi (구독자, #53131) [링크] (5개 응답)
초기 ChatGPT 시절에 저는 코드 생성을 부탁할 생각은 없었지만, 이 방식이 설계를 다듬고 단순화하는 데 훌륭하다는 걸 알았습니다. 그들이 옳아서가 아니라; 오히려 그들의 황당한 해결책 때문에 제가 놓쳤을 접근법을 생각하게 만들었기 때문이죠.
전설에 따르면, 일부 프로그래머들은 문제를 해결하기 위해 고무 오리에게 말을 건다고 합니다. 글쎄요, GPT-3조차 확실히 고무 오리보다는 나았습니다. 반드시 10배 더 낫다는 건 아니지만, 그래도 더 낫습니다. 최근 모델들은요? 잘 모르는 영역에서도 진짜 유용하다고 생각합니다. 예 하나만 들자면(제가 더 덜 알던 도메인인 제책 분야의 예도 줄 수 있지만, 이 메시지는 이미 깁니다):
지난 며칠 동안 Rust를 깊게 파고들었는데, LLM에서 받은 크레이트 및 접근법 제안을 어떻게 대체할 수 있을지 모르겠습니다. 아마도 옛날식으로, 사람들이 요즘 무엇을 하는지 보려고 충분한 Rust 코드를 읽는 방법이겠죠. 하지만 그건 몇 배의 노력이 들었을 겁니다. 마찬가지로, 특정 스니펫이 왜 borrow checker를 불행하게 만드는지 빠르게 파고들고 대안을 제시하는 데도 해당됩니다. 한 번도 들어본 적 없는 상태에서 smallvec를 검색 대상으로 쉽게 배우기는 어렵습니다.
또는 오늘은, 프로세스 그룹과 세션, 그것들의 pty와의 상호작용(제가 잘 몰랐던 부분), 그리고 "도대체 왜 이런 프로세스 트리를 얻게 되는지"를 파고들었는데 — LLM이 제가 몰랐던 subreaper에 대해 가르쳐 줬고, 검색어로 쉽게 떠올릴 수 있었을 것 같지도 않았습니다.
제 생각에 문제는 사람들이 LLM이 100% 항상 옳지 않으면 화를 낸다는 겁니다. 그건 좀 "사용법이 틀렸다"와 비슷해 보이기도 합니다. 항상 옳을 거라고 기대하지 마세요. (덧붙여 말하면, 사람들이라고 해서 항상 옳다고 기대하지 마세요. 아주 조금만 말하지 않는 이상요.) 대신 큰 그림을 빨리 보여주는 데 의존하세요. 스스로 공부한 지 꽤 지나서도 수정되어야 할 오해를 품고 있을 수 있는 지점 — 완전히 무지한 상태보다는 훨씬 낫습니다.
2025년 10월 16일 7:03 UTC (목) 게시자: Wol (구독자, #4433) [링크] (2개 응답)
전설에 따르면, 일부 프로그래머들은 문제를 해결하기 위해 고무 오리에게 말을 건다고 합니다.
제 책상에는 바로 그 이유로 봉제 Tux가 있습니다(비록 잘 쓰지는 않지만).
그런데 문제를 동료에게 설명하는 과정에서, 종종 그 동료가 한마디도 하지 않았는데도 해결되는 경우가 얼마나 많습니까? 그래서 고무 오리/봉제 Tux/그 무엇이든 그런 디버깅 도구가 유용한 겁니다. 무생물과 대화하는 게 좀 이상하게 느껴질 수 있지만, 흠 잡지 마세요. 효과가 있어요...
건배,
Wol
2025년 10월 16일 11:48 UTC (목) 게시자: iabervon (구독자, #722) [링크] (1개 응답)
저는 동료들과 그룹 채팅에서 이야기하듯 설명을 타이핑하는 것이 소리 내어 말하는 것만큼 잘 작동한다는 걸 알았고, 풀 리퀘스트를 만들기 전에 버전 관리되는 파일에 그것을 넣어 비우곤 합니다. 그러다 보면 문서나 커밋 메시지에 쓸 멋진 문구가 생기기도 하는데, 원래 형태는 미완성 토픽 브랜치 바깥 조직에는 쓸모가 없을 내용이죠. 또한 이렇게 하면 몇 달 후에 중단해 둔 프로젝트로 돌아왔을 때, 그 작업을 하면서 오리에게 뭐라고 했는지 되돌아보는 데 아주 좋은 정보가 남습니다.
물론, 그 말은 진행 중인 기능에서 맞닥뜨린 이슈들을 설명하는 목록이라고 적힌 파일이 버전 관리에 있고, 메인라인 커밋에는 그 밖에 아무것도 없다는 뜻이기도 합니다.
2025년 10월 16일 16:04 UTC (목) 게시자: SLi (구독자, #53131) [링크]
동의합니다. 거기에 시간을 좀 더 들이면 더 좋아지기도 하죠.
하지만 비대화형 환경에서 명확하게 글을 쓰는 것은 어쩌면 대부분의 엔지니어가 갖추지 못한 기술이라고 생각합니다. 모든 엔지니어가 기술 글쓰기를 배워야 합니다(제 대학은 저에게 가르치지 않았습니다). 많은 이들이 그것이 꽤 다른 기술 세트라는 걸 인지하지 못하는 듯합니다.
2025년 10월 16일 13:40 UTC (목) 게시자: kleptog (구독자, #1183) [링크] (1개 응답)
저는 LLM이 큰 그림을 찾는 데 특히 유용하다고 느낍니다. 무언가가 왜 작동하지 않는지 알아내려고 할 때, 문제가 있을 가능성이 높은 구성 요소의 이름을 알려줄 수 있고, 그러면 그것을 검색할 수 있죠.
이걸 처음 똑똑히 본 건 CodeMirror로 뭔가를 하려다가 각종 사이트에서 상충되는 조언을 잔뜩 받았을 때였습니다. 결국 오류를 ChatGPT에 넣었더니 5와 6 버전이 완전히 다른 구성 스타일을 사용한다고 지적했습니다. 검색 엔진은 그런 정보를 알려주지 않았을 겁니다. 어떤 웹사이트도 자신들이 어떤 버전을 쓰는지 명시하지 않거든요.
그리고 일회성 스크립트에는 최고입니다. 자, Python으로 X, Y, Z 단계를 수행하는 스크립트가 필요합니다. 이전에 이 작업을 하던 bash 스크립트는 여기 있습니다. 그리고 보아라.
모든 것을 알고 아무것도 이해하지 못하는 바보로 대하세요. 바로 그겁니다... 요령은 여러분의 이해와 그것의 지식을 결합하는 것입니다.
2025년 10월 23일 11:07 UTC (목) 게시자: nye (구독자, #51576) [링크]
모든 것을 알고 아무것도 이해하지 못하는 바보로 대하세요. 바로 그겁니다... 요령은 여러분의 이해와 그것의 지식을 결합하는 것입니다.
제가 어디서든 본 LLM에 대한 최고의 설명이라고 생각합니다.
2025년 10월 20일 2:14 UTC (월) 게시자: gmatht (구독자, #58961) [링크]
LLM이 쓰레기를 내놓기도 하지만, 때로는 제게서 나올 결과보다 더 잘할 때도 있습니다.
모든 C 프로그래머와 마찬가지로, 저는 어떤 언어로든 C를 쓸 수 있습니다. 가끔 제가 Python에서 C를 쓰기 시작하면 LLM이 복잡한 알고리즘을 두 줄짜리 파이써닉한 해법으로 완성해 주겠다고 제안합니다. 또 LLM의 UI 초안은 기능적이지만 평범한 제가 v1.0이라고 부를 버전보다 보기 좋습니다.
다음과 같은 말이 있었던 것으로 기억합니다. 컴파일러/LLM보다 제가 항상 더 좋은 코드를 쓸 수 있는 이유는 제가 컴파일러/LLM을 사용할 수 있기 때문이라는 거죠.
LLM의 가장 큰 약점은, 코드베이스가 어느 정도 품질 수준에 도달하면 LLM이 기존 버그를 고치는 것보다 새로운 버그를 추가하는 데 더 관심을 갖게 되기 때문에, 바이브 코딩으로 v1에 도달하는 것이 불가능해 보인다는 겁니다. 예컨대, 깔끔하게 다듬어진 알고리즘을 찾아서 테스트가 몇몇 값만을 커버한다고 관찰한 뒤, 그 값들을 그냥 하드코딩해서 여전히 "통과"하도록 알고리즘을 단순화하려 들죠.
2025년 10월 16일 6:06 UTC (목) 게시자: azumanga (구독자, #90158) [링크]
물론 선택은 당신 몫이지만, 더 최신 모델을 아직 써 보지 않았다면, 한 번 써 보길 권합니다.
저는 서서히 죽어가던 Python 2 프로그램에 갇혀 있었고, 몇몇 사람들이 Python 3로 업데이트하려 시도했다가(그리고 실패했다가) 포기한 상태였습니다. 전에 저는 4일을 꽉 채워 시도했지만 어디에도 가까워지지 못하고 포기했습니다.
Claude Code와 오후 한나절을 앉아 있었고, 완전한 Python 3 변환을 끝냈습니다.
Claude는 Python 3 버전이 없는 것들의 대체 라이브러리를 찾아 주었고, Python 3 업그레이드를 받지 못한 몇몇 함수의 새로운 구현을 작성해 주었습니다(체크했는데, 원본을 그냥 복사한 건 아니었습니다). 그리고 Python 2 -> Python 3 업그레이드 과정에서의 모든 유니코드 문제를 해결하도록 도와줬습니다.
2025년 10월 15일 20:39 UTC (수) 게시자: SLi (구독자, #53131) [링크] (7개 응답)
ChatGPT만 써 본 게 아니라면, LLM이 만든 코드는 단일 프롬프트의 결과도, 심지어 한 번의 대화의 결과도 아니며, 보통 다음과 같은 워크플로의 결과라는 것을 알 것입니다:
ChatGPT만으로도 사실 그래야 합니다.
저는 LLM이 절대적으로 쓸모없다고 우기는 사람들과, 그것으로부터 많은 좋은 것을 얻는 사람들 사이의 일반적인 차이가 바로 이거라고 의심하게 되었습니다. 문자로 의사소통하는 데 그다지 능숙하지도 않은(우리 중 많은 이들이 그렇습니다. 기술 글쓰기가 학문인 데는 이유가 있습니다) 사람에게 단 하나의 엉성한 프롬프트를 쓰게 하고, LLM이 그의 마음을 읽지 못했을 때 결과를 일축하는 것이죠.
2025년 10월 15일 20:54 UTC (수) 게시자: Wol (구독자, #4433) [링크] (1개 응답)
하지만 제가 더 명확히 하려고 할 때마다, AI는 같은 구덩이를 더 깊이 파고들 뿐입니다.
좋아요, 제가(알고) 사용한 유일한 AI는 구글 검색입니다. 적어도 제 쿼리를, 그것이 답하려는 쿼리로 바꾸어 표현해 주는 점은 예의가 있죠(그리고 그렇게 바꾼 쿼리에 대해서는 꽤 잘 답합니다). 문제는 그것이 답하는 질문이 제가 던진 질문과는 거의 닮지 않았다는 겁니다.
건배,
Wol
2025년 10월 15일 21:19 UTC (수) 게시자: SLi (구독자, #53131) [링크]
네, 구글 검색은 매우 우스꽝스럽죠, 특히 "사람들이 함께 묻는 질문" 결과가요 :)
2025년 10월 16일 8:17 UTC (목) 게시자: taladar (구독자, #68407) [링크]
이상하게도 "그것으로부터 많은 좋은 것을 얻는다"는 사람들이 유튜브나 다른 어디에서도, 노력 대비 출력 품질의 비율 면에서 설득력 있는 결과를 보여주는 동영상을 만든 적은 한 번도 없었습니다.
2025년 10월 20일 8:35 UTC (월) 게시자: ssmith32 (구독자, #72404) [링크] (3개 응답)
그건 약간 허수아비 논증 같습니다. 저처럼, 간단한 변환이나 여전히 코드베이스에 남아 있는 보일러플레이트 생성(여러 다양한 이유로 안타깝게도 계속 남습니다)에 유용하다고 느끼는 사람은 충분합니다. 하지만 간단한 작업에서 웃길 정도로 실패할 수 있다는 것도 인지합니다.
저는 Claude 기반 어시스턴트에게 다음을 요청했습니다:
특정 버전으로 라이브러리를 업그레이드하라. 그런데 대신, 해당 라이브러리와 이름이 비슷한, 전혀 관계없는 구성 값을 라이브러리 이름으로 바꿨습니다. 그 구성 파일은 빌드 시스템의 일부가 전혀 아니었습니다. LLM이 사람들이 주장하는 것처럼 정말로 "문맥"을 이해했다면, 그 파일에는 손대지 않았어야 합니다.
여전히 보일러플레이트가 필요한 데이터 저장소에 새로운 객체를 써 넣기 위한 보일러플레이트를 잔뜩 생성하라. 대부분 제대로 했습니다.
도커파일을 만들어 달라. 시간을 절약했고 작동했습니다. 하지만 쓸모없는 군더더기가 유난히 많이 붙었습니다. 그래도 처음부터 직접 만드는 것보다 그걸 빨리 제거하는 게 더 빨랐습니다.
맥에서 특정 자바 버전을 설치하는 방법. 완전히 실패했습니다. 더 이상 존재하지 않는 캐스크를 사용하라고 고집했고, 더 이상 해당 버전을 호스팅하지 않는 위치에서 다운로드하라고 하는 등등. 분명 오래된 블로그들에서 제안을 그대로 토해 낸 것이었습니다.
코드베이스에 유사한 패턴이 있거나, 문서와 랜덤 웹사이트에 (정확한) 예제가 많다면 잘할 수 있습니다.
빌드에 추상적으로 끌려 들어오고, 다른 라이브러리도 업데이트해야 함을 이해해서 라이브러리 버전을 업데이트하는 것처럼 사소해 보이는 것처럼 보이지만 새로운 것이거나 독특한 것 — 혹은 진짜로 흥미로운 독특한 것이라면 — LLM은 형편없이 실패합니다.
놀랍지 않습니다. 작동 방식을 이해하고 나면 유용한 도구입니다. 그리고 상당한 양의 코드는 사실 그다지 새로운 것이나 독특한 일을 하지 않습니다.
설계에 대한 대화에는, 제게는 여전히 동료나 고무 오리가 훨씬 더 좋습니다.
2025년 10월 20일 12:36 UTC (월) 게시자: pizza (구독자, #46) [링크] (2개 응답)
놀랍지 않습니다. 작동 방식을 이해하고 나면 유용한 도구입니다. 그리고 상당한 양의 코드는 사실 그다지 새로운 것이나 독특한 일을 하지 않습니다.
다시 말해, LLM이 가장 유용한 곳은 두 가지입니다:
보일러플레이트를 생성하던 개발 환경의 "마법사"의 후계자 [1]
화려한 자동완성.
[1] 90년대 초 Microsoft의 Visual<whatever> 개발 환경에서 대중화된 대화형 프롬프트 기반 템플릿 엔진을 가리킵니다.
2025년 10월 22일 17:25 UTC (수) 게시자: raven667 (구독자, #5198) [링크] (1개 응답)
그 말이 맞는 듯합니다. 또 추가하자면, 기존의 포괄적 프레임워크를 아주 단순하게 사용하는 것도 LLM이 토해낼 만한 일처럼 보입니다. 예컨대 간단한 CRUD 앱을 만드는 방법 같은 보일러플레이트는 훈련 데이터에 예제가 충분히 있어야 하므로, 필드 이름을 알려주면 장고(Django) 앱을 내뱉을 수 있어야 할 겁니다. 하지만 그 이론은 시험해 보지 않았습니다. LLM은 한 번도 안 건드렸거든요. 아마 ffmpeg 호출에 대한 자유 형식 텍스트 프런트엔드 정도? ;-)
2025년 10월 23일 7:32 UTC (목) 게시자: taladar (구독자, #68407) [링크]
CRUD 앱을 자동 생성만 원한다면 LLM은 과잉일 것 같습니다. 일반 템플릿 엔진으로 쉽게 할 수 있을 겁니다. 아마 프로젝트 템플릿 도구의 단순한 것들로도요(예: cargo-generate, Python에도 대응물이 있는지는 모르겠습니다)
2025년 10월 23일 10:34 UTC (목) 게시자: jvoss2 (손님, #7065) [링크] (1개 응답)
이 점을 두 번째로 강조하고 싶습니다: 제 생각에 "프롬프트"를 문서화하라는 요구는 실용적이지 않습니다. 너무 많은 작은 프롬프트 조각이 있고, 일부는 사용자가 타이핑하며 일부는 시스템 프롬프트, 도구 설명, 하위 에이전트를 위한 미리 작성된 가이드 등에서 오기 때문입니다. 이것들을 어떻게든 모두 소화 가능한 형태로 묶을 수 있다 하더라도, 별로 유용하지 않을 겁니다. LLM이 하는 일은 요청이 이루어진 시점의 파일 시스템 상태에도 좌우되기 때문입니다. (예: "somefile.c의 코드를 검토해 주세요. [LLM이 생각하고 보고함] 좋아요, 함수 시작 부분 근처에 명시적 체크를 추가해 당신이 발견한 정수 오버플로를 고쳐 주세요.")
2025년 10월 24일 7:50 UTC (금) 게시자: taladar (구독자, #68407) [링크]
더 중요한 것은, 정확한 모델에도 좌우된다는 점이며, 적어도 호스팅된 모델의 경우 과거의 어떤 요청과 정확히 같은 버전을 얻는 방법이 없다는 겁니다.
2025년 10월 25일 19:28 UTC (토) 게시자: davidgerard (손님, #100304) [링크]
당신 말은: "그렇게 멍청할 리 없어, 당신이 프롬프트를 잘못 주고 있는 거야"라는 건가요?
2025년 10월 15일 4:42 UTC (수) 게시자: pabs (구독자, #43278) [링크]
리브레 ML 모델, LLM 또는 AI가 어떤 모습일 수 있는지에 대한 논의가 있었나요?
개인적으로는 Debian의 해당 문서가 마음에 듭니다:
https://salsa.debian.org/deeplearning-team/ml-policy/
적어도 일부는, 예컨대 자연어 번역, 오디오 노이즈 제거, TTS, STT 등과 같은 것들을 위해 매우 유용할 것입니다.
2025년 10월 16일 1:20 UTC (목) 게시자: davecb (구독자, #1574) [링크]
하나는 기하학적이고 다른 하나는 대수적인 모델에서 통계적 학습을 하는 것만도 충분히 어렵습니다. 이제 그중 하나를 버그투성이로 만들어 보세요.
헹구고, 반복하세요.
Copyright © 2025, Eklektix, Inc.
이 글은 Creative Commons CC BY-SA 4.0 라이선스 조건에 따라 재배포할 수 있습니다
댓글과 공개 게시물의 저작권은 작성자에게 있습니다.
Linux는 Linus Torvalds의 등록 상표입니다
LWN .net News from the source