[SJ] 회의록 어떻게 잘 쓸것인가?

회의의 유형 정의

• 몇가지ㅡ상충하는 의견중 택일
• 부서간 이견 조율 합의
• 과정의 기록:타부서업무협조,설명회등
• 업무지시회의
• 정의되는 과정:기획회의등,다음회의의 기반, 다음 활동 정의

개발 프로젝트를 하든 시스템 운영 업무를 하든 다양한 업무 분야에서 회의는 필수적이다. 특히 프로젝트가 크면 클수록 다양한 이해당사자들이 참여하는 복잡한 회의 횟수도 많아지고 시간도 길어지게 마련이다. 이런 회의의 결과로써 중요한 산출물이 바로 회의록이다.
회의록을 쓰는 원칙은 딱히 정해진 것은 없지만 육하원칙(1H5W)이 널리 알려져 있다. 육하원칙은 Who(누가), When(언제), Where(어디서), What(무엇을), Why(왜), How(어떻게) 를 서술 하는 방식이다. 어떤 사건을 기록하는 가장 보편적인 원칙이기도 하다. 하지만 대부분의 회의록은 양식에서 이런 부분들을 포함 한다. 참석자, 회의 일시, 장소, 회의 내용, 합의 결과, 향후 일정 등을 쓰도록 회의록 양식을 사전에 준비하기 때문에 이런 것들이 빠지는 회의록을 작성하지는 않는다. 하지만 이런 눈에 보이는 항목들 외에 반드시 기록해야 하는 부분들이 있다.이런 내용을 알기 위해서는 프로젝트 수행 시 하는 회의 자체에 대한 이해가 필요하다. 왜 회의를 하고 회의가 남기는 공식적인 것과 비공식적인 것, 회의록에만 남겨지는 것들을 알아야 회의록에 어떤 내용을 남겨야 되는지 이해를 할 수 있다.
모든 회의가 동일한 목적이나 유형은 아니다. 이해당사자간 상호 대립되거나 상충된 의견들을 조율하여 합의를 이르게 하거나 절충안을 찾기 위한 회의( 이런 유형의 회의들은 쉽게 끝나지 않고 2차, 3차 회의를 계속 진행하는 경우도 있다) 도 있고, 꼭 어떤 합의를 이룬다기 보다는 타부서의 의견을 개진하거나 상관의 일방적인 업무 지시를 위한 회의 등 여러 가지의 회의가 있다. 프로젝트 기간중에 하는 회의는 여러가지 유형들이 있겠지만 특히 프로젝트 구축에 중요한 의사결정을 하기 위한 회의들이 많다. 이런 회의 결과가 도출이 되면 그것은 프로젝트 구축을 위한 산출물에 표현이 되게 된다.
한가지 예를 들어 보겠다. 콜센터 상담 어플리케이션을 만드는 프로젝트에서 CRM(Customer Relations Management, 고객관계관리)시스템과 콜센터시스템간의 인터페이스 방식에 대한 결정을 하기 위해 회의를 하게 되면 그 회의는 실제로는 인터페이스 정의서를 만들기 위한회의인 것이다. 회의는 다행이 큰 이견없이 끝났고 콜센터 개발팀에서 제시한 방식인 EAI(Enterprise Application Interface, 이기종 시스템간의 데이터 전송 시스템)를 통해서 연계 하기로 결론을 내면 인터페이스 정의서에 그 결과가 기록이 된다. 그럼 회의를 하면 만든다는 회의록은 언제 필요한 것일까? 이런 의사결정을 위한 회의록의 가장 큰 목적은 나중에 이 결론에 대한 근거자료, 결정 배경으로써 중요한 역할을 한다. 분명히 회의중에 콜센터 개발팀에서 EAI를 제시한 이유가 있을 것이다. 개발적인 측면에서 용이함, 유지보수 측면에서의 장점, 비용적인 측면, 프로젝트 범위와의 연관성등의 다양한 이유가 있었을 것이다. 이런 것들이 회의록에 기록으로 남는 것이다. 그리고 이런 부분들에 대해서 회의에 참석한 이해당사자들이 서로 공감한 부분들이 있거나 자신들의 측면에서 유리한 점이 있어서 합의가 이루어 졌을 것이다. 이런 부분들이 회의록에 기록으로 남아야 하는 것이다.
즉 회의록의 목표는 의사결정의 과정과 근거에 대한 기록이다. 개발관련 공식 산출물에는 이런 과정들이 표현되지는 않는다. 위 예에서보면, 인터페이스 정의서에는 최종적으로 합의된 연계 방식에 대해서만 기술한다. 그 방식이 왜 선택되었는지 굳이 인터페이스 정의서에 설명하지는 않는다. 하지만 프로젝트 후반부에 담당자가 변경되거나, 팀장이 바뀌거나, 내부 감사나 감리 과정을 거치면서 왜 이런 식으로 결정했는지에 대한 확인 요청이 왔을 경우 회의록은 중요한 역할을 한다. 특히 그 결정이 비용이나 일정과 관계 된 것이라면 더욱 중요하다. 이제대략 회의록이 어떤 역할을 하는지 감이 올 것이다. 회의에서 나온 모든 말을 기록한다고 해서 훌륭한 회의록은 아니다. 모든 말을 기록하는 것은 그냥 녹음을 하면 된다. 요즘 스마트폰은 대부분 녹음 기능을 가지고 있기 때문에 증거가 필요하다면 녹음을 하면 된다. 하지만 회의록은 증거를 위한다기 보다는 향후 발생할 수 있는 논란의 소지를 없애고 서로의 기억을 보충해주는 역할이 중요하다. 그리고 그렇게 하기 위해서는 회의록을 쓸 때 장황하게 쓰지 않더라도 좋은 회의록의 역할을 할수 있게 해주는 요령이 필요하다. 그 요령의 핵심은 회의의 내용이나 주제에 맞게 관점을 달리 해서 작성하는 것이다.
그럼 이제 그런 회의록을 쓰기 위한 요령을 알아보기 위해서 먼저 우리가 프로젝트를 진행하거나 업무를 보면서 부딪히게 되는 회의의 유형에 대해서 먼저 살펴 보자.
첫번째 유형은 앞서 예를 들었었던 것 같은 상충하는 몇 가지 방안 중에서 한가지를 택하는 회의, 다수의 인원과 조직이 참여 하는 프로젝트에서는 이런 회의가 참 많다. 특히 상충하는 방안이 서로 다른 부서나 조직간의 이해 관계가 걸려 있는 경우 더욱 어려워진다. 이런 회의의 경우 결국은 방안이 선택되기 까지의 과정이 가장 중요한 부분이다. 누군가 1번안을 제시하면 그 이유가 있을 것이고 거기에 대해서 다른 쪽에서는 문제점을 이야기 하고 또 다른 안을 제시하고, 이런 식으로 다양한 안들에 대한 이유와 문제점들을 늘어 놓고 그중에서 가장 합당한 안을 찾는 방식으로 진행이 된다. 회의록에서는 결국 누가 어떤 안을 어떤 이유로 지지하고 어떤 이유로 반대하는지를 중점적으로 기록을 해야 한다. 이런 회의록은 절대 결과 중심으로 작성이 되어서는 안된다. 실제로 회의 자체는10명이 참석해서 2시간 이상 진행하여 1개의 의사결정을 했을 수도 있다. 만약 중요한 안건이었다면 프로젝트 관리자 입장에서는 아주 흡족해 했을 수도 있고 결론은 1번안 머 이런 식일 수 있다. 하지만 회의록에 그것 한줄에 대해서만 써서는 절대 안된다. 그에 대한 대안들과 후보안들에 대해 왜 탈락하고 기각되고 무시되었는지에 대해서 반드시 기록을 해야 되고 특히나 누가 어떤 안에 대해 어떤 의사 표시를 했는지도 반드시 기록을 해야 나중에 그 회의록을 다시 보게 될 일이 있을 때 그 회의록이 회의록으로써의 의미가 있다. 특히 “누가” 라는 부분이 중요한 것이 나중에 다른 부서에서 이의 제기를 하는경우에 그 회의록에 그 부서의 대표자가 직접 그 내용에 대해서 언급한 부분이 있으면 그 회의록은 훨씬 막강한 의미를 지니게 되고 그 부서는 특별히 이의를 제기 하기 어렵게 된다.
두번째 유형은 업무지시형 회의가 있다. 프로젝트 관련해서 규제부서(보안부서나 품질부서등)에서 내부 규정이나 지침 등을 알려주거나 부서장이나 관련 팀장님이 경영진의 의견이나 고객사의 의견 등을 일방적으로 하달하는 회의등도 많다. 이런 회의들은 회의록 작성이 크게 어렵지 않다. 회의 주최자의 지시 사항만 잘 정리하면 된다. 이때 주의 할 점은 즉시 뭔가 해야 되고 거기에 대한 피드백이 필요한 업무에 대한 지시가 있는 것인지 평소에 꾸준히 주의를 해야 되는 것들에 대한 내용인지 잘 판단해서 회의록에 구분해서 정리해야 된다. 예를 들어 최근개인정보 유출로 프로젝트에 투입된 개발자들이 PC에 대한 보안 관련 준수 사항을 잘 지키고, 담당PL은 이에 대한 일일보안점검표를 작성해서 보고해야 한다. 이런 지시가 만약 있었다면 “보안관련 준수사항을 잘지키고” 는 평소에 꾸준히 해야 되는 일인거고 “보안점검표 작성 보고”는 기한이 정해진 업무를 지시한 것이다. 이런것은 회의록 마지막 부분에 별도의 “향후 작업” 등으로 구분해서 정리하는 것이 좋다. 근데 이 “향후 작업” 부분에는 반드시 담당자와 종료 기간을 명시할 수 있어야 된다. 만약 팀장이 위의 지시 처럼 언제까지라는게 없다면 회의중에질문을 해서 언제까지인지 물어보는게 좋다.
세번째는 부서간 의견 조율을 위한 회의 이다. 이것은 첫번째 회의 유형과 비슷하긴 하지만 조금 차이가 있다. 이것은 제로섬 게임에서 내가 조금 더 많이 가져가는 것과 비슷한 것이다. 그것은 결국 다른 사람은 약간의 손해가 발생할 수 있는 경우다. 즉, 타 부서나 타 팀에게 우리의부서나 팀의 이익을 위해서 손해를 감수하기를 요청하는 것과 마찬가지 인 것이다. 이런 유형의 회의는 회의자체도 힘들지만 회의록 작성도 무척 어렵다. 왜냐면 회의록에 대한 최종 합의를 상대방과 해야 되기 때문에 회의석상에서는 말로써 두리뭉실하게 넘어갔던 부분도 회의록에 문자화 되면 다시 이견이 발생할 수 있기 때문이다. 이런 회의록을 쓸 때 가장 주의 해야 할 점은 명확해야 한다는 것이다. 어차피 전쟁은 시작된 것이고 그 전쟁은 누구 한쪽은 피를 봐야 되는 상황이므로 회의록에 명확하게 결과를 쓰는 것이 중요하다. 이것은 과정 보다도 결과가 훨씬 중요하다. 결과적으로 우리 부서에서는 이렇게 하고 저쪽 부서에서는 이렇게 하기로 했다. 그리고 회의록에 서명 받고 서로 확인하는 것 이게 핵심이다. 어차피 과정을 따진다기 보다는 깃발 꽂는 쪽이 이기는 싸움이기 때문이다. 이런 회의록은 과감해야 되고 시기 적절해야 된다. 회의 끝나자 마자 바로 최단 시간에 작성하고 회의의 여운이 남아 있을 때 바로 서명을 받는 것이 중요하다.
네번째 유형은 과정상 필요한 회의이다. 이것은 타 부서나 협조가 필요한 팀과의 회의이지만 굳이 타 부서에 손해를 감수하기를 요청할 필요가 없다. 예를 들자면 전사 마케팅을 개선하기 위한 솔루션을 도입한다고 하면 마케팅과 간접적인 관계가 있는 영업지원 부서나 고객센터관계자들에게 앞으로 이런 프로젝트가 진행되니 요구사항 도출이나 향후 테스트 등에 지원을 부탁한다거나 프로젝트의 개요 등을 설명하고 동의를 구하여 향후 프로젝트를 진행하는데 서로 협조 체계를 가져 가거나 내부 협조세력을 구축하는데 도움을 줄 수가 있다. 실제 대형 기업에서 프로젝트를 하다 보면 연관 부서간에 의견 협조가 안되서 프로젝트 막판에 힘들어 지는 경우가 많다. 이런 회의록은 이견을 조율하거나 하는 부분이 없기 때문에 누가 참석 했고 언제 했고 이런 일반적인 기록 사항등이 중요한 부분이다. 그리고 회의록 제목도 회차를 적어주거나 해서 이런 과정을 다수 진행했음을 강조하는 편이 좋다. 예를 들어 “마케팅 솔루션 도입 유관부서 협의 (3차)” 이런 식으로 적는 것이 좋다.
특히 회의록을 작성할 때 공통적으로 주의 해야 될 부분이 있는데 그것은 바로 회의에 대한 일종의 결론이 필요하다. 회의는 한번에 끝나지 않고 관련 사항을 여러 번에 나눠서 점진적으로 진행을 해야 할 경우가 많다. 이럴 경우 현재의 회의를 마무리 짓는 것이 필요하다. 적어도 이번 회의에서는 어디까지 합의가 되었고 남은 것은 무엇이다. 라는 것이 정리가 되어야 한다. 근데 이걸 회의시간에 정리를 하지 않으면 회의록에 쓸 수가 없다. 이해하기 쉽게 말하면 회의록에 결론이 없는 경우, 정리가 안되는 경우는 회의 자체가 잘못 되었을 수도 있다. 회의가 흐지부지 하게 끝나 거나 정리가 되지 않는경우 좋은 회의록을 쓸수가 없는 상황이 발생하는 것이다. 그렇기 때문에 회의 주관자는 항상 회의의 마무리 정리를 잘해야 한다. 그리고 회의 이후에 해야 할 작업들이 발생할 경우 반드시 기한과 담당자를 지정해야 한다. 그런 부분도 회의중에 나오지 않으면 회의 진행자나 회의록을 작성하는 서기가 확인을 하거나 회의 이후에 라도 확인을 해야 한다.
어떻게 보면 좋은 회의록을 쓰는 가장 좋은 방법은 회의를 잘하는 것일 수도 있다.