개발자의 커뮤니케이션 2
배려, 그리고 역지사지
지난 글에서는 개발자가 생각을 정리하고 말하는 스킬, 말의 뉘앙스에 대해 이야기했다면 이번에는 조금 더 실무적인 상황에서 중요한 ‘배려하는 커뮤니케이션’에 대해 이야기해보려 한다.
실력이 아무리 뛰어나도, 협업에서 배려가 없으면 오히려 신뢰를 잃을 수 있다. 평소 우리가 놓치기 쉬운 몇 가지 상황을 짚어보며, 함께 생각해 보면 좋겠다.
내가 아는 것을 상대도 다 안다고 생각하지 말기
요즘 웹개발의 경우에는 프론트엔드, 백엔드가 나뉘어 있는 경우가 대부분이다. 이런 경우 백엔드 개발자가 api를 만들어서 프론트엔드 개발자에게 전달하는 형태가 많은데, api 가이드 문서 하나 없이 url과 컬럼 정도만 전해주는 경우가 있다. 또한, 내가 만들지 않은 테이블의 데이터를 사용해야 할 때, 테이블 정의서 없이 "A 테이블의 b 컬럼에 넣어주세요"라고 결론만 전달하는 경우도 있다.
이 외에도 기획자에게 개발에 대한 이야기를 할 때 로직에 대한 이야기를 개발자들의 용어를 섞어서 어렵게 말하는 경우들도 빈번하다. IT 기획자 라면 당연히 알아야 할 개발 용어들이 있지만 그 범주를 벗어나서 커뮤니케이션에 지장을 주는 말들을 구태여 할 필요는 없을 것이다.
내가 알고 있다고 해서, 모두가 아는 것은 아니라는 점을 항상 기억하자. 과하다고 생각할 수도 있지만 상대가 인지할 수 있도록 상세하게 말하거나 문서화해서 전달하는 습관을 기르면 좋다.
공유하기
어찌 보면 가장 중요한 커뮤니케이션 스킬이 아닐까 싶다. 우리는 여러 사람과 함께 일을 하는 회사를 다닌다. 이런 환경에서 "공유"가 없이는 많은 시간을 낭비할 수도 있고, 큰 문제들에 직면할 수도 있다.
이를테면, 동일한 프로젝트를 담당하고 있는 개발자가 A 작업을 하면서 공통 로직을 수정해 놨다. 수정한 후 어떠한 코멘트도 남기지 않고, 별도로 공유도 해주지 않았다. 다음 날 이전과 달라진 로직을 보면서 다른 개발자는 의아해하고, 무엇 때문에 변경이 됐는지 히스토리를 알 수가 없다. 결국 수정한 작업자에게 찾아가 변경된 사항에 대한 설명을 따로 듣고 나서야 의문이 풀리게 된다.
이러한 일련의 상황들은 생각보다 업무를 함에 있어서 빈번하게 일어난다. 신기술을 도입했음에도 팀 공유가 되지 않아 혼자만 새로운 기술을 사용하는 경우도 있고, 장애 발생에 대한 처리 과정을 문서화해놓지 않아 이후에도 동일한 장애가 계속해서 일어나는 경우들도 있다.
어떠한 일이든 내가 한 일이 조금이라도 팀 또는 협업자들에게 도움이 될 것 같다는 생각이 든다면 스스럼없이 공유해 보자. 생각보다 많은 사람들이 고마워하고 감사를 표시할 것이다. 만약 거기서 질타하는 사람이 있다면, 그 사람은 공유를 하지 않아도 결국 뭐라고 할 사람이니, 너무 신경 쓰지 않아도 된다.
궁금한 것은 물어보기
어느 집단을 가든 부끄러움이 많고 소극적인 사람들이 있다. 그들의 대부분은 질문하는 것에 부담을 가지고 어려워한다. 그리고 상대방의 시간을 뺏고 상대를 불편하게 만든다고 생각하기도 한다. 하지만 궁금하거나 모르는 것은 필히 물어봐야 한다. 무슨 말인지 알아듣지 못한 채로 혼자서 해결하려고 하다가는 더 큰 문제에 직면하게 된다. 그래도 질문하기가 두렵다면 상대에게 조금 유하게 말해보자.
"이건 어떻게 하는 건가요?" "이걸 왜 이렇게 해야 하는 거죠?" 식의 말보다는,
"‘OO 기능에서 OO 처리하는 방식’이 잘 이해되지 않아서요. 시간 되실 때 간단히 설명해 주실 수 있을까요?" 또는 대하기 어려운 상대라면 "바쁘실 텐데 죄송하지만 ‘OO 기능에서 OO 처리하는 방식’ 설명 한 번 부탁드려도 될까요?" 등의 어조로 다가가 보자. 대부분의 사람들은 질문에 대답해 주는 것을 내가 걱정하는 것보다 크게 개의치 않아 한다. 오히려 문의하지 않고 나중에 더 큰 참사가 오는 것을 훨씬 더 두려워한다.
여기서 한 가지 주의할 점은 내가 혼자서 충분히 찾아볼 만큼 찾아보고 어느 정도까지 인지가 된 상태에서 정리된 버전으로 질문을 해야 한다는 것이다. 고민도, 정리도 없이 무턱대고 다 해달라는 식의 질문은 꼭 피해야 할 행동 중에 하나이다.
자신의 실력을 자만하지 말기
개발자들 중에 실력이 뛰어난 사람들이 왕왕 있다. 아니, 정말 많다. 그렇지만 간혹 가다 자신의 실력을 믿고 자만하는 경우들을 많이 보았다. (실력이 뛰어나지 않아도 스스로 자만하는 경우도 종종 있다.) 잘하는 사람이기 때문에 당연지사 어려운 일을 도맡아 하는 상황이 많은데, 그런 일일수록 더욱 많은 설계 과정이 필요하고 꼼꼼한 체크가 동반되어야 한다. 그렇지만 회의에서부터 얼마 걸리지 않을 일이라며 쉽게 얘기하고 기간마저 짧게 산정해 버리니 결국 테스트 과정에서 수없이 많은 오류를 만나게 된다. 더 심각한 상황은 이미 운영 서비스에 개발 사항이 배포가 된 후에 버그를 맞닥뜨릴 때다. 자신이 잘한다고 해서 자만하지 말자. 어떤 업무든 주어졌을 때 꼼꼼하게 검토가 필요하다고 기획자에게 말하고, 여러 가지 케이스들에 대해 생각해 보고 의문을 가지고 충분히 질의하는 시간을 가지자.
개발자의 커뮤니케이션에 대한 이야기를 두 편에 나누어 정리해 보았는데, 사실 이 외에도 떠오르는 사례나 배울 점은 정말 많다. 하지만 오늘 이야기한 내용만으로도 충분히 실무에서 더 나은 협업자가 되는 데에 큰 도움이 될 거라 생각한다.
개발은 혼자서 하는 일이 아니기에, 기술 못지않게 중요한 것이 바로 커뮤니케이션이다. 상대방의 입장을 먼저 생각하는 습관만 들여도 협업의 질이 달라진다.
무엇보다 가장 중요한 스킬은 바로 “역지사지”.
내가 이런 설명을 받는다면, 내가 이런 대화를 듣거나 보게 된다면 어떤 기분이 들까?
이 질문 하나만 마음에 품고 있어도 우리는 더 따뜻하고, 효율적인 협업을 만들어갈 수 있다.
