[SI이야기] 회의록이 당신의 생명줄이 될 수 있다

이런 포스팅을 쓰게 될 줄은 상상도 못 했다. 회의록을 잘 쓰는 법만 정리하면 될 거라고 생각했는데, 회의록을 왜 써야 하는지에 대해 설명을 할 필요가 있다는 생각을 못했다. (회의록 잘 쓰는 방법은 아래 포스팅을 참고하자)

 

2020.03.30 - [슈르의 오피스라이프/오피스라이프 팁] - 회의록 제대로 작성하는 방법

회의록 제대로 작성하는 방법

 

그런데 왜 이 포스팅을 하게 되었냐... 하면... 얼마 전에 회사 동료로부터 '문제가 많은 프로젝트가 있어서 지원을 갔는데 회의록이 없었다'라는 이야기를 들었기 때문이다. 

 

회의록을 잘 쓰는 사람이라면, 회의록을 써야 한다는 사실을 아는 사람이라면, 최소한 회의록을 쓰라고 시키는 사람이 옆에 있는 사람이라면 겪을 필요가 없는 일이었을 것이다. 회의록을 계속 써왔을 테니 말이다. 어떤 회의까지 회의록으로 남기느냐만 차이가 있었을 텐데 그건 프로젝트 특성마다 다르니 회의록의 중요성을 아는 사람이라면 알아서 재량껏 하리라 믿는다.

 

중요한 것은 이거다. '회의록은 단순 문서 작업이 아니다'라는 사실을 아는 것. 팀 저연차 아이들이나 개발자들에게 회의록을 쓰라고 하면 '다 아는데 왜 써야 해...'라고 생각하거나 '다 합의했는데 뭣하러.. 명확한걸 문서로 남겨야 해'라고 생각할 수 있다. 하지만, 그 한 번의 미룸, 두 번의 귀찮음이 나중에 나를 죽기 직전의 상황에 처하게 한다는 걸 안다면 절대 무시하지 못할 것이다. 오늘은 그 이야기를 하려고 한다.

---

회의록 = 생명줄을 이해시키기 위해 우선 '프로젝트에 문제가 있는데 왜 회의록이 필요한가'부터 설명을 하겠다.

 

 

1. 회의록은 진행경과를 증명한다.

 

'프로젝트가 어쩌다 이지경이 되었지?'라는 게 궁금하다면 제일 먼저 하는 일은 회의록을 열어서 보는 것이다. 담당자를 붙잡고 물어볼 수 있지만 그것보다는 사실에 기반된, 모두가 합의한 회의록을 읽는 것이 선행되어야 한다. 누구를 붙잡고 물어도 다 자기 억울한 이야기를 할 거고, 가장 최근에 있던 일부터 이야기를 할 것이기 때문이다. 그리고 때로는 누가 발언했느냐, 누가 있는 곳에서 어떤 목적으로 발언된 거냐에 따라서 해석이 달라지기 때문에 처음은 객관적인 사실이 필요하다.

 

하지만 여기서 회의록이 없다면 '합의된 내용인지 알 수 없는', '어디까지 공유된 건지 알 수 없는', '누구의 발언이었는지 증명되지 않는' 이야기들을 듣게 되는 것이다. 그렇게 되면 문제를 진단하고 해결하는 사람이 "A과장이 그러는데 어떠어떠하고 이래저래 했다면서요?"라고 물었을 때 고객으로부터 '아니요? 전 모르는데요?'라는 대답이 돌아오는 황당한 상황이 발생할 수 있는 것이다. 사실이어도 상대방이 오리발을 내민다면 우리는 그 오리발을 보면서 억울해할 뿐, 증명할 방법이 없는 것이다. 그보다 더 최악인 경우는 "맞아요 그랬는데요. A과장이 오해했나 보네요. 그런 의도는 아니었어요."라고 해버리는 경우인데 이러면 '고객의 의도를 확인하지 않은 잘못'이 A과장에게 가는 불상사가 일어난다.

 

 

2. 어떤 회의록은 계약서의 효력을 발휘한다.

 

가장 대표적인 회의록이 '협상 회의록'이다. 계약서나 요구사항에 어떤 내용을 담을지에 대해 이야기한 기록인데, 여기에는 계약서나 요구사항에 담겨있지 않는 내용들이 들어가기도 한다. 전제조건이라든지, 검토했다가 제외되었던 요구사항이라든지 등등... 그래서 나중에 누군가가 요구사항을 변경하고 싶거나 내용을 엎으려고 할 때 그 회의록을 들이밀면(그게 유리한 상황이라면) 번복되는 상황을 방지할 수 있게 된다. 아니면 전제조건이 지켜지지 않았을 때 (예 : B회사 -남의 회사-의 개발이 5월까지 완료되어야 한다) 그 뒤에 개발하기로 했던 업무범위를 없앨 수 있다. 고객사와 합의된 사항이기 때문에 안 해도 되는 일이 생긴다는 것이다. 하지만 그런 걸 그냥 듣고 넘어가거나 회의록이 없다면 꼼짝없이 지연을 감수하고 개발해야 할 수도 있다.

 

