2021.06.01

벤더 기고ㅣ엔터프라이즈를 위한 서버리스 퍼스트 전략

최인영 | CIO KR

아마존 CTO 버너 보겔스 박사는 2019년 re:Invent 키노트 세션을 통해 "AWS에서 기대하는 미래의 모습은, 개발자가 작성하는 모든 코드는 오직 비즈니스 로직일 뿐입니다"라고 언급했다. 이 짧은 한 문장은 많은 의미를 함축하고 있다. 일반적으로 개발자는 비즈니스 로직을 구현하는 것 외에 애플리케이션의 스케일링, 인프라 오케스트레이션, 가용성, 보안, 배포 등도 고려해서 개발한다. 대부분의 근무 시간을 비즈니스 로직 구현에 할당해야 하지만 현실은 부가적인 일에 생각보다 많은 시간을 할애하고 있는 것이 사실이다.

* 벤더가 작성한 본 기고문은 벤더의 시각과 주장, 솔루션에 대한 직접적인 내용을 담고 있다.

하지만 가까운 미래에는 개발자가 비즈니스 로직을 구현하는 일에 보다 집중할 수 있는 환경이 될 것으로 전망한다. 필자는 ‘개발자가 비즈니스 로직을 구현하는 일에 집중’할 수 있다는 말의 배경에는 ‘서버리스 컴퓨팅(Serverless computing)의 확산과 발전’이 큰 역할을 할 것으로 본다.

컴퓨팅 환경의 진화
서버리스 컴퓨팅에 대해 얘기하기 전에 먼저 컴퓨팅의 환경이 어떻게 진화했는지 알아보고자 한다.

• 우리가 알고 있는 '서버(Servers)'
불과 10여년 전만 해도 새로운 서비스를 개발하기 위해서는 물리 서버를 구매하는 것을 당연하게 생각했다. 일반적으로 5년(또는 3년)을 기준으로, 사용자 트래픽 증가를 고려해서 용량을 산정하고 그 용량을 기반으로 서버와 스토리지, 네트워크 장비 등의 스펙을 결정했다. 

물리 서버들이 데이터센터에 입고되고 랙에 스택킹이 된 후 UTP 케이블이 서버에 연결되면 이때부터 본격적인 서버 작업이 시작된다. 이후 OS를 설치하고, 정책에 기술된 보안 패키지 설치와 구성 설정을 하고, 서버 관리를 위한 다양한 유틸리티를 설치하며, 네트워크 툴을 설치하고, 백업을 위한 스크립트 등 수 많은 작업을 수행했다.

보통 시스템 엔지니어들은 항상 수십(또는 수백) 페이지에 달하는 자기만의 서버 설치와 구성 작업을 위한 매뉴얼을 가지고 있었다. 다시 얘기하지만 이런 일은 불과 10여년 전의 얘기다.

• 가상 머신(Virtual Machines)
서버 리소스(예: CPU, Memory 등)의 사용률(Utilization)을 높이고 확장성(Scalability)의 요구에 대응하기 위한 방안으로 가상 머신(Virtual Machine)이 등장했다. 이는 미리 준비된 서버 이미지를 기반으로 배포를 단순화한다. 서버 이미지에는 필요한 대부분의 작업(OS 설치/패치/구성, 유틸리티 설치, 보안 등)을 미리 준비해놓고 재사용했다. 이러한 방식은 매우 효율적으로 잘 작동하고 있었고, 서버의 효율을 높였다. 장애가 발생해도 서버 구성이 빠르게 되기 때문에 다운 타임(Down time)도 예전보다는 많이 줄었다.

• 컨테이너(Containers)
2013년 파이콘(PyCon)에서 처음으로 소개된 도커(Docker)는 애플리케이션 개발과 배포의 방식을 완전히 바꿨다(컨테이너 기술 자체는 훨씬 오랜 역사를 가지고 있다). 도커 컨테이너는 애플리케이션 코드와 라이브러리, 런타임, 시스템 툴 등 애플리케이션 실행에 필요한 모든 것을 포함해서 완전한 하나의 컨테이너 이미지로 패키징한다. 그리고 이 컨테이너 이미지 자체로 애플리케이션을 배포한다. 

애플리케이션 실행에 필요한 모든 것을 하나의 컨테이너 이미지로 패키징하기 때문에 '불변(Immutable)'의 성질을 가지게 된다. 또한 컨테이너 기술은 OS를 가상화하는 가상 머신(Virtual machines) 기술과는 다르게 호스트 OS에 있는 자원을 공유해서 사용하고 프로세스를 격리하는 방식으로 작동된다. 따라서 물리 서버 자원(CPU, Memory 등)의 성능 손실이 거의 없다.

• 서버리스(Serverless)
서버리스를 생각하면 아마도 제일 먼저 떠올리게 되는 것이 AWS 람다(Lambda)일 것이다. 서버를 프로비저닝하거나 관리할 필요가 없는 AWS 람다는 2014년 11월 처음 소개된 후로 사용자가 유용하게 사용하는 서비스로 자리 잡았고, AWS 자체 플랫폼에서도 많이 사용되고 있다.

