시스템 개발의 서버·인프라에 관련된 법률 문제란 무엇인가

기업에서 사용하는 IT 시스템은 어떤 면에서 보면, 사양서나 설계서를 작성하고, 그 내용에 맞는 소스 코드를 작성함으로써 만들어지는 것입니다. 그러나 이러한 소프트웨어적인 측면뿐만 아니라, 물리적인 컴퓨터, 즉 인프라가 있어야 시스템이 실제로 기능합니다. 본 기사에서는 시스템 개발 프로젝트에서 인프라라는 영역과 관련이 깊은 법률 문제에 대해 설명해 드리겠습니다.

IT 시스템에서 인프라란 무엇인가

시스템 개발을 담당하는 기술자들을 시스템 엔지니어(SE)라고 부릅니다. 그리고 개발 프로젝트는 사양서 및 설계서 작성과 같은 상류 공정에서 시작하여, 프로그램의 구현 및 테스트를 실시하는 것이 대략적인 흐름이 됩니다. 물론, 광의의 시스템 엔지니어(SE)는 이러한 모든 업무를 담당하는 기술자라고 설명할 수 있지만, 기업이나 직장에 따라 담당하는 업무 내용이나 영역에 따라 더욱 세부적으로 명칭을 구분하는 경우도 있습니다. 인프라 엔지니어라는 명칭은 IT 시스템의 개발 및 운영에 관련된 업무 중에서, 특히 물리적인 컴퓨터의 작동 환경을 구축하는 기술자를 가리킵니다. 기업이나 직장에서 사용되는 IT 시스템은 어떤 의미에서는 소스 코드의 조합으로 이루어진 추상적인 구조물입니다. 그러나, 그 시스템이 본래 기대되는 역할을 수행하기 위해서는 서버, 네트워크를 비롯한 인프라 주변의 환경 구축이 필수적입니다. 프로그램 소스 코드의 구현과 그 작동 환경을 지원하는 인프라 주변의 환경 구축이라는 두 개의 바퀴로 시스템 개발의 실무가 진행됩니다. 이러한 관점은 예상치 못한 문제 발생을 예방하기 위해서도 중요하다고 생각됩니다.

인프라 문제로 프로젝트가 실패하는 구체적인 상황은?

시스템 개발 프로젝트에서 추상적인 프로그램이나 소스 코드의 설계에만 집중하다 보면, 인프라 관리라는 관점을 놓칠 수 있습니다. 그러나 두 가지가 동시에 진행되지 않으면 프로젝트의 실패 위험이 있습니다.

서버 사이징의 오류가 분쟁을 일으키는 사례는?

예를 들어, 프로그램의 구현이나 테스트 등이 모두 완료된 후에야 서버의 처리 능력이 부족하여 시스템이 실제로 사용할 수 없다는 사실이 드러나는 경우가 있습니다. 시스템이 운영 단계에서 어느 정도의 부하를 견딜 수 있는지 예측하고, 시스템의 규모에 맞는 인프라를 구축하는 것을 ‘사이징’이라고 합니다. 서버 사이징의 오류가 원인이 되어 문제가 발생하는 사례는 과거에도 실제로 있었습니다. (결과적으로 합의로 해결되었지만, 유명한 사례로는 이 사례를 참고하실 수 있습니다.) 두 당사자 간의 분쟁에 대해 ‘합의’라는 방법으로 해결하는 방법에 대해서는 아래의 기사에서 자세히 설명하고 있습니다.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

분쟁이 합의로 해결되었다는 것은 간단히 말해 두 당사자가 ‘대화’를 통해 분쟁이 해결되었다는 것입니다. 따라서, 법원에서 판결이 내려진 경우와 달리, 그 합의 내용은 판례로 축적되는 것이 아니며, 개별적인 특성이 강한 것이 일반적입니다.

사례의 본질은, 불명확한 사양에 대한 벤더의 응답 의무 범위이다

그러나, 이러한 분쟁의 본질은 ‘명시되지 않은 사항에 대해 벤더가 어디까지 책임을 지어야 하는가’라는 점일 수 있습니다. 이 점을 고려하면, 아래의 기사 내용에서 많은 힌트를 얻을 수 있습니다.

https://monolith.law/corporate/system-development-specs-function[ja]

