Understanding Over Origin
Many of developers communities are asking the wrong question. Not because they're wrong to worry...
개요 #
요즘 개발자 커뮤니티에서 "이거 AI로 만든 거 아니야?"라는 말이 일종의 심사 기준처럼 쓰인다. 겉보기엔 저품질 결과물을 걸러내려는 합리적인 태도 같지만, 실제로는 도구의 출처만 볼 뿐 결과물의 완성도는 전혀 가려내지 못한다.
Adam은 이 잣대의 허점을 정면으로 지적한다. AI를 썼는지 여부는 코드가 잘 만들어졌는지에 대해 아무것도 말해주지 않는다는 것이다. 정작 봐야 할 것은 "제작자가 자기 결정을 설명할 수 있는가, 결과를 책임지는가"인데, 커뮤니티는 그 자리에 체크박스 하나를 놓아버렸다.
두 프로젝트, 같은 라벨 #
글쓴이는 Open Vectorizer 프로젝트를 둘러싼 논쟁을 예로 든다. 제작자 Madsen은 자신의 작업을 공유하고 기여자를 모으고 싶어 했지만, 돌아온 반응은 "AI 프로젝트가 너무 많아서 싫다" 같은 말들이었다.
여기서 문제가 드러난다. 이제 게이트키퍼들에게 "AI가 생성한 것"과 "제대로 유지·관리되는 엔지니어링"의 차이는 보이지 않는다. 심사가 단 하나의 이분법으로 쪼그라들었기 때문이다. "AI를 썼나, 안 썼나."
두 프로젝트를 떠올려 보자.
- 프로젝트 A: 2년에 걸쳐 벡터화 알고리즘을 다시 설계하고, 머신러닝 도입 여부를 검토한 뒤 결정론적 방식을 택했다. 자기 벤치마크가 부풀려져 있다는 걸 스스로 발견해 고쳤고, 재현 가능한 결과를 공개하며 코드를 꾸준히 관리한다.
- 프로젝트 B: "음악 스트리밍 앱 만들어줘"라고 AI에 입력한 뒤 테스트도 없이 결과물을 올리고 사라졌다.
둘 다 AI를 썼고, 둘 다 "AI 생성물"로 묶인다. 하나는 커뮤니티에 있어야 할 작업이고, 다른 하나는 정확히 커뮤니티가 걸러내야 할 것이다. 그런데 현재 기준으로는 둘 다 똑같이 거부당한다.
Photo by "AI가 만들었다"는 품질 기준이 될 수 없다 #
게이트키핑 논리는 첫인상만 그럴듯하다. 뜯어보면 허점이 많다.
"네가 만든 거 아니잖아"라는 반응. 이 말은 실제 기술 작업을 통째로 무시해야만 성립한다. Madsen은 알고리즘 파이프라인 전체를 다시 짰고, 기존 도구들과 비교 테스트했으며, 자기 벤치마크를 유리하게 보이게 만들던 버그를 잡아내 더 나쁜 수치를 그대로 공개했다. 프롬프트 한 줄 던지고 끝낸 사람과는 거리가 멀다.
검증되지 않은 AI 코드의 위험. 누군가는 검수 없는 AI 생성 코드가 보안 취약점을 낳는다고 짚는다. 유지보수와 책임에 관한 정당한 우려다. 문제는 그걸 근거로 모든 AI 협업 프로젝트를 기술적 검토도 하기 전에 거부한다는 데 있다. 저품질 코드에 대한 걱정은 타당하지만, "도구를 썼으니 거부"라는 방식은 그 걱정을 전혀 해결하지 못한다.
언어를 생각해 보자. Rust가 메모리 안전을 쉽게 해준다고 해서 모든 Rust 패키지를 통과시키지 않고, C가 메모리 오류를 허용한다고 해서 모든 C 프로젝트를 불안전하다고 단정하지 않는다. 언어 선택은 확률에 영향을 줄 뿐 품질을 결정하지 않는다. AI도 마찬가지다.
"예전 Dev.to는 좋았는데"라는 향수. AI 도구가 등장하기 전 커뮤니티는 더 수준 높았다는 전제가 깔려 있다. 하지만 사람들은 1980년대부터 형편없는 코드를 올려왔고, 스팸도 늘 있었다. AI는 그걸 더 싸고 쉽게 만들었을 뿐, 없던 문제를 만들어낸 게 아니다.
진짜 문제는 따로 있다 #
커뮤니티가 실제로 범람하는 건 "AI 생성물"이 아니라 저품질 결과물 그 자체다. AI가 제작 비용을 낮추면서 그 물결이 감당하기 어려운 속도로 불어난 것뿐이다.
해법은 "AI를 금지하라"가 아니다. 신호와 소음을 실제로 가르는 기준을 세우는 것이다.
- 제작자가 아키텍처를 설명할 수 있는가, 아니면 스택오버플로를 읽어주는 수준인가?
- 의미 있는 테스트가 있는가?
- 주장한 결과를 독립적으로 재현할 수 있는가?
- 벤치마크가 투명한가?
- 약점을 스스로 공개하는가?
- 변경 사항을 직접 리뷰하고 책임지는가?
- 6개월 뒤에도 유지될 프로젝트인가, 한 번 쓰고 버릴 실험인가?
이 질문들은 사람이 직접 쓴 코드에도 똑같이 적용된다. 그리고 하나같이 검증 비용이 비싸다. 직접 읽고, 생각하고, 판단해야 한다.
반면 "AI 썼어?"는 싸다. 체크박스 하나면 되고, 원칙 있어 보이며, 심사자를 곧바로 다음 일로 넘어가게 해준다. "이게 제대로 된 엔지니어링인가?"라는 질문만이 작업과 실제로 씨름하게 만든다.
소프트웨어는 늘 이렇게 흘러왔다 #
돌아보면 소프트웨어 개발은 항상 이런 식이었다.
어셈블리에서 C로 넘어갈 때 아무도 "컴파일러 쓰니까 진짜 코딩 아니다"라고 하지 않았다. 수동 메모리 관리에서 가비지 컬렉션으로, 생 SQL에서 ORM으로, 손으로 쓰던 Dockerfile에서 템플릿으로, 스택오버플로 복붙에서 IDE 리팩터링을 거쳐 Copilot 자동완성으로 옮겨왔다.
단계마다 추상화 수준이 높아졌고, 그때마다 "개발자가 게을러진다, 기준이 무너진다, 기예가 희석된다"는 걱정이 뒤따랐다. 그러나 매번 정작 중요한 질문은 "어떤 추상화 수준을 썼나"가 아니라 "생성된 결과를 이해하는가, 방어할 수 있는가, 유지할 것인가"였다.
AI는 그 연장선 위의 다음 단계다. 더 공격적이고 더 눈에 띄며 평범한 결과물을 더 빠르게 쏟아낸다는 차이가 있을 뿐, 반복 작업을 넘겨 중요한 결정에 집중하게 해주는 도구라는 본질은 다르지 않다. 고급 언어가 처음 나온 이래로 사람들은 줄곧 소프트웨어 개발이 끝났다고 말해왔다. 같은 불안이 이름만 바꿔 돌아올 뿐이다.
좋은 심사는 이렇게 한다 #
핵심은 "문을 활짝 열자"가 아니라 무엇을 거르는지를 바로잡는 것이다.
좋은 심사라면:
- AI가 상당 부분 관여했다면 그 사실을 공개하도록 요구한다(투명성).
- 재현성, 테스트 커버리지, 제작자의 책임성으로 프로젝트를 판단한다.
- 공개 벤치마크나 활발한 버그 대응이 있는 프로젝트를 빠르게 통과시킨다.
- 뻔한 저품질 결과물을 출처가 아니라 깊이의 부재로 잡아낸다.
- 배우는 중인 사람에게 자리를 내주되, 성의 없는 재게시는 걸러낸다.
나쁜 심사는 지금 벌어지는 일이다. AI가 관여한 모든 작업을 "프롬프트 던지고 게시"와 동일시하는 일괄 금지, 기술적 알맹이를 한 번도 들여다보지 않는 무시성 댓글, 엄밀함의 부재가 아니라 도구의 존재만으로 내리는 거부.
AI 협업 콘텐츠를 금지하는 대신 공개를 요구하는 Dev.to의 방향 전환은 바람직하다. 정직할 책임을 제작자에게 지우고, 판단은 실제 작업을 보고 커뮤니티가 하도록 맡기기 때문이다.
결국 남는 것 #
댓글 창에서 unitbuilds가 남긴 말이 이 논쟁의 핵심을 짚는다.
"소프트웨어 개발은 오케스트레이션 과정이다. 궁극의 가치는 사람이 타이핑한 시간이 아니라, 동작하고 감사받고 테스트된 소프트웨어에 있다."
커뮤니티의 역할은 작업을 공유하고 실질적인 피드백을 주고받는 것이지, 방법을 단속하는 게 아니다. 풀타임으로 일하면서 99% AI로 3000줄짜리 게임을 만든 사람도, Copilot으로 반복 작업을 자동완성한 사람도, AI의 도움으로 아키텍처를 결정하되 설명 못 할 것은 내놓지 않는 Open Vectorizer 제작자도 모두 자기 작업을 공유할 자격이 있다.
이들 중 누구도, 작업의 품질에 대해 아무것도 말해주지 않는 라벨 하나로 무시당할 이유는 없다.
좋은 엔지니어링과 저품질을 가르는 질문은 단순하다.
- 아키텍처 결정을 설명할 수 있는가?
- 무엇이 깨졌고, 어떻게 고쳤는가?
- 벤치마크는 재현 가능한가?
- 이걸 유지할 것인가?
- 지적받으면 고칠 의향이 있는가?
이 질문들은 코드를 사람이 쳤든, Claude가 생성했든, 둘을 섞었든 똑같이 유효하다. 늘 품질을 결정해온 것은 결국 이해와 책임이었기 때문이다.
엔지니어링은 이해, 정확성, 유지보수성, 테스트, 책임으로 평가해야 한다. 키보드를 몇 번 두드렸는지로 평가할 것이 아니다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.