[번역] How to Communicate

원문 : https://playfulprogramming.com/posts/how-to-communicate/

수많은 엔지니어들과 일하다 보면, 그들은 정말 뛰어난 두뇌를 가지고 있는 경우가 많습니다. 마음만 먹으면 거의 무엇이든 해낼 수 있는 사람들이죠. 하지만 대부분은 결정적인 약점을 하나 가지고 있습니다. 바로 커뮤니케이션입니다.

조직에서 요구하는 커뮤니케이션 수준에 부합하는 개발자를 만난 적은 거의 없습니다. 다만 그런 개발자들은 대체로 빠르게 그룹의 리더로 성장하더군요. 자신과 동료들의 막힘을 더 빠르게 풀어내며 실제 생산성을 끌어올리거나, 동료들이 일하는 방식을 한 단계 끌어올려 더 생산적이라고 느끼게 만들거나, 혹은 둘 다 해내기 때문입니다.

제가 그동안 의지해 온 커뮤니케이션 도구함 속 여러 도구들을 함께 살펴보겠습니다.

효율적인 메시지의 해부학

팀에 효과적인 메시지를 작성하는 일에는 생각보다 많은 요소가 들어갑니다. 가벼운 잡담은 그저 즐거움이 목적이지만, 특정 목적을 가진 커뮤니케이션은 목표가 완전히 달라집니다.

이제 여러분의 1순위 목표는 즐거움이 아니라, 정보를 전달하고, 변화를 이끌어내며, 그 과정을 직설적으로 해내는 것입니다.

이를 실현하기 위해, 메시지의 효과를 끌어올리는 몇 가지 패턴을 따라볼 수 있습니다.

”No Hello”와 “Don’t Ask to Ask”

엔지니어링에서 몰입 상태(flow state)는 개인의 생산성에 매우 중요합니다. 몰입 상태에 들어가는 데 가장 큰 부분은 한 가지 작업에 방해받지 않고 집중할 수 있는 시간인데요, 사방에서 알림이 날아오는 환경에서는 이를 달성하기 어렵습니다.

그래서 많은 엔지니어들은 기기를 “무음”으로 해두고 자신의 작업에 몰두합니다. 작업이 끝난 뒤에야 그동안 놓친 메시지들을 확인하죠. 이를 흔히 “비동기 커뮤니케이션(Asynchronous communication)“이라고 부릅니다. 각자 시간이 될 때 주고받는 방식이죠.

이는 전화 통화처럼 같은 시간에 즉각적인 주고받음을 기대하는 “동기 커뮤니케이션(Synchronous communication)“과는 완전히 다릅니다.

문제는 많은 사람들이 메시지를 동기 커뮤니케이션처럼 다룬다는 것입니다. 메시지는 본래 비동기로 활용될 때 가장 효과적인데도 말이죠.

예를 들어 어떤 사람들은:

• “안녕하세요”나 다른 인사말을 보낸 뒤 답을 기다린 후에 본론을 꺼냅니다.
• “혹시 질문 하나 드려도 될까요?”라며 질문해도 되는지부터 물어봅니다. 마찬가지로 답을 받은 뒤에야 실제 질문을 합니다.

이 둘 모두 대면 대화에서는 흔한 풍경이지만, 메시지에서는 그다지 유용하지 않습니다.

왜 그럴까요?

자, 다른 팀 사람과 소통하는 상황을 떠올려 봅시다. 어떤 정책 절차를 어떻게 진행해야 하는지 묻고 싶고, 그건 그 팀의 절차입니다.

“안녕하세요, 혹시 자리에 계신가요?”

답을 기다립니다. 몇 시간이 지나서야 답이 옵니다.

“앗, 죄송해요. 자리에 없었어요. 무슨 일이세요?”

업무 시간이 지난 뒤에 온 답장입니다. 알고 보니 긴 그룹 미팅이 있었더군요. 다음 날 출근해서 보냅니다.

