568 lines
24 KiB
Markdown
568 lines
24 KiB
Markdown
# TaxBaik 개선 로드맵 WBS
|
|
|
|
이 문서는 "완료 보고"가 아니라 검증 가능한 작업 목록이다. 각 WBS는 성공 기준을 통과해야 완료로 본다.
|
|
|
|
---
|
|
|
|
## 완료 판정 원칙
|
|
|
|
- 코드 변경만으로 완료 처리하지 않는다.
|
|
- 서버 배포 대상 기능은 CI/CD 성공과 실제 동작 확인을 요구한다.
|
|
- API 기능은 단위 테스트 또는 통합 테스트와 함께 실제 HTTP 호출 결과를 확인한다.
|
|
- DB 변경은 마이그레이션과 롤백 위험을 문서화한다.
|
|
- 비밀값은 Gitea Secrets 또는 서버 환경변수로만 관리한다.
|
|
|
|
---
|
|
|
|
## ── 홈페이지 · SEO · UX ───────────────────────────
|
|
|
|
## WBS-UX-01 공개 홈페이지 UX/SEO 검증
|
|
|
|
목표: 공개 홈페이지가 검색 유입과 상담 전환에 맞는 구조인지 검증한다.
|
|
|
|
성공 기준:
|
|
- 홈/블로그 목록/블로그 상세/상담 문의 페이지 200
|
|
- 주요 페이지 title/description 존재
|
|
- 모바일 viewport에서 주요 CTA가 보인다.
|
|
- 상담 문의 제출 Playwright E2E가 통과한다.
|
|
- 블로그 상세 SEO 메타 검증이 배포본 기준으로 통과한다.
|
|
|
|
Todo:
|
|
- [x] 공개 페이지 Playwright smoke E2E 추가
|
|
- [x] 상담 문의 제출 E2E 추가
|
|
- [x] 블로그 상세 SEO 메타 검증 추가
|
|
|
|
검증 파일:
|
|
- `tests/e2e/public-smoke.spec.ts`
|
|
- `tests/e2e/blog-seo.spec.ts`
|
|
- `tests/e2e/contact-submit.spec.ts`
|
|
- `tests/e2e/inquiry-detail.spec.ts`
|
|
|
|
## WBS-UX-02 홈페이지 FAQ 섹션 (정적)
|
|
|
|
목표: 방문자가 상담 전 자주 묻는 질문에서 직접 답을 얻고 전환율을 높인다.
|
|
|
|
성공 기준:
|
|
- 홈페이지에 4개 FAQ 아코디언 표시 (기장료, 양도세 상담, 무료 상담, 첫 상담 준비물)
|
|
- 아코디언 열림/닫힘 동작
|
|
- 모바일에서 가독성 확인
|
|
|
|
Todo:
|
|
- [x] Index.cshtml에 FAQ 아코디언 섹션 추가 (최종 CTA 앞)
|
|
- [x] site.css faq-accordion / faq-item / faq-question / faq-answer 스타일
|
|
- [x] 배포 완료 (`12070b7`)
|
|
- [ ] 배포 후 브라우저 아코디언 동작 확인
|
|
|
|
## WBS-UX-04 개인정보처리방침·이용약관 페이지
|
|
|
|
목표: 법적 의무를 충족하고 방문자 신뢰를 높이는 정책 페이지를 제공한다.
|
|
|
|
성공 기준:
|
|
- `/taxbaik/privacy` 개인정보처리방침 페이지 정상 렌더링 (200)
|
|
- `/taxbaik/terms` 이용약관 페이지 정상 렌더링 (200)
|
|
- 푸터에 두 페이지 링크 표시
|
|
- 개인정보처리방침: 수집 항목, 이용 목적, 보유 기간, 파기 방법, 책임자 정보 포함
|
|
- 이용약관: 목적, 서비스 범위, 면책 조항, 저작권, 준거법 포함
|
|
|
|
Todo:
|
|
- [x] Privacy.cshtml + Privacy.cshtml.cs (Razor Page)
|
|
- [x] Terms.cshtml + Terms.cshtml.cs (Razor Page)
|
|
- [x] _Footer.cshtml에 링크 이미 존재 확인
|
|
- [ ] 배포 후 /taxbaik/privacy, /taxbaik/terms 접근 확인
|
|
|
|
## WBS-UX-03 FAQ 관리 (어드민 CRUD)
|
|
|
|
목표: 세무사가 관리자 화면에서 FAQ 항목을 직접 등록·수정·삭제·순서 조정한다.
|
|
홈페이지 FAQ가 하드코딩에서 DB 기반으로 전환되어, 코드 수정 없이 운영 가능해진다.
|
|
|
|
설계 방향:
|
|
- FAQ 항목: 질문(question), 답변(answer), 정렬 순서(sort_order), 활성화 여부(is_active)
|
|
- 홈페이지는 is_active=TRUE 항목을 sort_order 오름차순으로 표시
|
|
- 카테고리 태그(선택): "기장·세금신고", "부동산", "증여·상속", "기타" — 홈페이지에서 탭 필터 가능
|
|
|
|
성공 기준:
|
|
- 관리자 `/taxbaik/admin/faqs` 목록/생성/수정/삭제/순서변경 동작
|
|
- 홈페이지 FAQ 섹션이 DB에서 로드 (하드코딩 제거)
|
|
- 비활성 항목은 홈페이지 미표시
|
|
- sort_order 기준 정렬
|
|
|
|
DB 스키마:
|
|
- `faqs` 테이블 (V007 마이그레이션)
|
|
- id SERIAL PK
|
|
- question VARCHAR(300) NOT NULL
|
|
- answer TEXT NOT NULL
|
|
- category VARCHAR(50) — 기장·세금신고, 부동산, 증여·상속, 기타
|
|
- sort_order INT DEFAULT 0
|
|
- is_active BOOLEAN DEFAULT TRUE
|
|
- created_at TIMESTAMPTZ
|
|
- updated_at TIMESTAMPTZ
|
|
|
|
Todo:
|
|
- [x] V007__CreateFaqs.sql 마이그레이션 (기본 FAQ 4개 시드 포함)
|
|
- [x] Faq 엔티티 (Domain)
|
|
- [x] IFaqRepository 인터페이스 (Domain)
|
|
- [x] FaqRepository 구현 (Infrastructure) — sort_order 정렬, CRUD
|
|
- [x] FaqService 구현 (Application) — Categories 상수, 유효성 검사
|
|
- [x] FaqList.razor 관리자 목록 (활성/비활성 상태 칩, 삭제 확인)
|
|
- [x] FaqEdit.razor 관리자 등록/수정 (질문/답변/카테고리/순서/활성 토글)
|
|
- [x] Index.cshtml FAQ 섹션 하드코딩 → DB 루프로 교체 (빈 DB에도 안전)
|
|
- [x] IndexModel FaqService 주입, Task.WhenAll 병렬 로드
|
|
- [x] MainLayout.razor FAQ 관리 메뉴 추가 (홈페이지 그룹 하위)
|
|
- [ ] 배포 후 관리자에서 FAQ 추가 → 홈페이지 반영 확인
|
|
|
|
---
|
|
|
|
## ── 시즌별 마케팅 ───────────────────────────────
|
|
|
|
## WBS-MKT-01 시즌별 홈페이지 자동 전환
|
|
|
|
목표: 세무 신고 시즌마다 홈페이지 Hero·CTA·서비스 카드 순서가 자동 변경된다.
|
|
|
|
성공 기준:
|
|
- 7개 시즌(vat-2nd, year-end-settlement, corporate-tax, income-tax, vat-1st, comprehensive-real-estate-tax, year-end-gift) 날짜 판정 정확
|
|
- 시즌 중 Hero에 UrgencyBadge 표시
|
|
- D-7일 이내 긴박감 메시지 표시
|
|
- FocusService 기준 서비스 카드 순서 자동 정렬
|
|
- 최종 CTA 시즌 문구 전환
|
|
|
|
Todo:
|
|
- [x] TaxSeason / TaxSeasonCalendar 정의
|
|
- [x] CurrentSeasonDto / SeasonalMarketingService 구현
|
|
- [x] Index.cshtml Hero 시즌 분기 렌더링
|
|
- [x] Index.cshtml 서비스 카드 cardOrder 정렬 로직
|
|
- [x] Index.cshtml 최종 CTA 시즌 전환
|
|
- [x] CLAUDE.md 섹션 13 세무 캘린더 하네스
|
|
- [ ] 배포 후 시즌 날짜 경계값 수동 확인
|
|
|
|
## WBS-MKT-04 시즌 시뮬레이터 (어드민)
|
|
|
|
목표: 관리자가 날짜를 선택해 홈페이지 시즌 화면을 사전에 확인하고 콘텐츠 준비를 계획한다.
|
|
|
|
배경: 7개 시즌이 자동 전환되므로, 실제 날짜가 되기 전 미리 Hero 화면을 확인하는 도구가 필요하다.
|
|
|
|
성공 기준:
|
|
- 관리자 `/taxbaik/admin/season-simulator` 접근 가능
|
|
- 날짜 선택 시 해당 날짜의 Hero 섹션 미리보기 렌더링
|
|
- 각 시즌 버튼 클릭으로 해당 시즌 첫날로 즉시 이동
|
|
- 비시즌 날짜 선택 시 기본 Hero 미리보기 표시
|
|
- 연간 시즌 타임라인 테이블 표시
|
|
|
|
Todo:
|
|
- [x] SeasonSimulator.razor 어드민 페이지 구현
|
|
- [x] 날짜 선택 → 실시간 Hero 미리보기
|
|
- [x] 시즌 빠른 이동 버튼 (7개 시즌)
|
|
- [x] 연간 타임라인 테이블 (활성/비활성 구분)
|
|
- [x] MainLayout.razor 시즌 시뮬레이터 메뉴 추가 (홈페이지 그룹 하위)
|
|
- [ ] 배포 후 관리자에서 시뮬레이터 동작 확인
|
|
|
|
## WBS-MKT-02 관리자 공지사항 (Announcement)
|
|
|
|
목표: 운영자가 홈페이지 최상단 배너를 등록·수정·삭제할 수 있다.
|
|
|
|
성공 기준:
|
|
- 관리자 `/taxbaik/admin/announcements` 목록/생성/수정/삭제 동작
|
|
- is_active=TRUE + 기간 조건(starts_at~ends_at)에 해당하는 공지만 홈페이지에 노출
|
|
- 유형(info/banner/urgent) 별 색상 배지 표시
|
|
- 홈페이지 최상단 announcement-bar 노출
|
|
|
|
Todo:
|
|
- [x] V005__CreateAnnouncements.sql 마이그레이션
|
|
- [x] Announcement 엔티티, IAnnouncementRepository, AnnouncementRepository
|
|
- [x] AnnouncementService 구현
|
|
- [x] AnnouncementList.razor, AnnouncementEdit.razor 관리자 화면
|
|
- [x] Index.cshtml 공지사항 배너 렌더링
|
|
- [x] MainLayout.razor 공지사항 메뉴 추가
|
|
- [ ] 배포 후 공지 등록 → 홈 노출 확인
|
|
|
|
## WBS-MKT-03 블로그 시즌 연동
|
|
|
|
목표: 시즌 활성 중 홈페이지 블로그 섹션이 시즌 관련 글을 우선 노출한다.
|
|
|
|
배경: 세무 시즌에 맞는 콘텐츠를 전면에 배치해 상담 전환율과 SEO 체류시간을 높인다.
|
|
|
|
성공 기준:
|
|
- 시즌 중: 해당 카테고리 글 최대 2개(이번 시즌 추천 배지) + 최신 글로 3개 채움
|
|
- 평상시: 최신 글 3개 (기존 동작)
|
|
- 시즌별 전체 글 보기 버튼 (`/taxbaik/blog?category=<slug>`)
|
|
- 배너 헤더가 시즌명 표시
|
|
|
|
카테고리 → 시즌 슬러그 매핑:
|
|
- `vat-2nd` / `vat-1st` → `vat`
|
|
- `income-tax` → `income-tax`
|
|
- `year-end-settlement` / `corporate-tax` → `business-tax`
|
|
- `comprehensive-real-estate-tax` → `real-estate-tax`
|
|
- `year-end-gift` → `family-asset`
|
|
|
|
Todo:
|
|
- [x] TaxSeason.RelatedCategorySlug 추가
|
|
- [x] TaxSeasonCalendar 각 시즌에 카테고리 슬러그 매핑
|
|
- [x] CurrentSeasonDto.RelatedCategorySlug 추가
|
|
- [x] SeasonalMarketingService에 RelatedCategorySlug 전달
|
|
- [x] IBlogPostRepository.GetByCategorySlugAsync 추가
|
|
- [x] BlogPostRepository.GetByCategorySlugAsync 구현
|
|
- [x] BlogService.GetSeasonalPostsAsync 추가
|
|
- [x] IndexModel SeasonalPosts/RecentPosts 분리 로드
|
|
- [x] Index.cshtml 블로그 섹션 시즌 분기 렌더링
|
|
- [x] site.css 블로그 시즌 강조 스타일 추가
|
|
- [ ] 배포 후 시즌 활성 날짜에 블로그 카드 "이번 시즌 추천" 배지 확인
|
|
|
|
---
|
|
|
|
## ── 운영 인프라 ─────────────────────────────────
|
|
|
|
## WBS-OPS-01 배포 검증 게이트 고도화
|
|
|
|
목표: curl/API만이 아니라 실제 브라우저 검증까지 통과해야 배포를 성공으로 본다.
|
|
|
|
성공 기준:
|
|
- `dotnet build TaxBaik.sln -c Release` 경고 0, 오류 0
|
|
- `dotnet test TaxBaik.sln -c Release --no-build` 전체 통과
|
|
- CI 배포 후 Playwright가 `/taxbaik/admin/login`에서 실제 로그인 수행
|
|
- 로그인 후 `/taxbaik/admin/dashboard` 도달
|
|
- 브라우저 console error 및 page error 0개
|
|
|
|
Todo:
|
|
- [x] Playwright Test 프로젝트 추가
|
|
- [x] 관리자 로그인 E2E 추가
|
|
- [x] CI 배포 후 Playwright 실행 단계 추가
|
|
- [x] Playwright가 발견한 Blazor DI 결함 수정
|
|
- [ ] CI run에서 Playwright 전체 통과 확인
|
|
- [ ] 배포 검증에 블로그 상세/문의/비밀번호 변경 성공 기준 반영 확인
|
|
|
|
## WBS-OPS-02 배포 502 / Nginx 유지보수 페이지
|
|
|
|
목표: CI 배포 중 502 Bad Gateway 대신 한국어 유지보수 페이지를 제공한다.
|
|
|
|
성공 기준:
|
|
- Nginx error_page 502/503 → maintenance.html 직접 서빙
|
|
- 배포 중 방문자는 유지보수 페이지(15초 자동 새로고침)를 본다.
|
|
- 배포 완료 후 정상 서비스 복구
|
|
|
|
Todo:
|
|
- [x] maintenance.html 작성
|
|
- [x] Nginx error_page 502 503 @taxbaik_maintenance 설정
|
|
- [x] 서버 측 헬스 루프 (40회×3초) 단일 SSH 연결로 처리
|
|
- [x] CI 배포 단계 헬스 체크 고도화
|
|
|
|
## WBS-OPS-03 관리자 401 수정
|
|
|
|
목표: 직접 URL 접근 시 관리자 Blazor 페이지가 401로 차단되지 않는다.
|
|
|
|
성공 기준:
|
|
- `/taxbaik/admin/announcements` 등 직접 접근 시 Blazor Shell 200 응답
|
|
- 미인증 사용자는 로그인 페이지로 리다이렉트
|
|
|
|
Todo:
|
|
- [x] MapRazorComponents().AllowAnonymous() 적용
|
|
- [x] AuthorizeRouteView → RedirectToLogin 인증 흐름 확인
|
|
|
|
---
|
|
|
|
## ── 인증 · 관리자 ─────────────────────────────────
|
|
|
|
## WBS-AUTH-01 인증/비밀번호 운영 안정화
|
|
|
|
목표: DB 직접 수정 대신 API로 관리자 인증 운영 작업을 수행한다.
|
|
|
|
성공 기준:
|
|
- 비밀번호 변경 API가 현재 비밀번호를 요구한다.
|
|
- 비밀번호 재설정 API는 운영 secret 없이는 동작하지 않는다.
|
|
- 실패 응답은 민감 정보를 노출하지 않는다.
|
|
|
|
Todo:
|
|
- [x] 로그인 API 검증
|
|
- [x] 비밀번호 변경 API 추가
|
|
- [x] 재설정 API 추가
|
|
- [x] 관리자 UI에 비밀번호 변경 화면 추가
|
|
- [x] 비밀번호 변경 Playwright E2E 추가
|
|
|
|
## WBS-ADMIN-01 관리자 Blazor 안정화
|
|
|
|
목표: 관리자 화면을 일반 웹페이지처럼 명시적 사용자 액션에만 갱신하고, circuit 예외를 배포 전 차단한다.
|
|
|
|
성공 기준:
|
|
- 관리자 주요 메뉴 대시보드/블로그/문의/설정/공지사항 circuit error 0개
|
|
- 저장/삭제/상태 변경 액션은 성공/실패 메시지를 표시한다.
|
|
|
|
Todo:
|
|
- [x] 중복 `/admin` 라우트 제거
|
|
- [x] MudBlazor DI 타입 오류 수정
|
|
- [x] 관리자 메뉴 smoke E2E 추가
|
|
- [x] 설정 저장 TODO를 실제 DB 기반 기능으로 전환
|
|
|
|
---
|
|
|
|
## ── 고객지원 백오피스 (CRM) ──────────────────────
|
|
|
|
> **배경**: 세무사 사무실에서 고객 정보와 상담 이력이 파편화(메모장·카톡·기억)되면 마감 누락, 서비스 연속성 단절, 재계약 기회 손실이 발생한다.
|
|
> 30년 경력 세무사가 혼자 또는 소수 인원으로 운영할 때 가장 먼저 필요한 것은 고객 카드와 상담 이력이다.
|
|
|
|
## WBS-CRM-01 고객 카드 (Client Card) — Phase 1
|
|
|
|
목표: 고객별 기본 정보·서비스 유형·상태를 한 화면에서 관리한다.
|
|
|
|
성공 기준:
|
|
- 관리자 `/taxbaik/admin/clients` 목록/검색/생성/수정/삭제 동작
|
|
- 고객 카드: 이름, 회사명, 연락처, 이메일, 서비스 유형, 세금 유형, 상태, 유입 경로, 메모
|
|
- 상태 필터(활성/비활성)로 목록 조회
|
|
- 고객 저장 시 updated_at 자동 갱신
|
|
|
|
DB 스키마:
|
|
- `clients` 테이블 (V006 마이그레이션)
|
|
- 컬럼: id, name, company_name, phone, email, service_type, tax_type, status, source, memo, created_at, updated_at
|
|
|
|
Todo:
|
|
- [x] V006__CreateClients.sql 마이그레이션
|
|
- [x] Client 엔티티 (Domain)
|
|
- [x] IClientRepository 인터페이스 (Domain) — GetPagedAsync 검색+상태 필터
|
|
- [x] ClientRepository 구현 (Infrastructure) — ILIKE 검색, 페이징
|
|
- [x] ClientService 구현 (Application) — ServiceTypes/TaxTypes/Sources 상수
|
|
- [x] ClientList.razor 관리자 목록 화면 — 검색바, 상태 필터, 페이징
|
|
- [x] ClientEdit.razor 관리자 등록/수정 화면 — 기본/세무/관리 섹션
|
|
- [x] MainLayout.razor 고객 관리 NavGroup 추가
|
|
- [ ] 배포 후 고객 등록 → 목록 조회 확인
|
|
|
|
## WBS-CRM-02 상담 이력 (Consultation Log) — Phase 1
|
|
|
|
목표: 고객별 상담 일자·내용·결과·수수료를 기록해 "이 고객 지난번에 뭐 상담했더라?"를 해결한다.
|
|
|
|
성공 기준:
|
|
- 고객 상세에서 상담 이력 목록/추가/삭제 동작
|
|
- 상담 이력 필드: 날짜, 서비스 유형, 상담 요약, 결과(계약/보류/거절/완료), 수수료
|
|
- 이력 없는 고객은 빈 목록 표시
|
|
|
|
DB 스키마:
|
|
- `consultations` 테이블 (V008 마이그레이션)
|
|
- 컬럼: id, client_id(FK), consultation_date, service_type, summary, result, fee, created_at
|
|
|
|
Todo:
|
|
- [x] V008__CreateConsultations.sql 마이그레이션
|
|
- [x] Consultation 엔티티 (Domain)
|
|
- [x] IConsultationRepository 인터페이스 (Domain)
|
|
- [x] ConsultationRepository 구현 (Infrastructure)
|
|
- [x] ConsultationService 구현 (Application)
|
|
- [x] ClientDetail.razor (고객 상세 + 상담 이력 추가/삭제)
|
|
- [x] DI 등록 (Infrastructure + Application)
|
|
- [ ] 배포 후 고객 상세에서 상담 이력 추가 확인
|
|
|
|
## WBS-CRM-03 문의 → 고객 전환 — Phase 1
|
|
|
|
목표: 홈페이지 문의 접수 건을 클릭 한 번으로 고객 카드로 등록한다.
|
|
|
|
성공 기준:
|
|
- 문의 상세에 "고객으로 등록" 버튼 표시
|
|
- 버튼 클릭 시 고객 카드 자동 생성 후 연결
|
|
- 이미 연결된 고객이 있으면 버튼 대신 고객 카드 링크 표시
|
|
- inquiries 테이블에 client_id, admin_memo, updated_at 컬럼 추가
|
|
|
|
Todo:
|
|
- [x] V009__AddClientIdToInquiries.sql 마이그레이션
|
|
- [x] Inquiry 엔티티 client_id, admin_memo, updated_at 추가
|
|
- [x] IInquiryRepository.LinkClientAsync, UpdateAdminMemoAsync 추가
|
|
- [x] InquiryRepository 구현
|
|
- [x] InquiryService.LinkClientAsync, UpdateAdminMemoAsync 추가
|
|
- [x] ClientService.CreateFromInquiryAsync 추가
|
|
- [x] InquiryDetail.razor "고객으로 등록" 버튼 + 담당자 메모 추가
|
|
- [ ] 배포 후 문의 → 고객 전환 흐름 확인
|
|
|
|
---
|
|
|
|
## ── 고객지원 백오피스 Phase 2 ──────────────────────
|
|
|
|
## WBS-CRM-04 신고 일정 캘린더 — Phase 2
|
|
|
|
목표: 고객별 신고 예정일과 마감일을 추적해 가산세 리스크를 방지한다.
|
|
|
|
성공 기준:
|
|
- 관리자에서 고객별 세금 신고 일정 등록/수정/완료 처리
|
|
- D-Day 표시 (D-7일 이내 강조)
|
|
- 이번 달 마감 목록을 대시보드 위젯으로 표시
|
|
|
|
DB 스키마:
|
|
- `tax_filings` 테이블 (V010 마이그레이션)
|
|
- 컬럼: id, client_id(FK), filing_type, due_date, status(pending/filed/overdue), memo
|
|
|
|
Todo:
|
|
- [x] V010__CreateTaxFilings.sql
|
|
- [x] TaxFiling 엔티티 (Domain)
|
|
- [x] ITaxFilingRepository, TaxFilingRepository 구현
|
|
- [x] TaxFilingService 구현 (Application)
|
|
- [x] TaxFilingList.razor (관리자 신고 일정 화면 + 상태별 탭)
|
|
- [x] FilingTable.razor (D-Day 강조, 완료 처리, 삭제)
|
|
- [x] Dashboard.razor에 30일 이내 마감 위젯 추가
|
|
- [x] MainLayout.razor 신고 일정 메뉴 추가
|
|
- [x] DI 등록
|
|
- [ ] 배포 후 신고 일정 등록 → D-Day 표시 확인
|
|
|
|
## WBS-CRM-05 문의 접수 현황 강화 — Phase 2
|
|
|
|
목표: 문의 상태를 세분화하고 담당자 메모를 기록해 처리 흐름을 추적한다.
|
|
|
|
성공 기준:
|
|
- 문의 상태: 신규/상담중/계약완료/거절/종결 5단계
|
|
- 목록에서 상태 탭 필터로 빠른 분류
|
|
- 상태 변경 시 updated_at 자동 기록
|
|
|
|
Todo:
|
|
- [x] V011__ExtendInquiryStatus.sql 마이그레이션 (contacted→consulting, completed→closed, admin_memo/updated_at 추가)
|
|
- [x] InquiryStatus enum 5단계 확장
|
|
- [x] InquiryStatusMapper 5단계 레이블 + TryParse 업데이트
|
|
- [x] InquiryList.razor 5단계 탭 (신규/상담중/계약완료/거절/종결)
|
|
- [x] InquiryDetail.razor 5단계 상태 버튼 + 색상 구분
|
|
- [x] Dashboard.razor 상태 레이블 5단계 반영
|
|
|
|
---
|
|
|
|
## ── 고객지원 백오피스 Phase 3 ──────────────────────
|
|
|
|
## WBS-CRM-06 텔레그램 자동 리포트 — Phase 3
|
|
|
|
목표: 세무사에게 일/주 단위 신규 문의·처리 현황·마감 임박 건을 텔레그램으로 전송한다.
|
|
|
|
성공 기준:
|
|
- 매일 오전 9시 신규 문의 수, 처리 대기 수 자동 전송
|
|
- 매주 월요일 주간 리포트 (신규 고객, 이번 주 마감 신고 건)
|
|
- 텔레그램 전송 실패 시 로그만 남기고 앱 정상 운영 유지
|
|
|
|
Todo:
|
|
- [x] BackgroundService 또는 Hangfire 기반 스케줄러 추가
|
|
- [x] 일간/주간 리포트 메시지 템플릿
|
|
- [x] TelegramNotificationService에 리포트 메서드 추가
|
|
|
|
## WBS-CRM-07 고객 포털 (읽기 전용) — Phase 3
|
|
|
|
목표: 기장 고객이 본인 신고 현황과 중요 알림을 직접 확인한다.
|
|
|
|
성공 기준:
|
|
- 고객 전용 URL + 인증(소셜 로그인 또는 링크 토큰)
|
|
- 본인 신고 일정, 상담 요약(세무사 허용 항목만) 조회
|
|
- 개인정보 열람 범위는 세무사가 허용한 항목만
|
|
|
|
Todo:
|
|
- [x] 고객 포털 설계 (인증 방식 결정 — WBS-CRM-08 선행)
|
|
- [x] 고객 전용 Razor Pages 추가
|
|
- [x] 세무사 허용 권한 설정 UI
|
|
|
|
## WBS-CRM-08 고객 회원가입 · 소셜 로그인 — Phase 3
|
|
|
|
목표: 고객 포털 접근을 위한 회원가입과 소셜 로그인을 제공한다.
|
|
가입 마찰을 최소화해 상담 접수 → 고객 포털 전환율을 높인다.
|
|
|
|
설계 방향:
|
|
- 가입 입력 최소화: 이름 + 연락처(또는 이메일) 2필드면 충분
|
|
- 소셜 로그인 우선: 비밀번호 없이 바로 가입
|
|
- 기본 계정(이메일/비밀번호) 옵션도 제공 (소셜 없는 사용자 대비)
|
|
- 고객 포털 전용 인증 — 관리자(admin_users)와 완전히 분리
|
|
|
|
지원 소셜 로그인:
|
|
- 네이버 (Naver OAuth 2.0) — 국내 주요 채널
|
|
- 카카오 (Kakao Login) — 기존 카카오 채널 연계
|
|
- 구글 (Google OAuth 2.0) — 해외·젊은 고객층
|
|
|
|
성공 기준:
|
|
- 소셜 로그인 3종 모두 동작 (네이버·카카오·구글)
|
|
- 이메일/비밀번호 기본 계정 가입 + 로그인 동작
|
|
- 가입 폼: 이름·연락처 2필드만 요구 (소셜 프로필에서 자동 채우기)
|
|
- 로그인 후 고객 포털 (`/taxbaik/portal`) 접근
|
|
- 고객 계정이 백오피스 clients 테이블 레코드와 연결
|
|
- 회원 계정 미인증 상태에서 포털 접근 시 로그인 페이지 리다이렉트
|
|
|
|
DB 스키마:
|
|
- `portal_users` 테이블 (V011 마이그레이션)
|
|
- id, client_id(FK, nullable), email, name, phone, provider(naver/kakao/google/local), provider_id, password_hash(nullable), created_at
|
|
- 소셜 로그인 provider_id는 각 플랫폼 식별자
|
|
|
|
기술 결정:
|
|
- ASP.NET Core OAuth Middleware (Microsoft.AspNetCore.Authentication.OAuth)
|
|
- 네이버: 커스텀 OAuth handler (공식 패키지 없음, 직접 구현)
|
|
- 카카오: AspNet.Security.OAuth.Kakao 패키지
|
|
- 구글: Microsoft.AspNetCore.Authentication.Google 패키지
|
|
- 고객 포털 세션: HttpOnly Cookie 기반 (JWT localStorage와 분리)
|
|
|
|
환경 변수 필요 (Gitea Secrets 추가):
|
|
- `NAVER_CLIENT_ID` / `NAVER_CLIENT_SECRET`
|
|
- `KAKAO_CLIENT_ID` / `KAKAO_CLIENT_SECRET`
|
|
- `GOOGLE_CLIENT_ID` / `GOOGLE_CLIENT_SECRET`
|
|
|
|
Todo:
|
|
- [x] WBS-CRM-07 고객 포털 기본 구조 완성 (선행)
|
|
- [x] OAuth 앱 등록 (네이버·카카오·구글 개발자 콘솔)
|
|
- [x] V011__CreatePortalUsers.sql 마이그레이션 (실제 V016__CreatePortalUsers.sql로 대체됨)
|
|
- [x] PortalUser 엔티티 / IPortalUserRepository / PortalUserRepository
|
|
- [x] 네이버 OAuth Handler 구현
|
|
- [x] 카카오·구글 패키지 추가 및 설정
|
|
- [x] 기본 계정 회원가입 폼 (`/taxbaik/portal/register`)
|
|
- [x] 소셜 로그인 콜백 처리 → portal_users 자동 생성
|
|
- [x] 신규 가입 시 clients 테이블 연결 또는 신규 생성
|
|
- [x] 포털 로그인 페이지 (`/taxbaik/portal/login`) — 소셜 버튼 + 이메일 폼
|
|
- [ ] Gitea Secrets에 OAuth 키 추가
|
|
- [ ] 배포 후 소셜 로그인 3종 E2E 테스트
|
|
|
|
---
|
|
|
|
## ── 유지보수성 ─────────────────────────────────
|
|
|
|
## WBS-MAINT-01 유지보수성/파편화 축소
|
|
|
|
목표: 문서와 실제 구조의 불일치를 줄이고 단일 앱 운영 기준을 유지한다.
|
|
|
|
Todo:
|
|
- [x] README 테스트/배포 섹션 갱신
|
|
- [x] CLAUDE.md E2E 기준 갱신
|
|
- [x] 오래된 최종 보고 문서의 허위 완료 표현 정정
|
|
- [x] CLAUDE.md 섹션 13 시즌별 마케팅 하네스 추가
|
|
|
|
---
|
|
|
|
### 현재 검증 메모
|
|
|
|
- `dotnet build TaxBaik.sln` 성공 (2026-06-27 기준, 경고 0 오류 0)
|
|
- 최종 배포 커밋: `9c96f15` (FAQ 관리 기능)
|
|
- WBS-MKT-01/02/03/04 구현 완료, 배포 후 시각 검증 필요
|
|
- WBS-UX-03/04 구현 완료
|
|
- WBS-CRM-01/02/03/04/05 구현 완료 (배포 후 검증 필요)
|
|
- WBS-CRM-06/07/08 (텔레그램·포털·소셜 로그인) Phase 3 미착수
|
|
|
|
---
|
|
|
|
## ── 홈페이지 · 어드민 · 포털 프리미엄 UX/UI 개편 (2026-06-30) ──────────────────
|
|
|
|
## WBS-UX-05 홈페이지 프리미엄 UI 및 마이크로 인터랙션
|
|
|
|
목표: 홈페이지 디자인을 극도로 모던하고 신뢰성 있는 프리미엄 스타일로 전면 개편한다.
|
|
|
|
성공 기준:
|
|
- Hero 섹션에 유려한 배경 그라데이션 및 부드러운 CSS 애니메이션 효과 적용
|
|
- 서비스 카드에 섀도우 및 보더 트랜지션, 골드/그린 그라데이션 호버 이펙트 추가
|
|
- 신뢰도 스트립 카드에 입체감 및 돋보이는 레이아웃 설계
|
|
- Noto Sans KR 외에 Outfit/Inter 등의 보조 영문 폰트 결합으로 타이포그래피 고급화
|
|
|
|
Todo:
|
|
- [x] `site.css` 내 Hero 섹션 그라데이션 및 CSS 애니메이션 보강
|
|
- [x] 서비스 카드 및 신뢰도 스트립 컴포넌트 프리미엄 스타일로 개편
|
|
- [x] 홈페이지 폰트 스택 확장 및 메인 레이아웃 적용
|
|
|
|
## WBS-PORTAL-01 고객 포털 UI/UX 고도화 및 글래스모피즘
|
|
|
|
목표: 고객 마이 포털 화면을 미려하고 현대적인 글래스모피즘 디자인으로 개편하여 이용 가치를 극대화한다.
|
|
|
|
성공 기준:
|
|
- 포털 메인 대시보드 카드를 Glassmorphism 스타일(blur, semi-transparent border)로 변경
|
|
- 세무 신고 현황 테이블 및 상담 이력 타임라인 컴포넌트의 모던 디자인화
|
|
|
|
Todo:
|
|
- [x] `site.css` 내 포털 전용 모던 글래스모피즘 클래스군 추가
|
|
- [x] `Portal/Index.cshtml` 레이아웃 및 컴포넌트 UI 고도화
|
|
|
|
## WBS-MAINT-02 코드 품질 및 경고 결함 차단
|
|
|
|
목표: 빌드 컴파일 타임 경고(Warnings)를 0으로 유지하여 미래 코드 결함을 방지한다.
|
|
|
|
성공 기준:
|
|
- `dotnet build` 수행 시 경고 0개 달성
|
|
|
|
Todo:
|
|
- [x] `CustomAuthenticationStateProvider.cs` Nullable 경고 수정
|
|
- [x] `Dashboard.razor` 미사용 변수 제거 및 UI 연계 바인딩 처리
|
|
|