이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트를 학교 서버가 아닌 실제 서버에 올려보고 싶어서 처음으로 클라우드 배포를 시도했습니다. 자료를 찾아보면서 EC2와 S3를 처음 사용해 보았습니다.
EC2에 서버를 올리고 S3에 정적 파일을 저장하는 구조로 배포하였습니다. 처음에는 보안 그룹 설정을 잘못하여 외부에서 접속이 아예 되지 않았으나, 포트 설정과 인바운드 규칙 개념을 이해하고 나서 해결되었습니다.
그 경험에서 클라우드 서비스가 편리하지만 설정이 잘못되면 오히려 더 복잡해진다는 것을 배웠습니다. 특히 보안 관련 설정은 기본값을 믿으면 안 된다는 것을 처음 알게 되었습니다. 이후로는 새 서비스를 사용할 때 공식 문서의 보안 관련 항목을 먼저 읽는 습관이 생겼습니다. 그 실패가 클라우드 설정을 꼼꼼히 보는 습관을 만들어주었습니다.
개인 프로젝트를 클라우드에 올리고 한 달 후에 예상보다 3배 이상 청구가 나와서 깜짝 놀랐어요. 뭐가 비용을 올리는지 몰랐습니다.
청구 대시보드를 뜯어보니 데이터 전송 비용과 EC2 인스턴스가 하루 종일 켜진 것이 주요 원인이었어요. 트래픽이 없는 밤에는 인스턴스를 꺼두도록 스케줄링하고, 불필요한 데이터 전송을 줄이는 설정을 바꿨습니다. 다음 달 청구는 처음과 비슷한 수준으로 돌아왔어요.
그 경험에서 클라우드는 쓴 만큼 나오지만 '얼마나 쓰는지'를 모르면 낭비가 생긴다는 것을 배웠어요. 서비스 구조를 짤 때 비용을 함께 생각해야 한다는 걸 처음 느꼈습니다. 지금은 새 기능을 추가할 때 예상 비용을 같이 확인하는 습관이 생겼어요. 그 경험이 클라우드를 비용 관점으로도 보게 해줬습니다.
개인 프로젝트에서 이미지 업로드 시 썸네일을 자동 생성해야 했는데, 이 기능만을 위해 서버를 계속 켜두는 건 낭비라는 생각이 들었어요.
Lambda 함수로 S3에 파일이 올라올 때마다 자동으로 썸네일을 생성하는 트리거를 만들었어요. 처음엔 Lambda의 실행 시간 제한을 모르고 큰 파일을 처리하려다 타임아웃이 났는데, 파일 크기 제한을 추가하고 나서 안정됐습니다.
서버를 상시 켜두지 않아도 되니 비용이 거의 없었고, 트래픽이 늘어도 알아서 스케일이 맞춰지는 구조였어요. '항상 켜야 하는 것'과 '필요할 때만 켜도 되는 것'을 구분하는 설계가 중요하다는 걸 그 경험에서 배웠습니다. 직접 써보고 나서 서버리스 방식이 언제 유용한지 감이 생겼어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올웨이즈 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.