지식 베이스

템플릿

한 번 작성해 버전으로 관리하고 여러 번 보내는 본문. 작성 창에서, 직접 작성한 코드에서, 또는 에이전트를 통해 보냅니다.

세부 정보

템플릿은 작성한 사람이 아니라 연결에 속하며, 이것이 첫 번째 버전을 통째로 교체한 이유입니다. 그 버전은 사용자를 기준으로 키를 잡았기 때문에 팀원의 템플릿이 워크스페이스 API 키에는 보이지 않았고, 그래서 통합 프로그램은 설정한 사람이 볼 수 있는 것을 보낼 수 없었으며, 작성자의 계정을 삭제하면 워크스페이스의 템플릿까지 함께 사라졌습니다. 기존 행은 버리지 않고 그대로 옮겨 왔습니다.
본문을 작성하는 방법은 두 가지입니다. 하나는 @react-email/components의 컴포넌트(Section, Row, Column, Container, Text, Heading, Button, Link, Img, Hr, Markdown, CodeBlock, CodeInline)로 구성한 블록 트리로, 작성하는 즉시 검사하므로 잘못된 노드나 안전하지 않은 href는 깨진 메일로 도착하는 대신 그것을 작성한 호출에서 거부됩니다. 다른 하나는 직접 렌더링한 마크업입니다. 템플릿이 이미 자체 저장소의 react-email 컴포넌트라면 그곳에서 @react-email/render로 렌더링해 HTML을 전송하면 되고, 이 HTML은 버전이 게시될 때 한 번 정제됩니다.
스물세 가지 출발점과 빈 템플릿 하나가 메뉴가 아니라 갤러리로 제공됩니다. 고르기 전에 직접 봐야 하는 것들이라 카드마다 이메일 자체를 보여 줍니다. 환영과 인증, 영수증과 청구서, 배송과 갱신, 다이제스트와 공지가 네 개의 제목 아래 정리되어 있고, 각각은 비주얼 편집기에서 열려 모든 요소를 옮기고 스타일을 바꾸고 삭제할 수 있습니다. 무엇을 고르든 초안으로 도착하므로 게시하기 전에는 아무것도 보낼 수 없습니다.
갤러리는 이 기능에서 앱에만 있는 유일한 부분입니다. 직접 작성한 코드나 에이전트에서 템플릿에 접근하는 호출자는 출발점을 지정하는 대신 본문(블록 문서나 직접 만든 마크업)을 전송하므로, 스물세 가지는 설치해서 가져다 쓰는 카탈로그가 아니라 시작할 자리일 뿐입니다.
이름 있는 슬롯과 이름 있는 프롭은 두 종류의 빈칸이며, 본문과 제목에 {{key}} 형태로 씁니다. 슬롯은 템플릿을 편집하는 사람이 채우고 기본값을 가지므로 아무것도 지정하지 않은 발송도 렌더링됩니다. 프롭은 발송 시점에 제공하며, required로 표시된 프롭이 없으면 발송을 거부합니다. 422가 반환되고 메일은 나가지 않습니다. 그 거부가 바로 프롭을 선언하는 이유입니다. 그러지 않으면 주문 번호가 들어가야 할 자리가 비어 있는 메시지가 나가고, 이는 아무도 보고하지 않으며 아무도 회수할 수 없습니다.
게시된 버전은 고정됩니다. 게시된 템플릿의 본문을 수정하면 운영 중인 내용을 고쳐 쓰는 대신 새 초안이 만들어지므로, 누군가 게시하기 전까지 발송은 어제 해석하던 내용을 그대로 해석하고, 버전 번호를 고정한 발송은 게시 이후에도 영향을 받지 않습니다. 본문은 게시 시점에 컴파일되며, 그래서 렌더링되지 않는 템플릿은 수신자가 아니라 게시하는 사람에게서 실패합니다.
미리보기는 발송하지 않은 채 발송 시 생성될 결과를 그대로 렌더링하고, 아직 비어 있는 항목은 거부하는 대신 알려 줍니다. 미리보고 있는 템플릿은 대개 작성 중인 템플릿이고, 블록을 하나씩 채워 가는 작성자가 지금까지의 결과를 보려고 모든 프롭을 충족해야 할 이유는 없습니다.
모든 템플릿은 자신이 보낸 내역을 따로 보관합니다. 최근 7일, 30일, 90일 동안 몇 통이 나갔는지, 그중 무엇이 열렸고 무엇이 클릭되었는지, 일별 추이, 그리고 각 발송이 어디에서 시작되었는지(작성 창, 직접 작성한 코드, 에이전트, 큐)에 따른 구분까지 담습니다. 각 비율은 분모를 빌려 쓰지 않고 저마다의 분모를 밝히는데, 실제로 서로 다르기 때문입니다. 열람은 픽셀이 실린 메시지를 기준으로, 클릭은 재작성된 링크가 실린 메시지를 기준으로 세며, 한 메시지가 둘 중 하나만 실을 수도 있습니다. 미리보기는 아예 기록되지 않고, 테스트 발송은 따로 세어 모든 수치에서 빼는데, 실제로 나간 적이 없기 때문입니다.
그 기록은 볼 수 없는 부분에 대해 정직하며, 그래서 볼 수 있는 절반을 신뢰할 수 있습니다. 발송은 발송 자체를 통해 전달 기록과 맞춰지는데, 전달 기록은 직접 작성한 코드나 큐에서 보낸 메일에만 실립니다. 작성 창이나 에이전트, 어시스턴트가 보낸 메시지에는 실리지 않습니다. 그래서 주로 작성 창에서 쓰는 템플릿은 대부분의 발송이 맞춰지지 않은 채로 도착하며, 맞춰지지 않은 건수는 아무도 열지 않은 것으로 합산되지 않고 별도의 수치로 표시됩니다.
하나의 서비스 위에 네 개의 표면이 있어서 "게시란 무엇인가"에 대해 오늘만 일치하는 세 가지 답이 아니라 하나의 답이 존재합니다. 작성 창의 템플릿 버튼은 게시된 템플릿을 제시하고, 고른 내용을 붙여 넣는 대신 메시지를 그것으로 대체합니다. 발송은 템플릿을 지정하고, 버전은 고르는 순간에 고정되며, 본문은 작성된 곳에서 렌더링되므로 고른 뒤 보내기를 누르기 전에 게시가 일어나도 나가는 내용은 달라지지 않고, 작성 창이 담아낼 수 없었을 레이아웃도 그대로 유지됩니다. 거기서 채우는 것은 값이지 본문이 아닙니다. /templates는 templates:read와 templates:write 스코프 뒤에 있는 아홉 개의 엔드포인트이며, SDK가 메서드 단위로 그대로 감쌉니다. 템플릿으로 보내려면 템플릿 권한뿐 아니라 발송 권한도 필요하므로, 카피라이팅 도구에 발급한 키는 아무에게도 메일을 보내지 못한 채 작성과 게시만 할 수 있습니다. MCP 서버는 list, read, preview, create, send 다섯 가지 도구를 제공합니다. 기존 템플릿을 수정하거나 삭제하거나 게시하는 도구는 의도적으로 없습니다. 수정은 다음 발송이 해석하지 않을 초안을 만들고, 삭제는 되돌릴 수 없기 때문입니다. 저장된 본문을 편집하는 일은 화면의 몫입니다. /workspace/templates에는 팔레트와 인스펙터가 딸린 블록 캔버스, 그 옆의 실시간 미리보기, 그리고 서로 분리된 저장과 게시가 있으며, 그래서 게시된 버전은 다음 버전을 작업하는 동안 건드리지 않고 둘 수 있는 것이 됩니다.
연결당 템플릿 200개, 블록 문서는 블록 500개까지, 중첩은 8단계, 값 하나당 20,000자, 슬롯 100개와 프롭 100개까지이며, 마크업으로 전송한 본문은 100만 자, 제목은 998자까지입니다. 이 모두는 요금제 제한이 아니라 폭주하는 스크립트를 막기 위한 안전장치이고, 거부할 때는 어떤 수치 때문에 거부했는지 메시지에 밝히며, 템플릿과 관련된 어떤 것도 등급 뒤에 가려져 있지 않습니다.