LLM의 냄새: AI 글쓰기의 특징과 AI 코드에서의 더 큰 비용

Shrijal Shrestha가 작성한 "다양한 LLM 냄새(various llm smells)"

디자인적 특징(design tells) 또한 다른 매체에서 나타나는 동일한 이야기입니다. 마케팅 페이지에 쓰인 JetBrains Mono 폰트, 동일한 스타일로 꾸며진 리스트의 모든 단계, 균일한 카드 컴포넌트, 똑같은 버튼 처리, 그리고 이제 모든 AI 기반 랜딩 페이지(AI-scaffolded landing page)가 기본적으로 탑재하고 있는 깜빡이는 작은 점 형태의 "라이브(live)" 배지 같은 것들 말입니다. Shrestha는 자신이 이러한 도구들을 사용하는 것에 반대하는 것이 아니라고 조심스럽게 밝히고 있으며, 저 또한 마찬가지입니다. 핵심은 순수성이 아니라 인지(recognition)입니다.

이것이 취향의 문제를 넘어 중요한 이유는 다음과 같습니다. 저는 실제 환경에서 이러한 특징들이 어떤 결과를 초래하는지 지켜봐 왔습니다. 커뮤니티는 이를 식별해냅니다. 중재자(moderators)와 자동 필터는 이러한 특유의 리듬(cadence)을 저품질 스팸(low-effort spam)으로 취급하며, 때로는 그것이 정확할 때도 있습니다. 독자들은 이를 알아차리는 순간 콘텐츠의 가치를 깎아내립니다. 이것이 바로 제가 작성한 모든 초안을 Reddit이나 다른 곳에 올리기 전에 반드시 휴머나이저(humanizer)를 거치게 하는 이유입니다. 그 "냄새"는 하나의 신호이며, 사람들이 읽는 그 신호는 "아무도 이것에 실제로 신경 쓰지 않았다"는 뜻입니다. 이미 생성된 텍스트로 넘쳐나는 피드 속에서, 그 신호는 운이 좋으면 무시당하는 정도에 그치지만, 최악의 경우 삭제될 수도 있습니다.

코드에서의 동일한 냄새, 그 비용이 발생하는 지점

산문의 냄새는 짜증을 유발하지만, 코드의 냄새는 비용(bill)을 발생시킵니다. 그리고 AI가 생성한 코드는 충분히 검토하다 보면 그 자체로 식별 가능한 잔여물(residue)을 남깁니다.

패턴은 빠르게 학습됩니다. 발생할 수 없는 조건에 대한 불필요한 방어적 체크(defensive checks), 할당만 되고 절대 읽히지 않는 데드 변수(dead variable), 모델이 코드베이스의 나머지 부분을 볼 수 없었고 볼 이유도 없었기 때문에 이미 세 파일 앞에서 구현된 무언가를 다시 구현하는 함수, 바로 아래 줄의 내용을 영어로 다시 설명하는 주석 같은 것들 말입니다. 또한, 제시된 문제 그대로를 해결하는 솔루션이 문제인데, 왜냐하면 명시된 문제는 대개 실제 문제와 약간 다르기 때문입니다. 모델은 당신의 테이블에 5천만 개의 행이 있다는 사실이나, 엔드포인트(endpoint)에 초당 만 번의 요청이 몰린다는 사실을 알지 못합니다. 모델은 시스템이 아니라 프롬프트(prompt)에 답할 뿐입니다.

산문(prose)과의 차이점은 여기서 비용은 느껴지는 것이 아니라 측정된다는 점입니다. Veracode는 2025년 생성형 AI 코드 보안 보고서(genai code security report)에서 100개 이상의 모델을 대상으로 80개의 큐레이션된 작업(curated tasks)을 실행했으며, 생성된 코드의 45%가 보안 결함(security flaw)을 유발한다는 사실을 발견했습니다. 이는 동일한 유형의 테스트에서 인간의 기준치인 25-30%에 비해 높은 수치입니다. 언어와 카테고리에 따라 상황은 더 악화됩니다. Java로 생성된 코드는 70% 이상의 확률로 보안 검사를 통과하지 못했습니다. 교차 사이트 스크립팅(Cross-site scripting)은 86%의 실패율을 기록했고, 로그 주입(log injection)은 88%였습니다. 이것들은 생소한 버그가 아닙니다. 지난 15년 동안 모든 체크리스트에 포함되어 온 지루한 CWE 항목들이며, 모델은 완전히 자신감 넘치는 어조로 이를 배포합니다.

