신뢰의 웹을 구축해 LLM 스팸에 맞서기 — vouching으로 돌아오는 인터넷

신뢰의 웹과 LLM 스팸 방어 — vouching으로 돌아오는 인터넷

신뢰의 웹을 구축해 LLM 스팸에 맞서기 — vouching으로 돌아오는 인터넷

LLM이 코드를 생성하고, 글을 쓰고, 디자인을 하는 시대. "이게 정말 사람인지, AI인지" 구분하는 것 자체가 일상이 됐다. 특히 오픈소스 커뮤니티에서는 이 문제가 더 날카롭다. 누구나 LLM 기반 도구로 코드 제출이 가능해졌다. 겉보기에는 정상이지만 미묘하게 잘못된 제출물이 늘고 있다. 유지보수자의 부담이 급증하고 있다.

이 문제를 풀기 위해 등장한 방법이 바로 신뢰의 웹(Trust Web) 구축이다. 사용자를 서로 보증하거나 비난하는 시스템을 통해 스팸이 아닌 신뢰할 만한 기여자를 가려내자는 아이디어다. 2026년 현재 어떤 실험들이 진행 중인지, 어떤 기술적·사회적 과제가 남았는지 정리한다.

LLM 스팸이 전통적 방어를 무력화하는 이유

오래된 스팸 방어 방식은 정형화돼 있다. 발신자 평판, 키워드 필터링, 사용자 신고. 규칙을 만들면 공격자가 규칙을 우회하는 게임이었다.

생성형 AI가 이 공식을 완전히 깨뜨렸다:

• 양산형 스팸 → 수천 개,어기와 구조가 제각각인 똑똑한 스팸을 자동 생성

• 피싱 공격 → 개인화 데이터를 조합해 진짜처럼 보이는우건을 제작

• 컨텐츠 스팸 → 검색 엔진 최적화용 AI blog나 문서를 대량 생성

단순 패턴 매칭 기반의 구방어는 이미 한계에 도달했다. Google은 2026년 현재 패턴 매칭에서 문맥적 추론(_contextual reasoning_)으로 방어 패러다임을 완전히 전환했다. Gmail, YouTube, Android 전체에 reasoning AI를 배포해 실제 의도(intent)를 파악하고, 외부 도구로 사실관계를 실시간 검증하는 구조다.

Tangled: 보증·비난 시스템의 실험

대표적 실험 사례는 Tangled다. 오픈소스 프로젝트 기반의 소셜 플랫폼으로, 사용자가 다른 사용자를 보증(vouch)하거나 비난(blame)할 수 있는 기능을 기본 제공한다.

핵심 동작 방식

보증·비난은 단순한 좋아요나 싫음이 아니다. 텍스트 기반 사유가 반드시 포함된다. 시스템에는 감쇠(attenuation)가 적용된다:

• 사용자는 본인과 본인의 서클(서로 보증한 사용자 그룹)이 내린 판단만 볼 수 있다.

• 서클 밖의 보증·비난은 보이지 않는다.지라나이 사용자를 향한 대량 비난도 노출되지 않는다.

• 보증은 시간이 지나면 자동으로 약해진다. 주기에 따른 갱신이 필요하다.

보증된 사용자는 프로필 사진 옆에 초록색 방패 아이콘이 표시된다. 비난된 사용자는 빨간색 방패 아이콘이 표시된다. 이를 통해 프로젝트 유지보수자는 "이 도구를 오용해 부담을 만드는 기여자"를 가려낼 수 있다.

실제 적용 시나리오

Alice → Bob을 보증 (사유: "Bob의 PR #42는 꼼꼼한 테스트 포함, 고품질")Bob → Carol을 비난 (사유: "같은 버그를 3번이나 반복 제출")Dave(서클 밖 사용자) → Alice의 보증만 확인 가능→ Bob의 Carol 비난은 보이지 않음

설계상 주목할 점

첫째, PDS 기반 공개 기록이다. 보증·비난은 사용자 PDS에 공개 기록으로 저장된다. 탈중앙적 신뢰 배머니을 구축할 수 있다.

둘째, 증거 추적 기능(예정)이다. PR을 병합한 직후 사용자를 보증하면 해당 PR이 보증 증거로 자동 추가된다.

셋째, 사적 가시성이다. 본인의 서클 안에서만 판단이 공유된다. 대규모 집단 비난 시빌 공격을 방지한다.

웹 오브 트러스트의 계푸

