기업 비즈니스 솔루션, 클라우드와 구축형 한 달 써봤더니

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

월요일 오전 9시, 외근 중인 영업팀이 계약서를 찾지 못하고 사무실의 담당자에게 전화를 겁니다. 같은 시간 재택근무자는 사내 서버 접속이 끊겼고, 관리자는 새로운 직원에게 어떤 권한을 줘야 할지 몰라 업무를 멈춥니다. 이런 장면이 반복되면 기업은 자연스럽게 클라우드형 기업 비즈니스 솔루션과 사내에 직접 설치하는 구축형 솔루션 사이에서 고민하게 됩니다.

두 방식을 한 달 동안 같은 업무 조건에 적용해 보니 승패는 단순하지 않았습니다. 클라우드는 빠르고 유연했지만 비용과 데이터 통제에서 질문이 남았고, 구축형은 세밀하게 통제할 수 있었지만 관리 부담이 예상보다 컸습니다. 중요한 것은 어느 제품이 더 유명한지가 아니라 우리 기업의 인원, 업무 방식, 보안 수준에 어느 운영 구조가 맞는가였습니다.

첫 주 대결: 당장 쓰는 클라우드 vs 준비해서 여는 구축형

클라우드는 계정을 만들자 바로 움직였습니다

첫 주에는 직원 25명이 문서 공유, 고객 요청 접수, 일정 관리, 전자결재를 처리한다는 조건으로 두 환경을 준비했습니다. 클라우드형은 관리자 계정을 개설하고 사용자를 초대한 뒤 부서별 권한을 나누는 데 반나절 정도가 걸렸습니다. 웹 브라우저와 모바일 앱을 이용하니 별도의 서버 구매 없이 외근자까지 같은 날 업무를 시작할 수 있었습니다.

구축형은 출발선부터 달랐습니다. 서버 용량을 산정하고 운영체제와 데이터베이스 환경을 결정한 뒤, 방화벽 정책과 사내 인증 체계를 점검해야 했습니다. 이미 서버와 전담 관리자가 있는 기업이라면 익숙한 과정이지만, IT 담당자가 총무 업무까지 겸하는 소규모 기업에서는 설치보다 내부 의사결정에 더 많은 시간이 들 수 있습니다. 첫 주의 속도만 보면 클라우드형 서비스가 확실히 우세했습니다.

다만 빠른 도입이 곧 올바른 도입은 아니었습니다. 계정을 급하게 만들다 보니 퇴사자 처리 기준, 외부 협력사 공유 범위, 관리자 권한의 보유자가 정해지지 않았습니다. 업무를 전자적으로 연결한다는 개념은 이비즈니스의 의미처럼 거래와 운영 방식 전체를 포함하므로, 도구만 열어 놓고 프로세스가 바뀌기를 기다려서는 부족합니다.

• 클라우드형 장점: 서버를 구매하지 않아도 빠르게 시작하고, 지점과 재택근무자에게 동일한 환경을 제공하기 쉽습니다.
• 클라우드형 주의점: 초기 설정이 쉬운 만큼 권한과 공유 정책을 임시 상태로 방치하기 쉽습니다.
• 구축형 장점: 사내 인증, 네트워크, 기존 데이터베이스에 맞춰 시작 단계부터 세밀하게 설계할 수 있습니다.
• 구축형 주의점: 설치 전 요구사항과 인프라 준비가 부족하면 개통 일정이 계속 밀릴 수 있습니다.

빠르게 접속할 수 있다는 것과 안전하게 운영할 수 있다는 것은 다른 문제입니다. 첫 로그인 전에 계정 생성·변경·회수 책임자를 먼저 정하는 편이 좋습니다.

둘째 주 대결: 매달 내는 구독료 vs 처음 크게 드는 구축비

보이는 가격보다 3년 총비용이 중요했습니다

