b24014/baron_qa_write

Fork 0

Files

T

root 3c10478482

Deploy EG-BIM QA Gateway / deploy (push) Successful in 2m4s

Details

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

2026-09-21 14:46:36 +09:00

11 KiB

Raw Permalink Blame History

관리페이지 개념 설명

운영팀이 관리페이지의 구조와 용어를 처음 접할 때 읽는 문서로 정리

실제 처리 순서는 관리페이지 운영팀 사용 가이드에서 확인

1. 관리페이지가 하는 일

여러 서비스에서 들어온 Q&A를 한곳에 모아 확인하고 처리하는 화면으로 정리

사용자가 남긴 질문이나 요청을 운영팀이 읽고, 담당자를 정하고, 답변하고, 필요한 개발 작업까지 연결할 수 있도록 구성

flowchart LR
    A[서비스에서 Q&A 작성] --> B[관리페이지에서 피드백으로 확인]
    B --> C[답변 또는 내부 처리]
    C --> D[필요 시 이슈 연결]
    D --> E[처리 결과 안내]

2. Q&A와 피드백

Q&A와 피드백은 서로 다른 글이 아니라 같은 요청을 화면별로 다르게 부르는 이름으로 구분

사용하는 곳	부르는 이름	의미
사용자가 글을 작성하는 화면	Q&A	사용자가 남긴 질문·요청·불편 사항
운영팀이 글을 처리하는 화면	피드백	관리 대상이 된 Q&A

사용자 화면: Q&A
      ↓
관리페이지: 피드백

따라서 운영팀은 “새 피드백이 들어왔다”고 말하지만, 실제로는 사용자가 작성한 Q&A가 관리페이지에 표시된 것으로 이해

3. 역할 구분

관리페이지와 Q&A 화면에서 역할을 다음과 같이 구분

역할	역할의 의미	주요 관심사
시스템관리자	전체 시스템과 여러 프로젝트를 관리하는 역할	전체 현황, 프로젝트별 업무 확인
프로젝트 담당자(읽는 당사자)	맡은 프로젝트의 Q&A를 읽고 처리하는 역할	담당자 지정, 답변, 내부 협업, 이슈 처리
Q&A 작성자	서비스에서 질문이나 요청을 남긴 사람	Q&A 작성, 답변 확인, 추가 문의

권한에 따라 확인할 수 있는 프로젝트와 실행할 수 있는 작업이 달라질 수 있도록 구성

4. 프로젝트와 채널

4.1 프로젝트

프로젝트는 하나의 서비스나 업무 단위를 묶는 가장 큰 관리 단위

예시

사내 시스템
인트라넷 Q&A
특정 업무 서비스

4.2 채널

채널은 프로젝트 안에서 Q&A를 받는 세부 접수 창구

하나의 프로젝트에 여러 채널을 둘 수 있고, 문의 종류를 나누는 기준으로 사용

예시

인트라넷 Q&A 프로젝트
├── 계정 문의 채널
├── 권한 문의 채널
└── 시스템 오류 채널

4.3 프로젝트와 채널의 관계

구분	프로젝트	채널
범위	큰 서비스·업무 묶음	프로젝트 안의 세부 접수 창구
확인 질문	어느 서비스의 요청인가?	어떤 종류의 요청인가?
관리페이지 열	프로젝트	채널
예시	인트라넷 Q&A	계정 문의

Q&A는 반드시 하나의 프로젝트와 채널을 기준으로 관리되도록 구성

프로젝트
└── 채널
    └── Q&A
        └── 피드백

프로젝트와 채널을 먼저 확인해야 담당자와 처리 방향을 잘못 정하지 않음

5. 피드백과 이슈

5.1 피드백

피드백은 사용자의 Q&A 자체를 처리하는 항목

주로 다음 내용을 관리

사용자의 질문과 요청
작성자 정보
중요도
담당자
댓글/답변
담당자 내부 메모
연결된 이슈
피드백 상태

5.2 이슈

이슈는 피드백을 해결하기 위해 필요한 개발·수정·확인 작업

예시

로그인 오류 수정
화면 문구 변경
권한 확인 및 수정
특정 조건에서 발생하는 오류 조사

5.3 연결 관계

한 피드백에 이슈가 없을 수도 있고, 여러 이슈가 연결될 수도 있도록 구성 같은 원인으로 들어온 여러 피드백을 하나의 이슈에 연결할 수도 있도록 구성

flowchart LR
    F1[피드백 A] --> I[이슈: 로그인 오류 수정]
    F2[피드백 B] --> I
    F3[피드백 C] --> I

이슈를 연결했다고 피드백이 자동으로 완료되는 것은 아니므로 각각의 처리 상태를 따로 확인

6. 피드백 상태와 이슈 상태

피드백 상태는 사용자의 요청이 어디까지 처리되었는지 나타내고, 이슈 상태는 개발 작업이 어디까지 진행되었는지 나타내도록 분리

상태	공통 의미
신규	아직 본격적으로 확인하지 않은 상태
접수	내용을 확인하고 처리 대상으로 받은 상태
진행중	답변·확인·개발 작업을 진행하는 상태
완료	필요한 처리와 안내가 끝난 상태
보류	일정·추가 정보·외부 사유로 잠시 멈춘 상태

상태 흐름은 다음처럼 이해

신규 → 접수 → 진행중 → 완료
                    ↘ 보류

