템플릿은 유지하고 이번 메일만 바꾸기: SmartNexus 일회성 이메일 작성 흐름

같은 Listing의 안내문이라도 어떤 문의에는 가격 설명이 필요하고, 어떤 문의에는 NDA보다 먼저 간단한 답장을 보내야 합니다. 템플릿을 매번 바꾸면 다음 발송까지 달라지고, 복사해서 새 템플릿을 만들면 관리할 문서만 늘어났습니다.

SmartNexus 개발일지 ⑪ · 2026년 9월 12일 · 약 6분

기본 템플릿과 이번 메시지는 다른 데이터다

Listing에 연결된 기본 템플릿은 반복 업무의 기준입니다. 한 고객에게만 문장을 추가하려고 기본 템플릿을 수정하면 이후 다른 고객에게도 그 문장이 나갈 수 있습니다. 반대로 모든 예외마다 새 템플릿을 만들면 이름만 다른 비슷한 문서가 쌓입니다.

SmartNexus에서는 기본 템플릿을 그대로 두고, 이번 발송에서만 사용할 제목과 본문을 별도로 전달했습니다. 발송이 끝나면 override는 재사용하지 않습니다. 사용자가 명시적으로 선택한 한 번의 예외라는 사실이 흐름에 남도록 했습니다.

어떤 템플릿이 선택됐는지 먼저 보여주기

드롭다운에서 템플릿을 골랐지만 Preview에는 다른 문구가 보이면 사용자는 저장이 안 된 것인지, 발송 단계에서 바뀐 것인지 알기 어렵습니다. Email & OM 화면에 선택된 템플릿 이름과 상태를 표시하고, Preview에도 최종 제목과 본문을 그대로 보여줬습니다.

Listing 저장과 Lead 저장, 이메일 발송은 서로 다른 행동입니다. 버튼 문구를 구체적으로 바꾸고 저장 후 돌아갈 위치도 분명하게 했습니다. 특히 “Save” 하나가 설정 저장인지 고객에게 보내는 행동인지 모호하지 않게 했습니다.

Other Message는 NDA 흐름을 억지로 타지 않게

전화나 소개로 들어온 문의는 일반 Listing Lead와 목적이 다를 수 있습니다. 모든 메시지에 NDA 상태를 요구하면 간단한 안내조차 보낼 수 없습니다. Other Message는 기존 안전장치를 유지하되, 승인된 한 번의 발송에서는 NDA workflow를 우회할 수 있게 했습니다.

여기서 우회는 규칙 삭제가 아닙니다. 발송 대상, Listing 연결, 선택 템플릿과 최종 본문을 Preview에서 확인하고 사용자가 실행한 한 건에만 적용했습니다. 기본 정책은 그대로 남기고 예외의 범위만 좁혔습니다.

DB 변경보다 기존 흐름을 활용하는 편이 안전했다

처음에는 일회성 본문을 위한 새 컬럼을 생각할 수 있지만, 영구 설정이 아닌 값을 DB 스키마에 넣으면 의미가 흐려집니다. 현재 요청의 모델과 발송 서비스에 값을 전달하는 방식으로 정리해 불필요한 migration 의존성을 제거했습니다.

발송 기록에는 최종 사용된 제목과 템플릿 출처를 남겼습니다. 나중에 “무슨 내용이 나갔나”를 확인할 때 현재 템플릿만 보면 과거 발송을 재현할 수 없기 때문입니다. 템플릿은 바뀔 수 있지만 발송 당시의 내용은 감사 가능한 기록이어야 합니다.

편집 자유보다 실수 방지 장치가 먼저였다

Rich Text Editor에서 자유롭게 고칠 수 있게 하되 수신자, 제목과 링크가 비어 있으면 발송하지 않았습니다. HTML은 허용 범위를 정하고, 변수 치환 결과까지 Preview에서 확인했습니다. 편집기가 유연해질수록 마지막 확인 화면은 더 구체적이어야 했습니다.

모바일에서는 긴 본문을 전부 편집하기보다 선택된 템플릿과 핵심 문구를 확인하는 데 집중했습니다. 복잡한 수정은 PC에서, 현장에서는 수신자와 최종 내용 확인 후 실행하는 기존 원칙을 유지했습니다.

