# 사내 지원 플랫폼 사용자별 사용 시나리오

## 1. 문서 목적

본 문서는 [architecture_secretary_sso_components_v2.md](./architecture_secretary_sso_components_v2.md)에서 정의한 통합 아키텍처를 바탕으로, 사용자 유형별 실제 사용 시나리오를 정리한 문서임.

핵심 목적은 다음과 같음.

- 어떤 사용자가 어떤 경로로 진입하는지 명확히 구분함.
- BARON-SSO, 우리 시스템, ABC User Feedback가 각각 어느 시점에 개입하는지 흐름으로 표현함.
- 조회 결과가 보이는 지점과 처리 결과가 저장되는 지점을 시나리오별로 시각화함.

## 2. 사용자 유형 정의

| 사용자 유형 | 주요 진입 경로 | 주요 목적 | 로그인 후 주 분기 화면 |
| --- | --- | --- | --- |
| 인트라넷 일반 사용자 | 인트라넷 포털 또는 공통 업무 진입점 | 물품 신청, 도서 신청, 차량 신청, 사내 문의 등록 | 사용자 피드백 작성 페이지, 내 피드백 목록/상세, ABC 조회 화면 |
| S/W 프로그램 사용자 | 각 S/W 프로그램 메뉴 또는 공통 업무 진입점 | 앱 전용 Q&A 등록, 장애/문의 접수 | 사용자 피드백 작성 페이지, 내 문의 목록/상세, ABC 조회 화면 |
| 승인자 | 인트라넷 또는 운영 포털의 공통 진입점 | 승인 대기 건 검토, 승인/반려 처리 | 승인 대상 목록, 피드백 상세, ABC 관리자 UI |
| 운영 담당자 | 운영 메뉴 또는 공통 진입점 | 전체 티켓 관리, 상태 변경, 후속 조치, 공지/알림 | 운영 목록/상세, 이슈 관리, ABC 관리자 UI |

## 3. 사용 기술 스택

| 영역 | 사용 기술 | 역할 |
| --- | --- | --- |
| 인증/사용자 식별 | BARON-SSO, OAuth 2.0, OIDC | 사용자 로그인, `user_id`, `tenant_id`, 토큰 발급 |
| 사용자/운영 화면 | 사용자 피드백 작성 페이지, ABC User Feedback Web Frontend | 사용자 입력, 목록 조회, 상세 확인, 이슈 관리, 관리자 설정 |
| 제어 백엔드 | FastAPI | `workspace` 매핑, 권한 분기, 승인 워크플로우, 외부 연동 orchestration |
| 제어 데이터 저장소 | 자체 DB (예: MySQL) | `support_tickets`, `request_approvals`, 매핑, 운영 이력 저장 |
| 원본 피드백 저장소 | ABC User Feedback | 피드백 원문, 첨부, 채널, 필드, 이슈 관리 |
| 외부 알림 연동 | Naver Works API, SMS Gateway | 승인/반려/처리 결과 알림 |
| 업무 시스템 연동 | 자산 API, 차량 API, 조직도 API 등 | 후속 처리 자동화 및 업무 데이터 조회 |

기술 스택의 책임 분리는 다음과 같음.

- BARON-SSO는 인증과 조직 식별의 기준 시스템임.
- 사용자와 승인자, 운영 담당자는 동일한 인증 상태에서 접속하고, 로그인 후에는 역할과 업무 컨텍스트에 따라 화면이 분기됨.
- 사용자 피드백 작성 페이지는 일반 사용자의 직접 입력 경험을 담당함.
- ABC User Feedback Web Frontend는 원문 조회와 운영 담당자용 관리 화면을 담당함.
- FastAPI는 ABC와 자체 DB 사이에서 정책과 절차를 제어하는 핵심 백엔드임.
- ABC User Feedback는 게시글 원본과 운영용 채널/이슈 관리 기능을 담당함.

## 4. 사용자별 시나리오 맵

```mermaid
flowchart LR
    classDef result fill:#eef6ff,stroke:#1d4ed8,stroke-width:1.5px,color:#0f172a;
    classDef control fill:#f8fafc,stroke:#334155,stroke-width:1.2px,color:#111827;
    classDef external fill:#fff7ed,stroke:#c2410c,stroke-width:1.2px,color:#111827;

    U1[인트라넷 일반 사용자]
    U2[S/W 프로그램 사용자]
    U3[승인자]
    U4[운영 담당자]

    ENTRY[공통 업무 진입점\n포털 / 앱 / 운영 메뉴]:::result
    SSO[BARON-SSO]:::external
    G1[우리 시스템\n세션 확인 / 역할 판정 / workspace 매핑]:::control
    UI1[사용자 화면 분기
작성 / 내 목록 / 내 상세]
:::result
    UI2[운영 화면 분기
승인 목록 / 운영 목록 / 상세]
:::result
    UI3[ABC User Feedback 관리자 UI]:::result
    APP[우리 시스템\n권한/워크플로우/매핑]:::control
    ABC[ABC User Feedback\n원본 저장소]:::result

    U1 -->|공통 진입| ENTRY
    U2 -->|공통 진입| ENTRY
    U3 -->|공통 진입| ENTRY
    U4 -->|공통 진입| ENTRY

    ENTRY -->|로그인 세션 확인 또는 SSO 요청| SSO
    SSO -->|user_id, tenant_id, role context 반환| G1

    G1 -->|일반 사용자 + 신청/문의 컨텍스트| UI1
    G1 -->|승인자/운영자 + 운영 컨텍스트| UI2
    UI2 -->|필요 시 ABC 관리자 기능 진입| UI3

    UI1 -->|등록/조회 요청| APP
    UI2 -->|승인/운영 요청| APP
    UI3 -->|원문/이슈 관리 요청| APP
    APP -->|원본 데이터 저장/조회| ABC
    APP -->|상태/승인/권한 기록| APP
```

