법적 관점에서 본 시스템 개발에서의 회의록 남기는 방법은?

한 회사가 다른 회사에 시스템 개발을 위탁하는 경우, 대표이사 간의 법인인으로 체결되는 계약서나 책임자가 작성한 요구사항 정의서만으로는, 결국 무엇을 언제까지 만들 것인지가 항상 명확하지 않은 경우가 많습니다. 대부분의 시스템 개발에서는, 담당자 수준의 이메일이나 전화 등의 교류, 책임자 수준의 사람이 주관하는 회의 등에서, 처음에는 모호했던 부분의 사양확정, 상황 변화에 따른 사양변경, 기능추가 요청, 발생한 문제에 대한 협력요청 등이 매일 이루어지기 때문입니다.

시스템 개발을 원활하게 진행하고, 또한, 만일 분쟁이 발생한 경우에 대비하기 위한 관점에서, 하나의 시스템 개발 프로젝트의 진행을 원활하게 관리하기 위해서는, 문서작성과 그 관리가 중요해집니다.

본 기사에서는 시스템 개발의 진행회의 등에서 사용하는 회의록 및 회의자료를 남기는 방법에 대해 법적인 관점에서 설명해 드리겠습니다.

시스템 개발에서 문서관리가 왜 중요한가

시스템 개발 프로젝트에서는 확인회의에서의 대화 내용이나 프로젝트의 진행상황과 경과에 대한 기록을 남기는 것이 법률적인 관점에서도 매우 중요합니다. 그 이유는 다음 두 가지를 들 수 있습니다.

나중에 문제가 발생하지 않도록 하기 위해

시스템 개발은 일반적으로 위탁자 측과 벤더 측이 많은 이해관계자를 포함하여 진행되는 프로젝트입니다. 따라서, 위탁자측과 벤더측이 각각 어느 정도의 역할을 맡고, 어떤 것을 의무로 인식하는지에 대해 양측의 인식에 차이가 있으면, 프로젝트의 진행에 장애가 발생할 수 있습니다.

또한, 많은 사람들이 참여하는 프로젝트라는 것은, 다른 관점에서 보면, “사람에 따라 말하는 내용이 약간 다르고, 누가 맞는지 모르겠다”는 커뮤니케이션 문제가 종종 발생할 수 있다는 것을 의미합니다.

양측의 인식에 차이가 없는지 확인하는 의미에서도, 형성된 합의 내용을 글로 정리해 두는 것이 좋으며, 관계자들이 각자의 타이밍에 맡게 같은 내용을 확인할 수 있는 자료로 정리해 두는 것은, 관계자들의 행동을 일치시키는 데 도움이 됩니다.

참고로, 분쟁발생을 사전에 예방하기 위해 법률지식을 활용하는 것을 예방법률 등이라고도 합니다.

나중에 분쟁이 발생했을 때 대비하기 위해

또한, 앞서 언급한 예방법률적인 관점과 비슷하지만, 약간 다른 관점에서 문서관리의 중요성을 설명하면, 실제로 분쟁이 발생한 상황을 가정한 “위기관리”라는 점도 들 수 있습니다.

어떤 문제가 발생하여 결과물이 완성되기 전에 프로젝트가 중단되거나, 처음에 정한 기한에 맞추지 못했다면, 잠시 법정소송이 될 상황을 가정해 봅시다. 위탁자측과 벤더측 모두에게 해당되는 것이지만, “발생한 상황에 대해, 나에게도 이야기할 것이 있다”고 하려해도, 기록이 문서화되어 있지 않으면, 자신의 입장을 입증하려 해도 할 수 없고, 법정에서도 불리한 대우를 받을 수 있습니다.

특히 “기한에 맞추지 못했다”는 문제에서는, 그 원인에 대해, “언제 어떤 타이밍으로 장애가 발견되었는가”, “어떤 타이밍으로 사양변경요청이 있었는가”, “위탁자측에서 기능추가 요청에 대해 벤더가 어떤 대응을 시도했는가” 등이, 법정의 판결을 좌우할 수 있는 중요한 논점이 될 수 있습니다. 이때 “말했다, 말하지 않았다”의 문제가 많이 발생하면, 공정한 분쟁해결을 기대하기 어려워질 것입니다.

시스템 개발회의의 의사록에서 특히 중요한 것은 무엇인가

시스템 개발에서의 회의 유형

