LLM의 말투가 내 문장이 될 때, 고유한 목소리를 지키는 법

LLM과 매일 대화하면 답변 내용만 가져오는 데서 끝나지 않을 수 있어요. 자주 접한 단어와 문장 리듬이 익숙해지고, 어느 순간 자기 글에서도 같은 표현이 먼저 떠오를 수 있어요. 개발자 놀란 로슨은 Claude와 오래 일한 뒤 이런 변화를 알아차렸고, AI를 쓰는 영역과 자기 목소리를 지킬 영역을 나누기 시작했어요. 1
핵심 요약
| 구분 | 핵심 | 왜 볼 만한가요 |
| 언어 습관 | LLM을 오래 읽으면 특정 단어와 문장 리듬이 자연스럽게 머리에 남을 수 있어요 | AI의 영향이 결과물뿐 아니라 표현을 고르는 과정에도 닿을 수 있어요 |
| 사용 경계 | 저자는 코딩에는 AI를 쓰지만 개인 글에는 맞춤법 검사도 맡기지 않아요 | 모든 작업에 같은 기준을 적용하지 않는 현실적인 선택지예요 |
| 저자성 | 업무 문서에서는 AI가 만든 문장을 별도로 표시해요 | 독자가 문장의 출처를 계속 추측하는 부담을 줄일 수 있어요 |
| 실천 방법 | AI가 개입하지 않는 읽기와 쓰기 시간을 의도적으로 남겨요 | 자기 문체를 유지하려면 다른 언어적 자극도 꾸준히 필요해요 |
1. LLM의 표현이 생각보다 먼저 떠오르기 시작했어요
놀란 로슨은 최근 글을 쓰다가 `load-bearing`이라는 표현을 골랐어요. 문맥에는 잘 맞았지만, Claude가 자주 쓰는 말이라는 점이 마음에 걸렸어요. 이후 `belt-and-suspenders`, `earns its keep`처럼 에이전트 답변에서 반복해서 본 표현도 자꾸 떠올랐어요. 그는 현재 여러 에이전트가 만든 코드를 검토하는 일을 많이 해요. 그 과정에서 읽은 문장이 자신의 어휘 선택에 스며들었다고 느꼈어요. 2
사람은 책과 주변 사람에게서도 말투를 배워요. 저자는 어린 시절 스티븐 킹을 읽은 뒤 쓴 과제에서는 킹의 문체를 닮았고, 《나니아 연대기》를 읽은 뒤에는 영국식 철자와 고풍스러운 표현을 썼다고 회상해요. 성인이 된 뒤에도 최근에 읽은 작가의 단어와 리듬이 글에 남았어요. 매일 많은 양의 LLM 문장을 읽는다면 챗봇도 비슷한 언어 환경이 될 수 있다는 걱정이에요.
저자의 걱정은 특정 단어를 빌리는 데서 그치지 않아요. 익숙한 문장이 먼저 떠오르면 생각을 구성하는 방식도 그 문장에 맞춰질 수 있어요. 표현을 고르는 일과 생각을 다듬는 일은 완전히 떨어져 있지 않아요. 매끄럽고 무난한 답변을 오래 읽을수록 자기 문장의 어색함을 너무 빨리 지우게 될 수도 있어요.
AI를 모두 끊는 대신 용도별로 선을 그었어요
저자는 AI 사용을 전면 중단하지 않았어요. 코드를 짜거나 기타 연습용 앱을 만드는 데는 적극적으로 활용해요. 반면 개인 글에는 LLM을 쓰지 않고, 맞춤법 검사도 맡기지 않아요. 조금 뻣뻣하거나 낯선 표현이 남더라도 그 흔적까지 자기 글의 일부로 받아들여요. 2
작업마다 AI 허용 범위를 다르게 정할 수 있어요. 코드에서는 변수명이나 반복문 형태에 대한 개인 취향을 양보해도 생산성이 더 중요할 수 있어요. 개인 에세이에서는 효율보다 저자의 목소리가 더 중요할 수 있어요. 작업마다 지키고 싶은 가치가 다르니 허용 범위도 달라질 수 있어요.
AI가 쓴 문장은 독자가 알아볼 수 있게 표시해요
업무 글에서는 Claude가 만든 문장을 인용 블록이나 접을 수 있는 영역 안에 넣어요. 어느 부분이 저자의 문장이고 어느 부분이 AI 출력인지 독자가 바로 구분할 수 있게 하는 방식이에요. AI가 쓴 것인지 모호한 글을 읽으면 독자는 문장마다 출처를 추측하게 돼요. 표시를 분명히 하면 이런 인지 부담을 덜 수 있어요. 2
표시는 내용의 정확성을 보장하지 않아요. 그래도 누가 썼는지 숨기지 않는다는 점에서 읽는 사람에게 필요한 맥락을 줘요. 팀 문서라면 AI가 만든 요약과 사람이 확인한 결론을 분리할 수 있어요. 창작물이라면 교정에 AI를 썼는지, 문장 자체를 생성했는지 범위를 밝힐 수도 있어요.
왜 중요한가요
AI 도구를 평가할 때는 보통 속도와 결과물 품질을 먼저 봐요. 이 글은 사용자가 매일 읽는 문장의 출처도 함께 보자고 말해요. LLM이 만든 문장을 오래 접하면 특정 어휘와 전개 방식이 편해질 수 있어요. 그 변화가 싫다면 AI를 완전히 끊기보다 노출 범위를 정하고, AI 없이 읽고 쓰는 시간을 남기는 방법을 택할 수 있어요. 2
개발자와 기획자에게는 실무적인 문제이기도 해요. 보고서, 제품 문구, 회고를 모두 같은 모델로 다듬으면 팀의 문장이 빠르게 비슷해질 수 있어요. 반대로 초안을 직접 쓴 뒤 사실 확인만 도구에 맡기거나, AI가 작성한 부분을 표시하면 사람의 판단과 도구의 도움을 구분하기 쉬워요. 중요한 문서일수록 어떤 단계까지 AI에 맡길지 먼저 정해 두는 편이 좋아요.
자기 문체는 완벽하게 고정된 정체성이 아니에요. 읽은 책, 함께 일한 동료, 속한 조직의 말투가 계속 섞여요. LLM도 그 목록에 들어왔어요. 어떤 영향을 받아들일지 의식적으로 고르는 일이 이제 글쓰기 과정의 한 부분이 됐어요.
참고 자료
- 사이보그가 되지 않기 위하여: LLM의 말투가 내 생각이 되지 않게 하기 — GeekNews
- On not becoming a cyborg — Nolan Lawson, Read the Tea Leaves
'IT & AI' 카테고리의 다른 글
| AI 회의론의 예측 성적표, 확신보다 검증이 먼저예요 (0) | 2026.09.02 |
|---|---|
| 브라우저 텍스트 편집기를 직접 만들며 확인한 세 가지 선택지 (0) | 2026.09.02 |
| Uber는 PR 70% 이상을 AI로 처리하며 비용을 어떻게 줄였나 (0) | 2026.09.02 |
| AI 코딩이 빨라질수록 개발자의 반복 경험은 더 중요해져요 (0) | 2026.09.02 |
| 67센트짜리 소형 Transformer가 ARC-AGI-1에서 44%를 기록했어요 (0) | 2026.09.02 |