기업용클라우드 가상서버를 활용한 자동화 수익 구축 비용 절감법

기업용클라우드 도입을 검토할 때 흔히 저지르는 오버스펙의 오류

처음 자동화 파이프라인을 구축해 수익을 내겠다는 계획을 세우면 대다수 직장인이나 1인 사업가는 과한 인프라부터 계약하곤 한다. 대기업들이 쓰는 대규모 기업용클라우드 서비스 스펙을 그대로 모방하여 초기 세팅 단계부터 필요 이상의 리소스를 확보하기 때문이다. 하지만 고성능 가상서버를 사용한다고 해서 자동화 프로그램이 갑자기 더 높은 가치를 만들어내지는 않는다. 오히려 매달 청구되는 카드 명세서의 고정 지출만 늘리는 결과로 이어진다.

가장 대표적인 실수는 연산 성능이 과도하게 높은 가상서버 요금제를 무턱대고 구독하는 일이다. 단순한 웹 크롤러나 데이터 파싱 프로그램은 메모리 2기가바이트 미만의 사양에서도 끊김 없이 돌아간다. 그럼에도 불구하고 초기 설치 단계부터 월 10만 원이 훌쩍 넘는 엔터프라이즈급 상품을 결제하는 사례가 빈번하다. 인프라 비용이 커지면 손익분기점을 넘기는 시점이 늦어지고 프로젝트의 유지 동력 자체가 떨어진다.

여기에 보안을 강화하겠다고 UTM장비 가상화 옵션이나 고가의 안티바이러스 솔루션까지 추가하면 고정 비용은 두 배로 뛴다. 물론 보안이 중요하지 않다는 뜻은 아니다. 다만 필요한 수준의 가용성은 개별 비즈니스의 규모에 맞추어 점진적으로 늘려가야 마땅하다. 쓸데없는 리소스를 비워두는 것은 디지털 공간에서 매달 빈 사무실 월세를 내는 행위와 다를 바 없다.

자체 구축 가상서버와 서비스형 클라우드 플랫폼의 비용 대비 생산성 비교

수익형 자동화 도구를 얹을 인프라를 결정할 때는 직접 구축하는 방식과 완성된 SaaS 형태를 활용하는 방식을 두고 치열하게 고민해야 한다. 전자는 AWS EC2나 케이티클라우드 같은 가상서버 환경에 직접 운영체제를 설치하고 자동화 코드를 구동하는 형태를 말한다. 후자는 이미 세팅된 업무 협업 툴이나 자동화 전용 웹 서비스를 월 구독료만 내고 쓰는 방식이다. 두 가지 방식은 자유도와 초기 세팅 리소스 측면에서 극단적인 차이를 보이기 마련이다.

가상서버 구축은 초기 세팅에 최소 3일 이상의 시간이 소요되지만 고정 비용 측면에서 장기적으로 유리하다. 예를 들어 t3.medium 인스턴스를 활용하면 월 3만 원 수준의 금액으로 24시간 내내 작동하는 독립적인 비즈니스 봇을 운영할 수 있다. 운영체제 레벨에서 사용자가 원하는 어떤 스크립트든 설치해 구동할 수 있다는 강력한 이점도 존재한다. 반면 서버 운영에 필요한 포트 설정, 방화벽 관리, 정기 패치 작업을 오롯이 본인이 책임져야 한다는 단점이 명확하다.

이와 달리 완성형 플랫폼을 이용하면 마우스 클릭 몇 번으로 자동화 연동이 끝난다. 개발 지식이 없는 초보자도 1시간 만에 원하는 업무 흐름을 만들 수 있어 초기 진입 장벽이 낮다. 하지만 서비스 제공업체의 요금 정책에 따라 가공 데이터의 건당 추가 비용이 발생하거나 서비스 연동 개수에 제한을 받는다. 누적 처리 데이터가 많아질수록 비용 상승 곡선이 가파르게 올라가 장기적인 수익 모델 설계에 불리하게 작용하기도 한다.

따라서 장기적으로 안정적인 마진을 남기려면 초기에 다소 노력이 들더라도 기업용클라우드 환경 위에 가상서버를 하나 띄우고 직접 코드를 돌리는 편이 훨씬 이득이다. 관리 부담을 덜고자 완제품 플랫폼을 선택했다가 나중에 비즈니스 규모가 커졌을 때 이관하는 비용이 더 크게 다가오는 사례가 수두룩하다. 개발의 난이도와 예상되는 데이터의 총량을 비교해보고 최적의 접점을 찾는 판단이 요구된다.

