커뮤니케이션의 중요성을 실감하는 요즘..
부트캠프 당시 팀 프로젝트를 수행하거나 팀원들을 모집하여 사이드 프로젝트를 수행하면서 커뮤니케이션의 중요성을 자주 느끼곤 했었지만, 실무에서 팀원들과 함께 서비스를 개발하고 운영해나가고 있는 요즘 커뮤니케이션의 중요성을 더욱더 느끼고있는 중에 있다. 사실, 개발뿐만 아니라 모든 직장을 포괄해서 더 나아가 인생에 있어 커뮤니케이션의 중요성을 느끼지 않는 사람은 거의 없으리라 생각한다. 😅
'커뮤니케이션'과 '커뮤니케이션을 잘한다' 에 대한 나름대로의 정의
우선, 커뮤니케이션의 사전적 정의는 '사람들끼리 서로 생각, 느낌 따위의 정보를 주고받는 일'이라고 한다. (그냥, 한국말로 하면 의사소통...) 이때, '커뮤니케이션를 잘한다.' 라는 의미에는 굉장히 많은 의미가 있으리라 생각한다. 하지만, 이 글에서는 "커뮤니케이션을 잘한다"라는 의미를 나름대로 '나의 생각을 상대방이 이해하기 쉽게 잘 설명하는 것'과 '상대방의 생각을 잘 이해하는 것'으로 정의하고자 한다. (일단, 글의 방향성을 잡기 위해서는 주제와 관련된 용어에 대한 정의를 명확히 해야하기에...📚)
하지만, '어떻게 하면 커뮤니케이션을 잘할 수 있을까?' 라는 질문에는 그 누구도 선뜻 '이것이 정답이다!'라고 대답하기 어렵지 않을까 생각이 든다. 왜냐하면, 커뮤니케이션이 잘 된다는 것은 상대가 누구냐(성격, 나이, 경력 등), 어떤 환경(조직 문화, 급박한 개발 일정 등)에 있느냐에 따라 다를 뿐더러 본인의 상황(지식, 경험 등)에 따라서도 다를 수 있기 때문이다. 다소 진부한 표현이긴 하지만 시간과 상황에 따라 커뮤니케이션이 잘 될 수도 있고 잘 안될 수도 있다. 이러한 갖가지 변수들로 인해 개인의 노력으로 커뮤니케이션이 잘 될 수도 있지만 잘 안될 수도 있다고 생각한다. 🙃
중요한건 알겠지만 다소 모호한 주제인 커뮤니케이션..👀
딱 잘라 정의하기 어려운 주제임에도 불구하고 '커뮤니케이션'에 대해 다루고자 하는 이유는 그만큼 실무에서 동료들간 커뮤니케이션은 필연적이며 비용이 많이 발생하기 때문이다. 이러한 비용으로 인해 개발 시간이 부족해지고 결국 초과 근무로까지 이어질 수 있다. 커뮤니케이션 비용은 불가피한 것이지만, 이를 효율적으로 사용하는 것은 매우 중요한 것이라고 생각한다.
이번 글에서 커뮤니케이션을 잘하는 방법에 대한 정답 내지 정설을 다루는 것은 아니지만, (애초에, 다룰 수도 없고..😅) 얼마되진 않았지만...😅 지난 실무에서 '동료 개발자들'과 함께 '개발'을 함에 있어 보고 듣고 느꼈던 나의 경험에 기반하여 어떤 커뮤니케이션들이 있었고 각각의 커뮤니케이션 방식에 대해 고민했었던 것들에 대해 다루어 보는 것도 나름대로 의미가 있다고 생각했다. 다만, 내가 고민했던 방법에는 예외가 있을 수 있으며, 누군가에게는 좋지 않은 방법일 수도 있음을 인정하고 글을 이어가고자 한다.
코드 리뷰 '잘' 하기 & '잘' 받기
일반적으로 본인이 개발한 작업을 배포하기 전에 팀원들로부터 코드 리뷰를 받는다. 이때, 코드 리뷰는 나의 의견을 상대방의 코드 상에 전달하기도 하고, 나의 코드에 상대방의 의견이 전달되기도 하므로 코드 리뷰 역시 커뮤니케이션의 일종이라고 생각한다. 개인적인 경험 상으로는 코드 리뷰가 개발자들 간 커뮤니케이션이 가장 활발하게 이루어는 순간들 중 하나인 것 같다.
팀원들간 코드 리뷰를 잘 해주고 또한 잘 받으려면 일단 해당 개발 작업분에 대한 배경 지식이 어느정도 비슷해야 한다고 생각한다. 일반적으로, 리뷰이(Reviewee)가 Pull Request 를 올릴 때 관련 이슈 링크를 공유해주곤 하는데, 해당 이슈에 작업분에 대한 히스토리가 충분히 있다면 리뷰어(Reviewer) 입장에서 한결 편하게 코드의 컨텍스트를 파악하고 리뷰에 집중할 수 있게 된다.
하지만, 해당 이슈에 내용이 충분히 담겨있지 않다면 Pull Request 본문에라도 "이 작업을 왜 했는지", "어떤 작업들을 수행했는지", "전후 장단점", "어떠한 의도로 코드를 설계했는지", "어떤 부분을 중점적으로 리뷰받았으면 하는지" 등을 적어놓으면 리뷰어 입장에서 코드 리뷰하는데 많은 도움이 된다. 특히, 리뷰어가 여러명이라면 작업한 사람 한 명의 노력으로 다수의 리뷰어가 시간을 절약할 수 있으니 팀 전체 리소스를 절약할 수 있는 효과도 있다.
리뷰어 입장에서는 코드 상 개선점이 있다고 생각되면 자신의 의견을 전달할 때, "~해야 한다.", "~를 제안한다." 뿐만 아니라 그것을 객관적으로 뒷받침해줄 근거 자료(공식문서, 스택오버플로우 등)도 같이 첨부해주면 리뷰이 입장에서 해당 의견을 훨씬 수용적으로 받아드릴 수 있으며, 팀원들 간 정보 공유도 된다.
또한, 코드 내지 설계의 변경이 필요할 경우 의견과 더불어 기존의 문제점과 변경 시 기대효과를 명시해주는 것도 좋다고 생각하는데, 이러한 기존 방식과 개선 방식 각각의 장단점 등 객관적인 근거들은 기술적 토론의 좋은 자양분이 되기 때문이다. 문답법을 기반으로 코드 리뷰를 하는 경우도 많이 있는데, 이 역시 리뷰이와 리뷰어간 보다 나은 논리를 만들어가는데 많은 도움이 된다고 생각한다. 이러한 논의들은 모두 Pull Request 에 기록되어 추후에 트래킹이 가능하다는 장점도 있다.
하지만, 리뷰이와 리뷰어가 매번 기술적으로 깊이있는 커뮤니케이션을 할 수 있는 것은 아니다. 상황에 따라 급박하게 개발을 해야되는 경우도 많기에 이러한 일련의 과정들을 생략하고 진행해야될 때도 분명히 있으며, 팀원 성향에 따라 보다 간소화된 형식으로 코드 리뷰를 진행하길 원할 수도 있다.
상황에 맞게 '잘' 질문 하기
개발을 하다가 궁금한 점이 생기면 팀원들에게 질문을 할 수 있다. 이때, 질문이라 함은 내가 궁금한 부분을 상대방에게 전달하고, 상대방은 그 질문에 대한 답을 응답한다는 점에서 질문 역시 커뮤니케이션이라고 생각한다.
당연히 팀원들간 질의응답은 매우 중요하며 불가피한 것이지만, 질문을 받는 입장에서는 기존에 하고있는 일이 있는데, 이 질문을 받음으로써 작업에 대한 컨텍스트 스위칭이 발생하므로 질문을 받는 것 역시 만만치 않은 비용이 될 수 있다. (사실, 코드 리뷰도 비용이다.) 따라서, 질문을 하는 사람이 '잘' 질문하는 것은 팀 전체 리소스를 효율적으로 사용함에 있어 매우 중요하다고 볼 수 있다.
일단, 질문 하는 사람은 질문하기 전에 본인이 알아볼 수 있는 것은 충분히 알아봤는지 점검해봐야 한다. 예를 들면, 사내 문서라든가 구글링을 통해 질문에 대합 답이 나온다면 굳이 바쁜 팀원의 비용을 사용할 필요는 없을 것이다. 나의 경우에는 단순히 '이거 뭐에요? 이거 어떻게 해요?' 식의 질문 보다는 '제가 ~ 에 대해 알아보았고 저는 ~ 라고 생각했는데 ~ 부분이 이해가 잘 되지 않는데 이 부분에 대해 설명해주실 수 있을까요?' 식의 질문을 하려고 노력했었다. 이러한 질문을 준비하는 과정에서 굳이 안해도 될 질문들을 걸러낼 수도 있었으며, 그 과정에서 관련 기반 지식들도 습득할 수 있었다.
다만, 언제라고 딱 잘라 말하기는 어렵지만 때로는 본인 스스로 고민하고 알아보는데 걸리는 시간 대비 팀원(보통 연차가 높은)에게 바로 물어보는 것이 더 효율적인 경우도 있다. 👀 이때, 그 팀원은 그 질문에 대답하는데 몇 초밖에 소요가 안될 수도 있기에, 팀 전체 리소스를 놓고 봤을 때 빠르게 팀원에게 질문하고 문제를 해결하는 게 나은 상황이 있을 수도 있다. 💫
문서화는 팀의 자산
문서는 기본적으로 쓰는 사람이 있고 읽는 사람이 있다. 쓰는 사람은 자신의 생각을 문서라는 매개로 상대방에게 전달하고, 읽는 사람은 상대방의 생각을 문서라는 매개로 전달받는다는 점에서 문서 역시 커뮤니케이션이라고 생각한다.
앞서, 질문을 하기 앞서 질문에 대한 답이 사내 문서에 있는지 찾아보는 것이 커뮤니케이션 비용을 절약하는데 도움이 된다고 언급했었는데, 이를 위한 전제 조건이 바로 문서화를 하는 것이다. 개발에 몰입하다보면 나만 아는 지식과 경험을 나만 아는 것으로 끝나는 경우도 많이 있다. 이때, "뭔가 이거는 다른 사람도 궁금해하지 않을까?" 싶은 게 있을 수 있는데, 이러한 경우 문서화를 해놓는다면 팀 전체 커뮤니케이션 비용을 줄이는데 많은 도움이 될 수 있다. 간단하게 예로 들면 기술, 정책 같은 중요한 사항들에 대한 의사결정 과정이나 인프라 아키텍처 등이 있다.
문서화는 일종의 '캐시'와도 같은 것이라고 생각한다. 서버가 클라이언트의 요청을 처리함에 있어 동일한 요청에 대해 동일한 응답을 주는 경우가 반복된다면 캐시를 고려할 수 있듯이 팀 내에서 반복적인 질문에 대해 반복적인 답변을 주어야 한다면 문서화를 고려해볼 수 있는 것이다.비록 문서를 작성하는 사람은 본인의 작업 시간 중 일부를 희생해야하지만, 팀 내 인원이 많을수록 아울러 모두가 궁금해할만한 소재를 다루고 있느냐에 따라 해당 문서가 가지는 잠재적 가치는 크다.
이와 별개로, 요구사항 같이 비지니스의 근간이 되는 부분에 대해 구두로 이루어진 의사결정 과정은 별도로 문서화하는 것이 효용성이 높다. 구두로 커뮤니케이션하는 것의 장점은 빠르고 설명하기 유연하다는 점이 있지만, 단점은 시간이 지나 커뮤니케이션 당사자들이 커뮤니케이션 내용을 까먹을 수 있으며 서로 의견이 합치되었다고 착각할 수도 있다는 점이있다. 이때, 문서는 기록으로 남기에 이러한 구두 기반 커뮤니케이션의 단점을 보충할 수 있는 부분이 많다.
하지만, 무작정 문서를 많이 만든다고 마냥 좋은 것만은 아니다. 앞서 말했듯이 문서를 작성하는 것은 비용이며, 해당 문서를 지속적으로 관리하는 것 역시 비용이다. 이때, 문서의 가독성과 관심도(비유를 하자면, 캐시 히트율...)에 따라 딱히 도움이 되지 않을 수도 있기 때문이다. 그래도 문서 만큼은 왠만하면 팀 내에 좋은 영향을 끼칠 확률이 높기에, 문서화 습관은 좋은 습관이라고 생각한다.
커뮤니케이션을 위한 마인드 셋
설계, 코드 리뷰, 페어 프로그래밍 등 팀원들과 각종 커뮤니케이션을 하다보면 자신의 의도 및 논리가 상대방의 의도 및 논리와 충돌하는 경우가 많다. 때로는 "내 생각이 당연히 맞는데, 상대방은 왜 저런 생각을 하는거지?"라고 생각될 때도 있다. 특히, 자기가 설계하거나 개발한 것에 대해서는 상대방의 비판에 대해 무의식적으로 방어적인 스탠스를 취하게 될 수도 있다. 물론, 자신의 당초 생각과 의도가 맞을 수도 있지만 이러한 방어적인 스탠스로 인해 상대방의 좋은 피드백을 놓치게 될 수도 있다. 이는 상대방의 생각을 제대로 이해하지 못한 것이므로 커뮤니케이션에 실패한 것이라고 볼 수 있다.
커뮤니케이션을 잘하기 위해서는 이성적으로 마음가짐을 가져야할 부분이 있다고 생각한다. 일단, 어떠한 방식으로든 커뮤니케이션을 함에 있어 말투, 표정 등에서 감정을 드러내지 않아야 한다. 상대방에게 감정을 드러낸다는 것은 무의식적으로 본인의 판단도 흔들릴 수 있을 뿐더러 상대방의 심리에도 영향을 끼쳐 커뮤니케이션에 많은 노이즈가 가해질 수 있기 때문이다. 사실, 이는 커뮤니케이션 문제를 넘어 앞으로 팀 내 협업을 하는데 있어 영향을 주는 것이기에 정말 주의해야한다고 생각한다.
또한, 확증 편향에 항상 유의해야한다. 일반적으로 자신의 생각과 논리대로 차근차근 무엇을 구현해낸 경우 해당 작업분에 대한 확신이 생길 수 있다. 이러한 확신에 갇혀있다 보면 상대방의 피드백을 올바르게 이해하지 못하게 되는 경우가 있다. 쉽지 않은 일이지만, 의식적으로라도 자기 확신에 벗어나고자 생각과 마음을 열어놓아야 한다.
이와 함께 중요한 것은 경청이다. 자기 확신에 갇히다 보면 상대방의 의견을 넘겨 짚거나 흘러 듣는 경우가 생길 수 있는데, 이로 인해 상대방의 생각과 의도를 올바르게 이해하지 못하게 된다. 마찬가지로 쉽지 않은 일이다. 하지만, 상대방의 의견을 이해한 내용을 정리해서 상대에게 확인을 구하거나 메모장에 상대방의 의견을 정리하는 등의 의식적인 행동이 상대 의견을 경청하는데 도움을 줄 수 있다.
커뮤니케이션에 영향을 끼치는 감정적 교류
최근에, 어떤 개발자 커뮤니티에서 직언하는 사람과 돌려 말하는 사람 중 어떤 동료와 일하고 싶은지에 대한 글이 화제였었다. (사실, 같이 일하고 싶은 동료의 조건 변수는 이외에도 무궁무진하지만...🤣) 답답해서 직언하는 사람이 좋다는 사람이 있고, 좀 더 유한 성격이라서 돌려 말하는 사람이 좋다는 사람도 있었다. 즉, 사람에 따라 선호하는 커뮤니케이션 방법이 있다는 것을 생각해볼 수 있었다.
사실, 커뮤니케이션의 사전적 정의는 '사람들끼리 서로 생각, 느낌 따위의 정보를 주고받는 일'이라고 하지만, 사람은 감정의 동물이기에 단순히 정보를 주고받는 것에만 그치지 않고 그 과정에서 상대방과의 감정적 교류도 있을 수 있다. 앞선 사례에서 돌려 말하는 사람을 선택했던 사람들은 단순 정보 교류도 중요하지만 감정적 교류도 중요하다고 생각하지 않았을까 싶다. 물론, 직언하는 사람을 선택했던 사람들도 정보 전달을 직언으로 듣는 것을 선호한다는 것이지 감정적으로 불쾌함을 느끼게 말하는 사람을 선호한다는 의미는 아니었을 것이다. 🤣
개인차는 있겠다만, 팀 내에서 좀 더 원활한 커뮤니케이션이 가능해지려면 팀원간 어느정도 감정적 벽이 허물어져야 한다고 생각한다. 극단적인 예시로, 친한 동기와 커뮤니케이션을 하는 것과 무서운 부장님과 커뮤니케이션을 하는 것에는 엄청난 차이가 있으며, 이는 정보 전달에도 영향을 끼칠 수 있다. 사실, 이는 조직 문화와도 관련이 깊은데, 자유로운 의견을 개진함에 있어서는 수평적인 조직 문화가 유리한 측면이 많다고 생각한다. 나의 경우 개인적인 노력으로 팀 내 사람들과 허물없이 지내기 위해 출퇴근 때마다 가볍게 인사드리거나 가끔 트래쉬 토크를 걸기도 한다. 특히, 말투에 있어서는 상대방이 기분 나쁘지 않도록 항상 유의한다.
커뮤니케이션은 어렵다.. 하지만, 중요하다..!! ☕
지금까지 거창한 표현을 써가며 커뮤니케이션에 대해 고민해온 내용들을 나열해봤지만, 이 글을 쓰는 나 조차 아직 위에 나열된 커뮤니케이션들을 잘 한다라고 자신있게 말하기는 어렵다. 1년차 신입 개발자로서 차근차근 배워나가고 있는 중에 있다. 🏃♂️ 아울러, 이외에도 많은 종류의 커뮤니케이션들과 좋은 노하우들이 존재하며, 나열된 내용들 역시 모든 상황에 적용되지 않으며 예외가 존재한다.
비지니스에서 커뮤니케이션을 잘하기 위해서는 상대방뿐만 아니라 본인이 속한 조직 문화도 어느정도 이해하고 있어야 한다. 즉, 이를 위해선 시간이 필요하다. 이때 커뮤니케이션을 잘 하기 어려운 점은 정답이 있는 것이 아니라 (시중에 어느정도 정형화된 방법으로 공개되어 있긴 하지만) 커뮤니케이션 상대에 따라 최적의 커뮤니케이션 방식이 정해지기 때문이다. 아울러, 본인은 커뮤니케이션을 잘하고 있다고 생각할 수 있지만 상대방은 그렇게 느끼지 않을 수도 있기에, 본인의 커뮤니케이션 능력을 객관화 함에 있어 각별히 유의해야 한다.
개인적으로 이렇게 정답이 정해져있지 않은 주제를 글로 쓰는 것을 선호하진 않지만, 팀 내에서 팀원들간 커뮤니케이션이 잘 되면 얻을 수 있는 장점이 굉장히 많기에 한번쯤은 본 내용에 대해 다루고 싶었다. 팀원들간 커뮤니케이션이 잘 된다는 것은 그 만큼 적은 비용으로도 정보를 효과적으로 전달할 수 있다는 것이므로 남은 비용을 에너지를 충전하는데 사용하거나 보다 생산적인 일에 투자할 여력이 생기게 된다. 이렇게 팀원들간 커뮤니케이션이 잘 되는 것이 '팀워크가 좋다'라고 할 수 있지 않을까 생각해보며 글을 마무리 한다. ✍