신뢰 네트워크라는 개념은 새롭지 않다. 역사는 깊다:

• Slashdot 3중 메타 조정 (2000년대) — 메타 모더레이션의 효시

• Lobste.rs 트리 초대 모델 (2010년대~) — 트리 구조로 하위 트리 전체 컷 가능

• human.json (2020년대) — 신뢰 사이트 간 최단 경로 + 거리 시각화

• Tangled (2026년~) — PDS 기반 보증·비난, 서클 가시성

특히 human.json 접근이 주목할 만하다. 신뢰하는 사이트와의 최단 경로를 찾아서 거리를 색으로 표시한다. 봇 계정끼리 서로 보증하는 시빌 공격에도, 네트워크 외부에서는 영향이 제한적이다.

과제: 기술이 해결할 수 없는 것

신뢰 메트릭 연구자들 사이에서도 의견이 분분하다.

"기술보다 강한 정책이 먼저"파

LLM 사용 자체를 금지하는 정책을 먼저 세우고, 그 정책을 위반했을 때 비난 기능을 쓰자는 주장이다. 실제로 GitHub 등에서는 LLM 사용을 장려하는 분위기가 강해 더 어렵다는 목소리도 있다.

"평판 농사(bot farm)" 우회 가능성

도메인을 여러 개 만들고 각각 백만 개의 임의 계정을 생성해 서로 보증하게 하면, 분리하기 어려운 평판 묶음을살 수 있지는 않겠냐는 지적이다. 현재 설계상 대량 비난은 서클 밖으로 전파되지 않지만, 평론 구매 시빌 공격 가능성은 완전히 배제되지 않았다.

"조정 시스템의 조정" 문제

Lobste.rs 사용자들 사이에서는 오히려 초대 트리 모델이 더 낫다는 반응이 있다. 누군가 남용을 시작하면 하위 트리 전체를 한번에 컷할 수 있어서 관리하기 쉽다는 것이다.

Google의 2026년 방어 전략

구글은 2026년 현재 LLM 스팸 방어를 위해 두 축으로 나뉜다.

첫째, 온디바이스 AI(Gemma 4)다. 기기 내에서 직접 스팸 screening을 한다. 클라우드에 데이터 전송이 불필요하다. 개인정보 보호와저지연을 동시에 달성한다.

둘째, Reasoning Agent + External Tools다. Gmail 수신자의 "이 링크 안전한가?"라는 질문에 AI가 실시간으로 검색·지도 도구를 활용해 사실관계를 검증한다. 복잡한 피싱우건도 추론 체인으로 돌파한다.

Gmail, YouTube, Android 전체에 이 방어 스택을 통합함으로써 수십억 명 규모의 보안 기준선을 한 번에 끌어올리고 있다.

전망: 어떻게 흘러갈 것인가

LLM 스팸 문제는 "기술로 완벽히 해결" 대상이 아니다. 공격 비용과 복잡성을 극적으로 높이는 것이 현실적 목표다.

앞으로 볼 수 있는 진화 방향은 여러 가지다:

• 보증 점수화 — "5명의 경로가 다른 사용자가 보증"과 "100명이 모두 같은 조상을 공유"를 차등 평가

• Petname 스타일 UI — "X, Y, Z가 보증함"을 인라인 또는 마우스오버로 표시

• 정책 연계 강화 — 반 LLM 정책, 괴롭힘 금지 정책 등 각 대회근거양화 정책과 연결

---

요약

키워드	내용
문제	LLM 도구로 코드 제출 장벽 하락 → "불쾌한 골짜기"식 스팸 증가
Tangled 해법	PDS 기반 보증·비난, 서클 가시성, 감쇠 메커니즘
Google 해법	Gemma 4 온디바이스 Screening + Reasoning Agent로 사실 검증
남은 과제	시빌 공격 방어, 평론 구매, 정책 연계

신뢰의 웹 구축은 기술적 실험이자 사회적 실험이다. 첫 번째 대규모 남용 사례가 터질 때까지는 진짜 효과를 알 수 없지만, 공격자를 맞서 싸우는 가장 진지한 시도의 하나임에는 분명하다.

---

tags: LLM, 스팸방어, 신뢰의웹, vouching, Tangled, 웹오브트러스트, AI보안, 핫토픽

---

📚 출처

• 신뢰의 웹을 구축해 LLM 스팸에 맞서기: https://news.hada.io/topic?id=29121