“괜찮아요! X는 어떻게 하면 되나요?”

다음 날 늦은 시간에야 다시 답을 받습니다. 이번에는 가족에게 급한 일이 있었다고 합니다.

만약 처음 “혹시 자리에 계신가요?” 메시지에 곧바로 “X는 어떻게 하면 되나요?”라고 물었다면, 하루 일찍 답을 받을 수 있었을 겁니다.

이 문제는 팀이 서로 다른 시간대나 근무 일정에 있을 때 기하급수적으로 커집니다. 커뮤니케이션 자체가 본질적으로 비동기일 수밖에 없는 환경이니까요.

그래서 저는 첫 메시지에 가능한 한 많은 맥락을 담을 것을 권합니다. 비동기 커뮤니케이션을 그 본래 의도대로 사용하세요.

Bottom Line Up Front (BLUF)

BLUF, 즉 “Bottom Line Up Front”라는 표현은 미군에서 유래했지만, 그 핵심 원칙은 일반 업무 환경에서도 매우 유용합니다. 골자는 단순합니다. 긴 메시지일수록, 궁극적으로 묻고 싶은 핵심을 대화 맨 앞에 두라는 것이죠.

이 방식은 누구에게나 도움이 되지만, 직급이 높거나 매우 바쁜 사람들에게는 두 배로 유용합니다. 의사결정에 필요한 잡음을 줄여주고, 이후 커뮤니케이션에서 어디에 에너지를 다시 집중할지 판단할 수 있게 해주기 때문입니다.

포맷팅에 집중하기

혹시 알고 계셨나요? 소프트웨어 개발 관련 사이트의 평균 체류 시간은 2분 30초가 약간 넘는 정도라고 합니다.

많은 사이트들이 — 이 사이트를 포함해서 — 사용자가 더 오래 머물도록 쓰는 트릭 중 하나는, 큰 텍스트 덩어리를 다양한 포맷팅으로 쪼개는 것입니다.

예를 들면:

• 리스트
• 표
• 엠 대시(—)
• 굵은 글씨
• 기울임 글씨

이 모두는 콘텐츠를 한눈에 파악하기 쉽게(glanceable) 만들어줍니다. 콘텐츠가 한눈에 들어올수록, 끝까지 읽어낼 가능성이 높아지죠.

같은 가설은 메시지에도 그대로 적용됩니다. 의도를 파악하는 데 중요한 키워드가 몇 개 있다면, 굵게 표시하세요! 여러 질문을 던지고 싶은데 그중 특정 항목에 대한 답이 꼭 필요하다면?

• 번호를 매기세요
• 후속 대화에서도 그 번호를 사용하세요

그래야 상대가 “1번에 대해서요”라고 말했을 때, 서로 무엇을 이야기하고 있는지 정확히 알 수 있습니다.

팀의 커뮤니케이션을 설계하기

하지만 메시지 구조를 정리하는 것만으로 팀 커뮤니케이션의 모든 문제가 해결되지는 않습니다. 좀 더 시스템 차원에서 커뮤니케이션을 개선할 수 있는 방법들을 살펴봅시다.

동기 vs. 비동기

다들 한 번쯤 들어본 말이 있을 겁니다. “이건 이메일로도 충분했을 텐데.”

그리고 사실, 대부분의 회의가 정말로 그랬을 가능성이 큽니다. 늘어지는 회의는 시간을 잡아먹을 뿐 아니라, 조직에서 시간은 곧 돈입니다(높은 엔지니어 연봉을 떠올려보세요). 다음 표를 한번 보시죠.

이게 고작 주 1회 회의의 비용입니다! 제가 VP로 회사에 처음 합류했을 때, 많은 팀원들이 매일 한 시간 반 가까이 진행되는 전사 콜에 참여하고 있다는 사실을 알고 충격을 받았습니다. 시간이 누적되면서 발생한 비용을 상상해 보세요!

