이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
비용 최적화 경험은 클라우드 프로젝트에서 있었습니다. EC2 인스턴스를 상시 켜두다가 월말에 예상보다 두 배 가까운 비용이 나온 것이 출발점이었습니다. 먼저 Cost Explorer로 서비스별 비용을 분석하니 개발 환경용 인스턴스가 야간·주말에도 돌고 있었습니다. 이를 스케줄 기반 자동 정지로 바꾸고 개발 환경은 Lambda와 서버리스로 전환했더니 해당 구간 비용이 60% 이상 줄었습니다. 비용 최적화는 무조건 줄이는 게 아니라 쓰지 않을 때 안 쓰는 구조를 만드는 것이라는 걸 배웠습니다. 앞으로도 비용을 다룰 때 지출 패턴을 먼저 시각화하고 낭비 구간을 찾는 방식을 유지하겠습니다.
비용은 줄이는 것이 아니라 정렬하는 것입니다.
비용 최적화를 직접 다뤄본 건 데이터 파이프라인 운영 중 월간 인프라 비용이 예산의 두 배 가까이 나왔을 때입니다. 처음엔 단순히 비싼 인스턴스를 내리는 방향을 생각했지만, 먼저 어디서 비용이 나는지 서비스별로 분해하는 것이 우선이었습니다. 로그를 분석해보니 배치 작업이 끝난 뒤에도 클러스터가 유지되는 구간이 문제였고, 작업 완료 즉시 리소스를 반납하는 방식으로 구조를 바꿨습니다. 이후 동일 성능 대비 비용이 40%가량 줄었고, 그 수치는 다음 달 청구서로 직접 확인했습니다. 이 경험에서 배운 건 어디를 줄일지보다 왜 그 비용이 발생했는지를 먼저 읽어야 한다는 것입니다. 이후 새 작업을 설계할 때 리소스 반납 시점을 명시적으로 정하는 습관이 생겼고, 비용은 관리의 문제가 아니라 설계 단계부터 포함해야 할 항목이라는 인식으로 바뀌었습니다.
비용 최적화 접근 방식은 사용 패턴 시각화 → 낭비 구간 격리 → 구조 변경 순서로 잡고 있습니다. 실제 경험은 SaaS 도구 계약 갱신 시점이었는데, 부서별 실사용 데이터를 뽑아보니 실제 사용자가 계약 수의 절반도 안 됐습니다. 이를 근거로 라이선스 수를 조정하고 사용 빈도가 낮은 기능은 다른 도구로 대체했더니 연간 비용이 35% 가까이 줄었습니다. 중요한 건 줄이는 것 자체보다 '지금 실제로 사용하고 있는가'를 주기적으로 검증하는 루틴을 만든 점이었습니다. 이후로는 새로운 서비스를 도입할 때 처음부터 사용 지표 추적 방식을 함께 정하는 것이 자연스러운 절차가 됐습니다. 비용 최적화는 한 번의 점검 이벤트가 아니라 사용 데이터를 읽는 반복 루틴에 더 가깝다고 느꼈습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 재무·회계 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.