AI 티 안 나는 글은 문체가 아니라 소재 관리에서 나온다

문제: 문체를 아무리 다듬어도 AI 티가 남는 이유

AI로 글을 자동 생성하면 가장 먼저 손대게 되는 것이 문체다. 어미를 바꾸고, 접속사를 줄이고, '~합니다'를 '~한다'로 통일한다. 그런데 이렇게 표면을 다듬어도 여러 글을 나란히 놓고 보면 여전히 인공적인 느낌이 남는다. 원인은 문장이 아니라 소재에 있다.
일반 AI 주제 생성에 의존하면 글은 '한국 주식 자동화의 5가지 장점' 같은 어디서 본 듯한 일반론으로 수렴한다. 실제로 어느 레포에서, 어떤 기록을 근거로 나온 이야기인지 추적할 수 있는 출처가 없다. 사람이 쓴 글과 갈리는 지점은 바로 이 검증 가능한 구체성인데, 주제부터 추상적이면 문체를 어떻게 손봐도 채울 재료가 없다.
실제 개발 파이프라인(EP.19)에서 내린 결론도 같았다. AI 티를 줄이는 핵심은 문체 교정이 아니라, 실제 경험을 작은 단위의 영속 소재로 관리하고 한 번만 소비하게 만드는 소재 관리 구조였다.

---

왜 위험한가: 재사용과 중복이 쌓이면 콘텐츠가 얇아진다

소재를 관리하지 않으면 두 가지 문제가 동시에 터진다. 첫째, 같은 경험을 여러 번 다른 제목으로 재활용하게 된다. 수동 확인만으로는 무엇을 이미 썼는지 매번 정확히 대조하기 어렵고, 이미 다룬 소재인지 판단이 사람의 즉흥적 기억에 의존하게 되면 중복 관리가 불안정해진다. 둘째, 주제가 마르면 자동 생성이 일반론으로 도피한다.
이 두 문제가 쌓이면 블로그 전체가 '얇고 겹치는 글 더미'가 되기 쉽다. 개별 글 하나가 문제가 아니라 같은 근거를 두 번 소비한 흔적이 사이트 전체에 남는다는 점이 핵심이다. 중복이 늘수록 사이트 단위로 관리가 어려워지고, 새 소재로 채워야 할 자리를 이미 쓴 이야기의 변주가 차지한다.
따라서 방어선은 글을 쓰는 순간이 아니라 그 앞 단계, 즉 '무엇을 소재로 삼을지 고르는 큐'에 세워야 한다.

---

해결 구조: 실제 기록을 영속 소재로 만드는 큐

EP.19에서 구축한 방식은 일반 AI 주제 생성을 버리고, 각 레포지토리의 실제 개발 기록(DEVLOG 항목과 커밋)을 소재의 원천으로 삼는 것이다. 핵심은 각 기록을 지워지지 않는 단위로 저장하는 데 있다.
DEVLOG 항목과 커밋마다 다음 네 가지를 영구 저장한다.

• source_id — 이 소재를 유일하게 식별하는 영구 ID
• 출처 — 어느 레포·어느 기록에서 나왔는지
• 카테고리 — 글을 발행할 분류(예: 한국주식 자동화)
• 원문 — 각색 전 실제 개발 기록 텍스트

이렇게 저장해두면 '이미 쓴 소재인지'를 제목이 아니라 source_id 단위로 판별할 수 있다. 제목만 바꾼 재활용은 같은 source_id를 다시 꺼내는 순간 걸린다. 또한 원문을 함께 보관하기 때문에, 글을 생성할 때 지어낸 일반론이 아니라 저장된 실제 개발 기록 자체를 재료로 넘길 수 있다.

---

중복과 과잉 생산을 막는 세 가지 제한

큐만 만든다고 중복이 사라지지 않는다. EP.19에서는 세 가지 제한을 함께 걸었다.

1. 사용한 기록과 중복 제목의 재등록 차단 — 한 번 소비한 source_id는 다시 큐에 올라오지 않고, 같은 제목의 재등록도 막는다.
2. 하루 최대 한 편 제한 — 생성과 임시저장을 하루 한 편으로 묶었다. 하루에 여러 편을 쏟아내면 결국 소재를 얕게 소비하게 되기 때문이다.
3. 사용 횟수 적은 소재 우선 + 카테고리 순환 — 레포별로 사용 횟수가 적은 소재부터 고르고, 카테고리도 돌아가며 선택한다. 한 주제에 편중되는 것을 구조적으로 막는다.

