[누구나리포터 LAB] 서버리스 환경의 프로젝트는 어떻게 관리해야 될까?

서버리스를 쓰게 된 배경

 

이번에 테크포임팩트라는 활동을 통해서 비영리 기업을 지원하는 프로젝트에 참여하게 되었는데요. 해당 기업에서는 내부적으로 Lambda라는 기술을 사용하고 있어서 신규 프로젝트도 서버리스 환경에 맞춰 구축하고 운영하기 위해 고려해야 되는 점들을 조사하여 정리해보려고 합니다.

 

일단 프로젝트를 개발하고 운영하는 전략을 알아보기 전에 서버리스는 어떤 장점을 가지고 있기에 스타트업부터 대기업까지 다양한 규모의 기업들이 활용하고 있는지에 대해 자세히 알아봅시다.

 

서버리스의 가장 큰 장점 중 하나는 적은 러닝커브에 있습니다. 개발자가 일반적인 웹서버를 구축하기 위해 어떤 지식들이 필요한지 나열해보면 아래의 내용처럼 많은 지식들을 요구하는 것을 알 수 있었습니다. 그래서 초기에 개발을 배우고 서비스를 만드려는 분들에게 많은 큰 허들이 되는 경우도 있습니다.

• 프로그래밍(Java, Node.js, Python 등)
• 프레임워크(Django, SpringBoot, Nest.js 등)
• 인프라 관련(AWS, GCP, Linux, Docker 등)
• 네트워크(HTTP, IP, port 등)
• 데이터베이스(MySQL, MongoDB 등)

반면에 서버리스 같은 경우 어떠한 지식들을 필요로 하는지 알아봅시다. 

• 프로그래밍
• 프레임워크(Django, SpringBoot, Nest.js 등)
• 인프라 관련
• 네트워크 
• 데이터베이스 DocumentDB로 대체 시

위의 서버를 구축하는 것에 비교한다면 프레임워크에 대한 학습이 필요 없고 Docker나 Linux에 대한 지식이 없어도 충분히 개발하고 운영할 수 있습니다. 개발을 처음 하시는 분들에게는 서버리스를 운영하기  위해서는 람다를 사용하는 방법과 HTTP의 개념 그리고 기초 프로그래밍 등의 지식들만 알고 있다면 무리 없이 프로덕트를 개발할 수 있기 때문에 비교적 낮은 허들이 될 것입니다. 그리고 그 외에도 큰 장점이 있는데 그것은 비용입니다. 

 

서버리스를 활용한 비용 절약

AWS EC2의 과금 정책과 Lambda의 과금 정책

 

서버를 올리는 형태로 배포하는 EC2와 서버리스 환경인 Lambda의 요금 형태를 비교해 보면 과금을 부여하는 정책이 다르다는 것을 알 수 있습니다. EC2는 인스턴스를 사용하는 시간(서버가 떠있는 시간)을 기준으로 비용이 청구되고 Lambda는 요청 수와 요청 처리 시간을 기준으로 청구되고 있습니다. 더 쉽게 이해할 수 있도록 예시로 설명해보겠습니다. 

GPT-4o를 통해 계산

서버의 최소 스펙의 인스턴스인 T3.micro를 기준으로 평균 100ms 요청을 처리한다고 가정해봤을 때 계산을 해본 결과, 평균적으로 시간마다 5만 개의 요청이 와야 EC2를 운영하는 것이 비용적인 측면에서 유리하다고 이야기하고 있습니다. 위의 예시처럼 Serverless 플랫폼인 Lambda는 개발자가 부족한 회사뿐만 아니라 초기에 적은 트래픽을 가진 회사에서도 비용을 최적화하는데 좋은 솔루션이라는 것을 알 수 있었습니다

 

 

서버리스의 프로젝트의 코드베이스 관리 전략

서버리스가 나오게 된 배경과 장점들을 알아봤으니 서버리스 프로젝트를 구축하고 운영하기 위해 해야 필요한 전략들에 대해 알아봅시다. 일단 지속해서 변화하고 늘어가는 코드베이스를 관리하기 위해서는 레포지토리 전략은 필수입니다. 이런 전략들을 세우는 이유들을 설명하자면 코드의 일관성 유지, 협업 효율성 증대, 버전 관리 용이성 등으로 설명할 수 있을 것입니다.

 

