brunch

매거진 채널톡 오퍼레이터 워크북

라이킷 32 댓글 5

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 채널톡 Nov 20. 2019

오퍼레이터를 위한 개발자 사용설명서

개발자의 뇌 구조를 파헤쳐보자

스타트업 씬에는 3대 놈놈놈이 있습니다.

1. 푸쉬하는 놈: 가즈아-만 외침 (이하 대표)

2. 요청하는 놈: 잘 모르고 귀찮게 함 (이하 잡부)

3. 거절하는 놈: 까칠하게 거절함 (이하 개발자)

이 중 오퍼레이터, 기획자, PM 등은 잡부 포지션에 속합니다. 대표한테 푸쉬당하고, 개발자에게 거절당하는 슬픈 숙명을 가지고 있지요. 답답한 마음에 요즘 개발자와 커뮤니케이션하는 법과 같은 클래스가 유행하길래 들어봅니다. 그런데도 여전히 개발자라는 존재가 어렵네요. 차라리 코딩을 직접 해볼까 껄쩍거립니다.

CX를 담당하는 스타트업 오퍼레이터에게 개발자는 애증의 파트너이죠. 오퍼레이터는 고객을 통해 프로덕트 이슈를 발견하고 개발자에게 개선 과제를 요청합니다. 개발자도 오퍼레이터의 요청사항을 통해 프러덕트의 완성도를 높여가고요. 공생 관계의 그들은 왜 그토록 가까워지기 힘든 걸까요?

오퍼레이터 천세희는 개발자와 커뮤니케이션 능력은 중요한 업무 역량이라고 합니다. 그녀는 코드 1줄도 안 쓰지만 어떻게 개퍼레이터(개발자+오퍼레이터)가 될 수 있었을까요? 20년 경력 오퍼레이터의 짬바이브에서 나오는 12가지 커뮤니케이션 꿀팁을 들어봅시다.

거품이 풍부한 라떼는 오늘 날도 유효하다

개발자의 '안돼요'에 대하여...

의도를 제대로 전달했는지 생각해보자

1. 불을 끄려면 주소를 제대로 불러주자

오퍼레이터: 지금 결제가 안 된대요. 고쳐주세요.

개발자: (결제 코드가 5만 5천 줄인데 당최 어디 말씀이신지...)

개발자는 0 아니면 1인 사람들입니다. 하나의 일 밖에 집중하지 못합니다. 띡-하니 수정해달라 던지면, 중요해 보이지도 않고, 딴 거 할 거는 너무 많고, 그렇게 개발 우선순위에서 밀려나는 거죠.

문제 해결이 10배는 빨라지는 방법이 있습니다. A 메뉴에서, B를 클릭하면, C 팝업이 뜨는데 여기서 버그가 나네요. 버그 나는 상황의 플로우를 상세하게 전달해주세요. 그리고 버그 리포트하기 전에 iOS, 안드로이드, PC에서 미리 테스트해보고 알려줘도 개발자는 흐뭇해한답니다!

(채널톡 광고지만) 오퍼레이터에게 진짜 꿀팁

2. 개발자는 깊게 파고, 오퍼레이터는 넓게 판다

오퍼레이터: 개발자님. 요즘 우리 앱 정말 빨라진 것 같은데요? 짱짱맨

개발자: (밤새 성능 개선한 건데.. 잘 보이지 않는 것 까지 알아주다니 감동...)

개발자들이 고백하건대 생각보다 개발자들은 제품 전체를 모릅니다. 프로덕트를 잘 아는 사람은 있어도, 많이 아는 사람은 없다고들 하죠. 다들 직접 짠 코드 외에는 다른 부분은 잘 모르는 거죠.

그래서 오퍼레이터가 얇고 넓게 제품을 파면서, 전체 프로덕트에 이슈가 되는 부분을 연결시킬 수 있습니다. 오퍼레이터로서 우리 회사 프로덕트를 하루에 몇 번이나 써보고 있나요?

개발자들은 나보다 제품을 더 빠싹 하게 알고 있는 오퍼레이터에게 믿고 의지하게 됩니다. 버그 저격 말고 제품 기능에 도움이 되는 피드백을 전달해보세요. 개발자가 오퍼레이터를 제품 개발의 등대라고 생각할 겁니다.

개발자와 오퍼레이터가 합쳐져야 T자형 인간이 될 수 있다

3. 동굴형 개발자를 동굴에서 끌어내자

오퍼레이터: 으악! 장애 때문에 고객에게 5만 통이 나가고 있어요