만약 동기 회의를 꼭 해야 한다면, 다음 조건은 갖추어야 합니다.

• 명확한 안건이 있을 것
• 모든 참석자가 반드시 필요할 것
• 어느 정도의 시간 민감성을 가질 것

요약 정리하기

점심 시간 직전, 까다로운 주제로 스레드를 시작합니다. 답이 필요한 상황이죠. 우리가 지금까지 이야기한 맥락, 포맷팅 같은 요소를 모두 잘 챙겨 메시지를 보냅니다. 그리고 점심을 먹으러 갑니다. 돌아와 보면…

아이고. 팀에 그 주제에 대해 할 말이 정말 많았던 모양입니다. 그런데 여러분은 자리에 없었죠! 이 59개의 메시지를 다 따라잡아야 할까요? 그리고 다음에 이 스레드를 보게 될 사람은요?

요약은 여러 아이디어를 한꺼번에 정리해두는 훌륭한 방법입니다. 맥락과 뉘앙스를 보존하면서도, 불필요한 잡담을 걷어낼 수 있죠.

이를 위한 몇 가지 방법:

• 스레드의 최상단 메시지에 요약을 덧붙이고, 가능하다면 핀 고정하기.
• 채팅 앱에서 벗어나 RFC 문서로 옮겨, 특정 항목에 코멘트하고 편집하며 여러 제안을 나란히 다루기.

특히 두 번째 방법은, 그 결정이 장기적인 영향을 미치는 사안일 때 매우 효과적입니다. 미래의 누군가에게 참고할 수 있는 기준점이 있다는 건 팀 커뮤니케이션에서 큰 자산입니다.

기록 가능한 커뮤니케이션을 기본값으로

팀과 일하다 보면, 특정 기술이나 의사결정에 관해 DM(다이렉트 메시지)으로 질문을 받는 일이 흔합니다.

별 일 아닌 듯 보이고, 악의가 있는 것도 거의 아니지만, 다음과 같은 이유로 문제가 될 수 있습니다.

• 정보가 일부 사람들에게만 갇혀 있어, 나중에 다른 사람들과 공유하기 어려워집니다.
• 그 주제에 대해 잘 아는 다른 사람들이 대화에 참여할 수 없습니다.
• 그 자리에 있었다면 자연스럽게 같은 지식을 얻었을 주변 사람들에게 정보가 전파되지 않습니다.

이는 메시지에만 국한된 이야기가 아닙니다. 1:1 통화로 페어 프로그래밍을 하자고 부르는 일도 마찬가지죠. 도움이 될 때도 있지만, 다른 사람들이 함께 참여하거나 그 경험에서 배울 수 없게 됩니다. 또한 그런 통화에서 내려진 비즈니스 또는 기술적 결정은 흔히 사라지거나, 나중에 새로운 시각으로 다시 평가해야 하는 경우가 많습니다.

이 문제를 풀기 위해 저는 커뮤니케이션을 기본적으로 공개하는 방식을 권장합니다. 즉, 명확히 비공개가 더 적절한 경우를 제외하고, 모든 질문은 메시지나 글의 형태로 — 인덱싱되고 손쉽게 찾을 수 있는 형태로 — 진행되도록 하는 것입니다.

비동기 콜 역시 마찬가지입니다. 누구나 자유롭게 들어올 수 있는 공간에서 진행하거나, 메모를 남기거나 AI로 전사된 녹화본을 게시하거나, 둘 다 하면 좋습니다!

팀 규모로 인한 위축

비공개 소통이 기본이 되어버리는 이 문제는, 질문을 던질 만한 공간이 큰 그룹 채팅뿐일 때 더 심해집니다. 많은 사람들은 바보처럼 보일까봐 위축되곤 하니까요.

