티스토리 뷰

클라우드 성공만 이야기 하는데, 경제성도 그만큼 받쳐 줄 것인가?

오늘은 정말 간만에 지인님들께 그 동안의 제 소식도 알리고 새해 인사도 드릴 겸 해서 포스팅 하나 올려봅니다.

간만에 새해 인사 한다더니 갑자기 왠? 클라우드 이야기냐? 라고 생각하는 분들이 있으실 텐데요. 최근 저희 회사 상황과 연관이 돼 있어서 겸사 겸사해서 이야기 드려 볼려고 합니다.

어설프군 YB의 그 동안 토막 소식?
11월 중순부터였던 것 같은데요. 저희 회사에서 운영하던 아이엠데이(모바일 어플리케이션 소개 소셜 서비스)에 여러 문제점이 발견 돼 새롭게 부분 리뉴얼을 진행하게 되었습니다. 처음엔 가볍게 로직 수정과 서버의 기능 점검 수준으로 생각하고 12월초 오픈 하려고 했었습니다.

그런데 건들기 시작하다 보니 초창기 개발 당시에는 보이지 않았던 것들이 눈에 보이기 시작해서 조금씩 조금씩 리뉴얼 범위를 넓혀지다 결국에는 서비스를 거의 80%이상 다시 설계하고 거의 새로 만드는 수준이 된 겁니다.

기존 서비스에서 가져다 쓰는 건 그동안 쌓아놨던 컨텐츠 빼곤 없다고 봐도 무방 할 정도인 것이지요. 아래 이미지는 변화 될 아이엠데이의 모습입니다. ㅎㅎ

<화면을 클릭하면 좀 더 큰 화면을 볼 수 있습니다>


조그만 서비스 뭐가 그렇게 개발 할 것이 많았나?
기존에 저희가 만들던 서비스를 보신 분들은 아시겠지만 사실 웹사이트만 봐서는 별 것 없는 서비스라고 보신 분들이 많으실 겁니다. 하지만 그 작은 웹사이트 구축과 운영을 위해서 서비스 뒤에서 동작하는 서버만 12대에 달합니다. (그것도 사실 3대 고장나서 폐기처분 했으니 15대로 시작한 것이지요.)

큰 서비스들에 비하면 보잘 것 없지만 저희 회사 수준에서 생각한다면 좀 무리한 시작이라고 보셔도 될 것 같습니다. 이런 서버들을 각각 로드밸런서, 웹서버, 어플리케이션 서버, DB 서버, 메일서버 등으로 세분화 시킵니다. 물론 더 큰 서비스들은 로드밸런스 뒤에 프록시를 두고 다시 로드밸런싱 시켜 실제 컨텐이너겸 어플리케이션 서버에 접근시키죠.

여기에 방화벽, 스토리지.. 등 기본 인프라 구축과 투자의 범위를 생각하면 사실 저희가 시작한 수준도 그리 큰 수준은 아닙니다.



일본의 하테나의 경우 300대의 서버로 (이것도 사실 몇 년전 기준입니다.) 일간 1000만명이 넘는 사용자에 대응한다고 합니다. 아시는 분들은 아시겠지만 이거 어머어마한 것이고 서버 튜닝과 설계에서 대단한 기술력을 갖추지 않고선 불가능한 것이지요.

그런데 저희 같은 작은 서비스도 각 서버간 모듈 체크와 헬스체킹, 이중화 각 노드단에 방화벽 세팅.. 이루 말할 수 없을 만큼 많은 작업이 들어갑니다. 그리고 그 기반 아래 웹페이지를 구축하고 이렇게 구축 된 서비스에 컨텐츠를 수집하고 노출하는 것이 웹서비스의 근간인데 생각 이상 작업량이 많습니다. (누군가 웹 개발과 인프라 개발자를 무시하는데 개인적으로 시스템 개발이나 하드웨어 기반 엔지니어보다 못하다고 보는 건 말이 안되는 것 같습니다… ㅡㅡ;)

그냥 블로그 하나 운영하는 것과는 차이가 있고 아주 어줍잖은 서비스라도 이 구성 뒷면을 보시면 웹서비스 구축과 운영이 그리 쉬운 것은 아니란 것을 아실 수 있게 됩니다.