여기에 더해 텔레그램 알림에 카테고리와 출처를 함께 포함했다. 어떤 분류의 어떤 출처가 소비됐는지가 알림에 그대로 드러난다.

---

적용 전과 후 비교

항목	소재 관리 전	소재 관리 후
소재 원천	일반 AI 주제 생성	레포의 실제 개발 기록(DEVLOG·커밋)
중복 판별 기준	제목·기억에 의존한 수동 확인	영구 source_id와 중복 제목 재등록 차단
생산량 관리	편수 상한 없음	하루 최대 한 편
소재 선택	정책 없이 선택	사용 횟수 적은 소재 우선 + 카테고리 순환
글의 재료	추상적 일반론	저장된 원문 기록을 재료로 사용

표에서 '소재 관리 전' 항목은 소재 큐가 없을 때 흔히 나타나는 상태를 일반적 예시로 정리한 것이다. 가장 큰 차이는 '겹치는가'를 판단하는 기준이 사람의 즉흥적 판단에서 source_id라는 기계적 사실로 바뀌었다는 점이다.

---

직접 적용하는 방법

같은 원리를 자신의 파이프라인에 옮기려면 다음 순서로 만든다.

1. 소재 원천을 정한다 — 개발자라면 커밋·DEVLOG, 다른 분야라면 작업 로그·회의 메모 등 '이미 일어난 일'을 원천으로 삼는다. AI에게 주제를 만들게 하지 않는다.
2. 각 소재에 영구 ID를 부여한다 — 삭제·수정에도 흔들리지 않는 source_id를 붙이고, 출처·카테고리·원문을 함께 저장한다.
3. 사용 여부 플래그를 둔다 — 소비한 소재는 사용됨으로 표시하고, 큐에서 제외한다. 같은 제목의 재등록도 막는다.
4. 하루 생산량에 상한을 건다 — 생성·임시저장 단계에서 하루 편수를 제한한다.
5. 선택 정책을 정한다 — 사용 횟수가 적은 소재를 먼저, 카테고리는 순환하도록 골라 편중을 막는다.
6. 글 생성 시 원문을 재료로 넘긴다 — 저장해둔 원문 기록을 그대로 재료로 넘겨, 없는 내용을 지어내지 않고 실제 기록에 기반해 글을 쓰게 한다.

이 중 3번과 4번을 자동 차단으로 걸어두면, 사람이 실수로 같은 소재를 다시 꺼내려 해도 시스템이 막아준다.

---

잘못했을 때 어떻게 되는가

소재 큐 없이 하루에 여러 편을 자동 생성하면, 인기 있는 소재 하나가 조금씩 표현만 바뀐 채 여러 글로 복제되기 쉽다. 처음에는 티가 안 나지만 몇 주가 지나면 사이트 전체에 '같은 이야기의 변주'가 깔릴 수 있다. 이 상태에서는 개별 글을 다듬어도 사이트 단위로 관리가 어려워질 수 있다.

반대로 source_id 기반 차단을 걸어두면, 제목만 바꾼 재작성이 등록 단계에서 걸려 애초에 발행되지 않는다. 방어선을 발행 뒤 정리가 아니라 소재 선택 앞단에 두는 것이 핵심 이유다.

---

한계와 주의사항

이 방식은 만능이 아니다. 몇 가지 전제와 한계가 있다.

• 원천 기록의 질에 의존한다 — DEVLOG나 커밋 자체가 부실하면, 소재를 잘 관리해도 좋은 글이 나오기 어렵다. 기록을 남기는 습관이 먼저다.
• 구체성과 오해 방지를 함께 봐야 한다 — 자동화 사례를 다룰 때 투자 정보로 오해받지 않도록, EP.19에서는 한국주식 자동화처럼 자동화 성격을 드러내는 카테고리를 구성했다. 소재가 구체적일수록 성과·수익을 단정하지 않도록 주의한다.
• 이 글의 수치는 특정 파이프라인의 설정값이다 — '하루 한 편' 같은 제한은 절대 기준이 아니라 해당 사례의 선택이다. 자신의 생산 여력과 소재 재고에 맞춰 조정해야 한다.

결론은 단순하다. AI 티는 문장 표면이 아니라 소재의 깊이와 유일성에서 갈린다. 문체를 다듬기 전에, 무엇을 재료로 쓰고 그것을 몇 번 소비할지부터 관리하라.