시스템 개발에서 벤더로부터 위탁자에게의 사과의 법적 의미란?

시스템 개발뿐만 아니라, 일명 서비스 업종에서 고객으로부터 제기되는 불만에 대한 대응은 말할 필요도 없이 중요합니다. 시스템 개발에서도 이러한 이슈는 결코 예외가 아니며, 고객인 위탁자로부터 제기되는 불만에 대해 기술 서비스를 제공하는 벤더가 대응을 요구받는 상황은 종종 발생합니다.

양측의 커뮤니케이션을 원활하게 유지하는 것을 중요시하면, 상대방의 주장을 듣고 사과하는 것이 합리적인 경우도 있을 것입니다. 그러나 구두로 사과를 하거나, 문서로 사과문을 제출한 결과로, 위탁자 측의 불합리한 주장이 그대로 사실로 인식되는 것은 아닌지라는 우려를 가진 사람도 있을 것입니다.

본 글에서는 ‘벤더로부터 위탁자에게 이루어진 사과’에 초점을 맞추어, 이것이 법적으로 어떤 의미를 가지는 것으로 이해되는지에 대해 설명하겠습니다.

시스템 개발 현장에서 왜 ‘사과’가 문제가 되는가

시스템 개발은 서비스 업의 일종이다

시스템 개발이라는 업무를 아웃소싱 형태로 외부 업체가 개입하는 경우, 이는 일종의 ‘기업 대상 서비스 업’이라고 할 수 있습니다. 법률 용어를 굳이 들고 나오자면, 도급계약이나 준위임 계약 등의 형태로 계약이 체결되는 것이 일반적입니다. 도급계약과 준위임 계약의 차이에 대해서는 아래의 기사에서 자세히 설명하고 있습니다.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

이야기의 핵심은, 어떤 형태의 계약이든, 일을 받는 벤더 측 기업이 보유한 기술력과 인력(그리고 그런 힘을 바탕으로 만들어진 제품)을 기반으로 매출을 내는 것에 변함이 없습니다. 벤더 측에 속하는 ‘사람’의 힘으로 제공되는 서비스와, 그에 대응하는 보수의 교환을 목적으로 하는 상업 거래이므로, IT 시스템의 개발이라는 업무는 원칙적으로 서비스 업의 일종이라고 할 수 있습니다.

위탁자가 ‘고객’이기 때문에 사과를 요구한다

시스템 개발이 서비스 업이기 때문에, 불만이나 클레임이 위탁자로부터 제기되는 것도 당연히 예상됩니다. 동시에, 그런 클레임에 정확하게 대응하는 능력도 벤더에게 요구되는 것입니다. 실제로 다양한 클레임이나 불만에 대해 벤더가 사과 등의 대응을 하면, 다시 협력 체제가 구축되고 프로젝트가 성공으로 이끌어지는 경우도 있을 것입니다.

그러나 반면에, 만약 프로젝트가 그 후에 실제로 중단되는 경우, 심지어 소송까지 이르는 상황을 가정해 봅시다. 위탁자는 벤더 측의 사과를 근거로, ‘벤더 측도 책임 사유를 자인하고 있다’고 주장할 수 있습니다.

위탁자는 어디까지 고객으로 있을 수 있는가라는 문제

시스템 개발이라는 프로젝트는, 확실히 한 면에서는 ‘고객’인 위탁자와 ‘외부 업체’인 벤더 사이에서 이루어지는 상업 거래입니다. 그러나 이런 관계성을 넘어서는 복잡성을 가진 것이 시스템 개발에 관한 계약의 특징입니다. 즉, 고객인 위탁자도 벤더의 의무에 협력해야만 프로젝트가 완료될 수 있는 것입니다. 위탁자 측에도 일정한 협력 의무가 부과되며, 양측이 협동 관계에 서서 프로젝트를 진행해야 하는 것은 과거의 판례에서도 지적되고 있는 사실입니다.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

벤더로부터 위탁자에 대한 ‘사과’를 둘러싼 법률 문제를 고려할 때, 이런 관계의 복잡성을 인식하는 것은 중요한 일입니다. 위탁자와 벤더 사이의 관계는, 상호 동등한 파트너십으로서 건전한 형태로 나아가는 경우도 있지만, ‘수많은 외부 업체 중 하나’라는 시각으로 보이는 경우도 있을 수 있습니다. 위탁자도 협력하고, 프로젝트의 달성을 목표로 협동하는 것이 법적 의무라는 기본 전제가 잊혀질 때 종종 나타나는 것이 부당한 사과 요구라는 문제입니다. 이 점은, 다른 서비스 업에는 별로 보이지 않는, 시스템 개발이라는 업무에 고유한 특성이라고 할 수 있습니다.

법원은 ‘사과’를 어떻게 보는가

그렇다면 실제로, 시스템 개발을 둘러싼 소송에서, 벤더로부터의 사과가 어느 정도 법적 의미를 가지는 것으로 취급되고 있는지를 아래에서 살펴보도록 하겠습니다.

사과를 둘러싼 판례 1: 위탁자로부터의 무릎 꿇기 요구

