# 관리페이지 운영팀 사용 가이드

> Q&A를 확인하고, 답변하고, 필요한 개발 작업까지 연결하는 업무 안내서입니다.

## 1. 이 문서에서 먼저 알아둘 것

사용자가 남긴 글을 사용자 화면에서는 **Q&A**, 관리페이지에서는 **피드백**이라고 부릅니다.
둘은 서로 다른 글이 아니라 같은 요청을 가리키는 이름입니다.

```mermaid
flowchart LR
    A[사용자: Q&A 작성] --> B[관리페이지: 피드백으로 확인]
    B --> C[담당자 지정 및 검토]
    C --> D{개발 작업이 필요한가?}
    D -- 아니오 --> E[답변 작성 및 피드백 처리]
    D -- 예 --> F[이슈 생성 또는 연결]
    F --> G[이슈 처리 및 진행 상황 확인]
    G --> E
```

### 핵심 원칙

- 피드백 상태와 이슈 상태는 **따로** 관리합니다.
- 고객에게 보여줄 내용은 **댓글/답변**에 작성합니다.
- 운영팀끼리만 공유할 내용은 **담당자 내부 메모**에 작성합니다.
- 이슈를 연결했다고 피드백이 자동으로 완료되는 것은 아닙니다.
- 처리할 때는 제목보다 먼저 **프로젝트와 채널**을 확인합니다.

## 2. 역할별로 하는 일

| 역할 | 주로 하는 일 | 이 가이드에서 볼 내용 |
| --- | --- | --- |
| 시스템관리자 | 전체 프로젝트의 운영 현황 확인, 필요 시 업무 처리 | 통합 관리, 피드백 처리, 이슈 처리 |
| 프로젝트 담당자(읽는 당사자) | 맡은 프로젝트의 Q&A를 읽고 담당·답변·이슈 처리 | 피드백 처리, 이슈 처리 |
| Q&A 작성자 | Q&A 작성, 답변 확인, 추가 문의 | 사용자에게 공개되는 답변의 의미 |

권한에 따라 보이는 프로젝트와 할 수 있는 작업이 다를 수 있습니다. 보이지 않는 프로젝트나 버튼이 있으면 시스템관리자에게 확인합니다.

## 3. 용어를 쉽게 이해하기

| 화면 용어 | 쉬운 뜻 |
| --- | --- |
| 프로젝트 | 서비스 또는 업무 단위입니다. 예: 특정 사내 시스템, 인트라넷 업무 |
| 채널 | 프로젝트 안의 Q&A 접수 창구입니다. 예: 일반 문의, 장애 문의, 기능 개선 |
| Q&A | 사용자가 작성한 질문·요청·불편 사항입니다. |
| 피드백 | 관리페이지에서 처리하는 Q&A입니다. |
| 담당자 | 해당 피드백이나 이슈를 실제로 확인하고 처리하는 사람입니다. |
| 댓글/답변 | Q&A 작성자에게 공개되는 안내입니다. |
| 담당자 내부 메모 | 운영팀만 보는 협업 메모입니다. Q&A 작성자에게 보이지 않습니다. |
| 이슈 | 개발·수정·확인이 필요한 작업 항목입니다. |
| 연결된 이슈 | 피드백과 관련된 작업 항목입니다. 하나의 피드백에 여러 이슈를 연결할 수 있습니다. |
| Gitea 이슈 | 개발자가 작업하는 외부 개발 이슈입니다. 관리페이지의 이슈와 연결해 진행 상황을 확인할 수 있습니다. |
| 중요도 | 먼저 처리해야 하는 정도입니다. |
| 최근 업데이트 | 피드백 또는 이슈가 마지막으로 변경된 시점입니다. |

## 4. 프로젝트 > 채널 구조

관리페이지의 데이터는 다음처럼 정리됩니다.

```text
프로젝트
└── 채널
    └── Q&A 1건
        └── 피드백으로 관리
            ├── 댓글/답변
            ├── 담당자 내부 메모
            └── 연결된 이슈
```

### 프로젝트와 채널의 차이

| 구분 | 프로젝트 | 채널 |
| --- | --- | --- |
| 의미 | 큰 서비스·업무 묶음 | 그 서비스 안의 세부 접수 창구 |
| 예시 | 인트라넷 Q&A | 계정 문의, 권한 문의, 시스템 오류 |
| 운영 목적 | 어느 서비스의 요청인지 구분 | 어떤 종류의 요청인지 구분 |
| 목록에서 확인 | 프로젝트 열 | 채널 열 |

예를 들어 사용자가 `인트라넷 Q&A > 계정 문의`에서 글을 남기면, 관리페이지에는 다음 정보로 표시됩니다.

