서버리스가 도통 이해되지 않던 시절을 떠올리며 이것저것 질문해 봤다.

서버가 사라졌다? 마법사의 정체

🧙‍♂️(박사) 「🐣야, 오늘은 서버리스에 대해 배우자. 이름만 들으면 ‘서버가 사라지는 마법’처럼 느껴지겠지만 실제로는 더 소박하면서도 깊이가 있다.」

🐣(학생) 「서버가 없다구요? 박사님이 해리포터처럼 ‘서버야, 사라져라!’라고 외치면 진짜 사라지는 건가요?」

🧙‍♂️(박사) 「하하, 대부분이 처음에 그렇게 생각한다. 하지만 실제로는 ‘서버가 없다’는 뜻이 아니다. 클라우드 뒤편에서 서버는 열심히 일한다. 다만 이용자는 그 존재를 의식하지 않아도 된다는 의미다.」

🐣(학생) 「에이, 그럼 사기 아닌가요? ‘무농약 채소’라고 해 놓고 몰래 농약 잔뜩 뿌린 것 같은데요.」

🧙‍♂️(박사) 「비유가 묘하지만 꽤 정확하다. ‘서버리스’의 ‘리스’는 ‘관리 없음(management-less)’이라는 뜻이다. 예전에는 서버를 직접 들여놓고 OS를 깔고 장애를 처리해야 했지. 말 그대로 햄스터를 키우는 것처럼 돌봤어야 했다. 서버리스에서는 클라우드 사업자가 이런 관리를 대신 맡아 준다.」

🐣(학생) 「햄스터는 죽으면 울지만, 서버는 죽으면 고객이 화내죠. 더 괴로운데요.」

🧙‍♂️(박사) 「게다가 햄스터는 새벽 3시에 ‘DB가 응답하지 않는다’라고 깨우지 않는다. 서버는 그런다.」

📌 주석: 서버리스의 기본 개념 서버리스(Serverless)는 ‘서버가 없다’가 아니라 ‘서버 관리를 클라우드 사업자가 대신하는’ 아키텍처다.

  • 기존 방식: 서버를 직접 구매·설치·관리
  • 서버리스: 클라우드 사업자가 인프라를 관리하고, 이용자는 코드에 집중

서버리스의 구조: 불릴 때만 등장하는 닌자

🐣(학생) 「사용법이 어려울 것 같은데요. 보통 서버랑 뭐가 달라요?」

🧙‍♂️(박사) 「맞다. 서버리스는 호출될 때만 ‘퐁!’ 하고 올라와 처리하고 바로 사라진다. 그래서 애플리케이션은 ‘단거리 주자’처럼 설계해야 한다. 마라톤 선수 스타일은 어울리지 않는다.」

🐣(학생) 「그러니까 ‘지금 당장 계산해!’라고 하면 등장하고, ‘끝났어’라고 하면 사라진다는 거군요?」

🧙‍♂️(박사) 「그렇지! 부르면 나타나는 닌자 같다. 평소에는 숨어 있으니, 아무 것도 하지 않는 시간의 임대료를 낼 필요가 없다.」

🐣(학생) 「근데 닌자는 매번 다른 곳에서 나타나잖아요. IP 주소 같은 건 어떻게 돼요?」

🧙‍♂️(박사) 「좋은 지적이다! 고정 주소가 없다. 매번 서버가 바뀌기 때문에 클라우드가 제공하는 API 게이트웨이가 ‘닌자 마을의 문지기’ 역할을 한다. 외부 요청을 적절한 닌자에게 전달하는 거다.」

🐣(학생) 「그렇다는 건, 닌자가 매번 다르면 지난번 일은 기억 못하겠네요?」

🧙‍♂️(박사) 「맞다. 그래서 ‘상태(State) 없는 설계’가 필수다. ‘어제 이어서…’ 같은 대화는 불가능하고, 매번 ‘처음 뵙겠습니다’로 시작하는 금붕어 기억력이라고 보면 된다.」

🐣(학생) 「불편한데요? 로그인이나 세션 관리는요?」

🧙‍♂️(박사) 「외부 데이터베이스나 Redis 같은 곳에 상태를 저장한다. 즉 닌자는 기억이 없어도 ‘두루마리 창고’에 중요한 정보를 맡겨 두는 셈이지.」

