흔히 마주할 수 있는 상황을 생각해 봅시다. 다음 스프린트의 핵심 기능인 ‘결제 모듈의 트랜잭션 롤백 전략’을 결정하기 위한 회의가 열렸습니다. 돈이 오가는 문제인 만큼, 데이터 정합성을 어떻게 맞출지가 중요합니다. 그렇게 개발자 A가 화이트보드에 케이스를 그리며 열심히 설명하고 있었습니다.

한창 열심히 설명하고 있을 무렵, 구석에 있던 팀원 B가 손을 듭니다.

“그런데, 결제 실패했을 때 유저한테 보내는 알림톡 문구는 정해졌나요? 지난번에 마케팅팀이랑 알림톡 템플릿 비용 때문에 이슈 있었잖아요. 트랜잭션 실패하면 알림톡이 두 번 발송될 수도 있는데, 비용 처리는 어떻게 하죠?”

순간 회의실에 정적이 흐릅니다. 조금 전까지 논의하던 DB 데이터 정합성이라는 핵심 맥락은 끊어졌고, 사람들의 머릿속에는 갑자기 마케팅팀과의 비용 이슈와 알림톡 발송 정책만이 떠오르기 시작합니다. 주최자인 개발자 A는 당황합니다.

‘아니, 알림톡 비용도 중요하긴 하지만… 지금은 DB 설계를 결정해야 하는 시간인데…’

결국 참가자들은 DB 트랜잭션과 알림톡 비용 사이를 오가다 귀중한 30분을 허비합니다. 시계를 보니 회의 종료까지 남은 시간은 단 5분입니다. 마음이 급해진 주최자는 결국 쫓기듯 회의를 종료하기 위한 결정을 내립니다.

“음… 시간이 없네요. 트랜잭션 처리는 일단 가장 익숙한 A 방식으로 갈까요?”

치열하게 고민해야 했을 중요한 기술적 의사결정을 시간에 쫓겨 급하게 처리해 버린 것입니다. 회의실을 나서는 팀원들의 표정에는 개운치 않은 찜찜함만 남았습니다. 이런 일이 반복될 때 우리는 흔히 팀원 B를 탓합니다.

“쟤는 왜 저렇게 눈치가 없지? 왜 자꾸 딴소리로 회의를 망치지?”

하지만 여러 회의를 겪으며, 제가 찾은 원인은 다른 데 있었습니다. 회의 중 발생하는 딴소리는 그 팀원의 무능이나 무질서 때문만이 아니라 ‘회의 시스템의 결함’으로 발생한 문제입니다.

소프트웨어에 버그가 발생하면 코드를 수정하듯, 회의 중에 딴소리라는 버그가 생기면 ‘회의 시스템’을 수정해야 합니다. 그 수정 설계의 핵심에는 ‘무엇을(What), 왜(Why), 어떻게(How)’라는 3가지 필수 요소가 있죠. 하나라도 부족하다면 누군가 딴소리를 할 수 있는 여지가 생깁니다.

딴소리가 불러오는 ‘기술 부채’

회의에서 흘러나오는 딴소리는 단순히 “말이 좀 많네” 하고 넘길 문제가 아닙니다. 회의가 주제를 이탈하는 순간, 팀의 생산성에는 치명적인 세 가지 악영향이 발생합니다.

첫째, 잘못된 의사결정을 유발합니다

방금 예시를 다시 떠올려 볼까요? 트랜잭션 롤백 전략은 시스템 안정성과 직결되는 문제입니다. 하지만 딴소리로 인해 충분한 토론 없이 “시간 없으니 익숙한 A 방식으로 하자”는 결정이 내려졌습니다. 이렇게 급하게 내린 판단은 장애로 이어지거나, 결국 코드를 다시 뜯어고쳐야 할지도 모를 ‘기술 부채’로 되돌아옵니다.

둘째, ‘회의 혐오’를 만듭니다

“우리 팀 회의는 들어가 봤자 시간만 낭비해.”라는 인식이 퍼지기 시작합니다. 개발자들은 회의를 일을 방해하는 요소로 받아들이고, 회의실에 들어올 때부터 방어적인 태도를 보이거나 아예 입을 닫아버립니다. 그렇게 팀원들의 참여는 점점 줄고, 주최자만 말하는 죽은 회의가 되어버립니다.

셋째, 우선순위의 혼란을 줍니다

