기업 전문 서비스 계약 전 운영 책임과 SLA 점검법

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

제안서의 기능과 가격은 만족스러운데 계약서에 서명하려니 불안한가요? 기업 전문 서비스의 성패는 화려한 기능보다 누가, 언제, 어디까지 책임지는지를 구매 전에 얼마나 구체적으로 합의했느냐에 따라 달라집니다.

특히 컨설팅, 시스템 구축, 운영 대행이 결합된 기업 솔루션은 결과물의 경계가 모호하기 쉽습니다. 아래 점검 항목을 계약 검토 회의에 그대로 활용하면 추가 비용, 일정 지연, 장애 대응 공백을 상당 부분 줄일 수 있습니다.

요구사항을 계약 가능한 문장으로 바꾸는 준비

업무 목표와 솔루션 기능을 분리합니다

“업무 효율을 높인다”는 표현은 사업 목표로는 좋지만 검수 기준으로는 부족합니다. 기업이 기대하는 변화와 서비스 공급사가 실제 제공할 기능을 나눠 적어야 합니다. 예를 들어 목표는 월간 정산 소요 시간을 단축하는 것이고, 납품 기능은 데이터 자동 수집, 오류 알림, 승인 이력 저장으로 구분할 수 있습니다.

서비스는 형태가 남는 제품과 달리 제공 과정과 이용자의 참여가 품질에 영향을 줍니다. 개념의 출발점이 필요하다면 지식백과의 서비스 정의를 참고하되, 실제 계약에서는 추상적인 정의보다 측정 가능한 수행 조건을 우선해야 합니다.

• 목표: 매출 증대, 처리 시간 단축, 오류 감소처럼 경영 관점의 변화를 씁니다.
• 범위: 진단, 설계, 개발, 데이터 이관, 교육, 운영 중 구매 대상에 포함되는 단계를 표시합니다.
• 산출물: 보고서, 설정 파일, 소스 코드, 매뉴얼, 교육 자료의 형식과 수량을 정합니다.
• 제외 사항: 기존 시스템 수정, 외부 라이선스 구매, 현장 장비 교체처럼 별도 비용이 될 항목을 밝힙니다.

현업의 말에서 모호한 표현을 걷어냅니다

“신속하게 지원”, “충분한 교육”, “유연한 연동” 같은 문구가 보인다면 숫자와 조건을 붙여야 합니다. 신속하다는 것은 접수 후 몇 분 안에 답변하는 것인지, 교육은 몇 회이며 참석 인원과 녹화본 제공 여부가 무엇인지 질문해 보세요. 연동 역시 API 제공과 실제 연동 개발은 전혀 다른 업무입니다.

구매 전에는 현업, 정보기술 담당자, 보안 담당자, 재무 담당자가 각자 요구사항을 한 번씩 검토하는 편이 좋습니다. 한 부서만 참여하면 사용 편의성은 확보해도 개인정보 처리나 비용 승인 조건을 놓칠 수 있습니다. 필수 요구, 협상 가능 요구, 향후 요구로 우선순위를 나누면 견적도 훨씬 선명해집니다.

계약서에 그대로 옮길 수 없는 요구사항은 검수할 수도 없습니다. 형용사를 줄이고 대상, 기한, 수량, 판정 방법을 넣어 문장을 다시 써보세요.

서비스 범위와 책임 경계를 확인하는 방법

업무 분장표로 빈칸과 중복을 찾습니다

전문 서비스 계약에서 자주 발생하는 갈등은 어느 한쪽의 역량 부족보다 책임 경계의 빈칸에서 시작됩니다. 데이터 정제는 고객이 하고 공급사는 이관만 하는지, 테스트 계정은 누가 만들며 오류 데이터는 누가 수정하는지를 업무 단위로 나누어야 합니다. 담당자가 두 명인 항목도 최종 승인권자가 없으면 일정이 멈춥니다.

업무 분장표에는 실행 담당, 최종 책임자, 사전 협의자, 결과 공유 대상을 표시할 수 있습니다. 이를 프로젝트 단계별로 작성하면 “그 업무는 포함된 줄 알았다”는 말을 예방할 수 있습니다. 공통 기준이 필요한 이유는 전기 회로에서 기준 전위를 공유하는 개념과도 비슷합니다. 용어 자체가 궁금하다면 GND 관련 지식백과 설명을 참고할 수 있으며, 계약에서도 양측이 같은 기준점을 공유해야 판단이 엇갈리지 않습니다.

