brunch

매거진 친절한 마녀의 B2B 마케팅

라이킷 17 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 친절한 마녀 Sep 27. 2021

개발자와 기깔나게 소통하는 법

개발자와 커뮤니케이션하는 법 2탄

사람이 세상에 태어나자마자 가장 처음 하는 일이 아마 관계 속 소통일 겁니다. 태어나보니 엄마, 아빠, 의료진 등 난데없는 사람들이 자신을 둘러싸고 빤히 쳐다보고 있고, 아기는 울음으로 자신의 존재를 알리니까요. 그 이후로 쭈~욱 아기는 성장하면서 평생 수많은 사람들과 관계를 맺으며 살게 됩니다. 부디 그 관계들이 원만하고 원활하길 바라며 열심히 소통하면서 말이죠. 요즘은 혼자 잘 먹고 잘 살기로 선택하고 실제로 그렇게 잘 사는 사람들이 많고, 심지어 미움받을 용기마저 가진 씩씩한 사람들도 많아서 다 그렇다고 말할 수는 없겠지만요.

이렇게 태어나면서 시작한 소통인데도 사람들은 편하기보다 불편하고, 익숙하기보다 낯설고, 소통이 안돼서 불통을 겪고 있다고 말합니다. 특히 의사소통의 문제는 난제로 꼽힙니다. 하지만 난제라 해도 하나의 문제일 뿐이니 한번 풀어보는 노력도 해볼 만합니다. 깨든가 깨지든가 둘 중 하나가 될 테지만 손 놓고 있는 것보단 속은 후련할 테니까요. 이번엔 IT 직장 내 마케터가 자주 대면하는 대상 중 하나인 개발자와의 소통에 대해 이야기해 볼까 하는데요. 어떻게 하면 개발자와 기깔나게 소통하며 관계의 미학을 발휘할 수 있을까요?

얼마 전 투비소프트 이준하 수석이 기고한 '개발자와 커뮤니케이션하는 법'을 읽으니 예전 기억이 말캉말캉 되새김질되었습니다. 개발자와 얘기하러 가기 전에 너무 무식한 티를 안 내려고 미리 제품 기술에 대한 사내 자료를 찾아보고 인터넷도 열심히 뒤져 보았던...... 모르겠는 말들이 어찌나 많던지. 한 줄을 읽으면 그 한 줄에 포함된 낯선 용어와 어려운 말들이 꼬리에 꼬리를 물어 읽고 찾고, 또 찾으며 헤맸던 모습이...... 컥~ 정말 '고군분투'란 말이 딱 그럴 때 쓰는 말이란 걸 몸소 실감했었더랬죠. 그 경험담을 소개해 보겠습니다.

인사도 하고 이야기를 주고받으니: 대상 탐색

이직을 하고 입사한 지 얼마 안 된 기업의 SW 기술은 또 다른 신세계였어요. 처음 접한 분야인 데다가 제품 소개서를 보니 이건 어느 행성의 언어냐 싶었죠. 주변의 기획팀, 영업팀의 이야기도 들어 보았는데, 명색이 SW 기업의 홍보마케터인데 대표 기술 정도는 가볍게 설명할 수 있어야 하지 않나 싶은 생각이 들었어요. 뭐, 처음부터 작정을 하고 누구에게 물어봐야겠다고 생각한 건 아니고 오며 가며 인사를 열심히 하면서 잠깐의 대화를 이어갔죠.

자주 마주치는 분들께 제품 내용을 보고 있는데 이해가 잘 안 돼서 걱정이라고 넌지시 얘기를 하면, '누구누구한테 가서 물어보면 도움이 될 거다'라고 얘기를 해주곤 했습니다. 그 누구누구인 분들을 직접 찾아가기도 했지만, 그보다는 먼저 그분들이 속한 팀의 팀장급 이상의 분들이 누구인지 알아 두었어요. 그리고 그분들을 마주칠 때면 웃는 얼굴로 인사를 더 하면서 친밀감을 형성했습니다. '웃는 얼굴에 침 못 뱉는다'라고 하잖아요!? '모르는 게 많아 궁금한 것도 많은 애가 인사성은 참 밝더라'라고 저의 존재감을 알렸던 거죠.

