운영 · 모니터링
발송 요청은 발송 큐(아직 끝나지 않은 발송)를 거쳐 처리되고, 처리가 끝나면 전송 시도 로그로 남습니다. 대시보드의 모니터링 그룹(발송 큐 · 전송 시도 · 감사 로그)과 개요 화면에서 이 흐름 전체를 추적할 수 있으며, 조회자를 포함한 모든 역할이 볼 수 있습니다. 메트릭을 API로 조회하려면 모니터링·로그 API를 참고하세요.
발송 큐
모니터링 › 발송 큐는 아직 끝나지 않은 발송(예약 · 대기 · 처리 · 재시도)을 보여줍니다. 처리가 끝난 건은 전송 시도 로그로 넘어갑니다.
| 상태 | 라벨 | 의미 |
|---|---|---|
scheduled | 예약됨 | 예약 시각까지 대기 중 |
queued | 대기중 | 큐에 적재되어 처리 순서를 기다리는 중 |
processing | 처리중 | 워커가 발송을 진행 중 |
retrying | 재시도 대기 | 실패 후 다음 재시도를 기다리는 중 |
dead_letter | 실패(DLQ) | 재시도까지 모두 소진되어 최종 실패 |
화면 상단 배너에는 현재 워크스페이스의 발송 속도 제한(N 건/초 또는 무제한), 처리 대기 건수, 예상 소진 시간이 표시됩니다. 검색어(수신자 · 요청 ID · 템플릿 · 공급자), 채널, 상태로 필터링할 수 있고 필터는 URL에 유지되어 링크로 공유할 수 있습니다.
각 잡에는 시도 횟수, 다음 재시도 시각, 마지막 오류 코드가 함께 표시됩니다.
예약 취소는 scheduled 상태의 잡에서만 가능합니다.
취소하면 되돌릴 수 없습니다.
전송 시도 조회
모니터링 › 전송 시도는 공급자에 대한 발송 시도(attempt) 단위의 완료 기록입니다. 하나의 요청이 폴백을 거치면 공급자별로 여러 시도가 남을 수 있습니다.
- 목록에는 시각, 공급자, 상태(
success/failure), 요청 ID, 실패 사유(코드 + 메시지)가 표시됩니다. - 상태 · 채널 · 공급자 · 검색어 필터는 URL에 유지됩니다.
예를 들어
?status=failure로 실패 건만 모아 보는 링크를 공유할 수 있습니다. - 요청 ID로 조회하면 특정 발송 요청의 모든 시도를 추적할 수 있습니다.
행을 클릭하면 상세 화면에서 다음을 확인할 수 있습니다.
- 시도 ID, 공급자, 시작/종료 시각, HTTP 응답 코드, 지연 시간(ms)
- 발송 요청 정보: 템플릿, 수신자, 변수, 렌더링된 최종 본문(실제로 발송된 제목 · 텍스트 · HTML)
- 공급자 원문 응답(body/headers JSON) — 실패 건은 기본으로 펼쳐져 있어 원인 파악에 바로 쓸 수 있습니다
감사 로그
모니터링 › 감사 로그는 워크스페이스에서 일어난 변경 이력을 기록합니다. 누가(수행자), 언제, 무엇을(대상), 어떻게(변경 내용) 바꿨는지 남습니다.
기록되는 액션의 예는 다음과 같습니다.
| 분류 | 액션 |
|---|---|
| 워크스페이스 | workspace.updated |
| 공급자 | provider.create / provider.test_send |
| 라우팅 | route.replace |
| API 키 | api_key.create / rotate / revoke / suspend / resume / update |
| 템플릿 | template.create / template.version.create / template.version.publish |
| 웹훅 | webhook.create / update / rotate_secret / delete |
| 제한 정책 | rate_limit.workspace.upsert / rate_limit.api_key.upsert |
| SES 온보딩 | ses.domain.connect / ses.domain.adopt / ses.email_identity.verify / ses.callback_secret.rotate / ses.callback_secret.finalize |
수행자가 없는 항목(actorUserId가 null)은 시스템이 수행한 작업입니다.
화면에서는 검색어, 액션, 대상 타입, 수행자로 필터링할 수 있습니다.
데이터 보존
발송 이력과 로그는 무기한 쌓이지 않고, 보존 기간이 지나면 백그라운드 작업이 주기적으로 완전히 삭제합니다. 따라서 앞의 모니터링 화면에서도 보존 기간이 지난 기록은 조회되지 않으며, 삭제된 데이터는 복구할 수 없습니다.
| 대상 | 기본 보존 기간 | 기준 시각 |
|---|---|---|
| 발송 요청 이력 (수신자 · 본문 포함) | 180일 | 요청 접수 시각 |
| 전송 시도 로그 | 90일 | 시도 시각 |
| 전송 상태 변경 로그 | 90일 | 기록 시각 |
| OTP 인증 기록 | 180일 | 생성 시각 |
| 이메일 트래킹 이벤트 (열람 · 클릭) | 180일 | 발생 시각 |
| 감사 로그 | 365일 | 기록 시각 |
- 발송 요청이 삭제되면 그 요청에 딸린 발송 잡 · 전송 시도 · 상태 로그 · 트래킹 이벤트도 함께 삭제됩니다.
- 수신거부한 뉴스레터 구독자는 수신거부 시각으로부터 30일이 지나면 구독자 명단에서 완전히 삭제됩니다. 수신거부 이력 확인이나 재동의 처리가 필요하면 이 유예 기간 안에 해야 합니다.
- 위 값은 기본값이며, 실제 보존 기간은 운영 설정에 따라 달라질 수 있습니다.
더 오래 보관해야 하는 발송 이력은 보존 기간이 지나기 전에 모니터링·로그 API로 조회해 별도 저장소에 내려받아 두세요.
요청 제한과 발송 속도 제한
두 기능은 서로 다른 개념입니다. 요청 제한은 Posmit으로 “들어오는” API 호출 횟수를 제한하고, 발송 속도 제한은 Posmit이 공급자로 “내보내는” 발송 처리량(TPS)을 제한합니다. 혼동하지 않도록 주의하세요.
두 정책 모두 저장 · 수정은 오너 또는 관리자만 가능합니다.
요청 제한 (Rate Limit — 들어오는 API 호출)
조직 설정 › 요청 제한에서 워크스페이스 기본 정책을 설정합니다.
- 시간 창(1~3,600초)당 최대 요청 수를 지정합니다.
- 워크스페이스 정책은 모든 API 키 사용량 합산에 항상 적용되는 상한입니다. 각 API 키 상세 › 요청 제한 탭에서 키 전용 정책을 두면 해당 키의 기본 키 한도(600회/60초) 가 그 정책으로 대체됩니다. 두 한도(워크스페이스 + 키)는 매 요청 모두 검사됩니다.
한도 초과 시의 응답과 클라이언트 재시도 방법은 요청 한도를 참고하세요.
발송 속도 제한 (Dispatch Limit — 나가는 발송 TPS)
큐에서 공급자로 나가는 발송 처리량을 초당 건수(TPS)로 제어합니다. 발송 큐가 소진되는 속도가 이 값에 맞춰집니다.
| 스코프 | 대상 | 설정 위치 |
|---|---|---|
workspace | 워크스페이스 전체 기본값 | 조직 설정 › 발송 속도 제한 |
provider | 특정 공급자 계정 | 채널 › 공급자 상세 |
apiKey | 특정 API 키 | API 키 상세 › 요청 제한 탭 |
여러 스코프의 제한이 동시에 활성화되어 있으면 실효값은 그중 최솟값(가장 엄격한 값)입니다. 활성 제한이 하나도 없으면 무제한으로 동작하고, 공급자·API 키 오버라이드를 삭제하면 워크스페이스 기본값으로 복귀합니다.
발송 속도 제한의 동작 원리와 관리 API는 라우팅과 폴백 › 디스패치 TPS 제한을 참고하세요.