기업용클라우드 기반의 무인 자동화 파이프라인을 구축하는 4단계 프로세스

자동으로 작동하며 소소한 이익을 가져다주는 백엔드 시스템을 만들기 위해서는 단계적인 접근이 필수적이다. 무턱대고 코드부터 짜기 시작하면 환경 설정 오류와 네트워크 차단으로 도중에 포기하기 쉽다. 다음의 4단계 과정을 거치면 안정적으로 24시간 작동하는 인프라를 갖추게 된다.

첫째, 적절한 사양의 가상머신 인스턴스를 고르고 초기 환경을 설정한다. 굳이 비싼 기업용클라우드 사양을 고집하지 말고 리눅스 우분투 환경을 기본으로 선택하는 것이 무난하다. 최초 기동 후에는 터미널에 접속하여 시스템 패키지를 최신 상태로 업데이트하고 방화벽 포트 22번과 443번만 열어두는 보안 처리를 마친다. 불필요한 포트를 열어두면 얼마 못 가 해외 악성 IP의 표적이 되어 해킹을 당하기 쉽다.

둘째, 자동화 로직을 실행할 런타임 환경을 구축하고 소스 코드를 동기화한다. 파이썬이나 노드제이에스 등 주로 다루는 개발 언어의 패키지 관리자를 설치한 뒤 깃허브 저장소를 통해 개발한 코드를 동기화한다. 이 과정에서 라이브러리 간 충돌을 방지하기 위해 가상 환경을 따로 만들어 구동하는 방법을 권장한다. 로컬 PC에서 정상 작동하던 코드가 리눅스 서버에서 작동하지 않는 현상을 방지하는 첫걸음이다.

셋째, 백그라운드에서 상시 실행될 수 있도록 프로세스 관리 도구를 연동한다. 사용자가 터미널 연결을 종료해도 프로그램이 멈추지 않아야 하므로 PM2 같은 라이브러리를 사용해 무중단 서비스를 등록해야 한다. 만약의 사태로 서버가 재부팅되더라도 자동으로 해당 프로그램이 다시 켜지도록 데몬에 등록해두는 설정까지 마쳐야 온전한 무인 가동이 이루어진다.

넷째, 일정 주기로 반복 실행할 수 있도록 시간 단위의 크론잡 스케줄러를 세팅한다. 특정 시간대에 포스팅을 하거나 데이터 수집을 원한다면 리눅스의 기본 기능인 crontab 기능을 활용하면 된다. 30분 간격 혹은 특정 시점의 주기 설정을 완료한 뒤 로그 파일이 정상적으로 쌓이는지 테스트하는 단계까지 거치면 모든 프로세스가 마무리된다.

기업용클라우드 도입 시 예산 낭비를 막는 기본 체크리스트와 가상서버 청구 기준

어떤 서비스를 선택하느냐에 따라 월말에 날아오는 인보이스의 숫자가 달라진다. 클라우드는 가동 시간만큼 요금을 지불하는 구조를 가지고 있기에 사용자가 모르는 사이에 지출이 누적될 위험이 있다. 서비스 이용을 확정하기 전에 사전에 작성해두고 비교해봐야 할 핵심 사항들은 다음과 같다.

먼저 요금 청구 방식과 비용 한계점을 확인해야 한다. 아래의 체크리스트 항목을 꼼꼼하게 대입해 보면 초기 설정 비용의 40퍼센트 이상을 덜어내는 결과를 얻을 수도 있다.
– 데이터 전송 아웃바운드 트래픽당 추가 단가 확인
– 서버 인스턴스 미사용 시 정지 모드 적용 가능 여부
– 기본 탑재되는 백업 스토리지의 기본 용량 제공 크기
– 공인 IP 할당 시 추가되는 개별 고정 비용 유무

대개 트래픽 비용을 간과했다가 낭패를 보는 경우가 잦다. 일반적인 데이터 수집 파이프라인은 업로드하는 트래픽이 많아 외부로 나가는 데이터 양에 따라 가산되는 요금을 주의 깊게 관찰해야 한다. 기가바이트당 약 120원 수준의 단가를 무시하고 과도한 멀티스레드 크롤링을 구동하다가는 생각지 못한 트래픽 요금 폭탄을 맞이하게 된다.