특별히 팀장급 이상의 분들을 점찍은 이유는 그간의 경력에서 우러나온 전략이었어요. 조직 내에 안 바쁜 사람이 없잖아요. 내 눈에 한가해 보이는 사람도 나름의 이유로 바쁘기 마련이죠. 모두가 바쁜 가운데 비교적 눈치 덜 보고 업무 시간에 틈을 낼 수 있는 분들. 평균적으로 회사와 경영진의 입장을 이해하고 대외적인 메시지를 어느 정도 파악하고 있는 분들이 팀장급 이상이라고 봤어요. 홍보마케팅을 하는 입장에서는 날 것 그대로의 기술에 대한 이해도 필요하지만 대내외적인 메시지에 대한 이해가 무엇보다 중요했거든요.

나의 무지를 모두에게 알리니: 취약점 드러내기

오다가다 인사도 잘하고 무지함을 널리 알린 덕에 나름의 '열공파'로 눈도장을 찍게 되니, 업무 시간 중에 제품 기술에 대해 설명을 들을 기회를 만들어 시간 양해를 구하는 것이 수월해졌어요. 기회를 만들고 나면, 무식해도 너~무 무식한 티를 내면 민폐자로 인식될까 봐 사전 공부를 했죠. 하지만 꼬리에 꼬리를 무는 말들을 다 찾아보고 이해하려 했다간 개발자를 만나기도 전에 넉다운이 되어 만나지도 못할 성싶었어요. 우선 아리송하고 난해한 내용은 표시해 두었다가 개발자와 이야기할 때 또 한 번 솔직하게 얘기를 했습니다.

밑줄 쫙쫙 긋고 물음표 표시해 둔 제품 소개서나 기술 문서를 슬쩍 내밀면서 "우리 회사의 제품 기술을 알고 싶은데, 솔직히 개발자가 아니다 보니 내용이 어렵다. 나름 이렇게 이렇게 열심히 찾아서 요렇게 요렇게 이해했는데, 제대로 이해한 건지 모르겠다."라고 말이죠. 열공의 흔적이 새겨진 문서나 자료를 보면, 보통 개발자들은 격려의 눈빛을 보내며 이렇게 말해 주었습니다. "어디 봅시다~" 이 말은 나의 노력을 가상히 여겨 도움을 주겠다는 신호였죠.

매 기회를 절호의 기회라 생각하고 또 하나 잊지 않은 게 있었는데요. 설명의 시간을 이용해 우리 제품을 만드는 개발자의 생각을 묻고 들어 보곤 했습니다. 개발자로서 우리 제품의 기술력이나 특정 기술 수준에 대해 어떻게 보는지, 타사 대비 장단점이 무엇인지, 그리고 고객도 그렇게 생각할지, 그것이 대외 문서에 잘 나타나 있다고 생각하는지 등에 대해 의견 조사 아닌 조사를 했어요. 그리고 각종 대내외 문서를 업데이트할 때마다 활용을 했습니다. 덕분에 자료 작성의 원천과 근거도 마련하고, 부서 간 메시지 합의도 수월해졌죠.

부가 의문문으로 확인 사살을: 효과적인 질문법

특히 대화의 포문을 여는 질문에 신경을 많이 썼던 기억이 나는데요. "이게 무슨 뜻이에요?'라고 대뜸 묻기보다 나름 이해한 내용을 먼저 말한 뒤에 '그런가요?' '맞나요?'와 같은 부가 의문문으로 확인 사살을 하는 형태로 대화를 이끌어 간 게 주요하지 않았나 싶어요. "이렇게 이렇게 이해했는데, 맞게 이해했나요?" 대부분의 개발자들은 제 노력을 가상히(?) 여겨 잘못 이해한 부분을 짚어 주고, 덧붙여 꼬리에 꼬리를 무는 용어에 대해서도 친절히 설명해 주었답니다. 정리하면, '부가 의문문-피드백-이해한 내용 정리 확인 사살' 순이 되겠네요.