## 5. 시나리오 1: 인트라넷 일반 사용자의 신청 등록

### 5.1 시나리오 설명

인트라넷 일반 사용자는 물품 신청, 도서 신청, 차량 신청, 사내 문의와 같은 업무를 등록하는 주체임. 이 사용자는 우리 시스템이 직접 구현한 사용자 피드백 작성 페이지에서 신청 내용을 입력하고, 우리 시스템은 그 뒤의 승인 정책과 처리 상태를 제어하며 원문은 ABC에 저장함.

### 5.2 주요 단계

1. 사용자가 인트라넷 포털에서 특정 지원 서비스를 선택함.
2. 사용자 피드백 작성 페이지가 BARON-SSO 인증을 수행하고 `user_id`, `tenant_id`를 확보함.
3. 우리 시스템이 진입한 서비스 코드를 `workspace`로 매핑하고, 해당 사용자를 적절한 ABC 프로젝트/채널로 연결함.
4. 사용자는 우리 시스템이 직접 구현한 입력 화면에서 신청 내용을 작성함.
5. 사용자가 신청서를 제출하면 ABC가 원본 피드백 데이터를 저장함.
6. 우리 시스템은 생성된 `feedback_id`를 내부 티켓과 매핑하고 상태, 승인 필요 여부, 운영 메타데이터를 저장함.
7. 사용자와 담당자는 ABC UI에서 원문을 보고, 우리 시스템은 상태와 승인 결과를 동기화함.

### 5.3 Flow

```mermaid
flowchart LR
    classDef result fill:#eef6ff,stroke:#1d4ed8,stroke-width:1.5px,color:#0f172a;
    classDef control fill:#f8fafc,stroke:#334155,stroke-width:1.2px,color:#111827;
    classDef external fill:#fff7ed,stroke:#c2410c,stroke-width:1.2px,color:#111827;

    U[인트라넷 일반 사용자]
    P[인트라넷 포털]
    SSO[BARON-SSO]:::external
    UI[사용자 피드백 작성 페이지
우리 시스템]:::result
    M1[우리 시스템\nworkspace 매핑 / 접근 제어]:::control
    M3[우리 시스템\n티켓 메타데이터 저장]:::control
    A1[ABC Feedback 저장 처리]:::control
    A2[ABC 원본 데이터 저장소]:::result
    D1[우리 DB\nsupport_tickets / approvals / mappings]:::result
    R1[ABC 접수 결과 화면\n내 신청 내역]:::result

    U -->|지원 서비스 선택| P
    P -->|신청 화면 호출| UI
    UI -->|SSO 인증 요청| SSO
    SSO -->|user_id, tenant_id 반환| UI
    UI -->|서비스 코드 전달| M1
    M1 -->|workspace 기반 프로젝트/채널 연결| UI
    UI -->|입력 화면 작성 및 제출| A1
    A1 -->|본문/필드값 저장| A2
    A2 -->|feedback_id 생성 이벤트 전달| M3
    M3 -->|상태/승인여부/매핑 기록| D1
    A2 -->|원문 조회 제공| R1
    A2 -->|원본 접수 데이터 확보| R1
```

## 6. 시나리오 2: S/W 프로그램 사용자의 Q&A 등록

### 6.1 시나리오 설명

S/W 프로그램 사용자는 특정 앱 내부의 도움말 또는 지원 메뉴를 통해 진입하며, 본인이 사용 중인 앱에 대응하는 전용 사용자 피드백 작성 페이지로 연결됨. 우리 시스템은 이를 적절한 ABC Q&A 채널에 매핑하여 원문을 저장함.

### 6.2 주요 단계

1. 사용자가 특정 S/W 프로그램 내 지원 메뉴를 클릭함.
2. 앱이 `app_id` 또는 서비스 식별자를 포함한 상태로 사용자 피드백 작성 페이지 진입 URL을 호출함.
3. BARON-SSO 인증 후 우리 시스템이 해당 식별자를 `workspace`와 ABC 채널로 매핑함.
4. 사용자는 우리 시스템의 사용자 피드백 작성 페이지에서 앱 전용 문의 폼을 작성함.
5. 사용자가 문의를 등록하면 ABC에 원본 피드백이 저장됨.
6. 우리 시스템은 내부 티켓과 앱-채널 매핑 정보를 함께 저장함.
7. 사용자는 필요 시 ABC 조회 화면에서 본인 문의 원문을 확인하고, 우리 시스템은 처리 상태를 별도 메타데이터로 관리함.

