청년과 스타트업의 만남! 2018 스타트업 채용 페스티벌

[ 청년과 스타트업의 만남 ]

청년 실업률이 10%를 웃도는 사상 최악의 취업난이 이어지고 있지만 정작 기업들은 인력난을 호소하는 ‘일자리 미스매치’ 현상이 심화되고 있습니다. 구직자와 구인기업 간의 정보 미스매치에서 비롯되는 이 현상을 극복하고, 상호 간 정보 소통을 할 수 있는 ‘채용 박람회’가 주목받고 있는데요. 참여 구직자들은 1대 1 현장 면접, 취업상담, 컨설팅 등에 참여하며 다양한 정보를 얻을 수 있고, 기업 입장에서도 우수한 인재들을 만나 사업 성공의 길을 여는 기회가 될 수 있습니다.

[ 2018 스타트업 채용 페스티벌 ]

▲ 취업하고 싶닭…! 스타트업 정보 있소…! <2018 스타트업 채용 박람회>

지난 12월 6일, 구직난에 시달리는 취업준비생과 인력난에 시달리는 스타트업이 한 자리에 모였습니다. 청년 실업률을 극복하고 고용시장을 활성화할 대규모 채용 행사로 49개의 참여 기업과 1,000여명의 구직자들이 모이며 성황리에 개최되었습니다.

강남구청이 주최하고 (사)한국엔젤투자협회가 주관한 <2018 스타트업 채용 페스티벌>에는 IT부터 서비스 직군까지 총 49개의 다양한 업체들이 참가했습니다. 우아한형제들(배달의민족 등), VCNC(타다, 비트윈) 등 이름만 들어도 알 수 있는 굵직굵직한 업체들이 함께해 구직자들에게 벌써 입소문이 났던 행사라는데요, 20대 사회 초년생부터 중장년층까지 1,000여 명의 구직자들이 행사장을 방문하며 본격적인 채용 설명회와 면접이 진행되자 박람회장 안은 인산인해를 이뤘습니다.

가장 인기가 있었던 부대 행사는 ‘스타트업 취업 토크콘서트’로, 스타트업 얼라이언스 임정욱 센터장이 ‘스타트업 생태계 현황 및 발전방안’이라는 주제로 강연을 진행했습니다. 이후 멋쟁이 사자처럼(대표 이두희), 왓챠(매니저 이충재)에서 다양한 직군 및 직급에서 생각하는 스타트업의 모습을 소개했습니다.

특히 가장 눈에 띈 곳은 지문과 AI를 통한 구직자들의 적성을 분석해주는 부스였는데요, 이번 박람회는 지문으로 알아보는 적성검사와 인공지능이 알려주는 AI 자소서 분석 등을 진행해 호응을 얻었습니다.

[ 엔젤투자협회X로켓펀치 광고 ]

채용 페스티벌은 좋은 기업의 참여도 중요하지만, 얼마나 많은 구직자들이 참여하느냐가 관건입니다. 행사를 주관하는 ‘엔젤투자협회’에서는 더 많은 구직자들에게 이번 행사를 알리기 위해 <로켓펀치>를 통해 광고를 진행했습니다. <로켓펀치>는 연 200만 명이 방문하는 대표적인 비즈니스 네트워킹 서비스입니다. 🙂

▲ 메인 페이지, 메인 배너 광고

▲ 채용 페이지, 서브 메인 배너 광고

메인 페이지에서 바로 눈에 띄는 ‘메인 배너’와 채용 정보 페이지의 ‘채용 서브 메인 배너’를 통해 집중적으로 광고를 집행했는데요, 그 결과 15일 동안 클릭수 약 1,400번에 도달했습니다.

메인 페이지는 <로켓펀치>에 접속하면 가장 먼저 보이는 화면으로, 사용자들의 관심을 효과적으로 끌 수 있습니다. 따라서 메인 배너 광고의 경우 창업/채용 관련 이벤트 혹은 신규 서비스 런칭에 최적화된 영역입니다.

채용 페이지는 인사를 담당하는 기업은 물론, 구직자들이 관심을 갖고 들어오기 때문에 ‘채용 서브 메인 배너’를 활용한다면 구직자를 대상으로 하는 행사 홍보 등이 가장 적합할 수 있습니다.

연 200만 명이 비즈니스 목적으로 방문하는 <로켓펀치>에 광고를 실어보세요 😀

로켓펀치를 이용하는 기업 회원, 개인 회원은 물론 검색을 통해 유입된 사용자들에게 광고가 노출되며, 광고 성과까지 간편하게 확인할 수 있습니다.

문의 사항이 있으시면 언제든 편하게 연락주세요. 빠르게 안내해드리겠습니다.
감사합니다.

– 프로를 만나는 곳, 로켓펀치

[신한퓨처스랩x로켓펀치] 대한민국 스타트업의 스케일업을 위하여!

[신한퓨처스랩x로켓펀치] 대한민국 스타트업의 스케일업을 위하여!

창업을 시작했거나 진행 중인 분들은 한 번쯤 들어보셨을 프로그램이죠. 스타트업의 스케일업을 지원하는 육성 프로그램 ‘신한퓨처스랩’에서 지난 12월 10일 4기 데모데이가 열렸습니다.

비주얼캠프(시선추적 기술개발기업), 보맵(보험 통합 관리 앱), 메디블록(헬스케어 블록체인), 콴텍(자산관리 플랫폼 로보어드바이저) 그리고 로켓펀치(비즈니스 네트워킹 서비스)까지 약 21개의 기업이 참석했는데요. 이번 데모데이는 신한금융뿐만그룹 아니라 어니스트펀드(P2P 금융 기업), 에임(자산관리 로보어드바이저), 핀다(금융 플랫폼) 등 1-3기 동문기업이 함께 참여해 더욱더 뜻깊은 자리가 되었답니다. 대강당이 꽉 찰 정도로 많은 기업과 관련 업계 분들이 많이 참석해주셨습니다. 👏  

 

출처: 신한퓨처스랩 홈페이지

 

:: 언제나 새롭고 즐거운 데모데이에는 어떤 기업들이?

300명 이상이 참석했던 이번 신한퓨처스랩 데모데이는 “Shinhan Future’s Lab Runway 2018”라는 컨셉으로 멘토들의 소개와 함께 4기 육성기업들의 서비스 모델 발표가 시작되었는데요.

 

출처: 신한퓨처스랩 홈페이지

 

시선추적 기술로 ATM 기기를 개발한 ‘비주얼캠프’, 육아맘 커뮤니티를 활용한 육아 상품/서비스 ‘베이비프렌즈’, 종목 선택 엔진을 활용한 자산관리 플랫폼 로보어드바이저 ‘콴텍’, 딥러닝기반 보안/위험 탐지 시스템 ‘시티아이랩’, 식품 유해성분 검색 및 건강식품 추천 솔루션 ‘엄선’, 여행 짐 없는 가벼운 여행을 위한 짐 배송 서비스 ‘짐좀’ 등 새롭고 다채로운 산업계의 스타트업을 만나볼 수 있어 최신 트렌드를 함께 공유하고 인사이트를 얻을 수 있는 시간이었습니다.

출처: 신한퓨처스랩 홈페이지

 

:: 로켓펀치도 함께했던 “Shinhan Future’s Lab Runway 2018”

로켓펀치는 채용 서비스에서 시작해 ‘비즈니스 네트워킹 서비스’로 한 단계 더 높은 목표를 세웠는데요. 이번 데모데이에 참석해 최근 새롭게 리브랜딩 된 서비스에 대한 소개와 앞으로의 비전을 말씀드렸습니다.

