본문으로 건너뛰기
고객 Care 고객 사용자 매뉴얼의 케어 상태 흐름 — 대기, 검토중, 처리중, 완료 네 단계와 단계별 색

업무 시스템 › 고객 지원·업무 관리

고객 Care + JIRA 연동 업무보고

고객 요청과 엑셀 보고를 JIRA 중심 흐름으로 바꿨다. Care는 고객사 사용, 업무보고는 부서 운영, WBS 앱은 개발까지.

고객사 사용
기간
2025.09 ~ 2026.04 (리드정보기술 재직 기간(이력서) 기준 · 도구별 작업 기록은 WBS 앱 2025-09 ~ 2026-02, 업무보고 2025-12 ~ 2026-02, Care 2026-01 ~ 02(파일 날짜 기준))
상태
주 배지는 고객 Care 기준. JIRA 연동 업무보고는 부서 운영, JIRA 연동 WBS 관리 앱은 개발(운영 적용 전)
맥락
리드정보기술(주) SI사업부 이사(부서장) — 전 직장, 2025.09 ~ 2026.04
역할
요청 처리·업무 보고 흐름을 다시 정의하고 JIRA·사내 메신저를 도입, 도구 기획·JIRA 연결·배포·운영과 부서 적용을 맡음
구현
Care는 Claude Code로 기획·디자인·구현(API 테스트 수행도 Claude Code 표기) · 업무보고는 AI 개발 도구 안티그래비티로 구현 · WBS 앱은 AI 활용 개발(저장소에 Claude Code 작업 지침)
기술
Next.js, React, Spring Boot, MyBatis, MySQL, MariaDB, Tailwind CSS, shadcn/ui, JIRA Cloud REST API, 카카오워크 알림 연동, Playwright

핵심 수치.

본인 확인

고객사 사용

고객 Care — 출시 후 고객사가 업무에 사용, 2026

본인 확인

부서 운영

JIRA 연동 업무보고 — 소속 부서에 적용·운영, 리드정보기술 재직 중

실측

13/13

Care API 테스트 PASS — 2026-01-15, 로컬 개발 환경, 테스트 수행 Claude Code

개요

전 직장 리드정보기술에서 부서장으로 일하며, 카카오톡과 엑셀로 흩어져 있던 고객 요청·업무 보고를 JIRA를 중심으로 한 흐름으로 바꾸고, 필요한 도구를 AI 개발 도구로 직접 만들어 적용한 사례다.

직접 만든 도구 가운데 실제로 쓰인 것은 두 가지다. 고객 Care는 출시되어 고객사가 업무에 사용했고, JIRA 연동 업무보고는 소속 부서에 적용해 운영했다.

같은 시기에 만든 JIRA 연동 WBS 관리 앱은 개발까지 진행했고 운영에는 적용하지 않았다.

문제

  • 고객 요청은 카카오톡으로 받고, 내부 업무 보고는 엑셀로 작성하고 있었다.
  • Care 소개 자료는 풀어야 할 일을 고객사·프로젝트별 이슈 통합 관리, JIRA 연동을 통한 개발·운영 업무 일원화, 고객과 운영자 사이의 투명한 소통으로 정리했다.

본인 역할

  • 부서장으로서 요청 처리·업무 보고 흐름을 다시 정의하고, 필요한 도구를 AI 개발 도구로 직접 기획·디자인·구현해 배포했다.
  • 도구를 만들기 전에 JIRA·사내 메신저를 도입해 스프린트 기반 운영·개발 관리 체계를 세웠다.
  • 직접 맡은 일은 고객 요청 흐름 기획, JIRA와의 연결, 서비스 배포·운영이다.
  • 구현은 AI 개발 도구가 맡았다. Care는 Claude Code로 기획·디자인·구현했고, 업무보고는 AI 개발 도구 안티그래비티로 구현했다.