더 조용한 비용도 존재합니다. AI가 생성한 풀 리퀘스트(pull requests, PR)에 관한 2026년 연구에 따르면, 인간의 PR에 비해 측정 가능한 수준으로 더 많은 코드가 생성되고 측정 가능한 수준으로 코드 재사용은 더 적은 것으로 나타났습니다. 이는 겉보기에는 괜찮아 보이기 때문에 조용히 다가오는 기술 부채(technical debt)입니다. 코드는 그럴듯하게 읽히고, 훑어보는 단계는 통과하며, 이미 가지고 있는 로직을 조용히 중복합니다. 세 번째 복사본이 동기화에서 벗어날 때까지 당신은 이를 알아차리지 못합니다.

왜 더 많은 AI로 AI의 냄새를 맡아 확인할 수 없는가

당연한 조치는 두 번째 모델을 첫 번째 모델의 출력물에 겨냥하여 리뷰(review)라고 부르는 것입니다. 이것은 절반만 작동하며 함정을 숨깁니다. 생성기(generator)와 리뷰어(reviewer)가 동일한 결과물(artifact)을 바탕으로 추론할 때, 이들은 상관관계가 있는 방식으로 함께 실패합니다. 리뷰어는 당신이 실제로 의도한 바가 아니라, 코드 그 자체를 기준으로 코드를 검사합니다. 또한 모델들은 아첨하는 경향(sycophantic)이 있어, 리뷰어 모델은 반박하기보다는 자신감 있는 오답에 동조하는 경우가 많습니다. 결국 두 AI가 서로 고개를 끄덕이는 동안 CWE-89 SQL 주입(SQL injection)은 그대로 통과되어 버립니다.

따라서 리뷰는 모델이 작성하지 않은 무언가에 기반을 두어야 합니다. 이는 몇 가지 번거로운 습관들을 의미합니다. 코드를 수락하기 전에 의도(intent)를 실행 가능한 명세(executable spec)나 테스트로 작성하여, 대조할 수 있는 외부적인 기준을 만드세요. 단순히 구문(syntax)뿐만 아니라 아키텍처(architecture)와 재사용성(reuse)을 검토하십시오. 구문은 모델이 정확히 맞히는 부분인 반면, 구조(structure)는 모델이 틀리는 부분이기 때문입니다. 그리고 일반적인 코드에 실행하는 것과 동일한 보안 도구(security tooling)를 실행하십시오. "AI가 작성했다"는 것은 깨끗하다는 증명이 아니라, 오히려 그 반대입니다.

Shrestha의 글에서 관통하는 핵심은 두 세계 모두에 적용됩니다. '냄새(smell)'는 그 작업물이 생성되었을 뿐, 아직 소유되지 않았음을 알려주는 신호입니다. 산문(prose)에서는 자신의 목소리로 직접 다시 작성함으로써 이를 해결합니다. 코드에서는 자신의 의도(intent)에 비추어 실제로 리뷰함으로써 이를 해결합니다. 도구는 괜찮습니다. 잔여물(residue)은 당신이 여전히 책임져야 할 부분입니다.

코드 측면의 구체적인 버전, 즉 테스트 패턴, 리뷰 체크리스트, 그리고 AI의 출력을 신뢰하는 대신 명세(spec)에 고정하는 방법이 궁금하시다면, claude code testing cookbook에 정리해 두었습니다. 만약 이러한 분석(teardowns)이 마음에 드신다면, tools.thesoundmethod.me에서 더 많은 글을 작성하고 있습니다.

출처

• shrijal shrestha, "various llm smells": https://shvbsle.in/various-llm-smells/
• veracode 2025 genai code security report (AI 생성 코드의 45%가 보안 결함을 포함하고 있었음; java >70%): https://www.veracode.com/blog/genai-code-security-report/
• "more code, less reuse: investigating code quality and reviewer sentiment towards ai-generated pull requests" (arxiv 2601.21276): https://arxiv.org/pdf/2601.21276