(“로켓펀치가 대한민국 스타트업들을 성공적으로 연결했던 것처럼 앞으로도 대한민국에서 일하는 모든 분들을 하나의 거대한 비즈니스 네트워크로 만들어, 그분들이 가진 비즈니스의 문제를 효과적으로 풀 수 있는 좋은 플랫폼을 만들 생각을 하고 있습니다.” – 로켓펀치 😎)

대한민국의 비즈니스 문화를 바꾼다! 로켓펀치는 ‘일하는 사람들의 네트워크’를 만듭니다.

로켓펀치 리브랜딩, ‘사람’과 ‘연결’ 중심의 비즈니스 네트워크로

 

이 뿐만 아니라 로켓펀치는 이번 데모데이를 위해 신한퓨처스랩의 행사 홍보를 진행하게 되었는데요.

SK그룹과 일본 미즈호 그룹 등 많은 국내외 벤처투자자와 핀테크 업계 관계자가 모인 만큼 메인 배너 광고, 서브 메인 배너, 텍스트 스폰서 배너, 총 3가지 광고를 약 1주일간 집중적으로 진행했습니다.


<메인 배너 노출 이미지>

<서브 배너 노출 이미지>

 

그 결과 1주간 약 2만 회 이상 노출되는 등 높은 관심도를 끌 수 있었고 이에 신한퓨처스랩 데모데이 행사는 로켓펀치의 광고와 함께 더 많은 참석자를 모을 수 있었습니다.

내년에도 신한퓨처스랩은 5기 모집을 시작할 예정이라고 합니다. 자세한 내용은 신한퓨처스랩 공식 홈페이지를 참고해보시는 것도 좋을 것 같습니다. 😊

*행사 광고 관련해 문의 사항이 있으시면 언제든지 편안하게 연락 주시면 로켓펀치가 빠르게 안내해 드리겠습니다.

 

로켓펀치는 개인과 기업 모두를 위한 비즈니스 네트워킹 서비스로 한층 더 업그레이드 되었습니다. 앞으로도 많은 기대와 관심 부탁드려요!

– 프로를 만나는 곳, 로켓펀치

 

[HR insight] 스타트업에서도 ‘인사 평가’를 해야 할까요?

“결론부터 먼저 이야기하면 ‘필요하다’.
그러나 기존의 형식적인 평가 방식을 답습하는 수준이라면
‘필요하지 않다’고 감히 이야기할 수 있다.”

[인사 평가, 왜 필요할까?]

연말은 한 해를 마감하고 다음 해의 시작을 준비해야 하는 시점으로, 기업의 비즈니스를 연 단위로 평가할 수 있는 시즌입니다.

이미 많은 스타트업들은 평가라는 이름을 붙이지 않더라도 각각 다양한 방식으로 인사 평가를 진행하고 있습니다.

인사 평가가 없거나 혹은 있더라도 각자 일한 과정을 공정하게 평가받지 못한다면, 높은 성과를 낸 사람과 낮은 성과를 낸 사람 모두 회사가 목표로 하는 핵심 성과에 미달하는 등의 부정적인 영향을 주게 됩니다.

따라서 평가는 반드시 필요하며 또한 공정해야 합니다. 공정한 평가를 위해서는 현실적인 기준을 정의해야 하고, 피평가자와 평가 기준에 대해 충분히 논의한 뒤, 평가 결과에 대해 명확한 피드백이 있어야 합니다.

[우리 조직에 적합한 인사 평가를 하려면?: 평가를 위한 ‘준비’가 필요하다 ]

인사 평가는 연봉 계약의 기초 자료가 되기 때문에 인사팀 담당자는 재직자들의 업적과 성과를 평가하기 위해 상당한 시간을 투자합니다. 평가를 위한 KPI를 제작하고 배포, 취합까지 전 과정을 담당합니다. 인사 평가가 효과적으로 사용되지 않는다면 인사팀 담당자의 모든 노력은 결국 삽질(?)로 끝날 수 있습니다.

연봉 계약의 기초 자료로서 제대로 된 평가 결과를 도출하기 위해서는 시스템과 사람의 ‘준비’가 먼저 이루어져야 합니다. 시스템 준비란 구조화된 평가 기준을 수립하는 것이고, 사람 준비란 평가 스킬(피드백 등 대화법)에 대한 교육 등이 될 수 있습니다. 팀 베이커에 따르면 평가 관련 대화법은 분위기 평가 대화, 강점과 재능 대화, 성장 가능성 대화, 학습과 발전 대화, 혁신과 지속적인 개선 대화 총 5가지로 정리할 수 있습니다. (‘평가 제도를 버려라’, 2016)

그렇다면 평가 시스템 준비에서 가장 먼저 해야 하는 것은 무엇일까요? ‘왜 평가하는가? 무엇을 평가할 것인가? 누가 평가할 것인가? 어떤 방식으로 평가할 것인가?’ 등의 기준을 먼저 정의해야 합니다.

다른 기업들이 하니까 우리도 한다는 식의 접근으로, 평가 기준에 대한 충분한 고려 없이 진행되는 형식적인 평가는 오히려 독이 될 수 있습니다.

대부분의 기업은 KPI(Key Performance Indicator, 핵심성과지표)에 따라 구조적으로 평가 항목을 정하고, 그에 따라 평가합니다.

‘핵심’이란 조직의 정량적 목표를 달성하는 데에 기여도가 높은 지표라 할 수 있습니다. ‘성과’라고 하는 것은 평가 이전 조직과 협의해 결정한 나의 목표 수준을 의미하며, 유기적으로 통합하는 차원에서 정리되어야 합니다. 따라서 목표를 설정할 때 충분한 커뮤니케이션을 통해 성과 측정 지표를 설정해야 하고, 그에 따른 정량적/정성적 지표를 바탕으로 평가 기준을 수립해야 합니다.

[스타트업 초기 인사 평가 : 연 단위가 아닌 분기 단위로]

틀을 갖추지 않은 스타트업 초기에는 기업 목표가 변경되는 일이 무수히 많이 일어납니다. 어제의 목표가 오늘은 더이상 목표가 아닌 경우도 종종 발생합니다. 따라서 1년 목표를 설정하고 연 단위로 평가하는 것보다, 분기 단위로 평가하는 것이 더 적합할 수 있습니다.

먼저 분기별로 목표를 수립한 뒤, 각 담당자의 역할을 정의합니다. 평가 결과는 어떻게 피드백할 것인지 기준을 정하고, 수시로 커뮤니케이션 합니다. 분기 단위로 재직자가 모두 참여해 의견을 조율하고, 상호 간 의견에 대해 솔직한 토론과 피드백을 나누는 시간을 갖는 것을 추천하고 싶습니다.

스타트업 초기일수록 사업 방향에 맞는 계획 수립과 그에 따른 평가가 중요합니다. 단, 평소 커뮤니케이션을 통한 자연스러운 평가로 특정 시즌을 의식한 별도의 평가가 필요하지 않은 문화를 만들어보면 어떨까요?

평가 제도를 구조화해 회사의 HR 시스템을 만들어가는 것도 중요하지만, 회사 성장 단계와 분위기에 따라 우선 순위에 맞는 제도를 도입하는 것이 더욱 중요하다고 생각합니다.

또 한 가지 덧붙일 것은 평가 형식에 너무 집중한 나머지 인사 평가 본래의 목적에서 벗어나고 있지는 않은지 진중하게 고민하고 결정하길 추천합니다.

(글쓴이 : 김성규 COO @로켓펀치, 채용 컨설팅 서비스 문의: alpius@rocketpunch.com)

대한민국의 비즈니스 문화를 바꾼다! 로켓펀치는 ‘일하는 사람들의 네트워크’를 만듭니다.

 

 

대한민국의 비즈니스 문화를 바꾼다!

