서버리스 컴퓨팅 시대의 풀 스택 개발

이 글은 Amazon Web Services의 Developer Advocate인 Nadar Dabit의 블로그글 Full-Stack Development in the Era of Serverless Computing을 본인의 허락을 받아 한글로 번역한 글 입니다.

서버리스 기술이 풀 스택 개발을 어떻게 변화시키고 있는가.

과거에는 프론트엔드 개발자와 프론트엔드 개발이 백엔드 개발만큼 중요하다거나 복잡하다고 여겨지지는 않았습니다. 하지만 지금은 다릅니다.

프론트엔드 개발은 지금은 훨씬 중요하게 취급되고 있습니다. 프론트엔드 개발자는 이제 백엔드 개발자만큼 수요가 많을뿐만 아니라 전문분야에 따라서는 오히려 더 귀한 대접을 받기도 합니다.

지난 10년 동안 백엔드는 자동화 및 편의성이 크게 향상되었지만 프론트엔드는 복잡성이 클라이언트 영역으로 이동함에 따라 실제로 점점 더 어려워지고 있습니다.

SPA의 증가, 더 복잡한 데이터 문제, 대상 기기의 증가 및 사용자 경험에 대한 기대 때문에 클라이언트 측 개발은 지난 10년 간 더욱 복잡해졌습니다.

프론트엔드가 점점 더 중요한 시대로 접어들고 있습니다. 프론트엔드 개발자는 이제 거의 백엔드코드를 사용하지 않으면서도 견고한 풀스택 응용 프로그램을 만들어내고 있습니다.

기술이 발전함에 따라 추상화도 진보되었습니다. 이제 곧 알게 되겠지만, 프론트 엔드 개발자의 영역은 더이상 응용프로그램의 프론트엔드 계층에만 머물지 않습니다. 지금부터 제가 설명해 드리겠습니다.

완전히 새로운 형태의 컴퓨팅 환경의 등장

그럼 지금부터 지난 수십 년 동안 컴퓨터 환경이 어떻게 발전해 왔는지 살펴 보겠습니다.

온프레미스

과거에는 사내 혹은 데이터 센터에 있는 응용 프로그램을 실행하기 위해 서버 랙을 구축해야만 했었습니다. 문제가 발생하면 직접 데이터 센터로 이동하여 현장에서 복구하거나 새 서버로 교체해야 합니다. 이러한것은 대체로 유지보수에 상당한 노력이 소요됩니다.

클라우드

클라우드 컴퓨팅이 등장하자 기업과 개발자들은 워크로드를 클라우드로 옮기고 클라우드 공급자가 인프라의 유지관리를 하도록 하기 시작했습니다.

이 경우에도 워크로드는 여전히 패치, 업데이트 및 가용성에 대한 관리가 필요한 서버상에서 실행됩니다. 확장성 또한 서버를 유지 보수하는 개발자나 팀이 직접 관리해 줘야만 합니다.

서버리스

서버리스 패러다임이 도입됨에 따라 가용성의 관리나 서버 패치 및 업데이트 관리의 필요성을 제거한 또 다른 수준의 추상화가 도입되게 됩니다. 서버리스 어플리케이션은 이벤트 드리븐이며 (한 번의 호출로 지속되는)임시적인 스테이스리스 컴퓨팅 컨테이너에서 실행되며 선택한 클라우드 제공자에 의해 완벽하게 관리됩니다.

이러한 응용 프로그램은 완벽하게 확장되며 서버 유지관리 작업은 일체 필요치 않습니다.

서비스형 서버리스

최근 저는 Joe Emison이 서비스형 서버리스(Serviceful Serverless)라는 용어를 사용한 글을 보았습니다.

이 글에서 당신은 “서비스형 서버리스Serverceful Serverless”라는 용어를 사용했는데 이것은 이미 존재하는 용어인가요? 나는 관리형 서버리스 서비스를 어떻게 불러야 할 까에 대해서 고민해 왔습니다. 과거에는 의미 그대로 “관리형 서버리스Managed Serverless”라는 용어를 써 왔는데 당신의 의견은 어떠한가요?