### 6.3 Flow

```mermaid
flowchart LR
    classDef result fill:#eef6ff,stroke:#1d4ed8,stroke-width:1.5px,color:#0f172a;
    classDef control fill:#f8fafc,stroke:#334155,stroke-width:1.2px,color:#111827;
    classDef external fill:#fff7ed,stroke:#c2410c,stroke-width:1.2px,color:#111827;

    U[S/W 프로그램 사용자]
    APP0[각 S/W 프로그램]
    SSO[BARON-SSO]:::external
    UI[사용자 피드백 작성 페이지
우리 시스템]:::result
    B1[우리 시스템\napp_id -> workspace 매핑]:::control
    B2[우리 시스템\n권한/채널 판정]:::control
    A1[ABC 채널/필드 구성]:::result
    A2[ABC Feedback 저장 처리]:::control
    A3[ABC 원본 Q&A 저장소]:::result
    D1[우리 DB\nworkspace_channel_mappings\nsupport_tickets]:::result
    R1[ABC 문의 등록 결과\n내 문의 목록]:::result

    U -->|지원 메뉴 클릭| APP0
    APP0 -->|app_id 포함 화면 호출| UI
    UI -->|SSO 인증 요청| SSO
    SSO -->|사용자 식별 정보 반환| UI
    UI -->|app_id 전달| B1
    B1 -->|workspace 및 채널 결정| B2
    B2 -->|작성 페이지용 채널 매핑 전달| UI
    B2 -->|채널 필드 정의 참조| A1
    UI -->|문의 등록 제출| A2
    A2 -->|Q&A 원본 저장| A3
    B2 -->|내부 티켓 및 매핑 기록| D1
    A3 -->|문의 원본 표시| R1
    D1 -->|처리 상태 표시| R1
```

## 7. 시나리오 3: 승인자의 승인/반려 처리

### 7.1 시나리오 설명

승인자는 일반 사용자와 동일한 로그인 상태에서 접속한 뒤, 역할과 업무 컨텍스트에 따라 승인 화면으로 분기되어 원문과 이슈를 확인하면서 우리 시스템이 제어하는 승인 정책에 따라 승인 여부를 결정하는 역할임. 승인 결과는 상태 변화와 알림 발송으로 이어짐.

### 7.2 주요 단계

1. 승인자가 공통 업무 진입점에서 승인 업무로 접속함.
2. 로그인 세션 확인 또는 BARON-SSO 인증 후 우리 시스템이 승인 권한과 ABC 프로젝트 접근 권한을 검증 및 동기화함.
3. 승인자는 역할에 따라 분기된 운영 화면 또는 ABC 관리자 UI에서 승인 대상 피드백과 연결 이슈를 조회함.
4. 승인자가 승인 또는 반려 판단을 수행하면 우리 시스템이 해당 결과를 내부 승인 로직에 반영함.
5. 우리 시스템이 `request_approvals`와 티켓 상태를 갱신함.
6. 필요 시 메신저 또는 SMS 알림을 발송함.
7. 사용자와 운영자는 분기된 조회 화면과 ABC UI, 내부 상태 동기화 결과를 기준으로 처리 결과를 확인함.

### 7.3 Flow

```mermaid
flowchart LR
    classDef result fill:#eef6ff,stroke:#1d4ed8,stroke-width:1.5px,color:#0f172a;
    classDef control fill:#f8fafc,stroke:#334155,stroke-width:1.2px,color:#111827;
    classDef external fill:#fff7ed,stroke:#c2410c,stroke-width:1.2px,color:#111827;

    U[승인자]
    UI[승인 화면 분기\n우리 시스템 운영 화면 / ABC 관리자 UI]:::result
    SSO[BARON-SSO]:::external
    C1[우리 시스템\n승인 권한 판정 / 멤버 동기화]:::control
    C2[ABC 피드백 / 이슈 조회]:::control
    C3[우리 시스템\n승인/반려 처리]:::control
    D1[우리 DB\nrequest_approvals / support_tickets]:::result
    X1[Naver Works / SMS]:::external
    R1[ABC 결과 화면\n처리 상태]:::result

    U -->|공통 진입 후 승인 업무 선택| UI
    UI -->|세션 확인 또는 SSO 인증 요청| SSO
    SSO -->|user_id, role context 반환| UI
    UI -->|승인 대상 조회 요청| C1
    C1 -->|권한 확인 후 피드백/이슈 조회| C2
    C2 -->|승인 대상 데이터 반환| UI
    UI -->|승인/반려 판단 수행| C3
    C3 -->|승인 이력 및 상태 갱신| D1
    C3 -->|결과 알림 발송 요청| X1
    D1 -->|처리 결과 반영| R1
```

## 8. 시나리오 4: 운영 담당자의 후속 조치 및 이슈 관리

### 8.1 시나리오 설명