로켓펀치는 ‘일하는 사람들의 네트워크’를 만듭니다.

-2018 신한퓨처스랩 데모데이 ‘로켓펀치’ 피칭 자료 및 Review-

“인공지능도 중요하지만 일할 때 가장 중요한 것은 무엇일까요? 결국 일하는 사람입니다.” – 스마트포캐스트 김형주 대표

 

로켓펀치가 ‘비즈니스 네트워킹 서비스’로 리브랜딩 후 처음으로 오프라인 행사인 신한퓨처스랩 데모데이(18.12.10)에서 서비스 소개를 하는 시간을 갖게 되었습니다. 21개의 유망 기업들과 300명 이상의 청중이 참석한 대규모 행사에서 로켓펀치는 어떤 이야기를 했을까요?

 

:: 로켓펀치가 세상에 태어났을 때의 엇갈린 반응

  • 드디어 한국에 필요한 서비스가 등장했다 vs 좋은 서비스인데 돈을 벌까?  

로켓펀치는 5년 전 스타트업을 찾는 사람들, 구직자나 투자자 같은 사람들의 아주 작은 어려움을 해결하기 위해 태어났습니다. “어디 가면 스타트업 정보를 찾을 수 있을까?”라고 고민하셨던 분들과 “도대체 우리를 찾는 사람들은 아무도 없는 걸까?”라는 그 반대편에 있는 스타트업 사람들, 이 두 그룹을 연결하는 150개의 기업 정보와 채용 정보를 가진 서비스로 시작되었습니다.

🎉🎉🎉

‘아! 정말 대한민국에서 필요한 서비스가 드디어 나왔구나!’

로켓펀치가 세상에 태어났을 때, 많은 분들이 축하해주셨습니다. 하지만 그다음의 반응은 조금은 엇갈렸습니다. 대부분의 사람들은 좋은 서비스인데 과연 돈을 벌까? 잘 될 수 있을까?라는 의문을 던지셨습니다.

하지만 그 반대편에는 스타트업의 가능성을 믿는 소수의 사람이 있었습니다. 스타트업이 대한민국 경제를 바꿀지도 모른다고 생각하시는 분들께서 로켓펀치에게 “로켓펀치도 대한민국의 비즈니스 문화를 바꾸는 서비스가 될 수 있을지도 몰라.”라는 믿음을 주셨습니다.

 

::지금, 그 결과는?

  • 유일하고 거대한 가치를 발견하다

현재까지 단 한 번이라도 로켓펀치를 방문하는 대한민국 인구 수는 무려 200만 명이나 되고 있습니다. 대한민국에서 일을 하는 분들은 약 2,400만 명이라고 말하는데 그 말은 대한민국에서 일하는 분들 12명 중 1명은 반드시 로켓펀치를 방문하고 계신 것입니다. 그리고 대한민국에서 그중 IT업계에서 종사하는 분들이 약 100만 명 정도라고 하는데요. IT업계 계신 분들 혹은 IT업계에 종사하시는 분들은 로켓펀치에 적어도 1년에 한 번씩은 방문하는 것으로 보입니다.

대한민국에서 연간 200만 명의 사람이 방문하는 서비스는 많이 있습니다.

쇼핑몰, 가십성 뉴스 서비스, 그리고 직장인들이 1년에 한 번씩은 반드시 방문해야 하는 홈택스 같은 서비스도 있죠.

로켓펀치의 200만 명은 다르다고 생각합니다. 로켓펀치의 방문자들은 비즈니스라는 진지한 목적으로 가지고 아무런 광고 없이 자발적으로 방문하는 사람들입니다. 어떻게 이러한 놀라운 일들이 가능했을까요? 로켓펀치는 아주 소수의 사람이지만 이 사람들을 긴밀하게 연결하는 데에 성공했기 때문입니다.

로켓펀치 사용자들은 로켓펀치 내에서 그들의 경력, 학력, 투자 혹은 전문 기술에 따라 밀접하게 연결되어 있습니다. 그 연결을 그들의 구인과 구직 전문 기술에 대한 자문, 투자유치 같은 것들에 폭넓게 활용되고 있죠.

<로켓펀치 브랜드 디자이너가 실제로 받은 메시지>

위 예시로 든 메시지가 로켓펀치가 가지고 있는 유일하고 거대한 가치입니다. 이제 로켓펀치 팀은 한 단계 더 높은 목표를 세웠습니다.

대한민국 스타트업들을 성공적으로 연결했던 것처럼 로켓펀치는 대한민국에서 일하는 모든 사람들을 하나의 거대한 비즈니스 네트워크로 만들어, 그들이 가진 비즈니스의 문제를 효과적으로 풀 수 있는 좋은 서비스를 만들 생각을 하고 있습니다.

대한민국에서 일하는 모든 사람들 로켓펀치에 들어오게 되면, 그들의 비즈니스 배경에 따라 서로 긴밀하게 연결이 되고, 그 연결을 그들이 가진 구인구직의 문제, 기술에 대한 자문, 투자 유치, 그 외 많은 마케팅에 대한 것들까지 활용할 수 있는 플랫폼이 될 것입니다.

 

:: 우리가 지구의 정복자인 이유, 바로 우리가 하는 일

  • 일하는 사람의 네트워크를 만들다

무엇이 우리를 지구의 정복자로 만들었을까요? 자연과 1:1로 맞서면 죽을수 밖에 없는 존재인데 말입니다. 그것은 바로 우리가 하는 일입니다.

에어비엔비는 여행을 하면서 가장 중요한 공간의 네트워크를 만들어 여행 산업을 바꾸고 있습니다. 우버는 자동차들과 오토바이 같은 운송수단의 네트워크를 만들어 운송산업 그 자체를 바꾸고 있죠. 로켓펀치는 일하는 사람들의 네트워크를 만듭니다. 그리고 그 일을 금융부터 투자까지 다양한 산업분야에서 활용할 수 있는 좋은 플랫폼으로 키워갈 생각을 하고 있습니다.

 

:: 지금 이 순간도 우리가 서로 돕고 함께 하고 있는 일 그 자체

  • 일하는 사람들의 네트워크, 로켓펀치

로켓펀치는 비즈니스 네트워크를 만듭니다. 그리고 그 비즈니스 네트워크를 함께 만들 투자자, 파트너, 동료들을 항상 기다리고 있습니다.

 

[AskMe] 클라우드 시대 본격화! 당신의 클라우드는 ‘안정’하신가요?

서비스 출시 이래 클라우드는 서버 등의 IT 인프라를 안정적으로 운영하면서도 비용도 절감할 수 있는 방식으로 생각되어 왔습니다. 하지만 지난 11월 말에 있었던 AWS의 대규모 접속 장애 발생 후, 현실은 그렇지 않을 수 있으며, 특히 전산 장애 발생 시 이에 대비한 백업 전략이 매우 중요하다는 사실을 새삼 절감했습니다. 멀티(Multi) 클라우드, 하이브리드(Hybrid) 클라우드 등 다양한 안전장치의 확보와 그에 따른 추가 비용도 불가피하다는 인식을 하게 됐습니다.

<로켓펀치> AskMe 3회에서는 클라우드 서비스의 운영 안정성에 대해 살펴보고, 본격화되는 클라우드 시대의 클라우드 서비스 백업 전략 및 실행에 대해 알아봅니다.

 


정창훈
CTO
@당근마켓

신현묵
CTO
@GooDoc

이동인
CEO
@WhaTap

김세라
마케팅 수석
@네이버 비즈니스 플랫폼

 

1. 안정성 경보 울린 AWS 대규모 접속 장애

2. 클라우드 시대, 재난 방지 대책의 새로운 관점

3. 당장 실행할 수 있는 백업 전략 구축 노하우