개발자: (흠... 이 코드가 왜 나도 모르게 머지가 되고 배포된 거지...?)

개발자들은 장애가 나면 문제의 본질부터 생각합니다. 아니, 본질만 생각합니다. 한 번은 특정 고객군에게 하루에 수천 건의 문자 메시지가 나가는 장애가 발생했는데요. 그때 개발자들은 고객의 상황보다는 동굴 속에 들어가 코드를 들여다보고 있는 거예요.

참다못해 24시간 이내애 고객에게 보상 방안을 마련해서 사과 공지를 지시했죠. 또한 문제 원인을 파악해서 회고하고 사후관리 체계를 공표했습니다. 이처럼 긴급한 장애 상황에 오퍼레이터들이 나서서 해결하고, 사후 대책에 대해 회고하는 문화를 퍼실리테이션 하면 어떨까요? 오퍼레이터가 위기를 기회로 만들 수 있습니다!

동굴 속에서 본질을 탐구하는 개발자들

왜 어려운 이야기만 꺼내는가...

개발자 말에 적당히 받아치는 스킬

4. 개발자가 괜히 어려운 말을 하는 게 아니라니깐요?

개발자: 홍시는 홍시 맛이다

오퍼레이터: 홍시 맛이 무엇인가요?

개발자: (그럼 이걸 어떻게 얘기하냐?)

개발 용어 너무 이해하려고 하지 마세요. 그냥 외우시면 됩니다. 그들이 원하는 대로 정확하게 얘기해봅시다. 오퍼레이터는 그래서 언제까지 할 수 있는지를 개발자에게 받아내기만 하면 됩니다.

그냥 아주 정확하게 말해보자

5. 적당한 개발 용어를 섞어 쓰면 공대물 먹은 느낌을 준다

오퍼레이터: 서버에서 URL을 보내줘야 하는데, API가 아직 미완성이란 거죠? 해당 페이지 켜져 있을 때만 체크하면 돼서 DB에 저장할 필요는 없어요. 이번엔 중요하지 않은 기능이라 괜찮아요.

개발자: (오? 공대물 좀 먹었나 보군)

개발자에게 통하는 매직 키워드를 틈틈이 공부해보세요. 리액트, 노드 이런 용어를 사용하면 이 오퍼레이터 공대물 좀 먹었나 싶을 거예요.

오퍼레이터도 기본적인 용어는 공부합시다! 용어만 중간중간 끼워 써도 공대 네이티브는 아니더라도 교포로 거듭날 수 있습니다. 여기서 포인트는 이해하지 말고 그냥 외우면 됩니다.

자 이제 공대체의 세상이 올 거다

6. 공동의 목표가 있을 때 개발자와 뇌구조를 맞춰보자

오퍼레이터: 이번 장애 처리하느라 고생하셨어요!

개발자: 문제를 해결하려면 아직은 좀 오래 걸릴 것 같아요. ~~지금은 서버에서 이미지만 주거든요. 이렇게 바뀌면, 배경 이미지를 따로 두고,~~ ~~스케줄을 각각 서버에서 하나씩 보내줘야 할 것 같아요. 그럼 서버 DB 구조도 손봐야 할 거예요. @#$%@#$%^&()(&^%$#@#$%^&()(&^%$#@#$%^&~~

오퍼레이터: (잘 모르지만 일단 듣는다)

평소에 오퍼레이터가 개발자와 깊은 대화를 나눌 상황이 많지 않아요. 그래서 이 두 집단의 뇌구조는 상당히 다른데요. 오퍼레이터가 먼저 다가가 개발자에게 장애를 얼마나 멋지게 제압했는지 물어보세요. 정말 신나게 이야기합니다. 이때가 개발자와 동질감을 느끼고, 개발 백그라운드를 업그레이드할 수 있는 타임이기도!

개발자와 기획자 평소의 확연히 다른 뇌구조

왜 내 말에 시큰둥한가...

개발자 장인정신을 탐구해보자

7. 개발자는 명령어 입력창이 아니에요

오퍼레이터: 작업 명세서 전달드립니다. 기간 맞춰 부탁드려요.

개발자: (내가 무슨 cmd인가.. 왜 명령어를...)

낯선 개발자에게 작업을 요청해야 하는 상황입니다. 왠지 정갈한 문서로 정리해야 할 것 같잖아요. 그러다 보니 빡빡한 작업지시서나 투두 리스트 형태를 작성하게 되는 거죠. 그런데 문서를 쓰다 보면 형식을 맞추고, 문서 라임을 맞추다 보니 점점 상황과 맥락이 사라져요.

