CS 티켓은 왜 자꾸 저글링 공이 될까

CS 개선 미팅을 하다 보면 이상한 순간이 온다.

처음에는 티켓 이야기를 한다.

이 티켓은 왜 오래 열려 있지?
이건 개발팀에 넘겨야 하나?
이건 고객에게 더 물어봐야 하나?
이건 그냥 닫아도 되나?

그런데 한참 이야기하다 보면, 어느 순간 티켓 이야기가 아니라 조직의 신진대사 이야기가 된다.

몸무게만 재고 있었는데, 사실은 근육량이 부족했던 것이다.

“열린 티켓이 몇 개인가?”는 몸무게다. 중요하다. 하지만 그것만 보면 해결이 안 된다. 진짜 질문은 따로 있다.

평시 근무 안에서 티켓이 0으로 수렴하는 구조인가?

오늘 글은 그 질문에서 시작한다.

티켓은 공이다. 문제는 공중에 떠 있는 공이다

CS 티켓은 공과 비슷하다.

고객이 던진다. CS가 받는다. 개발팀에 넘기거나, 파트너에게 확인하거나, 고객에게 다시 질문하거나, 제품 개선 후보로 올린다.

잘 돌아가는 조직에서는 공이 손에서 손으로 이동한다.

문제는 공이 공중에 떠 있을 때다.

누가 잡고 있는지 모른다.
다음 액션이 뭔지 모른다.
닫아도 되는지 모른다.
유상인지 무상인지 모른다.
개발해야 하는지 안내만 하면 되는지 모른다.

이 상태가 길어지면 티켓은 “진행 중”처럼 보이지만 사실은 그냥 공중에 떠 있다.

회의에서 누군가 그 티켓을 다시 본다. “아, 이거 아직 있네요.” 그러고 또 설명한다. 다음 날도 올라온다. 또 설명한다.

이쯤 되면 티켓 리뷰는 리뷰가 아니라 저글링 공연이 된다.

공은 계속 돌고 있는데, 관객은 피곤하고, 정작 공은 바구니에 들어가지 않는다.

데일리 미팅은 티켓 소개 시간이 아니다

티켓 리뷰가 실패하는 가장 흔한 방식은 이렇다.

“이 티켓은 어떤 내용이에요?”

물론 처음 보는 사람에게는 필요하다. 하지만 매일 이 말만 반복되면 티켓은 줄지 않는다.

좋은 데일리 미팅은 티켓 소개 시간이 아니라 “마찰을 드러내는 시간”이어야 한다.

질문이 이렇게 바뀌어야 한다.

어제 이 티켓에서 무엇을 했나?
어디서 막혔나?
오늘 누구에게 넘길 건가?
고객에게 지금 말할 수 있는 것은 무엇인가?
닫을 수 없다면 닫지 못하는 이유는 무엇인가?

이 다섯 질문에 답하지 못하면, 티켓 설명을 아무리 잘해도 다음 액션은 흐려진다.

재미있는 건, 이 질문들이 사람을 혼내기 위한 질문이 아니라는 점이다. 오히려 반대다. 사람이 일을 할 수 있는 상태인지 확인하는 질문이다.

“왜 못 했어요?”가 아니라 “어떤 구조 때문에 못 움직였어요?”에 가깝다.

다섯 개를 보는 것보다 한 개를 움직이는 게 낫다

티켓 다섯 개를 매일 본다고 해보자.

겉으로는 부지런해 보인다. 하지만 다섯 개 모두 설명만 하고 끝나면, 다음 날 같은 다섯 개가 다시 올라온다.

이건 운동으로 치면 헬스장에 가서 인바디만 재고 돌아오는 것과 비슷하다.

“근육량이 부족합니다.”
“네, 알겠습니다.”
다음 주에 또 잰다.
“근육량이 부족합니다.”

문제는 측정이 아니다. 운동할 시간이 없거나, 운동 방법을 모르거나, 식사 패턴이 그대로인 것이다.

CS도 같다.

티켓 숫자를 보는 건 필요하다. 하지만 숫자만 보면 안 된다. 티켓이 안 움직이는 이유를 봐야 한다.

• 고객 답변 대기인가?
• 내부 답변 지연인가?
• 개발 티켓이 막고 있나?
• 설치 일정이 없나?
• 유상/무상 판단이 안 됐나?
• 담당자가 없나?
• 오래된 티켓이라 사실상 종료 후보인가?

이 분류가 없으면 backlog는 그냥 큰 빨래 바구니가 된다. 흰 양말, 검은 티셔츠, 젖은 수건, 드라이클리닝할 코트가 한꺼번에 들어 있다.

빨래를 잘하려면 먼저 분류해야 한다.

유상인가 무상인가: AI 시대에 더 어려워진 질문

예전에는 기능 개발 요청이 들어오면 이런 식으로 생각하기 쉬웠다.

“이건 개발 공수가 크니까 유상.”
“이건 버그니까 무상.”

물론 실제로는 그때도 단순하지 않았다. 그런데 AI가 들어오면서 더 애매해졌다.