운영 담당자는 일반 사용자와 동일한 로그인 상태에서 접속한 뒤, 역할과 업무 컨텍스트에 따라 운영 화면으로 분기되어 접수 건을 실제 처리 단계로 연결하는 역할을 담당함. 예를 들어 자산 배정, 차량 배차, 원격지원, Q&A 이슈화, 상태 종료 처리 등을 수행함.

### 8.2 주요 단계

1. 운영 담당자가 공통 업무 진입점에서 운영 업무로 접속함.
2. 로그인 세션 확인 또는 BARON-SSO 인증 후 우리 시스템이 운영 권한과 조회 가능한 `workspace` 범위를 판정함.
3. 분기된 운영 화면 또는 ABC 관리자 UI에서 전체 피드백 또는 특정 `workspace`에 대응되는 채널을 조회함.
4. 우리 시스템이 상태, 우선순위, 요청 유형, 담당자 기준 메타데이터를 ABC 데이터와 동기화함.
5. 운영 담당자가 특정 피드백을 열어 원본 데이터와 승인 이력을 함께 확인함.
6. 필요 시 ABC 원문에 대응되는 이슈를 생성하거나 연결함.
7. 우리 시스템이 자산/차량/원격지원/알림 등의 확장 프로세스를 수행함.
8. 처리 완료 후 내부 상태를 종료하거나 추가 조치 필요 상태로 갱신하고, 필요한 결과를 ABC에 반영함.
9. 사용자와 운영자는 분기된 조회 화면과 ABC UI를 기준으로 최신 원문과 처리 상태를 확인함.

### 8.3 Flow

```mermaid
flowchart LR
    classDef result fill:#eef6ff,stroke:#1d4ed8,stroke-width:1.5px,color:#0f172a;
    classDef control fill:#f8fafc,stroke:#334155,stroke-width:1.2px,color:#111827;
    classDef external fill:#fff7ed,stroke:#c2410c,stroke-width:1.2px,color:#111827;

    U[운영 담당자]
    UI[운영 화면 분기\n우리 시스템 운영 화면 / ABC 관리자 UI]:::result
    C1[우리 시스템\n목록 필터/상태 조회]:::control
    C2[우리 시스템\n후속 조치 엔진]:::control
    C3[우리 시스템\n이슈/알림/자산 연계]:::control
    D1[우리 DB\n티켓/승인/운영 이력]:::result
    A1[ABC 원본 데이터]:::result
    A2[ABC 이슈/피드백 연결]:::control
    X1[자산/차량/외부 API]:::external
    R1[ABC 운영 결과 화면\n최신 상태]:::result

    U -->|공통 진입 후 운영 업무 선택| UI
    UI -->|조건별 검색 요청| C1
    C1 -->|티켓/상태/담당자 조회| D1
    D1 -->|목록 및 상세 데이터 반환| UI
    UI -->|원문 확인 요청| A1
    UI -->|후속 조치 실행| C2
    C2 -->|이슈 연결 또는 상태 갱신| A2
    C2 -->|운영 이력 저장| D1
    C3 -->|자산/차량/알림 API 호출| X1
    D1 -->|최신 결과 집계| R1
    A2 -->|원본 연계 상태 반영| R1
```

## 9. 권한별 핵심 차이

| 구분 | 일반 사용자 | S/W 사용자 | 승인자 | 운영 담당자 |
| --- | --- | --- | --- | --- |
| 인증 | BARON-SSO | BARON-SSO | BARON-SSO | BARON-SSO |
| 진입 기준 | 서비스 메뉴 | 앱 메뉴 | 승인 업무 메뉴 | 운영 메뉴 |
| 주 작업 | 신청 등록/조회 | 문의 등록/조회 | 승인/반려 | 상태 관리/후속 조치 |
| ABC 직접 사용 여부 | 부분 사용 | 부분 사용 | 직접 사용 | 직접 사용 |
| 우리 시스템 의존도 | 높음 | 높음 | 높음 | 높음 |
| 핵심 저장 위치 | ABC + 우리 DB | ABC + 우리 DB | ABC + 우리 DB | ABC + 우리 DB |

## 10. 문서 활용 가이드

- 화면 설계 시에는 일반 사용자용 작성 화면은 우리 시스템에서 직접 구현하고, 운영/관리 화면은 ABC 기본 UI를 우선 활용함.
- API 설계 시에는 어떤 단계가 우리 시스템 API인지, 어떤 단계가 ABC 연동인지 분리해서 정의함.
- 권한 설계 시에는 `workspace`, `role`, `approval permission`, `operator permission`을 별도 축으로 설계함.
- 운영 정책 수립 시에는 승인자와 운영 담당자의 역할이 섞이지 않도록 본 문서의 시나리오를 기준으로 책임 범위를 정리함.

## 11. 시나리오 기준 ABC User Feedback 활용 기능 및 API

### 11.1 활용 원칙

- 최종 사용자 인증은 BARON-SSO를 기준으로 하고, ABC의 사용자 인증 체계는 운영용 또는 관리용 보조 수단으로만 사용함.
- 일반 사용자는 우리 시스템의 사용자 피드백 작성 페이지를 사용하고, 운영 담당자는 ABC User Feedback UI를 직접 사용함.
- 우리 시스템은 사용자 입력 화면, ABC UI 진입 제어, 권한 동기화, 상태/승인 메타데이터 관리에 집중함.
- 따라서 ABC API는 크게 `프로젝트/채널 사전 구성`, `원본 피드백 저장/조회`, `이슈 관리`, `멤버/역할 동기화`, `운영 자동화` 용도로 사용함.

