Inbox Lens

Inbox Lens

흘려보낸 이메일에서 나의 일과 성장을 발견하다

1. 프로젝트 개요

1.1 서비스 한 줄 정의

Inbox Lens는 직장인의 이메일을 분석하여 반복 업무, 주요 프로젝트, 업무 성과, 커뮤니케이션 패턴, 자동화 가능 영역을 찾아주는 개인 업무 분석 서비스다.

일반적인 이메일 서비스는 받은 편지함을 관리하는 데 초점이 있다.

Inbox Lens는 이메일을 다음과 같이 바라본다.

Email
  ↓
업무 데이터
  ↓
반복 패턴
  ↓
업무 인사이트
  ↓
자동화 후보
  ↓
성과 기록

핵심 목표는 사용자가

"이번 달 메일을 348통 보냈다."

가 아니라

"이번 달에는 결제 QA 업무에 가장 많은 시간을 썼고,
반복적인 테스트 결과 공유 업무를 자동화할 수 있으며,
4개의 주요 이슈 해결에 기여했다."

라고 자신의 일을 이해하게 만드는 것이다.

---

2. 핵심 사용자

Primary User

반복적인 이메일 업무가 많은 직장인.

특히 다음 직군을 우선 대상으로 한다.

• QA Engineer
• Developer
• Product Manager
• Project Manager
• 영업
• 운영
• CS
• 마케팅
• 기획

1차 MVP에서는 QA Engineer를 대표 Persona로 사용한다.

---

3. QA Persona

사용자 상황

이커머스 QA 엔지니어.

매일 다음과 같은 업무를 반복한다.

테스트 요청 수신
↓
Test Case 수행
↓
결과 메일 전달
↓
버그 발견
↓
Jira 등록
↓
개발 수정
↓
재검증
↓
결과 메일 공유

문제는 각각의 업무가 이메일과 Jira에 흩어져 있기 때문에 사용자는 자신이 한 일을 체계적으로 기억하기 어렵다는 것이다.

예:

9월 이메일 371통

↓ Inbox Lens 분석

Checkout QA            87건
Regression Test        64건
Bug Verification       42건
Jira 관련 소통         31건

자동화 후보
- QA 결과 공유 이메일
- 재검증 완료 이메일
- 테스트 요청 확인 이메일

이번 달 주요 성과
- 결제 실패 오류 발견
- 쿠폰 Regression 오류 발견
- 주문 취소 Edge Case 발견

---

4. MVP 핵심 기능

초기 버전에서는 아래 7개 기능을 구현한다.

기능 1. 이메일 Import

지원 방식:

1차 MVP

CSV Import
EML Import
Mock Email Dataset

2차

Gmail OAuth
Microsoft Outlook OAuth

처음부터 Gmail API까지 구현하지 않아도 된다.

분석 시스템을 먼저 완성하고 이후 이메일 Provider를 붙이는 구조로 설계한다.

---

5. 전체 시스템 Architecture

┌───────────────────┐
│     Frontend      │
│     Next.js       │
└─────────┬─────────┘
          │
          │ REST API
          ↓
┌───────────────────┐
│      FastAPI      │
│      Backend      │
└─────────┬─────────┘
          │
          ├───────────────┐
          ↓               ↓
┌────────────────┐   ┌─────────────────┐
│ Email Analyzer │   │   AI Analyzer   │
│ Python Logic   │   │ LLM Adapter     │
└────────┬───────┘   └────────┬────────┘
         │                     │
         └──────────┬──────────┘
                    ↓
             ┌──────────────┐
             │ PostgreSQL   │
             │ + pgvector   │
             └──────────────┘

---

6. 권장 기술 Stack

Frontend

Next.js
TypeScript
Tailwind CSS
Recharts
TanStack Query

Backend

Python
FastAPI
Pydantic
SQLAlchemy

Database

PostgreSQL
pgvector

분석

Python
pandas
numpy
scikit-learn

AI

AI Provider는 Adapter 형태로 구현한다.

LLMProvider
 ├─ OpenAIProvider
 ├─ LocalProvider
 └─ MockProvider

특정 AI 서비스에 전체 시스템이 종속되지 않도록 한다.

---

7. 프로젝트 Directory

