혁신적인 아키텍처 시리즈, 4부

“Would you like coffee with that?”

‘Evolutionary Architectures’는 4부로 구성된 블로그 시리즈로, Startup 수명 주기의 여러 단계를 거치면서 기업의 솔루션 설계 및 의사 결정 방식이 어떻게 변화하는지 보여줍니다. 이 시리즈에서는 Fantasy Sports League와 유사한 ‘판타지 주식 시장’ 애플리케이션을 만들겠다는 아이디어를 가진 Example Startup이라는 회사의 여정을 따라가 봅니다. 이 회사는 일 년 동안 네 차례 ‘토너먼트’를 개최하는 방안을 구상하고 있습니다.

세 번째 블로그 게시물에서는 Startup이 CI/CD 파이프라인 및 코드형 인프라와 같은 도구를 포함하고 특히 보안 및 권한 부여와 관련한 모범 사례를 구현하는 아키텍처로 솔루션을 어떻게 발전시켜나가기 시작하는지를 설명했습니다. 4부에서는 Example Startup이 다양한 규정 준수 표준을 충족하기 위해 보안 및 백업 태세를 공식화하는 과정을 살펴보겠습니다. 또한 여기서 이 회사는 조직을 위한 데이터 전략을 수립하고 제품 포트폴리오를 다양화하기 위해 추가 사업부 설치를 검토합니다.

시리즈 B 펀딩을 통한 채용, 확대 및 확장

상황이 Example Startup에게 유리하게 진행되고 있습니다. 이 회사는 최근에 시리즈 B 펀딩을 마감했으며, 이를 통해 필요한 채용, 확대 및 확장이 가속화될 것으로 예상됩니다. 자금 조달 및 고객의 제품 수용과 함께 경쟁도 심화되었습니다. 이 분야에서 입지를 굳건히 다져온 업체들이 이 회사를 만만찮은 경쟁자로 여기기 시작했고 마케팅 활동을 강화하고 있습니다.

Example Startup은 업무 부서를 증설하고 사이트 신뢰성 엔지니어링(SRE), 플랫폼, 분석 및 데이터 과학을 위한 전담 팀을 구성하기 위해 채용을 시작합니다. 경쟁이 치열한 노동 시장과 전담 인사 부서가 없는 Startup의 한계로 인해, 다시 한 번 AWS Account 팀에 연락하여 능숙한 기술 인재를 찾는 방법을 AWS에 문의했습니다. Account 팀은 이미 이러한 채용 요구 사항을 지원할 수 있는 AWS 파트너를 추천하여 비슷한 상황에 처한 다른 Startup 고객을 도운 경험이 있습니다. 얼마 지나지 않아 Startup은 AWS 관련 경력을 갖춘 선별된 지원자들로부터 이메일을 받습니다. 다행스럽게도 면접을 통해 다수의 지원자에게 일자리를 제안할 수 있었고 이 Startup은 할 일 목록에서 채용 항목을 제외할 수 있게 되었습니다.

그런데 이 채용 건은 기술적인 문제로 이어집니다. 팀들은 Example Startup의 플랫폼 팀이 테스트 목적으로 새 계정을 개설하는 데 너무 오래 걸리고 그로 인해 혁신이 저해되고 있다고 불평합니다. 플랫폼 팀은 누군가가 기능에 대한 새로운 아이디어를 떠올릴 때마다 개별 계정을 만들 여유는 없다고 설명합니다. AWS 여정의 이 시점에 플랫폼 팀은 AWS Account 팀과 격주로 회의를 가지면서 이 딜레마에 대해 이야기합니다. AWS Solutions Architect(SA)는 AWS 조직 내에 샌드박스 전용 조직 단위(OU)를 설치하여 새로운 AWS 서비스 및 기능을 테스트하려는 다른 팀을 위해 임시 리소스와 환경을 신속하게 프로비저닝할 것을 제안합니다. 또한 SA는 비용을 억제하기 위해 자동화 기능을 활용하여 정규 업무 시간 외에는 Amazon EC2 인스턴스와 같은 리소스를 자동으로 중지할 것을 권장합니다. Example Startup의 플랫폼 팀은 SA의 조언을 따릅니다. Startup 전반에 걸쳐 다양한 팀의 계정을 신속하게 개설하고 비용을 통제할 수 있게 되었습니다.

