근거가 명확한 소통의 중요성

하루 종일 회의하고 퇴근하는 길. 열심히 일한 기분이 드는 한편, 마음 한구석이 왠지 찜찜하다. 긴 회의가 최선이었는지, 또 기나긴 얘기 끝에 팀원들이 정말 같은 지점을 바라보게 된 것이 맞는지 의구심이 남는다. 그리고 다음 날 오후, 의심은 현실이 되고 팀은 또다시 회의의 늪에 빠진다.

“어제 제가 말씀드린 내용을 제대로 이해하신 것이 맞나요?”

우리 팀의 회의는 왜 이렇게 길까?

한 팀이 되어 일할 때, 일에 대한 이해를 높이기 위해 회의를 한다. 회의에 참여하는 사람이 많을수록 사안에 대한 의견도 다양하므로 회의 시간은 길어진다. 그러면 둘이서 하면 짧을까? 꼭 그렇지도 않다. 이야기는 늘 예상치 못하게 길어지는 법이다.

회의가 길어지는 이유, 그렇게 길게 대화해도 서로의 말을 이해할 수 없는 이유 중 하나는 서로가 가진 근거가 명확하지 않기 때문이다. 회의도 토론이다. 좋은 토론에서는 구체적인 근거들을 바탕으로 날카로운 주장이 오간다. 기획 의도, 디자인 의도, 코드 작성 의도는 각자가 가진 근거들이다. 이 근거에 대해 충분히 생각해보지 않고 회의에 참여한다면, 주장을 설득력 있게 전달하기 어렵다.

하지만 근거를 탄탄히 준비한다면, 팀원들은 짧게 회의해도 서로의 요구를 쉽게 확인할 수 있다. 가령, 기획자는 기획안을 설명할 때 어떤 기능이 들어가야 할지, 그 이유는 무엇이라고 생각하는지 세심하게 설명할 수 있어야 한다. 만약 동료의 질문에 제대로 답변하지 못하고 자주 멈칫한다면, 아직 본인의 생각이 명확하지 않은 것이다. 또한 개발자는 자신이 개발하는 방식과 이유를 설명할 수 있어야 한다. 테스트케이스도 미리 다양하게 생각해본다. 이렇게 구체적이고 명확한 질문과 답변들이 오간다면 그 회의는 밀도가 높아지고, 팀원들의 머리에 같은 그림이 그려진다.

명확한 근거란 무엇일까?

구체적인 근거를 제시하기 위해서는 팀 회의에 참석하기 전에 자기 자신과 먼저 충분히 회의해야 한다. 나의 주장에 대해 가능한 반론들을 예상해보고 스스로 피드백하면서 논리의 모순이나 근거의 허점을 없애야 한다.

좋은 근거로는 다음과 같은 것들을 생각해볼 수 있다.

• 출처가 명확한 통계자료
• 전문가의 소견
• 구체적인 사례

다수의 사용자가 겪는 불편을 해결하는 기능을 만들고자 한다면 통계자료를 활용할 수 있다. 유저 데이터를 통해 문제가 주로 발생하는 경로를 파악하고, 설문조사를 통해 기능의 요구사항을 결정할 수 있다. 또한 일반적으로 많이 사용되거나 최근의 트렌디한 디자인과 개발 방법을 사용하는 것도 통계자료를 활용해 설명할 수 있다. 이미 많은 사람이 사용해본 방법이라면 사례에 대한 자료를 다양하게 검색할 수 있는 장점이 있다.

전문가의 소견을 가장 잘 활용할 수 있는 경우는 코드 리뷰이다. 좋은 코드에 대한 견해는 사람마다 엇갈릴 수 있겠지만, 경험이 많은 사람이 제시하는 방법에는 아무래도 힘이 실린다. 유명한 개발 블로그에서 소개된 방법을 사용한다면, 형식과 구조가 검증되었을 가능성이 높다.

직접 겪은 경험을 근거로 드는 것도 설득에 도움이 된다. 자신의 주변에서 발생한 일은 중요하게 느껴지게 마련이다. 때로는 유저들의 열 마디 말보다 팀원 한 번의 경험이 크게 다가오는 경우들이 있다. 그러므로 직접 겪은 사례를 잘 활용하면 주장에 힘을 실을 수 있다.

근거가 불명확하면 벌어지는 대참사

코드 리뷰도 일종의 회의이다. 한 팀원이 다른 팀원의 코드에 리뷰하는 상황을 예로 들어보자.

리뷰어: “10번째 라인의 A 문법을 B로 바꾸는 게 더 좋아 보입니다.”

코드 작성자: “그렇게 생각하신 이유가 무엇일까요?”

리뷰어: “B가 사용하기 더 편합니다.”

코드 작성자: “가독성은 비슷해 보이는데 혹시 어떤 지점에서 B가 A보다 편하다고 생각하시나요?”

리뷰어: “B가 저에게 더 익숙합니다.”

코드 작성자: “서로 익숙하다고 생각하는 문법에 차이가 있네요. 혹시 B의 성능이 더 좋아서 주로 사용하시는 걸까요?”

리뷰어: “이유에 대해서는 다시 한번 생각해 보겠습니다.”

