이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
부트캠프 팀 프로젝트에서 AWS EC2에 Nginx + Node.js 서버를 직접 구성하고 배포했습니다. 처음엔 로컬에서만 돌아가던 앱을 외부에서 접근 가능하게 만드는 것 자체가 낯설었는데, 포트 설정, SSL 인증서, 리버스 프록시 구성을 순서대로 해결하면서 전체 흐름을 파악했습니다. 배포는 GitHub Actions로 main 브랜치 머지 시 자동 배포되도록 파이프라인을 구성했습니다. 모니터링은 서버 CPU·메모리 사용률을 CloudWatch로 확인했고, 장애 시 이메일 알림이 오도록 설정했습니다. 실제로 메모리 누수로 서버가 멈추는 상황이 발생했을 때 로그를 직접 분석해 원인을 찾고 수정했던 경험이 가장 기억에 남습니다. 서버 장애를 직접 로그로 분석한 경험이 운영 환경에서 문제를 빠르게 진단하는 감각을 길러줬습니다. 직접 구축한 것은 왜 그렇게 됐는지를 더 잘 이해하게 만듭니다.
학교 프로젝트에서 Docker로 애플리케이션을 컨테이너화하고 VPS에 배포한 경험이 있습니다. 로컬과 서버 환경 차이로 생기는 문제를 없애고 싶었는데, 컨테이너로 묶으니 환경 의존성이 사라지고 배포가 단순해졌습니다. 배포는 docker-compose로 서비스를 정의하고, 처음에는 수동으로 실행했지만 나중에 `GitHub Actions`로 push 이벤트에 자동 배포가 트리거되도록 파이프라인을 추가했습니다. 모니터링은 컨테이너 로그를 실시간으로 확인하고, 헬스체크 실패 시 알림이 오도록 설정했습니다. 한 번은 컨테이너가 재시작을 반복하는 상황이 있었는데, 로그로 확인하니 환경변수 설정 누락이 원인이었습니다.
컨테이너는 환경을 통일하지만, 설정은 여전히 사람이 점검해야 합니다. 자동화된 환경도 사람의 확인이 필요한 지점이 있습니다. 배포의 단순화와 안정성은 함께 설계해야 합니다.
배포보다 운영 중 이상을 빠르게 감지하는 구조를 만드는 것이 더 어렵다는 걸 직접 운영해보고 알았습니다. 팀 프로젝트에서 GCP에 서버를 올리고 응답 시간과 오류율을 로그로 남기는 구조를 초반에 잡아뒀습니다. 처음에는 로그를 확인하는 방식이 수동이었는데, 알림 임계값을 설정해두지 않으니 장애가 한참 뒤에 발견되는 일이 있었습니다. 그 이후에 오류 비율이 특정 수치를 넘으면 알림을 보내도록 설정하고 나서, 같은 수준의 오류를 훨씬 빠르게 발견했습니다. 장애 대응에서 가장 중요했던 건 로그에 타임스탬프와 요청 맥락이 함께 남아있어야 원인을 빠르게 좁힐 수 있다는 것이었습니다.
감지 구조 없이 운영하면 장애가 쌓인 뒤에야 보입니다. 알림보다 먼저 로그 구조를 잡아야 합니다. 보이는 것만 고칠 수 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 마켓컬리 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.