그리고 계약이 어떻게 되었다 하더라도, 프로젝트 진행하면서 그 요구사항을 변경하는 회의가 진행되었고 모두가 합의했고 그게 우리 회사에 유리하다면 반드시 회의록으로 남겨야 한다. 왜냐면 계약서대로 프로젝트가 진행되었는지 확인하는 부서와 그 요구사항이 변경되는 것에 합의한 담당자가 다른 경우가 대부분인데 그 사람들은 그게 정당한 절차와 합의를 통해 변경된 건지 근거를 찾을 텐데 회의록이 없다면 증명할 방법이 없을 것이기 때문이다. (실제로 이런 게 빠져서 고객과 같이 마지막에 회의를 한 번 형식적으로 해서 회의록을 만들기도 한다. 이것도 좋은 고객이 있는 경우에 가능하다.)

 

 

3. 갈대 같은 고객의 성향은 회의록의 개수와 내용에 고스란히 담긴다.

 

고객이 화수분 같이 혼자서 요구사항을 계속 내는 사람이라면 그걸 몰아서 주지 않고 생각날 때마다 던질 확률이 높은데, 그걸 언급이 될 때마다 회의록으로 남긴다면 그 당시에는 고객은 '오 나의 의견을 잘 반영해주고 있군'하면서 흐뭇해할 것이다. 그리고 그게 나중에 업무량의 폭탄으로 이어져서 프로젝트가 끝이 없는 상황이 발생하면 그 수많은 회의록을 통해 '아, 이 고객이 화수분이라 엄청 고생했구나. 시도 때도 없이 요건을 새로 던졌네'하면서 알 수 있을 것이다. 그리고 상태가 안 좋은 프로젝트라면 어차피 이 고객과는 사이가 나쁠 것이기에 그때는 회의록을 왕창 들고 가서 '니가 이렇게 마구잡이로 생각나는 대로 요구사항을 던져서 일이 너무 많잖니. 추가 계약을 하든지 일을 줄여줘'라고 싸울 수가 있게 된다.

 

회의록이 없다면? 그냥... 언제 나왔는지, 누가 냈는지 알지도 못하는 요구사항을 들고 프로젝트를 하는 수밖에 없다. 그냥 고객한테 빈손으로 가서 "니가 요구사항을 너무 많이 줘서 우리 일이 너무 많아"라고 말할 것이고, 고객은 "그래? 우리가 그렇게 많이 줬어? 그땐 아무 말 안 했잖아. 우리가 요구사항 정의 기간에 이야기하지 않았나? (회의록이 없어서 모르겠네? ^^)"라고 할 거다. 그런 지경에 이르면, 근거가 없기 때문에 프로젝트를 수습하기 어려워진다. 수락한 PM이 온전히 감당해야 하는 사태가 벌어진다.

---

그래서 프로젝트에서 살아남고 싶다면, 회의록을 작성하자. 회의록을 어떻게 남겨야 하고, 어떤 회의록을 남겨야 살 수 있는지 궁금하다면 '어떻게 남겨야'는 지난 회의록 작성 포스팅을 참고하고(위 링크), 어떤 회의록을 남겨야 하는지는 지금 추가로 설명해주겠다.

 

 

1. 정기 회의(위클리/먼슬리)

 

정기 회의록은 회의 내용이 특별히 없어도 작성한다. 위클리/먼슬리를 하는 건 보통 계약의 의무이기도 하고, 보통 보고하는 문서가 같이 있기 때문에 그 파일로 보고했다는 기록을 남기고 누가 보고를 받았는지를 기록하는 것만으로도 의미가 있다. 그리고 다른 회의보다 이런 정기 회의에서 하나의 발언이 더 큰 영향력을 줄 수가 있다. 그런 자리니까. 그러니 정기 미팅은 빠짐없이 쓰도록 하자. 빠뜨리면 산출물 검수 못 받을 수도 있다.

 

 

2. 분석/설계 회의

 

요구사항 정의 기간에 일어난 회의를 다 작성하는 것이 맞다. 어떤 검토를 했고 어떤 논의를 했는지가 중요하다. 무엇을 왜 뺐는지도 필요하면 넣고, 왜 이런 의사결정을 하게 됐는지도 적는 게 좋다. SI에서는 모든 요구사항이 제안서 또는 회의록 같이 근기가 있어야 한다. 근기가 없이 발생하는 요구사항은 없다. '이 요구사항은 근거가 뭐죠?'라는 질문을 감사 또는 제3자에게 받기 싫다면 회의록을 남기자.

 

 

3. 직책자가 들어오는 회의

 

고객도 가끔 그냥 대리? 사원? 레벨과 (무시하는 건 아닙니다) 간단하게 이야기하는 회의들이 있을 때가 있다. 이런 경우 보통은 의사결정이 이루어지지 않고 지난 회의 보충 설명이라거나, Q&A 자리가 될 때가 많다. 스터디해서 자기 상사에게 설명해야 하거나 자기네 내부 보고자료를 만들어야 하니까 요청되는 회의랄까. 이런 건 회의록을 작성할 필요가 없다. 하지만 고객 직책자가 들어오는 회의는 회의록을 작성해야 한다. 그들은 말 한마디가 의사결정일 확률이 높고, 그들의 고민은 수행사에게 숙제가 될 확률이 높기 때문이다.

 