시스템 개발 프로젝트에서는 다양한 회의가 계속해서 계획되며 진행되는 경우가 많습니다. 이것은 많은 사람들이 참여하는 프로젝트이기 때문에 당연한 일일 것입니다. 프로그램의 구현을 개발현장에서 진행하는 프로그래머나 엔지니어들도 정기적으로 업무 진행상황을 확인하기 위한 회의를 개최하는 경우가 많을 것입니다. 또한, 구현된 코드에 대해 유지보수성이나 보안측면에서의 취약점 등의 문제가 없는지 확인하기 위해 실제 코드를 보면서 리뷰를 하는 경우도 있을 것입니다.

또한, 이러한 개발현장에서의 담당자 수준의 회의뿐만 아니라, 회사의 이사나 권한을 가진 책임자들이 모여 회의를 하는 경우도 있습니다. 이 경우에는 개발 프로젝트에서의 전반적인 방향성이나 정책을 결정하는 회의가 될 수 있습니다. 이러한 책임자 수준에서 중요사항을 ‘파악’하기 위한 회의는 스티어링 커미티라고도 불립니다.

특히 주의해야 하는 회의는 스티어링 커미티

시스템 개발 현장에서는 참여하는 사람의 입장에 따라, 또는 목적에 따라 다양한 회의가 계획되는 것은 앞서 언급한 바와 같습니다. 하지만 법률적인 관점에서 이 중에서 특히 중요하게 여겨져야 하는 회의는 스티어링 커미티입니다. 담당자 수준에서의 진행확인회의나 리뷰회의에 비해, 스티어링 커미티는 각종 분쟁의 예방과 분쟁발생시의 대책을 위한 관점에서 특히 문서화의 중요성을 확실히 인식해야 합니다. 그 이유는 다음과 같습니다.

1. 스티어링 커미티는 책임자 수준의 사람이 주최하는 회의라는 특성상, 중요한 의사결정에 관련된 회의가 되는 경우가 많으며, 위탁자와 벤더 양측의 인식이 어떤 것인지를 보여주는 것으로서, 법률적인 측면에서도 중요하게 여겨지는 것이기 때문입니다.
2. 담당자 수준의 회의라면 보통 그 회의 내용은 대부분 다양한 설계서나 명세서에 나중에 반영되는 경우가 많으며, 원래 ‘문서화 부재’라는 문제가 발생하는 것은 현실적으로 상상하기 어려운 일이기 때문입니다. (물론, 이들에 대해서도 문서화가 부족하다면, 그 부분에 대한 개선이 필요하다고 생각될 수 있습니다.)

위와 같은 점들을 들 수 있습니다.

스테어링 커미티의 회의록에 관련된 판례

아래에는 스테어링 커미티의 회의록이 실제 판례에서 중요한 증거로 취급된 사례를 하나 소개하겠습니다. 아래에 인용하는 판결문의 사례는 시스템 개발 프로젝트가 중간에 중단된 사례로, 벤더측의 프로젝트 관리 의무 위반이 인정된 사례입니다. 이때의 회의록 내용은 벤더와 위탁자 각각의 초기인식을 보여주는 것으로, 판례에서도 매우 큰 의미를 가지게 되었습니다.

벤더는 스테어링 커미티의 회의록에 기반하여 본 사건 시스템 개발의 진행 상황을 인정하는 것에 대해, 해당 회의록의 기재 내용은 위탁자로부터 수정이 가해진 것이라며, 작업 등의 실상을 반드시 반영하고 있지 않다고 지적하였습니다. 그러나, 스테어링 커미티는 본 사건 시스템 개발의 상급 관리 수준에서의 의사결정을 수행하는 목적으로 설정된 것이며, 벤더 및 위탁자 양측에서 본 사건 시스템 개발의 실시 책임자가 참여하여, 그 종합 평가, 스케줄·작업 진행의 실적·과제의 공유, 중요 과제의 의사결정 등을 수행하였습니다. 그리고 그곳에서 논의된 주요 사항에 대해서는, 회의의 다음 다음 영업일 오전까지 벤더가 회의록을 작성하고, 회의록 데이터베이스에 등록하며, 해당 회의록으로 회의의 최종 결정 사항을 기록화하도록 되어 있었습니다. 회의록을 확정하는 데 있어서는, 벤더 및 위탁자는 회의록으로 작업을 기록화하는 것의 의미를 충분히 인식하면서, 그 내용과 표현을 검토하여, 회의의 실상을 반영한 것으로, 기재 내용을 확정한 것으로 인정할 수 있습니다. 특히 벤더는 시스템 개발을 업으로 하는 자로서, 이러한 회의록 작성의 의미와 방법을 당연히 숙지하고 있었던 것이라고 할 수 있습니다. 따라서, 확정된 회의록은 스테어링 커미티의 작업 실상을 반영하는 것으로 취급하는 것이 적절하다고 할 수 있으며, 특별한 사정이 인정되지 않는 한, 앞서 언급한 작업의 진행 내용 등에 대해서는, 그곳에 기재된 내용이 해당 기일에 스테어링 커미티에서 종합된 것으로 인정하는 것이 적절하다.

