요즘은 다들 AI를 쓰면서도, 정작 AI가 만든 티가 나는 결과물은 다들 꺼립니다.
글이든 그림이든 화면이든 마찬가지입니다. 어딘가 AI스럽다는 인상을 받는 순간 신뢰가 한 단계 내려가고, 만드는 사람도 자기 결과물에서 그 티가 나는 걸 원하지 않습니다. AI를 쓰는 것과 AI가 쓴 것처럼 보이는 것은 이제 완전히 다른 문제입니다.
저도 최근에 블로그를 손보다가 비슷한 걸 느꼈습니다. 이모지로 꾸민 소제목이나 배경에 깔린 은은한 그라디언트 블롭 같은 게 전형적인 AI 생성 티였고, 이미 몇 군데는 고쳐뒀습니다. 그 김에 인터넷에서 정리된 자료를 하나 더 보고, 이 블로그에 실제로 적용해본 것들을 남겨둡니다.
글에서 티가 나는 곳
가장 먼저 걸리는 건 문장부호입니다. 엠 대시(—)나 콜론(:)을 문장 중간에 습관적으로 끼워 넣는 건, 문법 오류 없이 부연을 넣는 가장 싼 방법이라서 생기는 습관이라고 하더라고요. 부연이 필요하면 접속사나 문장 분리로 풀면 됩니다.
항목 개수를 억지로 3개에 맞추려는 습관도 있습니다. 이유든 사례든 실제로 2개면 2개, 5개면 5개로 쓰면 되는데, 균형을 맞추려고 항목을 끼워 넣거나 자연스러운 항목을 빼는 경우가 많다고 합니다.
“요약 → 항목 나열 → 훈훈한 마무리”로 이어지는 방어적인 3단 구조도 마찬가지입니다. 다음 내용을 자연스럽게 이어 쓰면 될 걸 굳이 한 줄로 요약하고 예고하는 문장(“한 가지는 분명했습니다” 같은)도 같은 습관이고요. 그리고 도치법이나 “시작은 사소했다” 같은 과장된 도입부도 자주 나오는 패턴입니다.
화면에서 티가 나는 곳
버튼이나 소제목에 이모지를 넣는 대신 커스텀 아이콘을 쓰는 것, 배경에 은은한 방사형 블러를 깔지 않는 것도 같은 맥락입니다. 이 블로그도 테마 토글 이모지를 SVG 아이콘으로 바꾸고, 시리즈 커버의 글로우 블롭 크기와 투명도를 줄였습니다.
이미지를 생성할 때는 조명이 특히 티가 난다고 합니다. 렌즈 플레어나 네온 글로우 같은 발광 요소를 없애려면 “빛을 빼달라”고 하는 것보다, flat lighting·overcast sky lighting 같은 긍정 키워드와 bokeh·lens flare 같은 부정 키워드를 같이 넣어야 실제로 지워진다고 하더라고요. 아직 이미지를 직접 생성해서 쓰고 있진 않지만, 나중에 쓸 일이 생기면 참고하려고 적어뒀습니다.
코드에서 티가 나는 곳
코드도 예외는 아닙니다. 간단한 유틸리티 함수 하나면 끝날 로직에 인터페이스, 팩토리, DTO, 어댑터까지 끌어와서 설계하는 것도 AI 특유의 습관이라고 합니다. 실제로 필요한 만큼만 만들면 되는데, 대규모 엔터프라이즈 코드를 흉내 내다 보니 생기는 과잉입니다. 반대로 필요한 만큼만 만들고, 중복되는 로직이 보이면 그때 한 곳으로 모으는 쪽으로 정리해왔습니다.
주석도 마찬가지입니다. count++; // 카운트를 1 증가시킵니다처럼 코드를 그대로 읽으면 되는 걸 다시 한글로 옮기는 주석, 타입이 이미 명확한데도 붙이는 JSDoc·Javadoc 풀세트가 대표적입니다. 숨은 제약이나 나중에 봐도 이유를 알 수 없는 부분에만 짧게 남기는 걸로 충분합니다.
마크다운에서는 조금 다른 종류의 문제도 있습니다. 코드 블록 안에 마크다운 예시(백틱 세 개)를 또 보여줘야 할 때, 바깥 블록을 여전히 세 개의 백틱으로 열면 파싱이 중간에 끊깁니다. 바깥은 반드시 네 개 이상의 백틱으로 열어야 합니다. 지금까지 쓴 글엔 이런 중첩 사례가 없었지만, 다음에 필요할 때 쓰려고 적어둡니다.
말투에서 티가 나는 곳
소제목이나 배경만의 문제가 아닙니다. 문장을 맺고 서술하는 말투 자체에도 AI 특유의 습관이 자주 드러납니다.
가장 흔한 건 종결어미의 단조로움입니다. 문장이 수행하는 역할(단순 사실 전달, 이유 설명, 경험 서술 등)과 상관없이 모든 문장을 기계적으로 ~습니다로만 밀고 나가거나, 반대로 평서문 곳곳에 ~요를 무작위로 섞어 어색함을 주는 식입니다.
과장된 확신과 단정적인 어조도 대표적입니다. 고민이나 사유 과정 없이 “이것은 분명한 한계였습니다”, “치명적인 문제였습니다”처럼 모든 문장을 지나치게 확신에 찬 어조로 단정하다 보니, 실제로 직접 고민해본 사람 특유의 담담함이나 여운이 사라집니다.
글의 결말을 억지로 교훈이나 병렬 대비로 포장하는 습관도 있습니다. “결국 A와 B는 맞닿아 있다”거나 “한 가지 분명하게 배운 점은 ~였다”처럼 억지로 웅장하게 마무리하려는 패턴인데, 이런 틀에 갇히면 어떤 주제의 글이든 마지막에는 매번 비슷한 톤으로 수렴하기 쉽습니다.
규칙은 실제로 문제가 되고 있는지 확인하고 넣는다
여러 자료에서 확인한 AI 슬롭 요소는 이보다 훨씬 많았습니다. 그중 하나가 상투적인 표현 목록이었는데, “~의 향연”, “~의 지평을 열다”, “단순히 A가 아니라 B이다” 같은 것들이었습니다. 바로 금지 목록에 넣으려다 한 번 멈췄습니다.
실제로 글을 쓰면서 쓰고 있는 표현인지 먼저 확인하는 게 순서인 것 같아서, 최근 발행순 10편을 검색해봤습니다. 세 표현 모두 0건이었습니다. 안 쓰고 있는 표현을 규칙으로 금지하는 건 실효 없는 규칙만 늘리는 일이라, 이번엔 추가하지 않았습니다.
지금 당장 문제가 되고 있지 않다면 후순위로 미뤄도 된다고 판단했습니다. 규칙을 무작정 늘리면 이 문서를 읽고 적용하는 데 드는 토큰도 그만큼 늘어나고, 정작 자주 걸리는 다른 규칙들이 여러 항목 사이에 묻혀 소홀해지기 쉽거든요.
규칙을 늘리는 것 자체보다, 지금 실제로 문제가 되는지부터 확인하는 과정이 더 중요하다는 걸 이번에 알았습니다.
마치며
결국 완벽하게 없애는 방법은 없는 것 같습니다. 그래서 최대한 많은 사람이 읽고 피드백을 주고받는 수밖에 없다고 생각합니다.
놀랍게도 AI 스스로도 이런 습관이 잘못됐다는 걸 알고 있습니다. 다만 글을 생성하는 순간에는 그게 우선순위로 반영되지 않을 뿐입니다. 그 부분을 조금 더 섬세하게 가이드해준다면, 지금보다는 나은 결과물을 받을 수 있지 않을까 싶습니다.