안녕하세요, 코딩은 못 하지만 IT가 너무 궁금한 비개발자 루카(Luka)입니다.

thumbnail

최근 몇 년간 '서버리스(Serverless)'라는 단어를 안 들어본 사람이 없을 정도로 뜨겁잖아요? 특히 AWS 람다(Lambda)가 그 중심에 있다고 해서, 개발자는 아니지만 도대체 이게 뭔지 너무 궁금해서 직접 파보고 기록으로 남겨보려 합니다. 제 식대로 '버튼 누르면 마법처럼 내 코드가 실행되는 서비스'라고만 어렴풋이 알고 있었는데, 막상 뚜껑을 열어보니 생각보다 훨씬 더 흥미로운 세계더라고요.

AWS 람다, 이게 대체 뭔데? (비개발자 시선)

제가 이해한 AWS 람다는 한마디로 "서버 관리에 대한 걱정 없이, 내가 짠 코드 조각(함수)만 AWS에 올리면 필요할 때 알아서 실행시켜주는 서비스"입니다. '서버리스'라는 말이 '서버가 없다'는 뜻은 아니고요(서버는 AWS 데이터 센터 어딘가에 있겠죠!), '우리가 서버를 직접 관리할 필요가 없다'는 의미더라고요.

생각해 보세요. 예전에는 웹사이트 하나 만들려면, 일단 서버 컴퓨터를 사거나 빌리고, 운영체제 깔고, 웹서버 소프트웨어 설치하고, 보안 패치도 주기적으로 해줘야 했잖아요? 트래픽이 늘어나면 서버를 더 늘리거나 업그레이드하는 것도 모두 우리의 몫이었고요. 람다는 이런 번거로운 과정을 AWS가 전부 알아서 처리해 주는 겁니다. 마치 제가 필요한 요리를 만들기 위해 직접 부엌을 짓고 재료를 준비하는 대신, 그냥 레시피만 주면 최고급 주방장이 알아서 요리해서 가져다주는 것과 비슷해요!

루카의 첫 람다 경험: 직접 만들어보니!

호기심에 덜컥 AWS 계정을 만들고(프리티어 만세!), 람다 콘솔로 들어가 봤습니다. 함수를 만드는 과정은 생각보다 직관적이더군요. 몇 번의 클릭만으로 제 첫 람다 함수를 생성할 수 있었습니다.

저는 가장 간단한 Python 런타임을 선택했어요. '함수 생성' 버튼을 누르고, 이름은 'MyFirstLambdaFunction'이라고 지었습니다. 그리고 기본으로 제공되는 코드 대신, 제가 이해할 수 있는 수준의 짧은 코드를 넣어봤습니다.

import json

def lambda_handler(event, context):
    # 이 함수는 'event'라는 데이터를 받아서 처리합니다.
    # 그리고 'statusCode'와 'body'를 담은 응답을 돌려줍니다.
    return {
        'statusCode': 200, # HTTP 상태 코드 200은 '성공'을 의미해요.
        'body': json.dumps('루카의 첫 람다! 안녕, 서버리스 세계!') # 응답 메시지
    }

이 코드를 복사해서 람다 콘솔의 코드 에디터에 붙여 넣고 'Deploy' 버튼을 눌렀습니다. 그리고 'Test' 버튼을 눌러보니, 제가 넣은 메시지가 고스란히 출력되는 걸 보고 어찌나 뿌듯하던지요! 코딩을 전혀 모르는 제가 IT 서비스의 핵심을 건드려 본 느낌이었습니다. 람다는 이렇게 특정 '이벤트'가 발생했을 때만 실행되는 '함수'예요. 어떤 이벤트가 이 함수를 실행시킬지는 '트리거'라는 것을 설정해야 합니다.

왜 람다를 쓸까? 비개발자가 본 매력적인 장점들 (수치와 함께!)

