AI로 반복 업무를 줄인 이야기: VOC 조회 자동화

작성자 웅진씽크빅 IT혁신본부 김민지 연구원, 서비스기획 / Minji Kim

Created with Claude Design

1. “진도변경이 안 됩니다”

현장에서 VOC가 하나 들어온다. 메신저일 때도 있고, Jira 이슈일 때도 있다. 내용은 대체로 이렇게 온다.

교사사번: xxxxxxxx
회원번호: xxxxxxxx
패드시리얼: xxxxxxxxxxxx
오류내용: LMS에서 진도변경을 진행했는데 진도변경이 되지않습니다.

이 문의 하나에 답하려면, 담당자는 이런 경로를 지나야 했다.

VOC 하나를 처리하기 위해 거쳐야했던 7단계

BCMS(백오피스)에 들어가 QAS(고객 정보 확인 메뉴)에서 고객번호를 검색하고, 계약번호를 확인하고, 멤버십과 오더를 훑고, 그 값을 들고 이번엔 LMS(학습관리시스템)에 다시 로그인해서 회원을 검색하고, 그제서야 학습 이력을 본다. 중간중간 번호를 복사해 다른 창에 붙여넣는 일이 계속 반복된다.

하나의 VOC를 확인하기 위해 대략 일곱 단계를 거쳐야 했다.

문제는 이 일곱 단계 중에 판단이 필요한 구간이 거의 없다는 것이었다. 사번을 복사해서 다른 시스템 검색창에 붙여넣는 데는 경력도 창의력도 필요 없다. 그런데도 창을 잘못 열거나 번호를 한 자리 흘리면 그 시간은 그대로 날아갔다.

VOC 처리는 우리 팀 업무의 1순위다. 1순위 업무가 이렇게 굴러가고 있다는 게 마음에 걸렸다.

2. 진짜 문제는 ‘단계 수’가 아니었다

처음엔 “일곱 단계를 몇 단계로 줄일까”를 생각했다. 그런데 업무 과정을 하나씩 뜯어보니, 진짜 불편함은 단계의 개수보다 다른 곳에 있었다.

첫째, 문맥 전환이다. BCMS와 LMS는 별개의 시스템이고, 각각 로그인이 필요하다. 화면을 옮겨 다니는 동안 담당자의 머릿속에서는 “지금 내가 어느 번호를 들고 어디로 가는 중이었지”를 계속 붙잡고 있어야 한다. 단계가 일곱 개라는 것보다, 끊기는 지점이 일곱 개라는 게 문제였다.

둘째, 사람이 옮겨 적는 번호다. 교사 사번, 회원번호, 계약번호, 시리얼 번호. 자릿수가 길고 서로 닮았다. 복사-붙여넣기 자체는 1초지만, 잘못 옮겼을 때 그걸 알아차리는 데는 몇 분이 걸린다.

셋째, 목적지는 늘 같았다. 이 일곱 단계의 끝은 결국 “LMS 학습 이력 화면”이었다. 매번 다른 곳을 헤매는 게 아니라, 알고 보면 늘 같은 한 페이지로 가는 길을 매번 새로 걷고 있었던 것이다.

세 번째를 깨닫고 나니 질문이 바뀌었다.

“단계를 어떻게 줄이지?” → “필요한 값을 이용해 LMS 학습 이력 화면의 링크를 바로 만들어주면 되지 않나?”

3. 완전 자동화를 목표로 하지 않았다

처음부터 VOC 처리 전체를 자동화하려고 하지는 않았다.

VOC를 처리하려면 담당자의 판단이 필요하다. 실제 오류인지, 사용 방법의 문제인지, 데이터를 수정해야 하는지, 개발팀에 전달해야 하는지는 학습 이력을 확인한 담당 기획자가 결정해야 한다.

회원 데이터를 자동으로 조회해 원인까지 요약하는 방식도 생각할 수 있다. 하지만 그렇게 하면 개인정보를 다루는 범위가 넓어지고, 잘못된 요약 결과를 담당자가 그대로 받아들일 가능성도 있다.

그래서 사람과 자동화가 담당할 범위를 나눴다.