일종의 직업병처럼 개발자들은 오류를 보면 그냥 못 지나치는 특성이 있어요. 오류는 반드시 해결해야 할 과제로 인식하죠. 그런 특성을 잘 공략한 질문 방식이지 않았나 싶어요. 보다 친절한 개발자는 최대한 쉽게 설명을 해주려 애썼고 도움이 될 만한 다른 자료까지 추천해 주기도 하는데, 그럴 때 열심히 공부해 오겠다고 하면 마다하지 않고 또 만나 더 쉬운 말로 설명해 주곤 했습니다. 이 질문법은 마녀가 개발자와 원활하게 소통하는 데 도움을 준 최고의 방법 중 하나였답니다. 단, 업무 시간에는 너무 많은 시간을 뺏지 않도록 주의했죠.

치고 빠졌더니: 시간 절약, 그리고 부담 제거

친절한 개발자는 설명도 친절하게 하고 추가로 더 많은 내용도 알려주려고 하는데, 이때 적당히 끊을 필요가 있더군요. 마음 같아선 한 번에 끝장 토론이라도 해 그 자리에서 다 알아 오고 싶지만, 그렇게 하면 이후 다시 가서 묻기가 부담스러워지더라고요. 미팅 후에 개발자가 상당한 시간을 빼앗겼다는 걸 인식하게 되고, 그 시간만큼 본연의 업무를 하느라 추가 근무를 할 수 있거든요. 그런 사실은 선한 마음으로 시간을 낸 개발자에게 또 다른 시간 할애를 부담스럽게 만들 수 있고, 찾아가는 사람도 부담이란 걸 알게 되기 때문이에요.

그래서 짧고 가볍게 치고 빠지곤 했어요. 정식 업무 회의나 특별한 경우가 아니라면 최대한 사전 학습을 하고, 질문은 2-3개, 시간은 15분에서 최대 30분을 넘기지 않도록 부가 의문문 형식을 취해 시간을 줄이려 애썼죠. 오픈형 질문은 자유로운 대답을 유도할 수 있지만, 너무 광범위하게 느껴져 자신의 시간과 노력이 많이 할애될 것 같은 인상을 심어 줄 수가 있어요. 한 마디로 귀찮아질 수 있다는 생각을 하게 만들 수 있다는 것이죠. 그러니 범위를 좁혀 상대의 시간과 노력을 덜 뺏을 수 있는 방식을 취하는 게 유리했어요.

개발자와 소통하면 이런 일이 생겨요!

보통 열공의 이미지로 각인을 시키고 나면 다음 미팅으로 자연스럽게 이어져 신뢰 관계를 구축할 수 있었습니다. 마케터가 개발자와 커뮤니케이션해야 하는 상황은 의외로 많습니다. 단순히 제품 공부 차원이 아닌, 홍보마케팅 활동에 필수적인 기술 숙지가 있어야 하기 때문입니다. 예를 들어, 프로모션 할 셀링포인트(selling point)를 잡을 때 우리 제품의 기능이나 성능이 고객의 요구에 부합하는 수준이나 방식인지 개발자에게 확인을 하고 뜬구름 잡는 소리를 하지 말아야 하니까요.

개발자와 자주 소통하면 마케터가 임의의 설명으로 제품을 왜곡하거나 과장하는 것을 방지하고, 보다 우리 제품을 잘 드러낼 수 있도록 설명을 쉽게 할 수 있다는 장점이 있습니다. 창작의 나래를 과하게 펼쳐 근거와 동떨어진 마케팅 활동을 하거나 이로 인한 갈등을 미연에 방지할 수 있는 거죠. 강•약점을 파악해 외부 문의에 원활히 대응할 수도 있는데요. 마녀의 경우, 마케팅 콘텐츠에 셀링포인트를 잡고 '이렇게 설명해도 무리가 없는지' 개발자와 논의하고 풀어갔던 것이 큰 도움이 되었어요. 그리고 마케팅의 역할을 계속 설명했더랬죠.