참고로 간단하게 차를 마시는 자리라면 생략될 수 있다. 그들도 회의록에 남기지 않고 하고 싶은 말이 있을 때가 있다는 사실을 이해해주자. 하지만 차를 마시면서 한 이야기가 프로젝트에 영향을 주는 거라면 회의록은 남겨야 한다.

 

 

4. 요구사항/범위가 변경되는 회의

 

이건 누가 말했든, 언제 말했든 상관없다. 지나가다 이야기했든, 전화를 이야기했든, 메신저/쪽지/메일로 보냈든 무조건 다 남겨야 한다. 그냥 구두로 듣고 요구사항을 변경해서 진행하면 감사/검수 단계에서 걸린다. 만약 메신저/쪽지/메일로 온 거라면 회의록의 형식으로 다시 작업할 필요는 없다. 따로 저장해서 모아두면 충분하다. 하지만 구두/유선(전화)으로 이야기된 거라면 회의록을 남겨야 한다. 그리고 그 회의록을 상대방에게 보내주면서 '우리가 조금 전에 이야기한 게 이런 내용 맞죠?' 하면서 확인을 받아야 한다. 전화 통화해서 녹음한 것도 근기로서 효력은 있는데, 제3자를 위해서 문서화하는 걸 추천한다. ^^

---

나에게 묻는다면, 나도 회의록을 매우 싫어한다. 하지만, 회의록을 안 써서 등골이 서늘해진 경험 + 회의록이 나를 살려준 경험을 한 이후로는 회의록을 빠뜨리지 않고 쓰는 편이다. (사내에선 잘 안 써요..)

 

혹시나 회의록이 문서작업이라고 생각하는 사람이 있다면, 그런 오해는 하지 말고 회의록을 쓰는 습관을 기르도록 하자. 회의록 없이 일하는 것은 계약서 없이 일하는 것과 같다. '근거 있어?'라고 했을 때 회의록이 있다면 무혐의로 벗어날 것을 회의록이 없으면 근거 없이 잡혀 들어갈 수가 있다. (어디로? 개미지옥으로!) 그리고 일 많은 당신을 측은해하는 사람보다 한심해할 사람이 늘어날 수가 있다. 

 

추가로, 회의록을 매번 쓰는 게 힘든 경우 엑셀로 쭉 정리하는 것도 방법이다. 산발적으로 요구사항이 오는 경우 이렇게 하면 업무 부담이 줄어든다. 그리고 합의를 구하는 방법은 그 엑셀을 위클리/먼슬리의 한 영역을 할애해서 쭉 추가해서 공동으로 모두 열람하고 추적할 수 있도록 하는 거다. 고객이 나중에 '나는 못 봤다' 라거나 '합의한 적 없다'라고 할 수 있지만 위클리에 매주 들어가 있고 공유되었던 내용을 단순하게 무시할 방법은 없다. 중요한 건 1) 들은걸 기록한다, 2) 공유한다 이 두 가지다. 어떤 방식으로든 지켜보도록 하자. 

 

SI에서는 프로젝트 마지막에 회의록 싸움이 일어나는 경우가 비일비재하다. 특히 큰 규모의 프로젝트에 이해관계자가 많고 유관부서가 많으면 더더욱 그렇다. (고객 담당자가 바뀌면 더 심하다.) 유능한 PM은 회의록 없이도 일을 잘하는 게 아니라, 회의록을 누구보다도 꼼꼼하게 챙겨서 고객과의 싸움에서 이긴다. 그 이유가 뭔지 생각하고, SI회사에서 을로서 얻어터지고 하드 캐리 하기 싫다면 회의록으로 싸우고 이기는 연습을 시작하자.

 

아 추가 꿀팁! 고객이 지나가듯이 애매하게 말하면서 거대한 폭탄(일)을 던지고 간다면 (무시할 수 있는 수준의 자리에서) 은근슬쩍 회의록을 쓰지 말자. 아니면 나머지 회의록을 다 쓰고 그 부분은 빠뜨리자. 고객이 잡아내면 '누락되었네요. 추가하겠습니다'라고 하고, 고객도 모르고 그냥 합의해주면 다음에 이야기 나올 때까지 은근슬쩍 넘어가자(영원이 다시 언급되지 않을 확률이 높은 요구사항들이 있다). 나중에 고객이 '내가 그때 그 이야기했잖아요'라고 말하면 '네? 어느 회의였죠? 제가 회의록을 열어서 확인해보겠습니다.'하고 없다는 걸 각인시켜주면서 요구사항을 날려버리자. 아주 교묘하게, 부지런히 움직여야 달성할 수 있다. 물론, 고객이 아무리 늦어도 해달라고 할 것 같은 건 그냥 요령 부리지 말고 하는 게 낫다. 곧이곧대로 다 적어서 손해보지 말자는 이야기다 ^^ 요령껏 요령껏~

 

내가 작성하는 회의록이 내 무기가 되어야지, 내 목을 조이게 하면 안 된다!