기업용 IT 솔루션 데모와 PoC, 본계약 성패를 가르는 차이

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

화려한 제품 데모를 보고 계약했는데 실제 업무에서는 핵심 기능이 작동하지 않는 경우가 있습니다. 데모는 솔루션이 할 수 있는 일을 보여주지만, 우리 회사의 데이터와 업무 조건에서도 같은 결과가 나오는지까지 보증하지는 않기 때문입니다.

기업용 IT 솔루션을 구매하기 전에는 데모와 PoC를 분리해서 설계해야 합니다. 디지털의 기본 개념은 네이버 지식백과의 디지털 용어 설명처럼 정보의 표현 방식에서 출발하지만, 기업의 디지털 솔루션 도입은 데이터·사람·프로세스가 함께 바뀌는 프로젝트입니다. 아래 단계별 점검표를 따라가면 영업 설명에 머물지 않고 실제 도입 가능성을 판단할 수 있습니다.

1. 제품 데모와 PoC의 목적부터 분리합니다

보여주는 시간과 증명하는 과정은 다릅니다

제품 데모는 공급사가 준비한 표준 시나리오를 통해 기능과 화면, 사용 흐름을 확인하는 자리입니다. 반면 PoC는 제한된 범위에서 실제 요구사항이 기술적으로 구현되는지 검증하는 과정입니다. 데모에서 검색 결과가 빠르거나 보고서가 깔끔하게 출력되더라도 사내 데이터 구조, 권한 체계, 동시 사용자 수가 반영되지 않았다면 구매 판단의 근거로는 부족합니다.

예를 들어 영업관리 솔루션 데모에서는 고객 등록부터 매출 대시보드까지 5분 안에 진행될 수 있습니다. 그러나 우리 회사에는 고객 코드가 두 시스템에 중복 저장돼 있고 부서별 열람 권한이 다를 수 있습니다. 이런 조건을 시험 데이터와 연동 환경으로 재현하는 것이 PoC입니다. 데모는 가능성을 탐색하고 PoC는 위험을 발견한다고 구분하면 이해하기 쉽습니다.

• 데모에서 확인할 것: 핵심 기능의 존재 여부, 사용자 화면, 기본 업무 흐름, 모바일 지원 범위
• PoC에서 증명할 것: 실제 데이터 호환성, API 연동, 권한 분리, 처리 속도, 오류 대응
• 본계약 전에 남길 것: 통과 기준, 미해결 항목, 추가 개발 범위, 책임 주체를 담은 문서
• 경계할 신호: 표준 샘플만 반복해서 보여주거나 실제 조건의 테스트를 계속 미루는 경우

실무 팁: 데모가 끝난 직후 “좋아 보였다”가 아니라 “우리 요구사항 중 무엇이 확인됐고 무엇이 확인되지 않았는가”를 회의록 첫 줄에 적어 보세요.

2. 구매 후보를 줄이는 사전 질문표를 만듭니다

기능 개수보다 해결할 업무를 먼저 적습니다

여러 솔루션을 같은 기준으로 평가하려면 요청서를 보내기 전에 현재 문제를 한 문장으로 정의해야 합니다. “좋은 협업 솔루션이 필요하다”는 표현은 평가가 불가능합니다. “월평균 800건의 승인 요청을 처리하면서 평균 2.5일인 결재 시간을 1일 이내로 줄인다”처럼 대상, 빈도, 현재 수치와 목표를 함께 적어야 공급사도 구체적으로 답할 수 있습니다.

필수 기능과 선호 기능을 섞지 않는 것도 중요합니다. 법적 보관 기간을 충족하는 감사 로그는 필수일 수 있지만, 대시보드 색상 변경은 선호 사항일 가능성이 큽니다. 모든 요구를 필수로 지정하면 후보가 사라지거나 과도한 커스터마이징 비용이 붙습니다. 반대로 핵심 요구가 모호하면 낮은 견적을 제시한 제품이 선정된 뒤 추가 개발비가 늘어납니다.