그 후 새로 고용된 SRE 팀은 이 Startup이 가용성 및 재해 복구(DR)의 관점에서 더 나은 환경을 갖출 수 있겠다고 판단하게 되었습니다. 그들은 이 Startup이 빠르게 성장하고 있고 대규모 고객을 대상으로 서비스를 제공하기 시작하면서 감사 및 규정 준수 검토와 같은 더욱 엄격한 보안 요구 사항에 직면하게 될 것임을 알고 있습니다. 이는 인프라를 변경해야 한다는 의미였습니다. 다행히 Example Startup이 시리즈 3부에서 인프라를 Terraform으로 템플릿화하고 다중 계정 아키텍처로 전환하면서 재해 복구와 관련된 많은 작업이 이미 이루어진 상태였습니다.

첫 단계로, Example Startup 팀은 AWS Resilience Hub 사용법을 익히면서 AWS에서 복원력이 뛰어난 애플리케이션을 구축하는 방법을 자세히 알아봅니다. 이 팀은 아직 해결하지 못한 몇 가지 의문점이 남아 있었기에, AWS Account 팀에 문의하여 복원력과 관련한 전문 지식을 갖춘 SA를 소개받습니다. 이 SA는 Example Startup과 협력하여 Recovery Time Objective(RTO) 및 Recovery Point Objective(RPO) 요구 사항을 지정하고 다양한 재해 복구 시나리오에 대한 비용/편익 분석을 수행합니다. SA와 몇 차례 전화 통화를 하고 수많은 내부 검토를 거친 끝에 SRE 팀은 RTO/RPO 요구 사항이 아직 다중 리전 설정이 필요한 정도는 아니라는 결론을 내렸습니다. 그리고 Amazon RDS for PostgreSQL에서 Amazon Aurora for PostgreSQL로 거래 데이터를 이전하기로 결정합니다. 이는 이 서비스가 제공하는 더 높은 가용성과 프로덕션 데이터베이스에서 중요한 Amazon Aurora 글로벌 데이터베이스 기능이 결정의 주된 이유였습니다. 또한 이 Startup은 AWS Audit Manager를 사용하여 예정된 감사에 대비해 관련 규정 준수 표준을 준수하고 있는지를 평가합니다. 자동화된 증거 수집 기능을 통해 수고를 많이 덜 수 있습니다.

보다 나은 고객 경험 구축

Chief Technology Officer(CTO)가 다양한 고객의 제품 피드백을 살펴본 결과 Example Startup의 거래 애플리케이션에서 트레이더에게 제공되는 대시보드 기능이 부족하다는 사실을 알게 되었습니다. 경쟁사를 이용하는 사용자들은 거래 수준별 거래 내역 및 실적(다른 트레이더와 비교)을 시각적으로 손쉽게 볼 수 있습니다. CTO는 이를 중대한 기능 격차로 지적하고 신규 분석 팀에 작업을 배정했습니다. 또한 CTO는 트레이더가 언제든 거래 보고서를 작성할 수 있도록 만들기를 이 팀에 요청합니다.

