이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
AWS 인프라 구축 경험 중 가장 도움이 됐던 것은 자동 확장 그룹 설계였습니다. 트래픽 패턴에 맞춰 EC2 인스턴스가 자동으로 늘고 줄어드는 구조를 직접 설정해봤는데, 스케일 인/아웃 임계값을 잘못 설정하면 인스턴스가 과도하게 생성되는 경험을 했습니다.
S3를 데이터 파이프라인 중간 저장소로 쓴 경험도 중요했습니다. 이벤트 트리거를 설정해 파일이 업로드되면 자동으로 처리 함수가 실행되는 구조를 만들었고, 파이프라인의 각 단계를 독립적으로 테스트할 수 있었습니다.
IAM 권한 설계도 실습했습니다. 처음에는 편의상 광범위한 권한을 부여했다가, 최소 권한 원칙을 학습한 뒤 역할 단위로 세분화하는 작업을 진행했습니다. 권한 범위가 줄어드니 실수로 잘못된 리소스를 수정하는 사고가 없어졌습니다.
AWS를 공부하면서 직접 해본 경험들이 쌓이면서 아직 약한 영역도 명확해졌습니다. 오토스케일링과 S3 파이프라인은 직접 구성해봤는데, 네트워크 설계는 아직 이론과 실습 사이의 간격이 있습니다. 서브넷 분리와 라우팅 테이블을 설정하다가 인터넷 게이트웨이와 NAT 게이트웨이가 어떤 경우에 필요한지 헷갈린 경험이 있었습니다. 비용 예측도 어려운 영역이었는데, 개인 프로젝트에서 예상보다 요금이 많이 나온 적이 있었습니다. 원인을 찾아보니 데이터 전송 요금이 발생하고 있었는데, 어느 서비스에서 어느 경로로 트래픽이 흐르는지 파악이 안 된 채로 구성했던 것이 문제였습니다. IAM 권한도 단순한 환경에서는 정리가 됐는데, 서비스 간 위임 관계가 복잡해지면 어느 역할이 어떤 리소스에 접근하는지 추적이 어려워졌습니다. AWS는 개별 서비스를 아는 것보다 서비스 간 연동 흐름과 네트워크 구조를 이해하는 것이 더 중요하다는 것을 배웠습니다.
AWS 인프라 구축에서 배포하고 나서 운영 중에 어떻게 되는지 모니터링하는 것도 인프라 구축만큼 중요하다는 것을 배웠습니다. 처음에는 배포가 되면 끝이라고 생각했는데, 오토스케일링이 예상대로 작동하는지 실제로 확인하려면 지표를 봐야 했습니다. CloudWatch로 CPU 사용률과 요청 수를 대시보드에 올리니 인스턴스가 늘어나는 시점과 줄어드는 시점이 어떻게 되는지 시각적으로 확인됐습니다. 경보 설정을 처음 해봤는데, 임계값을 너무 민감하게 잡으면 알림이 너무 자주 오고 너무 느슨하면 실제 문제를 놓친다는 것을 설정해보면서 배웠습니다. S3 파이프라인에서는 처리 함수의 오류율을 지표로 추가하니 어느 단계에서 실패가 집중되는지 파악할 수 있었습니다. 인프라는 구축 자체보다 구축 후 어떤 지표를 보고 어떤 경보를 설정할지 결정하는 것이 운영 안정성을 결정한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.