우리 제품의 특징을 고객에게 어렵지 않으면서도 돋보이게 설명하는 것이 마케팅의 역할이니 알기 쉬우면서도 기깔나는 표현을 할 수 있도록 조언해달라고 요청했어요. 개발자의 용어와 설명을 고객이 이해할 수 있는 용어와 설명으로 최대한 푸는 데는 개발자의 이해와 설명이 절대적으로 필요하다고 봤거든요. 그래서 틈틈이 개발자를 찾아가 묻고 논의하면서 더 나은 콘텐츠를 개발하고자 협업을 했습니다. 결과는? 개발자의 의견이 반영되었으니 최소한 욕은 안 먹었고, 종종 칭찬도 들으며 고객에게 큰 호응을 얻기도 했습니다.

시행착오는 없었냐고요? 왜 없었겠어요! 차고도 넘칩니다. 인상 좋은 개발자만 탐색한다고 될 일이 아니고 우리 조직에서 시간과 업무 통제권을 가지고 있는 팀장급 이상이 좋고, 취약점을 드러내더라도 쌩~무지함으로 접근하면 퇴짜 맞기 딱 좋을 수 있다는 상황 파악, 조건 파악, 분위기 파악을 하고, 치고 빠지더라도 바쁜 개발자의 일정을 잘 살펴 타이밍을 잘 잡아야 하는 숙제가 있다는 걸 알게 된 것도 다 시행착오를 겪었기 때문입니다. 경험상 그냥 아주 심플한 법칙 같은 것은 없어요. 항상 어떤 전제와 조건이 맞아떨어져야 합니다.

아주 운 좋게 한 번에 성공한 적도 있지만, 대부분은 시간이 걸리고, '여기가 아닌가벼?' 하며 왔다리 갔다리 하며 배운 것들입니다. 때론 욕도 솔찬이 먹기도 하면서 말이죠. 컨설팅이나 교육을 하다 보면, 간혹 '어떻게 그렇게 다 성공했어요?' '오랜 경력과 경험이 있으니 한 번에 딱 맞는 답을 제시해 줄 수 있으시겠네요. 우리에게 정답만 알려 주세요!'라고 요청하는 기업과 담당자가 있는데요. 숱하게 좌충우돌하며 쌓아온 경험이라도 한 번에 척! 통하고, 모두에게 적용될 수 있는 법칙이 되는 건 아닙니다.

아, 딱 하나가 있다면 '기본 지키기' '기본으로 돌아가라'는 말에서 알 수 있듯이 '기본'일 거예요. 세상에 정답은 없다고 하잖아요. 맞는 말이라 생각해요. 정해진 답이 있었다면 모두가 불통의 고통 없이 소통의 꽃길만 걸었겠지요?! 그저 우리는 주어진 상황과 맥락에 맞게 능동적으로 해답을 찾는 노력을 해 보는 거예요. 한번 최선을 다해본다고 해서 손해 볼 거 없다 생각하면서 말이죠. 마녀의 경험담이 정답은 아니지만 마케터가 개발자와의 소통 법에 한번 응용해 볼만하다 싶으면 좋겠어요.

소통이라는 것이 본디 어느 한쪽이 시작을 하지 않으면 이루어지질 않습니다. 누군가 먼저 시작을 해야 한다면 어차피 소통이 업인 마케터가 자신에게 유리한 방식과 위치로 끌고 오는 것이 업무를 더 수월하게 할 수 있는 방법이라고 봅니다. 그러나 세상이 두쪽 나도 그런 노력은 하지 않겠다, 불필요하다 생각하면 그것도 각자의 선택이니 틀린 건 아니고 다를 뿐이라 생각하고요. 뭐든 자신에게 맞는 게 최고니까요. 다만, 마케터가 지치지 않고 나름의 소통의 길을 찾는 걸 포기하지 않길 바랄 뿐입니다.

이상 친절한 마녀였습니다!

* 이 글은 어때요?