• 사람이 판단하는 것 — 이력을 보고 원인을 규명하고, 처리 방향을 정하는 일
• 기계가 반복하는 것 — 번호를 찾아 옮기고, 목적지 화면까지 데려다주는 일

목표는 “AI가 VOC를 처리한다”가 아니었다. 담당자가 원인 확인을 시작할 수 있는 화면까지 바로 이동하게 하는 것이었다.

이렇게 범위를 좁힌 덕에, 첫 결과물이 며칠 만에 나왔다.

4. 프롬프트 세 개로 만든 것들

여기서부터가 이 사례의 핵심인데, 사실 특별한 방법론은 없었다. 평소 손으로 하던 일을 그대로 말로 옮겨 AI에게 넘겼다. 설계 문서를 쓰거나 함수 구조를 잡고 시작한 게 아니라, “이게 불편하다”를 문장으로 만들어 던지고 나온 결과물을 써보고 부족한 부분을 다시 수정했다.

이 방식이 가능했던 이유는 새로운 업무를 만드는 것이 아니라, 이미 반복하고 있던 업무를 자동화하는 일이었기 때문이다. 담당자는 어떤 값을 어디에서 확인하고, 최종적으로 어느 화면을 봐야 하는지 이미 알고 있었다. 이 과정을 문장으로 정리한 것이 기능 요구사항이 됐다.

결과적으로 아래 세 개의 프롬프트가 이 프로젝트의 주요 요구사항이었다.

4–1. 적용 — 고객번호 하나로 LMS까지

첫 번째 프롬프트는 이거였다.

💬 "BCMS에서 고객번호 하나만 입력하면 LMS 링크를 바로 연결하는 방법을 알려줘"

핵심은 단순하다. BCMS에서 조회한 정보와 LMS 조회 URL 사이에는 일정한 규칙이 있었다. 기존에는 담당자가 고객정보를 검색하고, 멤버십과 오더를 확인한 뒤, 값을 복사해 LMS에서 다시 회원을 검색했다. 입력값과 URL 생성 규칙이 일정하다면 사람이 매번 같은 작업을 반복할 필요는 없었다.

결과적으로 멤버십 조회 → 오더 조회 → LMS 로그인 → 회원검색 이 네 단계가 링크 클릭 한 번으로 접혔다.

네 단계가 ‘AI 적용 — LMS 링크 자동화’ 한 구간으로 접혔다

4–2. 응용 — Jira 이슈를 열면 이미 링크가 붙어 있게

첫 번째 기능을 사용하면서 남아 있는 불편을 발견했다. LMS 링크를 만들려면 담당자가 Jira 이슈에 적힌 사번이나 고객번호를 직접 복사해 BCMS에 입력해야 했다. 그리고 그 사번은 대부분 Jira의 VOC 이슈(VC 프로젝트) 본문에 이미 적혀 있었다.

그래서 두 번째 프롬프트.

💬 "Jira VC 이슈 페이지에서 교사 사번을 추출하여 LMS 링크 생성해서 같이 보여줘."

이제 VOC 이슈를 열면 설명란에 이런 표가 함께 보인다.

jira 예시화면 이슈를 열면 교사 링크 함께 노출

담당자는 이슈를 읽다가 그 자리에서 링크를 누르면 된다. 사번을 찾아 드래그하고, 복사한 뒤, 별도의 화면에 붙여넣는 과정이 사라졌다.

이 변화가 작아 보여도 체감은 컸다. “필요할 때 도구를 실행한다”에서 “일하던 화면에 이미 준비돼 있다”로 성격이 바뀐 것이기 때문이다. 담당자가 도구의 존재를 기억할 필요조차 없어졌다.

4–3. 확대 — 메신저에서 드래그만 해도 바로 이동

사내 메신저(Works)로 오는 문의

VOC가 Jira로만 들어오는 건 아니다. 오히려 급한 건은 대부분 Works 메신저로 온다. Jira에서는 LMS 링크가 자동으로 생성됐지만, 메신저로 들어온 문의는 여전히 번호를 복사해 직접 조회해야 했다.

