관리페이지 데이터 전송 구현

docs/관리페이지 md 파일/관리페이지-개념설명.md

@@ -0,0 +1,316 @@
+# 관리페이지 개념 설명
+
+> 운영팀이 관리페이지의 구조와 용어를 처음 접할 때 읽는 문서로 정리
+>
+> 실제 처리 순서는 [관리페이지 운영팀 사용 가이드](<./관리페이지-운영팀-사용가이드.md>)에서 확인
+
+## 1. 관리페이지가 하는 일
+
+여러 서비스에서 들어온 Q&A를 한곳에 모아 확인하고 처리하는 화면으로 정리
+
+사용자가 남긴 질문이나 요청을 운영팀이 읽고, 담당자를 정하고, 답변하고, 필요한 개발 작업까지 연결할 수 있도록 구성
+
+```mermaid
+flowchart LR
+    A[서비스에서 Q&A 작성] --> B[관리페이지에서 피드백으로 확인]
+    B --> C[답변 또는 내부 처리]
+    C --> D[필요 시 이슈 연결]
+    D --> E[처리 결과 안내]
+```
+
+## 2. Q&A와 피드백
+
+Q&A와 피드백은 서로 다른 글이 아니라 같은 요청을 화면별로 다르게 부르는 이름으로 구분
+
+| 사용하는 곳 | 부르는 이름 | 의미 |
+| --- | --- | --- |
+| 사용자가 글을 작성하는 화면 | Q&A | 사용자가 남긴 질문·요청·불편 사항 |
+| 운영팀이 글을 처리하는 화면 | 피드백 | 관리 대상이 된 Q&A |
+
+```text
+사용자 화면: Q&A
+      ↓
+관리페이지: 피드백
+```
+
+따라서 운영팀은 “새 피드백이 들어왔다”고 말하지만, 실제로는 사용자가 작성한 Q&A가 관리페이지에 표시된 것으로 이해
+
+## 3. 역할 구분
+
+관리페이지와 Q&A 화면에서 역할을 다음과 같이 구분
+
+| 역할 | 역할의 의미 | 주요 관심사 |
+| --- | --- | --- |
+| 시스템관리자 | 전체 시스템과 여러 프로젝트를 관리하는 역할 | 전체 현황, 프로젝트별 업무 확인 |
+| 프로젝트 담당자(읽는 당사자) | 맡은 프로젝트의 Q&A를 읽고 처리하는 역할 | 담당자 지정, 답변, 내부 협업, 이슈 처리 |
+| Q&A 작성자 | 서비스에서 질문이나 요청을 남긴 사람 | Q&A 작성, 답변 확인, 추가 문의 |
+
+권한에 따라 확인할 수 있는 프로젝트와 실행할 수 있는 작업이 달라질 수 있도록 구성
+
+## 4. 프로젝트와 채널
+
+### 4.1 프로젝트
+
+프로젝트는 하나의 서비스나 업무 단위를 묶는 가장 큰 관리 단위
+
+예시
+
+- 사내 시스템
+- 인트라넷 Q&A
+- 특정 업무 서비스
+
+### 4.2 채널
+
+채널은 프로젝트 안에서 Q&A를 받는 세부 접수 창구
+
+하나의 프로젝트에 여러 채널을 둘 수 있고, 문의 종류를 나누는 기준으로 사용
+
+예시
+
+```text
+인트라넷 Q&A 프로젝트
+├── 계정 문의 채널
+├── 권한 문의 채널
+└── 시스템 오류 채널
+```
+
+### 4.3 프로젝트와 채널의 관계
+
+| 구분 | 프로젝트 | 채널 |
+| --- | --- | --- |
+| 범위 | 큰 서비스·업무 묶음 | 프로젝트 안의 세부 접수 창구 |
+| 확인 질문 | 어느 서비스의 요청인가? | 어떤 종류의 요청인가? |
+| 관리페이지 열 | 프로젝트 | 채널 |
+| 예시 | 인트라넷 Q&A | 계정 문의 |
+
+Q&A는 반드시 하나의 프로젝트와 채널을 기준으로 관리되도록 구성
+
+```text
+프로젝트
+└── 채널
+    └── Q&A
+        └── 피드백
+```
+
+프로젝트와 채널을 먼저 확인해야 담당자와 처리 방향을 잘못 정하지 않음
+
+## 5. 피드백과 이슈
+
+### 5.1 피드백
+
+피드백은 사용자의 Q&A 자체를 처리하는 항목
+
+주로 다음 내용을 관리
+
+- 사용자의 질문과 요청
+- 작성자 정보
+- 중요도
+- 담당자
+- 댓글/답변
+- 담당자 내부 메모
+- 연결된 이슈
+- 피드백 상태
+
+### 5.2 이슈
+
+이슈는 피드백을 해결하기 위해 필요한 개발·수정·확인 작업
+
+예시
+
+- 로그인 오류 수정
+- 화면 문구 변경
+- 권한 확인 및 수정
+- 특정 조건에서 발생하는 오류 조사
+
+### 5.3 연결 관계
+
+한 피드백에 이슈가 없을 수도 있고, 여러 이슈가 연결될 수도 있도록 구성
+같은 원인으로 들어온 여러 피드백을 하나의 이슈에 연결할 수도 있도록 구성
+
+```mermaid
+flowchart LR
+    F1[피드백 A] --> I[이슈: 로그인 오류 수정]
+    F2[피드백 B] --> I
+    F3[피드백 C] --> I
+```
+
+이슈를 연결했다고 피드백이 자동으로 완료되는 것은 아니므로 각각의 처리 상태를 따로 확인
+
+## 6. 피드백 상태와 이슈 상태
+
+피드백 상태는 사용자의 요청이 어디까지 처리되었는지 나타내고, 이슈 상태는 개발 작업이 어디까지 진행되었는지 나타내도록 분리
+
+| 상태 | 공통 의미 |
+| --- | --- |
+| 신규 | 아직 본격적으로 확인하지 않은 상태 |
+| 접수 | 내용을 확인하고 처리 대상으로 받은 상태 |
+| 진행중 | 답변·확인·개발 작업을 진행하는 상태 |
+| 완료 | 필요한 처리와 안내가 끝난 상태 |
+| 보류 | 일정·추가 정보·외부 사유로 잠시 멈춘 상태 |
+
+상태 흐름은 다음처럼 이해
+
+```text
+신규 → 접수 → 진행중 → 완료
+                    ↘ 보류
+```
+
+보류는 영구 종료가 아니라 다시 처리할 수 있도록 잠시 멈춘 상태로 구분
+보류로 변경할 때는 보류 사유를 함께 남기는 방식으로 정리
+
+### 상태를 따로 관리하는 이유
+
+| 상황 | 피드백 상태 | 이슈 상태 |
+| --- | --- | --- |
+| 고객에게 답변했고 개발 작업이 없음 | 완료 | 해당 없음 |
+| 개발 작업을 시작함 | 진행중 | 진행중 |
+| 개발은 끝났지만 고객 안내가 남음 | 진행중 | 완료 |
+| 고객 안내까지 끝남 | 완료 | 완료 |
+
+개발 이슈가 완료된 뒤에도 피드백에 결과를 답변하고 피드백 상태를 완료로 바꾸는 작업이 필요
+
+### 6.1 핵심 처리 순서
+
+세부 자동화 동작은 제외하고, 운영팀이 기억할 핵심 순서만 다음과 같이 정리
+
+```mermaid
+flowchart TD
+    A[사용자가 Q&A 작성] --> B[관리페이지에 피드백 등록<br/>상태: 신규]
+    B --> C[담당자 지정 및 내용 확인<br/>상태: 접수]
+    C --> D{개발 작업이 필요한가?}
+    D -- 아니오 --> E[댓글/답변 작성]
+    D -- 예 --> F[이슈 생성 또는 기존 이슈 연결]
+    F --> G[이슈 처리<br/>상태: 진행중]
+    G --> H[이슈 완료 여부 확인]
+    H --> E
+    E --> I[처리 완료 안내]
+    I --> J{작성자 확인 또는 확인 기간 만료}
+    J --> K[피드백 완료]
+```
+
+### 순서도 읽는 법
+
+1. Q&A가 등록되면 관리페이지에서 피드백 `신규`로 확인
+2. 담당자가 내용을 처음 확인하면 `접수`로 처리
+3. 개발 작업이 없으면 답변 후 완료 안내를 진행
+4. 개발 작업이 있으면 이슈를 연결하고, 이슈가 끝난 뒤 답변과 완료 안내를 진행
+5. 작성자가 완료를 확인하거나 확인 기간이 지나면 피드백을 `완료`로 처리
+
+### 꼭 기억할 예외
+
+- 처리하기 어려운 사유가 있으면 `보류`로 바꾸고 사유를 남겼음.
+- 보류 중인 항목은 댓글이나 외부 상태 변경만으로 자동 진행하지 않았음.
+- 완료 안내 뒤 작성자가 다시 문의하면 피드백을 다시 확인
+- 완료된 이슈와 피드백은 각각 별도로 완료 처리
+
+## 7. 댓글과 담당자 내부 메모
+
+두 입력 영역은 읽는 사람이 다르므로 목적을 분리
+
+| 구분 | 댓글/답변 | 담당자 내부 메모 |
+| --- | --- | --- |
+| 읽는 사람 | Q&A 작성자와 운영팀 | 운영팀과 관리자 |
+| 목적 | 고객에게 처리 결과를 안내 | 운영팀끼리 내용을 공유 |
+| 작성 예시 | 확인 결과, 조치 내용, 추가 안내 | 재현 방법, 원인 추정, 인수인계 |
+| 작성 시 주의 | 고객이 이해할 수 있게 작성 | 고객에게 공개되면 안 되는 내용도 작성 가능 |
+
+고객에게 전달할 내용은 댓글/답변에 작성하고, 내부 협의 내용은 담당자 내부 메모에 작성하도록 구분
+
+## 8. 담당자와 중요도
+
+### 담당자
+
+담당자는 피드백이나 이슈를 실제로 확인하고 처리할 사람
+
+담당자가 지정되지 않은 항목은 처리 주체가 불명확해질 수 있으므로 확인 후 담당자를 지정
+
+### 중요도
+
+중요도는 먼저 처리해야 하는 정도를 나타내는 정보
+
+중요도가 높거나 오래 업데이트되지 않은 피드백부터 확인하면 처리 우선순위 판단에 도움
+
+## 9. Gitea 이슈
+
+Gitea 이슈는 개발자가 실제 수정 작업을 진행하는 외부 개발 작업 항목
+
+관리페이지의 이슈와 Gitea 이슈를 연결하면 운영팀이 개발 작업의 번호와 상태를 함께 확인 가능
+
+```text
+관리페이지 이슈
+      ↕ 연결
+Gitea 개발 이슈
+```
+
+기존 Gitea 이슈가 있으면 검색해 연결하고, 관련 작업이 없으면 새 개발 이슈를 생성해 연결
+
+Gitea 연결 여부와 피드백 완료 여부는 별개이므로 개발 이슈를 연결한 뒤에도 고객 답변과 피드백 상태를 확인
+
+## 10. 목록의 주요 정보
+
+### 피드백 처리 목록
+
+피드백 처리 목록은 사용자의 Q&A를 찾아 답변하고 처리하는 데 필요한 정보를 표시하도록 구성
+
+| 항목 | 의미 |
+| --- | --- |
+| 프로젝트 / 채널 | 요청이 들어온 서비스와 접수 창구 |
+| 제목 | 피드백의 제목과 상세 진입점 |
+| 작성자 | Q&A를 남긴 사람 |
+| 담당자 | 현재 처리하는 사람 |
+| 피드백 상태 | 고객 요청의 처리 단계 |
+| 중요도 | 우선 처리 정도 |
+| 최근 업데이트 | 마지막으로 변경된 시점 |
+| 연결 이슈 | 관련 개발 작업 |
+| 등록일시 | Q&A가 등록된 시점 |
+
+### 이슈 처리 목록
+
+이슈 처리 목록은 개발 작업을 찾고 연결된 피드백까지 확인하도록 구성
+
+| 항목 | 의미 |
+| --- | --- |
+| 프로젝트 / 채널 | 이슈가 속한 서비스와 접수 창구 |
+| 제목 | 이슈의 제목과 상세 진입점 |
+| 담당자 | 이슈를 처리하는 사람 |
+| 이슈 상태 | 개발 작업의 처리 단계 |
+| 최근 업데이트 | 이슈가 마지막으로 변경된 시점 |
+| 연결된 피드백 | 해당 이슈와 관련된 Q&A |
+| 이슈 등록일시 | 이슈가 등록된 시점 |
+
+연결 항목이 여러 개이면 대표 항목 뒤에 `외 N개`로 표시
+
+## 11. 한눈에 보는 전체 구조
+
+```mermaid
+flowchart TD
+    P[프로젝트] --> C[채널]
+    C --> Q[Q&A]
+    Q --> F[피드백]
+    F --> R[댓글/답변]
+    F --> M[담당자 내부 메모]
+    F -. 필요 시 연결 .-> I[관리페이지 이슈]
+    I -. 개발 작업 연결 .-> G[Gitea 이슈]
+```
+
+정리하면 다음 구조로 이해
+
+```text
+프로젝트
+└── 채널
+    └── Q&A = 피드백
+        ├── 담당자
+        ├── 중요도
+        ├── 댓글/답변
+        ├── 담당자 내부 메모
+        └── 이슈 ── Gitea 이슈
+```
+
+## 12. 핵심만 다시 정리
+
+- Q&A는 사용자가 작성한 글이고, 피드백은 관리페이지에서 부르는 이름
+- 프로젝트는 큰 서비스 단위이고, 채널은 프로젝트 안의 세부 접수 창구
+- 피드백은 고객 요청을 처리하는 항목이고, 이슈는 개발 작업을 처리하는 항목으로 나누었음.
+- 댓글/답변은 고객에게 공개되고, 담당자 내부 메모는 운영팀끼리만 공유
+- 피드백 상태와 이슈 상태는 서로 영향을 주지만 자동으로 합쳐지지 않도록 분리
+- 이슈가 완료되어도 고객 답변과 피드백 상태 변경을 별도로 처리