메시지 1건을 보냈습니다. 배포 로그에도 'SENT'로 기록되었습니다.
그런데도 MCP에서 가져온 사용 건수는 '0'이었습니다.
blastengine 공식 MCP 서버를 통해 본인에게 메시지를 1건 보내어, 배포 로그와 Gmail까지 대조했습니다. 사용 현황의 updated_time을 확인한 결과, 23:52에 전송된 것보다 오래된 23:47:30 값이었습니다. 만약 AI가 '사용량이 0이므로 미전송'이라고 판단한다면 불필요한 재전송을 시도할 수 있습니다.
본 글에서는 전송 도구의 반환 값으로부터 배포 ID를 추적하고, 전송 결과와 사용량 집계를 분리하여 확인하는 절차를 남깁니다. 기록은 2026년 11월 4일자 1건에 대한 것입니다. Gmail에서는 수신된 본문을 스팸 메일함에서 확인할 수 있었습니다.
| 확인처 | 이번에 확인한 결과 | 이를 통해 알 수 있는 점 |
|---|
| MCP 전송 도구 | delivery_id: 1 | 추적할 배포 ID를 확보했습니다 |
| blastengine 배포 로그 | 배포 성공, 응답 코드 250 | 배포 로그상에서 성공으로 기록되었습니다 |
| Gmail | 스팸 메일함 내 본문 확인 | 이번 1건은 도착했지만, 받은 편지함에는 들어오지 않았습니다 |
2026년 11월 4일 23:52 JST 검증 내용입니다. 제목, 상태, 응답 코드 부분만 잘라냈습니다.
같은 제목의 메일을 Gmail에서 열어본 결과, '이전에 스팸으로 판단된 메일과 유사'라는 메시지가 표시되었으며, 지정한 본문을 확인할 수 있었습니다. 개인 주소 부분은 촬영 범위에서 제외했습니다.
이는 1건에 대한 동작 확인입니다. 도달률 비교나 스팸 판정 원인 특정을 위한 실험이 아닙니다. 이번에는 제 Gmail 주소를 발신처로 사용했기 때문에, 자체 도메인의 인증을 갖춘 운영 환경과는 조건이 다릅니다.
공식 매뉴얼에서 소개된 공개 리포지토리를 사용했습니다. 검증한 것은 blastengine-mcp-server 0.2.2 버전이며, 커밋은 46961dc304824b60311484c6b84bde9f5967796d입니다. 공식 리포지토리
이번에는 Claude Desktop에 상시 설치하는 대신, 작은 Node.js MCP 클라이언트를 사용하여 로컬의 stdio 서버에 연결했습니다. AI 에이전트에 의한 검증 작업이며, Claude Desktop 채팅 화면에서 시도한 예시는 아닙니다.
처음에는 다음 설정으로 구동했습니다.
{
"BLASTENGINE_ENABLE_SEND": "false",
"BLASTENGINE_ENABLE_BULK": "false",
...
}
로그인 ID와 API 키는 별도의 환경 변수로 전달합니다. 키를 기사, 소스 코드, 스크린샷에 넣지 않도록 합니다.
이 상태에서 tools/list를 통해 15개의 도구를 가져왔고, 다음 두 가지를 호출했습니다.
| 도구 | 확인할 내용 | 전송 전 결과 |
|---|
blastengine_usage_latest_get | 사용 건수・잔량・갱신 시각 | 사용량 0, 잔여 10,000 |
blastengine_mail_results_list | 대상 기간의 배포 로그 | data: [] |
전송을 비활성화한 구동 상태에서도 tools/list에는 blastengine_send_transaction이 포함되어 있었습니다. 도구가 보인다고 해서 전송 가능하다고 판단해서는 안 됩니다.
이 버전의 소스 코드에서는 전송 작업을 할 때 BLASTENGINE_ENABLE_SEND를 확인하는 구현이 되어 있습니다. 11월 4일 실제 전송 검증 시에는, 전송 비활성화 상태의 전송 도구 자체는 호출하지 않았습니다. 그래서 11월 7일에 다음 격리 테스트를 추가했습니다.
공식 MCP 서버 0.2.2를 stdio로 구동하고, 전송・일괄 배포・CSV 가져오기를 모두 false로 설정했습니다. 연결 대상의 BLASTENGINE_BASE_URL은 제 PC의 HTTP 서버였고, 인증 정보는 더미였습니다. blastengine 실 API로 전송 요청을 보낸 실험이 아닙니다.
| 작업 | 실제 결과 | 로컬 HTTP 서버가 받은 요청 |
|---|
tools/list | 전송 도구가 목록에 포함됨 | 0 |
blastengine_send_transaction | isError: true, code: send_disabled | |
| 0 |
blastengine_usage_latest_get | 모의 사용 현황을 가져옴 | GET /usages/latest가 1건 |
전송 도구에는 구문상 올바른 예시용 주소, 제목, 본문을 전달했습니다. 응답은 다음과 같습니다.
{"code":"send_disabled","message":"BLASTENGINE_ENABLE_SEND=true is required to send transaction mail","retryable":false}
SDK 클라이언트 측에서 isError 코드를 검사하고, 전송 호출 직후 HTTP 요청 수가 0이라는 점도 단언했습니다. 그 후에 참조계(reference type) GET이 1건 도착했기 때문에, 단순히 연결 불가능했다는 결과와 구분할 수 있습니다. 참조계의 응답 값은 자체 제작 모크(mock)의 고정값이므로, 실제 계정 이용 상황으로는 취급하지 않습니다.
이번 테스트를 통해 알게 된 것은, 해당 버전의 전송 비활성화 설정이 도구를 숨기는 방식이 아니라 실행 시점에 거부한다는 것입니다. MCP 서버가 인간의 승인 여부를 자동으로 판단한 것이 아닙니다. 전송을 활성화하는 과정에서는 수신자나 본문의 승인이 별도로 필요합니다.
실제 전송에서는 사람이 수신자, 제목, 본문, 그리고 1통이라는 상한선을 승인했습니다. AI 에이전트는 연결 설정 준비, 로컬 MCP 클라이언트 실행, 배포 ID를 사용한 로그 대조를 담당했습니다. 스팸 메일 내의 수신 결과와 이용 현황의 기준 시점도 확인하고 있습니다. 이번 재시행에서는 AI가 더미 상위 데이터를 준비하여 거부 응답과 요청 수를 대조했습니다.
실제 전송을 다시 수행하지 않고, 미확인되었던 거부 동작을 보완할 수 있었습니다. 실제 서비스로의 배포 확인과 로컬에서의 안전장치 검사는 서로 다른 증거로 남겨두었습니다.
관리 화면의 시작 가이드에는 트라이얼(trial) 배포 가능 주소를 등록하는 안내가 있었습니다. 이번 화면에서는 최대 5건까지 등록할 수 있다고 설명되어 있었습니다.
그래서 제가 관리하는 수신자만 등록하고, 이번 전송 조건을 고정했습니다.
수신자: 제가 관리하는 검증용 메일 주소 1건
제목: 【Adcore 검증】blastengine 수신 확인
본문: Qiita 기사 동작 확인용 메일입니다. 회신은 필요 없습니다.
...
수신자가 허가 목록에 있다는 것과, 이번 본문을 보내도 좋다는 것은 별개의 확인 사항입니다. 이번에는 수신자, 제목, 본문, 건수에 대해 인간의 승인을 받은 후에 실행했습니다.
1통 전송 시에만 다른 로컬 프로세스에서 BLASTENGINE_ENABLE_SEND=true로 설정했습니다. 일괄 배포(bulk sending)나 CSV 가져오기는 false 상태를 유지했습니다. 실행한 도구와 인자 형태는 다음과 같습니다. 주소는 예시로 대체했습니다.
{
"name": "blastengine_send_transaction",
"arguments": {
...
돌아온 값은 다음과 같았습니다.
여기서 '수신자가 읽을 수 있다'라고까지는 말할 수 없습니다. 다음으로 이 ID의 결과를 조사합니다. 전송용 프로세스는 종료되었고, 확인은 다시 전송 비활성화된 프로세스로 진행했습니다.
blastengine_mail_results_list에는 상대적인 '오늘'이 아니라 시간 차이를 포함한 시작/종료 시점을 전달했습니다.
{
"name": "blastengine_mail_results_list",
"arguments": {
...
결과 중 이번에 대조한 항목은 다음과 같습니다. 수신자 등을 제외한 발췌입니다.
{
"delivery_id": 1,
"maillog_id": 1,
...
관리 화면의 '배포 성공', '250'과 대응했습니다. 반면, Gmail에서는 같은 제목과 본문을 스팸 메일함에서 확인하고 있습니다. 배포 로그의 성공을 수신함에 배치되는 보장으로 해석해서는 안 된다는 것을 화면을 나란히 놓고 보면 잘 알 수 있습니다.
참고로, Gmail 표시만으로는 SPF, DKIM, DMARC 중 어느 것이 판정 원인이었는지 특정할 수 없습니다. 인증 결과 헤더 대조나, 인증된 자체 도메인과의 비교는 다음 검증 사항입니다.
또 하나 궁금한 점이 있습니다. 전송 후에 얻은 이용 현황에는 아직 다음 값이 반환되었습니다.
{
"month": 202611,
"current": 0,
...
이번 전송은 23:52였습니다. 이용 현황 업데이트 시점은 그보다 이전이었습니다. 배포 로그에 1건이 있는데 이용 현황이 0이라고 해서, '전송되지 않았으니 재전송'이라고 판단하는 것은 위험합니다.
이 관측만으로는 업데이트 간격의 사양까지 단정할 수는 없습니다. 다만, AI에게 잔량을 요약하게 한다면 '남은 10,000통'뿐만 아니라, 몇 시점의 정보인지도 돌려받았으면 좋겠다고 생각했습니다.
이번 결과를 사람이 판단할 수 있는 보고서로 만들려면 다음과 같이 작성할 수 있습니다. 이것은 MCP의 원본 응답(raw response)이 아니라, 위에서 관찰한 내용을 재구성한 예시입니다.
대상：이번에 승인된 1건, delivery_id=1
배포 로그：SENT / SMTP응답250, maillog_id=1
수신 확인：Gmail의 스팸함 내에서 동일 제목・본문을 확인
...
구현한다면, "전송 요청", "배포 로그 획득", "사람에 의한 수신 확인"을 별도의 상태로 유지합니다. 사용량 값만 보고 전송 처리로 돌아가는 분기는 만들지 않습니다. 타임아웃 등으로 전송 결과가 불분명한 경우에도, 이번 기록만으로는 재전송의 안전성을 보장할 수 없으므로, 결과 불명으로 하여 확인 단계로 넘깁니다.
이번 수확은 MCP로 이메일을 보낼 수 있었다는 점 외에도, 배포 결과와 사용 상황의 최신도가 분리되어 있었다는 것입니다. AI에게 운영을 돕게 할 때는 값과 함께 "무엇을, 언제 확인했는지"를 반환할 필요가 있었습니다.
blastengine MCP 설정 매뉴얼 / 검증한 공식 리포지토리
집필 및 검증 보조에 AI를 사용했습니다. 실행 경로는 로컬의 MCP 클라이언트이며, Claude Desktop의 조작 기록이 아닙니다.