그런데 왜 이렇게 오랜 시간이 걸렸나?
저희가 작은 벤처라 사실 체계가 많이 부족했습니다. 사회 경험이 있어서 일정 규모의 시스템도 경험해 봤지만, 작은 벤처에 적용하기 어려웠던 부분도 많아서 그때 그때 임기응변 식으로 하다 보니 제대로 시스템을 만들지 못했던 부분이 많았습니다.

예를 들면 저희 서버가 처음엔 개발 환경과 서비스 환경에 대한 생각 없이 모든 서버를 Centos 기반으로 구축했었습니다.

하지만 개발자의 개발 환경이 우분투 데스크탑 환경이라 (이 부분은 기회가 되면 설명 드리겠지만 제대로 구축만 하면 개발하기 무지 편한 환경이더군요) centos와 개발 환경이 차이가 많이 발생해서 라이브러리나 개발 서버 모듈의 버전차이가 발생해 개발 컴퓨터에선 잘 돌아가던 것이 서버에서 동작 안 하는 상황도 많이 발견되고 그랬습니다.

물론 우분투 서버로 구축했다고 모든 것이 해결 된 것은 아닙니다. 하지만 여러가지 면에서 개발 환경과 서비스 환경을 우분투로 통일하면서 여러 장점이 많이 발생해 시너지가 있다고 생각됩니다.

이런 것처럼 체계가 안 잡혔던 부분을 개발하며 조율하고 개선하면서 전진하는 것은 물론 웹 서비스 측면에서 사용성과 기본적인 모티베이션 차원의 문제를 근원적으로 찾다 보니 개발하는데 시간이 많이 걸리게 된 것이죠.

서두가 길었지만 암튼 처음부터 원점에서 서비스를 다시 고민하다 보니 늦었다고 보시면 됩니다.


그렇다면 왜? 클라우드 이야기를 했나?
이 부분에서 신생 스타트업이나 벤처들이 많이 생각해봐야 할 부분이 있어서 이야기를 겸사겸사 던지게 된 것인데요. 지금부턴 안부가 아니라 좀 더 근원적인 벤처인의 입장에서 말씀 드려 보겠습니다.

저희는 서비스 초기 멋모르고 어느정도 틀을 잡고 가겠다는 생각에 서버를 구매하고 IDC에 입주해 코로케이션 서비스를 받고 있습니다. 그런데 신생 벤처는 투자를 받았더라도 여러가지 상황에서 이 비들을 세이브하며 가야 합니다. (물론 저희은 투자 없이 스스로 제살 깍아먹으며 버티고 있습니다.)

실리콘 밸리 기준으로 벤처가 성공하려면 평균 4.5년이 걸립니다. 트위터가 이름을 본격적으로 날리는데 4~5년이 걸렸고, 구글을 비롯해 대다수 기업들이 최소 2~3년, 많게는 6~7년 걸려서 이름을 알리기 시작하죠. 이것 조차 성공 확률이 1%를 넘지 않고요.

그런데 아무리 좋은 엔젤이나 벤처캐피탈을 만났더라도 이런 긴 시간을 기다리긴 참 쉽지 않습니다. 특히나 회원이든 트래픽이든 지속 성장이 담보되지 않은 상황에서 그 시간을 버티는 것은 불가능에 가까울 수 있습니다.

그런데 인프라는 잘 구축해 놓으면 나중에 서비스가 제대로 동작하고 회원이 늘어났을 땐 큰 힘을 발휘하지만 이게 고정 비용으로 잡혀 있어서 투자 초기엔 오히려 큰 짐으로 다가 옵니다.

인원이 작아서 24시간 완벽 모니터링 체계를 구축하고 문제 발생시 대처하기도 어렵습니다. 때에 따라선 문제 발생 후 한참이 지나서야 발견하고 대처하는 경우도 있으니 말입니다.

또, 비용적인 측면에서도 상면비와 회선비를 생각 할 때 결코 만만하지 않더군요. 그러다 최근 엔터프라이즈 기반 클라우드 서비스가 나왔습니다.