그는 대답대신 이 용어가 사용된 대화의 링크를 보내주었습니다.

@patrickdebois 2016년 브룩클린에서 있었던 제1회 서버리스콘퍼런스에서 “서비스형(Serviceful)”이라는 용어가 만들어졌습니다. @mikebroberts 는 마틴파울러의 사이트에서 이를 BaaS(Backend as a Service)라고 불렀습니다. 하지만 그것은 나에게 있어서 적은양의 코드로 동작하는 플랫폼을 의미하기 때문에 나는 그 용어가 마음에 들지 않습니다.

저도 비슷한 생각을 지니고는 있었지만 용어 자체는 처음 듣는 것 이었습니다. 같은 아이디어에 대해 저는 관리형 서버리스라는 용어를 사용했지만 그것이 무엇인지에 대해서 정확히 설명한다는 점에 있어서는 서비스형 서버리스라는 용어가 더 낫다고 생각합니다.

서비스형 서버리스는 정해진 일련의 서비스를 제공하면서도 확장성과 가용성에 대한 관리를 포함해 그 어떠한 종류의 서버 유지관리 작업이 필요 없다는 점은 기존의 서버리스와 같지만, 코드를 필요로 하지 않는다는 점이 기존의 서버리스와는 본질적으로 차별화 되는 지점입니다.

서비스형 서버리스의 몇가지 예를 들어보자면 Auth0 / Amazon Cognito(관리형 인증 서비스), Algolia(관리형 검색 서비스), AWS AppSync / Cloud Firestore (관리형 API 서비스), Amazon Lex / Rekognition / Textract (머신러닝 서비스), 그리고 Cloudinary (관리형 이미지 & 비디오 호스팅 서비스)와 같은 것 들이 있습니다.

과거에는 이러한 백엔드 기능(검색, API계층, 인증 등)마다 유능한 백엔드 엔지니어가 투입되어 안전하고 적절하게 구축되기까지 몇 주 혹은 몇 달이 걸렸었습니다.

이제 프론트엔드 개발자는 백엔드 코드가 거의 없거나 전혀 없는 상태에서 실제 백엔드 구현에 대한 지식 없이도 이러한 서비스에 연결하여 적은 시간과 비용으로 필요로 하는 기능을 구현할 수 있습니다.

코드리스

이러한 서비스는 제3자가 만들고 관리하기 때문에 대부분의 경우 백엔드 코드를 작성하지 않아도 되므로 응용 프로그램의 코드가 줄어들게 됩니다.

적은 코드로 인해 버그가 줄어들고 응용 프로그램을 유지 관리하기도 훨씬 쉬워집니다.

새로운 개발자가 팀에 오거나 조직의 다른 누군가에게 프로젝트를 넘겨주는 경우에도 신경써야 할 부분이 적기 때문에 빠르게 적응할 수 있게 됩니다.

복잡성 감소

코드가 적을수록 복잡성도 줄어듭니다. 이 아키텍처는 단순하게 작동하는 API를 제공함으로써 복잡성을 추상화 할 수 있게 해 줍니다.

개발 속도

이러한 엔지니어링 방식을 통해 개발자와 기업은 훨씬 빠르고 비용 효율적으로 반복 작업을 수행 할 수 있으므로 수동으로 이러한 서비스를 구축해야만 하는 기존의 방식보다 더 자주 그리고 더 적은 오버헤드로 실험을 가능케 해 줍니다.

비용

급속하게 증가된 개발 속도로 인해 얻을 수 있는 이점 이외에 비용적인 이점도 있습니다. 이 패러다임을 통해 한꺼번에 대규모의 비용이 들어가는 자본 비용 방식을 필요한 만큼만 비용을 지불하는 가변 비용방식으로 전환할 수 있게 됩니다.

바퀴를 새로 발명하지 말라는 격언처럼 이미 존재하는 기능을 다시 만들기 위해 엔지니어에게 매번 비용을 지불하는 대신 여러분은 기본적인 구현에 대해서는 신경 쓸 필요 없이 정의된 기능 세트 혹은 API를 구독하기만 하면 됩니다.