1. 대상 업무의 시작과 종료 지점을 한 문장으로 작성합니다.
2. 사용자 수, 월간 처리 건수, 데이터 용량, 해외 접속 여부를 수치로 적습니다.
3. 요구사항을 필수·협의 가능·향후 검토의 세 단계로 나눕니다.
4. 개인정보, 재무정보, 영업기밀 등 데이터 등급을 표시합니다.
5. 기존 ERP, 그룹웨어, 인증 시스템과 연결해야 할 인터페이스를 기록합니다.
6. 후보 제품마다 동일한 질문지를 보내 답변의 구체성과 근거를 비교합니다.

구매 전 질문에는 “지원합니다”라는 답변만 받지 말고 지원 방식도 요구해야 합니다. 표준 기능인지, 별도 라이선스인지, 개발이 필요한지, 국내 기술지원팀이 처리하는지를 각각 표시하면 공급사의 답변을 객관적으로 비교할 수 있습니다.

3. 데모 시나리오는 실제 사용자 동선으로 요청합니다

공급사의 순서가 아니라 직원의 하루를 재현합니다

좋은 데모는 메뉴를 차례대로 소개하는 제품 설명회가 아닙니다. 현업 사용자가 업무를 시작해 결과를 확인할 때까지의 흐름을 끊김 없이 보여줘야 합니다. 구매 담당자가 사전에 익명화한 샘플 문서, 필수 입력값, 승인 조건과 예외 상황을 전달하면 공급사가 준비한 최적 화면에만 의존하는 문제를 줄일 수 있습니다.

정상 처리만 확인해서도 안 됩니다. 잘못된 파일 형식이 올라왔을 때의 안내, 승인자가 휴가 중일 때의 대결 처리, 권한 없는 직원의 접근 차단, 모바일 네트워크가 끊겼을 때의 저장 상태를 요청해 보세요. 직원이 실제로 불편을 느끼는 지점은 성공 화면보다 오류와 예외 화면에 더 자주 숨어 있습니다.

• 현업 담당자 2명 이상을 데모 평가에 참여시킵니다.
• 공급사 설명 중 질문을 미루지 말고 해당 화면에서 즉시 재현하도록 요청합니다.
• 클릭 수, 대기 시간, 수작업 입력 횟수를 관찰자가 따로 기록합니다.
• “추후 제공 예정”인 기능은 현재 기능과 구분해 평가표에 표시합니다.

데모 종료 후 참석자에게 단순 만족도 대신 “업무가 빨라지는 지점”과 “새로 생기는 수작업”을 각각 세 가지씩 쓰게 하세요. 이 답변은 기능표에는 나타나지 않는 사용성 비용을 찾아내는 데 도움이 됩니다.

4. PoC 범위와 합격선을 계약 전에 숫자로 고정합니다

작게 시험하되 핵심 위험은 축소하지 않습니다

PoC가 길다고 정확한 것은 아닙니다. 핵심은 구매 결정에 영향을 주는 불확실성을 선별해 제한된 기간 안에 검증하는 것입니다. 예를 들어 고객 상담 솔루션이라면 모든 부서에 배포하기보다 상담원 10~20명과 대표 채널 하나를 대상으로 데이터 이관, 응답 속도, 상담 기록 검색, 장애 시 복구를 시험할 수 있습니다.

다만 사용자 수만 줄이고 실제 데이터의 복잡성까지 없애면 의미가 약해집니다. 중복 고객, 빈 필드, 오래된 코드, 큰 첨부파일처럼 운영 환경에서 문제를 일으킬 자료를 익명화해 포함해야 합니다. 디지털 정보가 복제·처리되는 특성을 이해하려면 디지털 개념에 관한 지식백과 설명도 참고할 수 있습니다. 실제 도입에서는 이 특성이 데이터 정합성과 접근 통제 문제로 이어질 수 있습니다.

