Rinda 이메일 자동화 — 6대 신규 기능 기획서

0 시스템 현황 요약

6개 기능은 모두 기존 시퀀스·답장 처리 파이프라인 위에 얹힌다. 먼저 재사용 가능한 자산을 정리한다.

▶ 한 장면으로 보는 전체 그림

"수출기업 영업 담당 김 과장이 미국 바이어 200명에게 7일 간격 8차 메일 시퀀스를 돌린다" — 이 한 가지 상황에서 6개 기능이 어떻게 김 과장 대신 일해주는지.

1 미응답 자동 후속(Nudge) 메일 신규

보낸 메일에 답장이 없으면 최근 보냈던 내용을 바탕으로 "확인되셨을까요?" 톤의 후속 메일을 자동 발송.

핵심 설계 질문 — 7일 간격 8차 시퀀스는 어떻게?

요청에서 직접 지목한 쟁점이다. 결론부터:

트리거 조건 (전부 AND)

• sequenceEnrollments.status = 'completed' — 마지막 스텝까지 발송 완료
• repliedAt IS NULL — 답장 없음 (열람 여부 무관, 답장 기준)
• completedAt < now() - interval 'N days' — 마지막 스텝 후 cool-down (기본 5 영업일)
• 리드가 bounced/unsubscribed/suppressed 아님
• nudge_count < max_nudges — 시퀀스당 상한 (기본 1회, 최대 2회)

발송 내용 생성

1. 해당 enrollment의 마지막(또는 열람률 가장 높았던) 스텝 콘텐츠를 sequenceStepContents에서 가져온다.
2. LLM(gemini-3-flash)으로 "짧은 리마인드 톤"으로 재작성 — 원문 요지 1~2줄 인용 + "확인되셨을까요?" CTA. 새 제목 대신 Re: 유지.
3. 같은 스레드로 발송 — 원본 emails.threadId · messageId를 In-Reply-To/References 헤더에 넣어 받은 편지함에서 기존 대화에 묶이게 한다 (도달율·맥락 ↑).

언어 정책 (beta DB 실측 기반)

"확인되셨을까요?" 본문은 기존 AI 생성 파이프라인(gpt-5-nano/gemini-3-flash)을 그대로 재사용해 생성한다. 문제는 어떤 언어로 보낼지다.

DB 변경

-- sequenceEnrollments 에 컬럼 추가 (또는 별도 sequence_nudges 테이블)
nudge_count        smallint   default 0
last_nudge_at      timestamptz
nudge_state        varchar(16)  -- 'eligible' | 'sent' | 'replied' | 'exhausted'

별도 테이블보다 enrollment 컬럼 추가가 단순. Nudge 발송 자체는 sequenceStepExecutions에 stepOrder = -1 같은 가상 스텝으로 기록해 발송 이력/추적을 재사용한다.

실행 (worker)

• 신규 nudge-scanner.worker.ts — 하루 1~2회 cron tick. 위 조건 만족 enrollment 스캔 → keyset cursor 배치 → Nudge 생성 → 기존 발송 큐(sequenceEmailQueue) 재사용.
• 발송 시각은 기능 4(영업일) 로직을 그대로 통과 — 영업시간 내, throttle 적용.
• Nudge 발송 후 답장 오면 webhook에서 nudge_state='replied' 처리 (기존 reply 핸들러에 분기 1줄).

난이도 M · 기존 발송/스레드/LLM 인프라 대부분 재사용. 신규는 scanner worker + enrollment 컬럼 + 설정 UI.

2 OOO 영업시간 재발송 확장

주말·영업시간 외 발송 → 자동응답(Out-of-Office) 수신 시, 동일 내용을 수신자 영업시간에 다시 보낸다.

현황과 차이

지금은 out_of_office intent를 감지하면 enrollment를 7일 pause 후 자동 resume 한다. 요청은 "7일 뒤 다음 스텝"이 아니라 "방금 그 메일을, 곧 돌아올 영업시간에 다시" 보내는 것 — 리마인드 성격이 다르다.

플로우

1. OOO 감지 — 이미 auto-reply-detection.ts가 emails.isAutoReply=true + intent out_of_office로 처리. 여기까진 재사용.
2. 확장 OOO 본문에서 복귀일 파싱. LLM 1콜로 "I'll be back on June 5" → 2026-06-05 추출. 실패 시 null.
3. 재발송 시각 계산:
   • 복귀일 있으면 → 복귀일 다음 영업일 09:00 (수신자 timezone)
   • 없으면 → 다음 영업일·영업시간 시작 슬롯 (기능 4 로직 재사용)
4. 원본 step execution을 복제해 sequenceStepExecutions에 resend 1건 생성 — 동일 콘텐츠, 같은 스레드.

무한 루프 / 이중 발송 방지

DB 변경

-- sequenceStepExecutions
resend_of_execution_id  uuid   null   -- self-ref FK, unique partial idx
trigger_reason          varchar(24)    -- 'ooo_resend' 등 발송 사유 추적