가장 위험한 부작용입니다. 만약 딴소리하는 팀원의 목소리가 크면 어떨까요? 그가 꺼낸 알림톡 비용이란 이슈가 정작 회사에 더 중요한 결제 데이터 정합성보다 시급한 문제처럼 보이며 혼란을 주기 시작합니다. 팀의 리소스가 엉뚱한 방향으로 새어 나가는 출발점이 바로 여기입니다.

성공적인 회의를 위한 3가지 설계 요소

그렇다면 어떻게 해야 할까요? 회의 진행자가 말을 잘해서 흐름을 통제하는 데에는 분명 한계가 있습니다. 그래서 필요한 것은 회의 설계도입니다. 좋은 회의는 시작부터 다음 3가지 요소가 완벽하게 제공된 상태여야 합니다.

만약 스스로 주최한 회의에서 딴소리가 끊이지 않는다면, 팀원을 탓하기 전에 먼저 생각해 봐야 합니다.

‘나는 회의의 3가지 핵심 요소를 시작 전에 완벽하게 전달했을까?’

무엇을(What): 이 회의의 최종 목표는 무엇인가? 정보 공유인가, 아이디어 발산인가, 아니면 의사결정인가?
왜(Why): 이 안건을 왜 지금 논의해야 하는가? 이 논의의 비즈니스 가치와 긴급성은 어떤가?
어떻게(How): 우리는 어떤 규칙으로 논의할 것인가? 시간 배분과 발언권, 이탈 방지책은 무엇인가?

What & How: 회의의 좌표와 경로 찍기

회의 주최자가 회의실에 들어와 가장 먼저 해야 할 일은 무엇일까요? 바로 좌표와 경로를 찍는 것입니다.

딴소리가 난무하는 회의의 90%는 참석자들이 ‘우리가 지금 어디로 가고 있는지(What)’를 모르거나, ‘어떤 도로를 타고 갈지(How)’ 합의하지 않았기 때문에 발생합니다. 내비게이션 없이 운전대를 잡으면 운전자는 결국 잘 아는 길, 즉 자기 관심사로만 핸들을 꺾습니다.

What “오늘 우리는 무엇을 결정합니까?”

회의 주최자들은 회의를 초대하며 ‘주간 개발 회의’, ‘아키텍처 논의’처럼 모호한 제목을 적곤 합니다. 하지만, 이는 시작부터 팀원들에게 “와서 아무 말이나 하세요”라고 판을 깔아주는 것과 다르지 않습니다.

목표(What)가 불분명하면 사람들은 본능적으로 자신이 가장 잘 아는 주제, 혹은 가장 걱정하는 문제를 꺼냅니다. 앞선 예시에서 팀원 B가 갑자기 알림톡 비용을 이야기한 것도, 그에게는 그것이 가장 시급한 문제였기 때문일 겁니다. 이는 회의의 목표가 DB 트랜잭션 설계 결정이라는 점이 명확히 인지되지 않아서 생긴 상황입니다.

물리적으로 목표를 시각화하기

말로만 전달한 목표는 공기 중으로 흩어지기 쉽습니다. 눈에 보이게 만드세요.

가장 좋은 것은 회의실에 들어가자마자 보드 맨 윗줄에 ‘한 가지 목표’를 적으며 회의를 시작하는 것입니다. 이 목표 역시 구체적이어야 합니다.

나쁜 예: 결제 시스템 회의
좋은 예: 신규 결제 모듈 트랜잭션 롤백 전략 결정(API vs Queue)

회의에 초대하거나 회의록을 작성할 때도 마찬가지입니다. 문서 최상단에 헤드라인으로 ‘의사결정 필요’ 섹션을 만들어 두세요.

이렇게 What이 시각화되어 있으면, 딴소리를 제어하기 훨씬 쉬워집니다. 누군가 엉뚱한 이야기를 시작할 때, 이제는 감정을 섞을 필요가 없습니다. 그저 화이트보드에 적힌 목표를 가리키며 이렇게 말하면 됩니다.

“B 님, 비용 문제도 중요하지만, 지금 말한 것이 저기 적힌 ‘트랜잭션 롤백 전략 결정’에 당장 필요한 내용일까요?”

한마디면 충분합니다. 팀원 모두 “아, 지금 주제가 아니구나”라고 깨닫고, 자연스럽게 원래 논의로 돌아올 겁니다.