📌 주석: 상태 없는 설계의 중요성 서버리스 함수는 실행 때마다 새로운 컨테이너에서 기동하기 때문에 로컬 상태(변수, 파일, 세션)를 유지하지 않는다.

  • 상태 관리는 외부 DB, Redis, S3 등을 활용
  • 세션은 JWT 토큰이나 외부 스토리지에 저장
  • 파일은 임시 처리 외에는 외부 스토리지를 사용

기존 서버와의 차이: 애완동물 vs 닌자

🐣(학생) 「실제로는 어떤 느낌인가요?」

🧙‍♂️(박사) 「‘이미지 업로드 시 썸네일 생성’ 처리를 생각해 보자. 기존에는 24시간 서버가 ‘아무나 오나~’ 하며 대기한다. 전기 요금도 나오고, 장애로 멈추기도 한다.」

🐣(학생) 「문 앞에서 ‘손님 올까~’ 하며 서 있는 문지기 같네요.」

🧙‍♂️(박사) 「그렇다! 게다가 그 문지기는 감기라도 걸리면 쓰러진다. 서버리스에서는 ‘이미지 업로드!’라는 벨이 울리는 순간 닌자가 나타나서 썸네일 만들고 사라진다.」

🐣(학생) 「그거 괜찮네요. 근데 닌자가 나타나기까지 시간이 걸리지 않나요?」

🧙‍♂️(박사) 「그게 바로 콜드 스타트(Cold Start) 문제다. 닌자가 자고 있는 상태에서 깨워 준비시키려면 몇 초 걸린다. 특히 Java처럼 무거운 언어면 ‘잠에서 깨서 요가 매트와 아침 식사 준비’ 정도의 시간이 필요하다.」

🐣(학생) 「짜증 나겠네요. 실시간 처리에는 안 어울리겠어요.」

🧙‍♂️(박사) 「워밍업 기능도 있지만 기본적으로는 배치나 비동기 처리가 특기다. ‘지금 당장 응답해!’ 같은 요청은 약점이다.」

구체적 예시: 사진 공유 앱이라면

🐣(학생) 「예를 하나 들어 주세요. 사진 공유 앱을 만든다고 치면요?」

🧙‍♂️(박사) 「좋다. 기존 방식은 이렇다.」

기존 서버 방식:

24시간 가동 Web 서버 (월 5,000엔)
↓
"사진이 업로드되었습니다"
↓
서버 내부에서 썸네일 생성
↓
데이터베이스 저장

🧙‍♂️(박사) 「이 방식은 아무도 사진을 올리지 않는 달에도 5,000엔을 계속 낸다. 손님 없는 가게라도 월세를 내는 것과 같다.」

🐣(학생) 「비효율적이네요.」

🧙‍♂️(박사) 「서버리스 버전은 이렇다.」

서버리스 버전:

이미지가 S3에 업로드
↓
S3 이벤트가 Lambda 함수를 트리거
↓
Lambda 함수 기동 (0.1초)
↓
썸네일을 다른 S3 버킷에 저장
↓
Lambda 함수 종료
↓
과금: 실행 시간만 (1회 약 0.001엔)

🐣(학생) 「그럼 아무도 쓰지 않으면 공짜네요?」

🧙‍♂️(박사) 「그렇다! ‘사용한 만큼만’ 낸다. 다만 ‘대박’ 나면 청구도 대박이 된다. 바이럴 영상이 올라와서 백만 번 실행되면…」

🐣(학생) 「천 엔이네요!」

🧙‍♂️(박사) 「계산은 맞지만 실제로는 전송료, API Gateway 요금, 데이터베이스 요금이 붙는다. 정신 차리고 보면 수십만 엔이 될 수도 있다. ‘바이럴 덕분에 유명해졌지만 파산했다’는 현대판 비극이다.」

📌 주석: 종량 과금의 장점과 리스크

장점

  • 초기 비용 거의 0
  • 사용량에 따라 자동으로 스케일
  • 인프라 관리 불필요

리스크

  • 예상치 못한 고액 청구 (특히 바이럴 시)
  • 복잡한 요금 체계
  • 여러 서비스를 조합할 때 비용이 보이지 않음

대응

  • 청구 알림 설정
  • 레이트 리미트(rate limit) 구현
  • 사전 부하 테스트와 요금 추정

서버리스의 종류: 닌자의 전문 분야

🐣(학생) 「서버리스에도 종류가 많다던데요?」

