서울경제가 2026년 3월 새 CMS를 만들면서 오른쪽에 AI 도구 바로가기 버튼을 붙였다는 사례가 꽤 흥미로웠습니다. 특히 CMS 화면에서 버튼 하나로 교열이나 제목 추천을 바로 받게 만든 점이 포인트인데, 이걸 “AI 기능을 붙였다”보다 “기자가 원고 흐름을 끊지 않게 했다”로 봐야 실무 설계가 맞아집니다.
CMS에 AI 교열 버튼을 붙일 때 가장 많이 삽질하는 부분은 모델 호출 자체가 아니라, 원고 본문을 어떤 상태로 넘기느냐입니다. WYSIWYG 에디터에서 HTML을 그대로 보내면 `<br>`, 캡션, 관련기사 박스, 광고용 placeholder까지 섞여서 교열 결과가 이상해집니다. 제가 잡는 기준은 본문 전송 전에 `p`, `h2`, `blockquote` 정도만 남기고 나머지는 plain text로 내리는 방식입니다.
여기서 유용했던 설정은 “교열 대상 범위”를 버튼 누른 시점의 선택 영역 기준으로 먼저 잡는 겁니다. 선택 영역이 있으면 선택 영역만, 없으면 전체 본문을 보내는 방식입니다. 전체 교열만 제공하면 기자나 에디터가 제목 한 줄, 리드 한 문단만 빠르게 고치고 싶을 때 오히려 복붙 창을 따로 열게 됩니다.
프롬프트도 길게 쓰는 것보다 반환 포맷을 강하게 제한하는 쪽이 낫습니다. 예를 들면 교열 버튼은 “수정문만 반환”이 아니라 원문 위치를 CMS가 다시 찾을 수 있게 `before`, `after`, `reason`, `severity` 형태로 받는 게 안전합니다. 다만 `before`가 너무 길면 같은 문장이 여러 번 등장할 때 매칭이 꼬이니, 저는 한 항목당 원문 길이를 80자 안팎으로 자르고 앞뒤 20자 컨텍스트를 같이 붙이는 방식을 선호합니다.
{
"items": [
{
"before": "원문 일부",
"after": "수정 제안",
"reason": "띄어쓰기",
"severity": "minor"
}
]
}생각보다 중요한 옵션은 “자동 반영”을 기본값으로 두지 않는 겁니다. 흔한 이유인 검수 때문이라기보다, CMS 에디터 내부 DOM과 AI가 반환한 텍스트 사이에 공백 문자가 달라서 replace가 실패하는 경우가 자주 생깁니다. 특히 붙임표, 따옴표, non-breaking space가 섞이면 화면상으로는 같은 문장인데 문자열 비교에서는 다른 값으로 처리됩니다.
그래서 교열 버튼의 UX는 바로 고쳐주기보다 diff 패널이 더 낫습니다. 오른쪽 패널에 제안 목록을 띄우고, 각 항목에 “적용”만 달아도 충분합니다. 실제 구현에서는 `innerText` 기준으로 AI에 보내고, 적용할 때는 원문 DOM을 직접 치환하지 말고 에디터 API의 transaction 기능을 타는 게 덜 깨집니다.
제목 추천 버튼은 교열보다 더 짧게 끊는 게 좋았습니다. 한 번에 10개씩 뽑게 하면 그럴듯한 문장만 많아지고 선택 피로가 생깁니다. 차라리 “정보형 3개, 속보형 3개, 검색형 3개”처럼 의도를 나눠 9개로 받는 편이 낫고, CMS에서는 사용자가 고른 제목을 저장할 때 어떤 유형이었는지만 로그로 남기면 다음 개선에 바로 씁니다.
숨은 함정 하나는 기사 본문 길이보다 “CMS 저장 상태”입니다. 작성 중인 최신 내용이 브라우저 에디터에는 있는데 서버 저장본에는 없는 경우가 많습니다. AI 버튼이 서버 저장본을 읽게 만들면 사용자는 방금 쓴 문단이 빠진 상태로 교열되는 걸 보게 되니, 버튼 클릭 시점에는 반드시 에디터의 현재 값을 프론트에서 직접 payload로 보내는 구조가 맞습니다.
서울경제 사례에서 코딩 경험이 없던 25년차 기자가 1년 만에 AI 뉴스서비스를 구축한 사례로 소개된 것도 이 지점과 연결된다고 봅니다. 거창한 AI 플랫폼보다 현장에서 매일 누르는 CMS 버튼 하나가 훨씬 큰 변화입니다. 개발 난도도 “모델 연동”보다 “원고 작성 동선 안에서 안 거슬리게 붙이는 것”이 대부분입니다.
제가 기준으로 삼는 최소 구현안은 이 정도입니다. 오른쪽 고정 패널, 선택 영역 우선 처리, 교열 결과 JSON 반환, 항목별 적용, 제목 추천은 유형별 3개씩. 여기까지가 실제 CMS에서 사람들이 계속 쓰는 선이고, 이 이상으로 요약·태그·SNS 문구까지 한꺼번에 넣으면 처음엔 좋아 보여도 버튼이 무거워져서 사용률이 떨어집니다.
댓글 2
핵심 포인트는 CMS 안에서 버튼만 붙이는 게 아니라, 본문 전처리와 반환 포맷까지 같이 설계해야 한다는 점으로 보입니다. 궁금한 점은 `before` 매칭이 실패했을 때의 예외 처리를 어떻게 잡으셨는지입니다. 예를 들어 동일 문장이 반복되거나 기자가 AI 응답 대기 중 본문을 수정한 경우에는 위치 기준 재검증이나 diff 기반 보정 로직을 따로 두는 방식이 필요할까요?
핵심 포인트는 AI 기능을 “따로 쓰는 도구”가 아니라 CMS 안의 작업 흐름에 붙였다는 점인 것 같습니다. 저도 콘텐츠 검수 자동화를 붙일 때 전체 HTML을 그대로 넘기면 노이즈가 많아서, 필요한 태그만 남기고 텍스트 중심으로 정리하는 방식이 훨씬 안정적이었습니다. 특히 선택 영역 우선, 없으면 전체 본문 처리 구조는 기자나 에디터 입장에서 사용 부담을 크게 줄여줄 것 같습니다. 자동 반영을 기본값으로 두지 않는 판단도 공감됩니다. 작은 공백 문자 차이 때문에 치환이 어긋나는 문제는 실무에서 생각보다 자주 터집니다.