이를 완화하려면, 공개적으로 보이지만(또 메시지를 남길 수도 있지만) 굳이 외부에 광고되지는 않는 작은 환경을 만들어주면 좋습니다. 그곳에 꼭 필요한 사람들만 자연스럽게 모이도록 말이죠.

이는 또한 다른 사람들(특히 주니어들)이 자기 목소리를 내도록 돕기 위해, 더 넓은 차원에서 문화적인 변화가 필요하다는 신호이기도 합니다. 사소해 보이는 발언이라도 공개적으로 해준 것을 인정하고, “바보 같은” 질문을 벌하지 말고, 정기적으로 활발한 Q&A 시간을 장려하세요.

커뮤니케이션을 통한 리더십

팀에 속한 사람들은 무엇보다도 사람입니다. 엔지니어링 작업과 소프트 스킬 사이를 오가는 컨텍스트 스위칭은 결코 쉽지 않습니다. 그 길을 걷는 데 도움이 되도록, 동료들과 대화할 때 제가 늘 마음에 새기는 몇 가지를 소개합니다.

먼저 이해하려고 하기

새로운 팀(혹은 새로운 팀원)과 일할 때, 자신의 기존 지식과 경험을 활용해 곧장 변화를 만들고 빠르게 추진하고 싶은 유혹이 강하게 듭니다.

하지만 그 전에, 부탁드립니다. 본인의 의견을 내기 전에 가능한 한 많은 질문을 던지세요.

질문을 먼저 던지면, 시스템의 어느 지점이 아픈지 파악할 수 있습니다. 종종 누군가는 이미 당신에게 직관적인 그 방식을 시도해봤고, 어떤 이유로 벽에 부딪혔을 수 있습니다. 호기심 많은 자세를 가지면, 이미 시도되고 폐기된 아이디어를 다시 꺼내드는 헛수고를 피할 수 있습니다.

당신이 그 주제에 대한 전문가라 하더라도, “먼저 묻는” 자세는 강력한 도구입니다. 저는 특히 두 가지 상황에서 이 자세가 큰 효과를 발휘하는 것을 봤습니다.

1. 상대가 배우려는 의지는 있지만, 어떤 질문을 해야 할지 아직 모를 때.

   이 경우, 적절한 질문을 통해 상대가 자신의 출발점을 설명할 수 있게 됩니다. 이렇게 형성된 기준점은, 당신이 상대의 한계와 기존 신념을 더 잘 이해한 상태에서 들어가 가르치는 데 참고점이 되어줍니다.

2. 상대가 배우려는 의지가 없고, 자기가 더 잘 안다고 믿고 있을 때.

   이런 상황에서, 질문은 상대가 가진 오해를 뚫고 들어가는 데 도움이 됩니다. 어떤 경우에는 그들이 정말 옳을 수도 있습니다. 그 영역에서 충분히 시간을 쌓아 당신보다 더 날카로운 시선을 가졌을 수도 있죠. 또 어떤 경우에는, 당신이 그 주제에 더 정통하지만, 상대의 학습 거부가 어떤 오해(혹은 그 비슷한 것)에서 비롯되었음을 발견하기도 합니다.

어떤 경우든, 먼저 질문함으로써 상대가 어디에 서 있는지 파악하고, 그들을 당신의 목표 쪽으로 안내할 수 있게 됩니다.

시스템적으로 근거 덧붙이기

저만 그런지 모르겠지만, 어렸을 때 부모님의 결정에 “왜요?”라고 물었을 때 돌아오던 “내가 그러라고 했으니까”라는 답이 정말 싫었습니다.

순수한 호기심에서 출발한 질문이, 자신의 사고 과정을 설명하기 꺼리는 태도 앞에서 막혀버리곤 했죠. 이런 상황은 보통 아이의 고집과 비협조로 이어집니다. 무시당하고 가르침을 받지 못한 느낌이 드니까요.