4. 클라우드 시대를 준비하는 실무자의 자세

* AWS 대규모 접속 장애 사건이란?

▲ AWS 장애로 인한 마비된 홈페이지 2018.11.22

2018년 11월 22일, AWS의 서울 지역(region) ‘아마존 엘리스틱 컴퓨트 클라우드’ 서버에서 도메인네임시스템(DNS) 오류가 발생했다.

AWS를 이용하는 국내 업체들은 오전 8시 19분부터 84분 동안 홈페이지 연결 접속 장애를 겪었다. 배달의민족, 쿠팡, 야놀자, 여기어때, 푹 등의 인터넷 서비스와 업비트, 코인원, 고팍스 등 암호화폐 거래소, 스마일게이트 등의 게임 서비스, KB금융지주 ‘클래온(Clayon)’ 사이트와 신한은행 ‘쿱’ 등 금융사 서비스가 2시간 이상 정상적인 서비스를 제공하지 못했다.

세계 1위 업체인 AWS가 일으킨 ‘역대급’ 사고는 대다수 이용자가 ‘그냥 맡겨 놓으면 되는 줄’ 알았던 클라우드 역시 안전장치는 필요하다는 점을 새삼 환기하고 있다.

*          *          *

[ 안정성 경보 울린 AWS 대규모 접속 장애 ]

1. 지난 11월 말, AWS DNS 통신 장애가 있었습니다. AWS는 클라우드 서비스의 ‘안정성’과는 별개의 문제라고 선을 긋긴 했습니다만, 어떻게 해석할 수 있을까요?

정창훈 CTO @당근마켓

“AWS 장애로 서비스를 정상적으로 제공하지 못한 고객들이 있었기 때문에, 클라우드 서비스의 안정성 관련 사례 중 하나로 기록될 것”

AWS에서 이번 문제가 클라우드 서비스의 안정성과 별개라고 이야기하지 않았을 것이라 생각합니다. 클라우드 서비스에 장애가 있었고 이로 인해 서비스를 정상적으로 제공하지 못한 고객들이 있었습니다. 물론 이 문제가 클라우드 서비스라서 발생한 것은 아니지만 클라우드 서비스의 안정성에 대한 사례 중 하나로 남게 될 것입니다.

신현묵 CTO @GooDoc

“인터넷이나 통신 서비스가 가질 수 있는 보편적인 문제, 오히려 클라우드 서비스였기 때문에 빠르게 문제를 잡을 수 있었다고 생각”

클라우드의 안전성에 대한 큰 의미로 해석한다면, 안전성에는 큰 문제가 없다고 생각합니다. 다만, DNS 통신장애가 이번에 발생한 휴먼 에러에 가까운 실수는 언제나 발생할 수 있는 요소에 해당합니다. 전문가라고 하더라도, 해당 문제는 각각의 서비스를 별도로 운영하거나 IDC에서도 동일하게 발생될 수밖에 없는 이슈였기 때문에 이 문제는 서비스 운영과 관련된 실수라고 봐야하며, 해당 문제를 빠르게 대처한 것은 오히려 클라우드여서 전체적인 문제를 빠르게 잡을 수 있다고 생각합니다. 물론, 좁은 의미로 해석된다면 인터넷이나 통신 서비스가 가질 수 있는 보편적인 문제였다고 설명하는 것이 맞다고 생각합니다.

이동인 CEO @WhaTap

“언제든지 일어날 수 있는 일, 다만 상황과 원인을 즉각적으로 발표하지 않는 등의 늦은 대응은 아쉬워”

DNS 장애는 일어날 수 있는 일입니다. 그리고 모든 클라우드 서비스는 장애가 발생할 수 있습니다. 다만 이번 사고에서 아쉬운 점이 있다면 AWS에서 상황과 원인을 즉각적으로 발표하지 않은 것입니다. 한국 아마존은 미국 본사로부터 확실하게 권한을 위임받아서 장애 발생 시 더 빠른 대처를 보여줘야 합니다.

2. 전적으로 서비스를 한 클라우드에 의존한다면 장애 발생 시 속수무책일 수밖에 없습니다. 그동안 각 클라우드 서비스 제공업체들은 어떤 대책을 갖고 있었나요?

정창훈 CTO @당근마켓

“하나의 클라우드에만 의존했기 때문에 발생한 장애라고 생각하지 않아, AWS에서는 문제 상황을 대비해 최소 2개 이상의 가용 영역(Availability Zone) 제공하고 있어”

한 클라우드에 의존해서 장애가 발생했다고 생각하지는 않습니다. 여러 클라우드를 사용하더라도 그 클라우드 회사들이 하나의 IDC를 공유하거나 하나의 통신선로를 이용한다면 마찬가지입니다. 또한 IDC에서 직접 운영하는 경우 디스크 문제, 전원 문제 등으로 서버가 종료되는 일이 다반사입니다. 기존에 이런 문제가 발생하면 개발자가 직접 IDC로 뛰어가거나 IDC 상주 인력이 빠르게 문제 해결을 해줘야 했었습니다. 클라우드에서는 이정도 문제는 자동화 솔루션을 이용해 대부분 문제가 일어났는지도 모르게 지나가는 경우가 많습니다.

AWS에서도 서비스 안정성을 위해 최소 2개의 AZ 라고 부르는 가용영역을 제공하고 개발자들에게 하나의 가용영역에 문제가 발생하는 상황을 항상 가정하라고 이야기합니다. 다만 이번에는 서울 리전 전체적으로 발생했던 문제였고 이에 대한 AWS의 준비는 부족한 면이 있었다고 생각합니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“장애를 100% 방지하는 것은 불가능, NAVER CLOUD PLATFORM을 비롯한 많은 클라우드 제공업체에서는 다중 존(Multi-Zone) 혹은 가용 존(Availability Zone)을 제공하여, 고객들의 서비스를 분산시켜 장애 영향도를 최소화하도록 권고”

장애는 100% 방지할 수 없고 발생 시에 최우선으로 장애를 복구하는 노력과 더불어 클라우드 서비스 제공자들은 고객과의 소통이 중요합니다. 물론 모든 클라우드 서비스 제공자들이 이중화, 분산화 등 다양한 방법을 통해 인프라와 시스템 가용성을 높이는 구조를 만들고 있고, AWS의 사태처럼 운영상의 실수가 생기지 않도록 운영자의 조작이 필요 없는 운영 자동화를 많이 하고 있지만, 그렇다고 100% 방지는 안 되므로, 빠른 소통과 함께 빠른 대응책을 제시하는 것입니다.

NAVER CLOUD PLATFORM을 포함해서 많은 (전부는 아닙니다.!!) 클라우드 업체들은 다중 존(Multi-Zone) 혹은 가용 존(Availability Zone)으로 한 리전(지역)에 두 개 이상의 IDC에서 클라우드 서비스를 제공하고 있으며, 고객들의 서비스를 Multi-Zone에 분산시켜서, 장애 영향도를 최소화 하도록 권고하고 있습니다. 이번 AWS 장애에서도 AWS는 그 부분을 언급하긴 했으나, 그렇다고 모든 것을 고객 책임으로 돌릴 수는 없으며, 항상 고객과 커뮤니케이션을 하면서 서비스 가용성을 높이고 장애에 빠르게 대응하는 것이 중요합니다.

이동인 CEO @WhaTap

“많이 사용하는 ‘IDC 이중화’는 물리적인 한계가 있으며, 클라우드 서비스 제공업체에서는 리전의 개수를 늘려야 해 ”

