Search
🌖

[호스트인터뷰] CXCK의 시작을 이끈 주인공 ‘배경원’님

태그
Offline
Interview
생성일
2023/09/20 05:35
해당 인터뷰는 보다 많은 CX 담당자들이 업무에 있어 전문성을 갖추는 일에 동기부여를 얻을 수 있도록 하고자 하는 목적으로 추진되었습니다. 더 많은 인터뷰는 cxck.oopy.io 에서 만나보실 수 있습니다.
Interviewee Profile
이름: 배경원 / 닉네임: 미아(Mia)
Linked In: Kyeongwon Bae
MBTI: ENTP
외향적인 것 처럼 보이지만, 사실은 내향적입니다.
인터뷰 배경
CXCK 호스트 1호
現 iOS 개발자 (前 채널톡 CX 오퍼레이터)
TMI
고양이 두부와 함께 살고 있어요.
클라이밍에 푹 빠져있어요!
인터뷰를 통해 다음과 같은 내용을 얻어가실 수 있어요!
1.
CXCK 의 시작: 왜, 어떻게 운영했는지 알 수 있어요.
2.
오퍼레이터: 오퍼레이터를 이렇게 정의했어요.
3.
iOS 개발자: 개발자로 직군 전환은 이렇게 했어요.
파트별 요약도 있어요. 급하신 분들은, [Prat Summary] 클릭해서 확인해주세요

- 1부 - CXCK 의 시작 & 오퍼레이터 경험

CXCK 의 시작

간단하게 자기소개 부탁드립니다.
저는 CXCK 에서 호스트로 활동하고 있는 배경원이라고 합니다.
지금 가상자산 거래소를 서비스하고 있는 회사에서 iOS 개발자로 일하고 있으면서 CXCK 운영에도 열심히 참여하고 있습니다.
CXCK를 언제부터, 왜 하게 되셨는지 알려주세요
처음에 CXCK를 만들어야겠다고 생각한 것은 2020년 정도예요. 제가 IT 분야로 처음 이직을 하면서 업무 지식이 없는 상태로 처음 맡은 포지션이 CX 오퍼레이터 포지션이었습니다. 그때 채널톡(현 채널)에 처음 입사를 하게되었고요.
입사하고 보니, 막상 뭔가 아무것도 없는 것 같은데, 뭔가를 만들어야 될 것 같은데… 하는 아리송함이 있지만, 채널톡 내에는 사수가 없어서 질문할 곳이 필요하다는 생각이 들었습니다. 또, 마침 채널톡은 고객사가 사실 저보다 경험이 훨씬 풍부하신 오퍼레이터 분들이 많은 도메인적인 특성이 있어서 ‘경력이 있으신 분들을 모시고 주기적으로 이야기를 듣거나 또는 편하게 뭔가 물어볼 수 있는 장이 필요하겠다, 또 같은 일을 하면서 고민을 좀 공유할 수 있는 곳이 필요하겠다’라는 생각이 들어서 채널톡 동료 였던 분과 만들게 되었습니다.
이제 CXCK 도 4년 차인데, 그동안 어떻게 운영을 하셨나요?
사실 각 잡고 매주 뭔가를 해내지는 못했어요. 운영하는 3, 4년 동안 괄목할 만한 뭔가를 보여 드리지는 못한 것 같다는 것이 지금 생각입니다. 다만, 포기하지 않고, 가끔 일정이 되시는 분들과 밋업도 하고, 질문도 서로 올려주시면 답변도 하고 이런식으로 일상처럼 그냥 가져가니까 어찌 저찌 3년, 4년이 된 것 같아요.
처음 커뮤니티가 만들어졌을 때 주변 반응들이 어땠는지 기억 나시나요?
그때는 친한 고객사분들 그리고 저랑 연차도 비슷하신 분들, 저한테 직접적으로 가르쳐주시려고 하시는 분들… 이런 분들과 함께 7~9명 이렇게 해서 발대를 했던 방이거든요.
그러니까 사실 지금 이렇게 막 400명까지 커질지 생각 못하고 시작했던 거라서 처음에는 ‘뭐 한 30명 40명 올해 안에 되면 성공 아니야?’ 이렇게 생각하고 시작했던 건데 이렇게까지 성장하게 된 것은 예상한 바는 아니었어요. 그래서 그 당시에 모여주신 분들이 이런 소통할 수 있는 공간이 필요하다고 검증해 주신 것이라고 생각합니다.
4년차에 접어든 지금 460명이 넘게 커뮤니티에 모여있어요. 소회가 어떤지 한번 얘기 해 주세요.
이 업계로 처음 진입 하신 분들에게, 혹은 일을 하고는 계시지만 질문에 답을 구하기 어려운 환경인 분들에게 다른 사람들이 선의로 ‘일하는 방법’이라든지, ‘일에 대한 생각’을 나누고, 서로 알려주는 커뮤니티가 되었잖아요.
이런 문화(서로가 서로에게 지식을 나누는)가 사실 스타트업 전반에 퍼져 있는 문화이고 CX도 마찬가지로 “스타트업의 CX”라는 관점 안에서 문화를 잘 따라간 게 아닌가하고 평가를 하게 됩니다. 특히 이런 부분이 고무적이라고 생각해요. 자기만의 소중한 노하우들을 정말 어떤 대가도 없이 공유할 수 있는 장이 생긴 것 그것만으로도 굉장히 좋은 것 같아요.
특히나 지금 호스트로 수고해 주고 계시는 유진님이 첫 100명, 200명 만드는 어려운 과정에 정말 기여를 많이 해주셨어요. 그리고 스노우볼 굴리는데 대가(댓가)없이 도와주신 분들 세션 스피커(발표자) 분들 있으셔서 지금 CXCK가 있지 않나 생각합니다. 이 자리를 빌어 감사하다고 인사를 드려봅니다. 감사합니다.
어떤 커뮤니티를 지향하고 계시는지 궁금합니다.
이 부분은 사실 머릿속에 명확하게 그리고 있는 그림이 따로 있는 건 아니예요.
제가 스타트업에서 되게 좋아하는 문화, 아까 언급한 것처럼, “뭔가를 대가를 바라지 않고 서로의 성장을 위해서 뭔가를 공유할 수 있는 문화가 오퍼레이션 CX신 (CX scene)에도 더 뿌리깊게 적용이 됐으면 좋겠다.”
이 정도가 있고 앞으로는 아마 멤버분들이나 또 이번에 새로 합류하신 호스트 분들과 방향성을 논의하면서, 그리고 실현을 하면서 함께 쫓아가고 싶은 마음이 많이 드는 것 같아요.
CXCK를 운영하시면서 좀 가장 기억에 남는 활동이나 인터뷰, 강연 같은 것이 있으시다면 소개해 주세요.
아마 제일 공을 많이 들였던 게 재작년에 했던 VOC 분석 세션인데요, 그때 송인근님 외 다양한 분들이 연사로 참여해 주시기도 하셨고, 디자인도 하고, 신청도 받고 또, 완전 무료로 진행하기도 했고요. 당시 약 100명여 넘는 분들이 실시간으로 참여를 해주시고. CXCK 사상 가장 컸던 온라인 콘퍼런스라고 해야할까요? 그래서 그게 되게 기억에 남습니다. 그때 이후로 그 정도 규모의 콘퍼런스는 아직 진행한 적이 없는데, 기회가 되면 커뮤니티에 모여계시는 분들의 니즈가 많은 세션을 또 해보고 싶어요.
최근에는 커뮤니티 초기에 뽀짝뽀짝 작게나마라도 운영했던 인터뷰들이 침체되어 있는 듯 했으나 예진님이 새롭게 호스트로 조인하시면서 승훈님 인터뷰 발행하신 것도 기억에 남는 콘텐츠로 꼽을 수 있을 것 같습니다.
저도 그 세션에 참여했던 기억이 납니다. 함께 참여자 수를 보거나, 질문이 끊임없이 올라오는 것을 보면서 저는 “오퍼레이터 분들도 함께 나누고, 질문할 수 있는 장이 필요 했다” 에 대한 검증이 아니었나. 하는 생각이 들었어요.
사실 인근님 세션이 어떻게 보면 실무에 적용할 수 있는 방법을 대부분 공개해주신 케이스였는데요. 그러니까 정말 ‘모두사인에서는 이런 부분을 자동화를 했다.’ 이런 것들을 실제로 사용하시는 툴 등을 보여주시면서 설명해주시는 케이스였어요. 자동화, 플로우 정리 등에 대해 폭발적으로 질문이 많이 올라오고, 궁금해 하시는게 확인 되더라고요.
저는 그 상황을 보면서 오퍼레이터 업계에서 “실무에서 일하는 방식 등이 충분히 공유가 안 되어있다.” 또, “자동화를 통해 단순하고 반복되는 업무로부터의 탈피를 중요하게 생각하고 있다”는 느낌을 많이 받았어요.
이번에 이건 좀 딴 얘기인데.. 최근 iOS 개발자들만 모이는 콘퍼런스를 코엑스에서 했었어요.
전국에서 천 명 정도 와서 트랙도 다양하게 진행 했거든요. 그렇게 참석하는 것을 보니까 우리(CXCK커뮤니티)도 천 명은 아니더라도 300명이 모이는 콘퍼런스를 할 수 있지 않을까 이런 생각이 들더라고요.
저희 같은 경우에는 채용 관련 세션도 이전에 이미 있기도 했고, CX 관련해서 대규모 채용을 원하는 곳 들로부터 후원을 받으면 충분히 오프라인 세션을 할 수 있지 않을까. 그리고 우리가 한다면 풍부한 내용으로 구성하여 얘기할 수 있는 분들 모실 수 있으면 좋을 것이라고 생각했어요.