### 11.2 시나리오별 ABC 활용 기능

| 시나리오 | ABC에서 활용할 기능 | 실제 활용 API | 비고 |
| --- | --- | --- | --- |
| 인트라넷 일반 사용자 신청 등록 | 신청 원문 저장 | `POST /api/projects/:projectId/channels/:channelId/feedbacks` | 우리 작성 페이지에서 API 호출로 ABC 원문 저장 |
| 인트라넷 일반 사용자 신청 등록 | 이미지 포함 신청 저장 | `POST /api/projects/:projectId/channels/:channelId/feedbacks-with-images` | 첨부 업로드 자동화가 필요한 경우 사용 |
| S/W 프로그램 사용자 Q&A 등록 | 앱 전용 문의 원문 저장 | `POST /api/projects/:projectId/channels/:channelId/feedbacks` | 우리 작성 페이지에서 `workspace`와 채널 매핑 후 API 호출 |
| 승인자 승인/반려 | 원문 참조용 피드백 목록 조회 | `POST /api/admin/projects/:projectId/channels/:channelId/feedbacks/search` | ABC 관리자 UI와 병행 사용 |
| 운영 담당자 후속 조치 | 이슈 생성 | `POST /api/admin/projects/:projectId/issues` | 문의를 이슈로 승격할 때 사용 |
| 운영 담당자 후속 조치 | 피드백-이슈 연결 | `POST /api/admin/projects/:projectId/channels/:channelId/feedbacks/:feedbackId/issue/:issueId` | 문의와 처리 이슈 연결 |
| 운영 담당자 후속 조치 | 이슈 목록 조회 | `POST /api/admin/projects/:projectId/issues/search` | 현황판, 대시보드 구성에 사용 |
| 운영 담당자 후속 조치 | 이슈 상세 조회 | `GET /api/admin/projects/:projectId/issues/:issueId` | 연결된 피드백 수, 상태 확인 |
| 운영 담당자 후속 조치 | 피드백 수정 | `PUT /api/admin/projects/:projectId/channels/:channelId/feedbacks/:feedbackId` | 원문 보정 또는 메타 필드 갱신 |
| 운영 담당자 후속 조치 | 피드백 내보내기 | `POST /api/admin/projects/:projectId/channels/:channelId/feedbacks/export` | 운영 보고용 다운로드 |
| 운영 환경 준비 | 프로젝트 생성/조회 | `POST /api/admin/projects`, `GET /api/admin/projects` | 서비스 단위 프로젝트 생성 |
| 운영 환경 준비 | 채널 생성/조회 | `POST /api/admin/projects/:projectId/channels/`, `GET /api/admin/projects/:projectId/channels/` | 서비스별 접수 채널 구성 |
| 운영 환경 준비 | 채널 필드 관리 | `PUT /api/admin/projects/:projectId/channels/:channelId/fields` | 신청서 항목과 채널 필드 정합 |
| 운영 권한 구성 | 프로젝트 멤버 관리 | `POST /api/admin/projects/:projectId/members`, `POST /api/admin/projects/:projectId/members/search` | 운영자/담당자 접근 권한 부여 |
| 운영 권한 구성 | 역할 관리 | `GET /api/admin/projects/:projectId/roles/`, `POST /api/admin/projects/:projectId/roles/` | 프로젝트별 역할 정의 |

일반 사용자와 운영 담당자의 일상 사용 흐름은 ABC UI를 우선 사용하고, 위 API는 다음 목적에서 활용함.

- 초기 프로젝트/채널/역할 셋업 자동화
- BARON-SSO 사용자와 ABC 멤버 구조 동기화
- 내부 상태값과 ABC 피드백/이슈 연계 자동화
- 대량 등록, 이관, 배치 처리, 외부 시스템 연동

### 11.3 ABC에서 주로 재사용할 기능 묶음

| 기능 묶음 | 재사용 목적 | 설명 |
| --- | --- | --- |
| Feedback 저장 기능 | 문의/신청 원문 저장 | 제목, 본문, 필드값, 이미지 등 원본 데이터 보존 |
| Channel/Field 관리 기능 | 서비스별 입력 스키마 구성 | 채널별 신청서 항목과 커스텀 필드 유지 |
| Issue 관리 기능 | 운영 후속 조치 기록 | 피드백을 운영 이슈와 연결하고 상태 추적 |
| Project/Member/Role 관리 기능 | 운영 구조 설정 | 프로젝트, 채널, 담당자, 권한 체계 운영 |
| Export 기능 | 운영 보고/분석 | 피드백 데이터 다운로드 및 외부 분석 활용 |

## 12. 우리가 직접 구현해야 하는 부분

### 12.1 구현 원칙