국내 주요 서비스들은 모두 IDC(인터넷 데이터 센터)를 이중화하고 있습니다. 이는 물리적인 문제를 함께 가지고 있기 때문에 클라우드 서비스 제공업체에서 대책을 마련한다면 리전의 개수를 늘려야 합니다. 예를 들어 MS Azure는 서울과 부산에 리전을 가지고 있습니다. 아마존도 향후 리전을 늘릴 것으로 예상하고 있습니다.

3. 그동안 재해복구(Disaster Recovery) 시스템 구축에 대해 국내 기업의 인식은 어땠습니까?

이동인 CEO @WhaTap

“금융권에는 잘 구축되어있는 편, 스타트업의 경우 대부분 DR 시스템을 갖추지 못하고 있어”

금융권이 재해복구 시스템에 가장 민감한 분야라고 할 수 있습니다. 금융권에선 통상 주 센터와 DR 센터 간 거리가 20Km 내외로 떨어져 있으면 안전한 것으로 보고 있으며 한국은행이 추진하는 금융공동백업센터의 경우 떨어진 거리를 140Km로 정하기도 했습니다. 하지만 스타트업의 경우 대부분의 기업이 재해복구 시스템을 갖추지 못한 것이 현실입니다.

정창훈 CTO @당근마켓

“재해 발생 빈도 대비 서비스 구축 비용을 고려하면 일반적인 서비스 업체에서는 쉽지 않은 일”

재해복구 시스템은 금융이나 의료 등 장애가 발생했을 때 영향이 큰 경우에 주로 하는 편이라고 알고 있습니다. 일반적인 서비스 업체의 경우 재해복구에 대해서 신경쓰는 것은 쉽지 않습니다. 재해복구 시스템을 구축하는 비용이 만만치 않은데 장애가 그렇게 자주 발생하는 것도 아니고 장애가 발생해도 피해 금액이 많지 않기 때문입니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“서비스 가용성을 위한 ‘서비스 이중화’ 차원에서 접근해야”

일반적으로 국내 기업들은 재해복구(Disaster Recovery)에 대해 ‘하면 좋은데 비용은 비싸고, 정말로 확률이 거의 없는 재해 재난을 위해 비용 투자를 해야 하는가’라고 인식하고 있습니다. 그러나 이는 재해 복구 순서의 의미일 때이고, 장애 대비의 수준으로 클라우드를 활용할 때는 전혀 다릅니다.

서비스/업무 시스템을 분산시키는 구성 전략이므로 추가 비용이 드는 것이 아니고, 장애가 발생해도 100% 전면 서비스/업무 중단이 아닌 부분 가능 상태가 되고, 클라우드의 장점으로 신속히 증설해서 50%가 80%, 90%가 되게 하는 것이므로, 추가 비용의 부담이 있는 것이 아니며, 또한 장애는 재난과 다르게 발생 가능성이 항상 존재하므로 꼭 필요한 고려 사항입니다.

이를 다른 표현으로는 서비스 이중화라고 하겠습니다​​. 네이버/라인과 같은 대형 온라인 서비스들, 그리고 대형 게임 서비스들은 이미 서비스 이중화의 개념을 가지고 이부분에 더욱 집중하고 있습니다. 많은 기업이 재해복구(DR)와 서비스 이중화의 개념을 혼동하는 경우가 있습니다. 재해복구 DR 시스템을 구축하는 것도 중요하지만, 더 중요한 것은 서비스 가용성을 위한 서비스 이중화입니다. 많은 기업이 DR이라는 용어에 집착하면서 핵심을 놓치고 있는 것은 아닐까 생각됩니다.

[ 클라우드 시대, 재난 방지 대책의 새로운 관점 ]

4. 클라우드 서비스 제공 업체들이 제안하는 재난 방지 대책은 무엇인가요?

이동인 CEO @WhaTap

“IBM에서는 스마트클라우드 매니지드 백업 서비스 솔루션 제공”

재해복구 시스템은 전통적으로 엔터프라이즈 기업들을 위한 시장이었습니다. 중소기업들은 비용 문제로 재해복구 시스템을 도입하지 못했습니다. 최근 클라우드 서비스 제공업체들이 중소기업을 위한 재해복구 시스템에 관심을 보이는 상황입니다. IBM에서는 스마트클라우드 매니지드 백업 서비스와 같은 솔루션을 제공하고 있습니다.

정창훈 CTO @당근마켓

“AWS에서는 언제든지 실패할 수 있다는 가정 아래 AZ 제공하거나 개발자가 직접 재해복구를 하도록 제반 시스템 제공”

아마존 CTO Werner Vogels는 “모든 것은 항상 실패(Everything fails, all the time)한다.”고 이야기했습니다.  이런 기조에 따라 하나의 IDC에 해당하는 AZ는 언제든지 실패할 수 있다고 가정되어 있어서 DB 같은 경우 간단한 옵션만 켜면 추가 비용을 내면서 하나의 AZ에 장애가 발생하더라도 몇 분 이내에 자동으로 다른 AZ에서 복구됩니다. DB처럼 자동으로 아마존이 해주는 부분도 있지만, 개발자들이 직접 해야 하는 부분도 있습니다. 웹 서버를 다른 지역에 이중화한다거나 하는 것들은 직접 해야 합니다.

클라우드 서비스들은 DB 같은 주요 서비스는 쉽게 재해복구를 지원하지만 일반 서버 같은 경우는 개발자들이 직접 재해복구를 구축하도록 하고 있습니다. 재해복구에 필요한 지역 간 네트워크 연결 등 제반 시스템을 제공합니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“재난 방지 수준을 어떻게 보느냐에 따라 달라져”

재난 방지의 수준을 어떻게 보느냐에 따라 달라질 수 있습니다.

① 클라우드의 기능 장애, 인프라 장애 수준의 방지 대책을 의미한다면 클라우드 서비스 업체들은 일반적으로 멀티 존(혹은 가용 존)의 사용을 권고합니다. 하나의 서비스/업무를 양쪽 존에 분산해서 구축하는 구성을 제안합니다. 그리고 다양한 데이터 백업 상품들과 함께 관리형 DB 상품들을 제안합니다. 관리형 DB 상품은 DB 서버의 이중화 구성과 데이터 백업이 포함되어 제공되므로 이를 활용하면 고객이 스스로 구성하여야 하는 번거로움이 줄고, 미처 고려하지 못하는 실수를 방지하는 데 도움이 됩니다.

② 재해 복구 수준의 재난 방지를 위한 DR 시스템 구성으로 클라우드 서비스 업체에서 제안하는 유형은 크게 둘로 나눠볼 수 있습니다. 첫 번째는 클라우드를 DR 센터 혹은 Backup 센터로 사용하는 유형인데, ​이미 On-premise로 자체 IT 시스템을 가지고 있는 기업의 경우 (즉 아직 퍼블릭 클라우드를 사용하지 않는 경우)에 클라우드로의 전이(Transformation) 비용이 있기에 메인 시스템을 클라우드로 이전하기 전에, 자체 IT 시스템의 장애나 재난에 대비하기 위해 클라우드에 백업 데이터를 적재하는 방식입니다. 이는 기업의 현재 데이터 백업 솔루션과 클라우드의 여러 스토리지 상품들(예를 들어 오브젝트 스토리지, 아카이빙 스토리지 등)과 연동해서, 클라우드에 자동으로 데이터를 백업하게 됩니다.

두 번째 유형은 이미 클라우드를 사용하고 있거나 아니면 클라우드 이전 가능 (다른 표현으로 Cloud-Native) 구성을 가지고 있는 경우입니다. 클라우드를 이미 사용하고 있는 경우는 멀티 존 구성과 멀티 클라우드 전략을 제안하게 되며, Cloud Native 구성의 경우는 서비스/업무 시스템의 일정 비율을 클라우드에서 구동하도록 하는 것입니다.​