How “우리는 어떤 규칙으로 논의합니까?”

목표(What)가 ‘도착지’라면, 규칙(How)은 ‘교통 신호’입니다. 신호등이 없는 교차로를 떠올려 보세요. 목소리 큰 차가 먼저 지나가고, 눈치 빠른 차가 마구 끼어들면, 결국 병목 현상에 도로는 꽉 막혀버릴 것입니다.

회의도 다르지 않습니다. 발언권을 독점하는 사람, 꼬리에 꼬리를 무는 논쟁, 주제를 벗어난 아이디어 발산까지. 이런 혼란의 대부분은 How를 정의하지 않아 발생합니다.

회의 안건별 데드라인 설정하기

개발자들에게 민감한 데드라인을 회의 안건에도 심어보세요.

“1번 안건인 ‘롤백 시나리오 리뷰’에는 딱 15분 쓰겠습니다. 15분 안에 결론이 안 나면, 추가 미팅을 잡거나 주최자가 결정하겠습니다.”

타이머를 화면에 띄워두는 것도 좋은 방법입니다. 시간이 줄어드는 모습이 눈에 보이면, 사람들은 딴소리할 여유를 잃고 자연스럽게 핵심에 집중하게 됩니다.

회의 안건이 아닌 중요한 것을 모으기

딴소리를 제어하는 가장 강력하면서도 세련된 방식입니다. 회의 중 누군가 주제와 직접 관련은 없지만, 중요한 이야기(또는 그 사람이 중요하다고 믿는 이야기)를 꺼냈을 때 무조건 자르지는 마세요. 무시당했다고 느낀 팀원이 입을 닫아버리거나 오히려 반발심을 가질 수 있습니다.

그럴 때는 화이트보드 한쪽에 나중에 논의라는 공간을 만들고 활용해도 좋습니다. 이런 말과 함께요.

인정: B 님, 알림톡 비용 이슈는 운영 관점에서 정말 중요한 문제네요.
저장: 하지만 오늘 안건(DB 설계)과는 거리가 있으니, 여기 ‘나중에 논의’ 영역에 적어두겠습니다.
약속: 회의가 끝나고 시간이 남으면 이야기하거나 따로 티켓을 만들어 논의하시죠.

팀원 B는 ‘내 의견이 존중받았다’는 느낌을 받으면서도 더는 같은 문제로 회의 흐름을 방해하지 않을 것입니다. 딴소리를 마냥 제거하는 것이 아니라, 적절한 위치로 이동시키는 것. 이 역시 회의를 원활하게 만들 How입니다.

Why: 가치를 알게 하기

앞서 우리는 ‘What(목표)’을 시각화하고, ‘How(규칙)’를 정비했습니다. 이 두 가지만 잘 갖춰도 무의식적으로 튀어나오는 딴소리는 대부분 사라질 것입니다.

하지만 회의를 가장 힘들게 만드는 존재는 따로 있습니다. 바로 똑똑한 팀원의 확신에 찬 딴소리입니다. 팀원 C는 회의의 목표(What)가 무엇인지 알고 있고, 발언 규칙(How)도 충분히 이해하고 있습니다. 그런데도 손을 들고 제동을 겁니다.

“트랜잭션 롤백 전략도 중요한데요. 저는 이번 기회에 레거시 코드를 먼저 리팩토링해야 한다고 봅니다. 지금 구조로는 어떤 전략을 써도 코드가 너무 지저분해져서 나중에 유지보수를 할 수가 없어요.”

회의 주제는 분명 롤백 전략 결정입니다. 그런데 갑자기 코드 품질과 리팩토링이라는 훨씬 큰 주제가 던져집니다. 틀린 말은 아닙니다. 맞는 말일 수도 있습니다. 하지만 지금 이 회의에서는 분명한 딴소리입니다.

그렇다면 왜 이런 일이 벌어질까요? 원인은 정보의 부재가 아닌 가치의 충돌에서 찾아야 합니다.

조직의 목표 vs 개인적 동기

모든 개발자는 마음속에 자신만의 개인적인 동기를 품고 있습니다.

‘나는 더 깔끔하고 우아한 코드를 짜고 싶어.’라는 기술적 완벽주의나, ‘새로 배운 기술(MSA, GraphQL 등)을 써보고 싶어.’라는 학습 욕구, ‘나중에 귀찮아지기 전에 지금 고치고 싶어.’ 같은 편의성도 있죠.

