무시해도 되는 서버리스에 대한 세 가지 흔한 오해

F5 에코시스템 | 2019년 1월 03일

서버리스는 클라우드 업계에서 떠오르는 총아입니다. 조직 세 곳 중 적어도 한 곳(33%)은 지난 1년 이내에 서버리스 앱을 배포했습니다. (출처: Digital Ocean 2018년 2분기 개발자 설문조사) CNCF 2018년 설문조사 응답자 중 38%는 현재 서버리스를 사용하고 있다고 답했습니다. 또 다른 26%는 향후 12개월 이내에 이 기술을 사용할 계획입니다.

이제 막 떠오르는 이 클라우드 옵션은 빠르게 성장하고 있을 뿐만 아니라, 비용을 절감하고 가치 실현 시간을 단축하며 심지어 침대에서 아침 식사까지 차려 줄 수 있는 거의 초자연적인 능력이 있는 것처럼 오해받는 경우도 많습니다.

게다가 혼란을 더하는 것은 서비스형 함수(FaaS)와 서버리스가 혼용된다는 점입니다. 이 둘은 서로 같지 않으며, 이로 인해 일반적인 기업이 이 멋진 신기술을 어떻게 활용할 수 있는지에 대해서도 오해가 생깁니다.

그래서 오늘은 지난 6개월 동안 고객과 콘퍼런스 참석자들에게서 반복해서 들었던 세 가지 흔한 오해를 바로잡아 보겠습니다. 이 기술이 무엇이고 무엇이 아닌지를 이해해야만 시간을 들여 살펴볼 가치가 있는지 판단할 수 있기 때문입니다.

먼저 서버리스와 FaaS의 차이부터 명확히 짚고 넘어가겠습니다.

오해: 서버리스 === FaaS

서버리스는 시스템입니다. 플랫폼이자 프레임워크입니다. 적시형 탄력적 실행 환경이라고 설명하는 것이 가장 적절합니다. 서버리스는 무언가를 일종의 격리된 환경에서 온디맨드로 실행하여 운영 오버헤드와 불편을 없애는 것을 목표로 합니다. 이러한 격리 환경은 일반적으로 컨테이너이지만, 가상 머신과 WebAssembly를 사용하는 서비스도 있습니다. 간결하게 설명하기 위해 여기서는 이 세 가지를 모두 포괄하는 의미로 "컨테이너"라는 용어를 사용하겠습니다.

서버리스는 이벤트 기반입니다. 즉, API 요청이 도착하거나 시계가 오후 2시 7분을 가리키는 것과 같은 특정 트리거에 의해 프로비저닝과 처리가 시작됩니다. 자동으로 생성된 이벤트일 수도 있고, 웹 앱의 양식에서 버튼을 누르는 것과 같은 대화형 이벤트일 수도 있습니다. 서버리스 모델에서는 이벤트가 "컨테이너"에 존재하는 무언가의 실행을 시작합니다.

NETOPS 참고: F5 iRule에 익숙한 독자라면 서버리스 이벤트를 "HTTP_REQUEST" 및 "HTTP_RESPONSE"와 같은 iRule 이벤트와 연관 지어 이해할 수 있습니다. 모델은 거의 동일합니다. 즉, 이벤트가 발생하면 코드를 실행합니다. 아쉽게도 대부분의 서버리스 프레임워크는 TCL을 지원하지 않지만, node.js와 Python은 지원하는 경우가 많습니다.

"컨테이너"는 요청 시 리포지토리에서 로드되는 경우가 많으며(콜드 스타트), 이미 대기 중일 수도 있습니다(웜 스타트). 해당 "컨테이너"에 있는 항목이 실행된 후, 실행을 트리거한 시스템에 응답을 반환합니다.

서버리스의 비즈니스 모델은 일반적으로 소비한 리소스에 대해서만 비용을 지불하는 방식입니다. 단, "컨테이너"가 실행되는 동안에만 해당합니다. 운영 모델은 환경 운영과 관련된 모든 요소를 고려 대상에서 제외하여 사람들이 "무언가"를 구축하는 데만 집중할 수 있도록 하는 것입니다.

이것이 바로 서버리스입니다. 서비스형 함수(Function as a Service)는 서버리스의 구체적인 활용 방식으로, "무언가"를 "함수"로 정의합니다.