도쿄고법 헤이세이 25년(2013년) 9월 26일

법원의 입장은 벤더·위탁자 양측이 합의하에 작성한 회의의 문서로서의 회의록이라면, 그것은 ‘증거’로서 일정한 추정력을 기대할 수 있다는 것으로 생각됩니다. 다른 관점에서 말하면, 회의록에 너무 쉽게 기재를 해버리면, 그것이 그대로 증거가 되는 위험이 있다는 점과 함께, 이에 대해서는 충분히 주의해야 할 것입니다.

회의록에 기재해야 할 구체적인 사항은 무엇인가

회의록은 만일 법정에 상황이 이르게 되었을 때, 또는 그런 상황이 아니더라도 당사자 간의 원활한 후속 협상을 위해 중요한 의미를 가집니다. 그렇다면, 구체적으로 회의록에 어떤 내용을 문서화하여 기록해야 할까요? 아래에서 정리해 보겠습니다.

벤더 입장에서 기록해야 할 사항

벤더는 프로젝트에 대해 시스템 개발 전문가로서의 프로젝트 관리의무를 가집니다.

이러한 의무를 고려할 때, 벤더가 특히 기록해야 할 것은,

1. 각 개발 과정이 완료되었다는 사실과 그 날짜
2. 위탁자 측에서 받은 사양 변경·기능 추가 등의 요청에 대한 응답 내역
3. 위탁자 측의 자체 사정으로 개발 업무의 진행이 지체되는 경우, 협력을 요청하기 위해 취한 대응책과 그 과정

등을 들 수 있습니다.

참고로, 위의 3번 항목에 관련하여 추가 설명하면, 예를 들어 위탁자 측이 검수를 하지 않는 경우 벤더가 고려해야 할 사항에 대해서는 아래의 기사에서 설명하고 있습니다. 아래 기사에서는 벤더가 위탁자의 검수 수행을 위해 얼마나 협력적이었는지에 따라 법원의 판단이 크게 달라질 수 있다는 것을 실제 판결문을 인용하면서 설명하고 있습니다.

위탁자 입장에서 기록해야 할 사항

물론, 위탁자도 자체 시스템을 사용하기 때문에, 시스템 개발에서는 벤더의 개발 업무에 대해 일정한 협력 의무를 가집니다.

1. 원하는 기능, 화면 측면의 외관 등, 위탁자 측에서 벤더에게 전달해야 할 사항에 대한 내역
2. 벤더 측의 과정에서 발생한 다양한 문제의 내역(예를 들어, 팀원의 급작스러운 이탈이나, 벤더 측의 조사 부족이 원인으로 발생한 개발 과정의 일정 지연과 그 원인 등)

위의 2번 항목과 관련하여, 특히 예상치 못한 문제로 발전하기 쉬운 것은, 기존 시스템을 폐기하면서 동시에 새 시스템의 개발을 진행하는 경우입니다. 기존 시스템의 데이터를 새 시스템으로 이전할 때는 특히 문제가 발생하기 쉽지만, 이와 관련된 법적 문제 또한 있습니다.

요약

위 내용은 법적 관점에서 시스템 개발 현장에서 회의록을 남기는 방법에 대한 지침이었습니다. 실무적인 방법론은 물론, ‘법률’, ‘시스템 개발’, ‘문서 관리’라는 주제들의 연결성에 대한 인식을 깊게 하는 것이 중요합니다. 시스템 개발이 많은 사람들과 조직을 포함하여 대규모 상업 거래로 발전하기 쉬운 것이기 때문에, 그에 따른 분쟁의 예방 및 대응이 중요해집니다. 그리고 법적 관점에서 본 증거 보존의 필요성으로부터, 누구의 눈에도 객관적으로 확인 가능한 ‘문서’의 존재가 큰 의미를 가지게 됩니다.

확실히, 모든 대화와 프로젝트의 진행을 완전히 언어화하는 것은 부담이 크며, 또한 현실적이지 않을 수 있습니다. 그러나 법적으로 중요한 사항이 무엇인지를 파악하고, 그 중요한 사항은 적절하게 문서화를 진행하는 것이 중요하다는 점은, 법률 전문가인지 아닌지에 관계없이, 비즈니스에 관련된 모든 사람들에게 널리 인식되어야 할 것입니다.