아홉 줄에 걸쳐서 코멘트가 이루어졌지만 코드작성자는 결국 리뷰어가 B를 추천한 이유를 파악하지 못했다. 리뷰어는 자신의 주장을 명쾌하게 설명하지 못했고, 코드 작성자는 이 주장을 이해하기 위해 여러 번 질문해야 했다. 두 사람은 A와 B를 비교하는 데에 불필요한 시간과 체력을 들임으로써 코드의 다른 부분을 좀더 같이 살펴볼 수 있는 기회비용을 날리게 되었다.

이 리뷰를 간소화할 수 있는 힘은 B를 주장한 리뷰어에게 있었다. 그렇지만 부족한 근거로 코드 리뷰를 진행했고, 명확한 설명마저 하지 못했다. 코드 리뷰를 할 때 이러한 논의가 자주 벌어진다면, 팀원들은 점차 피로감을 느낄 것이다. 하지만 만약 리뷰어가 코멘트를 달기 전에 주장에 대한 명확한 근거를 준비했더라면, 이 리뷰는 훨씬 간소화되었을 것이고 작성자도 더 빠르게 상대의 주장을 이해했을 것이다. 이처럼 좋은 근거를 가진 주장은 토론의 효율을 높이고 더 의미 있는 시간을 쓰게 만든다.

몰입하는 회의는 어떤 모습일까?

나는 회의에 진심으로 몰입하는 사람들을 본 적 있다. 바로 영화 <어벤저스>의 히어로들이다. 한 번뿐인 기회로 지구인의 절반을 구해내겠다는 중요한 목표를 가진 이들의 회의 시간은 굉장히 밀도가 높게 진행된다.

회사에서 우리가 하는 일은 세상을 구하는 일은 아니지만, 각각의 일들이 쌓여 커리어의 방향이 결정된다. 그러므로 기획 회의와 코드 리뷰를 비롯한 모든 회의에서는 모두에게 고도의 집중력과 노력이 요구된다.

나 역시 즐겁게 회의에 몰입했던 경험이 있다. 그건 대부분 프로젝트가 중반 정도 진행됐을 무렵이었다. 각자가 원하는 게 가장 분명해졌을 때, 그리고 서로의 근거를 드디어 이해하고 공감대가 형성되었을 시점이 항상 프로젝트 중반부였던 것 같다. 이 시점이 프로젝트를 시작하고 바로 찾아오면 좋겠다는 생각을 늘 했지만, 초반부의 회의는 언제나 길고 지루했다. 주니어 레벨로 구성된 팀의 한계였는지도 모르지만, 우리가 가진 근거는 처음에는 늘 불명확했다. 하지만 서로의 말을 이해하기 위해 열심히 질문하고, 다음 회의에서는 각자가 준비해온 답변들로 논의를 이어갔다. 그러다 보면 서로의 말을 이해하는 순간이 찾아왔다.

이러한 예열과정이 팀 회의에 앞서 각자 할 수 있는, 그리고 해야만 하는 과정이다. 주장에 대한 명확한 근거를 만들기 위해 스스로 질문하는 시간을 충분히 갖는다면, 회의에서 다 같이 헤매는 시간도 줄어들 것이다. ‘내가 제시하려는 이 방법을 과연 상대방은 생각하지 못했을까?’, ‘상대방은 왜 저 방법을 선택했을까?’ 같은 상대의 입장을 고민하는 시간이 필요하다.

밀도 있는 토론은 활기찬 팀을 만든다

타인을 쉽게 이해시킬 수 없는 주장으로는 상대를 설득할 수 없을 뿐 아니라 합의점에 도달할 수가 없다. 자신이 왜 이 행동을 하려고 하는지 명확한 이유를 말하지 않는다면 상대방은 나의 근거를 추측할 수밖에 없고, 아마도 나는 상대방이 추측해서 내놓은 대안들이 마음에 들지 않을 것이다. 그렇다면 나는 또다시 주장을 반복할 것이고, 결국 이 대화의 주제는 나의 주장에만 머무를 뿐 상대의 대안에 대한 논의나 합의안으로 좀처럼 나아갈 수 없다. 그러므로 팀에 속해 있다면, 언제나 팀원을 명료하게 이해시키는 데에 초점을 맞추어야 한다.

근거를 잘 드는 건 물론 쉽지 않은 일이다. 하지만 다른 사람의 생각을 추측하는 건 더 고통스러운 일이다. 밀도 있는 토론을 위해서는 평소 생각이 논리정연하게 정돈되어 있어야 하고, 풍부한 배경지식을 쌓기 위한 시간도 많이 든다. 그러나 이러한 노력을 하지 않으면, 피드백하는 팀원들이 결국 지치게 된다. 팀원들이 번번이 내 생각을 끄집어낼 수 있도록 도와줄 수는 없다.

그렇기에, 좋은 회의문화를 가진 팀은 그만큼 팀원들이 노력하고 있는 것이다. 날카로운 주장에는 고민의 흔적이 고스란히 담긴다. 근거가 명확하면 팀원들은 서로의 의견을 온전히 이해할 수 있다. 사람들은 좋은 근거를 제시하는 팀원을 신뢰하고, 연속적인 협업을 하는 관계에서 이러한 신뢰는 큰 자산이다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.