[Part Summary] CXCK 의 시작

WOW! 실제 오프라인에서 진행하는 콘퍼런스를 오퍼레이터 씬에서도 기대해볼 수 있겠네요!
1.
CXCK 의 시작 이유는 다음과 같아요.
경력이 있으신 분들을 모시고 주기적으로 이야기를 들을 곳..!
편하게 뭔가 물어볼 수 있는 장도 있으면 좋겠고..!
같은 일을 하면서 고민을 좀 공유할 수 있는 곳이 있기를..!
2.
지향하는 커뮤니티는 아래와 같다고 합니다.
자기만의 소중한 노하우들을 정말 어떤 대가도 없이 공유할 수 있는 장
뭔가를 대가를 바라지 않고 서로의 성장을 위해서 뭔가를 공유할 수 있는 문화가 오퍼레이션 CX신 (CX scene)에도 더 뿌리깊게 적용이 됐으면..
3.
지금의 오퍼레이터 분들은 다음을 원하시는 것 같아요.
실무에서 일하는 방식 등이 공유가 안 돼 있어, 정보를 찾고 싶어한다.
자동화를 통해 단순하고 반복되는 업무로부터의 탈피를 중요하게 생각하고 있다.

CX 오퍼레이터로 일하며.

CXCK를 하게 되신 그 당시에는 어떤 업무들을 주로 하셨었나요?
그때 채널톡 입사하자마자 저는 입사 첫날부터 상담을 몇 백 개씩 했어요. 왜냐하면 그때가 딱 그 채널톡이 약간 2.0 같은 느낌으로 모든 기능을 다 엎은 날에 제가 간 거예요. 제품을 익히기도 전에 상담으로 ‘죄송합니다’부터 하고 이제 시작했고, 그게 잔잔해지고 나서는 하루의 전부를 상담에 갈아넣었죠.
그래서 그때 막 CX 오퍼레이터는 뭐 하는 건지도 모르지만 일단 몸으로 부딪히면서 제품을 알아가는 시기가 좀 있었어요. 채널은 당시에 전화상담을 안 받았고 무조건 99% 채팅으로만 응대를 했어요. 그러면서 이제 제품을 또 두들겨 맞으면서 배웠죠.(ㅎㅎ)
그리고 입사했을 때가 스물 몇 명 있을 때 들어갔는데 그때까지만 해도 CX 매니저가 따로 있는 게 아니라 개발자, 디자이너 무관하게 모두가 상담을 한다는 기조를 유지하고 있었어요. 아마 지금도 그럴 거예요.
그런 기조가 있던 때에 CX를 전담으로 맡아서 할 사람을 처음으로 뽑은 게 저였어요. 경험이 없는 사람이 CX 오퍼레이터가 된 거였기 때문에 이제 상담하고 그냥 6시 되면 녹초 돼서 집에 가고 이렇게 반복을 했죠. 이렇게 반복하면서 보니까 똑같은 걸 여러 사람이 돌아가면서 문의를 하는 거예요.
근데 뭔가 챗봇 같은 걸로 해결하는 것도 한계가 있는지, 잘 해소가 안되었어요. 그래서 가이드가 필요하다고 제안을 했는데, “가이드 없이 인지가 되는 프로덕트가 좋은 거다.” 라고 말을 하더라고요. 그래도 이런 부분은 필요하다고 생각하고 임의로 그냥 가이드를 만들었어요. 대신, 노션으로 만들면서 GA(Google Analytics)를 붙여놓고 유저 얼마나 들어오는지 한번 보자 이랬는데 폭발적으로 많이 들어온 거예요. 그때 당시 DAU(Daily Active User)의 거의 한 20~30% 정도가 가이드를 계속 보는 정도의 수치가 나왔어요. 그래서 이 데이터를 가지고 필요하다고 다시 얘기를 했죠. 데이터를 가지고 설득이 된거예요. 그래서 이제 가이드를 만들고 관리하는게 회사 단위의 프로젝트가 되었고, CX매니저가 관리하는 업무가 되었어요.
그 다음으로 했던게 이제 신규 기능을 굉장히 열심히 내는 팀인데 유저분들이 신규 기능이 나왔는지 아무도 모르는 거예요. 그래서 왜 아무도 모르지? 하고 보니, 신규 기능이 나왔다고 바로 알리지 않으니 알 수가 없었어요. 알아보니 거의 반기에 한 번 신규기능을 취합해서 알리고 있었는데, 이왕이면 멋있게 소개를 하고 싶은거예요. ‘사고 싶게, 구독하고 싶게 신규기능 안내를 만들고 싶다’ 라고 제안하면서, 업데이트 노트를 작성을 하기 시작했어요. 그러면서 업데이트 노트를 기다려주시는 분들도 생기고 그러면서 내가 할 역할을 이렇게 정의하게 된 것 같아요.
“회사에서 만들어지는 프로덕트와 유저들 간에 말하자면 통역사 같은 그런 역할”을 해야겠다.
이렇게 업무를 하게 되고, 업무들을 찾고나서는 회사 내에서 “프로덕트 오퍼레이터”라는 이름을 달라고 했죠.
당시 채널 쪽은 어떻게 합류하기로 결정하신건가요?
제가 중학교, 고등학교, 대학교를 같이 나온 친구가 있었어요. (WOW)
그 친구는 솔루션 영업 세일즈를 계속 하고 있던 친구였고 그 친구가 먼저 채널톡이 정말 정말 정말 규모가 작을 때 조인을 했죠. 저는 그때 스포츠에이전트 일을 하다가 모 신문사에서 스포츠 대회를 오거나이징을 하는 팀에서 일을 하고 있었어요. 육상 선수 에이전트를 열심히 하고 있었는데 갑자기 코로나가 터지면서 대회가 다 취소되고 갑자기 업무가 통째로 날아간거예요.
그러다보니 출근해서 맨날 그냥 우두커니 앉아 있고, 나는 아직 이십대인데 이러고 있어도 되나 이런 고민을 하고 있었죠. 어쨌든 놀고만 있을 수는 없으니, 다음 행사 기획도하고 있기도 했는데, 그때도 저는 워커홀릭이어서 주말에 그 친구 집에 가서 노트북 켜놓고 기획하고 막 이랬거든요.
근데 그 친구가 ‘너 이렇게 일을 하는 거를 좋아하면 너 우리 회사에 오면 진짜 잘 맞겠다.’ 라고 하길래 ‘난 IT도 모르고 뭐 내가 할 수 있는 게 뭐가 있냐’ 반문을 했죠. 그 친구가 ‘지금 채용하는 직군 중에 과거 이력 무관한 직군이 있다. CX 오퍼레이터.’ 라고 해서 이제 그 당시에는 CX 오퍼레이션이 뭔지도 모르고 지원을 한 거죠. 어쨌든 감사하게 뽑아주셔서 그냥 일을 했던 거고 그게 그렇게 첫 시작이죠. CX 뭔지도 모르고 천둥벌거숭이처럼!
그러다가 CXCK 도 시작하고, 가이드 관리하고, 업데이트 노트도 만들고, 유저들과 소통도하는 오퍼레이터 업무를 감사히도 시작하게 되었던 것 같아요.
실제로 업무를 하시면서 상담을 하는 일하고 사실 어떻게 보면 가이드를 만들고, 업데이트 노트를 만드는 영역은 기획에 가까운 영역이라고 보여요. 각 업무의 비중이 어느 정도였나요?
그때 되게 리소스를 넉넉하게 주지 않는 상태에서 였어요. 상담시간은 10시부터 5시까지였고 그때는 상담하고 회의만 갔다 와도 거의 완전 full resource 사용이었어요. 그러다보니, 다른 업무들을 하려니 거의 퇴근을 계속 11시 또는 12시 이때 했던 것 같아요. 퇴사할 때까지도요.
이게 참 딜레마인게… 인원을 무작정 늘릴 수는 없는상황인데, 회사가 잘 되면 상담은 늘고, 근데 내가 욕심이 있으면 이제 시간을 갈아넣어야 되는 것들이… 어려운 포인트 인 것 같아요. 그때 당시에 cx 오퍼레이터들의 고질적인 문제라고 생각하긴 했었죠. 요즘 그 시절을 되돌아보면, 되게 이거 되게 쉽게 해결할 수 있었는데 못한 부분들도 많았다는 생각이 들더라고요.
조금 더 자동화가 됐더라면, 다른 업무를 할 시간을 조금 더 확보하고 11시에 맨날 퇴근하면서 너무 지치도록 일을 하는 상황을 조금이라도 방지할 수 있었을 것이라는 아쉬움이 남더라고요. 그때는 하여튼 그냥 두 명이 일하는 것처럼 한 명이 그냥 일을 했다. 어쩔 수 없이 그때는 그랬어요.
그럼 일하시면서 가장 답답했던 포인트는 무엇이었어요? 그럼에도 11시, 12시까지 일할 수 있었던 동기(모티베이션)가 되었던 포인트는 무엇이 있으셨어요?
답답하거나 힘들었던 거는 그러니까 CX가 사실 경험을 아무리 좋게 만들고 이 사람들이 원하는 정보를 빨리 찾게 만들어주고 헤매지 않게 해줘도 회사가 성장을 하면 어쩔 수 없이 볼륨이 늘어나는데 이제 인하우스에서 모든 CS를 다 처리하다 보니까 이게 사람이 그렇게 비례해서 늘 수가 없잖아요.
그래서 내가 효율화를 하고 내가 더 좋게 만들어도 일단 볼륨이 계속는다는 게 엄청 그 당시에는 체력적으로는 정신적으로 좀 많은 스트레스였어요.
그래도 모티베이션이 많이 됐다고 생각하는 부분은, 당시 채널톡 유저분들이랑 고객사 이상으로 관계가 가까웠어요. CX 오퍼레이터 입장으로 CX 오퍼레이터 분들을 고객사로 이제 만나다 보니까 공감도 많이 되고 같은 툴을 사용해서 같이 일을 하고 있다 보니까 이분들이 ‘뭐가 좋아요, 이런 부분은 개선되면 좋겠어요’ 이런 부분을 사석에서든 어디서나 따로 들을 수 있었어요. 그러다보니 ‘역시 빨리 해줘야겠다.’ 이런 책임감 같은 그런 뭔가 알 수 없는 동기 부여가 많이 됐었던 것 같아요!
제가 알고 있기로는 업무를 11시 12시까지 하시면서도 동시에 개발 공부도 같이 병행 하셨다고 들었어요.
당시 제공했던 서비스가 사용하시는 분들이 그 분들의 프로덕트에 설치를 해야만 사용할 수 있는 것을 지원했잖아요. 사용자분들이 채널톡 설치하는 방법을 문의를 주시거나, 설치했는데 뭐가 이상해요, 둥둥이(채널톡의 아이콘)가 안 나와요, 들어갔는데 갑자기 다른 사람 이름이 나와요.
이런 문의들이 들어 왔을 때, 그냥 앵무새처럼 여기 여기를 확인해 보세요 하고 했는데 뭔가 조금만 더 깊은 문제가 나오면 바로 이제 개발자한테 토스해야 되고… 반복되는 질문인데 답변을 이해를 잘 못했던거 같아요.
조금만 개발적인 부분을 보면 알 수 있을 것 같아가지고 내가 한번 설치를 직접 해볼까 하고 공부를 조금씩 하면서 사용자 분들에게 알려드렸어요. 그렇게 조금씩 하던 게 프로덕트의 작동 원리를 이해하는 데 도움이 많이 되었는데, 이게 제 업무(고객을 지원하는 일)를 하면서도 도움이 많이 되더라고요.
이 부분은 제가 특별했다는게 아니라, 각자의 분야에서 전문가가 되는 그런 단계였던 것 같아요. 저는 판매했던 제품이 IT 제품이었기 때문에 설치, 설치 후 오류 등이 나오니까 이런 부분에서 공부를 했던 것이고요.
주얼리 분야에 계시면, 주얼리에 대한 이해도가 높아지거나, 펀딩 분야에 계시다면 펀드레이저의 마음을 얼마나 이해할 수 있는.. 그런 도메인에 따른 특화 분야가 되는 것 같아요.
그렇게 도메인에 대한 전문적인 지식이 쌓이고, 각 도메인에 따른 유저의 마음을 대변할 수 있게 되면서, 회사 내부와 소통할 때에 고객의 온도에 따라서 전달하고, 설득하고 그렇게 하면서 조금씩 해결이 되는 그러한 경험을 했던게 제가 더 애정을 가지고 이렇게 일을 할 수 있었던 것 같아요.
중요한 경험인 것 같아요. 고객의 불편함을 회사 내부와 소통하면서 개선했다는 점. 그리고 그러한 사이클을 돌면서, 설득하기도 하고. 그럼, 경원님이 생각하시기에 오퍼레이터에게 꼭 이 능력이 있으면 좋겠다고 추천해주실 스킬셋이 있을까요?
아시다시피 제 운영 업력은 짧은 편이어서 지금 이미 현업에서 열심히 하고 계신 분들한테 뭔가 이렇게 조언 같은 거를 감히 할 수 있는 상황은 아닌 것 같아요.
다만, 제가 느꼈을 때 운영을 하시는 분들을 계속 리스펙 하는 부분은… 유저의 문제를 집요하게 풀어주려고 하는 태도이자 그리고 그런 분들이 사람들이 많이 모여 있다는 점이예요. 또, 일을 잘하려고 하는 욕심이 있으신 분들도 계시는데, 그 분들은 문제 해결력을 높이기 위해서라도 본인의 남은 시간을 자기 계발에 투자해도 좋다고 생각하시기도 하는 부분들이 굉장히 존경스러운 부분이기도 합니다.
어쨌든 유저의 문제를 해결하고 싶은 상황들을 마주할 때, 여러 방법을 써보면서, 해결 방안을 찾아 보잖아요. 업무 범위에 상관 없이, A 라는 방법이 안되면, B 로 시도해보고. 그런 다음 단발성 해결해 줬다고 하더라도 장기적으로는 유저가 같은 경험을 하지 않게 하는 것. 그게 또 유저 경험을 개선하는 거니까 문제 해결을 하려고 집요하게 파고드는 능력이 참 도움이 많이 되는 것 같아요.

