tags: [ideas, email, persistence, naverworks, storage]

# 이메일 읽기시점 전건저장 아이디어

## 배경
- 현재 로빙의 이메일 처리 경로는 메일을 먼저 조회하고, 그중 콜드메일로 판정된 메일만 후속 처리 단계에서 저장합니다.
- 이 구조에서는 "왜 이 메일이 선택됐는가", "선택되지 않은 메일과 무엇이 달랐는가", "첨부파일이 여러 개인 경우 어떤 파일이 분석 대상으로 이어졌는가"를 나중에 정확히 추적하기 어렵습니다.
- 특히 콜드메일 오분석처럼 입력 선택 경로가 문제일 때, 저장되지 않은 일반 메일과 저장된 콜드메일 사이의 차이를 같은 기준으로 비교하기 어렵습니다.

## 문제 인식
- 현재 구조는 이메일을 "업무 데이터"가 아니라 "필터를 통과한 결과물만 남기는 임시 입력"처럼 다루고 있습니다.
- 그 결과:
  - 필터 이전 상태 추적이 약합니다.
  - 이메일 처리 흐름을 재현하기 어렵습니다.
  - 첨부 선택, 본문 해석, 분류 기준을 사후 검증하기 어렵습니다.
- 이메일 관련 기능이 늘어날수록 "콜드메일만 저장" 구조는 한계가 커질 수 있습니다.

## 핵심 아이디어
- 이메일 관련 정보는 **읽는 시점(fetch 단계)** 에 먼저 저장합니다.
- 즉 "콜드메일인지 아닌지"와 무관하게, 조회된 이메일을 공통 이메일 저장소에 먼저 적재한 뒤 후속 분류와 분석은 그 저장된 데이터를 기준으로 이어갑니다.

## 이 아이디어가 뜻하는 상태

### 1. 이메일은 필터 결과가 아니라 원본 단위로 관리한다
- 콜드메일은 이메일 저장소 위에 얹히는 "분류 결과"가 됩니다.
- 분석, 분류, 첨부 선택, Slack 전송은 모두 저장된 이메일 레코드를 참조합니다.

### 2. 읽기와 해석을 분리한다
- 읽기 단계:
  - 메일 식별자
  - 제목
  - 본문
  - 발신자
  - 수신 시각
  - 첨부 메타데이터
  - 원본 제공자 정보
  를 저장합니다.
- 해석 단계:
  - 콜드메일 여부
  - 신뢰도
  - 선택된 분석 문서
  - 후속 액션 상태
  를 별도 상태로 관리합니다.

### 3. 첨부도 이메일 중심으로 연결한다
- 첨부파일은 단순히 `document_id`만 흩어지는 구조가 아니라, "어느 이메일의 어떤 첨부였는지"가 유지되어야 합니다.
- 이후 IR 분석이 특정 첨부를 선택했다면, 그 선택 결과도 이메일 레코드에 연결됩니다.

## 기대 효과

### 1. 추적성 강화
- 어떤 메일이 왜 콜드메일로 갔는지, 왜 안 갔는지 같은 비교가 쉬워집니다.
- 잘못된 첨부 선택이나 본문 파싱 문제를 원본 기준으로 다시 볼 수 있습니다.

### 2. 기능 확장 기반
- 콜드메일 외에도 일반 투자문의, 회신 필요 메일, 중요 공지 메일 같은 다른 분류 체계로 확장하기 쉬워집니다.
- 이메일은 하나의 원본 저장소가 되고, 각 기능은 그 위에서 다른 해석 레이어를 붙일 수 있습니다.

### 3. 재현성 강화
- 이후 필터 로직이 바뀌어도 과거 메일 집합을 기준으로 재분류·재평가가 가능해집니다.
- 운영 중 문제 발생 시 "현재 메일함 상태"가 아니라 "당시 읽은 레코드" 기준으로 분석할 수 있습니다.

## 아직 아이디어 단계인 이유
- 어떤 저장 범위를 기본값으로 할지 아직 고정되지 않았습니다.
  - 제목/본문만 저장할지
  - 헤더 전체를 저장할지
  - 첨부 바이너리까지 읽기 단계에서 바로 저장할지
- 저장 위치도 아직 결정되지 않았습니다.
  - rb8001 DB 단일 저장
  - skill-email 중심 저장
  - 이메일 원본과 첨부 메타를 분리 저장
- 중복 읽기, 보존 기간, 개인정보/운영 데이터 경계도 아직 정책으로 확정되지 않았습니다.

## 이 아이디어가 열어두는 질문
1. 이메일 저장의 SSOT는 `rb8001`이 맞는가, 아니면 `skill-email`이 맞는가?
2. "읽었다"의 기준은 목록 조회 시점인가, 상세 조회 시점인가?
3. 첨부는 메타데이터만 우선 저장하고 실제 파일은 필요 시 가져오는 구조가 나은가?
4. 동일 메일 재조회 시 업데이트 정책은 어떻게 가져갈 것인가?
5. 이메일 저장과 콜드메일 분류 결과를 어떤 관계로 분리할 것인가?

## 바로 실행 결정으로 넘기지 않은 이유
- 이 아이디어는 단순 컬럼 추가가 아니라 이메일 도메인의 저장 책임을 다시 정하는 문제입니다.
- 따라서 이번 단계에서는 "이메일은 읽는 시점에 먼저 저장한다"는 방향만 열어두고, 실제 스키마·책임 경계·동기화 방식은 별도 계획 문서에서 닫아야 합니다.

## 한 줄 결론
- 콜드메일만 저장하는 구조보다, 이메일을 읽는 시점에 전건 저장하고 그 위에서 분류·분석을 얹는 구조가 더 추적 가능하고 확장 가능한 방향입니다.