핵심 판단

  1. 도구보다 관리 체계와 흐름을 먼저 세웠다. 도구를 만들기 전에 JIRA·사내 메신저를 도입해 스프린트 기반 관리 체계를 만들고, 그 위에 Care와 업무보고를 JIRA로 연결했다. 이유는 고객 요청 처리와 내부 업무 보고가 따로 놀지 않고 JIRA를 중심으로 한 흐름으로 이어지게 하려는 것이었다.
  2. 기획서에서 Care 직접 응답과 JIRA 처리를 나눴다. Care 기획서는 단순 문의는 담당자가 Care 안에서 바로 답하고, 별도 처리가 필요한 건만 JIRA 이슈로 만들어 Care 요청과 연결하도록 설계했다. JIRA 처리가 끝나면 고객에게 전달할 JIRA 댓글을 담당자가 골라 Care 답변으로 반영하는 방식도 기획서에 넣었다. 내부 작업 기록과 고객에게 보일 안내를 나누려는 설계다. 이 세부 정책이 출시판에 그대로 들어갔는지는 원자료으로 확인하지 못했다.
  3. 고객이 처리 상태와 우선순위를 같은 기준으로 보게 했다. 요청은 기능 오류·문의사항·기타 요청 세 유형과 P1 긴급 ~ P4 낮음 네 등급으로 등록하고, 상태는 대기 → 검토중 → 처리중 → 완료로 보이게 했다. 담당자가 검토 뒤 처리 가능 예정일을 입력해 고객에게 안내하도록 기획했다.
  4. 업무보고는 입력 공수를 줄이는 쪽으로 설계했다. 업무보고 기획안은 전일 내역 불러오기, JIRA 번호·제목 검색으로 업무 추가, 티켓의 최근 댓글 3개를 업무 근거로 발췌하는 기능을 두었다. 기획안이 적은 이유는 입력 공수 최소화, JIRA 연동을 통한 데이터 정합성, 주간 단위 조회를 통한 업무 투명성이다.

화면과 구성도

고객 Care + JIRA 연동 업무보고 구성도
구성도 — 직접 그린 그림(내부 주소·서버 이름 없음)
고객 Care 요청 처리 상태 흐름(대기 → 검토중 → 처리중 → 완료) — 고객 사용자 매뉴얼 v1.0 발췌, 운영 화면 아님
요청 유형 세 가지와 우선순위 등급 P1~P4 정의 — 고객 사용자 매뉴얼 v1.0 발췌
JIRA 연동 업무보고 사용자 화면 기획 와이어프레임(인물·업무는 예시 값) — 운영 화면 아님

과정

  • JIRA 연동 WBS 관리 앱: 프로젝트별 WBS를 관리하는 앱으로, 작업 기록은 2025-09부터 2026-02까지 남아 있다(파일 날짜 기준).
  • 역할 기반 접근(Admin·Manager·Member), 계층형 WBS 항목, 연도·주차별 계획·실제 진행률을 지원한다.
  • WBS 항목에는 JIRA 이슈 키와 주소를 연결하는 필드를 두었다.
  • 시즌 1 계획서는 JWT 인증, 프로젝트 관리, WBS 항목 관리, 드래그 앤 드롭 순서 변경, 주차별 진행률, Playwright E2E 12개를 완료로 기록했다.
  • 2026-01-27에는 시즌 2의 6단계(데이터 모델 확장, 검색 필터·대시보드, 계층형·카드형 보기, 엑셀 업로드·다운로드, 빠른 추가·다중 선택, 미리보기·마무리)가 완료로 기록됐다. 이 범위도 개발 단계이며 운영에는 적용하지 않았다.
  • JIRA 연동 업무보고: 2025-12-22 기획안과 와이어프레임을 바탕으로 DB 스키마(부서·사용자·일자별 보고·JIRA 업무·발췌 댓글·기타 업무·첨부 등 9개 테이블)와 로그인·업무보고 화면을 구현했다(구현 도구 안티그래비티).
  • 업무보고 화면은 상단에 사용자 정보와 잔여 휴가·진행 중 JIRA 건수를 보여 주고, 월~금 탭으로 날짜별 작성 상태(작성 완료·작성 중·미작성)를 구분한다.
  • 업무보고에는 JIRA 작업 현황 대시보드를 붙였고, 와이어프레임은 상태 체계를 DEV·SANDBOX·CBT·ready for release·released·종료 등으로 정의했다.
  • 고객 Care: 2026-01-12 무렵 작업을 시작했다(파일 날짜 기준).
  • 사용자는 고객 사용자·처리 담당자·관리자 세 유형으로 나누고, 고객은 권한이 있는 프로젝트에만 요청을 등록하게 했다.
  • 요청 등록 항목은 프로젝트·제목·유형·등급·메뉴 경로·URL·본문이고, 첨부는 최대 5개(각 10MB)까지 받는다. 요청이 등록되면 프로젝트별 기본 담당자가 자동으로 지정되도록 기획했다.
  • 2026-01-13 검증 기록에는 백엔드 컴파일 성공과 프론트엔드 린트 오류가 함께 남아 있고, 2026-01-15 로컬 API 시험 13건(인증 3·이슈 5·대시보드 1·공통 3·JIRA 1)은 모두 PASS였다. 시험 수행 주체는 Claude Code로 기록돼 있다.
  • 같은 날 고객·담당자 댓글과 신규 요청을 서로에게 알리는 알림 설계 문서가 작성됐고, 담당자 알림을 카카오워크로 보내는 코드가 백엔드에 있다.
  • 고객 화면은 로그인 직후 대시보드에서 전체·대기 중·진행 중·완료 건수와 최근 요청 목록을 보여 주고, 요청 상세에서는 담당자 답변과 고객의 추가 문의를 댓글 타임라인으로 주고받는다.
  • 등록한 요청은 수정할 수 없고, 추가 정보는 문의 댓글로 전달하도록 운영 규칙을 매뉴얼 FAQ에 적었다.
  • 2026-01-18 기능 정의서, 2026-01-20 고객 사용자 매뉴얼 v1.0을 냈다.
  • 이후 출시해 고객사가 사용했다.