🧙‍♂️(박사) 「주로 세 가지 흐름이 있다. FaaS(Function as a Service), BaaS(Backend as a Service), 서버리스 컨테이너다.」

🐣(학생) 「FaaS는 뭐죠?」

🧙‍♂️(박사) 「‘함수만 맡아 줍니다’라는 서비스다. AWS Lambda, Google Cloud Functions, Azure Functions 등이 있다. 우리가 작성한 함수를 맡기면 ‘불릴 때만 실행하고 요금은 종량제’라는 회전초밥집 같은 모델이다.」

🐣(학생) 「BaaS는요?」

🧙‍♂️(박사) 「‘데이터베이스도 인증도 푸시도 다 해 드립니다’라는 풀코스 서비스다. Firebase, Supabase, AWS Amplify 등이 있다. ‘엄마가 다 챙겨 주는 본가 생활’ 같지.」

🐣(학생) 「본가 살면 편하지만 부모님 말을 들어야 하죠.」

🧙‍♂️(박사) 「그게 바로 베ンダ 락인(Vendor lock-in) 위험이다. 어느새 ‘이 서비스 없이는 못 사는 몸’이 될 수 있다.」

서버리스가 잘하는 일과 서툰 일

🐣(학생) 「그렇다면 열심히 몸으로 때우면 되지 않나요? 굳이 서버리스를 써야 하나요?」

🧙‍♂️(박사) 「이유는 속도다. 떠오른 아이디어를 즉시 공개할 수 있고, 사용자가 적을 때는 거의 제로 비용이다. ‘어젯밤 생각난 서비스를 다음 날 아침에 공개’ 같은 짓이 가능하다.」

🐣(학생) 「모든 처리에 다 맞지는 않겠죠?」

🧙‍♂️(박사) 「그렇다. 장단점이 분명하다.」

잘하는 일:

  • 이미지 처리 (업로드 → 썸네일)
  • 데이터 변환 (CSV ↔ JSON)
  • 알림 전송 (메일, 푸시)
  • 정기 배치 (일일 리포트)
  • 가벼운 API 처리 (사용자 조회 등)

서툰 일:

  • 실시간 처리 (채팅, 게임)
  • 장시간 처리 (영상 인코딩, 머신러닝)
  • 복잡한 상태 관리가 필요한 애플리케이션
  • 레거시 시스템과 강하게 얽힌 구성

🐣(학생) 「즉 ‘스프린트는 잘하지만 마라톤은 약한 선수’네요.」

🧙‍♂️(박사) 「정확하다. 100m는 빠르지만 풀코스는 힘든 선수다.」

청구의 함정: 닌자의 시급제

🐣(학생) 「체력 좋은 사람은 쓸 필요 없고, 잘못 쓰면 청구서 맞고… 머리를 써야 이득인 건가요?」

🧙‍♂️(박사) 「정확하다! 서버리스는 ‘머리를 쓰면 이득, 방심하면 폭사’하는 특성이 있다. 과금 구조를 이해하지 못하면 지옥을 본다.」

🐣(학생) 「어떤 지옥이요?」

🧙‍♂️(박사) 「예를 들어 무한 루프에 빠지는 코드를 생각해 보자. 기존 서버라면 ‘서버가 버벅인다’로 끝났겠지만, 서버리스는 ‘새로운 닌자가 무한히 소환되는’ 사태가 된다.」

🐣(학생) 「닌자 부대가 계속 일하면서 시급을 청구하는 거네요? 공포영화 같은데요.」

🧙‍♂️(박사) 「그리고 그 사실은 월말 청구서에서 확인한다. ‘왜 100만 엔?’이라는 악몽이 펼쳐진다. 실제로 AWS에서 수백만 엔 청구된 사례가 널렸다.」

🐣(학생) 「끔찍하네요. 대책은요?」

🧙‍♂️(박사) 「물론 있다. 과금 알람, 실행 시간 제한, 동시 실행 수 제한을 설정한다. ‘닌자 고용 계약서’를 꼼꼼히 써 두는 셈이다.」

실제 실패 사례: 바이럴의 공포

🐣(학생) 「실제로 큰 청구 폭탄 맞은 사례 있어요?」

🧙‍♂️(박사) 「엄청 많다. 대표적인 게 ‘사진 미화 앱이 바이럴되고 월 300만 엔 청구’ 사건이다.」

