상대방에게 해줘야 할 말이 뭔지 아는 것이 실력이다
개발 커뮤니케이션
기획자나 테크 PM, PO 면접을 보면 압박면접이랍시고 말도 안 되는 상황극을 하는 스타트업들이 많다. 그렇지만 말도 안 되는 막장 드라마들이 더 재밌는 이유는 그 속에 숨어있는 외면하고 싶은 리얼리티 때문이리라.
그 상황극의 대부분은 어떤 기능을 개발해야 한다거나 어떤 서비스를 추가 기획해 구현해야 하는데 개발자가 안 돼요.라고 하면 어떻게 대처할 것이냐 하는 내용이다.
상황 가정 자체는 정말 현실적이다. 그래서 면접관만 스스로 질문의 의도가 좋다고 여기는 게 아니라 면접에 응하는 사람도 자신의 실력과 경험을 검증받을 수 있는 날카로운 질문이라고 생각해 눈빛을 반짝일 수 있다. (경험이 있다면)
대부분의 사람들은 자기 나름대로의 커뮤니케이션 방법을 설명할 것인데… 압박 면접이랍시고 면접관의 입에서 나오는 말은 보통 이런 식이다. 나는 비슷한 면접 경험이 세 번 있었다.
그래도 안된다고 하면요?
그럼 또 저는 이렇게…
그래도 안된데요.
그럼 이건 어떨까요…
그것도 안돼요. 무조건 안돼요.
….(어쩌라고)
어쩌면 누군가는 이런 면접 후에 굉장히 낙담하겠지만 사실 낙담할 필요가 없는 말도 안 되는 상황이다. 이런 상황이라면 나도 할 수 있는 말이 별로 없기에 나는 아래처럼 대답하고 그 회사들은 오라고 해도 안 갔다.
외주 개발사랑 같이 일하고 있으신가요?
그 개발자가 퇴사 예정인가요?
아니면 지금 사내에서 실제로 그렇게 커뮤니케이션이 이뤄지고 있나요?(대부분 그렇다고 하진 않고 멋쩍어하면서 극단적인 상황을 가정하다 보니 오해가 생긴 것 같다고 대답하더라)
다 안된다고 하시는데 제가 들어야 할 말은 아닌 거 같습니다. 저를 설득하거나 대안을 역으로 제시해 줄 생각은 없으신가요?
커뮤니케이션은 분야를 막론하고 양방향으로 이뤄진다. 한쪽이 아무리 노력해도 한쪽이 닫혀있으면 일방향으로 대화가 흘러가고 그건 커뮤니케이션이라 할 수 없다.
우리는 디자이너나 기획자들이 개발 공부를 하려는 이유, 그것이 트렌드가 된 이유가 뭔지 생각해 볼 필요가 있다. 열정적이고 프로의식이 있는 대부분은 커뮤니케이션을 위해 자기 분야가 아니더라도 개발 공부에 대해 고민한다.
개발자랑 대화를 못하는 게 너무 힘들어서 개발자를 이해해 커뮤니케이션도 잘하고 조금 더 개발하기 좋게 기획하고 디자인하고 싶어서 공부해요.
자신이 직접 개발까지 해보고 싶어서 공부하는 사람들도 개발자와의 커뮤니케이션이 답답해서 답답하면 내가 뛸 게의 심정으로 공부를 시작하는 경우가 많다.
얼마나 눈물겹나. 상대방과 소통하고 싶은데 말이 안 통하니 내가 너의 언어를 배울게 나와 대화하자. 거의 짝사랑에 가깝다. 사랑은 못이룰언정 친구 사이라도 되면 좋을 텐데 드라마는 역시 비극일까.
“어쭙잖게 알면서 간섭하지 마세요. ”
“그건 기획자님께서 신경 쓰실 사항이 아니라 저희가 알아서 할 일인데요.(기획이나 잘하세요). ”
물론 정말로 어쭙잖게 알고서 아는 티를 팍팍 내며 이건 이렇게 하셔야 하지 않나요?라고 하면 정말로 상대방인 개발자가 기분이 나쁠 수 있다. 그러니 누구나 할 수 있는 웹개발 4주 완성! 이런 강의를 하나 들었다고 역으로 거만해지면 절대 안 된다.
저도 조사를 해 보았는데 혹시 이런 부분이나 이런 방향은 검토가 가능할까요?라는 식으로 제안이나 겸손을 한 스푼 넣어 대화를 유도하는 게 가장 바람직할 것 같다.
그럼에도 불구하고 그건 기획자님이 관여하실게 아닙니다라고 한다면……. 내가 대답해 주는 게 인지상정?
비개발자인 팀원이 할 수 있는 노력은 할 만큼 했다. 이제는 이렇게 말할 수 있어야 한다.
제가 관여할 사항이 아니라면 검토해 보겠습니다라고 하고 미루는 게 아니라 제가 납득할 수 있고 기획에 반영할 수 있는 정확한 정보를 전달해 주세요.
원활한 커뮤니케이션이란 상대방에게 해줘야 할 말을 정확히 해줄 때 가능하다. 상대방이 듣고 싶은 말을 해주는 게 아니라 상대방이 이해할 수 있고 같이 Next Level을 설계할 수 있는 내용을 이야기해주어야 한다.
개발자던 디자이너던 기획자던 실력이 있다면 상대방이 듣고 싶은 말에 기반해 내가 해줄 수 있는 말, 제공해 줄 수 있는 정보를 정확히 제공할 수 있어야 한다.
그러니 개발자도 단순히 기획자가 개발을 이해 못 하네가 아니라 이 사람들에게 어떻게 하면 나의 어려움을 이해시킬까 혹은 새로운 대안을 제시한다면 어떤 일정을 이야기할 수 있을까 치열하게 고민하고 노력해야 한다.
나는 당시 3년 차 P.O. 로서 외국인인 동시에 무려 15년 차 경력을 가진 개발자와 함께 5개월 만에 SAAS 형태의 프로덕트를 론칭한 경험이 있다. 처음엔 나 스스로 디자이너지만 웹서비스를 클라이언트단부터 백엔드 구성, 데이터베이스 설계, 배포까지 홀로 제공한 경험이 두 번이나 있었기에 소통을 잘할 수 있었다고 생각했다. 그런데 지나고 생각해 보면 그분 역시 나와 소통하려고 노력해 주었기 때문에 우리 팀이 성공적으로 서비스를 론칭할 수 있었던 것 같다.
대부분의 의사소통 과정을 떠올려보면 단순히 감정적으로 불편함과 귀찮음, 자신의 업무가 많다는 등 변명이나 회피는 일절 없었다. 대신 자신이 모르는 부분이나 부족한 부분은 확실히 인정하고 그 부분에 대해 양해를 구하고 발전방향을 제시했다. 또 당장 고민이 되는 부분은 최소한의 시간을 들여 즉각적인 검토를 진행한 이후 빠르게 피드백을 주는 방식으로 협조해 주었다. 또 현재 어려움이 있는 부분에 대해 구체적으로 이야기해 주고 그 어려움을 토로하는 것에서 끝나는 게 아니라 현재 어려움을 우회적으로 극복하는 우선적 대안과 그것이 실패했을 때 생각해 볼 수 있는 다음 스텝까지 함께 논의해 주었다.
예를 들어 내가 아이디어를 에이포 용지에 열심히 스케치하며 설명할 때 괜찮은 알고리즘이나 구조라고 생각하면 개발자분은 이런 식으로 말해주었다.
“오늘 제가 한번 테스트해 보고(즉각적인 검토) 내일 이어서 논의해볼 수 있을까요?(다음 스텝 제시) ”라던지
“아 그러면 그건 이렇게 이렇게 해볼 수 있겠네요~ (수긍) 그런데 저도 실제로 해보지 않은 거라(현재 상태 인정) 공부를 이번 주에 해봐도 될까요?(양해 및 요청)” 혹은
“현재는 이런 구조인데 그렇게 하려면 구조를 변경해야 할 것 같아요.(현재의 어려움) 구조를 변경하는 데는 또 시간이 오래 걸리니까 구조를 변경하지 않으면서 말씀해 주신 방향이 가능할지 검토해 볼게요.(대안 검토) 일주일 정도 검토해 보고 답이 안 나오면 그때 다 같이 시간이 걸리더라도 구조 변경에 대해 얘기해 볼까요?(다음 스텝 제시)“
서로 일을 미루고 정보를 최소한으로 제공하면서 눈치 싸움하는 게 아니라 서로 최대한의 정보를 공유하고 소통하기 위해 노력했기에 서로가 납득하는 로드맵을 세워 그 로드맵을 중심으로 추진력을 낼 수 있었다.
못하는 것과 안 하는 것은 큰 차이가 있다. 그때 15년 차 개발자 분은 못하는 게 없었다. 단지 안 해 본 시도만 있었을 뿐이었다. 그리고 그분은 안 해 본 방법을 알게 되었을 때 혹은 내가 제안했을 때 새로운 대안을 환영하고 함께 공부하면서 기꺼이 시도해 주었다. 우리는 무엇이 근본적인 문제인지 같이 찾아볼 수 있는 기간을 협의할 수 있었고 문제를 찾아 하나씩 해결했다. 결국 몇 개월 후 우리 기술 스택 안에서 기획한 기능을 모두 완성할 수 있었다.
나는 좋은 회사에 다녀본 경험이 많지 않고 내가 대한민국의 모든 기업에 경험이 있는 것이 아니지만 나의 주변을 보면 대부분의 신생 회사에서 개발자들에게 머리를 조아리고 개발자들 편의성만 봐주려고 하는 게 일종의 습관성 문화가 되어버리지 않았나 하는 안타까운 생각이 있다.
특히나 경력이 오래되지 않았거나 커리어를 최근에 전향한 사람이지만 회사 내에 개발인력이 없거나 채용이 안되어 빠르게 리더가 된 사람들 혹은 회사가 리더로 키우려고 하는 사람일수록 방어적인 성향이 강한 것 같다.
검토해 보겠습니다, 지금 저희는 사실 불가능해요, 그건 잘못된 생각이에요, 힘들어요. 여기까지는 전문가가 아니더라도 누구나 할 수 있는 말이다.
함께 하나의 목표를 달성하기 위해 소통할 때는 분야를 막론하고 내 현재 상황을 정확히 성찰하고 팀원에게 팀원으로서 해줘야 할 말이 무엇인지 고민하고 실천해야 한다.
마지막으로 내가 새로운 조직에 적응할때 책상에 항상 메모하고 있는 내용이자 지금 내 앞에도 적어놓은 메모를 첨부하며 글을 마친다.