쉽게 설명하자면 유지보수와 협업을 쉽게 하기 위해 세운다고 보면 이해하시면 됩니다. 특히 서버리스 환경에서는 각 함수들이 독립적으로 분리되어 운영되기 때문에, 이를 효과적으로 관리하려면 코드베이스를 어떻게 구성할지에 대한 전략이 중요합니다.

모노 레포 VS 멀티 레포

서버리스는 함수 별로 독립적으로 분리되어 운영되기 때문에 모놀리식으로 운영하는 데에는 어려움이 많습니다. 그렇기 때문에 서비스 별로 레포를 분리하거나 아니면 모노레포 안에서 서비스를 분리하는 형태로 운영을 합니다. 이 중에서 어떤 전략을 선택할지는 프로젝트의 규모와 팀원들 간 어떻게 코드를 액세스 할 것인지에 따라 다르기 때문에 아래의 장단점을 보고 잘 판단하시면 됩니다.

 

모노 레포의 장점

• 통합된 코드베이스
• 일관된 버전 관리 및 릴리즈
• 쉬운 리팩토링
• 일관된 개발 툴링

모노레포의 점

• 확장성이 떨어짐
• 코드 접근 권한 관리 어려움
• 의존성 충돌 위험

멀티레포의 장점

• 독립적인 코드베이스를 유지
• 코드 접근 권한 세분화 가능
• 프로젝트 별로 경량화된 저장소

멀티레포의 단점

• 의존성 관리 복잡성이 높음
• 리팩토링시 서로 다른 레포를 수정하고 같이 배포해야 되기 때문에 리팩토링 어려움
• 일관된 툴링 설정 어려움

참고로 대규모 프로젝트라고 해서 무조건 멀티 레포로 쓰는 것은 아닙니다. 구글은 대규모의 프로젝트를 모노 레포로 운영하기 위하여 필요한 시스템을 만들어 직접 개발하고 운영하고 있습니다. 하지만 구글은 전 세계에 손꼽히는 테크기업이기도 하고 이런 시스템에 많은 돈을 투자할 수 있는 리소스가 있기 때문에 가능했던 것이기 때문에 규모가 이미 큰 회사에서도 웬만하면 멀티레포를 통해 마이크로서비스를 운영하는 편입니다.

 

이야기가 많이 돌아갔지만 결국은 작은 팀에서 긴밀한 협업이 필요한 경우는 모노레포가 적합한 판단이라고 이야기 할 수 있습니다. 관리 측면에서도 단일 CI 설정을 통해 관리할 수도 있고 공통적인 환경변수 관리에도 더 쉽고 편리하기 때문에 모노레포를 기반으로 프로젝트를 구축하는 방향이 좋은 선택일 것입니다.

 

서버리스 프로젝트를 구축하기 위한 프레임워크 선택하기

 

위의 사진처럼 초기에는 AWS 웹사이트의 인터페이스를 활용하여 개발할 수도 있겠지만 점점 프로덕트가 발전하고 고도화 됨에 따라 점점 프로젝트를 더 관리하기 어려울 것입니다.

 

예를 들어, 서비스가 많아지면서 발생하는 각 서비스 별 개발/프로덕션 배포, 환경 변수 관리, 모듈 의존성 관리 등 많은 변수들이 생겨 복잡해지는 상황 속에 수동으로 모든 것을 설정하고 관리하게 된다면 많은 시간을 소요하게 되고, 복잡한 환경설정으로 인해 실수의 가능성도 높아집니다.

 

따라서 체계적으로 프로젝트를 구축하고 운영하고 싶다면 프레임워크를 사용을 권장 합니다. 프레임워크를 활용한다면 환경변수 관리, 배포 프로세스 관리 등의 번거로운 작업들이 내부적으로 구현되어 있기 때문에 시간이 대폭 단축되고 체계화된 형태로 관리할 수 있습니다. 이제 대표적인 서버리스 프레임워크로들을 소개해보도록 하겠습니다.

AWS SAM(Serverless Application Model)

