서버리스(Serverless) 아키텍처, 개발자에게 무엇을 의미할까?

서버리스 아키텍처란 무엇인가?

“서버 없는” 착각과 실제 의미

‘서버리스(serverless)’라는 말은 문자 그대로 “서버가 없다”는 뜻처럼 들리지만, 실제로는 서버는 존재하되 개발자가 그것을 직접 관리하지 않게 된다는 의미입니다. 클라우드 제공자가 서버 프로비저닝, 유지관리, 자동 확장 등을 책임지고, 개발자는 오직 비즈니스 로직에 집중할 수 있도록 추상화된 환경을 제공하는 것이 서버리스의 핵심입니다.

클라우드 제공자는 이벤트 기반으로 코드를 실행하고, 실행된 시간과 메모리 소모량에 따라 비용을 청구합니다. 즉, 사용되지 않을 때는 비용이 거의 들지 않도록 설계됩니다.

서버리스 아키텍처의 구성 요소 및 작동 방식

서버리스 아키텍처는 여러 구성 요소가 유기적으로 작동하는 방식입니다:

FaaS (Function as a Service)

작은 단위 함수(또는 핸들러)를 작성하고, 특정 이벤트가 발생했을 때 호출됩니다. 함수는 상태를 오래 유지하지 않으며, 요청 처리가 끝나면 자원을 반납합니다.
이벤트 트리거 / 이벤트 소스

HTTP 요청, 데이터베이스 변경, 메시지 큐, 파일 업로드, 시간 스케줄러 등 다양한 이벤트가 함수 실행을 유발합니다.
관리형 서비스 (BaaS: Backend as a Service)

데이터베이스, 인증, 스토리지, 메시징 등은 클라우드 제공자가 관리하는 서비스로 제공됩니다. 개발자는 이를 활용해서 빠르게 기능을 구성할 수 있습니다.
API 게이트웨이 / 라우팅 계층

외부 요청을 함수 또는 서비스로 연결해 주는 게이트웨이 또는 라우터 역할이 필요합니다.
자동 확장 및 자원 해제

요청 부하에 따라 함수 인스턴스가 자동으로 확장되며, 요청이 없는 경우 인스턴스는 축소되거나 제거됩니다.

작동 흐름은 대체로 다음과 같습니다:

클라이언트 요청(예: HTTP) → API 게이트웨이 → 해당 요청을 처리하는 함수 실행 → 함수 내부에서 BaaS 서비스 호출 (데이터 읽기/쓰기 등) → 응답 반환 → 함수 종료 또는 유휴 대기

개발자에게 서버리스가 의미하는 변화

서버리스 아키텍처는 단순히 인프라 관리를 덜어주는 것 이상의 변화를 개발자에게 가져다줍니다. 좋은 점도 많고 주의해야 할 점도 있습니다.

장점: 개발자가 누릴 수 있는 혜택

운영 및 인프라 관리 부담 감소

서버 설정, 패치, 운영체제 업그레이드, 자동 확장 정책 설정 등을 직접 하지 않아도 되므로, 운영 관련 오버헤드가 줄어듭니다.
비용 효율성 (pay-as-you-go 모델)

사용한 만큼만 비용이 청구되기 때문에, 유휴 자원에 대한 낭비를 줄일 수 있습니다.
자동 확장성 확보

트래픽 변화에 따라서 클라우드 제공자가 자동으로 인스턴스를 늘리거나 줄여 줍니다. 개발자는 용량 예측에 덜 신경 써도 됩니다.
빠른 개발 및 배포 속도

인프라 구축이나 설정 없이 코드를 함수 단위로 배포할 수 있으니, 기능 추가나 수정 시 릴리즈 주기를 단축할 수 있습니다.
모듈화 / 책임 분리 촉진

함수를 작고 독립적으로 나누면 책임 범위가 명확해지고, 테스트 및 유지보수가 쉬워집니다.
재해 복구 비용 절감

서버리스는 재해 복구(Disaster Recovery) 사이트를 구성할 때도 비용이 낮을 가능성이 있습니다. 사용되지 않을 때 비용이 거의 없기 때문입니다.

단점 / 주의해야 할 점

콜드 스타트(Cold Start) 지연

함수가 일정 시간 호출되지 않으면 인스턴스가 내려가 있다가 다시 요청이 오면 부팅하는 데 시간이 걸릴 수 있습니다. 응답 지연이 발생할 수 있습니다.
함수 실행 시간 및 리소스 제한

메모리 사용량, 실행 시간(timeout), 디스크 I/O 등에 제한이 있는 경우 복잡한 작업에는 제약이 생길 수 있습니다.
디버깅 및 모니터링 복잡성