- ABC는 원본 데이터와 관리자 기능을 담당하고, 실제 서비스 경험은 우리 시스템이 완성함.
- 일반 사용자가 사용하는 사용자 피드백 작성 페이지는 우리 시스템에서 직접 구현하고, 운영/관리 기능은 ABC UI를 최대한 활용함.
- 따라서 인증, 권한, 워크플로우, 업무 상태, 외부 시스템 연계뿐 아니라 일반 사용자 입력 화면도 직접 구현 범위에 포함됨.

### 12.2 직접 구현 범위 요약

| 구현 영역 | 우리가 직접 구현할 내용 | ABC만으로 부족한 이유 |
| --- | --- | --- |
| SSO 연동 | BARON-SSO 로그인, 토큰 검증, `user_id`, `tenant_id` 세션 처리 | ABC 인증은 우리 조직의 통합 인증 기준이 아님 |
| 진입 경로 해석 | `app_id`, `service_type_id`, 메뉴 코드 등을 `workspace`로 매핑 | ABC는 외부 서비스 진입 맥락을 이해하지 못함 |
| 사용자 피드백 작성 화면 | 일반 사용자용 입력 폼, 유효성 검사, 제출 완료 UX, ABC 저장 API 호출 | ABC 기본 화면만으로는 서비스별 사용자 경험과 진입 컨텍스트를 충분히 통제하기 어려움 |
| ABC 진입 제어 | 사용자를 올바른 프로젝트/채널/화면으로 연결하는 리다이렉트 및 딥링크 로직 | ABC는 외부 포털 메뉴 체계와 직접 연결되지 않음 |
| 채널/필드 표준화 | 서비스별 필드 템플릿, 채널 생성 규칙, 운영 정책 자동화 | ABC만으로는 사내 표준 신청서 체계를 일관되게 강제하기 어려움 |
| 내부 티켓 모델 | `support_tickets` 기반 상태, 우선순위, 업무 유형, 담당자 관리 | ABC 피드백 원문만으로 운영 제어 메타데이터를 관리하기 부족함 |
| 승인 워크플로우 | `request_approvals`, 승인선, 승인/반려 이력, 다단계 결재 | 사내 결재 정책은 ABC 기본 기능 범위를 넘음 |
| 권한 동기화 | 사용자별 조회 범위, 승인 권한, 운영 권한, 워크스페이스별 접근 제어를 ABC 멤버/역할과 연동 | 프로젝트/멤버 권한만으로 세밀한 업무 분기 어려움 |
| 원본-내부 매핑 | ABC `feedback_id`와 내부 티켓 ID, 기존 시스템 ID 매핑 | 이관 및 통합 운영을 위한 별도 식별자 체계 필요 |
| 외부 연동 | 자산, 차량, 조직도, 메신저, SMS, 기타 사내 API 연계 | ABC는 사내 업무 시스템 orchestration 역할이 아님 |
| 알림 정책 | 상태 변경별 알림 템플릿, 채널 선택, 재발송 규칙 | 사내 정책 기반 알림 제어가 필요함 |
| 집계/리포팅 | 업무 유형별 KPI, 승인 지연, 처리 SLA, 부서별 통계 | ABC 통계는 일반 피드백 관점이라 업무형 리포트에 한계가 있음 |
| 마이그레이션 도구 | 기존 게시글, 첨부, 댓글, 분류 정보 이관 및 검증 | 기존 시스템 식별자와의 추적 관리가 필요함 |

### 12.3 시나리오별 구현 책임 정리

| 시나리오 | ABC가 담당하는 부분 | 우리가 직접 구현하는 부분 |
| --- | --- | --- |
| 인트라넷 일반 사용자 신청 등록 | 피드백 원문 저장, 첨부 저장 | SSO 로그인, 사용자 피드백 작성 페이지 구현, 서비스 진입 제어, 채널 연결, 신청 상태 저장, 승인선 생성 |
| S/W 프로그램 사용자 Q&A 등록 | 앱 전용 채널에 문의 원문 저장, 목록/상세 UI 제공 | 사용자 피드백 작성 페이지 구현, 앱 식별자 해석, `workspace` 매핑, 사용자 권한 판정, ABC 진입 URL 제어, 상태 메타데이터 관리 |
| 승인자 승인/반려 | 피드백/이슈 조회 UI 제공 | 승인 규칙, 승인 이력, 결과 알림, 상태 전이, ABC 멤버 권한 동기화 |
| 운영 담당자 후속 조치 | 이슈 생성, 피드백-이슈 연결, 원문 검색/수정 UI 제공 | 담당자 배정, 자산/차량 후속 처리, SLA 추적, 내부 상태 관리, 외부 API 실행 |
| 운영 환경 준비 | 프로젝트/채널/필드/멤버/역할 관리 API와 관리자 UI | 서비스 구조 설계, 채널 정책 표준화, 권한 모델링, 셋업 자동화 |

### 12.4 구현 우선순위 제안