Codex는 다음 구조를 기준으로 생성한다.

inbox-lens/

frontend/
│
├─ app/
│   ├─ dashboard/
│   ├─ emails/
│   ├─ automation/
│   ├─ achievements/
│   └─ settings/
│
├─ components/
│   ├─ charts/
│   ├─ cards/
│   └─ layout/
│
└─ lib/

backend/
│
├─ app/
│   ├─ main.py
│   │
│   ├─ api/
│   │   ├─ emails.py
│   │   ├─ analysis.py
│   │   ├─ dashboard.py
│   │   └─ reports.py
│   │
│   ├─ models/
│   │   ├─ email.py
│   │   ├─ thread.py
│   │   └─ analysis.py
│   │
│   ├─ services/
│   │   ├─ email_parser.py
│   │   ├─ classifier.py
│   │   ├─ similarity.py
│   │   ├─ automation_detector.py
│   │   ├─ achievement_detector.py
│   │   └─ report_generator.py
│   │
│   └─ ai/
│       ├─ base.py
│       ├─ prompts.py
│       └─ provider.py
│
├─ tests/
│
└─ requirements.txt

docker-compose.yml
README.md
.env.example

---

8. 핵심 Email 데이터 모델

이메일 원문과 분석 결과를 반드시 분리한다.

class Email:
    id: str

    message_id: str
    thread_id: str

    sender: str
    recipients: list[str]

    subject: str
    body: str

    sent_at: datetime

    direction: str

분석 결과:

class EmailAnalysis:
    email_id: str

    summary: str

    category: str
    project: str | None

    action: str | None
    outcome: str | None

    importance: int

    feedback_type: str | None

    automation_candidate: bool

    estimated_minutes: float

    embedding: list[float]

---

9. 이메일 Category

AI는 이메일을 아래 중 하나로 분류한다.

REQUEST
REPLY
REPORT
APPROVAL
SCHEDULE
ISSUE
RESOLUTION
COLLABORATION
FEEDBACK
INFORMATION
QA_REPORT
QA_REQUEST
BUG_REPORT
RETEST_RESULT
OTHER

QA 사용자에서는 별도의 QA Category를 둔다.

---

10. 이메일 분석 Pipeline

메일이 들어오면 다음 과정을 거친다.

Raw Email
   ↓
Normalize
   ↓
Thread Detection
   ↓
Direction Detection
   ↓
AI Classification
   ↓
Project Detection
   ↓
Action Extraction
   ↓
Outcome Extraction
   ↓
Embedding 생성
   ↓
Similarity Analysis
   ↓
Automation Score
   ↓
Achievement Detection
   ↓
Database 저장

---

11. 이메일 Normalize

메일에는 다음과 같은 불필요한 정보가 많다.

signature
quoted reply
HTML
tracking link
회사 disclaimer

분석 전에 제거한다.

핵심 구현:

import re


def clean_email_body(body: str) -> str:

    body = re.sub(r"<[^>]+>", " ", body)

    body = re.sub(
        r"On .* wrote:",
        "",
        body,
        flags=re.DOTALL
    )

    body = re.sub(
        r"From:.*",
        "",
        body,
        flags=re.DOTALL
    )

    body = re.sub(r"\s+", " ", body)

    return body.strip()

---

12. 이메일 방향 판단

사용자의 이메일 주소 목록을 입력받는다.

MY_EMAILS = {
    "me@company.com",
    "me.alias@company.com"
}

판단 로직:

def detect_direction(sender: str) -> str:

    if sender.lower() in MY_EMAILS:
        return "SENT"

    return "RECEIVED"

---

13. AI Email Classification

AI에게 이메일 전체를 그대로 던지지 않는다.

입력:

Subject
Clean Body
Direction

출력은 반드시 JSON으로 제한한다.

예:

{
  "category": "QA_REPORT",
  "project": "Checkout Renewal",
  "summary": "결제 Regression 테스트 결과 공유",
  "action": "TEST_RESULT_SHARED",
  "outcome": "BUG_FOUND",
  "importance": 4,
  "automation_candidate": true
}

---

14. AI Prompt

You are an enterprise email work analyzer.

Analyze the following business email.

Return JSON only.

Determine:

category
project
summary
action
outcome
importance
automation_candidate

CATEGORY must be one of:

REQUEST
REPLY
REPORT
APPROVAL
SCHEDULE
ISSUE
RESOLUTION
COLLABORATION
FEEDBACK
INFORMATION
QA_REPORT
QA_REQUEST
BUG_REPORT
RETEST_RESULT
OTHER

Importance:

1 = trivial
2 = low
3 = normal
4 = important
5 = critical

Do not guess project names if there is insufficient evidence.

EMAIL

Subject:
{subject}

Direction:
{direction}

Body:
{body}

---

15. 가장 중요한 기능

반복 이메일 탐지

Inbox Lens의 핵심 알고리즘이다.

예:

테스트 결과 전달드립니다.
확인 부탁드립니다.

금일 테스트 결과 전달드립니다.
확인 부탁드립니다.

Regression 테스트 결과 전달드립니다.
확인 부탁드립니다.

내용은 조금 다르지만 사실상 같은 업무다.

단순 문자열 비교로는 찾기 어렵다.

따라서 Embedding Similarity를 사용한다.

---

16. 반복 이메일 탐지 Algorithm

이메일을 Vector로 변환한다.

Email A
 ↓
Embedding
 ↓
[0.13, 0.81, 0.22 ...]

Email B
 ↓
Embedding
 ↓
[0.15, 0.78, 0.21 ...]

Cosine Similarity 계산.

from sklearn.metrics.pairwise import cosine_similarity


def calculate_similarity(vector_a, vector_b):

    score = cosine_similarity(
        [vector_a],
        [vector_b]
    )[0][0]

    return float(score)

기준:

0.90 이상
거의 같은 이메일

0.82 ~ 0.90
매우 유사

0.70 ~ 0.82
같은 업무일 가능성

0.70 미만
다른 업무

MVP 추천 Threshold:

SIMILARITY_THRESHOLD = 0.84

---

17. 반복 Email Cluster

각 이메일을 서로 비교하면 O(N²)가 된다.

이메일 수가 많아지면 비효율적이다.

따라서 다음 방식으로 처리한다.

최근 90일 이메일
↓
Category별 분리
↓
Embedding Search
↓
Similarity > 0.84
↓
Cluster 생성

예:

Cluster #23

QA 테스트 결과 공유

메일 수
21개

평균 similarity
0.91

평균 작성 예상시간
4.8분

---

18. 자동화 추천 Score

단순히 반복 횟수가 많다고 자동화해야 하는 것은 아니다.

다음 5개 값을 사용한다.

Frequency
Similarity
Predictability
Time Cost
Manual Effort

공식:

automation_score = (
    frequency_score * 0.30
    + similarity_score * 0.25
    + predictability_score * 0.20
    + time_score * 0.15
    + manual_effort_score * 0.10
)

0~100점으로 변환한다.

---

19. 구현 예시

def automation_score(
    frequency: int,
    similarity: float,
    estimated_minutes: float,
    predictability: float,
    manual_effort: float
):

    frequency_score = min(frequency / 20, 1)

    time_score = min(
        estimated_minutes / 10,
        1
    )

    score = (
        frequency_score * 0.30
        + similarity * 0.25
        + predictability * 0.20
        + time_score * 0.15
        + manual_effort * 0.10
    )

    return round(score * 100)

판단:

80점 이상
자동화 적극 추천

60~79
템플릿 추천

40~59
부분 자동화 가능

40 미만
자동화 필요 낮음

---

20. 자동화 추천 예

반복 업무 발견

QA Regression 결과 전달

최근 30일
21회

평균 작성시간
4.8분

Automation Score
87

추천

[QA 결과 공유 Template 만들기]

예상 절감 시간

월 1시간 24분

---

21. 시간 절감 계산

def calculate_saved_minutes(
    email_count: int,
    avg_minutes: float,
    automation_ratio: float
):

    return (
        email_count
        * avg_minutes
        * automation_ratio
    )

예:

21회

평균 작성시간
4.8분

자동화율
80%

21 × 4.8 × 0.8

= 약 81분

---

22. 이메일 작성 시간 추정

메일 작성 시간을 실제로 측정하기 어렵기 때문에 MVP에서는 추정한다.

기본값:

Short Email
2분

Medium Email
5분

Long Email
10분

구현:

def estimate_email_minutes(body: str):

    length = len(body)

    if length < 200:
        return 2

    if length < 700:
        return 5

    return 10

향후에는 사용자 실제 행동 데이터를 이용해 개인별 모델로 개선한다.

---

23. Thread Ping-Pong 분석

이 기능은 이메일 비효율을 발견한다.

예:

나
자료 부탁드립니다.

상대
어떤 자료인가요?

나
8월 QA 자료입니다.

상대
Web인가요 Mobile인가요?

나
둘 다입니다.

Thread Message = 5.

실제로 한 번에 끝날 수 있었던 요청이다.

---

24. Ping-Pong Score

def thread_pingpong_score(
    message_count: int,
    participant_count: int
):

    if participant_count <= 1:
        return 0

    return message_count / participant_count

추가로 AI가 원인을 분석한다.

missing_deadline

missing_platform

missing_scope

ambiguous_request

출력:

이메일 왕복 5회

가능한 원인

- 플랫폼 미기재
- 요청 범위 미기재

추천

다음 이메일에서는

기간 + 플랫폼 + 요청자료 + 기한

을 명시하세요.

---

25. 성과 Email 탐지

다음 데이터를 찾는다.

문제 발견
문제 해결
긍정 Feedback
성과
감사
승인
업무 완료

키워드 Rule + AI를 함께 사용한다.

예:

POSITIVE_KEYWORDS = [
    "감사합니다",
    "빠른 대응",
    "잘 정리",
    "덕분에",
    "해결되었습니다",
    "좋은 의견",
    "수고하셨습니다"
]

---

26. Achievement 후보

다음 조건 중 2개 이상 만족하면 성과 후보로 본다.

Positive Feedback 존재

ISSUE → RESOLUTION Thread

관련 Jira 존재

사용자 Action 존재

중요도 4 이상

---

27. 성과 카드

예:

이번 달 성과

Checkout 결제 오류 발견

관련 이메일
8건

관련 Jira
QA-3812

진행

Bug 발견
↓
Jira 등록
↓
Developer Fix
↓
Retest
↓
Close

Outcome

운영 배포 전 오류 수정

---

28. Project Detection

Subject + Body에서 프로젝트명을 추출한다.

예:

[Checkout Renewal]
[A Project]
[Search v2]

먼저 Rule을 사용한다.

PROJECT_PATTERN = r"\[(.*?)\]"

AI는 Rule로 찾지 못했을 때만 사용한다.

이렇게 하면 AI 비용을 줄일 수 있다.

---

29. Dashboard

메인 화면은 이메일 Inbox가 아니다.

Work Dashboard다.

상단:

이번 달

이메일             348
완료 업무            32
프로젝트              7
자동화 후보            4
예상 절감 시간       3.2h

---

30. 업무 분포 Chart

Donut Chart:

QA 결과 공유      26%

프로젝트 협업     22%

Bug 대응          17%

일정              12%

정보 공유         11%

기타              12%

---

31. 주요 프로젝트

Checkout Renewal

메일
82

Issue
17

Resolved
14

---

32. 자동화 Recommendation

자동화 추천 #1

Regression 결과 공유 이메일

반복
21회

예상 절감
81분 / 월

Automation Score
87

[Template 만들기]

---

33. 성장 Log

September Growth Log

9/03
Checkout 결제 오류 발견

9/08
Regression 결과 Template 제작

9/14
Coupon Edge Case 발견

9/21
QA 요청 메일 개선

---

34. API 설계

이메일 Import

POST /api/emails/import

Response:

{
  "imported": 320
}

---

분석 실행

POST /api/analysis/run

{
  "status": "completed",
  "emails_analyzed": 320
}

---

Dashboard

GET /api/dashboard

---

반복 업무

GET /api/automation/candidates

---

성과

GET /api/achievements

---

Monthly Report

GET /api/reports/monthly?month=2026-09

---

35. Dashboard Response 예

{
  "email_count": 348,

  "projects": 7,

  "achievements": 6,

  "automation_candidates": 4,

  "estimated_saved_minutes": 192,

  "categories": {
    "QA_REPORT": 82,
    "BUG_REPORT": 43,
    "COLLABORATION": 67
  }
}

