Software Engineer를 위한 회의주의

회의는 소프트웨어 개발뿐 아니라 삶의 많은 부분에서 나 아닌 다른 사람들과 소통하기 위한 중요한 수단으로 사용된다.

긴 시간 개발자로서 살아왔지만, 최근 몇 년간은 회의가 업무의 대부분을 차지하고 개발은 점점 더 작은 비중으로 줄어들었다.
프로그래머로서 사는 것도 좋아하고, 잘 맞는 일이라고 생각하지만, 또 회의와 소통을 통해 내 능력보다 더 큰 결과물을 추구하고, 또 새로운 아이디어를 회의 속에서 함께 만들어내는 것은 대단한 기쁨이다.

스스로 썩 좋은 회의 진행자라고 생각하진 않지만, 몇 가지 중요하게 생각했던 원칙에 대해서 정리를 해본다.

업무적으로 주로 기술 회의를 많이 하긴 했지만 반드시 기술 회의에만 적용되는 것은 아닐 것이다. 사람들이 모여서 하는 회의가 대부분 비슷한 목적을 가지고 있다.

회의 성격별로 조금씩 회의를 이끌어갈 때 주의할 점들이 다르지만, 그 전에 회의의 중요성에 대해 인식을 같이하는 것부터 출발해야 할 것이다.

엔지니어들은 회의에 참석할 때 상당한 부담감을 가진다. 사실은 귀찮아한다. "또 회의야?"
회의의 목적이 매우 중요함에도 회의 자체가 엔지니어들의 업무 몰입을 방해하고, 시간을 뺏기 때문에 회의를 불필요하게 자주하게 되면 역효과가 크다. 또, 회의 시간 역시 너무 길지 않도록 해서 사람의 집중력이 유지될 수 있는 한계를 넘지 않도록 하는 것도 중요하다.

a. 회의 시간은 경험적으로 1시간 30분 정도가 적당한 것 같다. 그보다 짧으면 제대로 된 토론을 하기가 어렵고, 길어지면 집중력이 무너진다. 정기적인 회의에서 많은 내용을 담고, 비정기적인 회의는 가능하면 피하는 게 좋다.
b. 회의 진행 시에는 회의가 주제를 이탈하지 않도록 잘 이끌어야 한다. 우스갯소리가 주의를 환기하는 수준에서 아주 짧게 오고가는 것이 아니라면 회의가 느슨해지기 때문에 매우 주의해야 한다. 회의가 느슨해지면 바로 회의를 종료하고 다음 회의를 잡는 것이 좋다.
c. 회의 참여자의 아이디어를 제어해서는 안된다. 사람의 생각이란 연상 효과에 의해 나오는 경우가 대부분이므로 회의의 짧은 시간에 순발력 있게 나오는 의견들은 체계성이 떨어지거나, 직접적인 연결고리가 안 보이는 경우가 많다. 하지만, 좀더 논의하다 보면 연결고리가 찾아지거나 새로운 아이디어나 관점으로 연결되는 경우가 많으므로 이러한 논의를 잘 이끌어내어야 한다. 앞에서 얘기한 주제 이탈과 상반되어 보일 수도 있지만, 어느 정도 논의 후에 다음 안건으로 넘기든지 기록해두든지 하는 게 좋겠다.
d. 의견들을 제어해야 하는 경우에는 빨리 제어를 해야 한다. 주제와 무관한 얘기로 분위기를 무너뜨리는 경우, 또 토론이 너무 길어져서 다음 주제로 넘어가지 못하는 경우, 그리고 기술 주제인 경우 참여자들 중 일부가 준비가 안되어서 이해를 못하는 경우가 이에 해당한다.
회의 성원들이 모두 이해를 하는 것이 가장 좋지만, 그렇지 못한 경우가 존재한다. 이해를 못하는 성원이 계속 이견을 내는 경우, 다수의 성원들은 충분히 이해가 되었다고 판단되면 끊어주고 다음 주제로 넘어가는 것이 필요하다.
e. 토론은 적정한 논리적 추상 수준을 유지해야 한다. 발표자는 적절한 비유를 통해 보다 쉽게 핵심 내용을 공유하려는 노력을 해야 하고, 또 적절하지 않은 은어를 사용하지 말아야 한다. 정확한 용어는 소통을 쉽게 할뿐 아니라 소통의 대상을 넓히는 효과를 주는데, 내부에서만 통용되는 새로운 용어를 만들고 그 용어의 의미 자체가 스스로 의미를 전달해주는 적절한 보통명사가 아니라면, 소통의 범위만 좁히는 게 아니라 잘못된 소통을 하게 만든다.
f. 회의 참여자들이 적극성을 가지고 회의에 참여하도록 분위기를 만드는 것이 매우 중요하다. 회의의 중요성에 대해 끊임없이 설득하고, 보다 나은 회의를 만들도록 지도를 해야 한다.


