이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 기간에 AWS 기반 인프라 운영을 처음으로 경험했습니다. EC2와 RDS를 기본으로 사용했고, 배포 파이프라인은 GitHub Actions로 구성해 main 브랜치에 머지되면 자동으로 빌드와 배포가 진행되도록 설정했습니다. 운영 중 가장 많이 다룬 부분은 보안 그룹 설정과 IAM 권한 관리였는데, 처음에는 편의상 권한을 넓게 열어뒀다가 보안 리뷰에서 지적받고 최소 권한 원칙을 적용하는 방식으로 수정했습니다.
CloudWatch로 서버 지표를 모니터링했고, CPU와 메모리 임계값을 넘으면 알림이 오도록 설정해 두었습니다. 인프라 코드화에 관심이 생겨 Terraform 기초도 학습하고 있는데, 수동으로 콘솔에서 설정하면 변경 이력이 남지 않아 재현이 어렵다는 문제를 직접 겪은 뒤였습니다. 인프라 운영은 기술 스택보다 변경을 추적 가능하게 유지하는 습관이 먼저라는 결을 얻었습니다.
인프라 운영에서 변경이 실제로 효과가 있었는지 확인하는 것이 처음에는 어려웠습니다. 설정을 바꿔도 좋아진 것 같다는 감각만 있고 수치로 검증하기 어려웠습니다. Prometheus로 변경 전후의 CPU 사용률과 응답 분위수를 비교하는 방식을 도입했습니다.
Grafana 대시보드에 before/after 구간을 표시하니 변경의 효과가 수치로 명확하게 드러났습니다. 로드밸런서 설정을 바꾼 뒤 P95 응답 시간이 800ms에서 320ms로 줄었는데, 이 수치를 팀과 공유했더니 다음 개선 방향에 대한 논의도 훨씬 구체적이 됐습니다. 인프라 운영은 느낌이 아니라 수치로 검증되어야 의사결정이 빨라지는 결이 있다는 것을 이 경험에서 배웠습니다.
메트릭이 없으면 개선을 주장하기 어렵다는 것도 함께 배웠습니다.
인프라를 콘솔에서 수동으로 설정하다가 같은 환경을 재현하지 못하는 문제가 생겼습니다. 개발 환경과 스테이징 환경의 설정이 달라서 환경 간 동작 차이가 원인 파악을 어렵게 만들었습니다. Terraform을 도입해 인프라 설정을 코드로 관리하기 시작했습니다. 처음에는 학습 비용이 있었지만, 코드를 버전 관리하면 언제 무엇이 바뀌었는지 추적이 됐고, 새 환경을 만들 때 같은 코드를 실행하면 동일한 설정이 보장됐습니다. 팀원이 인프라를 변경할 때도 PR 리뷰를 통해 의도하지 않은 변경을 사전에 확인할 수 있었습니다.
인프라도 코드와 같은 방식으로 관리하면 신뢰성이 높아지는 결이 있다는 것을 이 경험에서 배웠습니다. IaC는 도구가 아니라 인프라를 다루는 방식의 전환이라는 것이 남았습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 DB그룹 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.