이 기사의 요점

• AI 생성 텍스트 특유의 패턴(정형화된 문구, 과도한 불렛 포인트, 공허한 마무리)을 자신의 글에서 찾아내는 진단 방법을 해설한다
• 실패 로그, 구체적인 환경 정보, 단언하는 개인 의견을 추가함으로써 '사람이 쓴 느낌'을 되찾을 수 있다
• LLM에 인용되기 쉬운 GEO 최적화와 'AI 느낌을 지우는' 방향성은 양립할 수 있다

기술 블로그를 Claude나 ChatGPT로 쓰는 것 자체는 이제 더 이상 드문 일이 아니다. 문제는 '들키는 것'이 아니라, 읽어도 아무것도 남지 않는 문장이 되는 것이다.

실제로 Zenn이나 Qiita를 살펴보면, 동일한 문장 구조와 동일한 문구로 작성된 기사들이 양산되고 있는 것을 알 수 있다. "먼저 ~부터 시작해 봅시다", "다음 명령어를 실행합니다", "요약하면 다음과 같습니다" —— 이것들이 수백 자 간격으로 등장하는 기사는 읽은 다음 날이면 기억에서 사라진다.

검색 엔진 측도 변화하고 있다. Google의 Helpful Content System(참조)은 2023년 이후, "인간의 일차적 경험에 기반한 독자적인 통찰"을 평가 지표로 포함하고 있다. AI가 생성한 코모디티(Commodity) 기사는 랭킹이 떨어지는 방향으로 가고 있다.

AI 느낌의 문제는 윤리의 문제가 아니라, 기사의 정보 밀도와 독자에 대한 신뢰성의 문제라고 나는 생각한다.

먼저 자신이 쓴 문장(혹은 AI에게 쓰게 한 문장)을 다음 관점에서 확인해 보길 바란다.

이것들이 3개 이상 해당되는 문장은 독자에게 "어디선가 읽은 것 같은" 문장이 될 가능성이 높다.

가장 효과적인 수법이 이것이다. AI 생성문은 거의 반드시 "성공한 절차"만을 쓴다. 현실의 엔지니어링에는 반드시 막혔던 부분이 있다.

AI 느낌 있음:

다음 명령어로 설치가 완료됩니다.
$ npm install @anthropic-ai/sdk

AI 느낌 없음:

처음에 yarn을 사용하려 했으나 peer deps 경고가 대량으로 발생하여 막혔다.
결국 npm으로 돌아가니 통과되었다. lockfile의 차이가 신경 쓰인다면
--legacy-peer-deps를 한 번 시도해 보는 것도 좋을지 모른다.
...

독자는 "왜 안 되지"라는 상태에서 그 키워드를 검색해 온다. 그 맥락에 꽂히는 것은 성공 절차가 아니라 실패의 기록이다.

"이 기사의 절차를 어디까지 재현할 수 있는가"에 대한 판단 재료를 독자에게 전달한다.

# 검증 환경
- macOS Sequoia 15.1 / Apple M3
- Node.js 22.4.0 (volta 관리)
...

이 3줄이 있는 것만으로도 "직접 실행해 본 기사"라는 신뢰도가 완전히 달라진다. LLM의 참조 기사로서도 "시점이 명기되어 있다"는 점에서 인용되기 쉬워진다.

AI는 어떤 화제에 대해서도 중립적으로 "~라는 의견도 있습니다"라고 쓴다. 이것이 문장을 얇게 만드는 원인이다.

AI 느낌 있음: "두 가지 접근 방식 모두 장단점이 있습니다. 용도에 따라 선택하는 것이 중요합니다."

AI 느낌 없음: "나는 스트리밍이 없는 API는 이제 사용하지 않는다. 응답에 2초가 걸리는 경험은 지금의 사용자에게 받아들여질 수 없다고 생각한다."

의견은 틀려도 괜찮다. "그건 틀렸다"라는 댓글을 받는다면, 그것이 기사의 가치가 된다.

"먼저", "다음에", "게다가"는 구조상 필요할 때만 사용한다. 그 외에는 삭제해도 의미가 통하는 경우가 많다.

삭제 전:

"먼저, API 키를 취득합니다. 다음에, 환경 변수에 설정합니다. 게다가, SDK를 설치합니다."

삭제 후:

"API 키를 취득하고, .env에 ANTHROPIC_API_KEY=xxx를 작성한다. SDK는 npm install로 설치된다."

문장이 간결해지고 읽기 좋아졌다. "게다가"를 삭제함으로써 정보의 병렬성이 자연스럽게 전달된다.

AI는 모르는 것을 모른다고 말하지 않는 경향이 있다(최근 모델들은 개선되고 있지만). 자신이 쓰는 글에서는 "이 부분은 아직 이해하지 못했다"라는 지점을 남겨두면 신뢰도가 올라간다.