제가 직접 알아보니, 람다가 왜 이렇게 핫한지 충분히 이해가 되더라고요. 특히 비개발자 입장에서 와닿는 장점들이 많았습니다.

1. 비용 효율성: 쓴 만큼만 낸다! (초절약 모드)

가장 큰 장점 중 하나는 역시 비용이었습니다. 람다는 코드가 실행된 횟수와 실행된 시간(밀리초 단위!)에 따라서만 요금을 부과해요. 서버를 24시간 켜두는 것에 비해 엄청나게 효율적이죠. 공식 문서를 찾아보니, AWS 프리티어 사용자라면 한 달에 1백만 건의 요청(requests)과 40만 GB-초(GB-seconds)의 컴퓨팅 시간을 무료로 쓸 수 있다고 합니다. 이 정도면 웬만한 개인 프로젝트나 소규모 서비스는 거의 공짜로 운영할 수 있는 수준이에요. 제가 알아본 바에 따르면, 메모리 128MB 기준으로 1백만 번 실행 시 0.20달러, 실행 시간에 따라 추가 요금이 붙는 식입니다. 서버 한 대 계속 돌리는 것과 비교하면 정말 미미한 수준이죠.

2. 자동 스케일링: 트래픽 걱정은 이제 그만!

트래픽이 갑자기 폭주했을 때 서버가 다운되는 경험, 들어보셨을 겁니다. 람다는 이런 걱정을 할 필요가 없어요. 제 코드가 초당 100번 실행되든, 1만 번 실행되든 AWS가 알아서 필요한 만큼의 자원을 할당해서 처리해 줍니다. AWS 공식 문서에서는 람다 함수가 초당 수천 건의 요청도 너끈히 처리할 수 있도록 설계되었다고 강조하더군요. 갑작스러운 이벤트성 트래픽에도 유연하게 대처할 수 있다는 게 큰 매력이었습니다.

3. 운영 부담 감소: 서버 관리에서 해방!

개발자분들께 들어보니 서버 관리라는 게 생각보다 손이 많이 가는 일이라고 합니다. 운영체제 업데이트, 보안 패치, 모니터링 등 신경 쓸 게 한두 가지가 아니죠. 람다는 이런 모든 인프라 관리 업무를 AWS가 대신해 줍니다. 저는 그냥 코드만 잘 짜서 올리면 되는 거죠. 개발팀은 서버 유지보수 대신 서비스 기능 개발에 더 집중할 수 있게 됩니다.

4. 빠른 배포: 신속한 서비스 개발

새로운 기능을 만들고 배포하는 데 걸리는 시간도 단축됩니다. 서버 환경을 세팅하고 배포 파이프라인을 구축하는 복잡한 과정 없이, 코드만 업로드하면 바로 적용되니 훨씬 빠르죠. 제가 찾아본 사례 중에는 어떤 팀이 빌드 시간을 42초에서 11초로 줄였다는 이야기도 있었습니다.

람다, 마냥 좋을까? 비개발자가 본 단점과 고려사항

물론 람다가 만능은 아니었습니다. 몇 가지 아쉬운 점이나 주의해야 할 점도 눈에 띄더군요.

1. 콜드 스타트(Cold Start): 가끔은 느릴 수 있어요

람다 함수가 오랫동안 호출되지 않다가 처음으로 호출될 때, AWS가 해당 함수를 실행할 환경을 준비하는 데 시간이 걸릴 수 있습니다. 이걸 '콜드 스타트'라고 부르더라고요. 일반적으로 수백 밀리초에서 길게는 몇 초까지 걸릴 수 있다고 합니다. 자주 호출되는 함수는 이미 준비된 환경에서 실행되므로 빠르지만(웜 스타트), 가끔씩 실행되는 함수는 이 콜드 스타트 때문에 약간의 지연이 발생할 수 있어요.

2. 제한된 실행 시간 및 리소스

