구두 계약할 때는 다 해준다고 해놓고 나중에 문제 생기니까 그런 말 한 적 없다고 발뺌하는 업자

구두 계약의 위험성과 IT 인프라 관리의 유사점

서버 장비 도입이나 클라우드 마이그레이션을 진행할 때, 판매사나 SI 업체의 구두 약속만 믿고 계약서를 소홀히 했다가 나중에 큰 문제에 직면하는 경우를 자주 봅니다. “성능이 30%는 나올 겁니다”, “A/S는 당연히 무상으로 해드립니다”, “그 기능은 기본으로 포함되어 있습니다”라는 말은 구매 결정의 중요한 기준이 됩니다. 그러나 실제 문제가 발생했을 때, “그런 말씀을 드린 적이 없습니다”, “그건 표준 사양이 아닙니다”, “그 부분은 유상입니다”라는 답변을 들으면 프로젝트 일정은 차질을 빚고 예산은 초과하게 됩니다. 이는 신뢰를 기반으로 한 구두 계약의 치명적 위험을 보여줍니다.

증상: 구두 약속과 실제 결과의 괴리

다음과 같은 증상이 나타난다면, 구두 계약에 따른 문제가 발생하고 있을 가능성이 높습니다. 서버 인프라 구축 현장에서 흔히 접하는 사례입니다.

• 성능 미달: “이 스토리지면 IOPS 10K는 쉽게 나옵니다”라는 말을 믿고 구매했는데, 실제 운영 환경에서 4K도 나오지 않는 경우.
• 기능 누락: “모니터링 솔루션 라이선스는 같이 들어갑니다”라고 했으나, 설치 후 정식 라이선스 구매 필요를 통보받는 경우.
• 지원 범위 분쟁: 장애 발생 시 “24/7 무상 지원”을 약속받았지만, 야간 장애 처리에 별도 비용이 청구되거나 응답이 느린 경우.
• 추가 비용 발생: “현재 구성으로도 충분합니다”라는 컨설팅 후, 확장이 필요해지자 처음부터 다른 구성을 권장했다며 추가 비용을 요구하는 경우.

원인 분석: 모호함과 책임 회피의 구조

이러한 문제가 발생하는 근본적인 원인은 명확한 기록과 책임 소재의 부재에 있습니다. IT 인프라는 복잡한 요소들이 상호 연동되어 있어, 구두로 전달된 ‘모호한 기술적 약속’은 해석의 여지가 너무 많습니다. 판매자의 영업 목표와 구매자의 기술적 기대가 정확히 일치하지 않은 채 프로젝트가 진행되면, 필연적으로 갈등이 발생합니다. 실제로 ‘최대 성능’, ‘기본 포함’, ‘원활한 지원’과 같은 정량화하거나 정의하기 어려운 표현은 후속 분쟁의 주요 씨앗이 됩니다.

해결 방법 1: 계약 전, 명세서(Specification)를 철저히 문서화하기

가장 기본적이면서도 가장 효과적인 예방책입니다. 구두로 논의된 모든 기술 사항은 반드시 문서로 남겨야 합니다. 이는 단순한 제품 목록이 아닌. 상세한 성능 지표와 지원 조건이 포함된 명세서여야 합니다.

명세서 작성 시 다음 항목을 반드시 포함시키십시오.

1. 성능 수치의 명시: “빠르다”가 아닌 “웹 서버 응답 시간 95분위수(95th percentile)에서 200ms 미만”과 같이 측정 가능하고 검증 가능한 수치를 정의합니다. 벤치마크 환경(예: 동시 사용자 수, 데이터 크기)도 함께 기재합니다.
2. 기능 및 라이선스 범위의 목록화: 포함되는 소프트웨어, 모듈, 라이선스 수, 지원 기간을 일일이 나열합니다. “기본 관리 기능” 대신 “실시간 CPU/메모리 모니터링, 로그 수집 에이전트, 월간 성능 리포트 제공”으로 구체화합니다.
3. 지원 조건의 상세화: “무상 지원”이란 표현 대신 지원 채널(전화/이메일/원격), 응답 시간 목표(SLA, 예: 중요 장애 1시간 내 응답), 업무 시간 내/외 지원 여부, 지원 범위(소프트웨어 설정/하드웨어 고장/성능 튜닝)를 명시합니다.
4. 확장 및 마이그레이션 조건 사전 정의: 향후 스케일 아웃/업이 필요할 때의 비용 산정 기준(예: 노드 추가당 OOO만원)과 데이터 마이그레이션 지원 여부를 기술합니다.

이 명세서는 계약서의 부록(Attachment)이 되거나 계약서 본문에 참조되어 법적 구속력을 갖추어야 합니다.

실행 가능한 체크리스트: 계약서 검토 포인트

• 제공받은 제안서(Proposal)의 모든 기술적 내용이 계약서 본문 또는 부속명세서에 그대로 반영되었는가?
• 성능, 기능, 지원에 관한 모든 표현이 정량적이고 검증 가능한가?
• 계약서에 ‘구두 약속은 본 계약에 우선하지 않는다’ 또는 ‘모든 합의는 서면으로 이루어진 것에 한한다’는 조항이 있는가?
• 분쟁 발생 시의 해결 절차(예: 기술적 검증 방법, 중재 기관)가 명시되어 있는가?

해결 방법 2: 이메일을 활용한 공식적 합의 과정 만들기

모든 중요한 기술 논의와 결정 사항은 이메일을 통해 공유하고 확인하는 절차를 필수화하십시오. 이메일은 법적 효력이 있는 공식 기록으로 인정받을 수 있습니다.

