이메일 관련 동작 변경

최근 업데이트 이후 갑자기 Discourse가 모든 이메일 앞에 “주시 중인 주제에 누군가가 답변을 남겼습니다.”라는 문구를 붙여 보내고 있습니다. 모든 사용자들이 크게 불만을 토로하고 있으며, 이메일 설정을 변경한 사람은 아무도 없습니다.

모두가 매우 성가시다고 말합니다.

도대체 무슨 일이 벌어진 건가요? 이 기능을 끄고 원래의 일반적인 동작으로 되돌리는 방법은 무엇인가요? 이 기능이 제대로 구현되지 않았다고 생각하며, 개발자는 이를 확인해 보지도 않은 것 같습니다. 주시(watching)라는 단어에 불필요하게 대문자 W를 사용한 점만 봐도 그렇습니다.

앤드류의 커뮤니티 구성원들이 느끼는 불편함의 원인은 %{header_instructions}라고 생각합니다.

이 토큰은 상당히 큰 양의 불필요한 기본 텍스트(“답장하지 마세요…”, 링크, 안내 문구 등)로 확장되며, 많은 알림 템플릿에서 이메일 본문 맨 위에 표시됩니다. 숙련된 사용자에게는 메시지의 대부분을 차지하여 도움이 되는 안내라기보다 잔소리로 느껴집니다.

현재 이를 비활성화하거나 위치를 변경할 수 있는 사이트 전체 설정은 없습니다. 이를 제거하려면 관리자가 Admin → Email → Templates에서 각 이메일 템플릿을 개별적으로 수정해야 합니다.

현재 latest-release(저는 latest-release +17을 사용 중)에서는, 이미 DB 오버라이드가 있는 템플릿의 경우 본문의 시작 부분에 %{header_instructions}가 나타나는 경우 이를 제거하는 Rails 스크립트를 통해 중앙에서 이 문제를 해결할 수 있어야 합니다. 이 부분은 EmailTemplate 모델을 사용하므로 간단합니다.

모든 기본 템플릿(기존 오버라이드가 없는 템플릿 포함)에 동일한 변경 사항을 적용하려면, 내부 조회 API를 통해 기본 템플릿 본문을 가져와 오버라이드를 생성해야 합니다. 이는 가능하지만 Discourse 내부 구조에 의존하므로, 광범위하게 권장되기 전에 유지보수자의 검토/검증이 필요합니다.

따라서 근본적인 문제는 %{header_instructions}의 내용 자체만이 아니라, 이것이 관리자 수준의 토글 없이 사실상 전역적인 불필요한 기본 텍스트로 작동하며, 이를 제거하거나 이동하려면 템플릿별 수작업이나 지원되지 않는 스크립팅이 필요하다는 점입니다.

@Ethsim2 감사합니다, 정말 좋습니다. 그런데 왜 갑자기 이런 변경이 생겼나요? 변경 로그를 읽거나 찾는 데는 전문가가 아닙니다.

@Andro 네, 아주 적절한 질문입니다.

'갑자기’라는 표현을 쓴 이유는 %{header_instructions}가 로컬에서 변경한 내용이 아니기 때문입니다. 이 변수는 Discourse가 여러 알림 이메일에 주입하는 코어 제공 블록입니다. 코어에서 이 변수의 문구나 포함 시점이 변경되면, 관리자 설정을 건드리지 않았더라도 모든 사용자가 즉시 변화를 느끼게 됩니다.

특정 커밋 참조 없이 단정적으로 말하고 싶지는 않지만, 가장 유력한 원인은 감시 중인(watched) 토픽 알림에 대해 %{header_instructions}가 확장되는 기본 텍스트에 대한 최근의 코어 변경(예: "누군가 당신이 감시 중인 토픽에 답변했습니다."라는 줄 추가) 또는 해당 블록이 이메일 본문에 포함되는 시점의 변경일 것입니다.

출처를 확인하는 방법:

  • 관리자(Admin) → 이메일(Email) → 이메일 설정(Email Settings) → 템플릿(Templates)으로 이동하여 사용자가 받는 알림 템플릿(감시 중 / 추적 중 / 답변 / 멘션)을 확인해 보세요.
  • 본문이 %{header_instructions}로 시작한다면, 이것이 새로 추가된 서두 텍스트의 출처입니다.
  • 이 변수를 제거하거나 %{message} / %{context}(또는 %{reply_instructions}) 아래로 이동하면 이전의 ‘단순한’ 동작으로 되돌아갑니다.

불행히도 현재 이 기능을 사이트 전체로 제어할 수 있는 토글은 없습니다. 코어 동작이 변경될 때 이러한 변화가 갑작스럽고 제어하기 어렵게 느껴지는 이유는, 영향을 받는 각 템플릿을 개별적으로 조정해야 하기 때문입니다.

호스티드 Discourse를 사용 중이라면, 모든 템플릿을 수정하는 대신 사용자가 실제로 받는 소수의 템플릿만 편집하는 것이 실용적인 해결책입니다.

이 미리보기는 며칠 전에 추가되었습니다.

그렇다면 템플릿에서 %{email_preview}만 제거하면 이 문제가 해결되나요?