대표적인 서비스가 아마존의 EC2나 구글 APPS, 한국엔 KT U클라우드 등이 바로 그런 서비스라고 할 수 있습니다.

물론 전체 비용을 따져야 하지만 초기에 3~4대(웹2~3, DB1대 – 로드밸런스는 별도제공)을 이용하고 최대 이용 트래픽을 적절히 조정하면 한달에 1~20만원 수준에서 클라우드 서비스 이용이 가능 할 것 같다는 생각이 들었습니다. (계약 내용에 따라서 더 줄어들 수도 있습니다.)

지금 저희가 이용하는 비용은 이보다 더 많이 지불하고 있고, 트래픽이나 서버 용량과 이용 대수등을 조절하면 충분히 초기 시장 안착과 운영에 큰 부담 없이 서비스 개발과 운영이 가능하지 않을까 생각되더군요.

아무리 작은 회사라도 기본적으로 사무실 임대로, 통신비, 관리비(일반 관리비, 전기, 수도세, 일반 과세.. 등), 인건비가 고정입니다. 여기에 서버라도 있으면 회선비, 상면비가 들고 서버 관련해서는 인건비도 별도로 산출해야 하기에 전체적인 비용을 계산하면 꽤 큰 돈이 들게 되죠.

정말 먹고 쓰지도 못하고 일정 돈 나가니 죽을 맛일 때가 많습니다.


왜? 초기 시장에서 클라우드가 유리 할까?
우선 트래픽이나 서버 가용성 등에서 유리합니다. 초기에 계획대로 잘 맞아 트래픽과 회원 가입이 폭증하면 모르겠지만 대부분의 서비스는 초기에 그렇게 성공하기 힘듭니다. 이렇게 성공하는 서비스는 1%를 채 넘지 못한다는 통계가 있습니다.

그런 상황에서 저희 같이 회선과 상면, 서버를 통해 고정비가 나가는데 실제 트래픽은 계약한 서비스에 비해 턱없이 부족할 때 이를 얼마든지 유동적으로 조절 할 수 있게 되는 것이죠.

트래픽이 갑자기 급증하면 계약시 트래픽 급증에 따른 유동적 측면을 고려해 계약하거나 급한 상황에서 웹서버를 일시적으로 늘리거나 스토리지를 늘릴 수 있습니다. 물론 다시 서비스 트래픽이 하락하면 서비스에서 제외해 비용과 운영적 측면을 탄력적으로 조절 할 수 있습니다.




아직 한국에서는 시장 초기지만 미국 같은 경우 이미 일반화 되어 있고 이미 아마존 같은 경우 더 이상 유통 사업자가 아닌 플랫폼 사업자로 전환 된 것으로 보면 이미 꽤 의미 있는 발전을 기록하고 있다는 것일 알 수 있죠.

당연히 서비스 검증도 끝났고요. 이런 점을 생각해 보면 저희가 초기에 너무 이런 부분을 생각하지 못해 많은 비용을 지불하고 IDC 계약 내용 만큼 이용도 못하는 ..등, 많은 후회가 남더군요. 서비스 비용만 세이브 했어도 몇 달을 더 버틸 수 있는 여력이 생기니 말입니다.


아이엠데이는 어떤 부분 때문에 클라우드에 관심 갖게 됐나?
가장 큰 부분이 얼마 안 되는 인력으로 서버를 유지보수하고 이를 관리해야 한다는 부담이 었습니다. 예를들면 트래픽이 몰리면 웹서버나 DB 서버등을 강화해야 하는데 이런 부분이 유동적이지 못했지요.

서버를 구매하거나 기존에 놀고 있는 서버를 IDC에 가서 급하게 세팅을 바꿔서 웹으로 전환하거나 DB로 전환해야 하는데 세팅 시간, 인건비, 공간 제약은 물론 서비스 대응에서 문제가 되었습니다.

이번에 서비스 개편에서도 이런 부분이 크게 도드라지게 느껴졌습니다. 만약 클라우드를 이용했다면 IDC 방문 없이 버튼 몇번만 이용하고 가격 계산만 하는 것으로 서버 구축이 끝나고 세팅만 진행하면 됐을 텐데 서버 세팅하는데만 2주 가까운 시간을 보낸 점을 생각하면 신생 벤처에겐 인프라 구축이 꼭 득이 된다고 생각하기 어려운 시간이었고…