AWS에서 Serverless환경에서 Application을 개발하고 관리하기 위해 만든 오픈소스 프레임워크입니다. SAM은 Lambda를 활용하여 서버리스 환경을 구축하는데 아래와 같은 강력한 기능들을 제공합니다. 

• 템플릿을 제공하여 템플릿 기반으로 쉽게 서버리스 환경을 구축할 수 있습니다.
• 코드 작성부터 배포, 테스트, 모니터링등 전체적인 라이프사이클을 관리할 수 있도록 지원하기 때문에 유지보수가 편리합니다.
• AWS에서 만든 프레임워크임인만큼 AWS 클라우드를 코드 레벨로 프로비저닝 하는데 강력한 모듈들을 지원하기 때문에 필요한 인프라를 손쉽게 구축할 수 있습니다.
• 도커를 활용하여 이미지 기반으로 람다 서비스를 관리할 수 있습ㄴ디ㅏ.

하지만 모든 기술들이 완벽한 답이 되지 않는 것처럼 AWS SAM도 다른 프레임워크에 비해 아래의 아쉬운 점들도 있습니다. 아래의 단점을 확인해보면 SAM은 AWS 서비스 안에서 애플리케이션을 만드는데 특화되어 있다는 것을 알 수 있습니다. 그래서 기능의 다양적인 부분과 양적인 측면에 아쉬운 부분들을 보이는 점이 많습니다.

• Single Sign-On(SSO)에 대한 지원이 부족하다.
• 다양한 클라우드환경 안에서 서버리스 환경을 구축하기 위한 기능들이 부족하고 기능의 양적인 측면에서도 밀리는 부분들이 있다.
• 타 프레임워크와 비교해봤을 때 표준적으로 사용하는 기능들에 대한 SDK 지원이 부족하다. (open api specification, ci/cd 등)

 

Serverless Framework

 

AWS Lambda가 출시되면서 개발자들은 이전에 없었던 서버리스라는 개념에 대해 많은 관심을 보였고 그 뒤로 GCP, Azure 등 다양한 클라우드 공급 업체들도 서버리스 제품을 만들기 시작했습니다. 하지만 클라우드 공급 업체에 따라 다른 구조로 프로젝트를 관리하는 것에 있어서 어려운 부분들이 많았고 표준화되어있지 않았기 때문에 복잡한 설정에 머리 아파하시는 분들도 많았습니다. 그래서 이런 문제를 해결하기 위해 Serverless Framework입니다.

• 언어의 제약 없이 다양한 클라우드 환경에서 서버리스 환경을 구축할 수 있습니다.
• AWS SAM과 마찬가지로 코드 작성부터 배포, 모니터링 등 전체적인 라이프 사이클을 지원해 줍니다.
• 다양한 플러그인을 제공하고 해당 생태계가 활발하기 때문에 편리하게 서버리스를 확장하고 변경할 수 있습니다.

하지만 서버리스 프레임워크를 활용하더라도 클라우드 공급업체에 대한 종속성을 완전히 벗어나기는 어렵습니다. 예를 들어 AWS Lambda에 맞춰 프로젝트를 개발하다가 GCP의 Cloud Function으로 전환하려고 한다면 GCP에서 제공해 주는 스펙에 맞춰 야믈과 코드들을 변경해야 될 것입니다. 그 외에도 별도의 클라우드 환경에서 운영되어 돌아가다 보니 디버깅의 어려움이 있습니다.

 

Swarmion

 

서버리스 관련 프레임워크에 대해 찾아보다가 swarmion에 대해 알게 되었습니다. 마이크로서비스 환경을 모노 레포로 관리하는데 특화되어 있다는 장점을 가지고 있고 기존에 야믈을 기반으로 관리하는 프레임워크가 아닌 코드를 기반으로 인프라를 구축하고 연동할 수 있다는 점에서 차별성을 가지고 있는 기술입니다. 그리고 타입 스크립트를 기반으로 작성되어 있기 때문에 타입 안정성 또한 보증해 줍니다.

• 코드를 기반으로 서버리스를 구축함으로써 공통적으로 필요한 인프라 로직이 있다면 공유하여 활용할 수 있음
• 저수준 소프트웨어를 통해 테스트와 빌드시간을 최소화하기 때문에 비교적 빠른 속도의 CI/CD를 제공합니다.