국내 클라우드 서비스 기업들의 경우 중소기업이나 예비 창업자 대상의 바우처 사업을 연중 상시로 운영하고 있다. 이러한 정책 자금 신청을 이용하면 최대 70퍼센트까지의 요금 감면 혜택을 1년 내내 누리는 것도 가능하다. 사업자등록증과 사업 계획안을 마련하여 클라우드 서비스 공식 대리점이나 정보통신산업진흥원 홈페이지의 공고를 수시로 모니터링하며 신청 기회를 노릴 필요가 있다.

리소스 낭비를 막기 위한 모니터링 도구와 자동화 스크립트 활용 방안

매 순간마다 클라우드 관리 콘솔에 들어가 자원 사용량을 들여다볼 수는 없는 노릇이다. 이를 방치하면 가끔 오작동하는 프로세스가 가상서버 CPU 사용률을 100퍼센트 점유하여 과열되거나 막대한 시스템 부하를 불러온다. 따라서 자체적인 감시 시스템과 한계 수치 도달 시 스스로 인스턴스를 재부팅하는 쉘 스크립트를 심어두는 기법이 유용하게 쓰인다.

필자의 경우 매 정각 서버의 상태를 분석하여 메모리 점유율이 85퍼센트를 초과할 경우 내부의 캐시를 비우고 특정 데몬 프로세스를 재시작하는 가벼운 스크립트를 작성하여 스케줄러에 등록해두었다. 15줄 정도의 짧은 Bash 쉘 스크립트 작성만으로도 서비스 다운에 따른 매출 손실을 90퍼센트 이상 예방하는 성과를 거두었다. 이러한 가벼운 코드가 복잡한 모니터링 솔루션보다 1인 자동수익 모델에는 훨씬 직관적이고 다루기 쉽다.

여기에 더해 트래픽 사용량이 한계점을 초과했을 때 등록된 번호로 문자를 발송해주는 API 연동 알림 설정도 유용하다. 이를 위해 무료 등급을 제공하는 텔레그램 봇 API를 활용하면 모바일 메신저를 통해 이상 상황을 즉각 파악하여 빠른 대처가 가능해진다. 알림 메타데이터에는 서버의 현재 가용 용량과 활성화된 프로세스 리스트를 출력하도록 스크립트를 연동해두는 것이 현명하다.

서버 기반 자동화가 비즈니스 모델로 작동하기 어려운 예외 조건

클라우드를 이용한 자동화 수익 파이프라인은 누구나 시도해 볼 만한 가치가 있지만 만능 해결책은 아니다. 외부 웹사이트의 구조가 예고 없이 변경되는 등 동적 환경 변화가 극심한 영역에서는 유지보수 비용이 지나치게 커진다. 변화가 발생할 때마다 사람이 수동으로 소스코드를 고치고 디버깅을 진행해야 하는데 이는 노동 시간 증가로 이어지며 결국 수동 부업과 큰 차이가 없는 상황을 야기한다.

본업이 바빠 실시간 이슈 대응이 완전히 불가능한 직장인이라면 차라리 대형 플랫폼의 기존 유료 솔루션을 활용하는 방향을 추천한다. 이관 비용과 스크립트 제어를 전적으로 도맡아 할 리소스가 없기 때문에 초반 요금이 비싸더라도 관리 소요를 최소화하는 편이 차라리 낫다. 반대로 독자적인 아이디어를 보유하고 있으며 기술적 시행착오를 일정 수준 극복해낼 의지가 있는 이들에게는 가상서버를 이용한 파이프라인 구축이 확실한 레버리지 수단이 된다.

이 글을 읽은 독자가 가장 먼저 해야 할 일은 본인이 자동화하려는 업무의 외부 종속성이 얼마나 심한지 평가해보는 일이다. 수집하려는 타깃 웹사이트의 보안 정책이나 로그인이 필요한 수준을 분석해보는 것부터 준비해야 한다. 만약 보안 장벽이 너무 높다면 기업용클라우드 구축을 시작하기도 전에 비즈니스 모델 자체가 기각될 수도 있으므로 초기 기획 단계에서의 실증이 무엇보다 무겁게 다뤄져야 한다.