이런 부분을 절실하게 느꼈습니다.

그리고 비용적인 측면입니다. IDC 계약을 해보신 분은 알겠지만 상면에 따라 회선 비용을 탄력적으로 조정하기 어려운 부분이 많습니다. 저희도 가장 저렴한 수준에서 이용하고 일부 서버는 후배 도움으로 돈들이지 않고 이용하고 있지만 고정비로 월간 지출되는 비용이 감당하기 버거운 부분도 있습니다.

그런데 저희가 초기 고려했던 것보다 이용자가 많지 않았고 지금 같이 서비스 개발로 서버를 내려야 하는 상황 (서버를 내리면 안되지만 그럴만한 사정이 있었습니다. 기회 되면 소개하지요)이라서 근 1달 가까운 기간 비용을 날린 것입니다.

<KT U클라우드 가격표 참조>

이거 상당히 크거든요. ㅠㅠ 그런데 유지하면서 개발하기 힘든 여건도 있어고 여러 이유가 맞물려서 어쩔 수 없는 결정을 하게 된 것입니다. 만약 클라우드 였다면 서버 내린 기간 웹서버 한대만 동작시키고 테스트 서버 이외엔 모두 서비스를 제외해 비용을 세이브 했을텐데 아쉬움이 많이 남았고 서비스 초기 지혜롭지 못해 큰 부담을 앉고 가는 지금 현 상황이 다소 답답하게 느껴지기도 했습니다.


클라우드 실제 적용한다면 얼마나 들까?
아마존은 물론 한국에도 여러 서비스가 있고 KT도 공격적으로 U클라우드를 제공하고 있습니다. 가격은 모두 천차만별입니다. 아마존은 원격으로 이용하고 카드 결제가 되기 때문에 미국 서비스를 선택하고 한국에서 세팅해서 이용 가능합니다.

그래도 급한 문제가 생겼을 때 직접 전화를 해야 하는 상황을 고려하면 KT 같은 국내 서비스도 좋은 대안일 수 있습니다. 월 요금은 스토리지 서비스, 웹서비스, DB 서비스등 각 서비스마다 차이가 발생하는데 용량별, 전송료당 가격등을 생각하면 적개는 단위당 몇십원에서 1~200원 수준으로 책정 가능합니다.

또, 관제 서비스 추가를 하냐 안하냐에 따라 비용도 틀리고 자사 서버를 입주시키는 형태냐 모든 서버를 KT에서 제공 받냐에 따라 조금씩 서비스 계약 방향이 다르더군요.

아마존의 경우는 워낙 사례가 많아서 찾아보시면 되고, 전 영어가 딸려서 국내 서비스를 중심으로 알아보니 KT가 소개하는 관련 정보를 보니깐 유클라우드의 경우 유휴 트래픽 비용과 서버 임대료의 절감등을 보면 보통 20~50% 가까운 비용 절감 효과가 있었다고 하더군요.

<KT 유클라우드 자료 참조>

예를들면 서버 9대를 이용하고 트래픽량에의해 월간 4~500만원 비용이 들었는데 특정 트래픽 구간이 증가하는 시간대만 서버와 회선 용량을 늘리는 계약등을 하고 그렇지 않은 시간대는 서비스를 제안하는 형태로 50% 이상 세이브가 가능했다고 하네요.

저희 같은 경우 그럴 경우 20만원대까지 떨어질 것 같더군요.


신생 벤처들 앞으로 어떻게 하는 것이 좋을까?
뭐 제가 영업하는 사람은 아주 서비스 내부적인 요소를 구체적으로 설명하기는 좀 뭐하고 가격이나 서비스는 아마존, 유클라우드, 호스트웨어.. 등을 찾아보시길 바랍니다. 국내에선 개인적으로 유클라우드가 조금 체계가 있어 보였고 해외 서비스는 전통적으로 호스팅 분야에 강점이 있는 호스트웨이와 이미 오래전부터 이런 엔터프라이즈 클라우드를 제공하던 아마존 EC2 같은 서비스가 괜찮더군요.

