오전 10시 스탠드업, 11시 스프린트 플래닝, 2시 디자인 리뷰, 4시 기술 공유. 코드를 칠 시간이 없었다. 캘린더를 열어보면 파란 블록이 테트리스처럼 빼곡하게 쌓여 있는데, 그 사이사이 30분짜리 빈 시간에 뭘 할 수 있는지 모르겠다. 컨텍스트를 로드하는 데만 15분이 걸리는데, 15분 코딩하고 다시 회의실로 들어가야 한다.

이런 날이 일주일에 두세 번은 있었다. 그때마다 "회의 좀 줄여야 하는 거 아닌가"라는 말이 팀 슬랙에 올라왔고, 다들 공감의 리액션을 남겼다. 하지만 돌아보면 회의 수가 줄어든 적은 없다. 오히려 "회의를 줄이기 위한 회의"가 추가됐던 적도 있다.

문제는 양이 아니라 질이다#

한동안 나도 "회의가 너무 많다"가 핵심 문제라고 생각했다. 그런데 가만히 따져보니까 불만의 진짜 대상은 따로 있었다. 회의가 세 개인 날이어도 셋 다 깔끔하게 끝나면 별로 지치지 않았다. 반대로, 단 하나의 회의가 목적 없이 1시간을 잡아먹으면 오후 전체가 날아갔다. 결국 "회의가 많다"가 문제가 아니라 "나쁜 회의가 많다"가 문제였다.

이걸 구분하는 순간 불만의 방향이 달라진다. "회의를 없애자"에서 "회의를 고치자"로.

나쁜 회의의 패턴#

나쁜 회의에는 놀라울 정도로 일관된 패턴이 있다. 한두 번 겪은 게 아니라 여러 팀, 여러 회사를 거치면서 반복적으로 목격한 것들이다.

안건 없이 시작한다. 회의 초대장에 제목만 달랑 있다. "프론트엔드 싱크" 같은. 뭘 논의할 건지 아무도 모른 채 회의실에 앉는다. 시작하고 나서야 "그래서 오늘 뭐 얘기하죠?"라는 말이 나온다. 처음 10분은 안건을 정하는 데 쓴다. 그 10분 동안 나머지 사람들은 슬랙을 본다.

결론 없이 끝난다. 한 시간 동안 열띤 토론을 했는데, 마지막에 "그러면 좀 더 생각해보고 다음에 다시 얘기하죠"로 마무리된다. 다음 회의에서 같은 주제가 다시 나온다. 같은 논의가 반복된다. 누가 뭘 해야 하는지 정해진 게 없으니까.

참석할 필요 없는 사람이 불려간다. 10명이 앉아 있는데 실제로 발언하는 사람은 3명이다. 나머지 7명은 왜 거기 있는 걸까. "혹시 의견 있을 수 있으니까"라는 이유로 초대됐다. 그 "혹시"가 현실이 되는 경우는 열 번에 한 번도 안 된다. 나머지 아홉 번은 시간을 낭비한 거다.

30분이면 될 걸 1시간 잡는다. 캘린더의 기본 설정이 60분이라서 그런 건지, 회의를 잡을 때 무의식적으로 1시간을 블록한다. 파킨슨의 법칙이 여기서도 작동한다. 1시간을 주면 1시간을 다 쓴다. 실제로 필요한 시간은 절반도 안 되는 경우가 대부분인데.

이 네 가지 중 하나만 해당돼도 짜증나는데, 현실에서는 보통 두세 개가 동시에 터진다.

좋은 회의를 경험한 적이 있다#

전 직장에서 함께 일한 PM이 있었다. 그 사람은 회의를 잡을 때 반드시 노션 문서를 먼저 공유했다. 배경 컨텍스트, 논의할 포인트, 각 옵션의 장단점이 정리되어 있었다. 회의 초대장에는 한 줄이 적혀 있었다.

"이거 읽고 오세요. 회의에서는 결정만 합니다."

