AWS를 쓰는 스타트업 창업자가 자주하는 10가지 실수들 – 이것만은 피하세요!
스타트업이 빠르게 서비스를 만들고, 이를 확장하기 위해 클라우드를 사용해야 한다는 것은 모든 창업자들이 알고 있습니다. 모든 스타트업이 AWS 전문가를 가지고 있지 않기 때문에, 창업자가 서비스가 아주 작을 때 부터 작은 것 부터 신경쓰지 않는다면, 향후 상당히 어려운 문제에 직문하게 됩니다. AWS를 사용하기로 결정한 스타트업에서 기술적인 배경을 가지고 있지 않는 창업자가 꼭 피해야 하는 실수들을 찾아 보았습니다.
저희는 Startup Solutions Architects로서 Y! Combinator(YC) 및 TechStars를 포함한 세계 최고의 액셀러레이터에서 초기 단계의 스타트업에 대한 기술 고문으로 일하고 있는데, 수천 개의 스타트업을 일대일로 만나면서 얻은 것들을 조언들과 함께 작성해 보았습니다.
실수 #1: AWS Budget 기능을 설정하지 않았다
아무도 요금 폭탄 같은 깜짝 요금 청구서를 좋아하지 않습니다. AWS는 사용한 만큼 필요한 자원을 언제든지 저렴하게 사용할 수 있는 데도 불구하고, 비싸다는 인식이 있는 것은 클라우드 예산에 대한 기본적인 이해가 부족한 것이 큰 원인입니다. 클라우드를 활용하려는 클라우드 창업자라면 클라우드 비용 경제학에 대해 잘 알고 계셔야 합니다.
AWS Budget 기능은 요금에 대한 안전망과 조기 경보 시스템입니다. 스타트업이 예산을 설정해야 하는 이유와 AWS 예산으로 쉽게 설정하는 방법을 확인해서 바로 지금 설정하세요. 예산과 알림을 설정하는 데 5분밖에 걸리지 않습니다.
실수 #2: AWS Business Support를 활용하지 않았다
AWS를 계정을 처음 사용할 때, Support 프로그램을 선택하게 되는데요. 개인이라면 무료 플랜을 사용해도 무방합니다만. 스타트업아라면 당연히 AWS Business Support를 활용해야 합니다. 여러분 회사 개발자가 아무리 뛰어나도 AWS를 활용하는 동안에 어려운 문제에 봉착할 수도 있습니다. 시간은 스타트업에게 있어 핵심입니다.
AWS Business Support는 심각한 문제를 빠르게 도와 줄 수 있습니다. 이메일/채팅 등으로 필요한 질의를 할 수 있고, 프로적션 시스템의 중단 및 손상에 대해 1시간 혹은 4시간 내에 응답합니다. 매월 요금의 3~10% 정도의 추가 비용만 지불하면 되니까, 초기 스타트업의 경우 전담 인력 보다도 더 경제적입니다.
실수 #3: 루트 계정으로만 운영하고 있었다
AWS 계정을 처음 생성할 때, 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 단일 로그인으로 시작합니다. 이를 AWS 계정 루트 사용자라고 합니다. 계정을 만들 때 사용한 이메일 주소와 비밀번호를 사용하여 루트 사용자로 로그인할 수 있습니다. 그런데, 창업자는 회사 계정으로서 이 계정을 함부로 위임을 하면 안됩니다. 이 계정은 오로지 비용 및 전체 운영상 관리로만 사용하고, 각 컴퓨팅 리소스는 AWS IAM 서비스를 활용해서 추가적인 IAM User를 추가해야 합니다.
기본적인 보안 장벽을 구축해 두면 향후 발생 가능한 인증/권한 문제, 요금 관련 문제를 피할 수 있습니다. AWS IAM 서비스가 조금 어렵게 느껴지더라도 창업자가 꼭 챙기셔야 합니다.
실수 #4: 멀티 팩터 인증(MFA)을 설정하지 않았다
AWS 계정 루트 사용자는 이메일 주소와 비밀번호로 로그인할 수 있습니다. 이 말은 이 두 가지 정보가 외부로 유출되면 언제든지 해킹 당할 수 있다는 것을 의미합니다. 따라서, 루트 계정과 IAM 사용자 계정 등 모든 AWS 계정에는 멀티 팩터 인증(MFA)을 설정해야 합니다. 마치 인터넷 뱅킹할 때, 모바일 기기나 SMS 같은 2차 인증 수단을 통해 한번 더 인증 확인을 하는 것인데요. 계정에 대한 무단 액세스를 방지하는 데 도움이 됩니다.
그런데, 많은 개발자들이 로그인 시 조금 귀찮아서 설정 안하는 경향이 있습니다. 다양한 사회 공학적 해킹으로 인해 계정이 침해되는 경우, 스타트업에서는 치명적인 문제가 될 수 있습니다. 그래서 창업자들이 꼭 챙겨야 하는 것입니다.
실수 #5: 인프라로서 코드(Infrastructure as Code) 기능을 사용하지 않았다
클라우드 컴퓨팅의 장점 중에 하나가 모든 컴퓨팅 리소스를 프로그램 코드로 표현 가능하다는 것입니다. 따라서, 여러분의 스타트업에서 운영하는 가상 서버, 데이터베이스, 네트워크 설정 등은 모두 코드로 설정할 수 있습니다. 대개 개발자들이 콘솔에서 손으로 한땀 한땀 서버를 세팅하는 경향이 있는데, 이럴 경우 향후 재현을 하거나, 문제가 생겨서 복구를 하기가 상당히 어렵습니다.
인프라로서 코드 (Infrastructure as Code) 기능을 사용하면 콘솔을 통해 수동으로 작업을 수행하는 대신 구성 파일을 사용하여 인프라를 관리할 수 있습니다. 초기의 약간의 귀찮음이 따르지만, 나중에 상당한 관리상 이득이 될 것입니다. 창업자가 개발자들에게 IaC를 사용하도록 꼭 독려하세요.
실수 #6: 액세스 키를 누가 어디서 사용하고 있는지 모른다
클라우드 내 자원을 프로그램 코드로 제어를 하려면, 콘솔이 아니라 프로그램 언어에서 API 호출을 통해 하게 됩니다. 이를 위해서 우리는 루트 계정 혹은 IAM User가 가진 권한과 똑같은 Access ID 및 Access Secret Key라는 인증 코드를 사용합니다. 사실상 아이디와 비밀번호와 똑같은 것입니다. 실수로 이 코드가 유출이 되면, 계정 아이디와 비밀번호가 유출된 것 과 똑같은 피해가 생길 수 있습니다.
이를 제어하는 방법이 바로 AWS IAM Role을 사용하는 것입니다. 특정한 직무에 따라 역할에 대한 권한을 부여하고, 그 역할에 사용자를 연결하는 방법입니다. IAM Role은 AWS 서비스에 대한 권한을 세부적으로 설정할 수 있기 때문에, 굳이 Access ID/Key를 사용하지 않더라도 운영에 도움을 받을 수 있습니다. 특히, IAM Role은 사용자를 대신하여 AWS 서비스들 사이에 작업도 가능하기 때문에, 사람의 관리 영향을 최소화 할 수 있습니다.
액세스 키, IAM 역할, IAM 사용자… 무엇을 언제 사용해야 할지 혼란스러울 수 있습니다. 고객과의 신뢰를 얻기 위해 데이터를 안전하게 유지하는 것은 매우 중요하기 때문에 개발자들과 어떤게 더 나은 방법인지 계속 질문을 하시기 바랍니다.
실수 #7: 모든 것을 처음 부터 직접 만들고 운영한다
대개 개발자들은 처음 부터 바닥에서 새롭게 만드는 것을 선호합니다. 그런데, 스타트업은 그런 식으로 사업을 했다가는 속도와 생산성을 맞추지 못합니다. 요즘 대부분 스타트업은 회사 내부 시스템인 업무 처리, 소통, 채용, 경비 처리, 계약 같은 것도 모두 소프트웨어 서비스(Software as a Service, SaaS)에 맡기고 있습니다. 그것은 비핵심 업무에 드는 노력을 핵심 자원에 투자를 하기 위해서일 겁니다.
클라우드에서도 이런 관리 및 비용 상 이점을 얻을 수 있는 AWS 관리형 서비스를 제공하고 있습니다. 만약 여러분 개발자들이 데이터베이스 운영을 위해 AWS가 제공하는 관리형 서비스인 Amazon RDS를 사용하지 않고, Amazon EC2에 DB를 직접 설치하고 있는지 확인하셔야 합니다. Amazon RDS를 사용하는 것이 장기적인 관리 비용을 아끼는 길입니다.
실수 #8: 콘텐츠 배포 기능을 사용하지 않았다
여러분의 서비스를 더 많은 사용자에게 더 빠르게 전달하기 위해서는 처음 부터 콘텐츠 배포 네트워크(Content Delievery Network)를 이용해야 합니다. CDN 서비스는 이미 많은 기업들이 일반 사용자에게 서비스에 많이 활용되는 이미지, 동영상 전달을 효율적으로 하기 위한 수단으로 사용하고 있습니다. CDN 서비스는 더 비싼 컴퓨팅 자원을 아껴 주기 때문에 경제적일 뿐만 아니라, 전 세계 어디에 있는 사용자에게 서비스 지연을 줄여줄 수 있다는 장점이 있습니다. AWS에서는 Amazon CloudFront라는 CDN 서비스가 있는데, 아직 사용하고 있지 않다면 바로 알아보시기 바랍니다.
실수 #9: 사용하지 않는 리소스를 계속 실행하고 있다
여기에 개발자들의 귀찮니즘이 한번 더 작용합니다. 불 켜놓고 퇴근하거나, 잠을 자면 전기가 낭비되는 것처럼 사용하지 않는 리소스를 켜 두면 뜻밖의 AWS 요금 청구서를 받을 수 있습니다. 그런데, 어떤 클라우드 리소스를 끌지, 언제 끌지 지정하거나 알아내는 방법이 항상 명확한 것은 아닙니다.
몇 가지 솔루션이 있는데 먼저 AWS Instance Scheduler는 고객이 Amazon EC2 및 Amazon RDS 인스턴스에 대한 사용자 지정 시작 및 중지 일정을 자동으로 구성할 수 있는 AWS 솔루션입니다. 이 솔루션은 배포하기 쉽고 개발 및 프로덕션 환경 모두에 대한 운영 비용을 줄이는 데 도움이 될 수 있습니다. 이 솔루션을 사용하여 정규 업무 시간 동안 인스턴스를 실행하는 고객은 해당 인스턴스를 하루 24시간 실행하는 것에 비해 최대 70%를 절약할 수 있습니다.
조금 다른 관점으로 AWS에서는 자원을 끄거나 켜는 대신 아예 필요할 때 요청당으로 과금하는 서버리스 모델을 가진 서비스들이 있습니다. 예를 들어 EC2 인스턴스를 사용하여 API 서비스를 구축했다면, 이를 Amazon API Gateway와 AWS Lambda 서비스를 활용하면 서버당 비용이 아니라 시간과 비용을 모두 절약할 수 있습니다. 서버리스 기반의 개발 모델을 도전해 보세요.
실수 #10: 모든 데이터를 RDB에 때려박고 있다
초기 스타트업이 내려야 하는 가장 첫 기술적은 결정 중 하다가 서비스에 사용할 데이터베이스를 정하는 것 입니다. 데이터베이스 선택은 애플리케이션의 성능과 팀의 생산성에 장기적인 영향을 미치는 기술적 결정 중 하나입니다. 그런데, 애플리케이션의 특성과 상관없이 그냥 쉽게 시작할 수 있다는 이유 하나 만으로 관계형 데이터베이스(RDBMS)를 선택하는 경우가 많습니다.
현대적 애플리케이션은 다양한 데이터 요구 사항이 있고, 이를 바탕으로 AWS는 애플리케이션 목적에 따른 다양한 DB 유형을 관리형으로 제공하고 있습니다. 여러분의 애플리케이션의 요구 사항을 먼저 정의하십시오. 그런 다음 시장 출시 속도와 팀의 가용 기술을 고려하여, AWS의 DB 선택 옵션을 선택하세요. 지금 시간을 들여 이러한 요소를 고려하고 작업에 가장 적합한 데이터베이스 서비스를 선택하는 것이 중요합니다. (이런 고려 없이 서비스를 시작했다면, 지금이라도 늦지 않았습니다.)
우리 모두 실수를한다!
지금까지 언급한 실수 목록은 꼭 다 해결해야 하는 것은 아닙니다. 각 실수의 영향은 스타트업의 각 서비스 단계에 따라 다르므로, 우선 순위에 따라 지금 당장 해결을 해야할 좋은 시기가 아닐 수 있습니다. 하지만, 스타트업 창업자로서 이러한 문제를 어쨌거나 해결하지 않고 방치해 둔다면, 여러분의 스타트업 수명에 어떤 영향을 미칠 수 있는지 인식하는 것이 중요합니다. Y! Combinator의 Essential Startup Advice에 아래의 내용이 있습니다.
“유니콘이 된 스타트업을 포함해서 모든 스타트업이 심각한 문제를 안고 있었습니다. 그들의 성공 여부는 처음에 실패했는지 여부가 아니라 창업자가 피할 수 없는 문제에 대해 어떻게 행동 했느냐에 따라 결정됩니다. 창업자의 회사 운영은 침몰하는 배를 계속해서 바로잡는 일처럼 보일 것입니다. 이것은 아주 정상입니다.” – 제프 랄스턴, 마이클 세이벨
여러분의 CTO나 개발자들과 함께 의논해서 최선의 판단을 기반으로 운선 순위를 정하되, 무엇 보다 계정 보안에 영향을 주는 부분을 맨 먼저 시작하시기 바랍니다.
– Britton Winterrose (AWS 스타트업 솔루션즈 아키텍트) 및 Channy(윤석찬)
이 글은 AWS Startup Blog의 Ten Mistakes Founders Make on AWS, and How to Avoid Them를 한국어로 번역 후, 편집을 통해 내용을 추가하였습니다.
Source: AWS를 쓰는 스타트업 창업자가 자주하는 10가지 실수들 – 이것만은 피하세요!