클라우드형은 보통 사용자 수와 기능 등급에 따라 월 구독료가 늘어나는 구조입니다. 예를 들어 1인당 월 1만 원인 서비스를 30명이 이용하면 단순 구독료는 월 30만 원이며, 연간 360만 원이 됩니다. 여기에 전자서명, 고급 보안, 저장 공간 증설, 외부 시스템 연동 같은 옵션이 붙으면 실제 청구액은 달라집니다. 이 숫자는 특정 제품의 공식 가격이 아니라 예산 계산 방법을 보여 주기 위한 예시이므로, 도입 시점의 공급사 견적을 별도로 확인해야 합니다.

구축형은 서버, 데이터베이스 라이선스, 설치와 커스터마이징 비용이 초기에 집중됩니다. 겉으로는 월 사용료가 없어 장기적으로 저렴해 보이지만 하드웨어 교체, 백업 장비, 보안 업데이트, 장애 대응 인력까지 합치면 이야기가 달라집니다. 특히 담당자 한 명이 서버 운영에 매달 20시간을 쓴다면 그 인건비도 기업 솔루션의 총소유비용에 포함해야 합니다. 반대로 사용자 수가 수백 명으로 안정적이고 사내 인프라가 이미 갖춰져 있다면 구축형의 장기 비용이 더 예측 가능할 수 있습니다.

둘째 주에는 ‘어느 쪽이 싸다’보다 ‘어떤 비용이 숨어 있는가’를 찾는 데 집중했습니다. 클라우드는 퇴사자 계정을 제때 줄이지 않으면 사용하지 않는 구독료가 쌓였고, 구축형은 테스트 서버와 백업 회선 비용이 최초 견적에서 빠지기 쉬웠습니다. 기업 활동의 범위를 이해하려면 비즈니스 용어 설명도 참고할 만하지만, 실제 구매 판단에서는 회계상 비용뿐 아니라 업무 중단과 관리 시간까지 돈으로 환산해야 합니다.

예산표에는 다섯 줄을 더 넣어야 합니다

• 도입비: 설치, 데이터 이전, 교육, 초기 설정과 컨설팅 비용을 합산합니다.
• 운영비: 구독료 또는 유지보수료에 서버 전기료, 회선비, 관리자 인건비를 더합니다.
• 확장비: 직원 20명 증가, 저장 공간 두 배 확대, 지점 추가 상황을 각각 계산합니다.
• 전환비: 계약 종료 시 데이터 추출, 파일 형식 변환, 새 솔루션 교육 비용을 반영합니다.
• 중단비: 한 시간 동안 영업·물류·고객지원이 멈췄을 때 발생할 손실을 추정합니다.

비용 대결의 판정 기준은 회사의 성장 속도에 따라 달랐습니다. 인원이 자주 바뀌는 조직은 계정을 늘리고 줄일 수 있는 클라우드가 유리했고, 사용자 수와 프로세스가 장기간 고정된 조직은 구축형을 검토할 근거가 생겼습니다. 계약 기간만 보고 계산하지 말고 1년, 3년, 5년 시나리오를 나란히 놓으면 가격 역전 시점과 위험 구간이 훨씬 선명해집니다.

셋째 주 대결: 공급사가 지키는 보안 vs 회사가 쥐는 통제권

클라우드라고 자동으로 안전하거나 위험하지는 않습니다

셋째 주에는 고객 연락처, 견적서, 인사 문서처럼 민감도가 다른 데이터를 구분해 접근 권한을 시험했습니다. 클라우드형은 다중 인증, 접속 기록, 기기 제한 같은 기능을 관리 화면에서 적용하기 편했습니다. 그러나 기능이 제공된다는 사실과 실제로 켜져 있다는 사실은 다릅니다. 관리자 한 명이 모든 권한을 갖고 공동 계정까지 사용한다면 좋은 보안 기능도 효력을 발휘하기 어렵습니다.

구축형은 데이터가 사내 환경에 머물고 네트워크 접근 경로를 직접 결정할 수 있다는 점이 강했습니다. 특정 부서의 시스템을 외부 인터넷과 분리하거나 회사의 인증 정책과 촘촘하게 연결하기도 좋았습니다. 하지만 패치가 늦고 백업본이 같은 서버실에만 있다면 ‘직접 통제’가 오히려 약점이 됩니다. 구축형의 보안 수준은 장비의 위치가 아니라 운영 역량에 의해 결정됩니다.