• 성능: 주요 화면의 95%가 합의한 시간 이내에 열리는지 측정합니다.
• 정확성: 이관 표본의 필수 필드 일치율과 누락 건수를 확인합니다.
• 연동: API 호출 성공률, 재시도 방식, 중복 전송 방지 여부를 시험합니다.
• 보안: 역할별 접근 차단, 관리자 행위 기록, 계정 회수 절차를 검증합니다.
• 사용성: 교육 후 사용자가 도움 없이 완료하는 업무 비율을 기록합니다.
• 운영: 장애 접수부터 최초 응답, 우회 조치, 복구 안내까지 모의 훈련합니다.

“빠르게 작동한다” 대신 “동시 사용자 50명 조건에서 조회 요청의 95%가 2초 이내 완료된다”처럼 합격선을 작성해야 합니다. 실패 조건도 정해 두세요. 핵심 API가 작동하지 않거나 치명적인 권한 노출이 발견되면 다른 점수가 높아도 도입을 보류한다는 중대 결함 기준이 필요합니다.

5. 보안과 데이터 소유권은 별도 점검표로 확인합니다

기능 평가에 가려진 운영 위험을 찾아냅니다

IT 서비스 구매에서 보안 질문은 “암호화가 되나요?”로 끝나기 쉽습니다. 하지만 암호화 대상과 구간, 키 관리 주체, 관리자 접근 범위가 명확하지 않으면 답변의 실효성을 판단하기 어렵습니다. 저장 데이터와 전송 데이터의 보호 방식, 다중 인증 지원, 접속 기록 보존, 취약점 조치 절차를 각각 확인해야 합니다.

특히 SaaS를 계약할 때는 데이터가 누구의 소유인지뿐 아니라 계약 종료 후 어떤 형식으로 얼마나 빨리 돌려받을 수 있는지를 물어야 합니다. CSV 파일만 제공되는데 첨부파일이나 이력 데이터가 빠진다면 다른 시스템으로 이전하기 어렵습니다. 백업이 존재한다는 설명도 복구 가능성을 뜻하지 않으므로 복구 목표 시간, 복구 시점, 시험 주기와 결과 제공 여부까지 확인하는 편이 안전합니다.

• 데이터 저장 국가와 재위탁 업체의 역할이 공개돼 있는지 확인합니다.
• 관리자와 일반 사용자의 권한을 분리하고 변경 이력을 남길 수 있는지 봅니다.
• SSO와 다중 인증이 기본 요금에 포함되는지 별도 상품인지 구분합니다.
• 보안 사고 발생 시 통지 시간, 연락 채널, 조사 협조 범위를 확인합니다.
• 계약 종료 시 원본·첨부·로그의 반출 형식과 삭제 확인 절차를 문서화합니다.
• 정기 보안 업데이트의 제공 기간과 지원 종료 정책을 요청합니다.

전문가 조언: 공급사의 보안 인증은 유용한 출발점이지만 우리 회사의 설정이 안전하다는 보증서는 아닙니다. 인증 범위와 실제 도입 범위가 일치하는지까지 확인해야 합니다.

개인정보나 민감한 영업정보를 PoC에 사용할 때는 원본을 그대로 복사하지 않는 것이 원칙입니다. 가명·마스킹 데이터로도 목적을 달성할 수 있는지 먼저 판단하고, 불가피하다면 접근자, 보관 위치, 삭제 시점과 삭제 확인 책임자를 PoC 시작 전에 지정하세요.

6. 견적서에서는 라이선스보다 총소유비용을 읽습니다

첫해 할인과 장기 운영비를 같은 표에 놓습니다

월 사용자당 요금만 비교하면 실제 예산이 크게 달라질 수 있습니다. 초기 구축, 데이터 정제와 이관, API 사용량, 저장 공간, 관리자 교육, 사용자 교육, 기술지원 등급, 추가 개발, 환율과 세금까지 더해야 총소유비용을 볼 수 있습니다. 첫해 라이선스를 할인하는 대신 2년 차부터 정상 가격이 적용되는 조건도 흔하므로 최소 3년 기준으로 계산하는 편이 좋습니다.