신뢰성과 보안

이러한 서비스는 해당 서비스를 개발하고 유지 관리하는 대규모의 전담팀에 의해 지속적으로 개선되어져 나갑니다. 그들은 일반적으로 많은 수의 고객들과 더 많은 수의 사용자들에게 서비스를 제공하고 있습니다.

이것은 일반적으로 여러분이나 여러분의 팀이 엄청난 시간을 투자하지 않고서는 할 수 없는 것들을 만들어내고 이를 지속적으로 개선해 나가는 전문 엔지니어링 팀이 있다는 것을 의미합니다.

그들은 당신이 생각치도 못했을지 모르는 수많은 문제들을 엄청난 양과 경험속에서 해결해 왔습니다.

이렇게 다양한 상황속에서 검증된 것에 의존하는 것은 분명한 이점이 있습니다.

서버리스란 무엇인가?

서버리스에 대해서는 학문적으로나 여러 주관적인 정의들을 발견할 수 있지만 서버리스 응용 프로그램의 실제 형태에 대한 일반적인 정의는 없습니다.

예를 들어 사람들은 서버리스를 언급할때 일반적으로 클라이언트로부터 호출되는 서로 연동되는 람다 함수의 집합을 떠올립니다.

상호 호출되는 기능의 모음을 대신할 서비스형 서버리스 응용 프로그램의 좋은 예는 다음과 같다: a) 모든 상호 작용 로직을 처리하는 두터운 클라이언트 코드, b) 자주 사용되는 서비스들(예: AppSync, Cognito, @Auth0, @Algolia, @Cloudinary), c)연계를 위해 사용되는 작은 함수

나는 최신 서버리스 응용 프로그램을 어떻게 설계해야 하는지에 대한 이 의견에 동의할 뿐만 아니라 스타트업에서 포츈500대 기업에 이르는 기업들이 실제로 어떻게 사용하고 있는지를 매일 보고 있습니다.

하지만 이 주제에 대한 토의는 볼 수 가 없습니다. 엄청나게 값싸고 빠르게 새로운 아이디어를 프로토타이핑하고 테스트할 수 있다는 장점이 혁신의 긍극적인 원동력이 되고 있다고 생각합니다. 실패는 전 보다 더 용인되기 쉬워지는데, 서비스가 일상적으로 그리고 빠르게 분해되거나 재건될 수 있게 되었기 때문입니다.

점점 더 많은 기업과 개발자가 전통적인 백엔드와 이를 전담하는 엔지니어링팀의 필요성을 배제하고 중요한 작업 부하를 이러한 유형의 관리형 서비스로 이동하면서 사용자에게 가치를 전달하려는 노력에 집중하고 있습니다.

2019년 이후의 전망

이 서비스형 서버리스의 철학은 향후 수 개월에 걸쳐 더 많이 눈에 띌 것입니다.

소프트웨어 개발과 관련된 복잡성이 지속적으로 높아지면서 양질의 소프트웨어 엔지니어에 대한 수요와 비중이 전 세계적으로 급증함에 따라 클라우드 공급업체들이 이러한 관리형 서비스를 배로 늘리게 되며, 소프트웨어 기업과 개발자들은 이러한 서비스들을 활용하여 이러한 서비스가 제공하는 이점을 누리게 될 것입니다.

만약 당신이 이러한 서비스를 활용한 앱 제작 방식을 팀에 도입하고자 한다면 저희가 서비스형 서버리스의 철학에 기반하여 구축한 프레임워크인 AWS Amplify를 살펴 보시기 바랍니다.

제 이름은 Nader Dabit입니다.

저는 AWS Mobile의 Developer Advocate로서 AWS AppSync 및 AWS Amplify와 같은 프로젝트 관련 작업을 수행하고 있습니다. 저는 React Native in Action, React Native Training , 그리고 OpenGraphQL의 저자이기도 합니다.