린다 이메일 첨부파일 — 대용량 처리 아키텍처 분석 & 2026 최적안

0배경

슬랙 답장 기능 스레드(6/17)에서 첨부파일 관련 미해결 어젠다가 도출됨. 핵심 질문 두 가지.

• 대용량 첨부 처리 — "용량이 크면 첨부가 안 된다". 현재 한계 ~22MB. 큰 파일을 어떻게 보낼 것인가.
• 자동 다운로드 링크 — 김규동: "너무 클 때 자동으로 다운로드 링크를 제공하는 API는 없을까요?" / 조서현: browser→S3 직통 + 한 달 후 자동삭제 Lifecycle 필요, 범위가 커서 다음 어젠다로 제안.

이 문서는 그 결정을 내리기 위한 근거를 정리한다 — 우리 코드 현황, 업계 표준, 메일 서비스들의 실제 방식, S3 모범사례, 그리고 각 결정 포인트별 판단 기준.

1린다 현재 구현 (코드 전수조사)

결론: 모든 첨부가 서버(앱린다) 메모리를 경유하며, 용량 한계가 프론트·백엔드 불일치, 자동삭제(Lifecycle) 없음. presigned 직통 패턴은 녹음·CSV에만 존재.

업로드 경로 — 완전한 서버 경유

용량 제한 — 불일치 (SSOT 위반)

저장·다운로드

다운로드는 인증 라우트 GET /api/v1/emails/:id/attachments/:idx 경유. Lifecycle/TTL 없음 — 첨부가 영구 잔존(CacheControl: max-age=31536000, 1년 캐시). 단 CSV export에는 "24h presigned + lifecycle 정리 예정" 주석 존재.

이미 존재하는 직통 패턴 (재사용 가능)

• 녹음 파일: presigned PUT 직통 업로드 — s3.service.ts:816-838 getPresignedRecordingUploadUrl()
• CSV export: presigned GET — s3.service.ts:688-705

2이메일 첨부 기술 표준 — "왜 25MB인가"

한계는 임의 숫자가 아니라 base64 인코딩과 수신측 편차의 합산 결과. 이것이 임계값 결정의 1차 근거.

3메일 프로바이더 벤치마크 (2026)

거의 모든 서비스가 ~25MB에서 클라우드 스토리지 다운로드 링크로 전환하는 동일 패턴. 차이는 만료 정책.

4S3 활용 베스트프랙티스 (AWS 공식, 2026)

바이트는 클라이언트→S3 직행, 서버는 presign(작은 JSON)만. 서버 프록시는 대역폭 2배·OOM·게이트웨이 페이로드 한계(API GW 10MB)로 디폴트가 아님.

업로드 3가지 방식

// 용량을 서버가 강제하는 유일한 방법 (POST policy)
createPresignedPost(s3, {
  Bucket, Key,
  Conditions: [["content-length-range", 0, 10*1024*1024]], // 0~10MB 강제
  Fields: { "Content-Type": "application/pdf" },
  Expires: 600,
});

다운로드 제공

운영 필수 3종

• Lifecycle: AbortIncompleteMultipartUpload 7일(미완료 파트 과금 누수 차단) + Expiration N일(임시 첨부 자동삭제)
• CORS: ExposeHeaders에 ETag 필수(누락 시 multipart 완료 실패), AllowedOrigins는 명시 origin
• 보안: key는 서버 결정(테넌트 prefix 격리) · Content-Type 1차 + magic number 재검증 · GuardDuty Malware Protection for S3($0.09/GB)

5의사결정 기준 ★

각 결정 포인트 — 무엇을 정해야 하나 / 옵션 / 권장 / 근거. 린다(한국 사용자·서울 리전·B2B 이메일) 맥락 반영.

62026 최적 제안 — 린다 하이브리드 첨부 파이프라인

소형은 그대로 인라인 첨부, 임계값 초과는 browser→S3 직통 + 자동 다운로드 링크 + 30일 자동삭제. 한국 메일 서비스 모델 + AWS 모범사례 결합.

흐름

[발송 시 파일 크기 분기]
  원본 ≤ 10MB  → 인라인 첨부 (기존 경로 유지, base64 MIME)
  원본 > 10MB  → 대용량 모드
      1) FE가 BE에 presigned POST 요청 (key=서버결정: ws/{wsId}/attachments/{uuid}/{file})
      2) BE: content-length-range[0, MAX] 조건으로 presigned POST 발급
      3) 브라우저 → S3 직통 업로드 (서버 메모리 미경유)
      4) (선택) GuardDuty 스캔 통과 확인
      5) 발송: 본문에 presigned GET 다운로드 링크 삽입
              "📎 ○○.pdf (24MB) — 다운로드 (30일간 유효)"
  [S3 Lifecycle] email-attachments/ → 30일 Expiration
                 + AbortIncompleteMultipartUpload 7일

7구현 로드맵 (범위·우선순위)

8부록 — 답장 UX 피드백 (코드 현황)

스레드의 나머지 피드백도 코드 기준 현황 정리. (별도 분석 영역)