이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 `EC2` + `RDS` + `S3` 기반으로 서비스를 배포했는데, 처음에는 모든 트래픽을 단일 인스턴스에서 처리하다가 응답 지연이 3초 이상으로 늘어나는 문제가 생겼습니다. 원인을 분석해보니 이미지 처리 로직이 웹 서버와 같은 프로세스에서 돌아가고 있었습니다.
S3로 이미지 처리를 이관하고 Lambda를 붙여서 비동기 처리로 분리했더니 평균 응답 시간이 0.8초로 줄었습니다. 혼자 설계하면서 실패한 부분도 많았는데, 그 경험 덕에 서비스 아키텍처를 역할 단위로 분리하는 감각이 생겼습니다. 이후에는 새 기능을 붙일 때 기존 흐름에 영향을 주는지를 먼저 확인하는 습관이 생겼습니다.
인턴 기간에 CloudWatch 알람 설정을 담당했는데, 초기에 임계값 설정이 잘못되어 알람이 너무 자주 울리는 상황이 생겼습니다. 처음에는 모든 알람에 반응하다가 결국 알람 피로로 실제 이상 징후를 늦게 발견하는 문제가 있었습니다. 이후 p99 레이턴시와 5xx 에러율 두 지표만 우선 모니터링하도록 좁혔고, 에러 발생 시 `SNS` → 슬랙 알림 파이프라인을 구성했습니다. 단순히 서비스를 띄우는 것과 운영 가능한 상태로 유지하는 건 다른 문제라는 걸 그때 배웠습니다. 지금은 새 서비스를 만들 때 모니터링 설계를 배포 전에 먼저 논의하는 편입니다. 어떤 지표를 볼지 미리 정해두지 않으면, 장애가 났을 때 무엇이 문제인지 찾는 데만 시간이 다 가는 걸 봤기 때문입니다.
사이드 프로젝트에서 RDS를 항상 켜두다가 한 달 비용이 예상의 3배가 나온 적이 있었습니다. 원인은 개발 환경과 운영 환경을 분리하지 않고 같은 인스턴스를 쓴 것이었습니다. 이후 개발 환경은 `RDS` 스케줄러로 야간에 자동 중지하고, 스테이징은 Aurora Serverless v2로 전환해서 비용을 약 60% 줄였습니다.
AWS에서 비용은 아키텍처 선택의 결과라는 걸 직접 겪으면서 배웠고, 이후에는 서비스 설계 단계에서 비용 시뮬레이션을 먼저 해보는 습관이 생겼습니다. 개발 편의와 비용 효율 사이의 균형점을 처음부터 의식하게 된 계기였습니다. 비용이 예상을 넘기 전에 경고 알람을 Budgets으로 설정해두는 습관도 그때부터 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.