AutoPercenty3/cluade.md

1. 프로젝트 개요 목적 (Objective) 기존 PySide6 기반 데스크톱 자동화 시스템을 웹 기반 분산 아키텍처로 전환하여:

확장성 확보 (수평 확장)

작업 병렬 처리 (Redis Queue 기반)

인증/권한 관리 통합 (Supabase)

자동화 작업의 API화 (Microservices)

운영 환경 분리 (Worker / API / Frontend)

2. 전체 아키텍처 [Frontend (Web)] ↓ [Supabase Auth] ↓ (JWT) [FastAPI Middleware] ↓ [Redis Queue] ↓ [Worker Servers (Playwright 기반)] ├── 상품명 수정 서비스 ├── 옵션 정리 서비스 ├── 번역 서비스 └── 확장 서비스들...
3. 핵심 구성요소 3.1 Frontend 웹 UI (React / Next.js)

Supabase Auth 사용

작업 요청 생성

작업 상태 조회

3.2 인증 (Supabase) 역할 사용자 인증 (JWT 발급)

권한 관리

정책 모든 API 요청은 JWT 필요

FastAPI에서 JWT 검증 수행

3.3 FastAPI Middleware 역할 인증 검증

요청 검증

작업 큐 등록

상태 조회 API 제공

주요 엔드포인트 POST /tasks/create GET /tasks/{task_id} GET /tasks/list 내부 처리 사용자 요청 → JWT 검증 → Task 생성 → Redis Queue push → Task ID 반환 3.4 Redis (Queue) 역할 작업 큐

비동기 처리

Worker 분산 처리

구조 queue:task:translate queue:task:product_edit queue:task:option_clean 3.5 Worker Server 역할 실제 작업 수행 (Playwright 기반)

API 기반 모듈화

독립적 배포 가능

구조 Worker ├── task_router ├── playwright_handler ├── service modules 서비스 예시 POST /worker/translate POST /worker/product_name POST /worker/options 4. 데이터 흐름 작업 생성 흐름

1. 사용자 요청
2. FastAPI → JWT 검증
3. Task 생성 (DB 저장)
4. Redis Queue 등록
5. Worker가 Pull
6. 작업 수행
7. 결과 저장
8. 상태 업데이트
9. PDCA 기반 개발 전략 5.1 PLAN 목표 정의 항목 목표 처리속도 기존 대비 2배 이상 확장성 Worker 수평 확장 안정성 실패 재시도 유지보수 서비스 단위 분리 설계 원칙 Stateless API

Queue 기반 비동기 처리

서비스 단위 분리

API First 설계

5.2 DO 단계별 구현 순서 Supabase 인증 구성

FastAPI 기본 서버 구축

Redis Queue 연결

Worker 기본 구조 구현

Playwright 모듈 분리

Task DB 설계

API ↔ Worker 연결

5.3 CHECK 검증 항목 작업 실패율

처리 시간

Worker 부하

Redis Queue 적체

로그 시스템 Task 로그

Worker 로그

에러 로그

5.4 ACT 개선 전략 병목 구간 분석

Worker autoscaling

Queue 분리 (작업별)

캐싱 적용

6. Task 모델 설계 기본 구조 { "id": "uuid", "type": "translate | product_edit | option_clean", "status": "pending | processing | done | failed", "input": {}, "output": {}, "created_at": "", "updated_at": "" }
7. Worker 확장 전략 플러그인 구조 services/ ├── translate.py ├── product_edit.py ├── option_clean.py 확장 방식 신규 서비스 추가 시:

서비스 모듈 생성

라우터 등록

큐 추가

8. Playwright 설계 원칙 브라우저 풀링

세션 재사용

Headless + Debug 모드 분리

Timeout 및 Retry 설정

9. 배포 구조 서버 구성 서버 역할 API 서버 FastAPI Worker 서버 Playwright 작업 Redis 서버 Queue Supabase 인증/DB
10. 리스크 및 대응 리스크 대응 Playwright 크래시 Worker 재시작 Queue 적체 Worker 증설 인증 실패 토큰 갱신 사이트 변경 selector 관리
11. 향후 확장 AI 기반 자동 수정

작업 우선순위 큐

멀티 테넌시

Webhook 결과 전달

스케줄링 작업

핵심 요약 구조는 "API → Queue → Worker" 로 단순화

모든 자동화는 API화 + 비동기 처리

Playwright는 Worker 내부로 완전 격리

Supabase는 인증 + 데이터 중심