이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 GCP Cloud Run 위에 마이크로서비스 4개를 올리는 작업을 팀 3명과 함께 진행한 경험이 있습니다. 초기 배포 후 특정 서비스가 트래픽 급증 시 간헐적으로 응답을 못 돌려주는 문제가 생겼습니다. 로그를 뒤지니 서비스 간 내부 호출이 타임아웃 설정 없이 무한 대기 상태로 쌓이는 패턴이었습니다. 저는 Cloud Logging으로 에러 패턴을 시각화해 팀원들에게 공유하고, 각 서비스 호출에 3초 타임아웃과 재시도 로직을 붙이기로 합의했습니다. 수정 후 부하 테스트에서 에러율이 12%에서 1%로 줄었습니다. 분산 환경에서는 서비스 간 경계 설정이 성능만큼 중요하다는 걸 그 프로젝트에서 체감했습니다.
캡스톤 프로젝트에서 AWS ECS와 RDS를 연결한 이미지 처리 파이프라인을 구축했습니다. 초기에는 컨테이너 5개가 각자 DB 커넥션을 직접 맺는 구조였는데, 부하 테스트에서 동시 접속이 늘자 DB 커넥션 한계로 에러가 연쇄 발생하는 패턴이 잡혔습니다.
RDS Proxy를 도입해 커넥션 풀링을 위임했고, 연결 초과 에러는 주 3~4회에서 0회로 줄었습니다. 그런데 이번엔 일부 쿼리 응답이 평균보다 두 배 이상 느려지는 현상이 새로 생겼습니다. 원인을 추적하니 RDS Proxy가 Prepared Statement를 핀닝해 연결을 독점하는 동작이었습니다. 실행 방식을 텍스트 모드로 전환하고 나서야 지연이 해소됐습니다.
인프라 레이어를 추가할 때 그 레이어의 고유한 동작 특성을 먼저 파악하지 않으면 해결책이 또 다른 병목을 만든다는 것을 그때 배웠습니다.
팀 프로젝트에서 GCP Pub/Sub과 BigQuery를 연결한 실시간 이벤트 집계 시스템을 만든 적이 있습니다. Cloud Function이 메시지를 받아 BigQuery에 스트리밍 적재하는 구조였는데, 배포 후 데이터 전송 비용이 예상치의 세 배로 나왔습니다. 처음엔 쿼리나 배치 사이즈 문제로 보고 최적화를 시도했지만 개선이 없었습니다. 원인을 파고드니 Pub/Sub과 BigQuery 데이터셋이 서로 다른 리전에 배치돼 크로스 리전 트래픽이 전량 과금되고 있었습니다. 리소스를 같은 리전으로 통합하자 비용이 일주일 안에 정상 수준으로 내려왔습니다. 이 경험 이후 설계 단계에서 기능 구현 전에 리전 배치 다이어그램을 먼저 그리는 것을 팀 검토 항목에 추가했습니다. 클라우드 인프라에서 리전 배치 결정은 나중에 고치기 까다롭기 때문에 초기에 확정하는 편이 훨씬 낫다고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.