안녕하세요 HN, 저희는 Jay와 Frank이며 SST를 개발하고 있습니다.

SST는 AWS에서 서버리스 (Serverless) 앱을 구축하기 위한 프레임워크입니다. 여기에는 변경 사항을 적용하고 Lambda 함수를 라이브로 테스트할 수 있는 로컬 개발 환경이 포함되어 있습니다. 이는 귀하의 AWS 계정에 WebSocket 연결을 열어, 모든 Lambda 함수 호출 (Invocations)을 스트리밍하고, 이를 로컬에서 실행한 뒤 결과를 다시 전달하는 방식으로 작동합니다. 이를 통해 AWS 리소스를 모킹 (Mocking)하거나 변경 사항을 테스트할 때마다 매번 재배포할 필요 없이 함수 작업을 수행할 수 있습니다.

작동 모습을 담은 30초 분량의 영상은 다음과 같습니다 — https://www.youtube.com/watch?v=hnTSTm5n11g

배경 설명을 드리자면, 서버리스 (Serverless)는 클라우드 제공업체(이 경우에는 AWS)에 코드 조각(Lambda 함수라고 불림)을 보내는 실행 모델입니다. 클라우드 제공업체는 이를 실행하고 트래픽에 대응하여 확장 (Scaling)하는 책임을 집니다. 비용은 정확한 실행 밀리초 (Milliseconds) 단위로 청구됩니다.

지난 2016년, 저희는 서버리스를 발견하고 코드에만 집중할 수 있다는 아이디어에 매우 열광했습니다. 그래서 사람들에게 풀스택 서버리스 애플리케이션을 구축하는 방법을 보여주기 위해 가이드를 작성했습니다 — https://serverless-stack.com/#guide. 하지만 저희 독자 대부분이 Lambda 함수를 테스트하고 디버깅하는 데 매우 큰 어려움을 겪고 있다는 것을 알게 되었습니다. 로컬 Lambda 개발에는 두 가지 주요 접근 방식이 있습니다:

1. Lambda 함수가 사용하는 모든 서비스를 로컬에서 모킹 (Mock) 합니다. 예를 들어, Lambda 함수가 API 엔드포인트에 의해 호출된다면, 로컬 버전의 Lambda 함수를 호출하는 API 엔드포인트를 모킹하는 로컬 서버를 실행하게 됩니다. 이 아이디어는 SQS (큐), SNS (메시지 버스) 등과 같은 서비스로 확장될 수 있습니다. 하지만 Lambda 함수가 여러 서비스가 포함된 워크플로 (Workflow)의 일부로 호출되는 경우, 결국 수많은 서비스를 모킹해야 하는 경로로 빠지게 됩니다. 사실상 AWS의 모킹된 로컬 버전을 실행하는 셈입니다. 이러한 접근 방식을 사용하는 서비스(LocalStack 등)가 있지만, 실제로 사용해 보면 느리고 불완전한 경우가 많습니다.

2. 변경 사항을 다시 배포하여 테스트합니다. 이것이 바로 저희와 대부분의 독자들이 결국 도달하게 되는 지점입니다. Lambda 함수의 변경 사항을 만들고, 해당 특정 함수를 배포한 다음, 워크플로를 트리거하고, 디버그 메시지를 확인하기 위해 CloudWatch 로그가 나타나기를 기다립니다. Lambda 함수를 배포하는 데 5~10초가 걸릴 수 있으며, 로그가 나타나기까지 추가로 몇 초가 더 걸릴 수 있습니다. 이 프로세스는 매우 느리며, 변경 사항의 영향을 받은 함수들을 계속 추적해야 한다는 점도 요구됩니다.

저희는 커뮤니티의 많은 사람과 그들의 로컬 개발 환경 설정에 대해 이야기를 나누었고, 대부분은 현재 방식에 만족하지 못하고 있었습니다. 저희가 대화한 팀 중 하나는 ngrok(또는 터널링)과 같은 것을 사용하여 Lambda 함수 호출을 로컬 머신으로 프록시 (Proxy) 하는 아이디어를 시도해 본 적이 있다고 언급했습니다. 그리고 그것이 저희로 하여금 어떻게 하면 이 아이디어를 자동으로 수행해 주는 개발 환경으로 구축할 수 있을지에 대해 생각하게 만들었습니다.

그래서 저희는 SST를 만들었습니다. sst start 명령어를 실행하면 여러분의 AWS 계정에 작은 디버그 (debug) 스택(WebSocket API 및 DynamoDB 테이블)이 배포됩니다. 그런 다음 서버리스 앱을 배포하고, 앱 내의 Lambda 함수들을 스텁 (stub) Lambda 함수로 교체합니다. 마지막으로, 로컬 WebSocket 클라이언트를 실행하여 디버그 (debug) 스택에 연결합니다. 이제 여러분의 앱에서 Lambda 함수가 호출되면, 해당 함수는 WebSocket API를 호출하고, 이는 요청을 로컬 WebSocket 클라이언트로 스트리밍합니다. 그러면 Lambda 함수의 로컬 버전이 실행되고, 결과가 WebSocket API를 통해 다시 전송되며, 스텁 (stub) Lambda 함수가 그 결과를 응답하게 됩니다.

이러한 접근 방식에는 몇 가지 장점이 있습니다. Lambda 함수를 수정하고 이를 라이브로 테스트할 수 있습니다. 아무것도 모킹 (mocking)할 필요 없이 모든 Lambda 함수 트리거를 지원합니다. 디버그 로그는 로컬 콘솔에 즉시 출력됩니다. 또한 제3자 서비스가 개입되지 않습니다. 그리고 디버그 (debug) 스택은 서버리스 WebSocket API와 온디맨드 (on-demand) DynamoDB 테이블을 사용하기 때문에 비용이 저렴하며, 사용하지 않을 때는 비용이 청구되지 않습니다.

SST는 AWS CDK를 기반으로 구축되었습니다. 이를 통해 표준 프로그래밍 언어를 사용하여 AWS 인프라를 정의할 수 있습니다. 현재는 JavaScript와 TypeScript를 지원하며, 곧 다른 언어들에 대한 지원도 추가할 예정입니다.

SST에 대한 더 자세한 내용은 공식 문서(https://docs.serverless-stack.com)에서 확인하실 수 있으며, 프로젝트가 나아가는 방향은 공개 로드맵(https://github.com/serverless-stack/serverless-stack/milesto...)을 통해 살펴보실 수 있습니다.

저희에 대해 읽어주셔서 감사합니다. 꼭 한번 사용해 보시고 여러분의 의견을 들려주세요!