반면, 회의를 소집한 주최자는 분명한 조직의 목표를 바라봅니다.

‘코드가 좀 지저분해도 내일 당장 배포해야 해.’처럼 비즈니스 속도일 중요하게 볼 수도 있고, ‘새로운 기술 도전보다는 지금 잘 돌아가는 방식이 안전해.’라며 안전성을 따질 수도 있습니다.

딴소리는 바로 이 두 가지 Why가 정면으로 충돌할 때 발생합니다.

팀원 C는 자신의 개인적 Why(코드 품질)가 팀의 Why(출시 속도)보다 더 중요하다고 믿기에, 이를 관철하려 회의의 흐름을 끊었습니다. 만약 이때 권한이나 연차 같은 힘으로 “시키면 하세요”라고 찍어 누르면, 그 팀원은 입을 닫고 동기를 잃어버립니다. 그렇다고 모두 들어주면 배는 산으로 갈 것입니다. 어떻게 해야 할까요?

회의의 Why를 설득하기

그래서 회의 주최자는 회의 시작 전에, 팀원들에게 이 회의가 가지는 가치를 먼저 설득해야 합니다. 단순히 “모이세요”가 아니라 “왜 이 회의가 당신의 시간을 뺏을 만큼 가치 있는지”를 분명하게 증명해야 합니다.

회의 서두부터 비즈니스 맥락과 위협을 함께 공유하는 것이 가장 좋은 방법입니다.

나쁜 예: 자, 이번 스프린트 롤백 로직 개발 건 논의합시다.
좋은 예: 이번 결제 모듈이 다음 주 대규모 프로모션 때 배포됩니다. 만약 롤백 실패로 데이터가 꼬이면, CS 문의 폭주로 프로모션을 중단해야 할 수도 있습니다(Why). 그래서 오늘 회의에서는 완벽한 코드보다는 가장 확실하고 안전한 방법을 찾는 것이 먼저입니다.

이처럼 ‘안정성’이라는 이유를 명확히 하고 시작하면, 리팩토링이나 신기술 도입을 주장하려던 팀원도 스스로 브레이크를 밟게 됩니다. “아, 지금은 기술적 욕심을 부릴 때가 아니구나”라고 이해한 것이죠.

개인의 Why는 존중하되 냉정하게 다루기

그런데도 딴소리를 멈추지 않는 고집 센 팀원이 있다면, 어떻게 해야 할까요? 이때는 그들의 열정을 꺾지 않으면서도 회의를 구출하는 존중과 제어의 화법이 필요합니다. 핵심은 단순히 “틀렸다”라고 말하는 것이 아니라 “시점이 다르다”라고 말하는 데 있습니다.

1단계. 존중

“C 님의 리팩토링 의견은 정말 훌륭합니다. 장기적으로 우리 팀에 꼭 필요한 작업이고, 기술 부채를 진지하게 고민해 주신 점도 감사합니다.”

이처럼 먼저 팀원의 전문성과 동기를 인정하면, 그의 방어 기제를 내려놓는 데 도움을 줍니다.

2단계. 제어

“다만 앞서 말했듯이 오늘 회의의 목표는 ‘프로모션의 생존’입니다. 지금 리팩토링을 시작하면 우리가 목표로 한 프로모션 오픈 일정은 맞추기 어렵습니다. 다만, C 님의 소중한 의견이 묻히지 않도록 이 안건은 다음 안정화 스프린트 회의로 넘기는 게 어떨까요?”

그다음에는 팀의 Why를 근거로 우선순위를 다시 정렬합니다.

이 과정을 거치면 팀원은 자신의 의견이 무시당한 것이 아니라 ‘더 적절한 시기를 기다리고 있다’고 인식합니다. 회의의 목표를 지키면서도 가치의 우선순위를 정렬하는 방법입니다.

한계: 의지가 없다면 단호해지기

여기까지 왔다면 우리는 할 수 있는 모든 것을 다 했습니다.

What: 목표를 명확히 보여줬고,
How: 규칙을 세웠으며,
Why: 이유를 설득하고 가치의 우선순위까지 정렬했습니다.

이 정도 시스템이라면, 팀원의 95%는 딴소리를 멈추고 협력자로 바뀔 것입니다.