분석 팀은 Amazon Quicksight를 사용해 본 경험이 있기 때문에 트레이더가 정상치를 벗어난 특정 거래를 찾는 데 도움이 되는이상 탐지 기능을 비롯하여 대시보드 구성 요소를 간단하게 개선할 수 있습니다. 보고 요청의 경우에는 프로덕션 데이터베이스에서 보고서를 실행하여 개발자 팀에게 문제를 안겨주고 싶지는 않은 만큼 더 복잡한 문제입니다(이는 좋은 방법으로도 간주되지 않음). AWS 기반 현대적 데이터 아키텍처 백서를 참조한 끝에, 분석 팀은 Amazon RDS for PostgreSQL 데이터를 데이터 웨어하우스인 Amazon Redshift에 로드하는 것이 가장 좋은 방법이라는 것을 깨달았습니다. Amazon Redshift의 대규모 병렬 처리 기능을 사용하면 훨씬 짧은 지연 시간으로 이 거래 데이터에 대해 복잡한 집계를 실행할 수 있을 뿐만 아니라, 프로덕션 데이터베이스에서 병목 현상이 발생하지 않는다는 추가적인 이점도 있습니다. 분석 팀은 Amazon Redshift가 PostgreSQL 엔진을 기반으로 구축되었기 때문에 대부분의 쿼리를 재사용할 수 있다는 사실을 알게 되어 매우 만족하고 있습니다.

Startup에 새로운 사업부 추가

이러한 모든 변화가 일어나자 Chief Executive Officer(CEO)는 유력 트레이딩 회사의 전 동료 중 한 명과 회의를 가집니다. CEO는 시장에 유능한 트레이더가 부족하고, 이 문제가 트레이딩 회사의 채용 파이프라인과 향후 프로젝트에 부정적인 영향을 미치고 있다는 사실을 알게 됩니다. CEO는 트레이딩 회사의 친구 몇 명에게 전화를 걸어 이러한 인재 부족 문제가 업계 전반에서 나타나고 있다는 사실을 확인합니다. 이에 CEO는 아이디어를 구상하기 시작합니다. Example Startup에는 실적이 좋은 트레이더가 많이 있습니다. Example Startup이 트레이더에게 일종의 코호트 기반 교육을 제공하고 이러한 트레이딩 회사의 인재 파이프라인에 반영한다면 어떨까라는 아이디어가 떠올랐습니다. 이를 통해 트레이더들은 취업 시장에 진입할 수 있는 기회를 갖게 될 것이고 트레이딩 회사들은 새로운 인재를 확보하게 될 것입니다.

신입 교육생에게 올바른 거래를 추천하는 것이 교육의 핵심적인 부분이므로, CEO는 데이터 과학 팀과 통화하여 기계 학습(ML) 모델을 얼마나 빨리 구축할 수 있는지 알아봅니다. 다행히 몇몇 데이터 과학 팀원이 Amazon Sagemaker를 사용하여 모델을 구축, 훈련 및 배포한 경험을 갖고 있습니다. Amazon Redshift는 SageMaker에서 사용할 수 있는 데이터 소스 중 하나이므로, 데이터 과학 팀은 복잡한 추출, 전환, 적재(ETL) 파이프라인을 설정할 필요가 없습니다. SageMaker와 관련한 작업 경험이 많지 않은 데이터 과학 팀원의 경우 AWS Account 팀이 SageMaker를 중점적으로 다루는 Immersion Day에 초대하여 빠르게 기술 역량을 향상시켰습니다. 머지 않아 이들 역시 훈련 작업을 생성하고, 정확한 모델을 구축하며, 엔드포인트에 모델을 배포하기 시작했습니다. 데이터 과학 팀은 증가하는 컴퓨팅 비용에 대한 Example Startup 재무 팀의 요청을 미리 예상하여 몇 가지 조사를 수행한 끝에 실제로 전체 비용의 약 80%를 차지하는 훈련 작업을 스팟 인스턴스에서 실행할 수 있다는 사실을 발견했습니다. 이를 통해 비용을 크게 절감할 수 있었습니다.

이 인재 개발 이니셔티브가 신규 사업부로 발전하고 새로운 매출원으로 부상했다는 소식이 업계 전반에 퍼지면서, 더 많은 벤처 캐피털(VC) 회사들이 Example Startup에 관심을 보이기 시작했습니다. 이 Startup이 또 다른 펀딩 라운드를 시작하겠다는 의사를 밝히기도 전에 말입니다.