---

36. 핵심 Backend Service

class EmailAnalysisService:

    def analyze(self, email):

        cleaned_body = clean_email_body(
            email.body
        )

        direction = detect_direction(
            email.sender
        )

        ai_result = classifier.analyze(
            subject=email.subject,
            body=cleaned_body,
            direction=direction
        )

        embedding = embedding_service.embed(
            cleaned_body
        )

        minutes = estimate_email_minutes(
            cleaned_body
        )

        return EmailAnalysis(
            summary=ai_result.summary,
            category=ai_result.category,
            project=ai_result.project,
            action=ai_result.action,
            outcome=ai_result.outcome,
            importance=ai_result.importance,
            embedding=embedding,
            estimated_minutes=minutes
        )

---

37. Batch Analyzer

def analyze_emails(emails):

    results = []

    for email in emails:

        result = analysis_service.analyze(
            email
        )

        results.append(result)

    detect_duplicate_patterns(results)

    detect_automation_candidates(results)

    detect_achievements(results)

    return results

---

38. AI 사용 최소화 전략

모든 것을 AI에게 맡기면 느리고 비용이 증가한다.

따라서 처리 순서를 이렇게 한다.

RULE
↓
Python
↓
Embedding
↓
LLM

예:

프로젝트명 탐색

Regex 먼저
↓
없을 경우 AI

반복 이메일

Embedding

메일 개수

SQL

평균 응답시간

Python / SQL

월간 비율

SQL

최종 해석

AI

원칙:

AI는 숫자를 계산하지 않는다. AI는 숫자를 해석한다.

---

39. Monthly Insight Prompt

AI 입력:

{
  "email_count": 348,
  "top_categories": [],
  "projects": [],
  "automation_candidates": [],
  "achievements": [],
  "thread_statistics": {}
}

Prompt:

You are an enterprise productivity coach.

Analyze the user's monthly email work statistics.

Do not invent facts.

Focus on:

1. Main areas of work
2. Repeated work
3. Automation opportunities
4. Work achievements
5. One practical improvement for next month

Write in concise Korean.

Do not criticize the user.

Do not evaluate personality.

Only analyze observable work patterns.

---

40. 개인정보 보호 설계

기업 이메일을 다루기 때문에 매우 중요하다.

원칙:

최소 저장

가능하면 원본 메일 전체를 장기간 저장하지 않는다.

옵션:

Raw Email

↓ 분석

Summary
Embedding
Metadata

↓ 저장

Raw Body 삭제 가능

---

41. Redaction

AI 전송 전에 다음 정보를 마스킹할 수 있다.

전화번호

주민번호 형태

카드번호

계좌번호

개인 이메일

API Key

Password

예:

def redact_sensitive(text):

    text = re.sub(
        r"\b\d{3}-\d{3,4}-\d{4}\b",
        "[PHONE]",
        text
    )

    return text

---

42. Gmail/Outlook 연동 원칙

추후 구현 시 반드시

OAuth

Read Only Permission

을 우선한다.

MVP에서는 이메일 전송이나 삭제 기능을 만들지 않는다.

Inbox Lens는 분석 도구이지 이메일 조작 도구가 아니다.

---

43. Jira 연동 — Phase 2

QA 버전에서는 다음 단계가 핵심이다.

Email에서 Jira ID 탐색.

Pattern:

QA-3812
SHOP-921
CHECKOUT-271

Regex:

JIRA_PATTERN = r"\b[A-Z][A-Z0-9]+-\d+\b"

---

44. Email + Jira 연결

예:

Email

Checkout 결제 오류 확인

↓ Jira ID

QA-3812

↓

Jira

BUG

↓

Fix

↓

Email

QA-3812 재검증 완료

최종적으로 하나의 Work Episode로 묶는다.

---

45. Work Episode

{
  "title": "Checkout payment failure",

  "type": "BUG_RESOLUTION",

  "emails": 8,

  "jira": "QA-3812",

  "steps": [
    "BUG_FOUND",
    "BUG_REPORTED",
    "FIXED",
    "RETESTED",
    "CLOSED"
  ],

  "result": "Resolved before production release"
}