람다 함수는 무한정 실행될 수 없습니다. 제가 찾아보니 최대 실행 시간은 15분(900초)으로 제한되어 있습니다. 또한 메모리도 128MB에서 10,240MB(10GB)까지 설정할 수 있지만, 정해진 범위 내에서만 사용해야 합니다. 아주 긴 시간 동안 대량의 데이터를 처리해야 하는 작업에는 적합하지 않을 수 있습니다.

3. 복잡한 아키텍처 이해와 디버깅

서버리스 아키텍처는 이벤트 기반으로 동작하기 때문에, 전체 시스템의 흐름을 이해하는 데 전통적인 서버 방식보다 더 많은 노력이 필요할 수 있습니다. 로그가 분산되어 관리되는 경향이 있어 디버깅이 까다롭다는 이야기도 있더군요. AWS CloudWatch 같은 서비스를 통해 로그를 통합해서 봐야 합니다.

4. 벤더 종속성 (Vendor Lock-in)

한 번 AWS 람다에 익숙해지면, 다른 클라우드 서비스(Google Cloud Functions, Azure Functions 등)로 옮기거나 다시 전통적인 서버 방식으로 돌아가기가 쉽지 않을 수 있습니다. 특정 클라우드 서비스에 종속될 수 있다는 점은 항상 염두에 둬야 합니다.

AWS 람다 vs. 전통 서버: 비개발자를 위한 비교표

제가 직접 찾아본 정보를 바탕으로 람다와 전통적인 서버 방식을 비개발자 입장에서 비교해 봤습니다.

특징 AWS 람다 (서버리스) 전통 서버 (가상 머신, 예: EC2)
서버 관리 AWS가 운영체제, 런타임 등 전적으로 관리 직접 운영체제, 보안, 런타임 등 관리 필요
비용 모델 사용한 만큼 지불 (호출 횟수, 실행 시간) 인스턴스 가동 시간에 따라 고정적으로 지불
확장성 자동 확장, 트래픽에 따라 거의 무한대 직접 설정, 관리 필요, 확장에 시간 소요
유휴 자원 코드가 실행될 때만 자원 사용, 유휴 자원 비용 없음 서버가 켜져 있는 동안 지속적 비용 발생
콜드 스타트 초기 호출 시 발생 가능성 있음 (딜레이) 없음 (항상 켜져 있음)
운영 복잡도 낮음 (인프라 관점에서) 높음 (인프라 관점에서)
최대 실행 시간 15분 (900초)로 제한됨 이론적으로 무제한

비개발자가 헷갈리기 쉬운 부분 & 해결 꿀팁

저처럼 비개발자가 람다를 처음 접할 때 "이게 뭔 소리야?" 했던 부분들과 제가 나름대로 찾아낸 해결법을 공유합니다.

1. "람다 함수만 만들면 알아서 돌아가는 거 아니었나요?" (트리거의 중요성)

헷갈린 지점: 저는 람다 함수만 딱 만들면 뭔가 멋지게 동작할 줄 알았습니다. 그런데 함수를 만들어놓고 보니 '누가 이걸 실행시키지?'라는 의문이 들더군요.

해결 꿀팁: 람다 함수는 독립적인 코드 조각일 뿐입니다. 이 함수를 "언제, 어떤 상황에서" 실행시킬지를 정해주는 것이 바로 '트리거(Trigger)'입니다. 가장 흔하게 쓰이는 트리거는 웹 요청을 받을 때 쓰는 API Gateway, 파일이 S3 버킷에 업로드될 때 쓰는 S3 이벤트, 정해진 시간에 자동으로 실행시키는 CloudWatch Events (EventBridge) 등이 있습니다. 마치 "방아쇠" 같은 거죠. 특정 이벤트가 방아쇠를 당기면 람다 함수가 "빵!" 하고 실행되는 겁니다.

제가 터미널에서 간단하게 람다를 테스트해보는 명령어는 이렇습니다. 실제로 API Gateway 같은 걸 붙여야 외부에서 접근이 가능하지만, 기본적인 테스트는 이 명령어로 가능합니다.