결과

  • 고객 Care는 출시되어 고객사가 업무에 사용했다.
  • JIRA 연동 업무보고는 엑셀 보고를 대신해 소속 부서에 적용·운영했다.
  • 고객 요청 처리와 내부 업무 보고가 JIRA를 중심으로 한 흐름으로 연결됐다.
  • Care API 테스트는 13건 중 13건 PASS였다(2026-01-15, 로컬 개발 환경, 내부 시험).
  • 도입 전후의 처리 시간·누락률 같은 정량 효과를 확인할 수 있는 기록은 확보하지 못했다.

구성요소별 상태

구성요소상태검증 종료 근거남은 일
고객 Care고객사 사용본인 확인(2026-10-27) · 이력서 「출시·고객사 사용」정량 효과 측정 기록 미확인
JIRA 연동 업무보고부서 운영본인 확인(2026-10-27) · 이력서 「부서 적용·운영」정량 효과 측정 기록 미확인
JIRA 연동 WBS 관리 앱개발본인 확인(2026-10-27) · 시즌 1 계획서의 완료 기록(Playwright E2E 12개)운영 적용 전

JIRA·사내 메신저 도입은 위 도구들의 바탕이 된 업무 방식 정비로, 별도 상태 배지 없이 이력서 기재 범위로만 적는다.

한계와 다음 단계

  • 정량 효과 기록 미확인: 도입 전후의 처리 시간·누락률, 사용 고객사 수, 처리 건수는 원자료에 없어 적지 않는다.
  • 다음에는 요청 접수부터 완료까지의 리드타임, 등급별 처리 기한 준수율, 재요청 비율을 도입 시점부터 기록해 효과를 숫자로 확인한다.
  • JIRA 연동 WBS 관리 앱은 운영에 적용하지 않았다.
  • 실제 운영 화면 캡처는 원자료에 없다. 그래서 이 사례의 이미지는 고객 사용자 매뉴얼 발췌와 기획 와이어프레임, 구성도로 대신한다.
  • 이 맥에 있는 원본은 다른 PC 경로가 남아 있어 개발 사본으로 추정되며, 출시판과 같은지는 확인하지 못했다.
  • 참여 인원과 본인 지분은 기록이 없어 적지 않는다.

기술

  • 고객 Care: Next.js, Spring Boot, MyBatis, MySQL(개발 문서 기준), JIRA API 연동, 카카오워크 알림 연동, 디자인 토큰 기반 UI
  • JIRA 연동 업무보고: Next.js 16, MariaDB, Tailwind CSS, shadcn/ui, JIRA Cloud REST API
  • JIRA 연동 WBS 관리 앱: Next.js 16, Spring Boot 3.2, MyBatis, @dnd-kit, JWT, Playwright

AI 활용 방식

  • 도구가 한 일: Care는 Claude Code로 기획 문서·디자인·코드를 만들었고, API 테스트 결과서의 테스트 수행 주체도 Claude Code로 적혀 있다.
  • 업무보고는 AI 개발 도구 안티그래비티가 구현했다.
  • WBS 앱은 AI를 활용해 개발했고, 저장소에 Claude Code 작업 지침 파일(CLAUDE.md)이 있다.
  • 본인이 한 일: 요청 처리·업무 보고 흐름 정의, JIRA·사내 메신저 도입, 도구와 JIRA의 연결, 서비스 배포·운영, 부서 적용을 맡았다.
  • 같은 부서에서 도구마다 다른 AI 개발 도구(Claude Code·안티그래비티)를 썼고, 직접 만든 도구를 현업에서 쓰이게 했다.

관련 사례.

문서 기반 챗봇의 질문 처리 흐름 — 벡터 검색 유사도가 낮으면 관련 문서가 없다고 바로 응답, 높으면 LLM이 출처를 인용해 답하고 SSE 스트리밍으로 출력

지식·챗봇

고객사 시험운영

문서 기반 AI 챗봇 V3 — PDF 질의응답 챗봇

관리자가 올린 PDF를 근거로 답하는 챗봇. 기본 질의응답 경로를 로컬 LLM 구조로 바꿔 고객사 시험운영까지 진행

65.2/100 → 82.9/100 · 코드 리뷰 평균 점수 — 같은 4개 항목·검증 모델 GPT-5-mini, 1차 → 3차, 2026-03-25

2026.03 ~ 2026.04요약 사례