```text
프로젝트: 인트라넷 Q&A
채널: 계정 문의
제목: 비밀번호를 잊어버렸습니다
```

같은 프로젝트라도 채널이 다르면 문의 성격과 담당 부서가 다를 수 있습니다. 따라서 담당자를 지정하거나 이슈를 연결하기 전에 프로젝트와 채널을 확인합니다.

## 5. 화면 구성과 목록 읽는 법

통합 관리 화면은 여러 프로젝트의 처리할 일을 한곳에서 보여줍니다.

```text
통합 관리
├── 피드백 처리: 사용자의 Q&A를 읽고 답변하는 곳
└── 이슈 처리: 개발 작업과 연결된 이슈를 관리하는 곳
```

### 피드백 처리 목록

주요 열은 다음 순서로 읽으면 됩니다.

| 항목 | 확인할 내용 |
| --- | --- |
| # | 목록 순번입니다. |
| 프로젝트 / 채널 | 어느 서비스의 어떤 접수 창구인지 확인합니다. |
| 제목 | 피드백 상세를 여는 버튼입니다. |
| 작성자 | Q&A를 남긴 사람입니다. |
| 담당자 | 현재 처리 담당자입니다. `-`이면 아직 지정되지 않았습니다. |
| 피드백 상태 | 고객 요청의 처리 단계입니다. |
| 중요도 | 우선 처리 정도입니다. |
| 최근 업데이트 | 마지막 변경 후 며칠이 지났는지 확인합니다. |
| 연결 이슈 | 관련 개발 이슈입니다. 여러 개면 대표 제목 뒤에 `외 N개`로 표시됩니다. |
| 등록일시 | Q&A가 등록된 날짜와 시간입니다. |

### 이슈 처리 목록

| 항목 | 확인할 내용 |
| --- | --- |
| # | 목록 순번입니다. |
| 프로젝트 / 채널 | 이슈가 속한 서비스와 채널입니다. |
| 제목 | 이슈 상세를 여는 버튼입니다. |
| 담당자 | 이슈를 맡은 사람입니다. |
| 이슈 상태 | 개발 작업의 처리 단계입니다. |
| 최근 업데이트 | 이슈가 마지막으로 변경된 후 며칠이 지났는지 확인합니다. |
| 연결된 피드백 | 이 이슈와 관련된 Q&A입니다. 여러 개면 대표 제목 뒤에 `외 N개`로 표시됩니다. |
| 이슈 등록일시 | 이슈가 등록된 날짜와 시간입니다. |

### 검색과 필터

- 프로젝트 선택: 특정 프로젝트만 봅니다.
- 상태 버튼: 원하는 상태만 봅니다. 여러 상태를 함께 선택할 수 있습니다.
- 날짜 검색: 선택한 기간의 항목만 봅니다.
- 검색창: 제목·내용·작성자 또는 연결된 피드백을 검색합니다.
- `완료 상태 표시`, `보류 상태 표시`: 기본 목록에서 숨겨진 완료·보류 항목을 함께 봅니다.
- `내 담당`: 현재 로그인한 담당자의 피드백만 봅니다.

목록에 항목이 보이지 않으면 먼저 프로젝트, 날짜, 상태 필터와 완료·보류 표시 여부를 확인합니다.

## 6. 피드백 처리 방법

피드백 처리는 “사용자의 요청을 읽고 답변하는 일”입니다.

### 기본 처리 순서

```mermaid
flowchart TD
    A[피드백 목록 확인] --> B[프로젝트·채널 확인]
    B --> C[제목을 눌러 상세 열기]
    C --> D[작성자·내용·첨부파일 확인]
    D --> E[담당자 지정]
    E --> F[내부 메모로 운영팀 공유]
    F --> G{개발 작업 필요?}
    G -- 아니오 --> H[댓글/답변 작성]
    G -- 예 --> I[기존 이슈 연결 또는 새 이슈 생성]
    I --> H
    H --> J[피드백 상태 변경]
    J --> K[최근 업데이트 확인 후 종료]
```

### 단계별 안내

1. **목록에서 피드백을 찾습니다.**
   - 프로젝트·채널·날짜·상태를 확인합니다.
   - 오래된 미처리 건은 `최근 업데이트`와 중요도를 함께 봅니다.

2. **제목을 눌러 상세를 엽니다.**
   - 작성자, 이메일, 연락처, 소속, 직급, 등록일시, 수정일시, UUID를 확인할 수 있습니다.
   - 본문, 중요도, 첨부파일, 연결된 이슈를 확인합니다.