🐣(학생) 「헉… 자세히 들려주세요.」

🧙‍♂️(박사) 「어느 스타트업이 ‘AI로 사진을 예쁘게 만드는 앱’을 만들었다. 1장 처리에 0.1엔 정도로 예상했지.」

🐣(학생) 「그런데요?」

🧙‍♂️(박사) 「SNS에서 폭발적으로 퍼져 하루에 100만 장이 업로드됐다. 게다가 한 장 처리 시간이 길어 실제로는 ‘장당 3엔’이 나왔다.」

🐣(학생) 「100만 × 3엔 = 300만 엔…」

🧙‍♂️(박사) 「그리고 그게 30일 지속됐다. ‘성공했지만 회사가 망했다’는 현대판 비극이다.」

🐣(학생) 「대책은?」

🧙‍♂️(박사) 「과금 제한을 걸지 않았다. ‘설마 그렇게 바이럴될까’라는 안일함 때문이다. 지금은 ‘성공의 상한’을 설정하는 게 상식이 됐다.」

🐣(학생) 「성공 상한이라니, 아이러니하네요.」

🧙‍♂️(박사) 「‘기쁜 비명’이 진짜 비명으로 바뀌는 시대다.」

개발 경험의 변화: 마법 같은 쾌감과 제약의 고통

🐣(학생) 「개발할 때는 어떤가요? 일반 프로그램과 달라요?」

🧙‍♂️(박사) 「처음에는 즐겁다. ‘함수를 쓰고 툭 배포하면’ 바로 전 세계에 공개된다. 마치 마법사가 된 기분이지.」

🐣(학생) 「그건 확실히 재미있겠네요.」

🧙‍♂️(박사) 「하지만 익숙해질수록 현실이 보인다. 로컬 테스트가 어렵고, 디버깅도 번거롭다. ‘왜 안 돼?’라고 해도 닌자는 이미 사라졌으니 로그를 쫓을 수밖에 없다.」

🐣(학생) 「현장에 남은 단서만 보고 수사하는 탐정이 되는 건가요?」

🧙‍♂️(박사) 「정확하다. 게다가 그 로그가 여러 서비스에 흩어져 있다. CloudWatch, X-Ray, CloudTrail 등에서 탐정 놀이를 해야 한다.」

🐣(학생) 「귀찮네요. 그냥 서버 세우는 게 낫지 않을까요?」

🧙‍♂️(박사) 「그게 바로 ‘서버리스의 함정’이다. 처음엔 마법처럼 쉽고, 중반에는 저주처럼 복잡해진다. 하지만 한 번 익숙해지면 예전처럼 ‘서버 돌보기’로 돌아가고 싶지 않게 된다.」

🐣(학생) 「중독성이 있다는 뜻이군요?」

🧙‍♂️(박사) 「맞다. ‘서버 걱정을 안 해도 되는 쾌감’은 일종의 마약이다. 대신 ‘과금 걱정’과 ‘설계 제약’이라는 스트레스를 지게 된다.」

서버리스 vs 기존 방식: 비용 비교의 현실

🐣(학생) 「결국 비용 면에서는 어떤가요?」

🧙‍♂️(박사) 「복잡하다. 사용량과 예측 가능성에 따라 천차만별이다. 그래프로 생각해 보자.」

기존 서버

  • 고정비: 월 5만 엔
  • 변동비: 거의 없음
  • ‘정식 식당’ 모델

서버리스

  • 고정비: 거의 없음
  • 변동비: 사용량에 따라 결정
  • ‘회전초밥’ 모델

🐣(학생) 「얼마나 먹느냐에 따라 다른 거네요.」

🧙‍♂️(박사) 「그렇다! 소식이면 회전초밥이 이득이고, 대식이면 정식집이 낫다. 예를 들면,」

  • 월간 요청 100만 회 이하: 서버리스가 월등히 저렴
  • 월간 요청 1,000만 회 이상: 기존 서버가 저렴
  • 그 사이: 상황 봐가며 결정 (운영 비용 포함)

🐣(학생) 「예측이 틀리면요?」

🧙‍♂️(박사) 「그게 도박 요소다. ‘다음 달 수요’ 예측을 틀리면 ‘정식집에서 대식하려다 입맛 없어서 손해’, 혹은 ‘회전초밥에서 가볍게 먹으려다 폭식’ 같은 일이 생긴다.」