5. 기업 차원에서 할 수 있는 백업 전략들에는 어떤 것들이 있나요?

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“일반적인 DR과 서비스 가용성 혹은 연속성은 달라, 독립적으로 분산할 수 있는 멀티 클라우드 추천”

재해복구(Disaster Recovery)와 서비스 가용성(Service Availability) 혹은 연속성(Service Continuity)는 조금 다른 측면이 있습니다.

DR은 자연재해나 화재, 지진 등의 물리적 재해로 인해 IDC가 가동 불능이 되었을 때를 대비하는 것을 의미하고, 그 준비 수준에 따라 Hot DR(최상위 수준, 재해 발생 시 몇 분 내 곧바로 다른 IDC에서 서비스/업무 재개), Warm DR(중간 수준, 재해 발생 시 수 시간에서 수일 이후 서비스/업무 재개), Cold DR(낮은 수준, 데이터가 안전하게 백업되어 있어서, 신규로 IT 자원을 갖춘다면 언젠가는 서비스/업무가 재개될 수 있는 수준) 이 있습니다. 이런 개념의 DR은 금융 시스템이나 사회 안전 시스템, 공공성이 짙은 시스템들의 경우 필수적으로 갖추어야 하는 요건입니다.

서비스/업무의 가용성 혹은 연속성은, 재해(disaster)가 아닌 장애(fault) 수준에서도 서비스/업무 제공이 가능한지에 대한 관점으로, 이중화 혹은 고가용성(High Availability) 구성 등이 해당하며, IDC 수준의 장애에 대비하기 위해서는 멀티 IDC 혹은 멀티 존을 사용하게 되고, 클라우드 관점에서는 멀티 클라우드를 고려하게 됩니다. 이는 달걀을 한 바구니에 담지 말고 분산하라는 것과 같은 의미로, 예를 들어 서비스/업무 시스템을 2개의 클라우드에 50:50으로 분산시켜 놓았다면, 한 클라우드의 전면 장애에서도 최소한 50%의 서비스 가용성과 업무의 연속성을 보장하는 것입니다.

그리고 다른 두 개의 클라우드 업체를 사용하는 멀티 클라우드 전략과 한 클라우드 업체 내에서 멀티 존 혹은 멀티 리전을 이용하는 것과는 어떤 차이가 있을지에 대한 설명이 필요합니다. 멀티 존/리전을 사용하는 것도 2개의 IDC에 서비스/업무 시스템을 분산시켜 놓는 것이기 때문에 한 존/리전의 클라우드 인프라 장애의 경우에도 다른 존/리전에서 서비스/업무가 연속성을 가지고 제공될 수 있습니다. 하지만 이번 AWS 장애와 같이 운영상의 장애의 경우에는 동시에 양쪽 존, 혹은 여러 리전에 걸쳐서 장애가 발생할 가능성도 있습니다. 그러므로 독립적인 운영 체계로 분리된 복수 클라우드 사업자의 서비스를 사용하는 것, 즉 멀티 클라우드를 사용하는 것이 추가적인 고려 대상이 됩니다.

이동인 CEO @WhaTap

“시간을 기준으로 백업 전략을 결정하고 그에 따라 백업양을 결정, 백업 전략 전문 기업의 컨설팅을 받아 진행 ”

백업 전략은 시간을 기준으로 세워볼 수 있습니다. 실시간으로 진행할지 12시간, 24시간 또는 일주일 단위의 백업 전략이 있을 수 있습니다. 어떤 전략을 쓰냐에 따라 전체 시스템 백업을 할지 변경분 백업을 할지 결정하게 됩니다. 이런 전략에 대한 부분은 백업 전략을 전문적으로 제공하는 기업의 컨설팅을 받아서 진행하는 것이 일반적입니다.

정창훈 CTO @당근마켓

“주어진 비용과 서비스 상황에 맞춰 백업 수준을 정한 뒤, 알맞은 백업 전략 선택”

장애 발생 시 우리가 감당할 수 있는 수준을 정하고 그에 따른 대책을 상황에 맞게 정해야 합니다. 백업이나 장애복구의 경우 완벽하게 하려고 하다 보면 끝이 없는데요. 주어진 비용과 서비스 상황에 맞춰서 어느 정도 까지 할지 결정해야합니다.

어느정도까지 서비스를 유지할지 정해지면 그다음으로 알맞은 백업 전략을 찾으면 됩니다. 하나의 클라우드에서 여러 지역으로 분산하거나 여러 개의 클라우드 서비스를 섞어서 사용하거나 IDC를 동시에 운영하는 하이브리드 클라우드 방식도 있습니다.

신현묵 CTO @GooDoc

“기업마다 내부 가이드 라인이 정해져 있는데, 백업 리전을 많이 사용”

중요 디지털 자산들을 관리하기 위한 백업 절차들에 대해서는 각각 가이드라인들을 기준으로 많이들 사용합니다. 백업 리전도 많이 사용합니다.

[ 당장 실행할 수 있는 백업 전략 구축 노하우 ]

6. 결국 하나의 사본을 추가로 운영하는 일인데, 비용은 평균적으로 얼마나 더 들까요?

정창훈 CTO @당근마켓

“복잡해지는 아키텍처에 따른 개발 속도, IDC 운영 등 추가적인 기회비용이 계속 발생할 수 있기 때문에 3배 혹은 5배가 될 수도 있어”

단순히 사본을 하나 추가로 운영한다고 해서 비용이 2배가 되는것은 아닙니다. 비용이 3배 혹은 5배가 될 수도 있습니다. 단순히 하드웨어나 서비스 비용만 생각하는 것보다 서비스의 개발 속도에 따른 기회비용 역시 고려해야 합니다. 장애 대응이나 백업에 대한 고려를 하다 보면 아키텍쳐가 복잡해지고 이에 따른 개발 속도가 느려질 수 있는 부분도 있습니다. 클라우드와 함께 IDC를 직접 운영하거나 임대하기로 결정했다면 단순히 사본 하나가 아니라 IDC 운영에 대한 제반 비용도 추가됩니다.

신현묵 CTO @GooDoc

“단순 데이터 백업이라면 큰 비용이 들지 않지만, 실 운영이 가능한 서비스라면…. 부분적으로 백업하는 경우도 있지만 효과가 좋은 편은 아니기 때문에 잘 선택하지 않아”

사본의 개념이 단순 데이터의 형태라면 큰 비용이 들어가는 것은 아닙니다. 하지만, 실 운영 가능한 서비스의 형태라면 동일한 인스턴스 형태로 구성합니다. 부분적으로 RDS와 같이 데이터베이스를 AWS의 데이터를 저장하고, 인스턴스 분리하고 LB로 구현되는 정책들도 많이 사용합니다. 다만, 이런 서비스 역시 이번의 서울 리전에서의 이슈를 대응하기에는 불가능하기 때문에, 멀티 리전을 구사하는데 비용은 대부분 잘 선택하지 못합니다.

이동인 CEO @WhaTap

“시스템 개발부터 운영까지 2배 이상의 비용이 들지만, 일주일 단위로 백업을 진행한다면 비용 줄일 수 있어”

장애 발생 시 실시간으로 전환 가능한 서비스를 운영하기 위한 전략을 가지고 있다면 2배 이상의 비용이 발생합니다. 데이터 센터 비용도 올라가지만, 설계 복잡도가 높아지면서 시스템 개발에서 운영까지 비용이 올라가게 됩니다. 다만 일주일 단위의 백업을 진행한다면 비용은 매우 줄어들 것입니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“기존 물리적인 DR 개념이라면 비용은 2배 이상, 하지만 클라우드만의 특성을 살리면 전혀 다른 비용으로 접근 가능”

