이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트로 만든 일정 관리 웹 서비스를 실 서버에 올렸을 때, 예상 못 했던 건 동시 접속이 늘 때 응답이 무너지는 속도였습니다. 처음 100명 정도까지는 문제가 없었는데, 300명을 넘기자 DB 커넥션 풀이 바닥나면서 p95 응답 시간이 12초를 넘겼습니다. 가장 먼저 한 건 슬로우 쿼리 로그를 켜고 N+1 패턴을 찾는 것이었고, 문제가 되는 쿼리 3개를 발견했습니다. 인덱스 추가와 JOIN 재구성으로 가장 느린 쿼리를 320ms에서 18ms로 줄였습니다. 그 과정에서 성능 문제는 코드보다 데이터 접근 패턴에서 먼저 찾아야 한다는 걸 체감했고, 이후 설계 단계부터 쿼리 패턴을 먼저 그리는 습관이 생겼습니다.
상용 서비스를 운영하면서 사용자가 늘어날수록 서버 비용도 함께 늘어나는 문제를 경험했습니다. 처음에는 단순한 구조로 시작해서 모든 요청을 서버에서 직접 처리했는데, 트래픽이 늘어나면서 서버 사양을 올리는 방식으로 대응했습니다. 비용을 확인해보니 사양을 올리는 것이 트래픽 증가 속도를 따라가기 어려운 구조라는 것을 알게 됐습니다. 자주 변경되지 않는 데이터는 캐싱을 적용하고, 정적 콘텐츠는 CDN으로 이전하는 작업을 진행했는데, 서버 요청 수가 줄면서 비용도 안정됐습니다. 이 경험에서 상용 서비스의 도전적인 부분 중 하나는 기능이 잘 동작하는 것뿐 아니라 비용 효율적으로 운영되는 구조를 만드는 것이라는 것을 배웠습니다. 아키텍처 결정은 성능뿐 아니라 운영 비용도 함께 고려해야 한다는 것을 이 경험에서 배웠습니다.
상용 서비스를 운영하면서 개발 환경에서는 재현되지 않는 버그가 실사용자 환경에서 발생하는 경험을 했습니다. 특정 사용자에게서만 오류가 발생했는데, 개발 환경에서는 같은 조건을 만들기 어려워서 원인을 찾는 데 시간이 걸렸습니다. 로그를 추가해서 실제 환경에서 오류가 생기는 시점의 상태를 기록하고 나서야 원인을 찾을 수 있었는데, 특정 데이터 조합에서만 예외가 발생하는 케이스였습니다. 이 경험에서 상용 서비스는 개발 환경에서 검증하는 것만으로는 부족하고, 실제 사용자 데이터와 환경에서 어떤 문제가 생기는지를 관찰하는 구조가 필요하다는 것을 배웠습니다. 오류 로그와 모니터링을 처음부터 갖추는 것이 나중에 문제를 빠르게 찾는 데 핵심이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.