Watching이라는 단어는 특정 Discourse 기능을 언급할 때 대문자로 쓰이는 경우가 많습니다.

흥미로운 주제가 나타나는지 항상 주의를 기울이고 있습니다. 하지만 특정 주제에 새 답변이 올라오는지는 Watching으로 확인하고 있습니다.

그리고 토픽 알림 상태 드롭다운에 표시된 대로 추적 등 설정을 합니다.

솔직히, 저는 그걸 알아채지 못했을 것 같습니다. 이해는 가지만, 어떤 면에서는 다소 비범합니다.

감사합니다. 이해가 됩니다.

따라서 이 경우 Andro가 목격한 갑작스러운 변화는 최근 추가된 %{email_preview}(PR #36657)에서 비롯된 것입니다. 이는 관리자 설정 변경 없이도 갑자기 나타난 이유를 설명해 줍니다.

관리자 관점에서 보면, 어떤 경우든 핵심적인 문제점은 유사합니다. 이메일 본문 상단에 시스템에서 주입된 콘텐츠가 포함되며, 현재 이를 비활성화하거나 위치를 변경할 수 있는 사이트 전체 토글이 없습니다. 현재 유일한 해결책은 영향을 받은 이메일 템플릿을 편집하여 %{email_preview}를 삭제하거나 이동하는 것입니다(%{header_instructions} 처리 방식과 동일합니다).

특히 호스팅 고객에게는 이것이 갑작스럽게 느껴지는 이유가 바로 여기에 있습니다. 기본값이 변경되었지만, 이를 제어할 수 있는 지원되는 전역 설정이 없기 때문입니다.

미리보기 문자열도 오버라이드할 수 있습니다. 특정 문자열이나 .preview를 검색한 후, user_notifications에서 Ctrl-F로 검색하면 해당 문자열을 찾을 수 있습니다.

커밋 메시지 내용:

HTML 이메일의 경우 이 미리보기 텍스트는 display: none으로 숨겨져 이메일 본문 내에 표시되지 않도록 합니다. 이메일의 일반 텍스트 버전의 경우, 본문 내에 표시됩니다.

이 메시지는 어떤 사용자에게 표시되고 있습니까? 그럴 일은 없어야 합니다.

제 이메일 클라이언트에서 소스를 보면 다음과 같습니다:

<div class="email-preview" style="display:none"><p>Someone sent you a PM.</p></div>

그리고 Thunderbird와 Gmail(웹) 모두에서 숨겨져 있습니다.

참고로, 제 Outlook for iOS에서는 새 미리보기 텍스트가 이렇게 표시됩니다. 단순히 받은 편지함의 스니펫이 아니라, 메시지와 연관된 첫 번째 가시적인 줄이 되며, 이것이 사용자들의 반응을 불러일으키는 부분입니다.

이것은 최근 추가된 %{email_preview}와 일치하는 것으로 보입니다. HTML 이메일용 숨겨진 프리헤더 텍스트로 의도되었을지라도, 실제로는 사용자(적어도 일부 클라이언트/전달 경로에서)에게 매우 눈에 띄게 표시되며, 이는 갑작스러운 불만의 원인을 설명합니다.

이는 아마도 의도된 것일 가능성이 높습니다. 이메일의 이유를 메시지 미리보기에 표시하기 때문이죠. 없다면 메시지 미리보기는 대체로 유용하지 않을 것이라 추측해 봅니다.

말씀이 타당하며, 일정 수준의 의미 있는 미리보기 텍스트가 일반적으로 유용하다는 데에도 동의합니다.

사용자들이 문제 삼는 부분(적어도 iOS용 Outlook 및 유사한 클라이언트에서)은 이 미리보기 텍스트가 단순한 받은 편지함 스니펫에 영향을 미치는 것을 넘어, 실제 콘텐츠 앞에 위치하며 메시지 본문 일부로 시각적으로 인식된다는 점입니다. 실제로는 도움이 되는 것보다 반복적이고 노이즈가 느껴집니다.

현재 문구에는 약간의 긴장감도 있습니다. 익명 표현(“누군가가 답장했습니다…”)은 프라이버시와 스크린샷 공유 측면에서 유용하지만, 일상적인 사용에서는 사용자가 주로 알고 싶어 하는 누가 답장했는지, 그리고 주의가 필요한지에 대한 정보를 제공하는 발신자 인식 미리보기보다 정보량이 적습니다.

따라서 미리보기 텍스트가 존재해야 하는지 여부가 아니라, 현재 다소 경직된 구현 방식이 일부 클라이언트나 전달 경로에서 읽기 경험을 저하시키고 있는지가 더 중요한 문제입니다. 클라이언트별 접근 방식이나 이를 재배치하거나 비활성화할 수 있는 지원되는 방법이 있다면, 개선된 미리보기의 장점을 유지하면서 대부분의 불만을 해결할 수 있을 것입니다.

정말 많은 도움이 됩니다. 하지만 이제 제목에 사용되던 [The Jackrail][]에 카테고리가 더 이상 표시되지 않습니다. 원래 동작 방식을 유지하고 싶습니다.

또한, header_instructions 변수에 어떤 값이 들어 있는지 어떻게 확인할 수 있을까요?