1인 개발자를 위한 AWS Lambda 콜드스타트 Python 3.12 vs Node.js 20 실측 비교

서버리스로 사이드 프로젝트를 돌리는 1인 개발자라면 한 번쯤 이 화면을 봤을 거예요. API 응답이 첫 호출에서 3초씩 걸리는데, 두 번째부터는 멀쩡한 그 상황. 콜드스타트 문제예요. 그런데 Python을 쓰느냐, Node.js를 쓰느냐에 따라 이 대기 시간이 실제로 얼마나 달라질까요?

핵심 요약

• Python 3.12는 128MB 메모리 설정 기준 평균 콜드스타트 약 800-1,200ms인 반면, Node.js 20은 같은 조건에서 400-700ms를 기록해 약 절반 수준이에요.
• 의존성 패키지 용량이 콜드스타트 시간에 직접 영향을 미치며, 특히 numpy·pandas를 쓰는 Python 함수는 초기화 시간이 2초를 넘기는 경우도 있어요.
• Node.js 20은 2025년 4월 이후 EOL(지원 종료) 경고가 시작됐고, AWS는 Node.js 22로의 전환을 공식 권고하고 있어요.
• 1인 개발자 관점에서 순수 응답 속도가 우선이면 Node.js, 데이터 처리나 ML 연동이 필요하면 Python이 여전히 현실적인 선택이에요.
• 프로비저닝된 동시성(Provisioned Concurrency)을 쓰면 두 런타임 모두 콜드스타트를 거의 제거할 수 있지만, 비용이 약 3-5배 늘어요.

2026년에 이 비교가 다시 중요해진 이유

서버리스는 1인 개발자한테 천국 같은 아키텍처예요. 서버 관리 없이, 트래픽이 없으면 비용도 거의 없으니까요. 그런데 바로 그 이점 때문에 콜드스타트가 더 아프게 느껴지죠. 쓰지 않던 함수가 갑자기 호출될 때 런타임이 처음부터 초기화되는 시간, 그게 콜드스타트예요.

2025년 말부터 상황이 바뀌었어요. AWS가 Node.js 20 EOL 전환을 본격적으로 알리기 시작했거든요. CloudQuery 블로그에 따르면 Node.js 20은 2025년 4월부터 유지보수 모드에 진입했고, AWS Lambda에서도 Node.js 22로의 마이그레이션을 권고하고 있어요. 그러면서 많은 1인 개발자들이 다시 질문을 던지고 있어요. “그냥 Python 3.12로 갈까?”

Python 쪽도 변화가 있었어요. Python 3.12는 이전 버전 대비 인터프리터 성능이 약 10-15% 향상됐고(CPython 공식 벤치마크 기준), AWS Lambda에서의 초기화 속도도 일부 개선됐어요. 지금이 비교 타이밍으로 딱 맞는 거예요.

1인 개발자가 특히 신경 써야 하는 이유는 따로 있어요. 엔터프라이즈 팀이라면 프로비저닝된 동시성을 기본으로 깔고 가지만, 1인 개발자는 비용 때문에 기본 설정으로 쓰는 경우가 대부분이에요. 그 조건에서 런타임 선택이 사용자 경험에 직접 닿는 거죠.

실측 수치로 보는 콜드스타트 차이

기본 함수 환경에서의 격차

의존성 패키지가 거의 없는 단순 Lambda 함수 기준으로, 커뮤니티에서 공유된 실측 데이터(2025년 하반기 기준, AWS ap-northeast-2 리전)를 보면 패턴이 꽤 뚜렷해요.

워밍업된 함수에서는 두 런타임 성능 차이가 거의 없어요. 콜드스타트에서만 벌어지는 격차예요.

무거운 의존성을 달면 어떻게 되나

실제로 차이가 크게 벌어지는 건 여기서부터예요.

Python에서 numpy, pandas, boto3를 함께 올리면 의존성 압축 파일이 40-80MB를 쉽게 넘어요. 이 경우 콜드스타트가 2,000-3,500ms까지 늘어나는 걸 개발자들이 경험적으로 보고하고 있어요. 반면 Node.js에서 aws-sdk v3 + lodash 정도면 패키지가 10-20MB 선에서 유지되고, 콜드스타트 증가폭도 훨씬 작아요.

Lambda Layer를 써서 의존성을 분리하면 어느 정도 완화되지만, Python의 패키지 크기 자체가 Node.js보다 무거운 경향이 있어서 근본적인 차이를 없애진 못해요.

Node.js 20의 딜레마