FaaS를 사용하면 마이크로서비스에서 시작된 애플리케이션 분해를 궁극적인 형태인 함수까지 발전시킬 수 있습니다.

서버리스와 서비스형 함수(Function as a Service)가 서로 다르다는 점을 이해하는 것은 다음 오해를 바로잡는 데 중요합니다.

오해: 리팩터링이 필요하다

FaaS와 서버리스를 동일시하는 탓에, 시장의 많은 사람들은 서버리스의 이점을 활용하려면 애플리케이션을 구성 함수 단위로 리팩터링해야 한다고 잘못 생각합니다.

서버리스를 사용하기 위해 애플리케이션을 리팩터링하거나 새로운 앱을 함수 단위로 설계할 필요는 없습니다. 서버리스는 어떤 종류의 애플리케이션, 프로세스, 데몬 또는 함수가 담긴 "컨테이너"도 손쉽게 실행할 수 있습니다. "컨테이너"로 패키징되어 호출할 수 있기만 하면 서버리스 환경에서 실행할 수 있습니다.

기존 애플리케이션 아키텍처를 확장(현대화)하기 위해 서버리스를 활용한 성공적인 구현 사례도 보았습니다. 등록, 주문 처리 및 기타 핵심 경로에 속하지 않는 프로세스의 일괄 처리와 대역 외 처리는 기존 애플리케이션을 완전히 리팩터링하지 않고도 서버리스 모델로 구현할 수 있습니다. 이미 이러한 목적으로 외부 API 기반 통합을 활용하고 있는 애플리케이션이라면 서버리스를 더 쉽게 도입할 수 있습니다. 기존 클라이언트-서버 기반 애플리케이션은 서버리스를 활용하기 위해 어느 정도 수정이 필요할 가능성이 매우 높지만, 전체 리팩터링만큼 광범위한 작업이 필요한 것은 아닙니다.

간헐적이거나 예측할 수 없이 발생하는 특정 이벤트를 기반으로 가끔만 실행되는 프로세스도 서버리스에 적합할 수 있습니다. "컨테이너"를 항상 실행 상태로 유지하는 것보다 필요할 때마다 "컨테이너"를 가동해 작업을 실행하는 편이 비용 면에서 훨씬 효율적입니다. 이는 퍼블릭 서버리스와 온프레미스 서버리스 모두에 해당합니다.

이제 위치에 초점을 맞춘 세 번째 오해를 살펴보겠습니다.

오해: 서버리스는 온프레미스에서 구현할 수 없다

저는 각계각층의 IT 종사자뿐만 아니라 전문가들도 이런 주장을 하는 것을 들어왔습니다. 이는 온프레미스에서 "클라우드"를 운영할 수 없다는 생각만큼이나 명백히 잘못된 주장입니다. 온프레미스에서도 분명히 운영할 수 있으며, Developer Economics의 개발자 현황 보고서에 따르면 상당수의 조직이 실제로 그렇게 하고 있습니다.

규모가 크고 사용량이 많은 애플리케이션도 매우 효율적인 확장의 이점을 누릴 수 있습니다. 부하가 많이 걸리는 특정 부분에 필요한 추가 리소스에 대해서만 비용을 지불하면 되며, 해당 부분을 더 쉽게 파악하고 최적화할 수도 있습니다. 대규모 애플리케이션이 누리는 이러한 이점은 현재 서버리스 컴퓨팅 도입 기업의 17%가 자체 데이터 센터에서 솔루션을 운영하는 주요 이유일 것입니다.

온프레미스 서버리스 구현을 통한 비용 효율성 향상은 확장성에만 국한되지 않습니다. 동일한 리소스를 재사용하고 사용 빈도가 낮은 여러 애플리케이션에서 공유할 수 있다는 점도 상당한 이점입니다. 또한 서버리스는 핵심적인 이벤트 기반 특성을 활용하여 애플리케이션과 운영 기능에 부가 가치 기능을 손쉽게 추가할 수 있게 해줍니다. 서버리스의 이점은 개발자의 일상에서 운영상의 번거로움을 없애는 데 그치지 않는다는 점을 이해하지 못한 채 온프레미스에서의 활용을 가볍게 일축해서는 안 됩니다. 물론 그것도 큰 이점이지만 유일한 이점은 아니며, 조직들이 온프레미스 서버리스를 실험하는 유일한 이유도 결코 아닙니다.