이 기능이 완성되면 Inbox Lens는 단순 이메일 분석기를 넘어선다.

개인 업무 기록 시스템이 된다.

---

46. QA 특화 확장

향후 Jira 데이터를 이용해 다음을 분석한다.

Bug Hotspot

Checkout        31%
Coupon          24%
Order           19%
Search          12%
Others          14%

Regression Risk

High Risk

Checkout Payment

관련 Bug
17건

최근 3개월 재발
4건

---

47. 자동화 TC 후보

Jira + Email + TC 데이터를 연결하면 다음까지 확장한다.

반복 Regression 영역

+

발생 빈도 높은 Bug

+

매 Release 실행되는 TC

↓

Automation Candidate

예:

자동화 후보

Coupon Apply Regression

매 Release 실행
18회

최근 관련 Bug
7건

Manual 시간
약 12분

Automation Priority
92

---

48. UI Design 원칙

게임화는 사용하되 유치하게 만들지 않는다.

피해야 할 UI:

LV.99 QA MASTER

+500 XP

몬스터 처치

권장:

이번 달 개선

자동화 업무
+2

절감 시간
+86분

새로 발견한 반복 패턴
3개

게임의 성장 구조만 차용한다.

---

49. MVP 화면

총 5개면 충분하다.

1. Dashboard

전체 업무 요약.

2. Work Analytics

업무 유형/프로젝트 분석.

3. Automation

반복 업무와 자동화 추천.

4. Achievements

성과와 해결한 업무.

5. Email Explorer

개별 분석 결과 확인.

---

50. MVP 개발 우선순위

Sprint 1

Project Setup
Database
Email Import
Email Parser

Sprint 2

AI Classification
Summary
Project Detection

Sprint 3

Embedding
Similarity
Repeated Email Cluster

Sprint 4

Automation Score
Achievement Detection
Dashboard

Sprint 5

Monthly Report
UI 개선
Test
Docker

---

51. MVP 완료 조건

다음 시나리오가 모두 동작하면 MVP 완료다.

Scenario 1

사용자가 300개의 이메일 CSV를 Import한다.

Scenario 2

시스템이 메일을 자동 분류한다.

Scenario 3

프로젝트별 메일 수를 보여준다.

Scenario 4

반복 이메일 Cluster를 탐지한다.

Scenario 5

자동화 후보를 보여준다.

Scenario 6

예상 절감 시간을 계산한다.

Scenario 7

긍정 Feedback과 문제 해결 메일을 성과 후보로 보여준다.

Scenario 8

월간 리포트를 생성한다.

---

52. 테스트 데이터

Codex가 실제 회사 이메일 없이 테스트할 수 있도록 Mock 데이터를 생성한다.

예:

500 Emails

QA Request             80
QA Result             100
Bug Report             60
Retest                 60
Meeting                40
Project Update          80
Others                  80

프로젝트:

Checkout Renewal
Search v2
Coupon Platform
Order Revamp

반복 Template를 일부러 포함한다.

예:

테스트 결과 전달드립니다.

확인 부탁드립니다.

20개.

이렇게 해야 Similarity Algorithm이 제대로 동작하는지 확인할 수 있다.

---

53. Unit Test

반드시 다음을 작성한다.

test_email_cleaner

test_direction_detection

test_project_regex

test_jira_regex

test_similarity

test_automation_score

test_email_time_estimation

test_thread_pingpong

test_achievement_detection

---

54. Codex 구현 시 가장 중요한 원칙

1.

처음부터 Gmail을 붙이지 않는다.

분석 Engine부터 완성한다.

2.

모든 숫자는 Python 또는 SQL로 계산한다.

LLM이 숫자를 만들면 안 된다.

3.

LLM 결과는 반드시 JSON Schema로 검증한다.

4.

AI 실패 시 프로그램 전체가 중단되면 안 된다.

Fallback:

AI 실패

↓

category = OTHER

↓

다음 이메일 계속 분석

5.

Email 원문과 Analysis 데이터를 분리한다.

6.

분석 로직은 독립 Service로 구현한다.

Frontend에서 AI를 직접 호출하지 않는다.

---

55. Codex에게 전달할 실제 구현 지시문

아래 내용을 그대로 Codex 작업 시작 프롬프트로 사용할 수 있다.