앞서 언급한 것처럼 DR 개념으로 가면 하나의 사본을 추가로 운영하거나 미리 준비해 놓는 것이 되므로 비용이 2배 이상이 됩니다. 그래서 많은 기업이 DR 센터 혹은 백업 센터를 구축하면서 인프라 규모를 축소하여 최소한의 인프라만, 예를 들어 50% 정도만 DR센터에 구축하거나, 아니면 Cold DR 개념으로 데이터만 백업해 놓습니다.

그러나 클라우드의 특성을 잘 살리면 전혀 다른 관점으로 바라볼 수 있습니다. DR이 아닌 서비스 이중화나 서비스 가용성, 서비스 연속성의 관점에서 클라우드의 빠른 증설 및 확장 가능이라는 특성을 살리는 것입니다. 예를 들어 현재 A 클라우드의 1개 존에 서비스/업무 시스템 전체를 구축하여 사용하고 있다면, 이를 두 개의 존에 분산 배치할 수 있습니다. 클라우드에서는 하나의 로드 밸런서로 2개의 존을 커버할 수 있으므로 서비스 사용자 입장에서는 동일합니다. 예를 들어 10대의 웹서버를 운영하는 서비스였다면 5대 5대씩 두 개의 존에 나누어 놓지만, 전면에는 하나의 로드밸런서를 이용해서 10대의 웹 서버를 하나의 접속점 (ex. www.naver.com)으로 운영할 수 있습니다. 만약에 한쪽 존에 장애가 발생해서 5개대의 웹 서버가 서비스를 할 수 없는 상황이 된다면, 수 분 만에 서버 증설을 할 수 있다는 클라우드의 장점이자 특징을 활용하여 5대의 웹서버를 10대로 늘리는 것은 수 분 만에 가능해 질 것입니다. 혹은 아예 자동으로 늘어나도록 하는 ​Auto Scaling이라는 클라우드만의 기능을 적용할 수도 있습니다. 따라서 고객 관점에서는 항상 10대의 웹서버만 운영하는 것이므로, 추가 비용이 발생하지 않으면서도 장애에 대비할 수 있게 됩니다.

결론적으로 항상 준비되어 있고 빠르게 증설할 수 있으며 사용한 만큼만 비용을 지불한다는 클라우드의 특성이 기존의 비용이 2배가 된다는 DR의 관념을 바꿔 놨다고 할 수 있습니다.​

7. 새로 백업 리전/클라우드를 구축하려면 기간은 얼마나 걸릴까요?

신현묵 CTO @GooDoc

“규모와 복잡도 차이로 일정하지는 않지만, 큰 시간이 걸리지는 않아”

보통은 일반적인 배포 정책에서 백업 리전과 멀티 리전을 동일하게 구성하여 사용하는 경우가 대부분입니다. 이번 서울 리전 이슈때문에 많은 업체들이 멀티 리전 정책을 취하면서, 분석하고 구성을 완료하기까지 큰 시간이 투여되지는 않습니다. 다만, 이 기간 역시 규모와 복잡도의 차이 때문에 일정하지는 않습니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“멀티 클라우드 구축은 ‘즉시’! 기존 물리적인 DR, 백업 센터를 준비하고 구축하는 데에 드는 시간과 확연히 달라”

앞서 이야기한 관점에서 멀티 클라우드 전략을 실현할 때 소요되는 구축 시간은 ‘즉시’라고 할 수 있습니다. 물론 서비스/업무 애플리케이션의 구조 등을 미리 잘 파악하고 있어야 합니다만, 기존 물리 구성으로 DR 센터 혹은 백업 센터를 구축하기 위해 준비하고 구축하는데 드는 소요 시간과는 확연히 다르다고 할 수 있습니다.

정창훈 CTO @당근마켓

“서비스 상황에 따라 하루에서 1년까지 천차만별”

서비스 상황마다 달라서 대략 얼마 정도 걸릴 것이라고 이야기 하기 어렵습니다. 어떤 회사는 하루 만에도 할 수 있고 다른 회사는 1년이 걸릴 수도 있습니다. 어떤 경우에는 클라우드 서비스에서 제공하는 유일한 기능으로 인해 전체 서비스를 백업하지 못하고 일부만 대응해야 할 수 있습니다.

8. 구체적인 운영 방법이 궁금합니다. 백업 리전이나 클라우드 운영 시 어떤 장단점이 있고, 운영 노하우가 있다면 무엇인가요?

신현묵 CTO @GooDoc

“백업 리전을 사용하는 경우, 개발-스테이징-리얼 서비스 3단계에서는 스테이징, 리얼 서비스 단계를 다른 리전으로 구성하는 것을 추천”

기본적으로 백업 리전을 운영하고 있으며, 내부적으로 멀티 인스턴스에 LB를 혼용하는 일반적인 구성요소를 사용합니다. 개발-스테이징-리얼 서비스의 3단계 정책으로 긴급 상황에 스테이징 서비스를 리얼로 대신할 수 있게 하는 단계를 사용합니다. 일반적인 상황에서는 테스트 목적으로 사용하고 있는 구조입니다. 그리고, 이 구조에서 스테이징과 리얼 서비스를 다른 리전으로 구성하는 것이 가장 좋다고 생각합니다.

정창훈 CTO @당근마켓

“백업 리전이나 클라우드 운영으로 모두 해결되는 것이 아니기 때문에, 어느 정도까지 재해복구 시스템을 구축할지 정하는 것이 중요”

간단하게 시작할 수 있는 것은 아마존의 경우 Multi AZ 기능을 제공하는 서비스는 Multi AZ 기능을 활성화 하는것이 기본입니다. 그다음으로 DB의 백업 데이터를 주기적으로 다른 리전이나 다른 클라우드로 복제 한다거나 서버를 어디서라도 바로 실행할 수 있도록 서버 설치에 대한 방법을 코드로 관리하는 Packer 같은 툴을 이용하거나 인프라 시스템을 코드로 관리하는 Terraform 툴을 사용하는 것도 좋습니다.

백업 리전이나 백업 클라우드를 사용한다고 모두 해결되는 것은 아닙니다. 백업 리전을 운영했는데 운이 없게도 백업 리전과 현재 리전이 동시에 장애가 발생 할 수도 있고 백업 클라우드를 운영했는데 서로 다른 클라우드 서비스 회사가 알고 보니 같은 IDC 건물에 있어서 같이 안 될 수도 있습니다. 이렇기 때문에 어느 선까지 재해복구 시스템을 구축할지 정하는 것이 중요합니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“전통적인 DR이나 백업 센터 개념에서 벗어나, 클라우드 특성을 활용한 ‘서비스 가용성’ 측면에서 장/단점 파악할 것”

전통적인 DR 센터, 백업 센터 구축과 운영의 관점으로 보지 않고, 클라우드 특성을 활용한 멀티 존, 멀티 클라우드로의 분산 환경 구축을 통한 서비스 연속성, 서비스 가용성의 관점으로 바라본다면 어떤 장단점이 있는지가 잘 드러날 것으로 생각됩니다. 장점뿐만 아니라 단점을 명확히 하고, 그 단점을 극복할 방안을 마련하는 것이 중요합니다.

멀티 클라우드 전략의 경우도 동일한 개념이 적용될 수 있습니다. A 클라우드가 장애가 났을 때 B 클라우드에서 빠르게 용량 증설을 통해 서비스/업무의 가용성을 유지할 수 있습니다. 더구나 On-prem (기업 자체 IDC에 비 클라우드) 형태의 기업이더라도 클라우드와 병행하는 하이브리드 구성을 한다면, On-prem 장애의 경우에 클라우드에서 재빠르게 증설하여 서비스를 지속할 수 있습니다.

