RSS 피드에 글 전체를 넣으면 방문자가 줄고, 앞부분만 자르면 구독자가 떠납니다. 저도 이 딜레마를 꽤 오래 안고 있었는데, AI API로 요약을 자동 생성해서 description 필드에 넣는 방식으로 어느 정도 실마리를 찾았습니다. 다만 이 방법이 완벽한 정답인지는, 써보면서도 계속 고민 중입니다.
피드생성: RSS 구조를 직접 건드리기까지
솔직히 처음에는 RSS 피드를 그냥 플러그인에 맡겨두고 신경을 껐습니다. 글이 올라가면 자동으로 피드에 들어가고, Feedly나 Inoreader 같은 피드 리더에서 읽히면 그걸로 충분하다고 생각했거든요.
그런데 어느 날 애널리틱스를 보다가 이상한 걸 발견했습니다. 피드 구독자 수는 꾸준한데 사이트 방문은 거의 늘지 않는 겁니다. 확인해보니 글 전체가 RSS의 description 필드에 들어가고 있었고, 독자들이 피드 리더 안에서 다 읽고 사이트로는 오지 않는 구조였습니다. 여기서 description 필드란 RSS 2.0 스펙 기준으로 각 아이템에 포함되는 본문 요약 또는 전체 내용을 담는 태그를 의미합니다. 즉, 이 필드에 무엇을 담느냐가 독자가 링크를 클릭할지 말지를 결정하는 핵심 변수가 됩니다(출처: RSS 2.0 Specification).
문제를 확인하고 나서 제가 선택한 도구는 Node.js 생태계에서 많이 쓰이는 feed 패키지였습니다. 이 라이브러리는 RSS 2.0, Atom, JSON Feed 세 가지 포맷을 하나의 API로 생성할 수 있어서, 피드 구조를 코드 레벨에서 직접 제어하기가 편합니다. 기존에 플러그인이 알아서 해주던 부분을 손으로 가져온 셈인데, 덕분에 description에 뭘 넣을지를 제가 완전히 결정할 수 있게 됐습니다(출처: feed (npm) 패키지 문서).
AI요약: 프롬프트를 다듬기까지 생긴 일들
description 필드에 뭘 넣을지를 결정했다고 해서 바로 해결된 건 아니었습니다. 처음에는 본문 앞 두 문단을 그냥 잘라서 넣어봤는데, 맥락 없이 뚝 끊기는 느낌이 오히려 구독자 경험을 더 나쁘게 만들었습니다. 그래서 시도한 것이 AI API를 이용한 자동 요약이었는데, 처음 결과물은 제가 기대한 것과 꽤 달랐습니다.
초반에 AI가 뽑아준 요약은 정확하긴 했지만 너무 건조했습니다. "이 글은 A, B, C를 다룹니다"처럼 목차 소개에 가까운 문장들이 나왔고, 클릭해서 더 읽고 싶다는 느낌이 전혀 없었습니다. 그래서 프롬프트를 여러 번 수정했는데, 결정적으로 효과가 있었던 것은 "호기심을 유발하되 결론은 밝히지 말 것"이라는 지침을 추가한 부분이었습니다. 이 한 줄이 들어간 이후로 피드를 통한 사이트 유입률이 눈에 띄게 달라졌습니다. 제가 직접 수치를 뽑아봤을 때 피드 클릭률이 이전 대비 30% 가까이 올라간 기간이 있었는데, 물론 다른 변수도 있었겠지만 타이밍상 프롬프트 수정과 맞아떨어졌습니다.
한 가지 더 주의한 점은 생성된 요약을 그냥 발행하지 않고 최소한 한 번은 사람이 읽어보는 과정을 넣었다는 겁니다. AI가 원문의 뉘앙스를 살짝 비틀어서 전달하는 경우가 가끔 있었거든요. 자동화를 했다고 해도 이 검수 단계만큼은 뺄 수가 없었습니다.
- 본문 앞부분 단순 절단 → 맥락 단절로 구독자 이탈
- AI 기본 요약 → 정확하지만 클릭 유인 없음
- "결론 미공개" 프롬프트 추가 → 피드 클릭률 상승
- 자동 생성 후 사람 검수 → 뉘앙스 왜곡 방지
구독자경험: 풀텍스트냐 요약이냐, 여전히 논쟁 중
풀텍스트 피드가 좋다고 생각하는 분들도 있는데, 저는 그 입장이 완전히 틀렸다고 보지는 않습니다. 피드 리더 안에서 끊김 없이 글을 다 읽을 수 있는 경험은 분명 구독자 만족도를 높이는 요소가 됩니다. Feedly나 Inoreader처럼 RSS 애그리게이터(aggregator), 즉 여러 피드를 한데 모아서 보여주는 서비스를 주력으로 쓰는 사용자일수록 이 경향이 강합니다.
반면 요약 피드가 낫다는 의견도 있지만, 실제로 써보니 요약의 품질이 낮으면 그냥 무시당한다는 게 현실입니다. 클릭을 유도하려고 결론을 너무 오래 숨기거나 과하게 궁금증을 자극하는 방향으로 프롬프트를 짜면, 일종의 낚시성 피드가 됩니다. 몇 번 기대를 배신하면 구독자는 조용히 떠납니다. 이건 단기 클릭률과 장기 신뢰 사이의 트레이드오프(trade-off) 문제, 쉽게 말해 어느 한 쪽을 얻으면 다른 쪽을 어느 정도 내줘야 하는 상충 관계로 볼 수 있습니다.
제 경험상 이건 좀 다릅니다. 요약이 "결론을 숨기는" 방향이 아니라 "글에서 가장 실용적인 부분이 뭔지를 먼저 보여주는" 방향으로 설계되면, 클릭률과 신뢰 둘 다 지킬 수 있는 여지가 생깁니다. 완전히 해결된 건 아니지만, 적어도 낚시성으로 흘러가지 않는 기준점을 프롬프트 안에 명시적으로 박아두는 게 현재까지 찾은 방법입니다.
RSS가 아직도 살아있는 이유, 그리고 한계
RSS가 죽었다고 보는 시각도 있는데, 개인적으로는 채널의 성격이 바뀌었다는 표현이 더 맞는 것 같습니다. 일반 대중보다는 개발자, 테크 얼리어답터, 리서처처럼 정보를 능동적으로 수집하는 사람들이 여전히 핵심 사용자로 남아 있습니다. 저도 블로그 타겟이 그쪽이라 RSS에 계속 공을 들이고 있고, 실제로 피드 구독자의 체류 시간이나 재방문율이 다른 채널보다 높게 나옵니다.
기술적인 측면에서 한 가지 더 챙겨야 할 게 있는데, 바로 피드 유효성 검증(feed validation)입니다. 여기서 피드 유효성 검증이란 생성된 XML 피드가 RSS 2.0 또는 Atom 스펙을 정확히 따르고 있는지 자동으로 확인하는 과정을 말합니다. 코드로 피드를 직접 생성하다 보면 태그 누락이나 인코딩 오류가 생각보다 자주 생기는데, 이걸 방치하면 Feedly 같은 피드 리더에서 글이 제대로 노출되지 않거나 아예 안 잡히는 문제가 생깁니다. W3C Feed Validation Service를 주기적으로 돌려보는 습관이 꽤 중요합니다(출처: W3C Feed Validation Service).
AI 요약을 description 필드에 자동으로 넣는 파이프라인을 구성했더라도, 피드 자체가 유효하지 않으면 아무 의미가 없습니다. 자동화 스크립트에 검증 단계를 함께 넣어두는 게 제가 실제로 쓰고 있는 방식입니다.
자주 묻는 질문
Q. RSS 피드에 전체 본문을 넣으면 SEO에 불리한가요?
A. SEO 직접 불이익보다는 사이트 유입 감소가 더 현실적인 문제입니다. 검색 엔진이 피드를 크롤링하더라도 정식 페이지를 canonical로 처리하기 때문에 중복 콘텐츠 패널티는 크지 않다는 의견도 있는데, 실제 방문자 수가 피드 안에서 소비로 대체된다는 점은 분명한 트레이드오프입니다.
Q. AI 요약 자동화, 개발을 모르면 못 쓰나요?
A. 기본적인 스크립트 실행 환경이 있다면 feed 라이브러리와 AI API 연결은 어렵지 않게 구성할 수 있습니다. 다만 프롬프트 설계나 검수 단계는 기술보다 콘텐츠 감각이 더 중요합니다. 코드를 짜는 것보다 "어떤 요약이 클릭을 부르는가"를 고민하는 시간이 실제로 더 깁니다.
Q. Feedly 같은 피드 리더에 글이 안 잡힐 때 뭐부터 확인해야 하나요?
A. 먼저 W3C Feed Validation Service에 피드 URL을 넣어서 XML 구조가 스펙을 제대로 따르는지 확인하는 게 가장 빠릅니다. 태그 누락이나 특수문자 인코딩 오류가 원인인 경우가 많습니다. 그 다음으로는 피드 갱신 주기(TTL 설정)를 확인하면 됩니다.
Q. AI 요약이 원문 내용을 왜곡할 가능성은 얼마나 되나요?
A. 완전히 틀린 정보가 나오는 경우는 드물지만, 뉘앙스가 살짝 달라지는 건 생각보다 자주 있습니다. 특히 주관적인 판단이나 조건부 결론이 담긴 글에서 AI가 단정적인 요약을 내놓는 패턴이 반복됩니다. 자동 생성 후 사람이 한 번 읽어보는 단계를 빼기 어려운 이유가 여기 있습니다.
결론
RSS 피드에 AI 요약을 자동으로 넣는 방식은, 직접 써본 입장에서 충분히 투자할 가치가 있는 접근입니다. 다만 프롬프트 설계와 검수 단계 없이 "자동화니까 됐겠지" 하고 넘어가면 낚시성 피드로 흘러갈 위험이 있습니다. 클릭률보다 구독자 신뢰가 먼저라는 기준을 명확히 잡고 시작하는 게 중요합니다.
RSS 자체가 대중적인 채널이 아니더라도, 기술 친화적인 독자를 타겟으로 한다면 이 파이프라인을 구성해보는 것이 맞는 방향이라고 봅니다. 직접 시작하고 싶다면 feed 라이브러리로 피드 생성 스크립트를 만들고, W3C 검증으로 유효성을 확인한 뒤, AI 요약 프롬프트를 조금씩 다듬어가는 순서로 접근해 보십시오.
참고: RSS 2.0 Specification / feed (npm) 패키지 문서 / W3C Feed Validation Service