그런데 속도가 빠른 Node.js 20에 함정이 하나 있어요. AWS가 Node.js 22 전환을 권고하고 있는 상황이에요. 지금 Node.js 20으로 새 프로젝트를 시작하면 조만간 런타임 업그레이드 작업이 생기는 거예요. Node.js 22는 아직 Lambda에서 완전히 자리 잡히는 중이고, 일부 서드파티 라이브러리 호환성 이슈가 간헐적으로 보고되고 있어요.

반면 Python 3.12는 2025-2026년 기준 안정성 측면에서 가장 탄탄한 위치에 있어요.

Python vs Node.js: 어떤 상황에 어떤 걸 선택하나

Python 3.12 선택이 맞을 때:

• 데이터 처리, ML 모델 추론, pandas/numpy 연산이 필요한 함수
• OpenAI API나 HuggingFace 연동이 포함된 백엔드
• Python에 더 익숙한 경우 (개발 속도가 런타임 성능보다 중요한 1인 개발자)
• 콜드스타트가 크게 중요하지 않은 배치 처리 작업

Node.js 20/22 선택이 맞을 때:

• REST API, GraphQL 엔드포인트처럼 응답 속도가 사용자 경험에 직결되는 경우
• 프론트엔드가 TypeScript/JavaScript인 풀스택 개발자 (코드 공유 가능)
• 의존성을 최소화한 가벼운 함수
• JS/TS 에코시스템이 계속 성장하는 추세라 장기적으로도 선택지가 넓어요

절충안 — 프로비저닝된 동시성:

트래픽 패턴이 예측 가능하다면 AWS Provisioned Concurrency를 켜면 두 런타임 모두 콜드스타트를 사실상 제거할 수 있어요. 다만 비용이 기본 Lambda 대비 약 3-5배 올라가기 때문에, 월 활성 사용자가 어느 정도 있는 서비스가 아니면 1인 개발자 입장에서 부담스러울 수 있어요.

지금 당장 해볼 것들

콜드스타트를 줄이는 방법은 런타임 교체 말고도 몇 가지가 있어요.

단기 실천 (지금 바로):

• 메모리 늘리기: 128MB → 512MB로만 바꿔도 콜드스타트가 20-30% 줄어요. CPU도 같이 올라가거든요. 비용 증가폭은 생각보다 작아요.
• 패키지 다이어트: Python이라면 pip install --no-deps로 불필요한 의존성 체인 끊기, Node.js라면 aws-sdk v3의 개별 패키지 방식(@aws-sdk/client-s3만 import) 쓰기
• 핸들러 밖에서 초기화: DB 연결, SDK 클라이언트 초기화는 핸들러 함수 바깥에 두면 워밍업 함수 재사용 시 이 코드를 건너뛰어요

Node.js 20 사용 중이라면: Node.js 22로의 전환 계획을 세워두는 게 좋아요. 대부분의 마이그레이션은 package.json에서 런타임만 바꾸고 의존성 호환성만 확인하면 끝나는 수준이에요. 지금 당장은 아니어도 2026년 안에 해두는 편이 안전해요.

결론: 속도냐, 생산성이냐

요약하면 이렇게 돼요.

• 순수 콜드스타트 성능: Node.js가 약 두 배 빠름
• 무거운 데이터 처리: Python 3.12가 에코시스템 면에서 압도적
• 장기 안정성 (2026년 현재): Python 3.12가 우위, Node.js는 22 전환 필요
• 의존성 최소화 시: 두 런타임 차이가 크지 않음

1인 개발자한테 런타임 선택은 사실 기술 문제라기보다 생산성 문제에 가까워요. 본인이 더 빠르게 개발할 수 있는 언어, 더 익숙한 에코시스템이 종종 콜드스타트 200ms 차이보다 더 중요하거든요.

그리고 하나만 더 생각해보세요. 지금 만들고 있는 Lambda 함수 중에서, 콜드스타트가 진짜로 사용자 불만으로 이어지는 게 몇 개나 되나요? 그 함수들만 골라서 런타임이나 메모리를 조정해도 충분할 수 있어요. 전체를 갈아엎기 전에, 병목이 어디인지 먼저 AWS Lambda의 CloudWatch 지표로 확인해보는 걸 추천해요.

AWS Lambda 런타임 공식 문서 및 Node.js EOL 정보는 AWS Lambda 런타임 지원 정책에서 확인할 수 있어요.

참고자료

1. AWS Lambda Node.js 20 EOL: Upgrade to Node.js 22 | CloudQuery Blog
2. [AWS] 초보자를 위한 Lambda 배포 가이드: 콘솔 vs 테라폼 (macOS 기준)
3. 2025 프로그래밍 언어 순위 2위 TypeScript, 그렇다면 1위는? I 이랜서 블로그

Photo by Christian Palazzolo on Unsplash