개발자가 평소에 로봇처럼 딱딱하다고 해서 진짜 컴퓨터는 아니거든요. 팩트만 나열하기보다 '의도와 맥락'을 공유해주면 개발자도 훨씬 일 하기 좋습니다. 아무리 어려운 개발 과제라도 목표가 납득이 가면 도전해보고 싶은 의지도 생기고요. 구두로 다시 한번 전체 맥락을 짚어주면, 개발자들이 코딩하면서 춤을 출지도 모릅니다.

명령어는 컴퓨터에게 하는 걸로...

8. 버그 낸 개발자에게 저격을 멈춰 주세요

오퍼레이터: 버그다! 동네 사람들 버그가 났대요!

개발자: (아니야... 그럴 리 없어... 내가 짠 코드가 아닐 거야...)

가끔 버그를 외치지만 허공 속의 외침일 때가 있어요. 오래간만에 건수 잡아서 도움되는 말을 하다고 싶었는데 반응이 시큰둥하니까 답답하고 화나지요.

그런데 사실 버그가 나면 제일 속상한 것은 코드를 직접 짠 개발자입니다. 우리도 일 하다 실수했는데 욕만 잔뜩 먹으면 마음이 안 좋잖아요. 버그를 공유할 때 울고 있는 개발자들의 멘탈을 다독여 줍시다. 그러면 그들도 저격으로 받아들이지 않고 열린 마음으로 문제를 해결할 겁니다.

버그를 직면한 개발자의 멘탈 상태

9. 개발자의 집중 전환 비용은 비싸다.

오퍼레이터: 개발자님. 이거 지금 안 된다는대요? (고객 문의 사항 캡처 띡-)

개발자: (캡처 띡- 던지는 버그가 지금까지 5만 5천 개란 말이지...)

개발자들은 잦은 버그로 소환되어 본래 업무를 집중하지 못할 때 자괴감을 느낍니다. 집중해서 고민해야 하는 개발 이슈들이 있는데 슬랙으로 소환되고, 몸소 찾아와 말 거는 오퍼레이터에게 애증을 느끼는 거죠.

그래도 문제는 전달은 해야 하잖아요? 이것은 적절한 휴먼 매니지먼트의 영역입니다. 이럴 땐 버그 유형을 정리해서 전달하면 좋아요. 유사한 문제끼리 그룹핑하고 시급도에 따라 우선순위를 조율해주면 개발자들의 머리가 깔끔해집니다.

만약 빠르게 고쳐야 하는 버그가 있다면? 버그의 히스토리와 빈도에 대해서 언급해줍니다. '이 문제를 언제부터 일주일 3번 정도 고객이 지적한다'라고 팩트와 함께 중요성을 인지시켜주세요. 개발자는 숫자 중심의 팩트를 들으면 바로 작동이 됩니다.

QA를 따로 둘 수 없는 스타트업, 오퍼레이터가 잇몸으로

개발자는 왜 말 걸기 어려운가...

개발자와 미리 신뢰 자본을 쌓는 법

10. 잡담이 경쟁력이다. 안 친하면 일하기 어렵다.

오퍼레이터: 개발자님들! 고객님이 이거 물어보시는데, 설명 도와주실 분!?

개발자: (쟤 누구지? 쑥스러우니까 일단 패스.)

라테 같은 소리지만 주는 만큼 돌아오는 게 인생의 진리인 것 같습니다. 작게나마 밥을 같이 먹든, 칭찬을 하든, 개발자끼리 통하는 유머를 연마하든, 개발자와 여러 가지 방법으로 일상의 마일리지를 쌓아보세요. 오가는 잡담 속에 장벽이 허물어집니다. 개발자는 결국 코딩하는 기계가 아니라 사람입니다.

개발자와 오퍼레이터의 흔한 첫 만남

11. 힘들 때 도와줘야 진정한 우군이 된다

오퍼레이터: 오늘 서비스 런칭 힘내세요!

개발자: (쟤는 새벽까지 왜 같이 남아 있는지는 모르겠지만... 일단 비빔국수는 맛있당)

서비스 정기 점검을 하거나 신규 서비스를 오픈할 때면 개발자들은 새벽까지 남아서 작업을 해야 하는데요. 그때 함께하면서 개발자에게 진정한 우군으로 인정받을 수 있는 기회이기도 합니다. 새벽에 서비스를 오픈하는 날을 잡아 40인분의 비빔국수와 뜨뜻한 오뎅탕을 준비해가면서 존재감을 발휘하는 거죠.