[Part Summary] CX 오퍼레이터로 일하며.

채널 합류는 오랜 친구로부터 제안받았다고 해요!
1.
CX 오퍼레이터의 업무를 정의했어요.
Product Operator = 회사에서 만들어지는 프로덕트와 유저들 간에 말하자면 통역사
추가로 했던 업무1: 가이드가 필요 인지 → 제안(거절) → 임의 설정 → 데이터로 설득 = 결과: 가이드 관리
추가로 했던 업무2: 업데이트 노트 → 제안 = 결과: 업데이트 노트 관리
2.
고객 상담과 추가업무의 비중과 답답했던, 동기부여가 되었던 포인트는 아래와 같아요.
업무 비중 : 상담시간은 10시부터 5시까지 그리고 다른 업무들을 하려니 거의 퇴근을 계속 11시 또는 12시 까지 업무 진행
오퍼레이터의 고충: 회사가 성장하면, 문의가 많아진다 → 인원을 비례해서 늘릴 수 없다 → 담당자가 대신 고통받으며 일해야한다. (반복)
위와 같은 상황이 벌어지니, 체력이 떨어지면서, 스트레스 동반
동기부여
동일한 프로덕트를 사용하는 분들의 피드백을 받으면서 그에 따른 책임감
도메인 전문적인 지식이 쌓이고, 각 도메인에 따른 유저의 마음을 대변할 수 있게 되면서, 회사와 소통할 때에 고객의 온도에 따라서 전달하고, 설득하면서 조금씩 해결이 되는 경험
3.
오퍼레이터에게 필요한 능력으로는 다음을 뽑을 수 있어요.
유저의 문제를 집요하게 풀어주려고 하는 태도 = 문제해결능력 + 집요함
문제 해결력을 높이기 위한 자기 계발에 투자하는 태도