난이도 S~M · OOO 감지·발송 인프라 재사용. 신규는 복귀일 파서 + resend 스케줄 분기. 기능 4 의존(영업일 계산 공유).

3 담당자 아님 → 자동 전달 신규

"저는 담당자가 아니에요, XXX@회사.com 으로 보내세요" 답장 → 그 주소로 동일 내용 자동 전달.

현황과 갭

현재 AI 분류에 "담당자 아님" intent가 없다. 이런 답장은 objection이나 question으로 잘못 분류된다. 먼저 intent를 추가해야 한다.

구현 단계

1. 확장 AI 분류에 intent wrong_contact 추가 — 프롬프트에 정의: "recipient says they are not the right person and points to someone else". 응답에 referred_email·referred_name 필드 추출 추가.
2. 대체 주소 추출 — 답장 본문 정규식(이메일 패턴) + LLM 교차검증. 둘이 일치할 때만 신뢰.
3. 전달 실행:
   • 추출 주소를 새 leadContact로 추가
   • 원본 시퀀스 콘텐츠(현재 스텝)를 그 주소로 발송 — 새 enrollment 생성 또는 단발 전달
   • 원본 lead enrollment는 stopped (stopReason wrong_contact)

안전장치 — Auto vs Review

DB 변경

-- email_replies 에 추출 결과 저장 (intent='wrong_contact' 일 때)
referred_email   varchar(255)
referred_name    varchar(255)
forward_status   varchar(16)   -- 'pending' | 'forwarded' | 'review' | 'skipped'
-- enrollment stopReason enum 에 'wrong_contact' 추가

난이도 M · 분류 프롬프트 확장 + 주소 추출 + 전달 발송 + Review 카드 UI. 기능 6과 알림 경로 공유 가능.

4 국가별 영업일 발송 신규

시퀀스 메일을 수신자 국가의 영업일·영업시간 안에서만 발송. 벗어나면 다음 영업 슬롯으로 자동 이월.

현황과 갭

현재 timezoneMode(sender/buyer) + scheduledHour/Minute로 시각만 맞춘다. 영업 요일·공휴일 개념이 없다. 토요일 09:00, 크리스마스 09:00에도 그대로 발송된다.

설계 — Business Calendar 레이어

1. 신규 워크스페이스(또는 시퀀스)별 영업시간 설정: 영업 요일(기본 월~금), 시작·종료 시각(기본 09:00–18:00), 기준 timezone.
2. 신규 국가별 공휴일 — date-holidays 라이브러리 또는 정적 public_holidays 테이블(국가코드·날짜). 리드의 국가/timezone으로 조회.
3. 스케줄 보정 함수 nextBusinessSlot(scheduledAt, calendar): 계산된 scheduledAt이 영업시간 밖이면 → 다음 영업일·영업시간 시작으로 shift. 발송 워커의 로더가 픽업 직전 한 번 더 검증.

핵심 난제 — Throttle vs 영업시간 용량

DB 변경

-- 신규: business_hours (workspace_id 별 설정)
work_days        smallint[]    -- [1,2,3,4,5]
start_minute     smallint      -- 540 (09:00)
end_minute       smallint      -- 1080 (18:00)
calendar_tz      varchar(64)
-- 신규: public_holidays (country_code, holiday_date) 또는 date-holidays 런타임 조회

난이도 L · 6개 중 가장 무겁고 기능 1·2가 의존하는 기반. capacity 이월 로직이 핵심 리스크.

5 리드 데이터 멀티 필드 검토형 정리 확장

회사명뿐 아니라 website·country 등 여러 필드를 한 번에 정리. 단 즉시 반영이 아니라 dry-run 미리보기 → 필드/행 선택 → 확정 시에만 적용.

어떤 필드를 정리하나 (beta DB 실측 — 정리 대상 비율)

설계 — 필드별 normalizer 레지스트리 + dry-run 검토

1. 신규 normalizer 레지스트리 — 필드별 순수함수 모음(기능1에서 bun test 통과한 normalizeCompanyName 패턴 재사용). 각 함수는 (raw) → cleaned 로 부수효과 없음:
   • company_name: 법인접사 제거 (주)·㈜·Ltd·Inc·Co.·GmbH·株式会社 (word boundary로 과도제거 방지)
   • website_url: https:// 보정 + www.·끝 슬래시 제거 → canonical
   • country: 한글/약어 → 표준 영문명 매핑(미국→United States) — 언어추론·영업일(기능4) SSOT 정합
2. 확장 기존 BulkActionModal.tsx에 "normalizeFields" 액션 추가. 정리할 필드를 다중 선택(체크박스).
3. dry-run 미리보기 (DB 미변경) — 선택 필드마다 "변경 N건" 집계 + 이전→이후 샘플. 변화 없는 행/필드는 회색.
4. 사용자가 적용할 필드/행을 골라 확정할 때만 반영. 대상: 선택 리드 / 현재 필터 전체.

