baron_qa_write/docs/관리페이지 md 파일/관리페이지-운영팀-사용가이드.md

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

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

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

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

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. 프로젝트 > 채널 구조

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

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

프로젝트와 채널의 차이

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

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

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

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

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

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

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

피드백 처리 목록

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

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

이슈 처리 목록

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

검색과 필터

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

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

6. 피드백 처리 방법

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

기본 처리 순서

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. 이슈 처리 방법

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

이슈를 만들거나 연결할 때

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

기본 처리 순서

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. 한 줄 요약

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

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