위의 기사에서는, 사양서에 기록되지 않은 사항 중 벤더가 어디까지 판단력을 발휘하고 구현 의무를 지어야 하는지를 설명하고 있습니다. 여기서는, 요구 사항 정의서나 기본 설계서 등에서 쉽게 시각화할 수 있는 ‘화면 측’의 사항(일명 ‘프론트엔드’ 영역)과 데이터 이전 등의 ‘로직 측'(일명 ‘백엔드’, ‘데이터베이스’ 영역)에서 이야기가 크게 다르다는 것을 설명하고 있습니다. 즉, (일반적으로 시스템 개발 프로젝트에 전문적인 지식이 없는) 발주자/위탁자도 사양상의 문제를 쉽게 확인할 수 있는 ‘화면 측’의 영역일수록, 발주자/위탁자에게 책임이 돌아가는 경향이 있습니다. 반면, ‘로직 측’의 문제는 수주자/벤더에게 책임이 돌아가는 경향이 있습니다. 이러한 점을 고려하면, 서버 사이징의 문제는 전문가가 아니면 문제의 위치를 인식하기 어려운 영역이므로, 수주자/벤더에게 책임이 돌아가는 영역이라고 볼 수 있습니다. 따라서, 이 점에 대해 본격적으로 법정에서 다투게 된다면, 수주자/벤더 측의 책임을 면제하기 위한 적극적인 사정이 없는 한, 어떤 경우든 수주자/벤더 측에 불리한 판정이 내려질 가능성이 있습니다.

서버 사이징 오류로 인한 문제를 방지하기 위한 대책

앞서 언급한 문제를 예방하기 위해서는, 프로그램 구현 및 소스 코드 작성과 같은 업무와 인프라 환경 구축의 동기화가 중요합니다. 구체적으로 고려할 수 있는 대책은 다음과 같습니다.

서버 사이징에 대한 책임의 소재를 계약상 명확히 하는 것

이러한 사례를 포함하여, 시스템 개발 프로젝트와 관련된 분쟁의 대부분은 시스템 개발 전문가인 벤더와 회사 내부 상황을 이해하는 위탁자 간의 역할 분담이 명확하지 않아 발생하는 경우가 많습니다. 양측의 긴밀한 협력이 프로젝트의 원활한 진행에 필요한 것은 말할 필요도 없지만, 그 과정에서도 역할 분담 및 책임 범위를 가능한 한 계약 등을 통해 명확히 하는 것이 바람직하다고 할 수 있습니다.

개발 요구사항의 구체화, 변경 관리를 철저히 하는 것

또한, 원래 구현해야 할 기능 요구사항이 모호한 경우에도 이러한 분쟁이 복잡해질 위험이 높아집니다. 이는 초기 요구사항 정의 단계에서의 명세화와 프로젝트 중간에 이루어지는 변경 관리 두 가지 측면이 있습니다. 프로젝트 중간에 발생하는 명세 변경에 어떻게 대응해야 하는지에 대해서는 아래의 기사에서 자세히 설명하고 있습니다.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

프로젝트의 성격에 맞는 개발 모델을 선택하는 것

또한, 위의 두 가지 대책과도 깊게 관련되어 있지만, 시스템 개발 프로젝트는 그 성격과 규모 등에 따라 적절한 개발 모델을 선택하는 것이 중요합니다. 일반적으로, 서버 사이징이 중요해질 수 있는 일정 규모 이상의 시스템 개발인 경우, 명세와 책임 범위의 명확화에 적합한 워터폴 모델을 채택하는 것이 유리하다고 생각됩니다. 프로젝트의 성격을 고려한 적절한 개발 모델 선택에 대해서는 아래의 기사에서 자세히 설명하고 있습니다.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

요약

시스템 개발 프로젝트의 원활한 진행을 위해, 인프라 주변의 환경 구축에서 발생하는 문제는 쉽게 눈에 띄지 않는 포인트입니다. 인프라 주변의 문제에까지 주의를 기울이는 것은 기술 전문가가 아닌 이상 부담이 결코 작지 않다고 생각됩니다. 그러나, 이러한 문제의 예방책은 ‘명확한 사양/변경 관리의 철저함’, ‘역할/책임 범위의 명확화’, ‘프로젝트의 규모나 예산에 맞는 개발 모델의 선택’ 등, 매우 기본적인 조치의 연장선상에 있다고 할 수 있습니다. 기업 법무에 종사하는 사람이 먼저 이해해야 할 점은, 인프라의 문제에 대해서도 예방 법무의 기초가 충분히 펼쳐질 수 있다는 점입니다. 또한, IT 분야의 기술자라면, 인프라의 문제가 프로젝트의 심각한 위험 요소가 될 수 있다는 점을 이해하고, 원활하게 업무를 진행하는 것이 중요하다고 생각됩니다.