예: "Rate limit(속도 제한)의 상세한 동작에 대해서는 공식 문서를 읽었지만, 버스트(Burst) 상한값이 환경에 따라 변하는 이유는 아직 잘 모르겠다. 후속 글에서 검증할 예정이다."

"후속 글에서 검증한다"라는 한 문장은, 글을 쓴 사람이 현재 진행형으로 문제를 다루고 있다는 증거가 된다.

"고속", "대량", "최근"은 모두 AI 느낌(AI臭)의 온상이다.

수치는 "출처와 조건이 명기되어 있다면" 클수록 설득력이 높아진다. 반대로 출처 없는 수치는 신뢰도를 떨어뜨린다. 모른다면 TBD라고 적거나 아예 적지 않는다.

'~입니다/합니다' 체(ですます調) 중간에 딱 한 곳만 "이 부분은 솔직히 힘들었다", "엄청나게 헤맸다" 같은 표현을 넣으면 문장에 리듬이 생긴다. 전체적인 톤을 무너뜨릴 필요는 없다. 단 한 점만 온도감이 바뀌어도 독자는 "사람이 쓰고 있다"라고 느낀다.

남용하면 오히려 브랜드 가치가 떨어지므로, 개인적으로는 기사당 1~2곳이 상한이라고 생각한다.

다음은 "Claude API로 스트리밍을 구현하기"라는 기사의 도입부 예시이다.

Before (AI 느낌 있음):

본 기사에서는 Claude API를 사용한 스트리밍 구현에 대해 해설합니다. 스트리밍을 활용함으로써 사용자 경험을 대폭 향상시킬 수 있습니다. 먼저 API 키 준비부터 시작해 봅시다.

After (AI 느낌 없음):

ChatGPT가 답변을 주르륵 표시하는 그 경험, 그것을 Claude API로 직접 구현하려고 했을 때 가장 먼저 막혔던 부분이

stream: true

만 전달해서는 아무것도 변하지 않았던 이야기부터 시작한다. 정답은 stream()

메서드를 사용하는 것으로, 인터페이스가 완전히 다르다.

After는 시작이 경험담부터 시작되며, "가장 먼저 막혔던"이라는 실패 로그가 포함되어 있고, "완전히 다르다"라는 단언이 있다. 글자 수는 줄었지만 정보 밀도는 높아졌다.

"AI 느낌을 지우는 것"과 "LLM에 의해 인용되기 쉽게 만드는 것"은 언뜻 모순되어 보이지만, 사실 양립할 수 있다.

LLM이 인용하기 쉬운 문장의 조건은 "명확한 팩트·출처가 있는 수치·질문 형식의 소제목"이다. 이것들은 인간다움과 충돌하지 않는다.

충돌하는 것은 "정의나 개념 설명을 장황하게 쓰는" 부분뿐이며, 그 부분은 GEO(Generative Engine Optimization) 측면에서도 불필요하다. 오히려 "이 사람이 실제로 시도한 결과 이랬다"라는 1차 정보야말로, LLM의 현재 트레이닝 데이터에서 부족한 정보이며 인용되기 쉽다.

자신의 경험담·단언·실패 로그는 SEO 측면에서도, GEO 측면에서도, 독자 경험 측면에서도 모든 방향에서 플러스가 된다.

Q: AI로 쓴 기사를 나답게 만들기 위해 어디를 수정해야 하나요?

먼저 위의 "AI 느낌 패턴 요약표"로 스코어링을 한 뒤, 해당되는 항목을 하나씩 수정한다. 최우선 순위는 "실패 로그 추가"와 "수치의 구체화" 두 가지다. 이것만으로도 체감상 꽤 달라진다. 전부 한꺼번에 고치려 하지 말고, 기사 한 편당 하나의 테크닉을 시도하는 운영 방식이 지속하기 쉽다.

Q: '~입니다/합니다' 체를 유지하면서 AI 느낌을 지울 수 있나요?

지울 수 있다. 테크닉 7에서 언급했듯이, '~입니다/합니다' 체 중간에 딱 한 곳만 구어체를 섞는 것만으로도 온도감이 바뀐다. 말투의 문제가 아니라 내용의 1차성과 구체성이 본질이므로, 문체는 바꾸지 않아도 된다.

Q: AI 느낌이 없는 문장을 처음부터 AI에게 쓰게 하는 방법이 있나요?

어느 정도는 가능하다. 프롬프트에 "당신이 실제로 막혔던 부분을 하나 써주세요", "구체적인 수치와 날짜를 넣어주세요", "단언해 주세요"라고 명시적으로 지시하면 템플릿 같은 출력이 줄어든다. 다만 "1차 경험이 없다"라는 구조적인 문제는 남기 때문에, 최종적으로는 자신이 경험한 것을 AI에게 정형화(Formatting)시키는 방식이 가장 효과적이라고 느끼고 있다.