AI가 코드를 써준다. 재현도 도와준다. 문서도 정리해준다. 그러면 마음속에서 작은 목소리가 올라온다.

이 정도면 그냥 해줄 수 있는 거 아니야?

여기서 함정이 생긴다.

개발이 쉬워졌다고 해서 제품 판단이 쉬워진 건 아니다. 코드를 빨리 만들 수 있어도, QA해야 하고, 배포해야 하고, 문서화해야 하고, 다른 고객에게도 맞는지 봐야 하고, 운영 부담도 생긴다.

그래서 유상/무상 판단에는 최소한 이런 기준이 필요하다.

공통 제품 기능인가?
특정 고객만의 편의 기능인가?
기존 roadmap과 맞는가?
다른 고객도 반복 요청할 가능성이 있는가?
고객이 빠른 납기를 요구하는가?
개발보다 QA/배포/운영 비용이 더 큰가?

이 기준이 없으면 CS도 흔들리고, 영업도 흔들리고, 개발도 흔들린다.

결국 티켓은 이렇게 된다.

“할 수는 있을 것 같은데…”

이 말은 backlog의 접착제다. 티켓을 잘 붙잡아 둔다.

오래된 티켓은 선의로 닫히지 않는다

오래된 티켓은 조용하다.

고객이 답을 안 했을 수도 있다. 파트너가 확인을 안 했을 수도 있다. 설치 일정이 밀렸을 수도 있다. 담당자가 바뀌었을 수도 있다. “나중에 봐야지” 하다가 모두가 잊었을 수도 있다.

이런 티켓을 사람의 선의에 맡기면 잘 닫히지 않는다.

왜냐하면 닫는 것도 일이고, 닫을 근거를 찾는 것도 일이고, 닫았다가 누가 뭐라고 하면 대응하는 것도 일이기 때문이다.

그래서 규칙이 필요하다.

예를 들면 이런 식이다.

고객/파트너 응답 없음 5영업일: reminder
추가 무응답: 종료 후보
설치 대기 장기화: 설치 일정 확인 요청
1년 이상 waiting: 일괄 정리 후보
내부 답변 지연: 별도 action queue로 분리

중요한 건 고객 응답 대기와 내부 답변 지연을 섞지 않는 것이다.

고객이 답을 안 해서 멈춘 티켓과, 우리가 답을 못 해서 멈춘 티켓은 완전히 다르다. 하나는 reminder와 종료 규칙이 필요하고, 다른 하나는 SLA와 owner 지정이 필요하다.

같은 “오래됨”이라도 처방이 다르다.

AI Agent는 만능 상담원이 아니라 티켓 분류기부터 되어야 한다

AI Agent 이야기도 나왔다.

여기서도 욕심을 내면 위험하다. “티켓 들어오면 AI가 알아서 다 처리해줘”는 멋있지만 너무 넓다.

좋은 시작점은 훨씬 좁아야 한다.

티켓 번호나 증상을 입력한다
관련 Jira / Slack / 문서 / 기존 사례를 찾는다
공식 기능으로 답할 수 있는지 본다
코드나 로그 근거가 필요한지 분류한다
고객에게 물어볼 질문을 만든다
다음 owner를 제안한다

이 정도만 잘해도 엄청난 도움이 된다.

왜냐하면 CS에서 시간이 많이 드는 부분은 종종 “정답 작성”보다 “어디서부터 봐야 하는지 찾기”이기 때문이다.

다만 Agent에게 모든 문을 열어주면 안 된다. 외부 채널에서 바로 Jira를 수정하거나, 내부 문서를 쓰거나, raw source를 노출하거나, 고객 답변을 확정하게 하면 위험하다.

좋은 구조는 역할을 나누는 것이다.

• Partner-facing Agent: 공식 문서 기반 답변, 체크리스트, 티켓 초안
• Internal CS Analysis Agent: Jira, 코드, 문서, 기존 사례를 깊게 분석
• 사람/승인 레이어: 고객 전달, Jira write, 문서 반영 최종 결정

AI는 보안 경계가 아니다. AI는 좋은 조수다. 문 열쇠는 사람과 시스템이 쥐고 있어야 한다.

문서도 티켓 처리 속도다

CS 이야기를 하다 보면 결국 문서 이야기로 간다.

“이 기능 어느 버전에서 바뀌었죠?”
“이 API 있나요?”
“이 설정은 공식 지원인가요?”
“이 문서는 아직 유효한가요?”

이 질문에 답하기 어려우면 티켓은 느려진다.

문서가 없는 것도 문제지만, 더 자주 만나는 문제는 문서가 있는데 못 찾는 것이다.

오래된 문서가 섞여 있다.
버전 정보가 없다.
제품 영역 label이 없다.
deprecated인지 모른다.
릴리즈 노트가 너무 뭉뚱그려져 있다.

Agent를 잘 쓰려면 문서도 Agent가 찾기 좋은 형태여야 한다. 사람에게 좋은 문서와 검색 시스템에게 좋은 문서는 겹치지만 완전히 같지는 않다.