AWS 람다는 기본적으로 대부분의 주요 개발 언어(Node.js, Python, Go, Java, C#, Ruby 등)를 지원하고 워크로드 변화에 정확히 맞도록 스케일링이 조정된다. 또한 2020년 12월부터 AWS 람다 함수 실행 시간에 대해 1밀리 초 단위의 과금 정책이 적용됐다. 개발자는 단지 코드를 작성하고 ZIP 파일 또는 컨테이너 이미지로 업로드하면 된다. 

서버리스 서비스에는 AWS 람다만 있는 것이 아니다. 앞서 얘기했던 컨테이너 실행을 위한 서버리스 컴퓨팅 서비스인 AWS 파게이트(Fargate)도 있다. 이 밖에도 다양한 서버리스 서비스(예: 애플리케이션 통합을 위한 Amazon EventBridge, AWS Step Functions, Amazon SQS, Amazon SNS, Amazon API Gateway, AWS AppSync, 데이터 스토어를 위한 Amazon S3, Amazon DynamoDB, Amazon RDS Proxy, Amazon Aurora Serverless)가 있다.

서버리스 컴퓨팅(Serverless computing) 다시 생각하기
대부분 ‘서버리스 컴퓨팅’은 기술과 관련성 높은 용어라고 인식하는 경향이 있다. 틀린 얘기는 아니지만 IT 조직이 기술을 선택하기 위한 접근 전략으로 바라볼 필요가 있다고 생각한다. 앞서 컴퓨팅 환경의 진화에서 서버리스에 대해 살펴봤지만 서버리스 컴퓨팅의 정의부터 다시 짚고 넘어가 보고자 한다.

위키백과에 따르면 ‘서버리스 컴퓨팅은 클라우드 제공자가 컴퓨팅 리소스를 온디맨드로 할당하고 고객을 대신해서 서버를 관리하는 클라우드 컴퓨팅의 실행 모델’이라고 정의하고 있다. 서버리스라는 용어 자체가 내포하는 의미와는 다르게 실제 서버가 없는 것은 아니고 클라우드 제공자가 고객의 애플리케이션을 실행하기 위해 서버를 포함한 인프라스트럭처와 실행 환경을 대신 관리하고 운영을 해주는 것을 의미한다.

이제 필자가 서버리스 컴퓨팅을 조직의 기술 선택을 위한 접근 전략이라고 얘기하는 이유를 설명하고자 한다. 

AWS는 개발자가 인프라스트럭처 관리와 유지보수를 신경 쓰지 않고 오로지 비즈니스 로직과 관련된 애플리케이션 기능 구현에 집중할 수 있도록 추상화의 수준(실제 서버가 보이지 않도록)을 한층 높였다.

사용자 입장에서 ‘서버가 보이지 않는다’의 의미는 더 이상 용량 산정, 리소스 프로비저닝, 패치 등의 작업을 신경 쓰지 않아도 되고, 개발자와 엔지니어가 신경 써야 하는 애플리케이션의 확장성(Scalability)을 고민하지 않아도 된다는 얘기와 같다. 

이것은 조직의 IT 전략과 밀접한 관련이 있다. 대부분의 엔터프라이즈 조직은 최적화(아쉽지만 최적화는 최소화와 동의어처럼 사용되는 경우가 많다)된 IT 인력으로 구성되어 운영되고 있다. 대부분의 IT 조직은 비즈니스 유저의 요구 사항을 반영해서 서비스와 기능을 구현하는 일만으로도 버거운 상황이다.

IT 조직이 비즈니스를 지원하는 역할을 넘어서 비즈니스를 차별화하는 역할로 거듭나기 위해서는 IT 업무 생산성을 최대한으로 높이는 것이 매우 중요하다. 따라서 조직의 리더십은 개발자와 엔지니어가 애플리케이션 구축과 실행, 운영을 위한 인프라스트럭처를 고민하지 않게 하고 비즈니스 로직 구현과 실험에 그 시간을 온전히 투자토록 하는 것이 중요한 전략이다.

또 AWS의 서버리스 서비스는 종량제 요금 모델을 기반으로 하기 때문에 사용하지 않는 컴퓨팅 리소스에 대해서는 요금을 지불하지 않아도 된다. 더불어 서비스 자체의 고가용성과 오토 스케일링(Auto Scaling) 기능을 제공해 애플리케이션의 운영 효율성을 극대화할 수 있다.

서버리스 퍼스트 전략(Serverless first strategy) 이란?
서버리스 퍼스트 접근 전략은 애플리케이션을 개발할 때 서버리스 서비스를 중심으로 아키텍처를 설계하고 만약 예외 상황이 발생했을 경우에는 기존 방식을 고려하는 전략이다. IT 조직이 수행해야 하는 ‘차별화되지 않는(Undifferentiated heavy lifting)’ 운영 업무를 줄이고 새로운 기능과 서비스를 신속하게 제공하기 위한 핵심 업무에 집중한다.

혹자는 기존 방식에서도 고객과 비즈니스 유저의 요구에 맞춰 충분히 신속하게 빠르게 서비스를 출시하고 있다고 얘기를 한다. 이렇게 생각하는 배경에는 아마도 기존 IT의 역할에 대한 마인드셋(Mindset)이 크게 작용했을 것이다. 

기존 비즈니스 환경에서 IT의 역할은 매우 중요한 부분을 수행해 왔고 기업의 비즈니스를 지원하는 부서로서의 역할에 충실했다. 비즈니스 유저들의 요구를 잘 지원하기 위해 업무 프로세스 속도를 향상시키고 신뢰성과 정확도, 비용 효율을 높이는 것을 항상 염두에 두고 일을 했다. 

하지만 결정적으로 기존 IT의 역할은 경쟁환경에서의 비즈니스 차별화에 크게 기여하지 못한 듯 하다. 넷플릭스, 쿠팡, 배달의 민족 등의 사례를 보면 IT를 비즈니스 지원의 역할이 아닌 비즈니스 자체를 차별화하기 위한 역할로 새롭게 포지셔닝했다고 볼 수 있다. 기존 시장에 국한하지 않고 새로운 시장을 개척하기 위해 아이디어를 실험하고 제품들을 빠르게 출시한다. 이들의 공통점은 거의 모든 서비스를 클라우드에 기반해서 운영하고 있다는 점이다.

클라우드에 기반하고 있다는 얘기는 핵심 업무(비즈니스 로직 구현)에 대부분의 리소스를 집중하고 있다는 얘기와 동일하게 볼 수 있다. 또한 IT 기술을 빠르게 익히고, 익힌 기술을 새로운 기능을 실험하는 데 사용하고 있다는 뜻이다. 

엔터프라이즈가 이러한 디지털 기반의 혁신기업들과 경쟁하고 고객에게 더 혁신적인 서비스를 제공하기 위해서는 기존 IT의 역할을 재고해야 한다.

엔터프라이즈가 서버리스 퍼스트 전략을 선택해야 하는 이유
현대 경영학의 대가 마이클 포터는 전략(Strategy)을 ‘우리가 무엇을 할 것인가 보다는 무엇을 하지 않을 것인가(Strategy is defined by what your are NOT doing)’를 의미한다고 말했다. 이미 답은 제시된 것 같다. 

IT 조직이 고객과 비즈니스 유저의 요구에 신속히 대응하고 비즈니스를 차별화하기 위해서는 최대한 핵심 업무(비즈니스 로직 구현)에 집중하고 주변의 일을 줄여야 한다. IT 조직이 ‘하지 않을 그 무엇’을 목록화해서 정리해보면 서버리스 서비스가 올바른 전략이라는 것을 이해할 수 있을 것이다. 

다시 정리하자면, 서버리스 퍼스트 접근 전략은 애플리케이션을 개발할 때 서버리스 서비스를 중심으로 아키텍처를 설계하고 만약 예외 상황이 발생했을 경우 기존 방식을 고려하는 전략이다. 무조건 서버리스 서비스를 사용하라는 건 아니다.

어디서부터 어떻게 시작할까? 마인드셋(Mindset)의 변화
요즘에는 컨테이너, 도커, 쿠버네티스, 클라우드 네이티브, 마이크로서비스, 데브옵스, 카오스 엔지니어링(Chaos Engineering), SRE(Site Reliability Engineering), CI/CD 등 클라우드 생태계를 중심으로 소프트웨어 생명 주기 전체를 포괄하는 새로운 기술의 화두가 스타트업을 시작으로 엔터프라이즈까지 이어지고 있다. 

필자가 현장에서 고객들과 만나서 얘기하고 프로젝트를 진행할 때 기업과 개인마다 이러한 새로운 기술을 받아들이는 마인드셋이 사뭇 다르다는 것을 느낀다.

간혹 비즈니스 목적성은 뒤로한 채 기술 자체에 집중하는 경우도 있고 단기 비즈니스 목표 달성을 위해 기존의 방식을 고수하는 경우도 있다. 또 복잡하고 낯설다는 이유만으로 새로운 기술에 대해 부정적인 입장을 고수하는 경우도 많이 봤다.

새로운 기술은 기술 수용주기 이론에 의해 움직이는 경우가 대부분이고 앞서 언급한 기술들은 이제 캐즘(Chasm)을 넘어 전기 다수 수용자(Early Majority)의 단계(또는 그 다음 단계)를 지나고 있다고 생각한다. 시대의 흐름을 거스를 수는 없을 것이다. 부지불식간 우리의 업무 환경에 스며들어 주류를 이루게 될 날이 머지 않았다. 

이러한 상황에서 가장 안타깝게 느꼈던 것 중에 하나는 기업들이 새로운 기술을 접하고, 비즈니스 목적성에 부합하는지 실험해보기 보다는 ‘보고’, ‘기능 비교’, ‘표준화’, ‘프로세스’, ‘추진 계획’, ‘거버넌스 수립’ 등의 선행 작업에 너무 많은 시간을 소모하는 경향이 있다는 것이다.

즉 일하는 방식이 폭포수(Waterfall) 모델을 따르고 있다. 폭포수 모델의 개발 방식이 좋다 또는 나쁘다를 얘기하는 것은 아니다. 지금 시대의 비즈니스 요구에 부합하는 방식인지 살펴보는 것이 더 중요하다.

새로운 기술을 접할 때 비즈니스 목적성에 맞게 동작하는지를 먼저 확인하고 확장성과 안정성, 유지보수성, 보안(서버리스는 이러한 작업을 대부분 해결해 준다) 등은 그 후에 해도 늦지 않는다. 물론 이러한 것을 간과해도 된다는 말은 아니다. 

처음부터 모든 준비를 갖추고 진행하면 좋겠지만 앞서 얘기한 것처럼 완벽한 준비를 하고 시작하기에는 비즈니스 환경이 허락하지 않을 것이다. 이러한 마인드셋은 결국 엔터프라이즈를 환경에 적응하지 못하는 공룡으로 만들 수 있다. 작고 빠른 실패는 리스크로 귀결되기 보다는 ‘Lessons Learned’로 돌아오는 경우가 많다. 실험은 작고 빨라야 한다. 작고 빠른 실험이 실패했을 때 리스크는 그만큼 작다.

2019년 AWS 리인벤트(re:Invent)에서 해커톤(Hackathon) 행사가 열렸다. 이 해커톤에 참가한 선수들에게는 24시간의 시간이 주어졌고 선수들은 이 시간 내에 작동 가능한 애플리케이션을 치열하게 구현해야 했다. 여기서 우리가 목격한 것은 모든 팀이 AWS 람다와 다른 서버리스 서비스를 사용해서 애플리케이션을 구현했다는 것이다. 

더욱 놀라운 건 AWS 람다를 처음 사용하는 경우도 많았다. 해커톤을 통해 목격된 현상으로 모든 것을 일반화하는 것은 바람직하지 않지만 서버리스는 비즈니스를 차별화하기 힘든 많은 부분의 일을 덜어주기 때문에 처음부터 모든 것을 완벽하게 갖추고 진행하는 방식에서 벗어날 수 있고 비즈니스 변화의 속도에 맞춰 모던 애플리케이션(Modern Application)을 구축할 수 있는 가장 빠른 방법이 될 수도 있다.

서버리스 사용 사례
서버리스 서비스를 사용한 아키텍처 사례는 무수히 많지만 지면의 한계상 간략하게 세 가지의 사례를 살펴보고자 한다.

1. 범용 웹 애플리케이션 아키텍처
범용 웹 애플리케이션을 구축하기 위한 참조 아키텍처는 비즈니스 로직에 AWS Lambda, Amazon API Gateway를 사용해서 이벤트 중심적인 웹 애플리케이션 백엔드를 구축할 수 있다. 또 Amazon DynamoDB를 데이터베이스로 사용하고 Amazon Cognito를 사용자 관리에 사용할 수 있다. 모든 정적 콘텐츠는 Amazon S3의 ‘정적 웹 사이트 호스팅’ 또는 AWS Amplify 콘솔을 사용해서 호스팅할 수 있다.

아래는 간단한 ‘할 일 목록 애플리케이션’을 구현하기 위한 참조 아키텍처다. 등록한 사용자(Amazon Cognito)가 API Gateway의 Endpoint를 통해 할 일(ToDo)을 생성(addTodo), 수정(updateTodo)하고 기존의 항목을 조회(getTodo, getAllTodo)한 뒤 삭제(deleteTodo) 등을 할 수 있는 기능을 제공하고 있다. 샘플 코드는 링크에서 확인할 수 있다.
 

2. 실시간 데이터 처리 아키텍처
서버리스 서비스를 사용해서 트랜잭션 주문 처리, 클릭 스트림 분석, 데이터 처리, 지표 생성, 로그 필터링, 소셜 미디어 분석, IoT 디바이스 데이터 텔레메트리 등의 실시간 데이터를 손쉽게 처리할 수 있다. 예를 들어 실시간 클릭 스트림을 수집하기 위해 Amazon Kinesis Data Firehose를 사용하고, 수집된 원시 데이터를 Amazon S3에 자동으로 아카이브하고, Amazon Athena로 원시 데이터에 대해 애드혹 쿼리를 할 수 있다.

3. 배치 처리 아키텍처
아래의 배치 처리 다이어그램은 AWS의 오픈 데이터 레지스트리에서 제공하는 국제 대기질 데이터 OpenAQ를 배치 처리하는 참조 아키텍처 사례다. 하루 기준으로 대기질 측정값에 대한 최소, 최대 및 평균 점수를 생성한다. 

AWS Step Functions을 사용해서 AWS Lambda로 데이터의 ETL(Extract, Transform, Load) 작업을 오케스트레이션할 수 있다. ETL 작업은 수동으로 트리거해야 하지만, Amazon EventBridge 규칙을 사용해서 쉽게 반복 예약할 수 있다. 변환이 완료되면 요약 데이터에 대한 S3 위치를 이메일을 통해 알려준다. 샘플 코드는 링크에서 확인할 수 있다. 자세한 내용은 AWS 서버리스 페이지에서 확인할 수 있다.
 

마무리
서버리스 퍼스트 접근 전략은 엔터프라이즈에서 선택해야 하는 가장 중요한 전략 중 하나가 될 전망이다. 그리고 그 전략의 시작점은 서버리스를 기술이 아닌 전략으로 바라보는 마인드셋의 변화다. 서두에서 언급한 버너 보겔스(Werner Vogels) 박사의 메시지로 이 글을 마친다.
 

"AWS에서 기대하는 미래의 모습은, 개발자가 작성하는 모든 코드는 오직 비즈니스 로직일 뿐입니다."


* 최인영 Executive Technology Partner는 2017년부터 AWS(Amazon Web Services)에서 솔루션즈 아키텍트로 근무하고 있고, 엔터프라이즈 CxO 및 기술 리더를 대상으로 기술 가이드와 방향성을 제시하는 역할을 수행하고 있다. ciokr@idg.co.kr
 



2021.06.01

벤더 기고ㅣ엔터프라이즈를 위한 서버리스 퍼스트 전략

최인영 | CIO KR

아마존 CTO 버너 보겔스 박사는 2019년 re:Invent 키노트 세션을 통해 "AWS에서 기대하는 미래의 모습은, 개발자가 작성하는 모든 코드는 오직 비즈니스 로직일 뿐입니다"라고 언급했다. 이 짧은 한 문장은 많은 의미를 함축하고 있다. 일반적으로 개발자는 비즈니스 로직을 구현하는 것 외에 애플리케이션의 스케일링, 인프라 오케스트레이션, 가용성, 보안, 배포 등도 고려해서 개발한다. 대부분의 근무 시간을 비즈니스 로직 구현에 할당해야 하지만 현실은 부가적인 일에 생각보다 많은 시간을 할애하고 있는 것이 사실이다.

* 벤더가 작성한 본 기고문은 벤더의 시각과 주장, 솔루션에 대한 직접적인 내용을 담고 있다.

하지만 가까운 미래에는 개발자가 비즈니스 로직을 구현하는 일에 보다 집중할 수 있는 환경이 될 것으로 전망한다. 필자는 ‘개발자가 비즈니스 로직을 구현하는 일에 집중’할 수 있다는 말의 배경에는 ‘서버리스 컴퓨팅(Serverless computing)의 확산과 발전’이 큰 역할을 할 것으로 본다.

컴퓨팅 환경의 진화
서버리스 컴퓨팅에 대해 얘기하기 전에 먼저 컴퓨팅의 환경이 어떻게 진화했는지 알아보고자 한다.

• 우리가 알고 있는 '서버(Servers)'
불과 10여년 전만 해도 새로운 서비스를 개발하기 위해서는 물리 서버를 구매하는 것을 당연하게 생각했다. 일반적으로 5년(또는 3년)을 기준으로, 사용자 트래픽 증가를 고려해서 용량을 산정하고 그 용량을 기반으로 서버와 스토리지, 네트워크 장비 등의 스펙을 결정했다. 

물리 서버들이 데이터센터에 입고되고 랙에 스택킹이 된 후 UTP 케이블이 서버에 연결되면 이때부터 본격적인 서버 작업이 시작된다. 이후 OS를 설치하고, 정책에 기술된 보안 패키지 설치와 구성 설정을 하고, 서버 관리를 위한 다양한 유틸리티를 설치하며, 네트워크 툴을 설치하고, 백업을 위한 스크립트 등 수 많은 작업을 수행했다.

보통 시스템 엔지니어들은 항상 수십(또는 수백) 페이지에 달하는 자기만의 서버 설치와 구성 작업을 위한 매뉴얼을 가지고 있었다. 다시 얘기하지만 이런 일은 불과 10여년 전의 얘기다.

• 가상 머신(Virtual Machines)
서버 리소스(예: CPU, Memory 등)의 사용률(Utilization)을 높이고 확장성(Scalability)의 요구에 대응하기 위한 방안으로 가상 머신(Virtual Machine)이 등장했다. 이는 미리 준비된 서버 이미지를 기반으로 배포를 단순화한다. 서버 이미지에는 필요한 대부분의 작업(OS 설치/패치/구성, 유틸리티 설치, 보안 등)을 미리 준비해놓고 재사용했다. 이러한 방식은 매우 효율적으로 잘 작동하고 있었고, 서버의 효율을 높였다. 장애가 발생해도 서버 구성이 빠르게 되기 때문에 다운 타임(Down time)도 예전보다는 많이 줄었다.

• 컨테이너(Containers)
2013년 파이콘(PyCon)에서 처음으로 소개된 도커(Docker)는 애플리케이션 개발과 배포의 방식을 완전히 바꿨다(컨테이너 기술 자체는 훨씬 오랜 역사를 가지고 있다). 도커 컨테이너는 애플리케이션 코드와 라이브러리, 런타임, 시스템 툴 등 애플리케이션 실행에 필요한 모든 것을 포함해서 완전한 하나의 컨테이너 이미지로 패키징한다. 그리고 이 컨테이너 이미지 자체로 애플리케이션을 배포한다. 

애플리케이션 실행에 필요한 모든 것을 하나의 컨테이너 이미지로 패키징하기 때문에 '불변(Immutable)'의 성질을 가지게 된다. 또한 컨테이너 기술은 OS를 가상화하는 가상 머신(Virtual machines) 기술과는 다르게 호스트 OS에 있는 자원을 공유해서 사용하고 프로세스를 격리하는 방식으로 작동된다. 따라서 물리 서버 자원(CPU, Memory 등)의 성능 손실이 거의 없다.

• 서버리스(Serverless)
서버리스를 생각하면 아마도 제일 먼저 떠올리게 되는 것이 AWS 람다(Lambda)일 것이다. 서버를 프로비저닝하거나 관리할 필요가 없는 AWS 람다는 2014년 11월 처음 소개된 후로 사용자가 유용하게 사용하는 서비스로 자리 잡았고, AWS 자체 플랫폼에서도 많이 사용되고 있다.

AWS 람다는 기본적으로 대부분의 주요 개발 언어(Node.js, Python, Go, Java, C#, Ruby 등)를 지원하고 워크로드 변화에 정확히 맞도록 스케일링이 조정된다. 또한 2020년 12월부터 AWS 람다 함수 실행 시간에 대해 1밀리 초 단위의 과금 정책이 적용됐다. 개발자는 단지 코드를 작성하고 ZIP 파일 또는 컨테이너 이미지로 업로드하면 된다. 

서버리스 서비스에는 AWS 람다만 있는 것이 아니다. 앞서 얘기했던 컨테이너 실행을 위한 서버리스 컴퓨팅 서비스인 AWS 파게이트(Fargate)도 있다. 이 밖에도 다양한 서버리스 서비스(예: 애플리케이션 통합을 위한 Amazon EventBridge, AWS Step Functions, Amazon SQS, Amazon SNS, Amazon API Gateway, AWS AppSync, 데이터 스토어를 위한 Amazon S3, Amazon DynamoDB, Amazon RDS Proxy, Amazon Aurora Serverless)가 있다.

서버리스 컴퓨팅(Serverless computing) 다시 생각하기
대부분 ‘서버리스 컴퓨팅’은 기술과 관련성 높은 용어라고 인식하는 경향이 있다. 틀린 얘기는 아니지만 IT 조직이 기술을 선택하기 위한 접근 전략으로 바라볼 필요가 있다고 생각한다. 앞서 컴퓨팅 환경의 진화에서 서버리스에 대해 살펴봤지만 서버리스 컴퓨팅의 정의부터 다시 짚고 넘어가 보고자 한다.

위키백과에 따르면 ‘서버리스 컴퓨팅은 클라우드 제공자가 컴퓨팅 리소스를 온디맨드로 할당하고 고객을 대신해서 서버를 관리하는 클라우드 컴퓨팅의 실행 모델’이라고 정의하고 있다. 서버리스라는 용어 자체가 내포하는 의미와는 다르게 실제 서버가 없는 것은 아니고 클라우드 제공자가 고객의 애플리케이션을 실행하기 위해 서버를 포함한 인프라스트럭처와 실행 환경을 대신 관리하고 운영을 해주는 것을 의미한다.

이제 필자가 서버리스 컴퓨팅을 조직의 기술 선택을 위한 접근 전략이라고 얘기하는 이유를 설명하고자 한다. 

AWS는 개발자가 인프라스트럭처 관리와 유지보수를 신경 쓰지 않고 오로지 비즈니스 로직과 관련된 애플리케이션 기능 구현에 집중할 수 있도록 추상화의 수준(실제 서버가 보이지 않도록)을 한층 높였다.

사용자 입장에서 ‘서버가 보이지 않는다’의 의미는 더 이상 용량 산정, 리소스 프로비저닝, 패치 등의 작업을 신경 쓰지 않아도 되고, 개발자와 엔지니어가 신경 써야 하는 애플리케이션의 확장성(Scalability)을 고민하지 않아도 된다는 얘기와 같다. 

이것은 조직의 IT 전략과 밀접한 관련이 있다. 대부분의 엔터프라이즈 조직은 최적화(아쉽지만 최적화는 최소화와 동의어처럼 사용되는 경우가 많다)된 IT 인력으로 구성되어 운영되고 있다. 대부분의 IT 조직은 비즈니스 유저의 요구 사항을 반영해서 서비스와 기능을 구현하는 일만으로도 버거운 상황이다.

IT 조직이 비즈니스를 지원하는 역할을 넘어서 비즈니스를 차별화하는 역할로 거듭나기 위해서는 IT 업무 생산성을 최대한으로 높이는 것이 매우 중요하다. 따라서 조직의 리더십은 개발자와 엔지니어가 애플리케이션 구축과 실행, 운영을 위한 인프라스트럭처를 고민하지 않게 하고 비즈니스 로직 구현과 실험에 그 시간을 온전히 투자토록 하는 것이 중요한 전략이다.

또 AWS의 서버리스 서비스는 종량제 요금 모델을 기반으로 하기 때문에 사용하지 않는 컴퓨팅 리소스에 대해서는 요금을 지불하지 않아도 된다. 더불어 서비스 자체의 고가용성과 오토 스케일링(Auto Scaling) 기능을 제공해 애플리케이션의 운영 효율성을 극대화할 수 있다.

서버리스 퍼스트 전략(Serverless first strategy) 이란?
서버리스 퍼스트 접근 전략은 애플리케이션을 개발할 때 서버리스 서비스를 중심으로 아키텍처를 설계하고 만약 예외 상황이 발생했을 경우에는 기존 방식을 고려하는 전략이다. IT 조직이 수행해야 하는 ‘차별화되지 않는(Undifferentiated heavy lifting)’ 운영 업무를 줄이고 새로운 기능과 서비스를 신속하게 제공하기 위한 핵심 업무에 집중한다.

혹자는 기존 방식에서도 고객과 비즈니스 유저의 요구에 맞춰 충분히 신속하게 빠르게 서비스를 출시하고 있다고 얘기를 한다. 이렇게 생각하는 배경에는 아마도 기존 IT의 역할에 대한 마인드셋(Mindset)이 크게 작용했을 것이다. 

기존 비즈니스 환경에서 IT의 역할은 매우 중요한 부분을 수행해 왔고 기업의 비즈니스를 지원하는 부서로서의 역할에 충실했다. 비즈니스 유저들의 요구를 잘 지원하기 위해 업무 프로세스 속도를 향상시키고 신뢰성과 정확도, 비용 효율을 높이는 것을 항상 염두에 두고 일을 했다. 

하지만 결정적으로 기존 IT의 역할은 경쟁환경에서의 비즈니스 차별화에 크게 기여하지 못한 듯 하다. 넷플릭스, 쿠팡, 배달의 민족 등의 사례를 보면 IT를 비즈니스 지원의 역할이 아닌 비즈니스 자체를 차별화하기 위한 역할로 새롭게 포지셔닝했다고 볼 수 있다. 기존 시장에 국한하지 않고 새로운 시장을 개척하기 위해 아이디어를 실험하고 제품들을 빠르게 출시한다. 이들의 공통점은 거의 모든 서비스를 클라우드에 기반해서 운영하고 있다는 점이다.

클라우드에 기반하고 있다는 얘기는 핵심 업무(비즈니스 로직 구현)에 대부분의 리소스를 집중하고 있다는 얘기와 동일하게 볼 수 있다. 또한 IT 기술을 빠르게 익히고, 익힌 기술을 새로운 기능을 실험하는 데 사용하고 있다는 뜻이다. 

엔터프라이즈가 이러한 디지털 기반의 혁신기업들과 경쟁하고 고객에게 더 혁신적인 서비스를 제공하기 위해서는 기존 IT의 역할을 재고해야 한다.

엔터프라이즈가 서버리스 퍼스트 전략을 선택해야 하는 이유
현대 경영학의 대가 마이클 포터는 전략(Strategy)을 ‘우리가 무엇을 할 것인가 보다는 무엇을 하지 않을 것인가(Strategy is defined by what your are NOT doing)’를 의미한다고 말했다. 이미 답은 제시된 것 같다. 

IT 조직이 고객과 비즈니스 유저의 요구에 신속히 대응하고 비즈니스를 차별화하기 위해서는 최대한 핵심 업무(비즈니스 로직 구현)에 집중하고 주변의 일을 줄여야 한다. IT 조직이 ‘하지 않을 그 무엇’을 목록화해서 정리해보면 서버리스 서비스가 올바른 전략이라는 것을 이해할 수 있을 것이다. 

다시 정리하자면, 서버리스 퍼스트 접근 전략은 애플리케이션을 개발할 때 서버리스 서비스를 중심으로 아키텍처를 설계하고 만약 예외 상황이 발생했을 경우 기존 방식을 고려하는 전략이다. 무조건 서버리스 서비스를 사용하라는 건 아니다.

어디서부터 어떻게 시작할까? 마인드셋(Mindset)의 변화
요즘에는 컨테이너, 도커, 쿠버네티스, 클라우드 네이티브, 마이크로서비스, 데브옵스, 카오스 엔지니어링(Chaos Engineering), SRE(Site Reliability Engineering), CI/CD 등 클라우드 생태계를 중심으로 소프트웨어 생명 주기 전체를 포괄하는 새로운 기술의 화두가 스타트업을 시작으로 엔터프라이즈까지 이어지고 있다. 

필자가 현장에서 고객들과 만나서 얘기하고 프로젝트를 진행할 때 기업과 개인마다 이러한 새로운 기술을 받아들이는 마인드셋이 사뭇 다르다는 것을 느낀다.

간혹 비즈니스 목적성은 뒤로한 채 기술 자체에 집중하는 경우도 있고 단기 비즈니스 목표 달성을 위해 기존의 방식을 고수하는 경우도 있다. 또 복잡하고 낯설다는 이유만으로 새로운 기술에 대해 부정적인 입장을 고수하는 경우도 많이 봤다.

새로운 기술은 기술 수용주기 이론에 의해 움직이는 경우가 대부분이고 앞서 언급한 기술들은 이제 캐즘(Chasm)을 넘어 전기 다수 수용자(Early Majority)의 단계(또는 그 다음 단계)를 지나고 있다고 생각한다. 시대의 흐름을 거스를 수는 없을 것이다. 부지불식간 우리의 업무 환경에 스며들어 주류를 이루게 될 날이 머지 않았다. 

이러한 상황에서 가장 안타깝게 느꼈던 것 중에 하나는 기업들이 새로운 기술을 접하고, 비즈니스 목적성에 부합하는지 실험해보기 보다는 ‘보고’, ‘기능 비교’, ‘표준화’, ‘프로세스’, ‘추진 계획’, ‘거버넌스 수립’ 등의 선행 작업에 너무 많은 시간을 소모하는 경향이 있다는 것이다.

즉 일하는 방식이 폭포수(Waterfall) 모델을 따르고 있다. 폭포수 모델의 개발 방식이 좋다 또는 나쁘다를 얘기하는 것은 아니다. 지금 시대의 비즈니스 요구에 부합하는 방식인지 살펴보는 것이 더 중요하다.

새로운 기술을 접할 때 비즈니스 목적성에 맞게 동작하는지를 먼저 확인하고 확장성과 안정성, 유지보수성, 보안(서버리스는 이러한 작업을 대부분 해결해 준다) 등은 그 후에 해도 늦지 않는다. 물론 이러한 것을 간과해도 된다는 말은 아니다. 

처음부터 모든 준비를 갖추고 진행하면 좋겠지만 앞서 얘기한 것처럼 완벽한 준비를 하고 시작하기에는 비즈니스 환경이 허락하지 않을 것이다. 이러한 마인드셋은 결국 엔터프라이즈를 환경에 적응하지 못하는 공룡으로 만들 수 있다. 작고 빠른 실패는 리스크로 귀결되기 보다는 ‘Lessons Learned’로 돌아오는 경우가 많다. 실험은 작고 빨라야 한다. 작고 빠른 실험이 실패했을 때 리스크는 그만큼 작다.

2019년 AWS 리인벤트(re:Invent)에서 해커톤(Hackathon) 행사가 열렸다. 이 해커톤에 참가한 선수들에게는 24시간의 시간이 주어졌고 선수들은 이 시간 내에 작동 가능한 애플리케이션을 치열하게 구현해야 했다. 여기서 우리가 목격한 것은 모든 팀이 AWS 람다와 다른 서버리스 서비스를 사용해서 애플리케이션을 구현했다는 것이다. 

더욱 놀라운 건 AWS 람다를 처음 사용하는 경우도 많았다. 해커톤을 통해 목격된 현상으로 모든 것을 일반화하는 것은 바람직하지 않지만 서버리스는 비즈니스를 차별화하기 힘든 많은 부분의 일을 덜어주기 때문에 처음부터 모든 것을 완벽하게 갖추고 진행하는 방식에서 벗어날 수 있고 비즈니스 변화의 속도에 맞춰 모던 애플리케이션(Modern Application)을 구축할 수 있는 가장 빠른 방법이 될 수도 있다.

서버리스 사용 사례
서버리스 서비스를 사용한 아키텍처 사례는 무수히 많지만 지면의 한계상 간략하게 세 가지의 사례를 살펴보고자 한다.

1. 범용 웹 애플리케이션 아키텍처
범용 웹 애플리케이션을 구축하기 위한 참조 아키텍처는 비즈니스 로직에 AWS Lambda, Amazon API Gateway를 사용해서 이벤트 중심적인 웹 애플리케이션 백엔드를 구축할 수 있다. 또 Amazon DynamoDB를 데이터베이스로 사용하고 Amazon Cognito를 사용자 관리에 사용할 수 있다. 모든 정적 콘텐츠는 Amazon S3의 ‘정적 웹 사이트 호스팅’ 또는 AWS Amplify 콘솔을 사용해서 호스팅할 수 있다.

아래는 간단한 ‘할 일 목록 애플리케이션’을 구현하기 위한 참조 아키텍처다. 등록한 사용자(Amazon Cognito)가 API Gateway의 Endpoint를 통해 할 일(ToDo)을 생성(addTodo), 수정(updateTodo)하고 기존의 항목을 조회(getTodo, getAllTodo)한 뒤 삭제(deleteTodo) 등을 할 수 있는 기능을 제공하고 있다. 샘플 코드는 링크에서 확인할 수 있다.
 

2. 실시간 데이터 처리 아키텍처
서버리스 서비스를 사용해서 트랜잭션 주문 처리, 클릭 스트림 분석, 데이터 처리, 지표 생성, 로그 필터링, 소셜 미디어 분석, IoT 디바이스 데이터 텔레메트리 등의 실시간 데이터를 손쉽게 처리할 수 있다. 예를 들어 실시간 클릭 스트림을 수집하기 위해 Amazon Kinesis Data Firehose를 사용하고, 수집된 원시 데이터를 Amazon S3에 자동으로 아카이브하고, Amazon Athena로 원시 데이터에 대해 애드혹 쿼리를 할 수 있다.

3. 배치 처리 아키텍처
아래의 배치 처리 다이어그램은 AWS의 오픈 데이터 레지스트리에서 제공하는 국제 대기질 데이터 OpenAQ를 배치 처리하는 참조 아키텍처 사례다. 하루 기준으로 대기질 측정값에 대한 최소, 최대 및 평균 점수를 생성한다. 

AWS Step Functions을 사용해서 AWS Lambda로 데이터의 ETL(Extract, Transform, Load) 작업을 오케스트레이션할 수 있다. ETL 작업은 수동으로 트리거해야 하지만, Amazon EventBridge 규칙을 사용해서 쉽게 반복 예약할 수 있다. 변환이 완료되면 요약 데이터에 대한 S3 위치를 이메일을 통해 알려준다. 샘플 코드는 링크에서 확인할 수 있다. 자세한 내용은 AWS 서버리스 페이지에서 확인할 수 있다.
 

마무리
서버리스 퍼스트 접근 전략은 엔터프라이즈에서 선택해야 하는 가장 중요한 전략 중 하나가 될 전망이다. 그리고 그 전략의 시작점은 서버리스를 기술이 아닌 전략으로 바라보는 마인드셋의 변화다. 서두에서 언급한 버너 보겔스(Werner Vogels) 박사의 메시지로 이 글을 마친다.
 

"AWS에서 기대하는 미래의 모습은, 개발자가 작성하는 모든 코드는 오직 비즈니스 로직일 뿐입니다."


* 최인영 Executive Technology Partner는 2017년부터 AWS(Amazon Web Services)에서 솔루션즈 아키텍트로 근무하고 있고, 엔터프라이즈 CxO 및 기술 리더를 대상으로 기술 가이드와 방향성을 제시하는 역할을 수행하고 있다. ciokr@idg.co.kr
 

X