많은 사람들 앞에서 하는 세미나와 같은 일방성이 강한 회의를 제외하면, 소통을 위한 회의는 크게 네 가지 성격의 회의가 중요했던 것 같다.

하나는 광범위한 주제를 가진 brainstorm 회의. 새로운 아이디어를 내기 위한 목적의 회의이다.
다음은 소그룹 기술 발표 및 토론. 개인이 준비한 기술적인 내용를 공유하고, 비평하는 회의.
또다른 하나는 문제 해결 회의. 기술 토론의 연장선에 있지만, 발견된 문제점들을 해결하기 위해 아이디어를 모으는 회의이다.
마지막으로 업무를 공유하는 회의. 각 개인의 업무를 그룹에서 공유하면서 업무 이해와 개입을 하는 회의이다.


a. brainstorm 회의는 생산적이기 정말 어려운 회의인 것 같다. informal하게 tea time 처럼 개인별로 웅성거리면서 회의 아닌 회의를 한 후 결과를 수집하는 게 그나마 조금 나은 생산성을 보였던 것 같다.
b. 기술 회의는 발표자의 발표 능력이 첫번째 관건이다. 논리성과 의사 전달을 위한 비유 능력 등이 많이 요구된다. 다른 참여 성원들의 적극적인 critic은 발표 내내 보장되어야 한다.
c. 문제 해결 회의는 문제들을 잘 분석하는 데서 출발한다. 서로 독립적인 부분 문제들로 최소로 분해한 후 하나씩 차례로 해결해나가는 것이 가장 중요하다. 세부 문제 해결 과정은 동일하게 아이디어의 공유와 critic을 통해 이루어진다.
d. 업무 공유는 조직의 관심과 관리 측면에서 이루어지는 회의이다. 관리자는 각 성원의 업무 진척과 목표가 맞게 되었는지 또 해결 과정에 문제는 없는지 대화를 통해 catch해야 한다.

회의는 소통 수단 중 매우 효율적이고 중요한 수단이다. 여러 성원들의 서로 다른 뷰를 통해 논리가 탄탄해지고, 새로운 골조와 살을 붙일 수 있으며, 사물을 다른 사람의 관점을 통해 재인식할 수 있기 때문에 아이디어와 혁신의 산실이기도 하다.

혁신하는 조직은 생산적인 회의 문화를 가진 조직이다. 회의에서 혼자의 아이디어보다 두 사람의 아이디어가 더 낫다는 것을 확인하는 순간부터 조직은 창의적인 조직으로 변모한다. 대화와 발표의 기술은 반복과 코칭을 통해 의식적으로 개선해갈 수 있다.

댓글

이 블로그의 인기 게시물

[Java] Java G1 GC의 특성에 따른 Full GC 회피 튜닝 방법

일론 머스크의 First Principle Thinking (제1원리 기반 사고)

엄밀한 사고(Critical Thinking)란 무엇일까