이제 어른이 되고 일을 하다 보니, 많은 매니저들이 같은 실수를 반복하는 모습을 봅니다. 그 정도로 노골적이지는 않을지언정, 많은 관리자들이 엔지니어링 요청을 내릴 때 그 결정이 어떻게 내려졌는지에 대한 근거를 함께 전달하지 않습니다.

두 경우 모두, 상대가 풀고자 하는 문제를 더 깊이 이해할 수 있는 가능성을 차단합니다. 반발로 이어지지 않더라도, 솔루션에 깊게 몰입하는 데 한계가 생깁니다. 심지어 늘 적극적으로 참여하는 사람을 만난다 해도, 발견 단계에서 당신이 놓쳤을 만한 질문을 그들이 던질 수 없게 됩니다.

적극적 경청 연습하기

팀원과 1:1 미팅을 잡을 때, 다른 일정과 겹쳐서 진행하고 싶은 유혹이 자주 듭니다. 가령 점심을 먹고 돌아오는 운전 중에, 한산한 길이니 대화에 충분히 집중할 수 있다고 스스로 합리화하는 식이죠.

하지만 부탁드립니다. 그런 유혹은 피하세요. 대신, 중요한 미팅(특히 1:1)에는 최대한 온전히 집중해주세요. 그 방법으로:

• 미팅 중에 다른 일을 하지 않습니다.
• 평소엔 끄더라도, 카메라를 켭니다.
• 더 많은 정보를 끌어내기 위해 열린 질문을 사용합니다.
• 통화 중에 드러나는 감정을 인정해줍니다.
• 들은 내용을 다시 정리해서 말함으로써, 제대로 이해하고 있는지 확인합니다.

기억하세요. 팀을 이끌고 있다면, 그 팀원들은 당신에게서 기술적인 가이드뿐 아니라 심리적 안전감을 기대합니다. 스스로 최대한 주의를 기울이도록 강제함으로써, 당신은 그들 편이며 기꺼이 도울 의지가 있다는 사실을 거듭 확인시켜 줄 수 있습니다.

들은 말을 다시 정리해주는 것이 사소해 보일 수도 있지만, 정말 도움이 됩니다! 이런 적극적 경청은 상대가 자신이 잘 받아들여지고 있다고 느끼게 해줄 뿐 아니라, 이해의 오류를 바로잡는 데도 도움이 됩니다. 저도 잘못 들은 내용을 그대로 요약해 말하다가, 비로소 제 이해의 빈틈을 발견했던 적이 여러 번 있습니다.

막지 말고 함께 만들기

같이 일하기 까다로운 유형의 엔지니어가 있습니다. 당신과 팀이 감당할 수 있는 단계보다 몇 발자국이나 앞서가고 싶어 하는 사람들이죠. 사용자가 수천 명인 상황에서, 수백만 명 규모를 미리 설계하려 들기도 합니다.

그런 엔지니어가 왜 함께 일하기 까다롭다는 거죠? 시기는 안 맞을지언정, 좋은 아이디어를 가져오는 사람들이잖아요?

정확합니다. 문제는 바로 그 시점입니다. 많은 매니저들이 동료의 아이디어를 한 번 미뤄두면서도 그 사람의 열정을 식히지 않게 다루는 일을 어려워합니다.

생각해 보면, “안 됩니다”라는 말을 자주 듣는 건 누구에게도 즐거운 일이 아닙니다. 평소 충분한 재량을 부여받고 자기가 믿는 일을 자유롭게 추진하는 사람에게도 마찬가지입니다. 일에 대한 흥분이 부정적인 톤으로 한 번이라도 가로막히면, 그 사람의 일을 대하는 마음가짐이 송두리째 바뀌어 버릴 수 있습니다.

그래서 어떻게 해야 할까요? “Yes, and” 화법을 쓰세요!

이건 그 일에 곧장 리소스를 투입하는 데 동의한다는 뜻은 아닙니다. 다만 상대의 흥분을 활용하면서, 그 방향을 살짝 비틀어주는 것입니다.