두 방식 모두 공급사의 보안 인증, 데이터 저장 위치, 암호화 범위, 장애 대응 절차를 문서로 확인해야 했습니다. 클라우드는 계약 종료 후 데이터가 언제 삭제되는지, 백업본까지 제거되는지 질문해야 합니다. 구축형은 패치 책임이 공급사와 내부 담당자 중 누구에게 있는지, 원격 유지보수 접속이 언제 열리는지 명확히 해야 합니다. 여러분의 회사는 보안 사고가 났을 때 로그를 누가 확인하고 몇 시간 안에 보고할 수 있습니까?

실무 보안 항목을 맞대어 보니

• 관리자와 일반 사용자의 계정을 분리하고 다중 인증을 적용합니다.
• 부서 이동·휴직·퇴사 시 권한을 회수하는 처리 시간을 정합니다.
• 랜섬웨어를 가정해 운영 데이터와 분리된 백업본의 복구를 시험합니다.
• 파일 다운로드, 외부 공유, 대량 조회 기록을 얼마나 보관하는지 확인합니다.
• 계약서에 사고 통지, 데이터 반환, 삭제 증빙 절차가 있는지 살핍니다.

민감한 데이터는 ‘클라우드냐 구축형이냐’ 한 문장으로 보호되지 않습니다. 데이터 등급, 접근자, 보관 기간, 복구 책임을 한 표에 놓아야 실제 통제 수준이 보입니다.

넷째 주 대결: 표준 기능의 속도 vs 맞춤 개발의 정밀함

직원이 매일 만나는 화면에서 차이가 벌어졌습니다

넷째 주에는 영업 담당자가 고객 문의를 등록하고, 팀장이 견적을 승인하며, 회계 담당자가 매출 자료를 넘겨받는 흐름을 반복했습니다. 클라우드형은 준비된 양식과 자동 알림을 곧바로 사용할 수 있어 표준 프로세스를 정착시키는 속도가 빨랐습니다. 모바일 승인도 수월해 출장 중 결재가 멈추는 상황이 줄었습니다. 업무 절차가 일반적인 기업이라면 기본 기능만으로도 상당한 개선을 얻을 수 있었습니다.

하지만 기존 화면과 용어를 그대로 유지하려는 요구가 늘자 제약이 나타났습니다. 필드 이름은 바꿀 수 있어도 승인 로직이나 데이터 구조는 공급사가 허용한 범위 안에서만 수정할 수 있었습니다. 반면 구축형은 오래된 생산관리 시스템과 전용 장비 데이터를 연결하고, 부서 고유의 계산식을 화면에 넣는 데 유리했습니다. 문제는 맞춤 기능 하나를 추가할 때마다 테스트와 문서화, 향후 업그레이드 검토가 따라온다는 점이었습니다.

전자적 거래와 업무의 확장 개념은 business 관련 용어 자료처럼 폭넓게 쓰이지만, 현장에서는 클릭 수와 입력 중복이 만족도를 좌우합니다. 직원이 고객명을 세 번 입력하거나 엑셀로 다시 옮겨야 한다면 거창한 디지털 전환보다 작은 연동 하나가 더 가치 있습니다. 기업 맞춤형 비즈니스 솔루션은 무조건 많이 개발하는 제품이 아니라, 차별화되는 업무만 맞춤화하고 나머지는 표준화하는 서비스에 가깝습니다.

맞춤화 요청은 세 등급으로 나눴습니다

1. 즉시 설정: 사용자 권한, 알림 시점, 양식 항목처럼 관리자 화면에서 바꿀 수 있는 요구입니다. 클라우드와 구축형 모두 비교적 빠르게 처리할 수 있습니다.
2. 연동 개발: 회계, 고객관리, 쇼핑몰, 생산관리 시스템 사이에서 데이터를 주고받는 요구입니다. API 제공 범위와 호출량 제한, 오류 재처리 방법을 함께 확인해야 합니다.
3. 핵심 로직 변경: 회사 고유의 가격 계산이나 다단계 승인처럼 제품 구조를 건드리는 요구입니다. 구축형이 유리할 가능성이 크지만 업그레이드 비용까지 승인받아야 합니다.

