# 관리페이지 개념 설명

> 운영팀이 관리페이지의 구조와 용어를 처음 접할 때 읽는 문서로 정리
>
> 실제 처리 순서는 [관리페이지 운영팀 사용 가이드](<./관리페이지-운영팀-사용가이드.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는 사용자가 작성한 글이고, 피드백은 관리페이지에서 부르는 이름
- 프로젝트는 큰 서비스 단위이고, 채널은 프로젝트 안의 세부 접수 창구
- 피드백은 고객 요청을 처리하는 항목이고, 이슈는 개발 작업을 처리하는 항목으로 나누었음.
- 댓글/답변은 고객에게 공개되고, 담당자 내부 메모는 운영팀끼리만 공유
- 피드백 상태와 이슈 상태는 서로 영향을 주지만 자동으로 합쳐지지 않도록 분리
- 이슈가 완료되어도 고객 답변과 피드백 상태 변경을 별도로 처리