서버리스는 성공할까?

🐣(학생) 「그럼 서버리스는 성공하는 건가요, 실패하나요?」

🧙‍♂️(박사) 「완전 승리도, 완전 패배도 없을 것이다. 기존 방식, 컨테이너, 서버리스가 각자 강점을 살리며 공존한다. ‘닌자도 기사도 마법사도 모두 필요한’ 세상이 된다.」

🐣(학생) 「결국 어떤 기술도 만능은 아니네요.」

🧙‍♂️(박사) 「그렇다. ‘은탄환(silver bullet)’은 존재하지 않는다. 다만 적절한 장면에서 쓰면 매우 강력한 도구인 것은 틀림없다.」

🐣(학생) 「그럼 어떤 사람에게 추천할 수 있나요?」

🧙‍♂️(박사) 「이런 사람들이다.」

서버리스에 어울리는 사람

  • ‘우선 돌아가는 걸 빨리 만들고 싶다’는 타입
  • 과금 구조를 이해할 계산력이 있는 사람
  • ‘완전 제어보다 편한 관리를 택한다’는 성향
  • 새 기술에 설레는 사람

서버리스에 어울리지 않는 사람

  • ‘모든 걸 직접 관리하고 싶다’는 장인형
  • 예산 관리가 서툰 사람
  • ‘안정 운용’을 최우선으로 여기는 사람
  • 레거시 시스템에서 벗어날 수 없는 사람

🐣(학생) 「‘새 것을 좋아하는 알뜰가’라는 표현이 떠오르네요.」

🧙‍♂️(박사) 「좋은 표현이다. ‘혁신과 절약’을 동시에 원하는 기술이다.」

맺음말: 서버리스라는 삶의 방식

🐣(학생) 「결국 박사님은 서버리스를 추천하나요?」

🧙‍♂️(박사) 「‘추천한다’라고 말하기는 어렵다. 다만 ‘제대로 이해하고 써라’라고는 말한다. 서버리스는 ‘편리함의 유혹’과 ‘리스크의 현실’을 저울질하며 쓰는 현대의 주문이다.」

🐣(학생) 「주문이라… 잘못 쓰면 자신한테 돌아오는 거잖아요.」

🧙‍♂️(박사) 「맞다. 그래서 ‘올바른 주문법’을 배워야 한다. 서버리스는 ‘머리를 쓰면 이득, 방심하면 폭사’한다. 체력으로 버티는 타입에게는 맞지 않지만, 영리하게 쓰면 강력한 무기가 된다.」

🐣(학생) 「정리하면,」

  • 서버 운영: 근성으로 버티는 지옥 훈련
  • 서버리스: 머리로 제어하는 청구 생존전 「맞나요?」

🧙‍♂️(박사) 「완벽한 요약이다. 무엇을 선택할지는 상황에 따라 다르다. 다만 ‘아무 것도 선택하지 않는’ 선택지는 없다. 현대 엔지니어는 ‘기사냐 닌자냐 마법사냐’를 선택해야 하는 시대다.」

🐣(학생) 「알겠습니다. 일단 기본기부터, 닌자는 그다음이군요.」

🧙‍♂️(박사) 「그 마음가짐이면 훌륭한 ‘닌자 조련사’가 될 것이다. 단, 청구서에는 항상 신경 써라.」

🐣(학생) 「네! 과금 알람은 반드시 설정할게요!」

📌 최종 주석: 서버리스 도입 판단 프레임워크

서버리스를 채택할지 여부는 다음 요소를 종합적으로 판단한다.

기술적 요인

  • 처리 특성 (배치 vs 실시간)
  • 실행 빈도 (저빈도 vs 고빈도)
  • 상태 관리 필요성
  • 레거시 시스템과의 연계

비즈니스 요인

  • 초기 투자 예산
  • 운영 팀의 역량
  • 성장 예측의 확실성
  • 베ンダ 락인 허용 범위

결론: 서버리스는 ‘만능 해결책’이 아니라 ‘특정 상황에서 위력을 발휘하는 전문 기술’이다. 올바른 이해와 준비가 있다면 강력한 무기가 되지만, 성급한 도입은 고액 청구라는 대가를 부를 수 있다.

현대 엔지니어에게 서버리스는 ‘알아 두어야 할 선택지’이자 ‘적재적소에 써야 하는 기술’이다.