이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 클라우드 서버 비용이 한 달에 예산의 두 배가 나왔는데, 아무도 그 이유를 알지 못했습니다. 각자 '내가 많이 쓰지는 않는다'고 생각했던 것입니다.
클라우드 대시보드에서 서비스별 비용 내역을 분석해보니 개발용 인스턴스 두 대가 주말에도 계속 켜져 있었습니다. 아무도 끄지 않았던 것이었는데, 개발 인스턴스는 업무 시간 외 자동 중지 스케줄을 설정하니 다음 달 비용이 40% 줄었습니다. 간단한 설정 하나가 꽤 큰 차이를 만들어서 놀랐습니다.
인프라 최적화가 복잡한 기술보다 '지금 무엇을 쓰고 있는지 아는 것'에서 시작한다는 것을 배웠습니다. 보이지 않으면 최적화할 수 없고, 가시화가 먼저라는 것도 깨달았습니다. 그 경험이 인프라 비용을 주기적으로 확인하는 습관을 만들어주었습니다.
개인 프로젝트 운영 중에 몇 달 전에 테스트하고 그냥 둔 스토리지와 인스턴스가 계속 비용을 내고 있다는 걸 늦게 알아챘어요. 적은 금액이었지만 쌓이면 크더라고요.
한 달에 한 번 '사용 중인가'를 기준으로 리소스를 점검하는 루틴을 만들었어요. 마지막 접근 시간이 30일 이상인 리소스는 일단 스냅샷 찍고 삭제하는 방식이었습니다. 처음엔 삭제가 두려워서 스냅샷 없이 못 지웠는데, 백업이 있으면 지워도 된다는 걸 경험하면서 과감해졌어요.
그 이후로 월 비용이 꾸준히 줄었고, 만들고 쓰지 않는 것들이 얼마나 많은지를 보면서 처음부터 '이게 필요한가'를 물어보는 습관이 생겼어요. 최적화는 만드는 것보다 정리하는 것이 더 중요할 때가 많다는 걸 배웠습니다. 그 경험이 리소스를 대하는 방식을 바꿔줬어요.
프로젝트 초반에 '혹시 모르니까'라는 이유로 큰 인스턴스를 선택했는데, 한 달 지나서 보니 CPU 사용률이 평균 5%도 안 됐어요.
실제 사용 지표를 보고 한 단계 낮은 인스턴스로 다운사이징했어요. 처음엔 '작으면 느릴까봐' 걱정됐는데, 2주 운영해보니 응답시간에 차이가 없었습니다. 비용은 절반으로 줄었고, 오히려 불필요한 여유 자원을 갖고 있었다는 걸 알았어요.
그 경험에서 인프라 사이징은 '쓸 것 같으니까'가 아니라 '실제 쓴 것'을 기반으로 해야 한다는 걸 배웠어요. 처음에 크게 잡고 줄이는 게, 처음부터 딱 맞게 예상하는 것보다 현실적이라는 것도요. 그 경험이 인프라 결정에서 데이터를 먼저 보는 습관을 만들어줬습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.