Cloud Modernization 13
서버리스 컴퓨팅과 AWS Lambda 이해하기
서버리스라는 말 때문에 서버가 사라진다고 오해하거나, EC2와 Lambda의 책임 차이를 놓치기 쉽다.
근거 · 교안 p49-p50
1장: 루나: 서버리스, 서버가 없다는 뜻일까?
1. 루나: 서버리스, 서버가 없다는 뜻일까?
솔라는 노트북 화면에 떠 있는 한 문장에 시선을 고정한 채 미간을 찌푸렸다. 이미 몇 번이나 읽은 문장이었다.
“서버리스 컴퓨팅은 개발자가 서버나 인프라를 직접 구성하거나, 관리할 필요 없이 애플리케이션과 서비스를 빌드하고 실행하는 클라우드 실행 모델이다.”
단어 하나하나는 아는 것들인데, 합쳐 놓으니 이상하게 알쏭달쏭했다. 특히 ‘서버리스(Serverless)’라는 단어가 자꾸만 생각의 길을 막았다. 솔라는 고개를 들어 거실 반대편에서 조용히 책을 읽고 있는 언니, 루나를 불렀다.
“언니, 잠깐만. 나 이거 도저히 모르겠어.”
루나가 책에서 눈을 떼고 솔라를 바라보았다.
“‘서버리스’라는 게 대체 무슨 뜻이야? 단어만 보면 ‘서버가 없다’는 건데, 서버 없이 어떻게 코드가 돌아가? 말도 안 되잖아.”
솔라의 목소리에는 답답함이 묻어났다.
“그리고 이 설명, ‘개발자가 서버를 관리할 필요가 없다’는 거. 이게 그냥 AWS 같은 회사가 대신 관리해준다는 뜻이야, 아니면 정말로 우리가 알던 그런 서버 자체가 없어진다는 뜻이야? 전에 EC2 설정할 때 이것저것 고르는 거랑 뭐가 다른 건지 모르겠어.”
루나는 잠시 생각하더니, 책을 덮고 자리에서 일어났다. 솔라 옆으로 다가온 루나는 솔라의 노트북 화면 대신 근처 테이블 위에 놓인 빈 메모지와 펜을 집어 들었다.
“좋아, 솔라. 우리가 직접 레스토랑을 하나 연다고 상상해보자. 두 가지 방식이 있어.”
루나는 메모지 가운데에 세로로 긴 선을 그어 두 칸으로 나눴다.
“왼쪽은 우리가 직접 주방을 전부 짓는 방식이야. 가스레인지는 뭘 살지, 환풍기는 어디에 달지, 수도는 어떻게 연결할지, 냉장고 크기는 어느 정도로 할지 전부 정해야 해. 그리고 한번 지으면 끝이 아니지. 매일 청소하고, 가스 점검도 하고, 낡은 기구는 교체해야 하고.”
루나는 왼쪽 칸 위에 ‘직접 짓는 주방’이라고 적고는, 솔라가 말했던 EC2 설정의 기억을 되짚어 주었다.
“우리가 애플리케이션을 서버에 올릴 때도 비슷해. 전에 EC2 인스턴스 만들 때 기억나? 운영체제(OS) 이미지부터 시작해서, CPU나 메모리 같은 하드웨어 사양도 골라야 했지. 보안 설정, 네트워크 연결, 필요한 소프트웨어 설치까지 전부 우리 몫이었잖아. 그리고 한번 실행했다고 끝이 아니고.”
솔라는 루나의 말을 따라가며 고개를 끄덕였다.
“응. 보안 패치도 계속 해줘야 하고, 사용자가 몰리면 서버를 더 늘릴지 말지 결정도 해야 하고… 할 일이 엄청 많았지.”
솔라가 말하는 동안 루나는 왼쪽 칸에 그 내용들을 빠르게 받아 적었다.
- OS 선택 및 설치
- 하드웨어(CPU, 메모리) 사양 결정
- 네트워크 및 보안 설정
- 소프트웨어 및 업데이트 관리
- 서버 상태 모니터링
- 트래픽에 따른 서버 증설/축소
메모지 왼쪽 칸이 금세 빽빽해졌다. 루나는 이번엔 오른쪽 칸을 가리켰다.
“그럼 두 번째 방식. 이번엔 ‘공유 주방’을 쓰는 거야. 이미 완벽하게 설비가 갖춰진 주방의 한 공간을 빌리는 거지. 우리는 그냥 우리가 만들 요리 레시피랑 재료만 들고 가면 돼. 가스레인지가 고장 나든, 수도가 막히든 우리가 신경 쓸 필요 없어. 주방 관리인이 다 알아서 하니까.”
루나는 오른쪽 칸 위에 ‘공유 주방 빌리기’라고 적었다.
“서버리스가 바로 이런 식이야. 우리가 ‘직접 짓는 주방’처럼 모든 걸 관리하는 게 아니라, AWS라는 거대한 ‘공유 주방’의 한 조각을 빌리는 거지. 이 목록에서 우리가 계속 책임져야 할 건 뭘까?”
솔라는 펜을 들고 왼쪽의 빽빽한 목록과 텅 빈 오른쪽 칸을 번갈아 보았다. 잠시 망설이던 솔라는 오른쪽 칸에 딱 한 줄을 적었다.
- 애플리케이션 코드 (우리의 ‘레시피’)
그리고 잠시 더 고민하더니 한 줄을 더 추가했다.
- 코드가 쓸 최소한의 자원 설정 (요리에 필요한 화력 정도?)
“이것뿐인가?”
솔라는 스스로 적어놓고도 믿기지 않는다는 듯 중얼거렸다. 왼쪽 칸의 긴 목록과 오른쪽 칸의 단출한 목록이 극명한 대조를 이루었다. 그 차이를 눈으로 확인하자, 머릿속을 맴돌던 안개가 걷히는 기분이었다.
“아!”
솔라가 탄성을 질렀다.
“‘서버리스’는 서버가 진짜로 사라졌다는 뜻이 아니었구나! 서버는 있는데, 주방 관리인처럼 AWS가 전부 관리해주니까, 우리 개발자 입장에서는 서버가 없는 것처럼 보인다는 뜻이었네. 우리가 할 일과 AWS가 할 일의 책임 경계선이 다른 거였어.”
솔라는 방금 자신이 말한 ‘책임 경계선’이라는 단어가 마음에 들었다. 막연했던 개념이 선명한 그림으로 잡히는 순간이었다. 이제야 아까 읽었던 문장이 다르게 보였다. ‘개발자가 서버나 인프라를 직접 구성하거나, 관리할 필요 없이’ 라는 구절은 더 이상 서버의 유무에 대한 설명이 아니었다. 누구의 책임이 어디까지인지를 명확히 그어주는 선언이었다.
“그래. 우리가 할 일이 코드 작성에 훨씬 더 집중되는 거지.”
루나가 조용히 덧붙였다.
솔라는 후련한 표정으로 고개를 끄덕였다. 가장 큰 오해가 풀렸다. 하지만 메모지에 적힌 단출한 목록을 다시 보니 새로운 궁금증이 고개를 들었다.
“좋아. 우리가 서버 관리는 신경 꺼도 된다는 건 알겠어. 그런데… 좀 이상하지 않아? 우리가 직접 관리하는 서버는 항상 켜놓고 언제든 명령을 내릴 수 있잖아. 근데 이건 우리가 관리 안 한다며. 그럼 내 코드는 대체 언제, 어떻게 실행되는 거지? 항상 켜져 있는 게 아니라면 말이야.”
2장: 루나: 이벤트가 함수를 깨운다고?
솔라의 질문이 남긴 공기의 진동이 채 가라앉기도 전에, 루나는 어딘가로 향했다. 솔라의 질문은 ‘그래서 내 코드는 언제 실행되는데?’였지만, 루나는 대답 대신 작은 벨을 하나 들고 돌아왔다. 손님을 부를 때 쓰는 탁상용 벨이었다. 루나는 어제 솔라와 함께 서버 관리 책임 목록을 빼곡히 적었던 메모지 옆에 그 벨을 툭 내려놓았다.
‘딸랑’ 하는 소리와 함께, 어제의 대화 위에 새로운 물건이 놓였다. 루나는 이전 메모지 옆에 새 메모지를 한 장 더 펼쳤다. 그리고는 어제 그렸던 ‘공유 주방’ 그림을 다시 그리기 시작했다. 하지만 이번에는 주방 한쪽에 작은 쪽방을 그리고, 그 안에 졸고 있는 요리사 캐릭터를 그려 넣었다.
“어제 우리가 이야기했던 ‘공유 주방’을 다시 생각해 보자.”
루나가 입을 열었다.
“주방 시설은 관리인이 전부 책임지기로 했지. 우리는 우리만의 ‘레시피’, 즉 코드만 가지고 있어. 그런데 솔라 네 말대로, 우리 요리사가 항상 주방에 나와서 불을 켜놓고 대기할 필요는 없잖아. 그건 낭비니까.”
루나는 졸고 있는 요리사 그림을 펜으로 톡톡 쳤다.
“그래서 우리 요리사는 주문이 들어올 때까지 자기 방에서 쉬고 있어. 가게는 열려 있지만, 요리사는 잠들어 있는 상태인 거야.”
“주문이 들어올 때까지…?”
솔라는 루나의 그림과 탁자 위의 벨을 번갈아 보았다. 뭔가 연결될 것 같은 느낌이 들었다.
“그래. 자, 상상해 봐. 우리가 만든 앱의 기능 중 하나가 ‘사용자가 사진을 올리면, 그 사진을 정사각형 모양의 작은 썸네일 이미지로 자동 변환해서 저장하는 것’이라고 해보자.”
루나는 새 메모지에 간단한 그림을 그렸다. 구름 모양의 ‘사진 보관함’과 코드가 적힌 문서 모양의 ‘썸네일 생성 함수’였다.
“기존 방식이라면, 우리는 24시간 내내 켜져 있는 서버를 하나 두고 ‘혹시 새 사진 들어왔나?’ 하고 1분마다 사진 보관함을 들여다보는 프로그램을 돌려야 할 거야. 우리 요리사가 1분마다 잠에서 깨서 주방 문을 열고 ‘주문 없어요?’ 확인하고 다시 들어가 자는 셈이지. 비효율적이야.”
“응, 그렇지. 계속 컴퓨터 자원을 쓰는 거니까.”
솔라가 맞장구를 쳤다.
“그런데 서버리스 모델에서는 달라.”
루나는 ‘사진 보관함’에서 ‘썸네일 생성 함수’ 쪽으로 화살표를 그렸다. 그리고 그 화살표 위에 아까 가져온 탁상용 벨 그림을 작게 그려 넣었다.
“여기서는 사진 보관함 자체가 능동적으로 움직여. 새로운 사진 파일이 딱 도착하는 그 순간, 사진 보관함이 직접 벨을 눌러서 ‘새 주문이요!’ 하고 외치는 거야.”
루나는 실제로 테이블 위의 벨을 손가락으로 가볍게 눌렀다. ‘띵!’ 하고 맑은 소리가 울렸다.
“이 벨소리가 바로 ‘이벤트(Event)’야. AWS는 이 벨소리를 듣고, 그제야 자고 있던 우리 요리사, 즉 ‘썸네일 생성 함수’ 코드를 깨우는 거지. ‘일할 시간이야!’ 하면서. 그리고는 딱 그 요리 하나만 할 수 있는 작은 조리 공간을 즉시 만들어줘. 요리사는 잠에서 깨어나 썸네일을 만들고, 결과물을 내놓고, 자신의 일과가 끝나면 다시 사라져. 조리 공간도 바로 치워지고.”
솔라의 눈이 동그래졌다. 항상 켜져 있거나, 내가 직접 실행해야 한다는 두 가지 생각에 갇혀 있던 머릿속에 전혀 다른 그림이 그려졌다. 코드가 계속 대기하는 것이 아니었다. 코드를 깨우는 외부의 신호가 있었다.
“아! 그럼 내 코드는… 평소엔 그냥 잠자고 있는 거구나. 아무것도 안 하고. 그러다가 ‘사진 업로드’ 같은 특정 사건, 즉 이벤트가 발생하면 그게 실행 방아쇠가 되어서 내 코드를 딱 그 순간에만 불러내는 거네!”
솔라는 ‘실행 방아쇠’라는 단어를 내뱉으며 무릎을 쳤다. 방금 전 루나가 눌렀던 벨소리가 마치 총소리처럼 느껴졌다. 시작을 알리는 신호탄.
“맞아. 그래서 AWS Lambda 같은 서비스를 설명하는 문서에 ‘이벤트 소스가 함수 코드를 간접적으로 호출한다’ 같은 표현이 있는 거야. 우리가 직접 함수를 실행시키는 게 아니라, 이벤트가 발생하면 AWS가 우리를 대신해서 함수를 실행시켜주는 거지. 그 벨소리처럼.”
솔라는 루나가 그린 그림을 가만히 들여다보았다. ‘사진 보관함’과 ‘썸네일 생성 함수’ 사이에 그려진 작은 벨. 그 벨이 모든 것을 설명해주고 있었다. 서버리스의 코드는 하염없이 기다리는 존재가 아니라, 명확한 신호에만 반응하여 나타나는 해결사 같은 존재였다.
“알겠다. 이제 ‘책임 경계선’도 명확해지고, 내 코드가 언제 실행되는지도 알겠어. AWS가 서버라는 주방을 관리하고, 이벤트라는 벨이 울리면 내 코드가 깨어나서 요리를 하는 거구나.”
솔라는 두 가지 핵심 조각을 손에 쥔 기분이었다. 하지만 두 조각을 손바닥 위에 올려놓고 보니, 아직 딱 들어맞는 하나의 그림으로 완성되지는 않았다.
“그런데 언니, AWS가 서버를 관리한다는 첫 번째 조각이랑, 이벤트가 코드를 실행한다는 두 번째 조각. 이 두 개를 합치면… 이게 왜 ‘서버리스 컴퓨팅 모델’이라는 이름으로 불리는 거지? 그냥 ‘편리한 기능’ 두 개를 합친 것 이상인 것 같은데. 이 전체적인 작동 방식을 하나의 모델로서 어떻게 설명할 수 있을까?”
3장: 루나: 서버리스 컴퓨팅, 이제 어떤 모델인지 보이지?
테이블 위에는 메모지 두 장이 나란히 놓여 있었다. 왼쪽에는 ‘직접 짓는 주방’과 ‘공유 주방 빌리기’의 책임 목록이, 오른쪽에는 ‘사진 보관함’과 ‘썸네일 생성 함수’ 사이에 벨이 그려진 그림이 있었다. 솔라는 두 메모지를 손가락으로 번갈아 가리키며 뚫어져라 쳐다봤다. 하나는 ‘누가 무엇을 하는가’에 대한 책임의 문제였고, 다른 하나는 ‘언제 코드가 실행되는가’에 대한 시점의 문제였다.
솔라는 두 메모지를 좀 더 가깝게 붙여 보기도 하고, 둘 사이에 가상의 선을 그어보기도 했다. 머릿속에서는 분명 연결되는데, 하나의 온전한 그림으로 합쳐지지가 않았다. AWS가 서버를 관리하는 것과, 이벤트가 코드를 실행하는 것. 이 두 가지 사실은 알겠다. 하지만 이것들이 왜 특별히 ‘모델’이라고 불릴 만큼 대단한 조합인지, 그 구조적인 아름다움이 손에 잡히지 않았다. 그냥 편리한 기능 두 개를 묶어놓은 것 이상으로 느껴지지 않았다.
“두 조각을 합쳐서 하나의 그림을 만들고 싶은데 잘 안 되는구나.”
솔라의 고민을 지켜보던 루나가 조용히 입을 열었다. 루나는 솔라가 만지작거리던 메모지들을 그대로 둔 채, 깨끗한 새 메모지를 한 장 더 가져와 테이블 중앙에 놓았다.
“그럼 우리가 직접 하나의 서비스를 이 모델로 구상해보는 건 어때? 분석하는 것보다 직접 만들어보는 게 더 잘 보일 때도 있으니까.”
루나는 펜을 들어 새 메모지 위에 간단한 문장을 적었다.
새로운 사용자가 회원가입을 하면, 환영 이메일을 보낸다.
“아주 간단한 기능이야. 이걸 두 가지 방식으로 만들어본다고 상상해보자. 먼저 우리가 서버를 직접 관리하는 옛날 방식으로.”
솔라는 루나의 제안에 고개를 끄덕이고 펜을 잡았다. 잠시 생각에 잠겼던 솔라는 ‘직접 짓는 주방’ 메모지 아래에 익숙한 방식의 구성도를 그리기 시작했다.
“일단… 24시간 돌아가는 서버가 필요하겠지. 그리고 이 서버는 1분에 한 번씩 사용자 데이터베이스를 확인해서 ‘어, 새로운 사용자다!’ 하는 걸 찾아내야 해. 새 사용자를 발견하면 그때 이메일 발송 코드를 실행시키고. 이걸 계속 반복해야겠네.”
솔라는 그림 아래에 몇 가지 특징을 적었다. ‘항상 켜져 있는 서버’, ‘주기적인 확인 작업(Polling)’, ‘사용자가 없어도 돌아가는 컴퓨터 자원’. 그림을 보고만 있어도 비효율적이라는 느낌이 역력했다.
“좋아. 그럼 이번엔 우리가 방금 얻은 두 조각, ‘책임 경계선’과 ‘실행 방아쇠’를 써서 다시 설계해볼까?”
루나가 오른쪽의 벨 그림이 그려진 메모지를 톡 가리켰다.
솔라는 잠시 숨을 고르고, 루나가 내어준 새하얀 메모지를 바라보았다. 그리고는 이전과는 전혀 다른 그림을 그리기 시작했다. 서버 상자부터 그리는 대신, ‘사용자 DB’라는 구름 모양과 ‘이메일 발송 함수’라는 코드 문서 모양을 먼저 그렸다.
“여기선… 서버를 우리가 관리할 필요가 없지.” 솔라는 ‘책임 경계선’ 개념을 떠올리며 중얼거렸다. “그러니 항상 켜져 있는 서버는 생각할 필요 없고. 내 코드는 그냥 잠들어 있으면 돼.”
솔라는 ‘이메일 발송 함수’ 그림 옆에 작게 zZ 표시를 그려 넣었다.
“그리고… ‘실행 방아쇠’가 필요해. 1분마다 확인하는 게 아니라, 정확한 사건이 내 코드를 깨워야 하니까. 여기서 사건은 ‘새로운 사용자가 데이터베이스에 추가되는 순간’이겠지.”
솔라는 ‘사용자 DB’에서 ‘이메일 발송 함수’로 이어지는 화살표를 그리고, 그 위에 어제 봤던 벨 그림을 다시 한번 그렸다.
“사용자 DB에 새 데이터가 ‘띵!’ 하고 들어오는 순간, 그 이벤트가 AWS에 신호를 보내는 거야. 그럼 AWS가 잠자고 있던 내 ‘이메일 발송 함수’를 깨워서 실행시켜주고. 이메일 발송이 끝나면 내 함수는 다시 사라지는 거지. 내가 할 일은 그냥 이메일 발송 코드, 즉 ‘레시피’만 잘 만들어두면 끝.”
솔라는 그림을 완성하고 펜을 내려놓았다. 두 개의 그림은 극명하게 달랐다. 왼쪽 그림은 거대한 기계가 계속 헛돌고 있는 느낌이라면, 오른쪽 그림은 필요한 순간에만 나타나 정확하게 할 일만 하고 사라지는 정밀한 시스템처럼 보였다.
그 순간, 안개 속에 흩어져 있던 조각들이 ‘착’ 하고 제자리를 찾는 소리가 머릿속에서 울렸다.
“아! 알겠다!”
솔라가 외쳤다.
“이건 그냥 두 기능의 합이 아니었어. 완전히 새로운 방식의 설계도, 즉 ‘모델’이 맞아! ‘서버 관리 책임은 AWS에게’라는 원칙이 배경이 되어주니까, 개발자는 ‘어떤 이벤트에 어떤 코드를 실행할지’라는 모델 구성 요소만 정의하면 되는 거였어! ‘이벤트 소스’와 ‘함수 코드’. 이 두 개를 연결하는 것 자체가 애플리케이션을 만드는 방식이 되는 거구나.”
솔라는 자신이 방금 말한 ‘모델 구성 요소’라는 단어를 곱씹었다. 이제야 서버리스 컴퓨팅이 왜 하나의 ‘실행 모델’이라고 불리는지 명확하게 이해되었다. 그것은 인프라 위에서 코드를 돌리는 방식에 대한 근본적인 관점의 전환이었다.
이제 솔라의 눈에는 처음 봤던 그 문장이 완벽하게 해독되었다. ‘개발자가 서버나 인프라를 직접 구성하거나, 관리할 필요 없이(책임 경계선) 애플리케이션과 서비스를 빌드하고 실행할 수 있는(이벤트와 함수를 연결하여) 클라우드 실행 모델(새로운 방식의 설계도)이다.’
루나는 말없이 고개를 끄덕이며, 작은 포스트잇 몇 장을 솔라 앞에 내밀었다. 각 포스트잇에는 새로운 서비스 시나리오가 한 줄씩 적혀 있었다.
- 밤 12시마다 그날의 데이터를 집계해서 보고서 생성하기
- 사용자가 문의를 남기면 담당자에게 슬랙 알림 보내기
- 회사 소개 페이지 같은 정적인 웹사이트 보여주기
“자, 이제 솔라 네가 방금 이해한 그 모델에 가장 어울리는 시나리오를 골라봐.”
솔라는 망설이지 않았다. 그녀는 첫 번째와 두 번째 포스트잇을 집어 들었다.
“이거 두 개. 첫 번째는 ‘밤 12시’라는 시간 자체가 이벤트, 즉 실행 방아쇠가 되고, 두 번째는 ‘새로운 문의 접수’가 방아쇠가 돼. 명확한 사건에 대응해서 딱 정해진 일을 하고 끝나니까, 굳이 서버를 항상 켜놓을 이유가 전혀 없어. 이게 바로 이 모델이 빛을 발하는 순간이야.”
솔라는 세 번째 포스트잇은 옆으로 밀어놓았다. 이 모델이 모든 문제의 만능 열쇠는 아니라는 것도 이제는 알 수 있었다. 자신의 손으로 직접 모델을 조립하고 나니, 그 모델이 어떤 종류의 부품에 가장 적합한지 판단할 수 있는 눈이 생긴 것이다.