요약
QGIS가 AI의 도움을 받아 만든 코드 기여를 전면 금지했습니다.
무료 오픈소스 지리정보시스템(GIS) QGIS의 핵심 개발자 니얼 도슨이 9월 24일 정책 변경 제안을 올렸습니다. 이 제안은 투표를 거쳐 10월 7일 채택됐습니다. 사람이 검토하면 AI 사용을 허용하던 기존 정책이 효과가 없었다는 판단에서 나왔습니다.
왜 중요한가
- 대형 오픈소스 프로젝트가 AI 기여를 조건부로 받는 방식이 실패했다고 공식적으로 인정한 사례입니다.
- 프로젝트 측은 이번 조치를 임시방편으로 보고, 자동완성·번역 같은 용도는 나중에 하나씩 허용할 수 있다고 밝혔습니다.
핵심 내용
- 새 정책은 qgis/qgis 저장소에서 LLM, AI, 에이전트의 도움을 받은 코드 기여를 받지 않는다고 못 박았습니다.
- 위반이 드러나면 코드를 되돌리고 기여자 권한을 제재합니다.
- 이전 정책에서 'AI 지원' 표시가 붙은 PR(코드 변경 요청) 약 50개 가운데 40개가량이 병합되지 못하고 닫혔습니다.
- 찬성 측은 AI가 쏟아내는 기여가 유지보수자의 검토 능력을 넘어섰다고 지적했습니다.
- 이슈·문서·보안 보고서까지 막을지는 정리되지 않아, 범위를 넓히는 별도 제안이 논의 중입니다.
HN 반응
- Plotly, PgDog 등 다른 프로젝트 관리자들은 검토 안 된 AI 이슈와 PR에 시달린다며 공감했습니다.
- 반면 AI로 고친 작은 패치가 몇 주째 방치돼 개인 포크(저장소 사본)로 유지한다는 이용자들도 있었습니다.
저처럼 QGIS가 뭔지 몰랐던 분들을 위해 설명하면, 무료 지리정보시스템(GIS)입니다. 지리 공간 정보를 만들고, 관리하고, 분석하고, 저장하고, 시각화하는 도구라는 뜻이죠. (3D) 지도 같은 걸 떠올리시면 됩니다.
지리 공간 작업에는 LLM을 망가뜨리는 뭔가가 있는 것 같아요. 최신 Fable과 Opus 둘 다에서 정말 자주 겪었는데, 자신 있게 말하지만 틀린 답을 내놓는 전형적인 악몽입니다.
어제 거리 가중치로 뭔가를 측정하는 비교적 간단한 작업을 하고 있었는데, Claude가 꽤 잘 해냈어요. 그런데 마지막에 성공 지표도 있고 그 지표에 맞는 좋은 결과도 많이 나왔는데도, Claude가 제 수식이 틀렸으니 고쳐야 한다고 우기더군요.
이유를 묻고, 제안한 대체 수식이면 거리 가중치가 아예 상쇄돼 버린다고 짚었더니 곧바로 맞다고 인정하면서, 그 일을 다섯 번째 프로젝트 메모리로 적어 두겠다고 하더라고요.
엄격한 가드레일 없이는 자주 틀리는 다른 큰 분야는 좌표계와 측정입니다. 국가 격자 좌표와 wgs84 위도/경도를 오가면서 정밀도를 상당히 잃어버리는 식으로 변환하고, 국가 격자 좌표로 그냥 뺄셈 한 번이면 될 거리를 재려고 하버사인 비슷한 함수를 직접 짜기도 해요. 어이가 없습니다.
저는 요즘 의외로 꽤 효과적이라고 느꼈어요.
로봇 군집용 OpenLayers 기반 지도 편집기에 들어가는 공간/토폴로지 검증 시스템을 개편하고 있습니다. 공간 인덱스와 술어(predicate), 그리고 기본적인 지오툴박스 함수를 깔끔한 인터페이스로 정리해 뒀고요.
가장 놀랐던 순간은 Opus가 테스트에서 합집합(union) 방식이 느리다는 걸 알아챘을 때였어요. 로봇의 풋프린트가 항상 유효한 폴리곤 안에 있는지(여러 유효 폴리곤에 걸쳐 있는 경우 포함) 확인하는 방식이었는데, 그래서 풋프린트의 AABB 안에 있는 각 폴리곤과의 차집합을 구하는 쪽으로 바꿨습니다. 남은 도형의 크기가 0이면 유효한 것이고, 아니면 남은 도형이 유효하지 않은 부분이 되는 거죠.
또 “테스트 데이터에 이런 유형의 피처가 많으니, 적중과 미적중 중에 뭐가 더 흔한지 먼저 살펴보자”는 식으로 짚어내는 것도 놀라웠어요.
로봇 일을 하기 전에는 데이터 처리와 분석을 위한 공간 모델을 오래 만들었습니다. 지금은 공간 문제를 자연어로 설명하기만 해도 데이터셋에서 필요한 입력을 찾아내고 처리 과정까지 짜 주는 경우가 대부분이에요. 그렇다고 제가 아직 쓸모없어진 건 아닙니다. 10~20% 정도는 불필요한 중간 데이터 산출물을 만들어 가며 꽤 환상적인 여정을 떠나거든요.
아, 오해하지 마세요. 그런 점이 있어도 레벨업 시켜 주는 괴물이긴 합니다.
걱정되는 건 바짝 지켜보지 않으면 탄탄한 시스템을 얻고 있다고 착각하기 쉽다는 거예요. 내부에서 벌어진 광기 때문에 격자 전체가 사실상 오른쪽으로 10미터 밀려 있고, 공간 측정값도 겉으로 보이는 것보다 훨씬 부정확할 수 있거든요.
저한테는 그게 지난날의 암흑기였습니다. 요즘은 투영이나 실제 공간 계산은 특정 시스템만 쓰도록 묶어 두는데, 그러면 정직하게 굴더라고요.
그리고 놀라운 일이 생길 때는 정말 근사해요! 제가 제일 좋아하는 건 원시 데이터만 보고 스스로 추론해 내는, 있었으면 했던 온갖 QA 단계들입니다.
“어, 이 도시는 데이터가 없는데 인구는 많네. 아, 잘 안 알려진 룩업 테이블에서 행 하나가 잘려 나갔구나. 자, 해결.”
솔직히 저는 한발 물러서서 박수를 치게 됩니다.
LLM은 개념적으로는 단순하지만 지루한 분류 문제를 전반적으로 아주 잘 풉니다.
저는 이걸로 몇 시간씩 아낀 적이 있어요. 예를 들어 일관되지만 알 수 없는 스키마를 가진 복잡한 JSON 객체들로 이뤄진 큰 집합에서, 작은 부분집합 A와 서로소인 표본 B를 줍니다. 그리고 B의 어떤 객체에도 해당하지 않는, A의 객체들만의 공통점이 뭐냐고 묻는 거죠.
Claude가 내놓은 결과 예시는 이랬습니다. A의 모든 레코드에서 foo 필드에는 2016년 8월 3일부터 7일 사이의 날짜가 들어 있고, B의 모든 레코드에는 그보다 나중 날짜가 들어 있다.
Claude는 이게 문서 관리 시스템의 메타데이터라는 것, foo 필드가 문서 생성일이라는 것, 그리고 모든 레코드에서 똑같이 10인 옆 필드 bar가 연 단위 문서 보존 기간이라는 것, 따라서 A가 2026년 8월 3일부터 7일 사이에 폐기됐을 문서들이라는 것까지 정확하게 추정해 냈습니다.
아, 정말 그래요. 입력 좌표계가 달라서 격자가 안 맞는 바람에 래스터가 완전히 엉망으로 나왔던 기억이 갑자기 떠올랐네요. 제가 겪어 본 평범한 프로그래밍 작업들보다 훨씬 더 바짝 감독해야 하는 건 여전합니다.
저한테 큰 도움이 된 건 제 도메인 전용 데이터셋/시스템과 QGIS 사이에 어댑터를 만든 거였어요. 그러면 중간 단계를 보면서 살펴볼 수 있고, 시각적 패턴 매칭만큼은 제 두뇌가 여전히 꽤 훌륭하다는 점을 활용할 수 있거든요.
으악! 래스터 악몽 얘기에 저도 같이 오싹했어요. 저도 완전히 겪어 봤거든요. 시각적 패턴 매칭 본능도 너무 공감합니다. 저도 그렇게 일해서 신기하네요. 위대한 생각은 통한다고 하죠.
참고로 저는 어댑터로 duckdb와 그 공간 기능을 씁니다. 제 두뇌에 잘 맞고, 단계마다 SQL 파일을 쓰도록 강제하면 비슷한 방식으로 흘러가요. 아직 거친 부분은 있지만 전체적으로는 잘 돌아갑니다. 그러다 Claude가 제 수식에 시비를 걸면 저는 울죠.
LLM은 공간을 정말 이해하지 못합니다.
어제 부동산 사진에 테라스를 넣어 보려고 했어요. 이른바 “가상 스테이징”이죠.
같은 집을 다른 각도에서 찍은 사진 4장을 올렸습니다.
Gemini, ChatGPT, Grok에게 각 사진에 똑같은 테라스를 추가해 달라고 했는데, 결과가 웃음이 나올 만큼 일관성이 없었어요(보기에도 흉했고요).
4장의 사진이 3D로 일관되게 맞도록 몇 번이나 요청했지만, 이걸 할 방법이 아예 없다는 게 뻔히 보였습니다. 장면을 이해하지 못하는 거예요.
그리고 집을 서로 다른 각도에서 찍은 경우에, 집을 기준으로 한 “뒤쪽 테라스”와 “옆쪽 테라스”라는 개념도 이해하지 못했습니다. 어느 쪽이 옆쪽 테라스인지 짚어 줘도 다른 이미지에서는 또 헷갈리더라고요.
(놀랄 일은 아니고, 다들 LLM의 능력이 “들쭉날쭉하다”고 말한다는 것도 알아요. 그래도 이걸 보면 제가 해커뉴스 같은 데서 읽은 AI에 대한 온갖 외삽이 얼마나 형편없었는지 알 수 있습니다)
제 생각에 그런 작업은 LLM이 (아주 조용히) 지원하지 않는 방식으로 여러 능력을 가로지르는 일 같습니다.
LLM은 사진을 설명하는 건 잘하지만, 설명하는 대상의 정확한 좌표는 말하지 못해요. 제가 마지막으로 시험했을 때는 좌표를 거짓으로 지어내게 만들 수는 있었지만, 특정 대상 주위에 대략적인 경계 상자를 그려 보라고 하면 완전히 실패했고, 어떨 땐 웃음이 날 정도였습니다.
이건 가드레일이나 생물 테러 방지보다 훨씬 더 절실한 정렬 문제 같아요. 봇이 자기가 못 하는 게 뭔지 알기나 할까요? 경계 상자를 틀리게 그리면서도 그렇게 열심인 모습이, LSD 합성법을 알려 줄 의향이 있는지보다 저한테는 훨씬 더 걱정스럽거든요.
맞아요. 저는 AI에게 흑백 평면도 위에 가구 모양 직사각형들을 배치해 보라고 시켜 봤는데, 불가능했습니다. 방의 모서리를 찾고 그 방에 적힌 치수를 읽어 내는 flood fill을 짜게 하는 것까지는 공들여 이끌어 줄 수 있었지만, 그러면 이미지를 보는 능력은 전혀 쓰지 않는 셈이었어요. 그러고도 특정 직사각형을 왼쪽 아래 모서리에 붙이는 것 같은 건 여전히 못 했고요.
이해하긴 하지만 어떤 구체적인 공간 과제를 배우도록 적용했을 때만 그런 것 같아요.
예를 들어 최근 프론티어 모델이 CAD 같은 작업에서 정말 잘하게 된 걸 볼 수 있습니다. 어느 정도는 벤치 점수 올리기용 RL이라는 걸 시사하지만, 그래도 단순한 형상을 단계별로 만드는 데는 갑자기 꽤 능숙해졌다는 뜻이긴 하죠.
저도 threejs로 3D 코드를 짤 때 비슷한 문제를 겪었어요. 1년도 더 전에는 모델이 꽤 형편없었고, 1년쯤 전에 그럭저럭 쓸 만해졌고, 최신 모델은 꽤 잘합니다.
그래서 고정된 프롬프트로 간단한 A/B 테스트 평가를 만들었어요: https://threejseval.com
좌표 추론이 얼마나 나아졌는지 정말 잘 보여 주는 7자유도 로봇 팔이 있습니다.
https://threejseval.com/gallery?eval=robot-arm
Plotly에서도 비슷한 문제를 겪고 있습니다. 따라가려고 최선을 다하고 있지만, 지나가던 커뮤니티 기여자들의 기여는 그냥 손절하고 싶은 마음을 누르기가 정말 힘들어요. 아무도 교정하지 않은 3쪽짜리 이슈 보고서, 우리가 후속 질문을 해도 답하는 건 봇뿐이고, 그럴싸하지만 허술한 PR이 리뷰어 시간을 잡아먹는 엄청난 물량까지요. 저희는 정말 집중하고 싶은 핵심 작업이 있는데, 이 봇 말고는 아무도 겪지 않았을 버그 수정을 또 병합하고 있을 수는 없잖아요.
Hatchet에서도 기본적으로 똑같은 상황이었고, 마찬가지로 힘듭니다. 최근에 제가 본 비핵심 기여자들의 OSS PR 리뷰는 사실상 다른 사람을 거쳐서 Claude와 주고받기를 하는 게 대부분이라 답답해요. 1) 그냥 안 하거나 2) 제가 직접 Claude와 주고받으면서 중간 사람을 빼 버릴 수도 있을 것 같은데 말이죠.
사람들이 에이전트에게 저장소 500개를 체크아웃시키고 “이 저장소에서 버그를 찾아 고쳐”라고만 프롬프트를 준 다음 결과를 확인도 없이 제출하는 것 같다는 불길한 의심이 듭니다.
수정: 모바일이라 오타가 있었습니다
> 사람들이 에이전트에게 저장소 500개를 체크아웃시키고 “이 저장소에서 버그를 찾아 고쳐”라고만 프롬프트를 준 다음 결과를 확인도 없이 제출하는 것 같다는 불길한 의심이 듭니다.
여러 곳에서 나오는 보고를 보면 정확히 그런 일이 벌어지고 있다고 확신해요. 사람들은 이름이 붙은 버그를 찾아낸 영광을 원하고, 봇이 찾아낸 게 정말 엄청나게 중요한 것이라면 더 널리 쓸모 있는 평판이 따라올 거라고 믿는 사람도 있을 겁니다. 게다가 저장소 500개에서 끝나지도 않아요. 하나를 스캔할 때마다 계속 진행하라고 시키니까요.
이건 부트캠프와 “스팸성” 대학에서 진지하게 “문턱을 넘는 방법”이라며 권하는 얘기예요. 농담이 아니라요.
깃허브 스타가 일정 수 이상인 오픈소스 프로젝트에 기여한 경험을 요구하는 채용 공고를 본 적이 있어요.
글쎄요, FOSS에 기여하는 건 명예로운 성취입니다. 입사로 가는 길로 여겨지죠. 이제는 그냥 조작하기 좋은 지표가 됐고, 그 과정을 자동화하기도 너무 쉽습니다.
여기에 “뒤처지고 있다”는 불안감이 커지는 데다, 소프트웨어 일자리가 언제든 무너질 거라는 대대적인 보도까지 겹치면, 기여했다는 증거는 뭐든 귀한 대접을 받아요. 그러니 안 할 이유가 없죠.
하지만 그렇게 하다가 그 명예를 스스로 무너뜨릴 거예요. 안타깝게도 OSS 모델은 이제 그런 사람들을 차단하도록 바뀌어야 할 테고, 서두르는 사람이 많을수록 그런 대응도 빨리 나올 겁니다.
오히려 반대로, 명예는 올라갈 거예요. 걸러내는 장치, 피로감, AI 기여의 전반적인 금지 때문에 PR이 받아들여지기가 더 어려워질 테니까요. 그 모든 걸 통과했다면 이제 진짜배기인 겁니다.
저희는 PgDog의 PR을 비활성화했고, 이슈는 일단 열어 뒀습니다.
AI가 생성한 GitHub 이슈로 보고되는 버그 대부분은 기술적으로는 버그지만 실제로 누가 겪은 적은 없는 엣지 케이스예요.
기여는 전부 AI가 만든 것인데, 그 GH 계정 뒤에 있는 봇에게 추가한 중복 테스트 5개를 지우라거나 3천 줄짜리가 돼 버린 파일을 리팩터링하라고 요청하느니, 제가 그냥 GitHub 이슈만 보고 직접 하는 게 훨씬 쉽습니다.
AI는 코드 품질, 유지보수성, 장기 목표에 신경 쓰지 않아요. RL로 최적화된 지역 최댓값일 뿐입니다. 디버깅에는 훌륭하고 리뷰에는 괜찮지만, 평균 이상인 건 아무것도 만들어 내지 못합니다.
정확한 지적입니다. AI는 타당한 엣지 케이스이긴 하지만 어쩌면 코드가 기대하는 바가 정해지지 않은 영역일 수도 있는, 동떨어진 엣지 케이스를 찾아내요. 그걸 처리하는 데 드는 복잡도를 피해야 모든 게 더 이해하기 쉽고 깔끔하게 유지되는데도요.
안타깝게도 사람들은 AI가 찾아낸 이런 엣지가 전부 타당하고, 반드시 고쳐야 하고, 아무도 생각해 본 적 없는 거라고 여기는 것 같습니다. 대부분은 이미 고려했고, if문 50개를 더해 가며 처리할 가치는 없다고 판단한 것들이에요. 순환 복잡도는 AI와 함께 기하급수적으로 폭발했는데, 다들 하는 대답은 “아니아니아니, 그냥 opus 6.5 쓰면 돼”입니다.
네, 공감은 하지만 저는 그 반대편 입장을 겪어 봤어요. 제가 버그를 하나 만났는데(Home Assistant용 통합 하나가 통합의 버그 때문에 HA를 재시작할 때마다 수동으로 깨워 줘야 했습니다), 제 AI가 한 줄로 고쳤어요. 저한테는 아주 잘 돌아갑니다. PR을 올렸는데 몇 주째 방치돼 있네요. 상관없어요. 제 AI가 제 패치가 적용된 개인 포크를 알아서 유지할 테니까요. 내 PR이 병합될 때까지(혹은 안 될 때까지요). 예전에는 직접 포크를 유지하면서 업스트림 변경을 병합하고 패치가 계속 동작하게 하는 일이 너무 큰 수고였죠.
한 방에 고쳐서 배포할 수 있는 AI 에이전트를 많은 사람이 갖게 되면서 이게 흔한 결과가 될 것 같아요. 어쩌면 그런 사람들과 메인테이너들이 각자 원하는 걸 얻으니 나쁜 일은 아닐지도 모르고요.
이건 일종의 일시적이고 불안정한 균형이라고 생각해요. 메인테이너들이 에이전트를 더 효과적으로 활용하는 법을 찾아내면, 매일 봇 작업을 돌려서 모든 포크를 조회하고 괜찮아 보이는 것만 가져오면 됩니다. 다만 기여자 쪽을 효과적으로 확장할 도구와 관행이 아직 갖춰지지 않았을 뿐이죠.
OSS는 원래의 Git 모델에 가까워지거나, 어쩌면 한 걸음 더 나아가 “수평적 유전자 전달”처럼 될 거라고 봅니다. 하나의 표현형 계보를 따르는 대신 밈/대립유전자가 여러 저장소에 걸쳐 복사되는 식으로요.
AI PR을 받는 포크와 AI 기여를 막은 포크를 따로 두는 게 흔한 결과가 된다면 흥미로울 것 같습니다. 양쪽 진영을 모두 만족시킬 뿐 아니라, 에이전트가 만든 코드의 품질과 유지보수성이 어떤 영향을 주는지 장기적인 사례로 남을 테니까요.
맞아요. 저도 KDE Spectacle로 거의 똑같이 했습니다. 주석 기능에 쓸 만한 단축키가 없어서 AI에게 추가해 달라고 했어요. 직접 검토한 아주 작은 패치를 메인테이너들에게 보냈는데 답은 못 받았습니다.
이건 일부는 정렬 문제인데, 사람 쪽의 문제입니다. 병목은 더 이상 코드를 쓰는 일이 아니라 코드와 계속 보조를 맞추는 일, 즉 코드가 뭘 하는지, 내가 의도한 대로 하는지 아는 일이에요. 제 일에서는 제가 직접 시킨 코드조차 이제 그게 일의 대부분입니다. 모르는 사람이 올린 큰 PR을 리뷰해야 하는 메인테이너들에게는 분명 훨씬 더 심할 거고요. 금지는 좀 가혹하지만, 왜 그들이 자신의 주의력을 배급제로 쓰는지는 이해합니다.
자기 소프트웨어가 뭘 하는지 아는 건 정말 어려운 문제입니다. 대부분의 개발자는 어렴풋이 알고 있지만, *어떻게 확신하죠?*라고 물으면 답을 통해 그들이 실제로 아는 게 얼마나 적은지 드러나요.
대개는 잘 동작한다는 신호와 지표에 만족하고, 뭔가를 증명하는 수고를 피하려고 이론과 멘탈 모델을 만들어 씁니다.
더 나쁜 건 LLM으로 코드를 생성하기 시작할 때 벌어지는 일이에요. 멘탈 모델의 지름길을 잃어 가면서 코드를 이해한다고 스스로를 속이게 된다고 느낍니다. 실제로 이해하는 건 거의 없는데도요.
게다가 몇 안 되는 코드 리뷰 연구들을 보면, 한 시간에 몇백 줄 넘게 읽고 나면 우리가 코드 품질에 미치는 영향은 아주 작다고 합니다.
그래서 지금의 정신적 도약은 “AI가 나보다 더 나은 프로그래머다”입니다.
그래도 저는 더 나은 프로그래머가 되는 게 여전히 가치 있다고 생각해요. 지름길은 없습니다. 그저 코드를 쓰고, 나쁜 코드를 쓰며 씨름해 보는 수밖에 없어요.