최종 PDR
📋 제품 요구사항 명세서 (PDR)
AI 기반 자동 Jira 티켓 생성 시스템
1. 문제 정의 (Problem Definition)
핵심 문제
개발팀이 Slack이나 이메일에서 논의된 버그나 요청사항을 Jira 티켓으로 수동 전환하는 과정에서 발생하는 비효율성
구체적인 문제점
-
시간 소모: 수동 티켓 생성 작업이 번거롭고 티켓당 약 30분 소요
-
추적 누락: 회사에서 Jira로 모든 이슈를 트래킹하고자 하지만, 실제로는 놓치는 사항들이 많음
-
프로세스 비효율: Slack/이메일에서 논의된 중요한 내용들이 Jira로 제대로 이관되지 않아 추적 누락 발생
문제의 중요성
개발 프로세스의 투명성과 효율성을 저해하며, 중요한 이슈가 누락될 위험성이 높음
2. 목표 (Goals/Objectives)
달성하고자 하는 주요 가치
-
시간 절약: 수동 티켓 생성 시간 대폭 단축
-
이슈 추적 완성도 향상: Slack/이메일 논의사항의 누락 없는 Jira 이관
-
업무 효율성 증대: 개발팀의 전반적인 생산성 향상
-
리소스 Estimation 가능: 프로젝트 계획 및 리소스 배분의 정확도 개선
성공 측정 방법
-
MCP 콜이나 API 콜 수를 통한 개발자 업무 강도 측정 및 모니터링
-
시스템 사용량과 자동화 정도를 데이터로 추적 가능
확장 비전
향후 Jira ticket을 Codework에 연동하여 더 정확한 개발 업무량 측정 및 분석 가능
3. 타겟 사용자 (Target Audience / Persona)
주요 사용자
개발팀 전체 (개발자, PM, QA 등 모든 팀원)
사용 시나리오 및 일상 업무
-
외부 요청 처리: 고객사와의 협업 중 컨플루언스 페이지에 새로운 댓글로 요청이 들어옴
-
Gmail 연동: 해당 요청이 Gmail로 알림이 오면, 이를 시스템에 전달
-
자동 티켓 생성: “이걸 티켓으로 정리해서 만들어달라”고 API 호출
-
다양한 활용: 스크럼 계획, 버그 리포트, 기능 요청 등 모든 개발 업무에 활용
사용 타이밍
-
외부/내부에서 요청이 들어왔을 때 즉시
-
이메일이나 Slack에서 업무 관련 논의가 발생했을 때
-
수동으로 티켓을 만들어야 하는 모든 상황에서
4. 핵심 기능 (Key Features / Functional Requirements)
가장 중요한 핵심 기능들
1. 자연어 요청 처리
- 사용자가 “Gmail에 새로운 요청이 왔어, 티켓 내용을 정리해줘” 같은 자연어로 요청
2. Gmail/Slack 메시지 분석
- 요청받은 메시지를 AI가 분석하여 내용 파악
3. AI 기반 1차 추정 시스템
-
제목, 내용 자동 생성
-
리소스 소요량 추정
-
ETA(예상 완료 시간) 추정
4. 사용자 피드백 루프 시스템
-
AI가 생성한 추정값을 사용자에게 확인받는 대화형 인터페이스
-
사용자 피드백을 수집하고 반영
5. RAG 학습 시스템
-
사용자 피드백을 바탕으로 지속적인 학습 및 개선
-
추정 정확도 향상
사용자 플로우
사용자 요청 → Gmail/Slack 분석 → AI 1차 추정 제공 → 사용자 피드백 수집 → RAG 학습 → 최종 티켓 생성
5. 비기능 요구사항 (Non-functional Requirements)
성능 요구사항
-
응답 시간: Gmail/Slack 분석 후 1차 추정 결과를 5초 이내 제공
-
최대 응답 시간: 10초를 넘지 않도록 보장
보안 요구사항
-
인증 방식: 소셜 로그인 기반 사용자 가이드
-
기업 보안: SAML 또는 SSO 연동 (회사에서 이미 지원하는 인프라 활용)
-
데이터 보안: Gmail, Slack 등 민감한 데이터 처리 시 보안 고려
사용자 인터페이스
-
디자인 방향: 개발자 친화적인 심플한 형태
-
사용 편의성: 복잡하지 않은 직관적인 인터페이스
확장성
-
동시 사용자: 100명 이내의 작은 처리량 고려
-
팀 규모: 중소 규모 개발팀 대상
6. 성공 지표 (Success Metrics / KPIs)
효율성 지표
-
시간 절약률: 티켓 생성 시간 단축률 (기존 30분 → 목표 5분 이내)
-
자동화율: 전체 티켓 중 자동 생성 티켓 비율
-
API 호출 빈도: MCP/API 콜 수를 통한 업무 강도 측정
품질 지표
-
AI 추정 정확도: 리소스 및 ETA 추정의 실제 대비 정확도
-
사용자 피드백 반영률: 피드백 루프 시스템의 학습 개선 정도
-
티켓 품질 점수: 생성된 티켓의 완성도 및 유용성
사용성 지표
-
일일 활성 사용자 수: 시스템을 실제로 사용하는 개발팀원 수
-
응답 시간: 평균 시스템 응답 시간 (목표 5초 이내)
-
사용자 만족도: 시스템 사용 편의성 및 만족도 점수
7. 가정 및 제약사항 (Assumptions & Constraints)
주요 가정사항
-
사용자 행동: 개발팀이 Gmail/Slack을 적극적으로 업무에 사용
-
시스템 연속성: Jira를 지속적으로 사용할 것
-
피드백 참여: 사용자들이 AI 추정에 대한 피드백을 적극적으로 제공
-
기업 환경: 회사에서 SAML/SSO 인프라를 계속 지원
기술적 제약사항
-
성능 제약: 응답 시간 10초 이내 보장
-
확장성 제약: 100명 이내 동시 사용자 처리 범위
-
기술 스택: LangChain, Supabase, Next.js 기반 구조 활용
운영 제약사항
-
팀 규모: 중소 규모 개발팀 대상
-
데이터 접근: Gmail, Slack API 접근 권한 필요
-
보안 정책: 기업 보안 정책 준수
🧱 시스템 아키텍처 개요
전체 시스템 구조
🧍♂️ User
│
▼
┌─────────────────────────────┐
│ 1. 로그인 (Google / Slack) │
└─────────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Supabase Auth │
│ - OAuth 인증 │
│ - JWT 발급 (유저 구분 ID 제공) │
└──────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────┐
│ 2. Gmail / Slack 메시지 수집기 (ETL) │
│ - Gmail API / Slack API │
│ - 메시지 → 임베딩 → Supabase pgvector 저장 │
│ - user_id 로 연동 │
└──────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 3. LangChain Agent Server (Python) │
│ - RAG Retriever: Supabase pgvector에서 메시지 검색 │
│ - LLM: 요약/티켓 템플릿 생성 │
│ - Tool: Jira API 호출용 Supabase Edge Function 호출 │
└─────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────┐
│ 4. Supabase Edge Function │
│ - Jira 티켓 생성 │
│ - 생성 결과 Supabase DB에 저장 │
└────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ 5. Next.js 프론트엔드 │
│ - 티켓 결과 표시 / Slack / 메일로 알림 │
└──────────────────────────────────────────────┘주요 흐름 (Step-by-Step)
- 로그인: Google 또는 Slack OAuth → Supabase Auth
- 메시지 수집: Gmail/Slack API → 임베딩 → Supabase pgvector
- LangChain 처리: 자연어 요청 → 메시지 검색 → AI 추정 → 피드백 수집
- Jira 연동: Supabase Edge Function → Jira API → 티켓 생성
- 결과 표시: Next.js 프론트엔드 → 사용자 확인
핵심 기술 스택
-
Frontend: Next.js
-
Backend: LangChain (Python)
-
Database: Supabase (pgvector)
-
Authentication: Supabase Auth (OAuth)
-
Integration: Gmail API, Slack API, Jira API
📂 예상 디렉토리 구조
project-root/
│
├── frontend/ # Next.js 기반 UI
│ ├── pages/
│ │ ├── index.tsx # 로그인 or 요청 페이지
│ │ ├── dashboard.tsx # 생성된 티켓 결과
│ │ └── callback.tsx # OAuth 콜백 처리
│ ├── components/
│ ├── utils/
│ │ └── supabaseClient.ts # Supabase 클라이언트
│ └── .env.local # API Key들
│
├── supabase/ # Supabase 프로젝트 폴더
│ ├── migrations/ # DB 정의 (messages, tickets 등)
│ ├── functions/ # Edge Functions (jira-create 등)
│ │ └── create-jira-ticket.ts
│ └── .env # Service Role Key 등
│
├── backend/ # LangChain 기반 Python 서버
│ ├── agent.py # Agent 정의
│ ├── retriever.py # Supabase 벡터 검색
│ ├── tools/
│ │ └── jira_tool.py # Supabase Edge 호출
│ ├── embeddings.py # 메시지 임베딩 처리
│ └── main.py # Flask / FastAPI 서버
│
├── etl/ # Slack / Gmail ETL
│ ├── sync_slack.py
│ └── sync_gmail.py
│
└── README.md🗃 Supabase DB 설계
users (자동 생성됨 by Auth)
messages
| 필드 | 타입 | 설명 |
|---|---|---|
| id | uuid | PK |
| user_id | uuid | Auth user.id |
| source | text | ”slack” / “gmail” |
| content | text | 메시지 내용 |
| embedding | vector(1536) | 임베딩 결과 |
| created_at | timestamp | 수집 시각 |
tickets
| 필드 | 타입 | 설명 |
|---|---|---|
| id | uuid | PK |
| user_id | uuid | 생성한 유저 |
| title | text | Jira 제목 |
| description | text | Jira 본문 |
| jira_url | text | Jira 티켓 링크 |
| estimated_hours | integer | 추정 소요 시간 |
| eta_date | date | 예상 완료 일자 |
| feedback_score | integer | 사용자 피드백 점수 |
| created_at | timestamp | 생성 시각 |
✅ 핵심 장점
-
LangChain은 LLM 추론에 집중, Supabase는 데이터 저장과 실행 제어에 집중
-
Supabase Auth 기반으로 유저별 데이터 격리 보안 완성
-
피드백 루프 + RAG 학습으로 지속적인 품질 개선
-
확장 시 Slack, Notion, GitHub 등도 쉽게 연동 가능
이 PDR 문서는 AI 기반 자동 Jira 티켓 생성 시스템의 개발 방향과 요구사항을 체계적으로 정리한 문서입니다. 특히 사용자 피드백 루프와 RAG 학습 시스템을 통한 지속적인 개선이 핵심 차별화 요소입니다.
📅 작성 정보
-
작성일: 2025-01-10
-
버전: 1.0
-
작성자: AI Product Manager Assistant
-
상태: 개발 준비 완료