특히 이런 메타데이터가 중요하다.

제품 영역: DAC / SAC / KAC / Workflow / IAM
대상 버전
현재 유효 여부
관련 기능명 / 메뉴명
비슷한 고객 질문 표현
공식 답변 가능 범위

문서에 label을 붙이는 일은 지루해 보인다. 하지만 이건 창고에 선반 이름을 붙이는 일이다. 선반 이름이 없으면 아무리 좋은 물건도 매번 새로 찾아야 한다.

감사 대응은 제품 신호다

회의에서 인상 깊었던 또 하나의 축은 감사 대응이었다.

금융권 고객의 감사 요청은 보통 단순하지 않다.

SQL Request 승인 이력, 실제 실행 SQL, DML Snapshot Before/After, Ledger 설정 현황, 변경 이력, 업무 사유까지 이어서 보고 싶어 한다.

이걸 매번 MetaDB SQL로 뽑아주기 시작하면 CS는 빠르게 지친다.

여기서 중요한 판단이 필요하다.

단발성 고객 양식인가?
반복될 감사 데이터인가?
제품 Report / Export / API로 가야 할 후보인가?
AI는 원자료를 판단해야 하나, 검증된 결과를 고객 양식으로 가공해야 하나?

내 생각에는 감사 대응의 미래는 이렇게 나뉘어야 한다.

• 제품 Report: 반복적으로 필요한 감사 데이터를 안정적으로 제공
• Export/API: 원본 로그와 증적을 권한 모델 안에서 추출
• MetaDB 보조 조회: 표준 기능이 아직 부족한 경우의 임시 다리
• ACP AI: 검증된 결과를 고객별 양식으로 재구성

AI에게 바로 “감사 SQL 만들어줘”라고 던지는 건 위험하다. 대신 제품이 검증된 원재료를 제공하고, AI는 그걸 사람이 읽기 좋은 보고서로 바꾸는 편이 안전하다.

사람은 티켓 기계가 아니다

결국 가장 중요한 결론은 이거다.

CS 담당자는 티켓을 닫는 기계가 아니다.

좋은 CS는 고객의 불편을 제품 언어로 번역한다. 반복 문의를 문서 개선으로 바꾼다. 애매한 요청을 roadmap 질문으로 바꾼다. 고객이 정말 원하는 기능을 찾아낸다.

그런데 티켓이 너무 많이 떠 있으면 사람은 이 일을 못 한다.

온종일 냄비 뚜껑만 열고 닫다 보면, 주방 메뉴를 개선할 시간이 없다.

그래서 AI와 자동화의 목표는 “사람을 더 바쁘게 만드는 것”이 아니어야 한다.

목표는 사람이 사람다운 일을 하게 만드는 것이다.

고객을 만나고, 맥락을 듣고, 제품 방향을 설명하고, 불편을 구조화하고, 반복되는 문제를 시스템으로 없애는 일.

그게 CS가 제품 조직에 줄 수 있는 진짜 가치다.

내가 이 미팅에서 가져간 운영 룰

첫째, 데일리는 티켓 설명이 아니라 마찰 공유 시간이다.

둘째, 모든 티켓에는 next owner가 있어야 한다. CS, Dev, Partner, Customer, Product 중 하나라도 붙어야 한다.

셋째, 오래된 티켓은 규칙으로 닫는다. 선의로는 잘 안 닫힌다.

넷째, 유상/무상 판단 기준을 문서화한다. AI가 코드를 빨리 짠다고 제품 판단까지 공짜가 되지는 않는다.

다섯째, Agent는 넓게 열지 말고 좁게 성공시킨다. 티켓 분석, 근거 탐색, 다음 질문 생성부터 잘하면 된다.

여섯째, 문서 label과 릴리즈 노트는 CS 속도다. 검색되지 않는 지식은 없는 지식에 가깝다.

일곱째, 감사 대응 같은 반복 고비용 업무는 제품 신호로 본다. 매번 영웅적으로 처리하지 말고 Report / Export / API 후보로 분리한다.

마지막으로: 티켓이 줄어드는 조직은 조용하다

티켓이 줄어드는 조직은 반드시 시끄럽게 일하지 않는다.

오히려 조용하다.

누가 뭘 해야 하는지 안다.
오래된 건 자동으로 정리된다.
고객에게 다음 업데이트 시점이 남는다.
개발로 갈 일은 근거와 함께 간다.
문서로 답할 일은 문서로 답한다.
반복되는 일은 자동화된다.

그럼 회의에서 더 이상 “이 티켓은 어떤 내용이에요?”만 반복하지 않아도 된다.

대신 이런 이야기를 할 수 있다.

여기서 계속 막히네요. 이 마찰을 없애봅시다.

나는 그게 좋은 CS 운영의 출발점이라고 생각한다.

공을 더 많이 던지는 팀이 아니라, 공이 바닥에 떨어지지 않게 흐름을 설계하는 팀.

그런 팀은 티켓을 처리하는 팀을 넘어, 제품을 더 똑똑하게 만드는 팀이 된다.