함수들이 분산 실행되고 상태를 오래 유지하지 않기 때문에, 전체 흐름(trace를 잇는 디버깅이나 에러 추적이 어렵습니다. 로그 수집, 분산 추적 등이 중요해집니다.
클라우드 제공자 종속성 (Vendor lock-in)

각 클라우드 업체의 함수 플랫폼, BaaS 서비스, 인증/권한 모델 등에 종속될 위험이 있으며, 나중에 다른 클라우드로 이전하기 어려울 수 있습니다.
비용 예측의 어려움 / 지속 사용 시 비용 증가 가능성

요청이 많고 함수 호출이 빈번해질수록 누적 비용이 커질 수 있으며, 지속적으로 높은 부하가 있는 서비스는 전통적인 서버 방식이 더 효율적일 수 있습니다.
아키텍처 복잡성 증가

함수간 호출이 많아지면 복잡한 이벤트 흐름이 되고, 지연/오류 전파 관리가 어려워질 수 있습니다 (“Lambda Pinball” 패턴 등)
상태 유지 어려움

함수는 본질적으로 무상태(stateless)이기 때문에, 상태 유지가 필요한 경우 외부 저장소를 사용해야 하고, 일관성 관리가 까다로워질 수 있습니다.

개발자 관점에서의 핵심 고려 사항

서버리스를 효과적으로 도입하고 활용하려면, 개발자/아키텍트로서 다음과 같은 부분들을 주의해야 합니다.

함수 설계 전략

함수 단위는 너무 작게 만들면 호출 오버헤드나 관리 복잡성이 커질 수 있으므로 적절한 수준으로 설계해야 합니다.
함수 간 호출 체인이 길어지면 복잡성과 지연이 커지므로, 지나치게 세분화된 구조는 피해야 합니다.
가능한 비동기 처리를 활용하고, 이벤트 중심 아키텍처를 적극적으로 설계하는 것이 좋습니다.

콜드 스타트 완화

“프로비저닝된 동시성(provisioned concurrency)” 또는 함수 워밍업 전략을 도입할 수 있습니다.
빈번히 호출되는 함수나 낮은 대기 시간이 중요한 함수는 미리 준비해 두는 방법을 고려해야 합니다.

리소스 / 타임아웃 최적화

메모리 할당, 타임아웃 시간 등을 조정하여 비용과 성능의 균형을 맞춰야 합니다.
함수 내부 로직을 효율적으로 작성하고, 외부 서비스 호출을 최소화하는 방식이 좋습니다.

로깅 / 모니터링 / 분산 추적

중앙 로깅 시스템, 분산 추적(distributed tracing) 도구, 경고(alert) 체계를 구축해야 합니다.
함수 호출 흐름 전체를 추적할 수 있는 로깅 및 모니터링이 필수적입니다.

권한 및 보안 설계

함수별 최소 권한 원칙을 지켜야 합니다.
비밀 정보(Secrets) 관리, 네트워크 경계 설정, 입력 유효성 검사 등을 꼼꼼하게 구성해야 합니다.

벤더 종속성 완화 시도

클라우드 기능 호출 부분을 추상화하거나 인터페이스를 분리해서, 향후 다른 클라우드 또는 온프레미스로의 이전 가능성을 열어 두는 전략이 필요할 수 있습니다.
표준화된 프레임워크나 오픈소스 플랫폼을 활용하는 것도 한 방법입니다.

언제 서버리스를 사용하는 것이 적절한가?

서버리스가 항상 정답은 아니며, 아래 경우들에 적합하거나 유리한 경우가 많습니다.

적합한 경우

트래픽이 불규칙하거나 간헐적인 서비스
기능 단위가 비교적 작고 독립적인 업무 로직
빠른 프로토타이핑이나 MVP 개발 시
이벤트 중심 워크플로우 (예: 파일 업로드 처리, 알림, 메시지 처리 등)
급격한 트래픽 변화 가능성이 있는 캠페인, 프로모션 기능 등

부적합하거나 주의해야 할 경우

지속적으로 높은 부하가 걸리는 핵심 기능
매우 낮은 응답 지연(Latency)을 반드시 보장해야 하는 서비스
긴 실행 시간이 필요한 작업 (예: 영상 인코딩, 대규모 데이터 처리 등)
인프라 제어가 꼭 필요한 경우
다중 클라우드 전략 또는 클라우드 이전 가능성을 강하게 고려해야 하는 경우

마무리하며

서버리스 아키텍처는 개발자에게 많은 자유와 효율성을 제공하는 모델입니다. 인프라 운영 부담을 줄이는 동시에, 기능 개발과 비즈니스 로직에 더 집중할 수 있게 해 줍니다. 하지만 이와 동시에 아키텍처 설계, 비용 최적화, 모니터링 및 디버깅 역량이 더욱 중요해지며, 무작정 서버리스로 전환하는 것이 옳지는 않습니다.