1. `BARON-SSO 연동 + 사용자 피드백 작성 페이지 + workspace 매핑 + ABC 진입 제어`를 먼저 구현해야 함.
2. 그 다음 `support_tickets + approvals + abc_feedback_mappings` 중심의 내부 제어 DB를 구축해야 함.
3. 이후 `ABC 멤버/역할 동기화 + 승인 워크플로우 + 외부 연동`을 확장하는 순서가 가장 현실적임.
4. 마지막으로 `마이그레이션 도구 + 통계/리포트 + 셋업 자동화`를 붙여 운영 전환을 마무리하는 구성이 적절함.

## 13. 사용자 작성부터 이슈 생성 및 처리, 답변 입력까지의 시스템 데이터 처리 모식도

### 13.1 목적

이 절은 일반 사용자가 사용자 피드백 작성 페이지에서 문의를 등록한 뒤, 담당자가 이슈를 생성하고 처리한 후 답변 또는 처리 결과를 입력할 때까지 데이터가 어느 시스템에 저장되고 어떻게 연결되는지를 한 번에 보여주기 위한 보조 모식도임.

핵심 확인 포인트는 다음과 같음.

- 일반 사용자는 보통 BARON-SSO 인증을 마치고, 우리 시스템이 접근 권한과 연결 채널을 판정한 뒤 작성 페이지에 진입함.
- 운영 담당자와 관리자도 동일하게 BARON-SSO 인증 또는 세션 확인을 거친 뒤, 역할에 맞는 운영 화면 또는 관리자 화면으로 분기 진입함.
- 사용자 입력 원문은 ABC User Feedback에 저장됨.
- 제어용 상태와 승인/운영 메타데이터는 우리 DB에 저장됨.
- 담당자 이슈 생성과 처리 이력은 ABC 이슈와 우리 DB가 함께 관리함.
- 최종 답변 또는 처리 결과는 사용자에게 보이는 원문/상태 화면으로 다시 동기화됨.

### 13.2 단계별 데이터 처리 요약

| 단계 | 수행 주체 | 주요 처리 | 주요 저장 위치 |
| --- | --- | --- | --- |
| 1 | 일반 사용자 | 신청/문의 메뉴로 진입하고 보호된 작성 페이지 접근을 시도 | 진입 전 상태는 포털 또는 앱 컨텍스트 |
| 2 | BARON-SSO + 우리 시스템 | 로그인 세션 확인 또는 SSO 인증 수행, `user_id`, `tenant_id` 확보 | 우리 시스템 세션 / 인증 컨텍스트 |
| 3 | 우리 시스템 | `workspace`, 채널, 권한, 요청 유형을 판정하고 작성 가능한 대상인지 검증 | 우리 시스템 제어 로직 |
| 4 | 일반 사용자 | 권한이 확인된 작성 페이지에서 문의/신청 내용을 작성하고 제출 | 제출 전 일시 상태는 우리 시스템 화면 메모리 |
| 5 | 우리 시스템 | ABC 저장 API 호출 | 우리 시스템 제어 로직 |
| 6 | ABC User Feedback | 피드백 원문, 필드값, 첨부, 생성된 `feedback_id` 저장 | ABC Feedback 원본 저장소 |
| 7 | 우리 시스템 | `feedback_id`를 받아 내부 티켓, 승인 필요 여부, 상태값 생성 | 우리 DB `support_tickets`, `abc_feedback_mappings` |
| 8 | 운영 담당자/관리자 | 공통 업무 진입점 또는 운영 메뉴로 접속하고 보호된 운영 화면 접근을 시도 | 운영 포털 또는 운영 메뉴 컨텍스트 |
| 9 | BARON-SSO + 우리 시스템 | 로그인 세션 확인 또는 SSO 인증 수행 후 운영 권한, 관리자 권한, 조회 가능한 `workspace` 범위 판정 | 우리 시스템 세션 / 권한 컨텍스트 |
| 10 | 승인자/담당자/관리자 | 역할에 따라 분기된 운영 화면 또는 ABC 관리자 UI에서 승인, 조회, 이슈 작업 수행 | 우리 시스템 운영 화면 + ABC 관리자 UI |
| 11 | 승인자/담당자 | 승인 또는 반려 판단 | 우리 DB `request_approvals`, `support_tickets` |
| 12 | 담당자/관리자 | ABC 관리자 UI에서 이슈 생성 및 피드백-이슈 연결 | ABC Issue, ABC Feedback-Issue 연결 정보 |
| 13 | 우리 시스템 | 담당자 배정, 처리 메모, 외부 연동 결과, SLA 상태 저장 | 우리 DB `support_tickets`, 운영 이력, 알림 이력 |
| 14 | 담당자/관리자 | 처리 결과 또는 답변 입력, 필요 시 원문/상태 반영 | ABC 원문 표시 정보 + 우리 DB 상태값 |
| 15 | 일반 사용자 | ABC 조회 화면 또는 우리 시스템 조회 화면에서 처리 결과 확인 | ABC 원문 + 우리 DB 상태 동기화 결과 |

### 13.3 End-to-End 데이터 흐름 모식도