Build a full-stack MVP called "Inbox Lens".

Inbox Lens analyzes workplace email logs to discover:

- work categories
- projects
- repeated email patterns
- automation candidates
- estimated time savings
- achievements
- communication inefficiencies

TECH STACK

Frontend
- Next.js
- TypeScript
- Tailwind CSS
- Recharts

Backend
- Python
- FastAPI
- SQLAlchemy
- Pydantic

Database
- PostgreSQL
- pgvector

AI architecture
- provider abstraction
- mock provider must work without an external API key

IMPORTANT DESIGN RULES

1. Numerical statistics must be calculated in Python or SQL.
2. LLMs should only classify, summarize, extract and interpret.
3. All LLM output must use validated structured JSON.
4. AI failures must not stop batch analysis.
5. Raw email and analysis results must use separate database models.
6. Sensitive information should be redactable before AI processing.
7. Do not implement email sending or deleting.
8. Start with CSV/mock email import.
9. Gmail and Outlook connectors are future extensions.

CORE FEATURES

1. Email import
2. Email normalization
3. Email classification
4. Project detection
5. Semantic embeddings
6. Similar email clustering
7. Automation scoring
8. Estimated time saving
9. Achievement detection
10. Thread ping-pong analysis
11. Monthly work report
12. Dashboard

EMAIL CATEGORIES

REQUEST
REPLY
REPORT
APPROVAL
SCHEDULE
ISSUE
RESOLUTION
COLLABORATION
FEEDBACK
INFORMATION
QA_REPORT
QA_REQUEST
BUG_REPORT
RETEST_RESULT
OTHER

AUTOMATION SCORE

frequency_score * 0.30
+ similarity_score * 0.25
+ predictability_score * 0.20
+ time_score * 0.15
+ manual_effort_score * 0.10

Create:

- backend
- frontend
- database schema
- REST API
- mock data generator
- unit tests
- Docker configuration
- README

Generate at least 500 realistic mock workplace emails.

The mock dataset should include QA workflows such as:

test request
→ testing
→ test result
→ bug report
→ Jira
→ developer fix
→ retest
→ closure

Include repeated email templates so that semantic similarity detection can be tested.

BUILD ORDER

1. project skeleton
2. database models
3. mock data generator
4. email parser
5. analysis engine
6. similarity engine
7. automation engine
8. achievement engine
9. API
10. dashboard
11. tests
12. Docker
13. README

Do not build everything in one giant file.

Keep domain logic in services.

After implementation:

run all tests,
fix errors,
run the application,
and verify the main MVP workflow.

---

56. 장기적으로 지향할 제품

1차 버전은

Email Analyzer

다.

2차 버전은

Email + Jira Work Analyzer

가 된다.

3차 버전에서는

Email
+
Jira
+
Manual Test Case
+
Automation Test
+
Release

를 연결한다.

그러면 최종적으로 다음과 같은 질문에 답할 수 있다.

이번 달 QA에서 가장 많은 시간이 들어간 영역은 어디인가?

계속 반복되는 Manual Test는 무엇인가?

어떤 TC를 자동화해야 효과가 가장 큰가?

어떤 기능에서 Bug가 반복되고 있는가?

내가 이번 달 실제로 예방한 품질 문제는 무엇인가?

지난 6개월 동안 나는 어떤 QA 역량이 성장했는가?

이 단계에 도달하면 Inbox Lens의 본질은 이메일 분석이 아니다.

반복적인 QA 업무를 기록하고, 자동화하고, 그 과정에서 QA의 성장을 눈에 보이게 만드는 시스템이다.

서비스의 최종 메시지도 여기에 맞춘다.

테스트케이스는 닫혀도 경험은 남습니다.
Inbox Lens는 반복 업무 속에서 그 경험을 찾아냅니다.

가장 현실적인 구현 순서는 CSV/Mock 데이터 → 분석 엔진 → 대시보드 → Gmail/Outlook → Jira → Manual TC/자동화 테스트 연동입니다. 처음부터 메일·Jira·AI를 모두 연결하는 것보다, 반복 탐지와 자동화 추천 엔진부터 정확하게 만드는 편이 제품 완성도가 높아집니다.