처음에는 솔직히 귀찮았다. 회의 전에 문서를 읽어야 하니까. 그런데 막상 회의에 들어가면 완전히 달랐다. 배경 설명이 필요 없으니 바로 핵심에 들어갔다. "A안과 B안 중에 뭘로 갈까요?"부터 시작했다. 각자 문서를 읽으면서 이미 생각을 해왔기 때문에 의견이 빠르게 오갔다. 15분 만에 결정이 나고, 액션 아이템이 정리되고, 끝.

그때 깨달은 게 있다. 회의 시간 자체가 아니라, 회의 전후의 준비와 정리가 회의의 질을 결정한다는 것. 그 PM이 문서를 작성하는 데 30분을 썼을 수도 있다. 하지만 그 30분 덕분에 6명이 참석하는 회의가 45분에서 15분으로 줄었다. 단순 계산으로도 총 시간이 절약된 거다.

좋은 회의는 세 가지가 명확하다. 왜 모이는지, 뭘 결정해야 하는지, 누가 뭘 해야 하는지. 이게 빠진 회의는 그냥 여러 명이 동시에 생각하는 시간일 뿐이다. 각자 자리에서 해도 되는 걸 굳이 같은 방에 모여서 하는 거다.

개발자로서 내가 바꾼 것#

남 탓만 하고 있을 수는 없었다. 내가 참여하는 회의라면 나도 바꿀 수 있는 부분이 있었다.

가장 먼저 손댄 건 스탠드업이었다. 우리 팀 스탠드업은 전형적인 패턴이었다. 돌아가면서 "어제 뭐 했고, 오늘 뭐 할 예정이다"를 말한다. 5명이 각자 3분씩 하면 15분. 근데 솔직히, 다른 사람이 어제 뭘 했는지는 Jira 보면 안다. 스탠드업에서 정말 가치 있는 정보는 "뭐가 막혀 있는지"다.

그래서 제안했다. "어제 뭐 했는지" 대신 "오늘 뭐가 블로커인지"만 말하자고. 블로커가 없으면 "없습니다" 한마디로 끝내자고. 팀 리드가 동의했고, 다음 날부터 스탠드업이 5분 안에 끝나기 시작했다. 블로커가 있는 사람만 이야기하고, 상세 논의가 필요하면 스탠드업 끝나고 해당되는 사람끼리 따로 했다.

두 번째로 바꾼 건 비동기 커뮤니케이션이다. 간단한 기술적 질문이나 의사결정을 위해 회의를 잡는 대신, 슬랙 스레드를 적극적으로 활용했다. 핵심은 질문을 잘 구조화하는 거다. "이거 어떻게 하면 좋을까요?"보다 "A, B 두 가지 방법이 있는데 저는 A가 나은 것 같습니다. 이유는 이러이러합니다. 다른 의견 있으면 스레드에 남겨주세요"가 훨씬 빠르게 결론이 난다.

PR description도 비동기 소통의 좋은 채널이다. 예전에는 PR을 올리고 리뷰어를 붙이면서 슬랙으로 "이거 한번 봐주세요"만 보냈다. 지금은 PR description에 변경 이유, 접근 방식, 확인해줬으면 하는 포인트를 적는다. 리뷰어가 코드를 열기 전에 컨텍스트를 파악할 수 있으니 리뷰 시간도 줄고, "이거 왜 이렇게 한 거예요?"라는 질문도 줄었다.

이런 것들이 거창한 변화는 아니다. 하지만 한 가지 확실한 건, 내가 비동기로 소통하기 시작하니까 주변 사람들도 따라하기 시작했다는 거다. 동료가 나한테 질문할 때 슬랙 스레드에 구조화된 형태로 올리기 시작했다. 문화는 제안이 아니라 실천으로 바뀐다.

프레이밍을 바꾸면 해법이 달라진다#