# AWS CLI가 설치되어 있어야 합니다.
# MyFirstLambdaFunction은 위에서 만든 람다 함수의 이름입니다.
# --payload는 람수 함수에 전달할 데이터를 JSON 형태로 넣어주는 겁니다.
# output.txt 파일에 람다 함수의 응답이 저장됩니다.
aws lambda invoke --function-name MyFirstLambdaFunction --payload '{"message": "헬로 람다!"}' output.txt

# 람다 함수의 응답 결과 확인하기
cat output.txt

위 명령어를 터미널에 치고 output.txt를 열어보면, 람다 함수가 반환한 {"statusCode": 200, "body": "루카의 첫 람다! 안녕, 서버리스 세계!"}와 같은 내용이 들어있는 것을 볼 수 있습니다.

2. "메모리랑 타임아웃은 뭘 설정해야 하죠?" (리소스 설정의 감 잡기)

헷갈린 지점: 람다 함수를 만들 때 '메모리(MB)'와 '타임아웃(초)'을 설정해야 하는데, 뭘 기준으로 설정해야 할지 감이 전혀 오지 않았습니다.

해결 꿀팁: 이 두 가지는 람다 함수가 실행될 때 얼마나 많은 자원(메모리)을 사용하고, 최대 몇 초까지 실행될 수 있는지를 정의하는 중요한 설정입니다.

  • 메모리: 128MB부터 10,240MB(10GB)까지 설정할 수 있습니다. 메모리를 높이면 CPU 성능도 함께 올라가서 함수 실행 속도가 빨라지는 경향이 있습니다. 간단한 텍스트 처리나 데이터 조회 같은 작업은 128MB로도 충분할 수 있지만, 이미지/비디오 처리나 복잡한 계산에는 512MB 또는 1GB 이상이 필요할 수 있어요. 저는 처음엔 그냥 128MB로 시작해서, 나중에 성능 문제가 생기면 조금씩 늘려보는 방식으로 접근했습니다.
  • 타임아웃: 함수가 실행될 수 있는 최대 시간을 의미합니다. 기본값은 3초인데, 이 시간 안에 함수가 작업을 마치지 못하면 강제로 중단됩니다. 최대 15분(900초)까지 늘릴 수 있습니다. 제 경우는 간단한 'Hello World'라 3초도 충분했지만, 외부 API를 호출하거나 데이터베이스 작업을 하는 경우엔 여유 있게 10초, 30초 정도로 설정하는 것이 좋다고 합니다.

3. "이벤트 객체가 도대체 뭐예요?" (입력 데이터 이해하기)

헷갈린 지점: 람다 함수의 lambda_handler에 event라는 파라미터가 들어가는데, 이게 뭔지 감이 안 왔습니다.

해결 꿀팁: event는 람다 함수를 트리거한 '이벤트'에 대한 모든 정보가 담겨 있는 '데이터 덩어리'라고 생각하시면 됩니다. 예를 들어: * API Gateway로 웹 요청이 들어왔다면, 요청 헤더, 바디, 쿼리 파라미터 등이 event에 들어있습니다. * S3에 파일이 업로드되어 트리거 됐다면, 어떤 버킷에 어떤 파일이 어떤 이름으로 업로드되었는지 등의 정보가 event에 담겨 람다 함수로 전달됩니다.

처음에는 이 event 객체의 구조가 낯설지만, 각 트리거마다 event 객체의 형식이 거의 정해져 있습니다. AWS 문서에서 '람다 이벤트 객체 형식' 같은 키워드로 검색해보면 각 트리거별로 event가 어떻게 생겼는지 예시가 잘 나와 있어서 몇 번 보다 보면 감이 잡힙니다. 이 event를 분석해서 필요한 정보를 추출하고 그에 따라 함수가 동작하는 것이 람다의 핵심이에요.

실전 적용 꿀팁: 비개발자도 꿈꿀 수 있는 람다 활용 사례