1. 착수, 분석, 설계, 구축, 시험, 전환, 안정화 단계로 업무를 나눕니다.
2. 각 업무의 실행 담당자와 최종 승인자를 한 명씩 지정합니다.
3. 고객이 늦게 제공하면 일정에 영향을 주는 자료와 계정을 표시합니다.
4. 제삼자 솔루션 업체나 클라우드 사업자가 관여하는 지점을 따로 구분합니다.
5. 담당자가 바뀔 때 권한과 기록이 자동으로 승계되는 절차를 확인합니다.

제외 범위와 변경 요청 절차를 먼저 묻습니다

포함 범위만 확인하고 제외 범위를 묻지 않으면 견적이 저렴해 보이는 착시가 생깁니다. 출장비, 야간 작업비, 데이터 정제, 추가 인터페이스, 사용자 계정 증설, 보고서 양식 변경이 기본 금액에 포함되는지 확인하세요. “통상적인 수준에서 제공”이라는 답변은 통상적인 수준의 수량과 단가를 문서로 받아야 의미가 있습니다.

계약 이후 새로운 요구가 생기는 것 자체는 실패가 아닙니다. 문제는 변경 요청의 영향도와 승인 절차가 없을 때입니다. 요청서 접수, 비용 및 일정 산정, 양측 승인, 기준선 반영 순서를 정하고 구두 지시로 작업을 시작하지 않도록 합의해야 합니다.

• 변경 요청 한 건의 최소 과금 단위가 있는지 확인합니다.
• 분석만 진행해도 비용이 발생하는지 묻습니다.
• 긴급 변경의 승인 권한과 사후 보고 기한을 정합니다.
• 변경으로 기존 기능에 문제가 생겼을 때 하자와 유상 작업을 구분하는 기준을 둡니다.

SLA 수치와 장애 대응의 현실성을 검증하는 기준

가동률보다 장애 상황의 행동을 살펴봅니다

SLA는 서비스 수준 협약을 뜻하지만 가동률 하나만 적는다고 충분하지 않습니다. 월 가동률 99.9%라도 계획 점검, 고객 귀책, 외부 서비스 장애를 모두 계산에서 빼면 체감 품질과 큰 차이가 날 수 있습니다. 측정 구간, 제외 시간, 측정 도구, 보고 주기를 함께 확인해야 숫자의 의미가 생깁니다.

운영 중 더 중요한 질문은 “문제가 생겼을 때 누가 무엇을 하는가”입니다. 접수 채널이 이메일뿐인지, 야간에는 당직자가 실제로 응답하는지, 원인 분석 보고서는 언제 받을 수 있는지 확인하세요. 매출이나 고객 응대에 직접 영향을 주는 기업 솔루션이라면 심각도 등급도 회사 업무에 맞게 정의해야 합니다.

지원 등급과 월 비용을 함께 계산합니다

지원 비용은 서비스 범위, 사용자 수, 대응 시간, 전담 인력 여부에 따라 크게 달라집니다. 단순 문의 중심의 업무시간 지원은 월 정액 또는 사용량 기준이 흔하고, 야간·휴일 대응이나 전담 담당자가 포함되면 구축비와 별도의 운영비가 커질 수 있습니다. 따라서 특정 금액만 비교하기보다 월 기본료, 초과 작업 단가, 긴급 출동비, 라이선스 증설비를 합친 총비용 시나리오를 만들어야 합니다.

예산 검토에서는 평상시와 장애가 잦은 달을 나눠 계산해 보세요. 월 기본 지원 시간이 열 시간이고 초과 단가가 시간당 십만 원이라면, 안정화 기간에 서른 시간이 투입될 때 예상 청구액이 달라집니다. 공급사에 최근 유사 프로젝트의 월별 지원 시간 분포를 익명 통계로 요청하면 현실적인 예산을 잡는 데 도움이 됩니다.

• 지원 시간이 이월되는지와 최소 청구 단위를 확인합니다.
• 회의, 이동, 원인 조사도 지원 시간에 포함되는지 묻습니다.
• 긴급 장애와 일반 문의의 단가 차이를 비교합니다.
• SLA 미달 보상이 현금 환급인지 다음 달 크레딧인지 구분합니다.
• 보상 한도가 지나치게 낮아 공급사의 개선 유인이 사라지지 않는지 살펴봅니다.