하지만 끝이 아닙니다. 만약 이 모든 것을 완벽하게 만들어도, 여전히 팔짱을 낀 채 딴소리를 하며 분위기를 흐리는 나머지 5%가 있다면 어떨까요? 시스템을 제공해도 거부하는 그들에게 우리는 어떤 카드를 꺼내야 할까요?

소통 vs 태도와 동기

여기서부터는 진단을 바꿔야 합니다. 이는 더 이상 회의 주최자가 해결할 수 있는 소통 문제의 영역이 아닙니다. 본질은 협업 태도의 문제입니다. 시스템으로 개선할 소통 문제에 비하면, 동료의 태도와 동기 문제는 주최자가 고칠 범위가 아닙니다. 시스템을 따를 의지가 없는 참여자에게 더 정교한 회의 기법을 쓰는 것은 솔직히 시간 낭비에 가깝습니다.

이때는 친절한 진행자의 가면을 벗고, 단호한 심판자의 역할을 해야 합니다. 억지로 설득하려 들기보다는 정해진 규칙에 따라 논의를 중단시키거나 문제 해결을 상위 리더에게 위임하세요. 만약 통제가 불가능한 상황이 온다면, 감정적으로 맞서지 말고 건조하게 선을 긋는 것이 낫습니다.

“의견은 충분히 들었습니다. 하지만 정해진 규칙과 시간 안에 결론을 내려야 하는 관점으로, 이 논의는 여기서 중단하겠습니다. 이견이 있다면 회의록에 ‘미해결 안건’으로 남기고, 팀장님(결정권자)과 별도로 이야기하시죠.”

이처럼 명확한 선을 긋는 것 역시 주최자의 중요한 역할입니다. 해결할 수 없는 문제까지 끌어안으려다 회의 전체를 망치지 마세요. 주최자의 책임은 모두를 만족시키는 것이 아니라, 회의에 참여한 다수의 시간을 보호하는 것입니다.

회고로 개선하기

마지막으로, 딴소리 없는 회의를 유지하려면 시스템을 꾸준히 개선해야 합니다.

이를테면, 아이디어 발산이 중요한 프로젝트 초반에는 딴소리를 어느 정도 허용해야 할 수도 있고, 마감이 임박한 시점에는 군대식 통제가 필요할 수도 있습니다. 그럴 때는 (애자일 조직이라면) 회의 자체를 하나의 안건으로 ‘회고’에 올려보세요. 이런 질문을 던지면 좋습니다.

이번 스프린트 회의의 What은 명확했나요?
우리가 정한 How가 너무 빡빡해 창의성을 해치진 않았나요?

팀원 스스로 “‘나중에 논의’ 제도가 좋았다”거나 “시간이 너무 부족했다”처럼 솔직히 피드백하도록 장을 열어주세요. 회의의 규칙이 리더가 시킨 것이 아닌 우리가 함께 합의한 문화로 인식되는 순간, 딴소리는 자연스러운 자정 작용으로 사라질 것입니다.

마치며

지금까지 ‘회의 시간에 딴소리하는 팀원’이라는 골치 아픈 현상을 함께 살펴봤습니다. 첫 질문으로 돌아가 봅시다. “회의 시간에 딴소리하는 팀원, 고칠 수 있을까요?”

제 대답은 “시스템이 그들을 돕는다면 가능하다”입니다.

우리는 너무 쉽게 동료를 비난합니다. “눈치가 없다”, “이기적이다”, “말귀를 못 알아듣는다”. 하지만 그 비난의 손가락을 거두고 내가 설계한 회의실의 풍경을 다시 한번 점검해 보세요. 화이트보드에 목표(What)는 적혀 있었는지, 팀원들에게 규칙(How)을 주었는지, 그리고 이 회의의 이유(Why)를 충분히 설명했는지 말입니다.

딴소리는 팀원의 입에서 나오지만, 그 원인은 회의 방식에도 숨어 있습니다. 어떻게 보면 딴소리는 ‘지금 이 회의의 시스템이 고장 났습니다’라는 경고음입니다. 그럴 때는 경고음을 낸 사람을 탓하기보다 시스템을 먼저 수리해 보세요. 말 잘 듣는 팀원을 찾기보다 누가 들어와도 몰입할 수밖에 없는 회의를 설계하는 것이 빠릅니다.

이렇게 What, Why, How가 제대로 채워진 회의실에서는 더 이상 낭비되는 시간이 없을 겁니다. 지금 당장, 다음 회의의 What을 적어보는 건 어떨까요?