효율적인 회의를 위한 속성 정의

일주일에 한 번 모이는 팀에서 일하다 보면 회의 한 번이 유독 무겁게 느껴진다. 그런데 최근 몇 주를 돌아보니 업무 시간의 대부분이 회의로 채워지고, 정작 개발은 제대로 시작도 못 한 채 하루가 마무리되는 날이 많았다. 결국 회의 방식 자체를 돌아볼 필요가 있다는 생각이 들었다.

문제의 핵심은 회의의 속성이 불명확하다는 점이다. 속성에 따라 집중해야 할 것도, 경계해야 할 것도 달라지는데, 주최자도 참가자도 이 회의가 어떤 회의인지 공유하지 않은 채 시작하면 서로 전혀 다른 포인트로 이야기하게 된다.

물론 속성이 혼재하는 회의가 항상 나쁜 건 아니다. 오히려 더 풍성한 논의로 좋은 결과를 얻을 때도 있다. 다만 그런 회의를 성공적으로 이끌려면 주최자의 상당한 퍼실리테이션 역량이 필요하다. 매번 그것에 의존하는 건 지속 가능하지 않다.

회의를 크게 세 가지 속성으로 나눠보면, 각각 지향점과 주의할 점이 명확해진다.

1. 정보 공유 회의

Weekly 싱크업, 업무 진행 상황 공유처럼 해결할 아젠다가 없어도 정기적으로 진행하는 회의다.

지향할 것

• 정보 공유자의 완성도 높은 사전 자료 준비
• 참여자의 자유로운 질문 — 이해를 위한 질문이 활발할수록 좋다

지양할 것

• 정보 공유·이해 목적을 벗어난 논의
  • 여기서 의견 충돌이 시작되면 회의가 예상치 못하게 길어진다

2. 브레인스토밍 회의

유저 리텐션을 높이기 위한 기능 아이디에이션, 이벤트 기획처럼 다양한 아이디어를 발산하는 회의다.

지향할 것

• 눈치 보지 않는 자유로운 의견 개진
• 아젠다에 대한 개인 사전 고민
• 명확한 종료 시간 설정 — 발산에는 반드시 마감이 필요하다

지양할 것

• 대안 없는 부정적 피드백 — 아이디어를 죽이는 가장 빠른 방법이다
• 종료 시간 없이 의견을 무한 발산하는 것

3. 의사 결정 회의

신규 기능 개발 타당성 논의, 아키텍처 결정, UX 플로우 확정처럼 명확한 결론을 도출해야 하는 회의다. 세 유형 중 사전 준비가 가장 중요하다.

지향할 것

• 주최자의 명확한 아젠다를 문서 형태로 사전 공유
• 공유된 문서를 기반으로 참여자들이 논의 지점을 미리 숙지·검토
• 회의 후 결론과 Action Item을 명확히 정리해 공유

지양할 것

• 추상적인 아젠다 공유
  • “이거 어떻게 할까요?”는 아젠다가 아니다
• 사전 공유 범위를 벗어난 논의, 또는 유관자끼리 따로 해결 가능한 지엽적인 디테일을 전체 회의에서 다루는 것
  • 예: 전체 회의 중 테크리드와 백엔드 개발자가 특정 자료구조 필드 설계를 논의하거나, 디자이너와 프론트엔드 개발자가 hover 처리 방식을 결정하는 경우
• 모호한 결론과 흐릿한 A/I

한 줄 요약 회의 초대장에 유형 한 줄을 추가하는 작은 습관이 꽤 큰 차이를 만든다.