"회의 줄이자"라고 하면 방어적인 반응이 나온다. 회의를 잡은 사람 입장에서는 나름 이유가 있어서 잡은 건데, 그걸 없애자고 하면 자기 판단이 틀렸다는 뜻으로 들리니까. 그래서 이 프레이밍은 잘 작동하지 않는다.

대신 "소통을 효율적으로 하자"라고 하면 이야기가 달라진다. 회의 자체를 부정하는 게 아니라, 같은 목적을 더 적은 비용으로 달성하자는 거다. 이 30분짜리 싱크, 슬랙 스레드로 대체할 수 있지 않을까? 이 문서 리뷰, 코멘트로 비동기로 하면 안 될까? 꼭 모여야 한다면, 사전 문서를 공유해서 시간을 절반으로 줄일 수 있지 않을까?

이렇게 물으면 대부분 "아 그것도 그렇네"가 된다. 반대하는 사람이 거의 없다. 회의 자체에 애착이 있는 사람은 없으니까. 다들 그냥 "원래 이렇게 해왔으니까" 관성으로 잡는 거다.

한번은 팀 리드한테 이렇게 말한 적이 있다. "이번 주 회의 중에 슬랙 스레드로 대체할 수 있는 거 있으면 한번 바꿔보면 어떨까요?" 공격적이지 않게, 실험의 톤으로. 팀 리드가 캘린더를 훑어보더니 주간 싱크 하나를 슬랙 비동기로 전환했다. 일주일 해보니까 아무 문제가 없었다. 그 회의는 그대로 사라졌다.

그래도 회의가 필요한 순간은 있다#

여기까지 읽으면 "이 사람 회의 극혐인가" 싶을 수 있는데, 꼭 그런 건 아니다.

슬랙에서 기술적인 논의를 하다가 메시지가 다섯 번째 왔다 갔다 하는데 서로의 말을 오해하고 있다는 걸 느낀 적이 있다. 텍스트는 뉘앙스를 전달하기 어렵다. 특히 기술적 트레이드오프를 논의할 때, 각자 머릿속에 그리고 있는 아키텍처가 다르면 텍스트로는 수렴이 안 된다.

그래서 "잠깐 화상통화 할까요?" 하고 5분 통화를 했다. 화면 공유하면서 "내가 생각하는 건 이거다" 하고 그림을 그려줬다. 5분 만에 정리됐다. 슬랙으로 하루 종일 했을 논의가.

이게 핵심이다. 회의라는 도구 자체가 나쁜 게 아니다. 도구를 언제 쓸지 판단하는 게 중요한 거다. 망치가 나쁜 게 아니라, 나사를 박는데 망치를 쓰는 게 나쁜 거다.

비동기로 충분한 건 비동기로. 실시간 대화가 필요한 건 짧은 콜로. 여러 이해관계자의 합의가 필요한 건 사전 문서와 함께 짧은 회의로. 상황에 맞는 소통 채널을 고르는 능력이 결국 팀의 속도를 결정한다.

결국 소통의 감각이다#

개발자는 코드만 잘 짜면 된다는 말을 가끔 듣는다. 그런데 현실에서 코드를 짜는 시간보다 소통에 쓰는 시간이 더 많은 날이 분명히 있다. 그리고 그 소통의 질이 결과물의 질에 직접적으로 영향을 준다. 요구사항을 잘못 이해하면 코드를 아무리 잘 짜도 다시 짜야 하니까.

회의를 싫어하는 게 아니라, 비효율을 싫어하는 거다. 같은 30분을 쓰더라도 뭔가 결정되고 앞으로 나아가는 회의라면 오히려 에너지가 생긴다. 반대로 결론 없이 흩어지는 1시간은 하루를 통째로 무겁게 만든다.

그래서 나는 회의를 줄이자고 주장하지 않는다. 대신 회의에 들어가기 전에 "이 회의가 끝났을 때 뭐가 결정되어 있어야 하지?"를 한 번 생각한다. 그 질문 하나가 회의의 밀도를 완전히 바꿔놓는다.