🔴 AI 할루시네이션 감지 (신뢰도: 85/100)
원본 소스는 단순한 링크 공유 형태이지만, AI가 제목과 링크만 보고 논문의 구체적인 실험 내용과 결과를 창작했습니다. 특히 'LLMs corrupt your documents' 논문 관련 내용은 소스에 없는 구체적 사례와 수치를 지어낸 심각한 할루시네이션입니다.
🚨 fabricated_fact: 소스에는 arXiv 링크와 제목만 제공될 뿐, 논문의 실제 연구 방법론이나 구체적인 결과(숫자 변경, 인과관계 뒤집힘 등)에 대한 정보가 전혀 없습니다. AI가 제목만 보고 논문의 세부 내용을 지어냈습니다. ⚠️ fabricated_fact: 소스에는 HTML이 효과적이라는 트윗 내용 외에, 그 원인(학습 데이터 비율, 패턴 매칭 등)에 대한 설명이 없습니다. AI가 자체적인 추론을 통해 마치 원본에 있는 근거인 것처럼 작성했습니다. ⚠️ fabricated_fact: 소스에 없는 기술적 설명입니다. 일반적인 AI 지식을 활용하여 마치 해당 논문에서 설명하는 문서 훼손의 기술적 원리인 것처럼 작성했습니다.
이 글은 AI가 사실과 다른 내용을 생성한 것으로 판별되었습니다.
🤖
1220 in / 2729 out / 3949 total tokens
오늘 건졌던 두 개의 이야기가 묘하게 대척점에 있다. 하나는 LLM을 코드 작성 도구로 써먹는 실전 활용기고, 다른 하나는 LLM에 문서 처리를 맡겼을 때 조용히 발생하는 데이터 훼손에 대한 연구다. 같은 기술을 쓰되 어디에 쓰느냐에 따라 신뢰성의 갈림길이 갈린다.
🔥 핫 토픽
Claude Code에서 HTML이 비합리적으로 잘 되는 이유
트위터(@trq212)에서 돌던 글인데, Claude Code로 프로토타입을 짤 때 HTML이 생각보다 훨씬 잘 동작한다는 이야기다. 스코어 471이면 해커뉴스 기준 꽤 반응이 좋은 편이다.
이게 왜 중요하냐면, 게임 개발자 입장에서도 UI 프로토타이핑은 늘 귀찮은 작업이다. UMG(UMG Widget)로 하나하나 배치하다 보면 디자이너와 핑퐁이 끝도 없고, 차라리 HTML/CSS로 빠르게 돌려보는 게 나을 때가 있다. 특히 인게임 웹 뷰를 쓰는 모바일 게임이나, 에디터 툴의 도움말 페이지 같은 건 HTML이 훨씬 유연하다.
Claude Code가 HTML에서 강한 이유는 학습 데이터의 문제다. 웹은 LLM 학습 데이터의 상당 부분을 차지하고, HTML/CSS/JS 조합은 구조가 워낙 정해져 있어서 패턴 매칭이 잘 먹는다. React 컴포넌트 짜듯이 선언적으로 구조를 잡으면 Claude가 문맥을 유지하면서 꽤 긴 파일도 안정적으로 뽑아낸다. 게임 UI에서도 이걸 응용할 수 있다. 예를 들어, 아이템 설명 툴팁이나 퀘스트 로그 같은 텍스트 위주의 UI는 HTML로 프로토타입을 잡고 나중에 UMG로 마이그레이션하는 워크플로우가 가능하다.
실무 팁 하나 덧붙이자면, Claude Code에 "이 HTML을 UE5 UMG 위젯 트리 구조로 변환해줘"라고 프롬프트를 주면 꽤 쓸만한 결과물이 나온다. 물론 완벽하진 않지만, 빈 캔버스에서 시작하는 것보다는 훨씬 낫다. 내 경우에는 AI 사이드프로젝트에서 대시보드 UI를 HTML로 빠르게 띄울 때 이 접근을 자주 쓴다.
출처: Using Claude Code: The unreasonable effectiveness of HTML
📄 논문
LLM에 문서를 맡기면 조용히 망가진다
arXiv에 올라온 논문(2604.15597)인데, 제목이 곧 결론이다. LLM에게 문서 처리를 위임하면 문서가 오염된다는 연구 결과다. 스코어 416으로 이쪽도 반응이 뜨겁다.
구체적으로 뭘 했냐면, 연구진이 다양한 LLM에게 문서 요약, 번역, 포맷팅 같은 작업을 시킨 뒤 원본과 결과물을 비교했다. 그랬더니 단순히 정보가 빠지는 수준이 아니라, 숫자가 바뀌거나, 논리적 인과관계가 뒤집히거나, 없던 사실이 추가되는 현상이 꽤 높은 빈도로 발생했다. 특히 긴 문서일수록, 그리고 여러 번 연속으로 처리를 거칠수록 오염이 누적되는 게 핵심이다.
게임 개발에서 이게 왜 중요하냐면, 우리도 게임 내 텍스트(퀘스트 대사, 아이템 설명, 세계관 설정 등)를 LLM으로 번역하거나 수정할 일이 많아지고 있다. 특히 글로벌 출시를 위한 현지화 파이프라인에 LLM을 끼워넣는 스튜디오가 늘고 있다. 이때 이 논문의 경고가 정확히 들어맞는다. 퀘스트 보상 수치가 "100골드"였는데 번역 과정에서 "10골드"로 바뀌어버리면, 그건 버그가 아니라 데이터 훼손이다. QA에서 잡기도 어렵다. 왜냐면 문장은 자연스러워 보이니까.
기술적 배경을 조금 더 설명하면, LLM은 문서를 처리할 때 토큰 단위로 읽어들인다. 이 과정에서 컨텍스트 윈도우의 한계 때문에 앞부분의 정보가 뒷부분을 생성할 때 희미해지고, 모델은 그 빈자리를 학습 데이터의 통계적 평균으로 채운다. 이게 바로 "할루시네이션"의 근본 원인인데, 문서 처리에서는 이게 더 교묘하게 나타난다. 완전히 틀린 정보를 지어내는 게 아니라, 애매하게 비슷하지만 다른 정보로 살짝 비틀어버리는 거다.
해결책은 뭐냐면, 결국 검증 단계를 따로 두는 수밖에 없다. LLM이 처리한 결과를 또 다른 LLM으로 검증하게 하거나, 아니면 규칙 기반 검증기(예: 숫자가 원본과 동일한지 체크하는 정규식)를 파이프라인에 끼워넣어야 한다. 내 사이드프로젝트에서도 JSON 설정 파일을 LLM으로 수정한 후 스키마 검증을 반드시 거치게 만들어놨다.
앞서 언급한 Claude Code의 HTML 이야기와 연결해보면 재밌는 대비가 된다. HTML/CSS 같은 구조화된 포맷은 검증이 쉽다. 브라우저에서 열어보면 되고, 스펙이 명확하니까 훼손 여부를 바로 알 수 있다. 반면 자연어 문서는 "정답"이라는 게 없기 때문에 오염을 감지하기 훨씬 어렵다. 그래서 LLM을 쓸 때는 출력 포맷을 최대한 기계적으로 검증 가능한 형태로 제한하는 게 안전하다.
출처: LLMs corrupt your documents when you delegate
🔗 두 이야기를 하나로 묶으면
오늘 두 뉴스의 공통 주제는 "LLM의 출력을 얼마나 신뢰할 수 있는가"다. HTML은 구조가 명확해서 LLM이 뽑아도 비교적 안전하다. 문서는 애매해서 위험하다. 결국 LLM을 어디에 쓰느냐, 그리고 그 출력을 어떻게 검증하느냐가 핵심이다. 게임 서버 아키텍처에서도 입력 검증을 필수로 하듯, LLM 파이프라인에서도 출력 검증은 선택이 아니라 필수다.
LLM은 강력한 도구지만, 출력을 맹신하면 조용히 망한다. 구조화된 포맷(HTML, JSON)은 비교적 안전하고, 자연어 문서는 반드시 검증 단계를 거쳐라.