3. **담당자를 지정합니다.**
   - 실제로 확인할 사람을 선택합니다.
   - 담당자가 없으면 후속 조치가 누락될 수 있으므로 확인 후 지정합니다.

4. **필요하면 내부 메모를 남깁니다.**
   - 재현 방법, 확인할 부서, 통화 내용, 다음 담당자에게 전달할 내용을 기록합니다.
   - 고객에게 보여도 되는 답변은 내부 메모가 아닌 댓글/답변에 작성합니다.

5. **댓글/답변을 작성합니다.**
   - Q&A 작성자가 읽는 안내입니다.
   - 확인한 내용, 조치한 내용, 추가로 필요한 정보를 짧고 분명하게 씁니다.
   - 처리 완료 안내가 필요한 경우 댓글 작성 화면의 `처리 완료 안내`를 선택합니다.

6. **피드백 상태를 바꿉니다.**
   - 답변이나 개발 진행 상황에 맞는 상태를 선택합니다.
   - 상태만 바꾸고 답변을 남기지 않으면 작성자가 처리 결과를 알기 어렵습니다.

### 피드백 상태

| 상태 | 언제 사용하나요? |
| --- | --- |
| 신규 | 새로 들어와 아직 확인하지 않은 요청입니다. |
| 접수 | 요청을 확인했고 처리 대상으로 접수한 상태입니다. |
| 진행중 | 답변 작성, 확인, 개발 작업 등 처리가 진행 중입니다. |
| 완료 | 안내와 필요한 처리가 끝난 상태입니다. |
| 보류 | 정보 부족, 일정, 외부 사유 등으로 잠시 멈춘 상태입니다. 보류 사유를 함께 남깁니다. |

`진행중` 상태에서는 내부 처리 흐름에 따라 추가 안내가 표시될 수 있습니다. 화면에 보이는 상태와 고객에게 보내는 답변은 각각 확인합니다.

## 7. 이슈 처리 방법

이슈 처리는 “피드백을 해결하기 위해 필요한 작업을 관리하는 일”입니다.

### 이슈를 만들거나 연결할 때

| 상황 | 처리 방법 |
| --- | --- |
| 이미 같은 개발 작업이 있음 | 기존 이슈를 찾아 피드백에 연결합니다. |
| 새로운 개발 작업임 | 이슈를 새로 만들고 피드백을 연결합니다. |
| 단순 안내·문의임 | 이슈를 만들지 않고 답변 후 피드백을 처리합니다. |
| 같은 원인으로 문의가 여러 건임 | 하나의 이슈에 여러 피드백을 연결할 수 있습니다. |

### 기본 처리 순서

```mermaid
flowchart TD
    A[이슈 처리 탭에서 이슈 확인] --> B[프로젝트·채널·제목 확인]
    B --> C[이슈 상세 열기]
    C --> D[연결된 피드백 확인]
    D --> E[이슈 담당자 지정]
    E --> F{Gitea 개발 이슈가 있는가?}
    F -- 있음 --> G[Gitea 상태와 작업 내용 확인]
    F -- 없음 --> H[기존 Gitea 이슈 검색·연결 또는 새 이슈 생성]
    H --> G
    G --> I[내부 메모로 진행 내용 기록]
    I --> J[이슈 상태 변경]
    J --> K[연결된 피드백에 답변 및 상태 반영]
```

### 이슈 상세에서 확인할 것

- **이슈 내용**: 작업 제목과 상세 내용입니다.
- **이슈 상태**: 개발 작업이 어느 단계인지 표시합니다.
- **이슈 담당자**: 작업을 맡은 사람입니다.
- **연결된 피드백**: 같은 문제를 겪은 Q&A 목록입니다. 항목을 눌러 내용을 확인합니다.
- **담당자 내부 메모**: 개발·운영팀 간 진행 내용을 기록합니다.
- **Gitea 이슈 연결**: 번호나 제목으로 기존 개발 이슈를 검색해 연결합니다.

### 이슈 상태

이슈도 피드백과 같은 상태 색상과 이름을 사용합니다.

| 상태 | 의미 |
| --- | --- |
| 신규 | 작업이 등록되었지만 아직 본격적으로 시작하지 않았습니다. |
| 접수 | 작업 내용을 확인하고 처리 대상으로 받았습니다. |
| 진행중 | 개발·확인 작업을 하고 있습니다. |
| 완료 | 작업이 끝났습니다. 연결된 피드백의 답변·상태도 확인합니다. |
| 보류 | 작업을 잠시 멈춘 상태입니다. 이유를 내부 메모에 남깁니다. |

이슈가 완료되어도 고객 피드백은 별도로 답변하고 상태를 바꿔야 합니다. 반대로 피드백에 답변했다고 이슈가 자동 완료되는 것도 아닙니다.