보안과 데이터 권리를 구매 조건에 넣는 절차

데이터의 위치와 이동 경로를 그립니다

기업 서비스가 고객 데이터에 접근한다면 보안 서약서 한 장만으로는 부족합니다. 어떤 데이터가 어느 서버에 저장되고, 공급사 직원이 어떤 장비와 계정으로 접근하며, 백업본은 어디에 남는지 확인해야 합니다. 개인정보, 영업비밀, 일반 업무 자료를 분류하면 항목별 통제 수준을 다르게 적용할 수 있습니다.

국외 클라우드나 외부 생성형 인공지능 도구를 사용하는지도 반드시 물어보세요. 공급사가 작업 효율을 위해 고객 문서나 코드를 외부 도구에 입력할 가능성이 있기 때문입니다. 허용 도구, 입력 금지 정보, 비식별화 방법, 위반 통지 절차를 계약 부속 문서에 넣으면 현장의 판단이 쉬워집니다.

1. 수집하는 데이터 항목과 이용 목적을 목록으로 받습니다.
2. 저장 위치, 보유 기간, 암호화 방식, 백업 주기를 확인합니다.
3. 공급사와 재위탁사의 접근 인원 및 권한 승인 절차를 점검합니다.
4. 보안 사고 인지 후 통지 시한과 연락 책임자를 지정합니다.
5. 계약 종료 후 원본·복제본·백업본의 삭제 증빙 방식을 정합니다.

산출물 소유권과 재사용 권한을 구분합니다

맞춤형 솔루션이라고 해서 모든 소스 코드와 지식재산권이 자동으로 고객에게 넘어오는 것은 아닙니다. 공급사가 기존에 보유한 프레임워크, 프로젝트에서 새로 만든 코드, 외부 오픈소스, 고객이 제공한 자료를 구분해야 합니다. 소유권을 모두 양도받기 어렵다면 최소한 영구 사용권, 수정 권한, 유지보수 업체 변경 시 제공 범위를 확보하세요.

컨설팅 산출물도 같은 원칙이 적용됩니다. 최종 보고서만 받으면 계산식, 인터뷰 원문, 분석 템플릿이 빠져 후속 활용이 어려울 수 있습니다. 파일 형식과 편집 가능 여부까지 명시하고, 공급사의 유사 사례 홍보에 회사명이나 수치가 사용되는 조건도 사전 승인 방식으로 정하는 편이 안전합니다.

• 고객 소유: 원천 데이터, 회사 고유 정책, 내부 업무 문서
• 공급사 기존 자산: 계약 전부터 보유한 방법론, 공통 모듈, 템플릿
• 신규 산출물: 맞춤 코드, 설정값, 분석 결과, 사용자 매뉴얼
• 제삼자 자산: 오픈소스, 유료 라이브러리, 외부 데이터의 라이선스

데이터 반환 조항에는 ‘요청 시 제공’만 쓰지 말고 파일 형식, 제공 기한, 암호화 방법, 비용 부담, 삭제 확인서까지 붙여야 실제로 작동합니다.

검수와 인수인계를 실제 운영처럼 시험하는 과정

검수 기준을 사용자의 행동으로 설계합니다

“정상 작동하면 검수 완료”라는 조건은 양측 모두에게 위험합니다. 정상의 의미를 판단할 입력값, 기대 결과, 허용 오차, 시험 환경이 없기 때문입니다. 실제 사용자가 수행하는 업무 시나리오를 기준으로 테스트하고 정상 사례뿐 아니라 오류, 중복, 권한 부족, 대량 처리 상황도 포함해야 합니다.

예를 들어 승인 솔루션이라면 문서 작성부터 결재, 반려, 재상신, 이력 조회, 퇴사자 권한 회수까지 한 흐름으로 검증합니다. 데이터 통합 서비스라면 정상 파일 한 개를 불러오는 시험에 그치지 말고 누락값, 잘못된 날짜 형식, 대용량 파일, 네트워크 중단 후 재처리를 확인하세요.

• 검수 환경과 실제 운영 환경의 차이를 기록합니다.
• 시험 데이터 생성 및 개인정보 비식별화 담당자를 정합니다.
• 치명적 오류와 경미한 오류의 판정 기준을 합의합니다.
• 재검수 가능 횟수와 보완 기한을 계약 일정에 반영합니다.
• 조건부 승인 후 남은 과제의 보증금 또는 대금 지급 조건을 둡니다.