멀티 클라우드 전략의 단점은, 클라우드 서비스 업체별로 100% 동일한 환경이 아니고 클라우드 상품 사용 방법이나 상품의 기술적 스펙 등에 차이가 있으며, 이러한 차이로 인해 100% 동일한 구성을 할 수 없다는 점입니다. 예를 들어 A 클라우드에서 서버를 생성하는 절차와 B 클라우드에서 서버를 생성하는 절차는 다를 것이고, A 클라우드에서 제공하는 상품/서비스의 종류와 기능들은 당연히 다른 클라우드와 차이가 있을 것입니다.

이러한 차이는 사용 기업 관점에서는 운영의 복잡성을 가져오게 되고, 나아가서는 시스템 운영 절차와 방법론의 차이에서 오는 무형의 운영 비용의 증가가 발생합니다. 또한 A 클라우드에서만 제공되는 특별한 상품/기능을 사용하고 있었다면, 멀티 클라우드 전략을 가져가는 데 걸림돌이 되면, 결국 1개의 클라우드 사업자에 Lock-in 되어 버리는 꼴이 됩니다.

그러므로 멀티 클라우드 전략을 가져가는 경우는 각 클라우드의 차이점을 충분히 이해하고, 또한 하나의 클라우드에 lock-in 되지 않도록 시스템 아키텍처에 신경을 써야 하면서, 정형화된 자체 운영 프로세스도 고려해야 합니다.

다행히도 이런 멀리 클라우드 전략을 택하는 사용자를 위한 다양한 멀티 클라우드 도구(툴)들이 존재하며, 이러한 소프트웨어 툴들을 사용하면 단점을 어느 정도 극복할 수 있습니다. 오픈 소스 도구 중에 가장 유명한 Packer나 Terraform 과 같은 소프트웨어 툴을 사용하면, A 클라우드, M 클라우드, N 클라우드와 상관없이 단일한 방식으로 즉 Packer와 Terraform의 사용법만으로 여러 클라우드에 서버를 생성하고 설정할 수 있습니다. NAVER CLOUD PLATFORM은 이러한 중립적인 오픈 소스 도구들을 지원함으로써 사용자들이 멀티 클라우드 전략을 쉽게 구현할 수 있도록 돕고 있습니다.

[ 클라우드 시대를 준비하는 실무자의 자세 ]

9. 클라우드 서비스는 피할 수 없는 거대한 흐름입니다. 클라우드 서비스 도입을 고민하는 실무 담당자가 꼭 고려해야 할 것이 있다면 무엇인가요?

이동인 CEO @WhaTap

“아마존의 독주에서 점차 다양해지고 있는 클라우드 시장! 기업의 서비스 특성에 맞는 클라우드를 선택할 수 있어”

비용과 안정성 그리고 비즈니스의 속도를 고민할 때 클라우드를 쓰지 않을 이유가 없습니다. 현재까지는 아마존의 독주였지만 최근 MS가 빠르게 성장하고 있습니다. 내년에는 오라클도 한국에 클라우드 리전을 오픈할 예정입니다. 한국의 클라우드 업체들도 특화된 서비스들을 만들어 가면서 빠르게 입지를 넓히고 있습니다. 이제 클라우드 시장에는 정말 다양한 선택지가 펼쳐지고 있습니다. 이제 실무 담당자는 가격뿐만이 아니라 기업의 서비스 특성에 맞는 클라우드를 선택해야 합니다.

정창훈 CTO @당근마켓

“서버에 대한 ‘관점의 전환’을 이해하는 것 필수 ”

클라우드 서비스가 보편화 되면서 서버를 바라보는 관점이 바뀌었습니다. 담당자는 이러한 관점의 전환을 이해 해야 합니다.

기존에는 서버를 운영하면서 하드웨어 사양을 미리 좋은 것들을 준비해야 했습니다. 메모리나 하드디스크를 업그레이드하려면 서버를 중지해야 했고 몇 시간이 걸리기도 하고 서비스가 동작하지 않기 때문에 항상 미리 준비하고 계획해야 했습니다. 트래픽이 늘어서 서버를 추가해야 하면 장비를 발주해서 구매하고 OS를 설치하는데 며칠이 걸립니다. 하지만 클라우드에서는 몇 분만에 완료되고 자동으로 모니터링해서 서버를 추가하는 것도 몇 분이면 됩니다.

클라우드 관점에서는 서버에 설치하다가 잘 안 되면 새로운 서버를 실행해서 처음부터 다시 시도하고 기존 서버는 과감하게 버립니다. 서버 하드웨어에 문제가 생기면 그것을 복구하려고 노력하기보다 그 서버는 버리고 새로운 서버를 실행합니다. 이제 서버는 쉽게 쓰고 버리는 개념으로 다가왔습니다.

이러한 관점의 전환을 이해하고 서버를 바라보는 담당자의 생각이 바뀌어야 클라우드 서비스를 제대로 활용할 수 있습니다. 클라우드에서도 기존에 운영하던 방식으로 접근한다면 클라우드 서비스가 주는 장점이 없다고 느낄 수 있습니다.

신현묵 CTO @GooDoc

“클라우드 또한 실 서버 운영과 동일하게 문제가 발생할 수 있어, 꾸준히 모니터링하면서 관리하는 자세 필요”

클라우드가 아니라, 실 서버로 운영을 한다고 하더라도, 문제는 계속 발생할 수 있습니다. 서비스는 중단될 수 있고, 예기치 못한 이슈로 문제를 일으키게 되는 것이 맞습니다. 언제나 죽을 수 있다는 상황을 꾸준하게 모니터링하면서 관리하는 자세가 가장 중요합니다.

10. 앞으로 계속 발전할 클라우드 서비스, 원활하게 운영하려면 어떤 태도를 가져야 할까요?

신현묵 CTO @GooDoc

“서비스는 곧 비즈니스 신뢰와 연결, 안정적인 상황을 위해 균형을 지키는 다소 보수적인 태도가 꼭 필요”

서비스 운영자는 매우 보수적으로 되는 것이 당연합니다. 서비스 중단은 비즈니스의 중단과 신뢰에 매우 큰 영향을 줄 수 있습니다. 보안과 안전성을 지키는 자세를 가지고, 비용이 허락되는 최대한의 리소스를 기업 내부에서 계산하고, 해당 기업의 비즈니스의 속도에 따른 적절한 환경을 구성해야 합니다. 비용은 한정적이고, 대응 자세는 그 역량에 따른 것이니까요. 보수적이고, 안정적인 상황을 위한 균형을 지키려는 태도를 꼭 가지도록 조언하고 싶습니다.

정창훈 CTO @당근마켓

“클라우드 서비스의 장단점을 파악하고, 적절하게 사용하기 위해서 끊임없이 공부하는 자세”

클라우드 서비스에 대해 방어적인 태도를 취하기보다 클라우드 서비스에서 얻을 수 있는 장점을 활용하는 것을 고민해야 합니다. 클라우드 서비스에 대해 계속 공부해서 클라우드 서비스의 장단점을 이해하고 적절하게 사용하는 것이 좋습니다.

*          *          *

 

‘클라우드 서비스’ 프로들과 인맥을 맺고, 새로운 비즈니스 기회를 만나보세요.


정창훈
CTO
@당근마켓

신현묵
CTO
@GooDoc

이동인
CEO
@WhaTap

김세라
마케팅 수석
@네이버 비즈니스 플랫폼

※ [AskMe]는 개인적 경험을 바탕으로 진행된 인터뷰로, 특정 회사의 입장을 대변하는 글이 아님을 밝힙니다.

※ 본 콘텐츠에 대해 궁금한 점이 있으시면 startup@rocketpunch.com으로 연락주세요.