1. 회의나 전화 통화 후, 논의된 내용과 합의 사항을 요약하여 상대방에게 이메일로 발송합니다. 예: “오늘 논의한 대로. 이처럼 a 솔루션의 클러스터 구성 시 장애 조치 시간(failover time)을 60초 이내로 보장해 주시기로 합의하였음을 확인합니다.”
2. 상대방으로부터 “내용 확인하였습니다” 또는 “수정할 부분은 다음과 같습니다”라는 답신을 받아야 합니다. 답신이 없을 경우, “확인 요청” 메일을 재발송하여 기록을 남깁니다.
3. 이러한 합의 메일들을 프로젝트 파일에 체계적으로 보관하고, 최종 명세서나 계약서 개정 시 반영합니다.

이 과정은 상대방에게 신중함을 요구하게 하며, 나중의 발뺌을 사전에 차단하는 효과가 있습니다.

해결 방법 3: 개념 증명(POC)과 성능 검증 조건 명시

성능과 관련된 약속은 실제 환경에서 검증할 수 있는 기회를 계약 조건에 반드시 포함시키십시오. 이는 가장 논쟁이 될 수 있는 부분을 사전에 해결하는 핵심 수단입니다. 만약 이러한 객관적인 검증 절차 없이 구두 계약만 믿고 공사 진행했다가 돈 못 받고 법적 다툼에서 지는 인테리어 업체처럼 안일하게 대처한다면 큰 금전적 손실을 입을 수 있으므로, POC 계약 시 고려해야 할 사항은 다음과 같습니다

1. 검증 환경 정의: POC를 수행할 하드웨어 사양, 네트워크 대역폭, 운영체제 버전, 테스트에 사용할 애플리케이션 및 데이터 샘플을 명확히 합니다. 업체가 이상적인 환경을 제공하여 결과를 조작하는 것을 방지합니다.
2. 성공 기준 수치화: POC가 성공적으로 끝났다고 판단하는 구체적인 수치를 합의합니다. 예: “부하 테스트 툴로 1000 VUSER를 걸었을 때, 트랜잭션 성공률 99.9% 이상, 평균 응답 시간 2초 미만을 달성해야 함.”
3. 비용과 일정 명시: POC 기간, 인력 지원 범위, 비용 부담 주체(일반적으로 업체 부담), POC 실패 시의 후속 조치(예: 계약 무효 또는 재구성)를 계약서에 명시합니다.

POC 결과 보고서는 최종 계약의 일부가 되어야 하며, 이 보고서에 명시된 성능이 실제 도입 후에도 유지되어야 할 의무 사항이 됩니다.

주의사항 및 이미 문제가 발생했을 때의 조치법

이미 구두 약속만 믿고 진행한 프로젝트에서 문제가 발생했다면, 당황하지 말고 체계적으로 대응하십시오.

중요: 분쟁 상황에서는 감정적으로 대응하기보다 사실과 기록을 중심으로 대화를 이끌어야 합니다. 첫 대응은 공식 이메일 채널을 통해 진행하며, 모든 통화 내용은 요약하여 다시 이메일로 확인하는 습관이 필수입니다.

1. 기존 기록 수집: 과거 주고받은 이메일, 제안서, 회의록, 채팅 기록 등 구두 약속의 흔적이 될 수 있는 모든 문서를 확보합니다. “~라고 말씀하셨습니다”라는 내용이 담긴 메일 한 통이 결정적 증거가 될 수 있습니다.
2. 현재 문제의 객관적 기록: 성능 미달이라면 성능 테스트 결과 스크린샷, 장애 발생 시의 로그 파일, 지원 요청 후 응답이 늦어진 타임라인 등을 상세히 문서화합니다.
3. 공식적 문제 제기: 수집한 자료를 바탕으로, 계약서나 명세서의 특정 조항을 인용하며 문제를 공식 이메일로 제기합니다, 감정적 표현은 배제하고 사실만을 서술합니다. 예: “계약서 부속명세서 3페이지에 명시된 ‘평균 응답 시간 150ms 미만’ 조건에 미달하는 것으로 테스트 결과 확인되었습니다(첨부 파일 참조). 이에 대한 시정 조치 및 일정을 요청드립니다.”
4. 계약서의 분쟁 해결 조항 확인: 계약서에 명시된 분쟁 해결 절차(예: 협의, 중재, 소송)를 따라 다음 단계를 준비합니다. 내부 법무팀이나 외부 법률 자문을及早에 활용하는 것이 좋습니다.

전문가 팁: 기술 조달의 핵심은 ‘검증 가능성’과 ‘기록’

서버 한 대를 들여오는 것도, 클라우드 서비스 하나를 가입하는 것도 명확한 SLA(서비스 수준 협약) 없이는 시작하지 마십시오. “믿음”은 인간 관계의 미덕이지만, IT 인프라 조달과 운영의 기준은 될 수 없습니다. 모든 약속은 측정할 수 있고, 기록으로 남으며, 이행되지 않았을 때 명확한 책임 소재와 페널티가 따라야 합니다. 가장 값비싼 서버보다 더 값비싼 것은, 모호한 계약으로 인해 발생하는 장애 시간과 이를 해결하기 위해 소모되는 조직의 에너지입니다.

종합하면, IT 인프라 구축은 기술적 이해도만큼이나 계약 관리 능력이 요구되는 작업입니다. 구두 계약의 유혹을 뿌리치고, 모든 것을 문서화하고, 검증 가능하게 만드는 절차를 고수하는 것이 장기적으로 가장 효율적이고 안전한 방법입니다. 이는 단순한 계약 기술이 아닌, 안정적인 서비스 운영을 위한 최소한의 기술적 책임감입니다.