클라우드 환경에서 실제 운영 경험이 있는지를 확인한다. 이론이 아닌 실무 적용 능력과 문제 해결 경험을 평가한다.
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
클라우드 환경 운영 경험은 AWS 기반 서비스의 배포 파이프라인과 모니터링 설정에서 쌓았습니다. EC2 인스턴스와 RDS를 운영하면서 비용 최적화와 장애 대응 두 가지에 집중했습니다. 비용은 사용하지 않는 리소스를 주기적으로 확인하고 예약 인스턴스를 활용하는 방식으로 줄였습니다. 장애 대응은 CloudWatch 알림으로 임계치를 설정하고 슬랙과 연동했습니다. 가장 배운 것은 클라우드는 편하지만 설정이 잘못되면 비용이 빠르게 늘어난다는 점이었습니다. 앞으로도 비용 가시성과 장애 감지를 운영의 기본으로 유지하는 방식을 이어가겠습니다. 앞으로도 비용 가시성과 장애 감지를 운영의 기본으로 유지하는 방식을 이어가겠습니다.
클라우드는 편하지만 설정이 잘못되면 비용이 빠르게 늘어납니다. CloudWatch 임계치와 슬랙 알림 연동이 장애 대응 시간을 줄이는 가장 실질적인 방법이었습니다.
GCP 기반 인프라를 운영하면서 컨테이너 환경 전환 과정에서 가장 많은 것을 배웠습니다. 처음에는 VM 위에서 서비스를 직접 띄우다가 트래픽이 예측 불가하게 튀는 시점이 반복되자, Kubernetes 클러스터로 전환하는 결정을 내렸습니다. 전환 후에는 HPA(수평 파드 오토스케일러)를 설정해 피크 타임에 파드 수가 자동으로 늘어나는 구조를 만들었고, 비용은 오히려 줄었습니다. 운영 중에 가장 신경 쓴 건 노드 장애 시 자동 복구 여부를 사전에 검증하는 것이었습니다. 카오스 엔지니어링 수준은 아니었지만 의도적으로 파드를 강제 종료해 서비스 연속성을 확인하는 테스트를 주기적으로 진행했습니다. Cloud Logging으로 에러 패턴을 모니터링하면서 장애 발생 전 조짐을 알림으로 잡는 방식이 실제 대응 시간을 줄였습니다.
컨테이너 환경은 배포가 빠른 만큼 설정 오류가 전파되는 속도도 빠르다는 걸 운영하면서 몸으로 익혔습니다.
이전 팀에서는 AWS와 온프레미스를 병행 운영하는 하이브리드 환경에서 일했습니다. 가장 복잡했던 건 두 환경 간 네트워크 레이턴시와 데이터 동기화 타이밍을 맞추는 부분이었습니다. 특정 배치 작업이 새벽에 실패했을 때 온프레미스 서버 로그와 AWS CloudTrail 로그를 동시에 뒤지는 일이 반복됐고, 그때 중앙 집중식 로그 수집 체계의 필요성을 처음 실감했습니다. Elasticsearch로 로그를 모으고 Kibana 대시보드를 만들어 두 환경의 이벤트 흐름을 한 화면에서 보는 구조로 바꾼 뒤 장애 원인 파악 시간이 눈에 띄게 줄었습니다.
장애 복구 시나리오를 문서화하는 것도 운영의 일부라는 인식이 이때 생겼습니다. 단순히 시스템을 고치는 게 아니라 다음 번에 같은 문제를 더 빠르게 잡을 수 있는 흔적을 남기는 것이 운영 품질을 높입니다. 로그가 없으면 원인 추적이 아닌 추측이 됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 펄어비스 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.