그 이외에 더 많은 서비스가 있지만 서비스 종속성도 있고, 원하는데로 세팅 된 서버를 컨트롤 못하는 단점도 있어서 좀 프리한 자유성을 생각하면 위에 소개한 업체들 중심으로 알아봐도 괜찮을 것 같습니다.



다만, 벤처기업중 클라우드를 생각하는 기업이 계시다면 꼭 고민해 보셔야 하는 것이 무조건 클라우드가 좋다고 보는 것은 무리가 있습니다.

과금 체계에 따라 트래픽에 따라서 오히려 비용이 더 나올수도 있고 저희 같이 이미 계약되어 성장중인 상태라면 비용과 상황을 잘 따져보는 것이 좋을 듯 한데 저희 같은 경우는 클라우드를 이용 했다면 지금보다 최소 56%정도 비용을 세이브 했을 수 있었겠다는 결론에 많은 아쉬움이 남았습니다.

다만, 트래픽이 특정 시간대 집중적으로 발생하고 나머지 유휴 시간대에 늘지 않는 서비스나 기업 내부 인트라넷 정도로 운영하는 기업, 기존 서비스를 유지하면서 특정 시간대만 웹이든, DB든 스토리지든 빌려서 잠깐 잠깐씩 쓰려는 사용자에겐 도움이 되지 않나 생각됩니다.

특히 벤처 입장에서 초기 서버가 많이 필요 없고 테스트용과 실 서비스용으로 웹,DB,DNS를 하나로 구축해 이용하려는 사용자에게도 추천 할만한 서비스 같습니다.

다만, 규모가 수백대 이상 되고 트래픽이 특정 시간 가리지 않고 꾸준하게 나오는 기업이나 서비스의 경우 세밀하게 따져봐야 하는 문제는 있겠지만, 전반적으로 그렇게 일관 된 트래픽과 서버를 필요로 하는 경우가 많지 않은 점을 고려하면 기업형 클라우드 서비스는 꽤 의미 있는 비즈니스로 다가 올 수 있다고 생각이 됩니다.


결론, 성공은 결국 작은 차이와 리스크를 줄여가는 것..
언제 쓰러질지 모를 제 입장에서 이런 이야기 하긴 그렇지만 위에서 말한 초기 성공 가능성을 높이기 위해 작은 리스크(비용, 인력, 운영… 모든 측면)를 얼마나 줄여갈 수 있느냐에 따라 성공 가능성이 높아지는 것 같습니다.

결국, 벤처도 버틸 수 있을 만큼 버티면서 자신들이 처음 생각했던 생각을 펼쳐보아야 이런저런 시행착오도 겪고 경험도 쌓이면서 소비자의 needs를 파악하며 본격적인 괘도에 오를 수 있는 것 같습니다.

그런면에서 무조건 인프라 구축과 같이 고정비가 들어가는 부분만 고려하기 보단 사업 초기 상황을 고려해 좀 더 장기적인 발전 계획을 고려해 보는 것은 어떨까 생각되고, 인프라 투자냐? 아니면 클라우드 구축이냐의 관점을 잘 따져보고 자신들에게 어떤 것이 이득일지를 생각하면 성공에 다가가는데 조금이나마 도움이 되지 않을까요?

개인적으로 지나온 길을 되 집어 보면 초기 시장 예측이나 사업성을 판단하지 못했던 어리숙함은 분명 제게 큰 교훈으로 다가옵니다. 비용을 줄일 수 있는 부분 좀 더 흔들리지 말고 정진했어야 할 부분등 많은 교훈을 얻었죠.

그러나 그 실패 가운데 여러 경험을 얻었고, 인프라 투자와 운영 구축도 그런 측면에서 꼭 손해라고만 생각하진 않습니다.

당시 전 많이 부족했고 어리숙해서 놓쳤던 부분들을 큰 비용 치루고 돌아오면서 깨달았지만 새로 시작하는 분들은 그런 실수를 경험하지 않았으면 하는 바람에서 부족하지만 몇자 적어봤네요.

모든 벤처인들 힘내시고, 파이팅해서 좋은 결과물 얻으시길 바라겠습니다.
댓글