API — dry-run / commit 2단계

// 필드별 normalizer 레지스트리 (서버·프론트 미리보기 공유, 전부 순수함수)
const NORMALIZERS = {
  companyName: (s) => s
    .replace(/\(주\)|㈜|주식회사|유한회사|株式会社|有限会社/g, " ")
    .replace(/\b(Inc|LLC|Ltd|Co|Corp|Limited|GmbH|S\.?A|B\.?V)\b\.?/gi, " ")
    .replace(/\s{2,}/g, " ").trim(),
  websiteUrl: (s) => {
    let u = s.trim().replace(/\/+$/, "")
    if (u && !/^https?:\/\//i.test(u)) u = "https://" + u
    return u.replace(/:\/\/www\./i, "://")
  },
  country: (s) => COUNTRY_CANONICAL[s.trim()] ?? s.trim(),  // 미국→United States
}
// ❌ employee_count 등 "범위 문자열" 필드는 레지스트리에 넣지 않음 (의미 손실)

난이도 M · 회사명 단일(S)에서 멀티 필드+dry-run으로 확장. normalizer는 순수함수라 unit test로 값싸게 커버. 프론트+경량 API로 빠르게 체감되는 기능.

6 긍정·미팅 답장 알림 메일 확장

답장이 positive_interest 또는 meeting_request로 분류되면 담당 유저 이메일로 즉시 알림.

현황과 갭

이미 email-reply-notification.service.ts가 답장 알림을 보내지만 intent 필터가 없어 모든 답장에 발송된다. "긍정·미팅만"으로 좁히고 내용을 풍부하게 만드는 작업.

설계

1. AI 분류(classifyEmailReplyAsync) 완료 후, intent ∈ {positive_interest, meeting_request} AND confidence ≥ 0.7 일 때만 알림 트리거.
2. 알림 메일 내용: 회사/리드명 · intent 배지 · AI 요약(aiSummary) · 답장 원문 발췌 · "받은 편지함에서 열기" 딥링크.
3. 발송: 기존 SendGrid 발송 서비스(email.service.ts) 재사용. 수신자 = enrollment 소유 유저(user_email_accounts 또는 user 이메일).
4. 중복 방지 — 같은 thread 같은 intent는 24h 내 1회만.

알림 설정 (preferences)

// reply-automation 파이프라인 끝에 1 분기 추가
if ((intent === "positive_interest" || intent === "meeting_request")
    && confidence >= 0.7
    && !alreadyNotified(threadId, intent)) {
  await sendPositiveReplyAlert({ to: ownerEmail, lead, intent, aiSummary, snippet })
}

난이도 S · 발송·분류 인프라 완비. intent 게이트 + 메일 템플릿 + 중복 가드만. 가장 빠른 백엔드 기능.

⚠ 예외·리스크 분석 & 대처

"리스크 있는 시나리오가 모두 대처 가능한가?"에 대한 답. 각 기능의 실패 시나리오를 발생 영향·대처·테스트 가능 여부로 정리한다.

공통 리스크 4가지 (모든 기능 공유)

기능별 핵심 예외 & 대처

✓ 2026 패턴 적합성 · 테스트 검증

"2026 최적 패턴인가" + "테스트 코드로 문제없는지 보장 가능한가"에 대한 답.

2026 최적 패턴 부합 점검

테스트로 문제없는지 — 현실 평가

⚙ 설정 위치(UI 배치) · 기본값 정책

"on/off 토글을 어디에 두나, 그리고 처음 켰을 때 기본값은 무엇인가." 설정의 적용 범위(scope)로 위치를 정하고, 평판 리스크로 기본값을 정한다.

위치 결정 기준 — "이 설정은 무엇마다 달라지나?"

기본값 결정 4원칙

기능별 — 위치 × 기본값 × 핵심 파라미터

기존 워크스페이스 마이그레이션 (원칙 D 상세)

⬡ 헥사고날 설계 · 영향도 분석

코드 반영 전 단계에서 2026 헥사고날(ports & adapters)로 설계. 도메인 로직을 순수하게 격리하고 부수효과(DB·이메일·AI·시계)는 port 뒤로 — 인프라 없이 유스케이스를 테스트한다.

4계층 구조

영향도 분석 (기능별 touch points)

★ 통합 우선순위 · 로드맵

권장 진행 순서

1. Wave 1 (빠른 가치) — 기능 6 + 기능 5. 의존 없음, 며칠 내 체감. 사용자 만족·신뢰 즉시 확보.
2. Wave 2 (기반) — 기능 4 영업일 캘린더. 가장 무겁지만 기능 1·2가 이 위에 선다. capacity 이월 로직을 여기서 한 번 제대로.
3. Wave 3 (지능형 자동화) — 기능 3(전달) → 기능 2(OOO 재발송) → 기능 1(Nudge). 모두 답장 intent·영업일 기반을 재사용.