변수 치환에서 값이 없는 항목도 그대로 보내지 않았습니다. 고객 이름이나 Listing 이름이 비어 있으면 중괄호 형태의 변수가 메일에 남을 수 있으므로 Preview에서 경고하고 발송 전 수정하게 했습니다. 자동 작성은 시간을 줄여주지만 완성되지 않은 문장을 자동으로 보내는 장치가 되어서는 안 됩니다.

템플릿 선택을 바꾼 뒤 브라우저의 뒤로 가기나 새로고침을 했을 때도 현재 발송 대상이 바뀌지 않는지 확인했습니다. 편집 상태와 CRM 연결 상태를 분리해, 글을 고치는 과정에서 다른 Client나 Listing으로 잘못 전송되는 위험을 줄였습니다.

변수 누락은 발송 직전에 드러나야 했다

템플릿에는 고객 이름, Listing 이름과 연락처처럼 발송 시점에 채워지는 값이 있습니다. 일회성 편집 중 변수 이름을 잘못 지우거나 일부만 남기면 자연스러운 문장처럼 보여도 실제 메일에는 빈칸이 생길 수 있습니다. Preview에서는 원본 템플릿이 아니라 변수 치환을 마친 최종 HTML을 표시하고, 필수 값이 없으면 어떤 항목을 먼저 보완해야 하는지 알려줬습니다.

링크도 같은 방식으로 확인했습니다. 화면에 보이는 문구가 맞더라도 href가 이전 Listing을 가리키면 더 큰 실수가 됩니다. 발송 전 수신자, 제목, 본문뿐 아니라 주요 버튼과 문서 링크의 대상까지 한 묶음으로 검토했습니다. 수정 가능한 범위와 자동 생성되는 범위를 시각적으로 구분해 사용자가 건드리지 않아도 되는 부분을 줄였습니다.

취소와 뒤로 가기도 발송 흐름의 일부다

Preview에서 잘못된 내용을 발견했을 때 수정 화면으로 돌아가도 작성한 문장이 사라지지 않아야 합니다. 반대로 발송을 끝낸 뒤 브라우저의 뒤로 가기로 같은 요청을 다시 실행해서는 안 됩니다. 편집 상태는 현재 작업 동안 보존하고, 성공한 발송에는 고유 기록과 중복 실행 방지를 적용했습니다.

테스트는 기본 템플릿 그대로 보내는 경우, 제목만 바꾸는 경우, 본문과 링크를 함께 바꾸는 경우로 나눴습니다. 여기에 필수 변수가 없는 경우와 발송 직전 Client가 변경된 경우를 추가했습니다. 예외 기능은 정상 사용보다 경계 상황을 먼저 확인해야 기본 템플릿의 신뢰를 지킬 수 있었습니다.

실무 체크리스트

FAQ

기본 템플릿을 수정하는 것과 무엇이 다른가요?

기본 템플릿은 이후 발송의 기준을 바꾸지만, override는 현재 한 건에만 적용됩니다.

일회성 본문도 DB에 별도 컬럼으로 저장해야 하나요?

영구 설정이 아니라면 요청 데이터로 전달하고 최종 발송 기록에 결과를 남기는 편이 구조를 단순하게 유지합니다.

NDA 절차를 건너뛰면 위험하지 않나요?

예외 대상과 목적을 제한하고 Preview와 명시적 실행을 거치면 됩니다. 기본 NDA 정책 자체를 끄는 방식은 피해야 합니다.

템플릿이 나중에 바뀌면 과거 메일도 달라지나요?

아닙니다. 발송 당시 최종 제목과 본문을 별도 기록하면 과거 내용을 그대로 확인할 수 있습니다.

공식 자료

• Google for Developers: Gmail 메시지 발송
• Microsoft Learn: ASP.NET Core 요청 위조 방지
• OWASP: Input Validation Cheat Sheet

관련 글

• 이메일 Lead 판별 규칙
• 이메일을 To-do로 바꾼 과정
• Google Contacts 동기화와 배포 알림