- 2부 - 오퍼레이터에서 개발자로

오퍼레이터에서 개발자로

개발 직군으로 어떻게 변경을 하게 되셨는지 좀 백그라운드를 설명해 주실 수 있나요?
저는 채널톡에서도 오퍼레이터 한 절반 정도 일을 하고 그 이후에 제가 콘텐츠 마케터로 잠깐 활동을 했다가 이제 CSM*, AM** 세일즈 팀이 신설이 되면서 그쪽으로 가서 마지막까지 근무를 한 케이스인데 그러니까 일을 하면서 계속 개발 공부가 필요했어요.
뭔가 고객사를 만나서 설득을 하든 채팅으로 설득을 하든 이 제품을 알아야 하니까 계속 공부를 개발 공부를 했었는데 그게 너무 잘 맞았어요.
제가 대외적으로 되게 막 사람들 모아서 뭐 하고 이래서 뭔가 인싸처럼 보일 수 있는데 실제로는 제가 그렇게 막 엄청 외향적이고 이런 스타일은 아니거든요.
근데 이제 CSM, AM 이런 걸 하면서 거의 하루에 고객사를 네 팀 다섯 팀씩 미팅을 하고 이렇게 하다 보니까 제가 너무 조금 그게 이제 실제로 화상으로 계속 미팅을 4개 5개씩 하니까 저도 에너지가 많이 떨어지더라고요. 그래서 휴식을 위해서 퇴사를 했는데 근데 그 기간 동안에 제가 혼자서 공부할 수 있는 게 사실 개발 밖에 없었고, 하면서도 적성에 맞고 재밌어서 선택하게 되었어요.
그리고 애초에 제가 저는 개발자 이력서에다가도 스스로를 메이커라고 소개를 하거든요.
저는 디벨로퍼나 엔지니어보다 약간 메이커라는 이름이 저를 더 잘 대변한다고 생각해요.
그래서 어떻게 보면 그냥 개발자는 그냥 직함 내지는 그런 거 그냥 직무에 지나지 않고 제가 즐거워하는 거는 뭔가를 만들고 또 거기에 계속 피드백해서 좋아지게 만들고 뭐 뭔가 없는 거 만들어내고 이런 게 저는 되게 재밌거든요.
사실 막 이거 직무를 바꾼 게 뭔가 대단한 의미가 있어서 사실 바꾼 건 아니고 저는 CX에서 했던 그런 문제를 해결하는 것 그게 어쨌든 말로 사람과의 문제를 해결하든 뭐 코드로 컴퓨터와의 문제를 해결하든 전 비슷한 맥락이라고 생각해서 그래서 저는 막 엄청 대격변이라고 생각하지 않고 있습니다.
*CSM: Customer Success Manager (관련 아티클: 고객 성공 관리자란?)
**AM: Account Manager (관련 아티클: Account Manger?)
그럼 iOS 개발을 선택하신 이유가 있나요?
그건 제가 애플 팬이라서고, 특별한 이유가 없습니다.
저는 중학교 때 산 첫 스마트폰이 아이폰 3gs 인데, 그때부터 사용을 했죠.
그러다보니 거의 모든 버전의 아이폰을 다 겪었죠.  (이때 기자들도 잠시 인터뷰에서 벗어나 한참 아이폰 추억 여행을 했답니다.)
사실 앞서 말씀하신 문제해결능력은 어떤 직군이든 갖고있으면 도움이 되는 것 같아요. CX 오퍼레이터의 경험이 지금 개발자로 계실 때 도움이 되나요?
제가 딱 문제해결을 위한 집요함으로부터 도움 많이 받은 것 같아요.
살짝 제 자랑인데요, CX 오퍼레이터 출신으로서 배웠던 어떤 능력이 개발이나 다른 영역에서 되게 좋게 작용했던 거는… 제가 생각하는 해결 방식이 되게 간단하고 짧고 근데 되게 효과적인 경우가 있어요. 개발이나 기획을 오래 하셨던 분들을 생각하지 못하는 방향성도 간혹 존재 하거든요.
그래서 여러 방안을 대입해보고, 단순화해서 문제를 잘라보고 이런식으로 하니까 되게 문제가 단순화되는 경험을 했었죠. 그런 것들을 자주는 아니지만 간혹 경험하면서 분명히 이런 문제를 객관적으로 보고, 가지를 쳐나가면서 핵심을 찾는 그런 능력은 어떻게 보면 고객의 긴 말 속에서 뭔가를 찾아냈던 경험들이 CX 오퍼레이터로서의 능력이고, 거기서 배웠던 기술이 다른 데도 녹아 들어간 게 아닌가 하는 그런 생각도 있습니다.
(문제해결을 위한 집요함이라든지, 문제를 객관적으로 보고 가지를 쳐 나가는 능력이) 임기응변으로 문제를 해결하는 데에도 도움이 되겠지만, 결국에는 (유저의 이슈가) 계속 재발을 안 하려면 내부 인원과 어떤 딜(설득)을 해야 되잖아요. 이러한 설득을 해봤다는게 엄청나게 도움이 많이 된다고 말씀드릴 수 있는게 예를 들어 보자면,
저도 개발자로 면접을 볼 때는 사실 제 이력이 그렇게 막 엄청 도움 되는 이력은 아니거든요. 면접관들에게는 일단 편견이 있어요. 제가 문과이고, 심지어 문학 전공이에요. CX오퍼레이터 말고도 그 전까지 했던 일도 개발이랑 크게 관련이 없는 일들이더 보니까, 이런 이력을 읽은 면접관들은 “내가 그럼 당신을 써야 하는 이유가 뭔가요? 경력이 길지도 않은데, 심지어 관련업을 하지도 않은 지원자분을 왜 채용해야 하나요?” 이런 질문을 항상 받아요.
그때마다 저는 진짜 자신 있게 “내부 커뮤니케이션 자신 있다.”라고 얘기합니다.
제가 오퍼레이터로 일하면서 개발자분들이나 내부 직원 분들한테 요청하거나 물어보는 것을 수없이 많이 했을 거 아니에요. “왜 안 돼요? 이거 왜 빨리 하면 안 돼요?” 이런 질문들.
그런데 개발자 분들이 열심히 이유를 설명해 주시려고 하는 분도 계시지만, “안돼요” 하고 이유는 알려주시지 않는 분들도 계세요. 특히 후자 같은 경우가 설명을 했다고 해서 내가 이해할 수 없다는 걸 아니까 그냥 안 돼요라고 말하는 것이거든요. 그게 사실 오퍼레이터 일하면서 제가 너무 답답했고, 이유를 알고 싶어서 개발 공부를 한 것도 있었죠.
이제는 제가 개발자의 눈으로 그런 요청들을 바라보니까 사실 기술로 해결할 수 없는 문제는 거의 없다는 생각을 했어요. 다만, 회사의 근간을 흔드는 어떤 로직을 바꿔야 되고, 그 로직을 바꾸려면 전사에 공유하고, 설득을 해야하고 이러면 “다음 주에 해 드릴게요.” 이렇게 할 수가 없는 상황들이 있는게 보이더라고요.
앞에서 말씀드린 “내부 커뮤니케이션” 부분에 대해서는 저의 경험을 공유 하면서 비개발자도 납득되게 설명할 수 있는 개발자라는 것을 어필할 수 있게 되었죠. 이 부분이 특히나 CX 오퍼레이터를 경험했기 때문에 자신있게 말 할 수 있는 포인트가 아닌가 싶습니다.
내부 커뮤니케이션을 어떻게 진행 하셨는지 예시를 들어주실 수 있나요?
예를 들어서 오퍼레이터가 “a를 빨리 하고 싶어요” 라고 하면, 보통 일반 개발자들은 ‘그게 왜 중요하지, 이거 하면 뭐가 좋아지지, 이걸 내가 왜 해야 되지…’ 이런식으로 중요성이 뭔지, 기대효과는 뭔지, 해야하는 이유는 뭔지 등에 대해 궁금함을 느껴요.
데이터가 없는 상태에서 하고 싶다고만 얘기하게 되면, 현업에서 그게 몇 건이나 들어오는지는 당연하게도 체감을 못해요.
저는 이런 부분을 전달할 때 만약에 주에 200건 이상 문의가 들어오는 상태라고 가정하면,
주 200건
상담사 1명당 동일 질문 응대를 N번 이상
콜 당 가격 계산 → 낭비되는 리소스
위와 같은 방식으로 전달하는 거죠. 이런식으로 데이터를 함께 전달하는 건 특히 VOC 관련 개선 프로젝트를 할 때, 개발자 분들의 온도도 확 올라가는 경험을 했어요.
데이터가 함께 있으면, 개발자가 납득할 수 있는 설득도 가능하고, 개발자가 왜 미뤄야 하는지에 대해서 이유도 듣고 하면서, 각자의 업무 영역에서 어떤 리스크를 쥐고 있는지가 설명 할 수 있는 기회가 되요. 이런 커뮤니케이션을 하다 보니 회사 전체가 원 팀(one team)으로 일할 수 있게 되었고, 커뮤니케이션을 잘 할 수 있다는 자신감이 붙었어요.
커뮤니케이션 코스트 자체가 낮아지면서 업무가 효율적으로 진행되고, 업무 영역들에서 신뢰도가 올라가기 때문에 팀이 강해지는 효과도 있다고 생각합니다. 숫자로 설득을 하고 이제 뭔가 개발자와 대화를 하면서 이런 게 되게 돌아가게끔 만들어내는 구조 자체가 중요하다고 저는 생각을 하거든요.
커뮤니케이션 코스트를 낮추는 부분은 정말 중요한 것 같아요. 그럼, 운영도 해보시고, 개발도 해보신 입장에서 어떻게 하면 운영자 입장에서 좀 개발자와 잘 소통할 수 있는지 한 번 더 정리해서 얘기해 주시면 좋을 것 같아요.
왜 해야 되는지를 잘 설명하면 좋아요.
잘 설명한다는 것은, 데이터, 리소스, 시기에 맞춰서 전략적으로 소통하는 것 같아요.
개발자로 일을 해보니 이게 뭔가 다른 사람들의 일이 완성되기 위해서 개발이 마지막 단계로 필요한 경우가 굉장히 많아요. 기획자의 마지막 단계 디자이너의 마지막 단계 서비스 운영의 마지막 단계 이런 여러 분들의 결과물이 실제로 나가려면 개발을 통해야 되는 경우가 많습니다. 즉, 많은 사람이 개발자 1명에게 “이거를 며칠까지 해 주실 수 있나요”를 엄청나게 소통하게 되는 것 같아요.
그러다보니 개발자 입장에서는 신 기능을 만들어서 내보내는 것은 사업의 확장을 위해서라도 한다고 생각한다면, 이미 개발이 되어 배포된 기능의 개선이 필요한 거는 ‘지금 할 것도 많은데 이거 좀 나중에 해도 되지 않나 90%는 돌아가는 거잖아.’ 약간 이런 생각을 하게 돼요. 개발자도 인간인지라… 일이 많고, 우선순위를 생각하다보면 그런 생각을 하게 되죠.
제가 얼마전에 저희 팀에서 VOC 개선을 진행할 때 이런식으로 진행되어 좋았던 면을 소개시켜드리자면,
데이터를 기반으로 문제를 가지고 오셨는데, 거기에 이런 문제를 해결하는데는 얼마나 많은 리소스가 드는지 물으시는 거예요. 그래서 알려드렸죠. 어떤 문제는 해결하려면 리소스 투입이 너무나 많을 수 있지만, 어떤 문제는 아주 작게 끝날 수도 있는 것도 있었어요. 그래서 그런 이슈를 해결하는데의 리소스를 인지하고 계시면서 PM,PO, 서비스 기획자 분들과 소통 하면서 언제 어떤 신 기능이 들어갈지에 대한 부분을 알고 계시면, 그 때 관련 이슈를 함께 진행해달라고 요청하는 거죠.
그래서 운영팀은 그런 회사 장기 플랜을 꼭 알고 있을 필요가 있다라는 생각이 좀 있어요.
그런데 오퍼레이터와 어떻게 보면 개발자가 소통할 때, IT 용어를 모르면 서로 소통 하기가 쉽지 않아요. 어떻게 하면 개발자가 말했을 때 찰떡같이 알아 들을 수 있을까요?
일단 제일 좋은 거는 저는 개발자가 친절하게 설명하는 거라고 생각하거든요.
저는 잘 설명해 주시는 개발자분들도 채널에서도 되게 많이 겪었고 그래서 그런 분들에게 좀 감명을 받아서 저도 되게 잘 설명하려고 노력합니다.
하지만, 모든 개발자가 그렇게 상세히 설명하려고 하진않고, 또 모든 개발자가 이런 VOC나 운영적인 이슈에 관심이 없을 수 있잖아요. 그때는 그러면 최소한 대화가 될 수 있는 기본적인 용어들은 IT 스타트업을 다닌다면 직군에 상관없이 알아야 한다고 생각하고 있습니다.
혹시 추천해주실 책이나 강의 같은게 있을까요?
비개발이었던 사람으로서는 사실 나와있는 책들이 쉽지 만은 않은 것 같아요. (여담이지만) 이런 부분에 의견이 일치하는 분들이랑 함께 더 쉬운 IT 용어를 풀어쓰는 강의나 책을 만드는 것도 좋겠다라는 생각도 하고 있어요.
또, 요즘은 강의나 책을 봐야만 뭔가를 배울 수 있는 세상은 아닌거 같아요. 회사에서 모르는 용어가 있으면 그때 그때 구글링이나 챗GPT 활용해서 찾아보시는 걸 추천드려요. 멀지 않은 시일 내에 CXCK 내에서도 IT회사에서 꼭 알아야 하는 용어설명세션을 열도록 해보겠습니다. (오! 예에)
PM(PO) 또는 개발자로 직군 변경을 원하시는 분들도 계실 수 있을 것 같아요. 그래서 이런 스킬 셋을 가지고 있으면 개발자로 일하기 좋아요. 아니면 PM으로 일하기 좋아요. 할 만한 것이 있을까요?
개발은 사실 저도 이제 갓 2년 차가 된 입장이라 누가 하면 좋다 뭐 이렇게 얘기하기가 굉장히 조심스럽기는 한데 직무를 막 변경한 사람의 입장으로 말씀드리면 일단 아까 말씀드린 것처럼 문제 해결 좋아하는 사람 그리고 약간 덕후 스타일인 사람, 앉으면 약간 궁금증이 해결될 때까지 집요하게 집중할 수 있는 사람. 그게 중요하다고 생각해요.
조금 현실적인 얘기를 하자면 ‘영어를 읽고, 이해하는데 무리가 없고, 자신 있다.’ 이러면 굉장히 유리합니다.
사실 개발이 특별한 게 아니라 저는, 사용법을 읽고 물건을 잘 사용하는 사람 있죠? 그런 사람들이라면 누구나 할 수 있다고 생각하거든요. 근데 대신에 그 사용법이 영어로 되어 있는!
그래서 영어에 익숙하고, 사용법에 맞춰 잘 적용해서 한다는 점이 괜찮으면 클라이언트 개발자*로도 충분히 CX 오퍼레이터 분들도 일 하실 수 있는 분야라고 생각합니다.
클라이언트 개발자들은 UIUX를 만들고 디자이너분들이 보통 말하는 그런 어포던스** 같은 거를 잘 이해할 수 있는 사람들이라고 생각해요. ‘여기에 버튼 같은 걸 두면 유저들이 분명히 헤맬 텐데 뭐 아니면 이거 이렇게 하면 유저들이 못 찾던데’ 이런 경험들이 CX오퍼레이터라면 다 있잖아요. 물론, 그게 개발자 본연의 역할은 아니지만 그래도 자신 있게 의견 낼 수 있는 개발자로 되기에 충분하다고 생각합니다.
그리고 매우 현실적으로는 공부를 많이 해야죠.
저는 역으로 저희 CXCK 안에서 원래 개발자이신데, 지금은 CX 리더를 하고 계신 분도 알고 있거든요. 그분도 되게 공부 많이 하시고 유저에 대해서 많이 탐구하시고 이렇게 하시면서 어렵게 넘어오셨을 거라고 생각해요.
어느 직군이든 넘어가려면, 공부도 많이해야하고 그러는게 현실인 것 같아요. 그런데 클라이언트 개발자한테는 이 CX 경험은 진짜 굉장히 도움이 많이 된다 라고 말씀드릴 수 있을 것 같습니다.
*클라이언트 개발자: 스마트폰, PC 등을 Client 라고 하며, 이에 구현하는 개발자가 Front-end 개발자이다. (관련 아티클: 개념정리)
**어포던스 (affordance) : 어떤 행동을 유도한다는 것 (관련 아티클: 어포던스)
현실적으로 말씀해주셔서 감사해요! 그럼, 개발자로 얼마나 준비 하셨는지 궁금합니다.
저는 그냥 회사 다니면서 찔끔찔끔 하다가, 퇴사하고 좀 쉬다가 서울시에서 소프트웨어 관련해서 청년 취업사관학교에서 무료 코스를 듣게 되었습니다.
그리고 다행히 제가 들었던 코스는 되게 운영사 분들이 너무 좋으셔서 그 동료들이 너무 좋았고 정말 잘하는 친구들 사이에서 또 감사하게 공부할 기회가 생겨서 6개월 공부하고 바로 취업을 했고 6개월 사이에 제가 만든 서비스를 거의 한 두세 달 차에 바로 출시를 했어요.
(어떤 서비스인지 물어봤습니다. : 달리기 트레킹하는 거고 지금도 앱스토어에 가면 있어요. 근데 제가 조금 리뉴얼을 좀 하고 나중에 저희 CXCK 방에다가 올려보도록 하겠습니다. 나중에 꼭 오픈할게요!)