그래서 세 번째 프롬프트는 이랬다.

💬 "웹이나 Works 메신저에서 드래그나 Ctrl+C만 해도 링크를 바로 생성해서 말풍선으로 보여줘."

이제 메신저 대화 속 교사사번: xxxxxxxx에서 교사 사번을 드래그하면, 그 자리에 말풍선이 뜬다.

교사 상세페이지로 이동하시겠어요? (xxxxxxxx)

드래그만 하면 바로 말풍선 링크가 나오는 데스크탑 응용프로그램

드래그만 하면 바로 이동 제안이 뜬다

담당자가 말풍선을 클릭하면 LMS 대상 화면으로 바로 이동한다.

이를 통해 Jira와 Works 메신저 중 어느 경로로 VOC가 들어오더라도 비슷한 방식으로 학습 이력을 조회할 수 있게 됐다.

5. 그래서 무엇이 달라졌나

첫째, VOC 업무 시간이 줄었다. VOC 한 건의 학습 이력을 조회하는 시간이 약 180초에서 5초로 줄었다. 기존 대비 약 97% 단축된 결과다. 줄어든 것은 원인을 분석하는 시간이 아니라, 시스템 로그인과 검색, 번호 복사, 회원 조회처럼 판단이 필요하지 않은 과정이다.

둘째, 실수가 나올 자리가 사라졌다. Jira나 메신저에 입력된 값을 기준으로 링크가 자동 생성되기 때문에, 번호를 잘못 복사하거나 일부 숫자를 빠뜨리는 실수를 줄일 수 있었다.

셋째, 처리 품질이 균일해졌다. 담당자마다 달랐던 조회 순서가 링크 클릭 방식으로 통일됐다. 신규 담당자도 복잡한 조회 경로를 따로 익힐 필요가 줄었다.

6. 마치며 — 작게 시작해서, 자연스럽게 확장되었다

최종 프로세스

1. 적용 — 일단 한 구간만 줄여봤다 (BCMS → LMS 링크 자동화)
2. 응용 — 쓰다 보니 아쉬운 게 보여서 Jira로 옮겼다
3. 확대 — 인입 경로 전체(메신저)로 넓혔다

처음부터 “VOC 처리 프로세스 전면 자동화” 같은 걸 기획했다면, 아마 요구사항 정의만 하다가 끝났을 것이다. 우리는 그냥 제일 손이 많이 갔던 구간 하나를 프롬프트 한 줄로 줄여봤고, 그게 되니까 다음이 보였다. 자동화는 설계도를 다 그린 다음 시작하는 게 아니라, 한 칸 줄인 뒤에 다음 칸이 보이는 일에 가까웠다.

그리고 한 가지 확실하게 배운 게 있다. AI는 “이 업무가 어떻게 굴러가는지”를 대신 알아내 주지는 않는다는 점이다.

프롬프트 세 문장이 짧아 보이지만, 그 문장을 쓸 수 있었던 건 담당자가 이미 그 일곱 단계를 수백 번 걸어봤기 때문이다. 어느 구간이 접히는지, 목적지가 늘 같다는 사실, 어디부터는 사람이 판단해야 하는지 — 전부 매일 그 일을 해본 사람만 아는 것들이었다. 무엇을 시켜야 하는지 아는 사람만이 그 짧은 문장을 쓸 수 있다.

이 방식이 통했던 건 만들려는 게 이미 우리가 매일 손으로 하던 일이었기 때문이다. 무엇을 만들어야 하는지 스스로 모르는 상태에서 AI에게 물으면, AI도 똑같이 모른다.

주변에도 매일 반복하지만 판단은 거의 필요하지 않은 업무가 있을 것이다.

여러 시스템에 접속하고, 같은 값을 반복해서 입력하고, 마지막에는 항상 같은 화면을 확인하는 업무라면 자동화할 수 있는 구간이 있는지 살펴볼 수 있다.

전체 업무를 한 번에 자동화하기보다, 가장 반복이 많은 조회나 입력 과정부터 적용해보는 것을 권한다.

읽어주셔서 감사합니다.