Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 소프트웨어 개발에서 '의존성 관리'와 'AI 활용 코드 검토'라는 두 가지 주제를 다룹니다. 특히, LLM이 생성한 코드가 실제 사람의 기여물로 오인되거나 과도하게 의존하는 현상에 대해 비판적 시각을 제시합니다. 핵심은 기술 자체보다 공동체 내에서의 배려와 지속 가능한 개발 문화가 중요하다는 점입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기저자 스스로 Rust가 C·C++·Vala보다 취약점을 10분의 1 수준으로 줄일 수 있다고 한다면, 언어를 피하기보다 의존성 버전을 고정하거나 GNOME 프로젝트에서 포크해 직접 관리하는 편이 맞다고 봄.
저자는 언어별 패키지 관리자 사용을 통제되지 않는 의존성과 동일시하는 듯하지만, 둘은 다름. Rust에서도 의존성을 통제하는 빌드를 구성할 수 있고, C++에서도 통제되지 않는 의존성을 사용할 수 있음.
악성 의존성에 대처할 방법은 메모리 안전성을 확보할 방법보다 훨씬 다양함. 보안 문제를 다루는 글에서, 이 이유로 상당수 문제를 손쉽게 해결할 수단을 넘겨버리는 건 납득하기 어려움.
최근 Cargo를 쓰지는 않았지만 Python, Node, Elixir는 꽤 다뤄봤는데, 여기서 의존성이 얼마나 되는지 궁금함. 다른 생태계에 비춰보면 전이 의존성이 적어도 수백 개는 될 것으로 예상함.
Vala가 왜 C, C++과 함께 묶이는지 궁금함. 필요하면 끌 수 있는 자동 메모리 관리 기능이 있는 것 아니었나?
지금 Clippy에 기여하려고 하는데, 유지보수자 입장에서는 상황이 암울해 보임. 예전에는 PR을 만들 수 있다는 것 자체가 역량의 신호였고, 문서와 테스트까지 있으면 훌륭한 기여자였음. 해결하는 이슈를 연결하고 무엇을 했는지 제대로 설명하면 만점이었음.
유지보수자는 늘 이런 신호로 한정된 시간을 어디에 쓸지 결정했고, 시간을 들이면 상대도 그 배려에 응답한다는 확신이 있었음. 이제는 며칠 동안 LLM과 직접 검토를 거듭하며 다듬은 코드인지, 이력서에 넣을 실적을 쌓으려고 Claude에 Ralph loop를 돌린 결과인지 구분하기 어려움. 상대가 실제 사람이라는 보장조차 없음.
Rust/Clippy의 정책은 최종 검토자와 유지보수자를 배려하며 LLM을 사용하는 방법을 사려 깊고 명확하게 제시함. 나도 코드를 꼼꼼히 다듬는 쪽이지만 일부 기준을 어겼고, 최종 결과물에 기계가 만든 코드가 없다고는 할 수 없어 PR을 닫고 다시 작성하기로 함. LLM을 이용한 취약점 탐지는 좋지만, LLM이 작성한 이슈와 PR은 좋지 않다고 봄. 검토자의 부담을 줄일 역량과 배려를 갖춘 사람이 필요함. 핵심은 언제나 작업 자체가 아니라 검토·유지보수·지속이 가능한 형태로 작업하는 것이었고, 이를 반영하는 공동체의 기준과 지침이 필요함.
여기서는 배려의 격차가 풀기 어려움. 제품을 빠르게 내놓는 데 익숙해져 어떤 마찰도 용납하지 않는 이들이 있고, 코드의 중요성을 받아들이는 정도도 달라짐.
업무 중 PR에 상세한 검토를 남겼더니 즉시 답변이 돌아온 적이 있음. 상대가 읽지도 않고 Claude에 “답변이 왔으니 처리해”라고 시킨 듯했음. 쏟아지는 자동화 기여를 배려로 받아내려다가는 번아웃만 심해질까 두려움.
“2026년에는 AI 취약점 탐지 없이 품질 좋은 소프트웨어를 유지할 가능성이 전혀 없고, 반대 주장은 망상”이라니 진심인가? 안전하지 않은 언어를 쓰지 않는 방법도 있고, 늘 포인터를 쓰는 대신 때로는 벡터를 쓰는 방법도 있지 않나?
이건 LLM 사용을 치켜세우기 위한 불성실한 논리로 보임. Rust가 싫다면 필요에 맞는 언어를 만들어 LLVM으로 컴파일할 수도 있음. C/C++/Vala를 계속 쓰며 사고가 안 나길 바라는 것보다 훨씬 쉬운 길이라고 봄.
그래도 Rust에서 버그를 만들 수 있다면?
내 작은 개인 프로젝트인 원주율 검색기도 Rust로 작성했지만, LLM이 잠재적인 XSS와 자원 과다 사용에 따른 서비스 거부 경로를 찾아줘 도움이 됨. 심각한 문제나 원격 코드 실행 수준은 아니어도 유용했음.
LLM이 버그를 찾아내는 건 능력이 대단해서라기보다 기술 업계가 보안을 진지하게 다루지 않았기 때문에 가까움. 생성형 AI 기업들이 모델을 돋보이게 하려고 수백만 달러를 쏟는 효과도 있음. 그 돈으로 침투 테스트 팀을 고용하면 LLM이 내놓은 결과보다 질과 양 모두 더 나을 것이라 확신함.
지구를 태우는 저질 결과물 생성기가 있어야 보안에 신경 쓰기 시작하는 것인지 씁쓸함. 사실 그런 기계를 투입한다고 보안을 진지하게 다루는 것도 아니니, 그 효과조차 있었는지 의문임. 어쨌든 이 극도로 비윤리적인 기술에 반대할 수밖에 없음.
10년 넘게 Rust 반대자들이 “Rust가 모든 보안 문제를 막지는 못한다”고 하면, 다들 “당연하지만 그래도 쓸 가치가 있다”고 차분히 설명해왔음.
그런데 이제는 Rust만으로 모든 보안 문제를 해결할 수 있다는 듯한 글을 보니 황당함. Rust를 쓰면 자동 취약점 검사도 필요 없고, 이미 존재하는 수백만~수십억 줄의 C·C++ 코드 보안을 개선할 필요도 없다는 식임.
기존 소프트웨어를 하룻밤 사이에 다시 작성할 수는 없음. JIT처럼 안전성과 비안전성의 경계를 자주 넘나들어야 하는 소프트웨어도 있으니, 안전하지 않은 언어를 쓰지 말자는 것만으로는 해결하기 어려움.
Cargo 의존성의 위험에는 전적으로 동의하지만, 그렇다고 GNOME에서 Rust를 피하자는 결론은 논리가 어긋난다고 봄. GNOME의 공식 Rust 라이브러리가 왜 침해된다고 보는가? GNOME 소프트웨어가 Cargo로 그 밖의 무언가를 가져와야 할 이유는 무엇인가? https://crates.io/ 에 의심스러운 라이브러리가 많다고 해서 전체가 안전하지 않은 것은 아님. 악성코드가 돌아다니니 인터넷 자체를 쓰지 말라는 것과 비슷함.
LLM의 확산이 낳은 적대적 영향으로 소프트웨어 품질의 정의 자체가 달라졌고, 그 변화에 대응하려고 LLM을 더 떠받들어야 하는 지경이 됨. 이렇게 되도록 내버려뒀다는 게 서글픔.
소프트웨어 품질 문제는 원래부터 존재했음. 이제 비용 효율적으로 찾아낼 방법을 발견했을 뿐이고, 이는 좋은 일임.
정말 서글픈 건 업계와 우리 자신이 오랫동안 현실을 외면하며 소프트웨어 품질을 방치하도록 내버려뒀다는 사실임. 다행히 이제 그 시기는 끝남.
LLM 검토가 이렇게 효과적이라는 게 좀 실망스러움. 명세도, 시뮬레이션 테스트도, 체계적인 방법론도 없는데 말임. LLM이 실제로 세심하게 주의를 기울일 수 있다는 뜻일까?
왜 실망스러운가? 예상보다 적은 전제 조건으로 예상보다 잘 작동한다면 반가운 소식 아닌가?
“AI 생성 취약점 보고를 계속 금지하는 프로젝트는 GNOME의 의존성으로 부적합하며 GNOME GitLab 밖에서 개발해야 한다”니, 품질이 들쭉날쭉한 AI 버그 보고를 처리하는 데 시간을 전부 쓰지 않으면 세계 최악의 개발 플랫폼에서 쫓겨난다는 건가? 참 어려운 선택임.
나도 그 강제성이 가장 불편함. 취약점 보고가 공익을 위한 활동이지 의무가 아니라는 데는 동의하지만, AI가 쓴 저질 보고서를 보내거나 아예 보고하지 않거나 둘 중 하나만 가능한 것은 아님.
직접 보고서를 쓰기 싫다면 취약점의 존재와 사용한 프롬프트만 전달하는 편이 나음. 유지보수자는 직접 확인하거나 원하면 자기 에이전트에 맡길 수 있음. 사실상 누구나 최상위급 에이전트를 쓸 수 있는데 굳이 생성 결과물까지 제출할 이유가 있을까?
AI 보고서는 사람이 읽기 너무 어려워 결국 받는 쪽도 에이전트를 쓰게 만드는 전염성이 있음. 꼭 그럴 필요는 없으며, 보고자가 직접 사람이 읽기 좋은 형태로 추려주면 모두에게 더 좋음.
인정하기 싫지만 저자가 맞는 부분도 있음. AI가 생성한 버그 보고서의 기묘한 용어 남발이 문제임. 배열 접근에는 늘 “gated”, 버전이나 테스트에는 “pinned”, 모든 테스트 사례에는 “fixture”라는 표현을 붙임.
이런 전문용어 남발과 장황한 문장 때문에 어떤 보고서든 헛소리일 가능성이 절반쯤 된다는 느낌이 듦. 그래도 이 글은 드물지만 실제로 존재하는 문제를 찾는 일과, 사람이 쓰지 않을 법한 문구를 해독하는 일 사이의 긴장을 잘 짚어줌.