현장 투표에서는 흥미로운 차이가 나왔습니다. 경영진은 맞춤 보고서를 선호했고, 실무자는 검색 속도와 모바일 접근, 입력 항목 감소를 더 중요하게 봤습니다. 그래서 데모를 볼 때 관리자만 참석시키지 않고 실제 사용자에게 ‘고객 한 건 등록하기’, ‘지난 계약 찾기’, ‘휴대전화로 승인하기’를 수행하게 했습니다. 기능 목록의 체크 표시보다 업무 한 건을 끝내는 시간을 재는 편이 두 선택지의 생산성 차이를 정확하게 드러냈습니다.

다음 분기에는 승자가 바뀔 수 있는 운영 조건

한 달의 선택을 고정된 판결로 만들지 않았습니다

한 달 사용 결과, 빠른 개통과 장소 제약 없는 협업이 필요한 팀에는 클라우드형이 앞섰습니다. 반면 외부 연결을 제한해야 하거나 독자적인 업무 로직과 사내 시스템 연동이 핵심인 조직에서는 구축형이 강했습니다. 어느 쪽이든 모든 부서를 한 번에 옮기기보다 영향이 작은 팀에서 시험 운영하고, 실제 처리 시간과 문의 건수, 오류율을 기록하는 방식이 안전했습니다.

도입 후에는 사용률만 보지 말아야 합니다. 로그인 횟수가 많아도 직원이 엑셀에 똑같은 내용을 다시 입력한다면 개선 효과가 낮습니다. 반대로 접속 횟수는 적어도 승인 대기 시간이 이틀에서 두 시간으로 줄었다면 충분한 가치가 있습니다. TS컴퍼니 같은 종합 비즈니스 솔루션 서비스를 검토할 때도 제품 소개 화면보다 문제 정의, 운영 책임, 성과 측정 방법을 먼저 요청하는 것이 좋습니다.

최종 후보를 고른 뒤에는 30일 단위로 다음 항목을 측정해 보세요. 수치가 기대에 못 미치면 교육 문제인지, 설정 문제인지, 제품 구조의 한계인지 구분해야 합니다. 이 과정이 있어야 클라우드에서 구축형으로, 또는 구축형에서 클라우드로 성급하게 갈아타는 비용을 줄일 수 있습니다.

변화 시점을 알려 주는 운영 신호

• 인원 변화: 채용이나 조직 개편으로 사용자 수가 20% 이상 변하면 구독 등급과 서버 용량을 다시 계산합니다.
• 업무 변화: 신규 지점, 해외 거래, 새로운 판매 채널이 생기면 접속 지역과 연동 범위를 재검토합니다.
• 비용 변화: 클라우드 요금제, 환율, 저장 공간 사용량, 유지보수 계약 조건이 바뀌면 3년 총비용표를 갱신합니다.
• 보안 변화: 다루는 개인정보나 영업기밀의 민감도가 높아지면 인증, 로그, 백업과 데이터 저장 위치를 다시 평가합니다.
• 기술 변화: 공급사의 API 정책, 지원 브라우저, 서버 운영체제 지원 종료 일정이 바뀌면 전환 계획을 앞당깁니다.

특히 가격표와 제품 기능, 보안 인증, 관련 규정은 시간이 지나며 달라질 수 있습니다. 지금의 승자를 영구적인 표준으로 정하지 말고 분기마다 비용, 사용자 경험, 장애 복구 시간, 공급사 정책을 다시 확인해야 합니다. 오늘은 클라우드가 효율적이던 기업도 데이터 규모와 규제 요건이 달라지면 구축형이나 혼합 구조가 적합해질 수 있고, 반대의 변화도 충분히 가능합니다.