[Part Summary] 오퍼레이터에서 개발자로

오퍼레이터에서 개발자는 문제해결 능력의 확장이예요.
1.
오퍼레이터에서 개발자로 직군변경은…
문제를 해결하는 것의 연장선으로 비슷하다고 생각: 사람과 문제해결, 코드와 문제해결
오퍼레이터의 경험 중 도움이 되었던 부분?
문제를 객관적으로 보고, 가지를 쳐나가면서 핵심을 찾는 능력
데이터를 갖고 설득을 해봤다는 점
2.
오퍼레이터로서의 내부 커뮤니케이션
데이터가 함께 있으면
개발자가 납득할 수 있도록 설득도 가능하고,
개발자가 왜 미뤄야 하는지에 대해서 이유도 듣고 하면서,
⇒ 각자의 업무 영역에서 어떤 리스크를 쥐고 있는지가 설명 할 수 있는 기회
커뮤니케이션 코스트 자체가 낮아지면
업무가 효율적으로 진행되고,
업무 영역들에서 신뢰도가 올라가기 때문에 팀이 강해지는 효과도 있다고 생각
운영자로서 개발자와 잘 소통할 수 있는 비법
왜 해야하는지를 데이터를 수반한 상태에서, 리소스를 파악하고, 시기에 맞춰서 전략적으로 소통 추천
시기? PO, 서비스 기획자들과 소통하면서, 언제 어떤 기능이 나갈지를 아는 것 - 운영팀은 그런 회사 장기 플랜을 꼭 알고 있을 필요
3.
개발자와 잘 소통 하려면?
최소한 대화가 될 수 있는 기본적인 용어들은 IT 스타트업을 다닌다면 직군에 상관없이 알아야.
추천 책, 강의
4.
개발자가 되려면,
문제 해결 좋아하는 사람 그리고 약간 덕후 스타일인 사람, 앉으면 약간 궁금증이 해결될 때까지 집요하게 집중할 수 있는 사람이면 개발자 추천합니다.
영어를 읽고, 이해하는데 무리가 없고, 자신 있다.’ 면 유리해요.
(무엇보다) 공부를 많이 해야합니다.
마지막으로 자유롭게 한 마디 해주세요!
그동안 CXCK 운영이 활발 하지는 못했지만, 이제는 더 많은 정보와 더 많은 이벤트를 준비해 드릴 수 있어야 되지 않을까 생각하고 있습니다.
최근 채용 사이트나 이런 데도 CX, CS 부문이 또 따로 생기는 것도 보이는 것 같아요. 그래서 어느 정도는 스타트업 씬에서 CX/CS 직무 인지도가 점점 쌓이고 있어서 고무적이라고 생각합니다. 앞으로는 전문성을 더 오퍼레이터 씬에서 키워나가야 하는 것 그게 우리한테 지금 필요한 숙제라고 생각하고 이를 해결하는 데에 CXCK 가 도움이 됐으면 좋겠다고 생각합니다.
CXCK는 전적으로 멤버분들 모두가 편하게 해보고 싶은 걸 해볼 수 있는 곳이 되었으면 좋겠어요. 모든 멤버분들께 감사드립니다!
오퍼레이터들의 고민을 나눌 수 있는 CXCK 커뮤니티의 시작과 성장, 운영하는 경험을 상세하게 공유해주신 경원님, 감사합니다.
앞으로도 CXCK 를 운영하는 호스트로서 함께 사명감을 갖고 움직여주실 것을 기대해봅니다.
다음편은 이번 시즌에 새롭게 시작하는 시리즈물인 [게스트 인터뷰 No.1] 는 “O인O”님입니다. 풀네임은 23-10-04 에 만나요!  
경원님의 호스트 인터뷰가 재밌으셨나요? 그렇다면, 좋아요를 눌러주세요.
좋아요는 저희들이 즐겁게 작성할 원동력이 됩니다.
 9월에 호스트가 된 정민지 드림.