담당자가 바뀌어도 운영되는지 확인합니다

좋은 인수인계는 설명회를 한 번 여는 것이 아니라 고객 담당자가 문서만 보고 주요 작업을 재현할 수 있게 만드는 과정입니다. 관리자 계정 생성, 사용자 권한 변경, 로그 확인, 백업 복구, 자주 발생하는 오류 처리 등을 고객 담당자가 직접 수행하고 공급사가 관찰하도록 구성해 보세요.

교육 자료는 화면 캡처가 많은 매뉴얼만으로 충분하지 않습니다. 변경 이력, 장애 대응 흐름, 설정값 목록, 외부 연동 정보, 연락망, 알려진 제약 사항이 함께 있어야 합니다. 퇴사나 조직 개편이 잦다면 신규 담당자를 위한 녹화 교육과 추가 교육 단가도 미리 확보하는 편이 경제적입니다.

1. 운영자와 일반 사용자 교육을 분리해 진행합니다.
2. 편집 가능한 원본 문서와 최종 PDF를 함께 받습니다.
3. 관리자 계정과 API 키가 개인 이메일에 묶여 있지 않은지 확인합니다.
4. 고객 담당자가 복구 절차를 직접 실행하는 모의 훈련을 합니다.
5. 인수인계 완료 확인서에 미해결 항목과 담당 기한을 남깁니다.

서명 직전에 반복되는 계약 공백과 비용 착시

낮은 견적보다 빠진 항목을 경계합니다

흔한 첫 번째 실수는 제안 금액만 맞춰 놓고 부가세, 출장, 외부 라이선스, 데이터 이관, 안정화 지원을 따로 두는 것입니다. 처음에는 저렴해 보여도 운영 첫 달부터 추가 청구가 이어질 수 있습니다. 공급사별 견적서를 같은 항목으로 다시 배열해 초기 구축비와 예상 운영비를 합친 총소유비용으로 판단하세요.

두 번째 실수는 영업 담당자의 설명을 계약 조건으로 여기는 것입니다. 회의에서 약속한 전담 지원이나 무상 수정이 계약서와 부속 문서에 없으면 담당자 교체 후 확인하기 어렵습니다. 중요한 답변은 질의응답표에 남기고, 계약서와 충돌할 때 어떤 문서가 우선하는지도 명시해야 합니다.

• 견적 유효기간과 환율 변동 조건을 확인합니다.
• 무상이라는 표현에는 기간, 시간, 횟수의 한도를 붙입니다.
• 제안서, 과업지시서, SLA, 견적서의 우선순위를 정합니다.
• 자동 갱신 시점과 해지 통보 기한을 달력에 등록합니다.

담당자의 선의를 비상 절차로 대체합니다

세 번째 실수는 유능한 담당자 한 명에게 계약의 안정성을 맡기는 것입니다. 그 사람이 휴가를 가거나 퇴사하면 장애 접수와 의사결정이 동시에 멈출 수 있습니다. 주 담당자와 대체 담당자, 기술 책임자, 계약 책임자의 연락 경로를 분리하고 정기적으로 최신 상태를 확인하세요.

마지막 서명 전에는 실제 장애 상황을 가정해 짧은 모의 질문을 던져보는 것이 효과적입니다. “금요일 밤 핵심 기능이 멈추면 누가 전화를 받고, 몇 분 안에 어떤 정보를 제공하며, 외부 업체가 원인일 때 누가 조율합니까?”라는 질문에 양측 답변이 다르다면 계약 공백이 남아 있다는 뜻입니다.

1. 계약 종료나 공급사 교체 시 데이터 반출 비용이 별도인지 확인합니다.
2. 핵심 인력 변경 시 고객에게 사전 통지하는 조건을 둡니다.
3. 분쟁 중에도 데이터 접근과 필수 운영 지원이 유지되는지 점검합니다.
4. 구두 합의는 계약 담당자가 문서화한 뒤 승인하도록 합니다.
5. 서명본과 모든 부속 문서를 한 저장소에 보관하고 갱신 알림을 설정합니다.

시간이 부족할수록 범위, SLA, 데이터 반환, 인수인계, 종료 조건만큼은 생략하지 마세요. 이 항목들이 명확하면 기업 컨설팅과 솔루션 서비스는 담당자의 기억이 아니라 합의된 운영 체계 위에서 움직이게 됩니다.