하지만 나오지 얼마 되지 않은 프레임워크이기 때문에 TypeScript밖에 지원하지 않는다는 점과 AWS SAM과 Serverless Framework와 비교했을 때에도 기능의 다양성과 다양한 환경에서의 호환성이 떨어지는 부분들이 어느정도 있습니다.

 

하지만 생산성을 중요시하는 문화를 가지고 있고 인프라를 코드를 기반으로 관리함으로써 표준화된 마이크로서비스를 구축한다고 하면 좋은 선택지가 될 수 있을 것 같습니다.

 

서버리스 환경에서의 프로젝트 폴더 구조

기존의 서버와 다른 형태로 개발해야 되다보니 AWS Lambda는 어떠한 형태의 폴더 구조를 만들어 개발해야 되는지 모르는 경우들이 많습니다. 서버리스 기반의 프로젝트의 폴더 구조는 일반적인 서버 프로젝트와 다르게 이벤트나 도메인 중심적으로 분리하게 되는데 우선적으로 마이크로서비스 형태의 디렉토리 구조를 설명하도록 하겠습니다.

 

마이크로서비스 형태의 폴더 구조는 도메인 별로 디렉터리를 구분 지으며 각 디렉터리 안에 해당 마이크로서비스에서 동작하는 API와 비즈니스 로직들을 포함하고 있습니다. 만약 공통적으로 사용해야 되는 모듈이 있다면 src와 같은 위치에 lib를 생성하고 해당 폴더 아래의 필요한 모듈들을 추가하시면 됩니다. 자세한 내용은 아래의 링크를 참고하시길 바랍니다. 

 

이벤트 기반의 폴더 구조는 말 그대로 필요한 비즈니스의 로직들을 이벤트 별로 정의하고 관리하는 형태입니다. lambdas라는 폴더 안에 각 이벤트마다 폴더들을 가지고 있으며 각 폴더 안에서는 해당 이벤트의 동작을 나타내는 코드와 디펜던시들을 포함하고 있습니다. 

 

두 가지의 폴더 구조 방식은 각각의 개성이 뚜렷하기 때문에 내가 만들어야 하는 소프트웨어의 성향에 따라 선택하면 됩니다. 프로젝트가 이벤트나 트리거 기반의 동작이 대다수이고 각각의 이벤트들이 독립적으로 동작해야 된다면 이벤트기반의 아키텍처가 적절한 선택이 될 것이고 내가 만들고자 하는 소프트웨어가 도메인 중심적이며 도메인을 기반으로 비즈니스 로직들을 작성해야 된다면 후자가 좋은 선택이 될 것입니다.

 

후기

서버리스 환경에 대해 사실 들어만 보고 직접적으로 사용해 본 경험은 없었는데 이번 기회로 서버리스 환경이 어떤 배경으로 나왔는지와 서버리스 생태계에도 많은 발전들이 이뤄지고 있다는 것을 알게 되어 재밌게 리서치할 수 있었던 것 같습니다. AWS를 사용하면 비싼 유지비용을 생각하며 데탑이나 NAS를 구매하여 서버를 구축하시는 사례들을 많이 봐왔는데 직접 물리 서버를 구축하기보다는 이처럼 서버리스 환경을 활용하여 초기에 작은 비용으로 시작해 보는 것도 좋은 방법 중 하나일 것 같습니다.

 

테크포임펙트 활동을 기회로 서버리스 환경을 구축하기 위해 필요한 기반 작업들과 관련 기술들을 쭉 나열해 봤는데요. 초기에는 AWS 사이트의 UI를 통해 개발하는 것도 무리가 없겠지만 프로덕트가 발전되고 고도화될수록 어려운 부분들이 많을 것입니다. 수작업보다는 공정을 통해 생산되는 제품이 빠르게 나오듯이 프로덕트의 발전으로 인해 점점 관리가 어려워진다면 이처럼 프레임워크를 활용한다면 빠르고 안정적이게 프로덕트를 개발할 수 있는 방법 중 하나가 될 것입니다. 이 글을 통해 저처럼 서버리스를 시작하려고 하시는 분들에게 좋은 자료가 되었으면 좋겠네요 ㅎㅎ