예를 들어 사용자 100명에게 월 2만원을 제시한 서비스는 연간 라이선스만 보면 2,400만원입니다. 여기에 초기 설정 1,000만원, 연동 개발 2,000만원, 교육 500만원, 프리미엄 지원 연 600만원이 붙으면 첫해 비용은 6,500만원이 됩니다. 이것은 특정 제품의 시세가 아니라 숨은 비용을 찾기 위한 계산 예시이며, 실제 계약에서는 공급사의 최신 견적과 과금 단위를 확인해야 합니다.

1. 3년 동안 예상되는 활성 사용자 수의 증감 폭을 계산합니다.
2. 최소 구매 수량과 휴면·외부 사용자 과금 여부를 확인합니다.
3. API 호출량, 저장 용량, 백업 공간의 초과 단가를 적습니다.
4. 필수 연동과 선택 연동을 나누고 유지보수 비용까지 받습니다.
5. 가격 인상 통지 기간과 갱신 시 할인 종료 조건을 확인합니다.
6. 중도 해지 위약금, 데이터 반출비, 전환 지원비를 총액에 포함합니다.

가격표에는 없지만 내부에서 발생하는 비용도 있습니다. 현업 인터뷰 40시간, 데이터 정제 120시간, 관리자 교육 16시간처럼 투입 시간을 기록하고 내부 시간당 원가를 곱해 보세요. 두 제품의 견적이 비슷하더라도 관리가 복잡한 솔루션은 매년 더 많은 운영 인력을 요구할 수 있습니다.

7. 4주 검증과 3년 비용으로 최종 결재안을 만듭니다

의사결정자가 바로 판단할 수 있는 숫자를 남깁니다

최종 결재 문서는 기능 목록을 길게 붙이는 대신 검증 결과, 남은 위험, 필요한 비용과 일정이 한눈에 보여야 합니다. 추천 제품 하나만 제시하면 선택 근거가 약해질 수 있으므로 최종 후보 2개와 현행 유지안을 같은 기준으로 비교하세요. 점수 차이가 작다면 가격이 아니라 중대 결함과 전환 난이도가 의사결정을 가를 수 있습니다.

일반적인 중소 규모 PoC는 준비 1주, 실행 2주, 결과 분석 1주처럼 총 4주로 설계할 수 있습니다. 담당자는 현업 2명, IT 1명, 보안 또는 개인정보 담당 1명, 공급사 담당자를 지정하고 주당 내부 투입 시간을 미리 합의합니다. 복잡한 ERP 교체나 다수 시스템 연동이라면 이 숫자를 그대로 적용하지 말고 범위를 나눠 검증 기간을 다시 산정해야 합니다.

• 1주 차: 테스트 계정, 익명화 데이터, 연동 환경과 통과 기준을 준비합니다.
• 2~3주 차: 정상·예외·장애 시나리오를 실행하고 증거 화면과 측정값을 저장합니다.
• 4주 차: 실패 항목의 개선 견적, 책임 주체와 본도입 조건을 확정합니다.
• 비용표: 첫해 구축비와 2·3년 차 반복 비용을 분리해 3년 총액을 표시합니다.
• 시간표: 내부 투입 시간을 역할별로 합산하고 기존 업무에 미칠 영향을 적습니다.
• 승인 조건: 중대 결함 0건, 필수 항목 통과율, 예산 상한과 목표 개시일을 명시합니다.

현실적인 최종안에는 숫자 네 개가 반드시 있어야 합니다. PoC 기간 4주, 내부 참여 인원 4명 안팎, 3년 총소유비용, 본도입 예상 기간입니다. 여기에 10~15%의 예비 예산과 데이터 정제·교육에 필요한 시간을 별도 표시하면 예상 밖의 추가 작업에도 대응하기 쉽습니다. 제한된 예산과 일정 안에서 좋은 선택을 만드는 기준은 가장 많은 기능이 아니라, 정해진 비용과 시간으로 핵심 업무를 안정적으로 수행한다는 검증 결과입니다.