이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 동시 접속자를 고려한 중규모 웹 서비스를 처음 만들었습니다. 200명 동시 접속 시 응답이 느려지는 상황을 시뮬레이션했고, 단일 서버에서 모든 요청을 처리하다 보니 CPU가 금방 포화됐습니다. 쿼리 최적화와 Redis 캐싱을 적용해서 응답 시간을 줄였고, 정적 파일은 CDN으로 분리했습니다. 팀에서 제 역할은 API 설계와 DB 스키마를 담당하면서 다른 팀원들이 개발할 때 인터페이스 기준을 잡아주는 것이었습니다. 데이터가 쌓이면서 일부 쿼리 응답 시간이 점점 길어지는 현상을 경험했고, 인덱스 설계와 페이지네이션을 소급해서 적용했습니다. 초기에 설계 결정을 더 신중하게 했다면 소급 비용이 줄었을 거라는 점에서 서비스 규모가 커질수록 처음 설계 결정이 나중 비용을 결정한다는 걸 배웠습니다.
대규모 웹 서비스에서 개선 작업이 실제로 효과가 있었는지 수치로 확인하는 것이 중요했습니다. Redis 캐싱을 도입하기 전에 주요 API의 평균 응답 시간을 먼저 기록해뒀습니다. 캐싱 적용 후 같은 API를 측정했더니, 자주 조회되는 데이터를 캐싱한 엔드포인트에서 응답 시간이 평균 1.8초에서 0.15초로 줄었습니다. 모든 엔드포인트에 효과가 있었던 것은 아니고, 쓰기가 많은 API는 캐시 무효화 비용이 생겨 오히려 복잡해지는 경우도 있었습니다. 개선 작업을 할 때마다 전후 수치를 남기는 것이 다음 작업에서 어디에 집중해야 하는지를 알게 해줬습니다.
지표 없는 최적화는 무엇이 효과적인지 알 수 없는 결이 있다는 것을 이 경험에서 배웠습니다.
대규모 웹 서비스에서 처음 설계 결정이 나중 비용을 얼마나 크게 만드는지 직접 겪었습니다. 초기에 데이터가 적을 때는 문제없이 동작하던 쿼리가, 데이터가 쌓이면서 점점 느려지는 결이 됐습니다. 소급 인덱스를 추가하는 것은 기술적으로는 가능했지만, 인덱스 생성 중 해당 테이블에 잠금이 걸릴 수 있어 운영 환경에서 조심스럽게 진행해야 했습니다.
CONCURRENTLY 옵션으로 잠금 없이 인덱스를 생성하는 방식을 써야 했는데, 이것도 처음부터 알고 있었다면 더 쉬웠을 내용이었습니다. 지금은 새로운 테이블을 만들 때 자주 쓰이는 조회 조건을 먼저 파악하고 인덱스를 함께 설계하는 결이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.