보류는 영구 종료가 아니라 다시 처리할 수 있도록 잠시 멈춘 상태로 구분 보류로 변경할 때는 보류 사유를 함께 남기는 방식으로 정리

상태를 따로 관리하는 이유

상황	피드백 상태	이슈 상태
고객에게 답변했고 개발 작업이 없음	완료	해당 없음
개발 작업을 시작함	진행중	진행중
개발은 끝났지만 고객 안내가 남음	진행중	완료
고객 안내까지 끝남	완료	완료

개발 이슈가 완료된 뒤에도 피드백에 결과를 답변하고 피드백 상태를 완료로 바꾸는 작업이 필요

6.1 핵심 처리 순서

세부 자동화 동작은 제외하고, 운영팀이 기억할 핵심 순서만 다음과 같이 정리

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[피드백 완료]

순서도 읽는 법

Q&A가 등록되면 관리페이지에서 피드백 신규로 확인
담당자가 내용을 처음 확인하면 접수로 처리
개발 작업이 없으면 답변 후 완료 안내를 진행
개발 작업이 있으면 이슈를 연결하고, 이슈가 끝난 뒤 답변과 완료 안내를 진행
작성자가 완료를 확인하거나 확인 기간이 지나면 피드백을 완료로 처리

꼭 기억할 예외

처리하기 어려운 사유가 있으면 보류로 바꾸고 사유를 남겼음.
보류 중인 항목은 댓글이나 외부 상태 변경만으로 자동 진행하지 않았음.
완료 안내 뒤 작성자가 다시 문의하면 피드백을 다시 확인
완료된 이슈와 피드백은 각각 별도로 완료 처리

7. 댓글과 담당자 내부 메모

두 입력 영역은 읽는 사람이 다르므로 목적을 분리

구분	댓글/답변	담당자 내부 메모
읽는 사람	Q&A 작성자와 운영팀	운영팀과 관리자
목적	고객에게 처리 결과를 안내	운영팀끼리 내용을 공유
작성 예시	확인 결과, 조치 내용, 추가 안내	재현 방법, 원인 추정, 인수인계
작성 시 주의	고객이 이해할 수 있게 작성	고객에게 공개되면 안 되는 내용도 작성 가능

고객에게 전달할 내용은 댓글/답변에 작성하고, 내부 협의 내용은 담당자 내부 메모에 작성하도록 구분

8. 담당자와 중요도

담당자

담당자는 피드백이나 이슈를 실제로 확인하고 처리할 사람

담당자가 지정되지 않은 항목은 처리 주체가 불명확해질 수 있으므로 확인 후 담당자를 지정

중요도

중요도는 먼저 처리해야 하는 정도를 나타내는 정보

중요도가 높거나 오래 업데이트되지 않은 피드백부터 확인하면 처리 우선순위 판단에 도움

9. Gitea 이슈

Gitea 이슈는 개발자가 실제 수정 작업을 진행하는 외부 개발 작업 항목

관리페이지의 이슈와 Gitea 이슈를 연결하면 운영팀이 개발 작업의 번호와 상태를 함께 확인 가능

관리페이지 이슈
      ↕ 연결
Gitea 개발 이슈

기존 Gitea 이슈가 있으면 검색해 연결하고, 관련 작업이 없으면 새 개발 이슈를 생성해 연결

Gitea 연결 여부와 피드백 완료 여부는 별개이므로 개발 이슈를 연결한 뒤에도 고객 답변과 피드백 상태를 확인

10. 목록의 주요 정보

피드백 처리 목록

피드백 처리 목록은 사용자의 Q&A를 찾아 답변하고 처리하는 데 필요한 정보를 표시하도록 구성

항목	의미
프로젝트 / 채널	요청이 들어온 서비스와 접수 창구
제목	피드백의 제목과 상세 진입점
작성자	Q&A를 남긴 사람
담당자	현재 처리하는 사람
피드백 상태	고객 요청의 처리 단계
중요도	우선 처리 정도
최근 업데이트	마지막으로 변경된 시점
연결 이슈	관련 개발 작업
등록일시	Q&A가 등록된 시점

이슈 처리 목록

이슈 처리 목록은 개발 작업을 찾고 연결된 피드백까지 확인하도록 구성

항목	의미
프로젝트 / 채널	이슈가 속한 서비스와 접수 창구
제목	이슈의 제목과 상세 진입점
담당자	이슈를 처리하는 사람
이슈 상태	개발 작업의 처리 단계
최근 업데이트	이슈가 마지막으로 변경된 시점
연결된 피드백	해당 이슈와 관련된 Q&A
이슈 등록일시	이슈가 등록된 시점

연결 항목이 여러 개이면 대표 항목 뒤에 외 N개로 표시

11. 한눈에 보는 전체 구조

flowchart TD
    P[프로젝트] --> C[채널]
    C --> Q[Q&A]
    Q --> F[피드백]
    F --> R[댓글/답변]
    F --> M[담당자 내부 메모]
    F -. 필요 시 연결 .-> I[관리페이지 이슈]
    I -. 개발 작업 연결 .-> G[Gitea 이슈]

정리하면 다음 구조로 이해

프로젝트
└── 채널
    └── Q&A = 피드백
        ├── 담당자
        ├── 중요도
        ├── 댓글/답변
        ├── 담당자 내부 메모
        └── 이슈 ── Gitea 이슈

12. 핵심만 다시 정리

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

11 KiB Raw Permalink Blame History