따라서 실제로 서버리스는 온프레미스 환경에 구현할 수 있으며, 이미 구현되고 있습니다. 앞서 언급한 CNCF 설문조사에서는 가장 인기 있는 "설치형" 서버리스 플랫폼을 자세히 살펴봅니다:

이 외에도 더 있으며, 이 기술이 빠르게 발전함에 따라 앞으로 더 많은 사례가 등장할 것입니다.

서버리스와 서비스형 함수(FaaS)는 모두 놀라운 속도로 도입되고 있습니다. 조직들이 신규 클라우드 네이티브 애플리케이션과 현대화 작업에 이 기술을 활용하기 위해 직접 시험하고 탐색하며 평가하고 있기 때문입니다. 흔히 접하는 오해를 파악하고 배제하는 것은 이 기술이 조직의 애플리케이션에 적합한지 판단하기 위한 중요한 첫걸음입니다.

공유

작성자 소개

Lori Mac Vittie
Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물

관련 블로그 게시물

AI 시대의 새로운 애플리케이션 제공 원칙으로 복잡성 극복하기
F5 에코시스템 | 2025. 02. 20.

AI 시대의 새로운 애플리케이션 제공 원칙으로 복잡성 극복하기

보안, 일관성, 완전 자동화에 중점을 둔 애플리케이션 제공의 새로운 6가지 원칙을 도입하여 복잡성 없이 하이브리드 멀티클라우드의 유연성을 누리세요.

디지털 혁신을 가속화하는 6가지 기술 역량
F5 에코시스템 | 2023. 01. 05.

디지털 혁신을 가속화하는 6가지 기술 역량

오늘날의 엔터프라이즈 아키텍처에는 기술 변화를 주도하는 데 핵심적인 민첩성, 확장성, 보안 및 관찰 가능성이 부족하지만, 이 여섯 가지 핵심 역량은 기업이 디지털 혁신 전반에 걸쳐 위험과 과제를 관리하는 데 도움이 될 것입니다.

하이브리드 근무가 ID 중심 보안으로의 전환을 이끌고 있습니다
F5 에코시스템 | 2021. 08. 16.

하이브리드 근무가 ID 중심 보안으로의 전환을 이끌고 있습니다

자동화와 디지털화의 폭발적인 성장에 하이브리드 근무 모델로의 전환 추세가 더해지면서, IP 기반 보안에서 벗어나 ID 기반 액세스 전략으로 전환하는 움직임이 더욱 가속화될 것입니다.

관점의 현대화: 애플리케이션에서 경험으로
F5 에코시스템 | 2021. 04. 05.

관점의 현대화: 애플리케이션에서 경험으로

그리스와 로마의 신들처럼, 여러 신화에서도 동일한 존재가 다양한 모습으로 나타나는 것을 볼 수 있습니다. 본질적으로 각각의 화신은 기존 존재가 새로운 얼굴로 드러난 것입니다. 디지털 세계에서도 이와 비슷한 양상이 나타납니다. 우리가 ‘애플리케이션’이라고 부르는 것들은 흔히 기존 기능이 새로운 형태로 구현된 것이라 볼 수 있습니다.

코로나19 이후 기업 결제의 디지털 전환
F5 에코시스템 | 2020. 06. 01.

코로나19 이후 기업 결제의 디지털 전환

디지털 결제는 과거의 현금만큼이나 보편화되었습니다. 코로나19 팬데믹으로 인한 봉쇄 조치는 소비자의 디지털 결제 서비스 의존도를 더욱 빠르게 높였습니다. 기업의 디지털 결제 도입 역시 가속화되었습니다. 대중을 상대로 영업하든 하지 않든 기업에는 여전히 지급해야 할 대금과 받아야 할 대금이 있기 때문입니다.

공급망 해킹과 보안에서 하드웨어의 역할
F5 에코시스템 | 2018. 10. 08.

공급망 해킹과 보안에서 하드웨어의 역할

수석 아키텍트 Dave Schmitt와 CTO 오피스가 최근 Bloomberg의 Super Micro 관련 기사를 계기로 하드웨어 보안 전문성의 중요성을 되짚어봅니다. 또한 이 글에서는 시스템이 안전하게 보호되고 있는지 확인하기 위해 공급업체에 물어봐야 할 질문도 소개합니다.