이 사건에서는, 밤샘 작업 후 위탁자에게 방문했을 때, 데이터를 삭제했는지의 비난을 받고, 무릎을 꿇은 후에, 위탁자의 주장에 따라 사과문을 제출한 경과입니다. 그러나 법원은, 그곳에서의 사과문에 진심이 없다는 견해를 보였습니다.

H는, 이 점에 대해 기록된 사과문을 작성하였지만, 그것은 밤샘 작업 후에, 헤이세이 13년(2001년) 10월 4일, 원고 사무소를 방문했을 때, 일방적으로 엄격하게 비난받고, 무릎을 꿇은 후, 원고의 요구에 따라, 일단 원고 임원들의 분노를 진정시키기 위해, 그들의 주장에 따라 작성한 것이며, H의 진심이 아니다. 마찬가지로 N이 작성한 사과문의 취지도 N의 진심이 아니다.

도쿄지방법원 헤이세이 16년(2004년) 4월 23일

비난이 ‘일방적’이었다는 점, ‘분노를 진정시키기 위해’, ‘진심이 아니다’ 등의 형태로, 당사자의 심정을 고려한 판단을 내린 점이 특징적이라고 할 수 있습니다.

사과를 둘러싼 판례 2: 사과문을 쓰거나 2000만 엔을 지불하라는 선택

또한 아래의 사례에서는, 엔드 위탁자에게 가져다주는 손해에 대해, 사과문을 쓰는 것에 대해 벤더가 동의했다 하더라도, 법적 책임이 벤더에게 귀속되어야 하는 것인지의 문제와는 구분해야 한다는 판단이 내려졌습니다.

원고의 대표자는, 해당 보고서를 받은 후, “이로써 E사가 나쁜 것이 분명해졌으니, 사과문을 쓰거나, 소프트웨어 개발비 2000만 엔을 부담하라.”라는 취지의 말을 했다. 피고는, 이 요구에 따라, 같은 해 1월 19일에, 해당 결함의 발생으로 원고에게 불편을 끼쳤다는 취지의 ‘사과문’을 작성하고, 이를 원고에게 전달했다.

(중략)

E사 제품의 판매자로서 할 수 있는 한도 내에서 대응했다고 볼 수 있어야 하며, 그 이상의 대응을 하지 않았다고 해서, 바로 피고가 본 거래 기본 계약에 기초한 피고의 채무를 게을리 했다고는 할 수 없다.

도쿄지방법원 헤이세이 8년(1996년) 7월 11일

형식적인 사과문의 수신인을 누구로 할 것인가와 같은 점이 아니라, 실무의 방식을 중시하고 그 위에 귀속할 대상을 결정하는 방식이 판결문에서도 읽혀진다고 할 수 있습니다.

위의 판례에서 공통적으로 말할 수 있는 것

위의 판례에서 말할 수 있는 것은, 벤더가 형식적으로 사과 요구에 응했다 하더라도, 그것이 현실의 소송에서 반드시 결정적인 의미를 가진다는 것은 아니라는 것입니다. 사과가 이루어지는 이유가 비즈니스 상에서도, 일을 진행시키기 위한 편의상의 것에 불과한 경우가 많다는 점은, 소송에서도 충분히 고려되는 사정이라고 생각됩니다. 오히려 그런 형식적인 사과의 유무보다는, 사과가 이루어진 경과나, 사과문이 작성된 경과를 고려하여, 위탁자와 벤더 사이에서 어떤 인간 관계가 구축되었는지 등도 고려한 위에서 종합적인 판단을 내리려고 하는 것이 법원의 입장이라고 볼 수 있을 것입니다.

시스템 개발에서, 위탁자도 벤더에게 협력 의무가 있다는 것은, 원래 법원이 보여주고 있는 견해입니다. 위탁자가 벤더에게 결코 협력적이라고 말하기 어려운 지배적이고 고압적인 관계가 있었다고 보여지는 사례에 대해서는, 더욱 사과는 형식적인 것으로 취급되기 쉽습니다.

경솔하게 사과에 응하는 것은 좋지 않으므로 주의

그러나, 만약 소송이 시작되었을 때, 사과가 그 자체로 결정적인 증거가 되는 경우가 드물다 하더라도, 경솔하게 사과를 하는 것이 좋다는 것은 아닙니다. 경솔한 사과는, 소송에 이르기까지의 협상 장면에서도, 위탁자 측에서 고집스러운 태도를 끌어내는 위험도 있습니다. 또한, 소송의 초기 단계에서, 판사가 사과문을 중심으로 인상을 형성하게 되면, 오해를 풀기 위해 많은 노력과 시간이 필요하게 될 수도 있습니다. 더욱이, 단순히 사과의 의미를 보여주는 것에 그치지 않고, 사과 내용이나 사과문의 기재 내용이 벤더의 과실을 세밀하게 지적하고 있는 경우에는, 사실 인정의 단계에서 불리한 해석이 이루어질 요소가 될 수도 있습니다.

어쨌든, 불만 처리·클레임 처리 등의 문제 자체도 법무의 문제라는 인식을 가진 위에서, 어떻게 사과를 해야 하는지에 대한 문제에 대해서도, 외부 전문가의 활용을 적극적으로 검토해야 할 것입니다.