몇 분기가 지난 후, 마케팅 활동, AWS와의 공동 마케팅 활동, 기존 고객의 입소문에 힘입어 Example Startup의 인재 개발 이니셔티브는 급속도로 성장했습니다. 고객 기반의 성장이 고무적인 것은 맞지만, 그보다 이 Startup이 창립 이래 처음으로 흑자를 기록하고 있다는 사실이 더 고무적이었습니다. 채용 서비스는 이 Startup에 있어 수익성 높은 사업으로 판명되었으며, 나날이 성장하고 있습니다. 경영진은 이러한 꾸준한 수익성이 나머지 비즈니스에 활력을 불어넣을 수 있다는 사실을 알고 있습니다. 이 회사는 앞으로의 밝은 미래를 기대하며 추가적인 확장 및 혁신 계획을 열심히 진행하고 있습니다.

요약

4부로 구성된 이 시리즈에서 Example Startup은 초기 단계부터 성숙한 회사로 성장하는 단계까지, Startup의 주요 성장 단계를 거칩니다. 대부분의 Startup은 대담한 아이디어와 헌신적인 창업 팀만 가지고 시작합니다. 이들은 창업 팀이 자체적으로 관리할 수 있는 방식으로 아이디어를 테스트할 수 있는 서버리스 인프라를 갖춘 최소 기능 제품(MVP)을 구축합니다.

Startup이 유료 고객을 확보하고 시드 단계 이후 자금을 확보하면서 ‘실질적인 착수’ 단계로 넘어갑니다. 이 단계에서는 아키텍처가 발전하고 확장, 보안 및 개발 민첩성에 대해 진지하게 고민하기 시작합니다. 즉, 빌드 도구 사용, 모니터링 및 전용 데이터베이스 설정과 같은 개선이 요구되는 단계입니다.

이 단계에서 가장 중요한 교훈 중 하나는 프로젝트를 시작하기 전이라도, 조기에 그리고 자주 AWS 팀과 협력하여 옵션을 평가하고 시간을 절약하기 위한 도움을 받는 것입니다. 비즈니스 및 기술 리소스 모두에 접근할 수 있게 되면 일정을 단축하고 초기 단계의 Startup 팀이 목표를 달성하는 데 도움이 될 수 있습니다.

제품 시장 적응 단계가 끝나면 Startup은 더 많은 인재를 채용하기 시작하고 ‘목표 추구’ 단계의 확장에 집중할 수 있습니다. 이제 서비스 지향 아키텍처, 캐싱 및 기타 아키텍처 조정 기법을 사용하여 기술적 관점에서 애플리케이션을 최적화하고 고객 경험을 개선하는 다중 계정 전략을 모색하기 시작합니다.

마지막으로 대규모 채용을 시작하고 추가 사업부를 구축하는 하이퍼스케일 단계에 진입합니다. 기술적 관점에서 이 Startup은 환경에 대한 보안, 제어 및 권한과 같은 사항을 개선하는 데 많은 시간과 엔지니어링 작업 시간을 투자했습니다. 이 회사는 다양한 사용 사례 중에서도 신속한 국제 사업 확장과 재해 복구에 활용할 수 있는 코드화된 환경 버전이라는 사용 사례를 가지고 있을 것입니다. 또한 데이터 전략을 수립했으며 고객과 비즈니스를 보다 효과적으로 파악하기 위해 분석과 기계 학습을 활용하는 중입니다. 이 마지막 단계는 달라질 수 있습니다. 인수 절차를 진행하는 Startup도 있을 수 있고, 수익성과 시장 지배력을 추구하는 Startup도 있을 수 있습니다.

Startup 여정을 시작할 준비가 되셨나요? AWS Activate에 가입하여 적시에 적절한 리소스로 Startup을 구축하고 확장하세요.

혁신적인 아키텍처 시리즈를 모두 참조하세요.

• 혁신적인 아키텍처, 1부 — “정말 멋진 아이디어가 떠올랐어요!”
• 혁신적인 아키텍처, 2부 — “우리가 무언가에 몰두하고 있는 것 같아요.”
• 혁신적인 아키텍처, 3부 — “달로 나아갑시다.”