제가 람다를 직접 경험해보고 다른 사람들의 사례를 찾아보니, 비개발자 시선에서도 정말 다양한 곳에 유용하게 쓸 수 있겠다는 생각이 들었습니다.

  • 간단한 웹 API 백엔드: 복잡하지 않은 모바일 앱이나 웹 서비스의 백엔드를 람다와 API Gateway로 구축하면 서버 관리 없이 서비스를 제공할 수 있습니다.
  • 데이터 처리 자동화: S3에 새로운 파일(예: 이미지, 로그 파일)이 업로드될 때마다 람다 함수가 자동으로 실행되어 이미지 크기를 변경하거나, 파일 내용을 분석해서 데이터베이스에 저장하는 등의 작업을 할 수 있습니다.
  • 정기적인 작업 (Cron Job) 대체: 매일 새벽 1시에 특정 데이터를 백업하거나, 주간 보고서를 자동으로 생성하는 등의 작업을 람다와 EventBridge(CloudWatch Events)로 스케줄링할 수 있습니다.
  • 챗봇 백엔드: 카카오톡, 슬랙 등의 챗봇 메시지를 람다 함수로 받아서 처리하고 응답하는 시스템을 만들 수 있습니다.

찾아보니 국내 스타트업 중에는 실시간 데이터 분석, 챗봇 백엔드, 알림 시스템 등에 람다를 활발하게 쓰고 있다고 하더라고요. 저처럼 코딩은 잘 몰라도 아이디어와 호기심만 있다면, 람다를 통해 상상했던 서비스를 실제로 구현해볼 수 있는 시대가 온 거죠!

마무리하며

AWS 람다를 직접 파보고 사용해보면서, '서버리스'라는 기술이 단순히 비용 절감이나 효율성을 넘어, IT 서비스 개발의 패러다임을 바꾸고 있다는 것을 몸소 느꼈습니다. 물론 아직은 개발자들의 전유물처럼 느껴지기도 하지만, 저처럼 비개발자도 충분히 그 개념과 활용법을 이해하고 작은 시도부터 해볼 수 있는 문이 열렸다는 점이 가장 인상 깊었습니다.

코딩을 몰라도 IT 트렌드를 놓치고 싶지 않다면, AWS 람다와 서버리스 아키텍처는 꼭 한 번쯤 들여다볼 가치가 있는 분야라고 생각합니다. 저처럼 비개발자도 충분히 이해할 수 있으니, 여러분도 겁내지 말고 한번 도전해 보시길 바랍니다!

핵심 요약 (3줄)

  • AWS 람다는 서버 관리 부담 없이 코드를 실행할 수 있는 혁신적인 서버리스 서비스입니다.
  • 사용한 만큼만 비용을 지불하고 자동으로 확장되어 효율성과 비용 절감 효과가 뛰어납니다.
  • 비개발자도 기본적인 개념과 활용법을 익히면 IT 서비스 이해도를 크게 높일 수 있습니다.

질문 형식 (FAQ)

람다는 어떤 프로그래밍 언어를 지원하나요?

람다는 Python, Node.js, Java, C#, Go, Ruby, PowerShell 등 다양한 프로그래밍 언어를 지원하며, 사용자 정의 런타임을 통해 다른 언어도 사용할 수 있습니다.

람다 함수는 얼마나 오랫동안 실행될 수 있나요?

람다 함수의 최대 실행 시간은 15분(900초)으로 제한되어 있습니다. 그 이상 걸리는 작업에는 적합하지 않습니다.

람다를 사용하면 항상 비용이 절감되나요?

대부분의 경우 비용 절감 효과가 크지만, 함수 호출 빈도가 매우 높고 각 실행 시간이 길며 메모리를 많이 사용하는 고성능 작업이라면, 전통적인 서버를 사용하는 것이 더 저렴하거나 예측 가능한 비용을 가질 수 있습니다. 적절한 비용 최적화와 모니터링이 필요합니다.