## 8. 피드백과 이슈를 함께 처리하는 예시

### 예시: 로그인 오류 문의

| 순서 | 담당자가 하는 일 |
| --- | --- |
| 1 | `시스템 오류` 채널에서 로그인 오류 피드백을 확인합니다. |
| 2 | 담당자를 지정하고, 재현에 필요한 정보를 내부 메모에 남깁니다. |
| 3 | 개발 수정이 필요하면 기존 로그인 오류 이슈를 검색합니다. |
| 4 | 같은 이슈가 있으면 연결하고, 없으면 새 이슈를 생성합니다. |
| 5 | 피드백에는 “확인 중이며 수정 작업을 진행한다”는 답변을 작성합니다. |
| 6 | 피드백과 이슈를 각각 `진행중`으로 변경합니다. |
| 7 | 개발이 끝나면 이슈를 `완료`로 바꾸고, 피드백에 결과를 답변합니다. |
| 8 | 고객 안내까지 끝난 뒤 피드백을 `완료`로 변경합니다. |

## 9. 댓글과 내부 메모 구분하기

| 작성 위치 | 누가 읽나요? | 작성할 내용 |
| --- | --- | --- |
| 댓글/답변 | Q&A 작성자와 운영팀 | 확인 결과, 처리 내용, 고객에게 전달할 안내 |
| 담당자 내부 메모 | 운영팀과 관리자 | 내부 협의, 원인 추정, 재현 방법, 인수인계 내용 |

### 잘못 작성하기 쉬운 예

- 고객에게 보여주면 안 되는 개인정보·내부 협의 내용을 댓글에 작성하지 않습니다.
- 고객이 알아야 할 처리 결과를 내부 메모에만 남기지 않습니다.
- “확인 중”이라고만 쓰지 말고 무엇을 확인 중인지 함께 씁니다.

## 10. 운영 전 확인 체크리스트

### 피드백을 열었을 때

- [ ] 프로젝트와 채널이 맞는가?
- [ ] 제목과 본문을 끝까지 확인했는가?
- [ ] 첨부파일이 있는가?
- [ ] 중요도를 확인했는가?
- [ ] 담당자가 지정되어 있는가?
- [ ] 기존 연결 이슈가 있는가?
- [ ] 답변과 내부 메모를 올바른 위치에 작성했는가?
- [ ] 피드백 상태를 실제 진행 상황과 맞게 바꿨는가?

### 이슈를 처리했을 때

- [ ] 이슈가 어느 프로젝트·채널에 속하는지 확인했는가?
- [ ] 연결된 피드백을 모두 확인했는가?
- [ ] 기존 Gitea 이슈가 있는지 먼저 검색했는가?
- [ ] 이슈 담당자를 지정했는가?
- [ ] 진행 내용과 보류 사유를 내부 메모에 남겼는가?
- [ ] 이슈 상태와 피드백 상태를 각각 바꿨는가?
- [ ] 고객에게 보낼 답변을 남겼는가?

## 11. 자주 생기는 상황

| 상황 | 먼저 확인할 것 |
| --- | --- |
| 목록에 피드백이 없다 | 프로젝트, 날짜, 상태 필터와 완료·보류 표시를 확인합니다. |
| 담당자가 보이지 않는다 | 해당 프로젝트의 담당 권한과 현재 선택한 프로젝트를 확인합니다. |
| 같은 문의가 반복된다 | 기존 이슈를 검색하고 여러 피드백을 하나의 이슈에 연결할 수 있는지 확인합니다. |
| 이슈는 완료됐는데 피드백이 남아 있다 | 이슈와 피드백은 별도 상태이므로 피드백 답변과 상태를 따로 처리합니다. |
| 고객에게 답변이 보이지 않는다 | 내부 메모가 아닌 댓글/답변으로 작성했는지 확인합니다. |
| 오래된 건을 찾고 싶다 | 날짜 검색 범위를 넓히고 `완료 상태 표시`·`보류 상태 표시`를 확인합니다. |
| 연결 항목 제목이 잘려 보인다 | 제목에 마우스를 올려 전체 내용을 확인하고, `외 N개`가 있는지 확인합니다. |

## 12. 한 줄 요약

```text
프로젝트·채널 확인
  → 피드백 읽기
  → 담당자 지정
  → 내부 메모 또는 고객 답변
  → 필요하면 이슈 연결
  → 피드백 상태와 이슈 상태를 각각 업데이트
```

이 순서만 지키면 Q&A 누락을 줄이고, 운영팀과 개발팀의 업무 경계를 명확하게 유지할 수 있습니다.