좋아요! 우리가 도달해야 할 비전으로서 정말 멋진 그림이네요. 그렇다면 이 컨셉을 증명할 수 있는, 하루 안에 만들어 볼 수 있는 버전은 뭐가 있을까요?

이쪽이 다음 표현보다 추진력을 훨씬 더 잘 유지시켜 줍니다.

그건 우리가 다룰 범위를 너무 벗어난 것 같네요.

칭찬은 공개적으로, 지적은 사적으로

기준에 못 미치는 행동을 봤을 때, 그 자리에서 — 그것이 그룹 환경이든 아니든 — 곧장 짚고 넘어가고 싶은 마음이 들 수 있습니다. 극단적인 경우에는 그게 적절할 수도 있지만, 대체로는 “칭찬은 공개적으로, 지적은 사적으로”라는 원칙을 따르는 편이 좋습니다.

예를 들어, 스탠드업에서 누군가가 본인이 보기엔 범위가 지나치게 넓어진 PR을 언급한다고 합시다. 그 자리에서 “이 작업은 이렇게 쪼개면 좋겠다”고 코멘트하고 싶은 충동이 들 수 있지만, 그렇게 하면 작업 관계에 균열이 생길 수 있습니다.

다른 사람들 앞에서 망신을 당하는 건 결코 유쾌한 경험이 아닙니다. 저만 그런지 몰라도, 저는 단체 환경에서 지적을 받으면 — 비록 그게 꼭 들어야 할 피드백일지라도 — 발끈하고 방어적으로 변하는 편입니다.

물론 이게 다른 팀원에 대한 부정적인 점을 윗선과 공유할 수 없다는 뜻은 아닙니다. 무언가에 대해 짚어야 한다고 느낀다면, 투명성을 위해 본인의 매니저에게 그 감정을 인지시키는 게 도움이 될 수 있습니다. 특히 그 사람이 당신에게 직접 보고하는 관계라면, 후일 시정 조치를 취해야 할 때 그런 기록은 중요한 근거가 됩니다.

반대로 누군가의 작업이 자랑스럽다면 — 세상이 다 알게 하세요! 자부심을 팀, 특히 그 위 매니지먼트와 함께 나누는 건 정말 좋은 경험입니다. 엔지니어링 리더십의 일은, 본디 팀에 있는 좋은 것들을 널리 퍼뜨리는 것이지 칭찬을 혼자 독식하는 것이 아닙니다.

결론

커뮤니케이션 능력을 기르는 일은, 한 가지 단일 스킬을 가리키며 “이거다!” 라고 할 수 있는 종류의 것이 아닙니다. 효과적인 팀 스킬이라는 단단한 토대를 만들기 위해, 서로 위에 쌓이는 일련의 디딤돌이라고 보는 편이 맞습니다.

시작은 자신의 메시지를 다듬는 것에서부터입니다. 명확하고, 직접적이며, 상대를 존중하는 커뮤니케이션을 통해, 동료 엔지니어들에게 당신이 그들과 그들의 시간을 소중히 여긴다는 사실을 전하세요.

다음 단계는, 팀의 환경을 설계하는 것입니다. 명확함과 기록을 장려하는 시스템을 만드는 단계죠.

마지막으로, 커뮤니케이션을 통해 팀을 이끄는 단계입니다. 신뢰를 쌓고, 근거를 함께 전하며, 공감으로 방향을 잡아주는 단계입니다.

이 세 가지를 모두 익힌 사람들은 단순히 기술적 문제를 푸는 데 그치지 않습니다. 그들은 조직을 이끄는 리더가 됩니다.

여러분이 가장 좋아하는 엔지니어링 커뮤니케이션 팁은 무엇인가요? Discord에서 알려주세요. 좋은 팀 커뮤니케이션에 대한 새로운 대화를 함께 시작해봅시다!