```mermaid
flowchart LR
    classDef result fill:#eef6ff,stroke:#1d4ed8,stroke-width:1.5px,color:#0f172a;
    classDef control fill:#f8fafc,stroke:#334155,stroke-width:1.2px,color:#111827;
    classDef external fill:#fff7ed,stroke:#c2410c,stroke-width:1.2px,color:#111827;

    U[일반 사용자]
    OP[운영 담당자]
    AD[관리자/승인자]
    E1[신청/문의 메뉴 진입\n포털 또는 앱]:::result
    E2[운영/관리 메뉴 진입\n운영 포털 또는 관리자 메뉴]:::result
    A0[BARON-SSO 인증 / 세션 확인]:::external
    G0[우리 시스템\n사용자/운영자/관리자 권한 판정\nworkspace / 채널 / 역할 결정]:::control
    W[사용자 화면 분기\n작성 / 내 목록 / 내 상세]:::result
    A1[ABC Feedback 저장 API]:::control
    A2[ABC 원본 피드백 저장소\n본문/필드값/첨부/feedback_id]:::result
    D1[우리 DB\nsupport_tickets\nabc_feedback_mappings]:::result
    O0[운영 화면 분기\n운영 목록 / 승인 목록 / 상세]:::result
    AP[승인 처리 엔진\n승인/반려/상태 전이]:::control
    D2[우리 DB\nrequest_approvals\nstatus history]:::result
    O1[ABC 관리자 UI]:::result
    I1[ABC Issue 저장소\nissue / feedback-issue link]:::result
    O2[우리 시스템\n담당자 배정/처리 메모/외부 연동]:::control
    D3[우리 DB\n운영 이력 / 알림 / SLA / 후속조치]:::result
    X1[자산/차량/Naver Works/SMS]:::external
    A3[결과 반영 화면\nABC 원문 + 우리 시스템 상태 동기화]:::result
    R1[최종 사용자 조회 화면]:::result

    U -->|신청/문의 메뉴 선택| E1
    OP -->|운영 업무 진입| E2
    AD -->|관리/승인 업무 진입| E2
    E1 -->|로그인 또는 기존 세션 확인| A0
    E2 -->|로그인 또는 기존 세션 확인| A0
    A0 -->|user_id, tenant_id, role context 확보| G0
    G0 -->|일반 사용자 화면 진입| W
    W -->|작성 완료 후 제출| A1
    A1 -->|피드백 원문 저장| A2
    A2 -->|feedback_id 반환 및 내부 매핑 시작| D1
    D1 -->|운영/관리 대상 건 생성| O0
    G0 -->|운영자/관리자 화면 진입| O0
    O0 -->|승인 필요 건은 승인 엔진으로 전달| AP
    AP -->|승인/반려 이력 기록| D2
    D2 -->|승인 결과 반영| D1
    O0 -->|원문 확인 및 관리자 기능 진입| O1
    O1 -->|이슈 생성/연결 요청| I1
    I1 -->|이슈 식별자/연결 정보 반환| O2
    O2 -->|담당자 배정, 처리 메모, 상태 갱신| D3
    O2 -->|support_tickets 상태 갱신| D1
    O2 -->|외부 업무 시스템 호출| X1
    O1 -->|답변/처리 결과 입력| O2
    D1 -->|최종 상태 동기화| A3
    D3 -->|처리 결과 동기화| A3
    O2 -->|답변/처리 결과 반영| A3
    A3 -->|내 목록 / 상세 / 결과 조회 제공| R1
```

### 13.4 저장 책임 정리

| 데이터 유형 | 우선 저장 위치 | 설명 |
| --- | --- | --- |
| 사용자 입력 본문, 필드값, 첨부 | ABC User Feedback | 원문 데이터의 기준 저장소 |
| `feedback_id`와 내부 티켓 연결 | 우리 DB | `support_tickets`, `abc_feedback_mappings`에 저장 |
| 승인 상태, 반려 이력, 단계별 결재 결과 | 우리 DB | `request_approvals`, 상태 이력 테이블에 저장 |
| 운영 이슈, 피드백-이슈 연결 | ABC User Feedback | 운영 추적의 기준 이슈 저장소 |
| 담당자 배정, 처리 메모, SLA, 외부 연동 결과 | 우리 DB | 운영 제어와 리포팅을 위한 내부 메타데이터 |
| 사용자에게 보여줄 최종 처리 결과 | ABC 원문 조회 화면 + 우리 DB 동기화 결과 | 원문과 상태를 함께 보여주는 최종 표시 데이터 |

### 13.5 설계 해석 포인트

- 사용자 작성은 인증과 접근 권한 검증, `workspace`-채널 판정이 끝난 뒤 시작되며, 작성 UX와 진입 제어는 우리 시스템이 담당하지만 원문 자체는 ABC에 남김.
- 승인과 운영 처리 단계에서는 우리 DB가 상태 제어의 기준 시스템 역할을 수행함.
- 담당자의 이슈 생성은 ABC를 기준으로 하되, 그 이슈를 어떤 업무 상태로 해석할지는 우리 시스템이 담당함.
- 답변 입력 또는 처리 결과 입력은 단순 텍스트 등록이 아니라 `support_tickets` 상태, 승인 결과, 운영 메모, 외부 연동 결과를 함께 묶어 사용자에게 노출하는 흐름으로 봐야 함.