[Zendesk 고도화] 매크로 활용하기 # 10
#10 CX 담당자와 개발 언어의 관계
지난 챕터를 통해 우리는 젠데스크 매크로를 사용하는 방법과 매크로의 내부메모와 공개답장에 자리표시자(Placeholder)를 사용하는 방법에 대해 이야기했습니다.
이제 진짜 매크로를 통한 젠데스크 고도화의 끝판왕이 나타났습니다.
리퀴드 마크업은 통해 자리표시자로 할 수 없었던 대부분의 일들을 구현할 수 있고,
다른 기능(자동화, 트리거, API 등등)들을 매크로에 연결할 때 중간 다리 역할을 해주는 중요한 녀석입니다.
하지만 리퀴드 마크업 언어(Liquid Mark-Up Language)라는 이름에서 알 수 있듯이,
리퀴드 마크업은 자바(JAVA), 파이썬(Python), C와 같은 개발 언어에 해당합니다.
그래서 이번 시간에는 CX 담당자와 개발 언어에 대한 이야기를 먼저 해보려고 합니다.
CX 담당자인데 개발 언어를 배우라고요?
아니...... 그럼 그냥 내가 개발자를 하죠.
젠데스크 고도화에 대한 칼럼인 줄 알았는데, 갑자기 개발 언어에 대해 이야기한다고 하니까 왠지 CX 담당자인 나랑은 무관한 것 같기도 하고, 너무 멀리 온 것 같은 느낌이 들 수도 있습니다. 이런 건 당연히 개발팀에서 해줘야 하는 것 아닌가?라는 생각이 들 수도 있습니다. 충분히 이해합니다.
무조건 개발 언어를 배워야 한다고 이야기하는 것은 아닙니다.
다만 CX 담당자로서 리퀴드 마크업 언어 정도는 챙겨가면 좋겠다고 제안드리고 싶기는 합니다.
몇 가지 이유를 최대한 쉽게 비개발자인 CX 담당자가 이해할 수 있도록 이야기해 볼게요.
1. 배우기가 무척 쉽습니다.
이와 관련된 밈도 있죠. ”얘들아, 폭력은 정답이 아니야.” / ”HTML은 프로그래밍 언어야.” / (폭력)개발 언어가 어떻게 쉬울 수 있냐고 생각하시겠지만, 개발 언어에도 수많은 카테고리가 있습니다.
일단 크게 프로그래밍 언어와 마크업 언어로 구분할 수 있는데요.
프로그래밍 언어에는 자바(JAVA), 파이썬(Python), C와 같이 우리가 한 번쯤 들어왔을 법한 언어들이 포진되어 있습니다. 이러한 언어들은 당연히 조금 더 복잡하고 배우는데 시간도 오래 걸릴 수밖에 없습니다.
마크업 언어의 대표적인 예가 HTML(Hypertext Markup Language)입니다. 외국에서는 HTML은 프로그래밍 언어가 아니다는 개발자 유머가 수십 개가 넘습니다.
제가 생각할 때 리퀴드는 마크업 언어와 프로그래밍 언어의 중간 어딘가에 존재하는 것 같습니다. HTML을 프로그래밍 언어로 인정하지 않은 가장 큰 이유 중에 하나가 조건문, 변수, 반복 루프(-지금은 무슨 단어인지 모르고 넘어가도 괜찮아요!-)가 존재하지 않는다는 점인데요. 리퀴드는 조건문, 변수, 반복 루프가 존재하기 때문입니다. 하지만 그렇다고 해서 일반적인 프로그래밍 언어처럼 자유로운 활용도와 복잡함을 가진 것은 아닙니다.
리퀴드 언어는 엑셀 함수와 형태가 유사합니다.
엑셀 함수를 한 번이라도 사용해 보셨다면 누구나 쉽게 리퀴드 언어를 배울 수 있습니다.
엑셀 함수를 몰라도 자리 표시자를 이해하셨다면 충분히 사용하실 수 있습니다.
2. 개발자와 소통 능력이 향상됩니다.
최근에 디자이너 중에서 프로그래밍 언어를 공부하는 디자이너들이 늘고 있습니다. 그래서 관련 책이나 교육 영상 콘텐츠도 부쩍 늘어나고 있습니다.
왼쪽은 책 제목이 너무 재미있어서 가져와봤는데요. 디자이너, 기획자, 그리고 우리(CX)가 개발자들에게 요청 사항을 이야기하면 하면 늘 "힘들어요." , "안 돼요."라고 이야기합니다.
안된다고 이야기하는 것은 뭐 그럴 수 있습니다.
왜 안되는지를 물었는데, 그때부터 개발자들이 외계어로 이야기를 시작합니다.
"���ఞఋಉషళ亗ళ 때문에 안됩니다.
이해되시죠? "
저 말을 듣고 우리가 할 수 있는 답변이 뭐가 있겠어요?
"아.... 네..."
라고 대답하고 미팅을 종료해야죠.
하지만 리퀴드 언어에 익숙해지면 다른 언어를 배우거나 개발자와 소통할 때 훨씬 친숙하게 접근할 수 있습니다. 개발자와 소통하는 8차선 고속도로는 아니어도, 신발에 물 안 묻게 하는 징검다리 정도는 리퀴드 언어로 다져 볼 수 있습니다.
3. 젠데스크에서 너무너무 광범위하게 쓰입니다.
단순히 매크로에서만 리퀴든 언어가 쓰이는 것이 아니라 젠데스크를 통해 해야 하는 대부분의 작업에서 리퀴드 언어가 사용됩니다.
예를 들어볼까요?
우리가 매크로를 통해 공개 답장에 고객 이름을 넣는 것은 가능했지만, 티켓 제목에 고객 이름을 넣을 수는 없었습니다. 이걸 가능하게 하려면 API라는 기능을 이용해서 젠데스크 서버에 직접 티켓 제목을 변경해 달라는 명령 요청을 해야 하는데요.
이때에도 리퀴드 마크업이 필요합니다.
제가 첫 주제를 매크로로 시작했던 이유도 매크로의 기능에 익숙해지는 것을 넘어서 자리 표시자와 리퀴드 마크업을 이해하기 제일 좋은 연습 장소였기 때문입니다.
매크로는 일단 한 두 개를 잘못 만들어도 시스템에 큰 영향을 주지 않습니다. 반면에 트리거나 자동화, API 등의 설정을 잘못 등록하거나 수정하는 경우에는 자칫 상담 시스템이 마비될 수도 있습니다. 하지만 매크로는 조건에 따른 자동 실행이 아닌 누군가에 의한 수동 실행이 필요하기 때문에 시스템이 미치는 영향이 없고, 미친다고 하더라도 하나의 티켓에 한정됩니다.
이렇게 젠데스크의 기능을 깊이 알고 싶은 CX 담당자에게 매크로는 자리표시자와 리퀴드 마크업을 연습하는 최적의 장소로 사용될 수 있습니다.
이전 챕터들을 통해 젠데스크 매크로를 배웠고, 자리 표시자를 능숙하게 사용하는 여러분이라면 리퀴드 언어를 통해 젠데스크의 많은 부분을 컨트롤할 수 있는 기회의 발판을 마련할 수 있을 것이라고 생각합니다.
개인적으로 CS와 CX를 구분하는 것을 좋아하지는 않지만요,
CS 담당자로 고객의 불만을 해결하는 것에만 오로지 중점을 두었다가,
CX 담당자로 고객의 경험 전반을 관리해야 하는 직무로 변화했다고 가정해 보죠.
관리하는 범위가 늘어나게 된다면, 내가 소통해야 하는 대상이 늘어나는 것은 너무 당연하죠.
CS 담당자 시절에는 고객의 언어를 듣고 말하는 것에 국한되어 있었다면,
CX 담당자 시절에는 고객의 언어, 개발자의 언어, 영업의 언어, 디자이너의 언어를 듣고 말하는 것에 익숙해져야겠죠.
개발자의 입장에서 생각해 볼까요?
개발 관련 지식이 전혀 없는 CX 담당자와,
직접 개발을 하는 것은 아니더라도 개발 언어를 조금 이해하는 CX 담당자 중에
누구와 일을 하는 것이 더 좋은 업무 효율을 낼 수 있을까요?
네. 우리가 리퀴드 언어에 한번 발을 담가봐야 할 이유가 그 대답 안에 있습니다.
감사합니다.
