이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
스케일러블한 시스템을 설계할 때 핵심은 상태를 공유하는 컴포넌트를 최소화하는 것이라고 생각합니다. 서버가 상태를 내부에 보유하면 수평 확장 시 동기화 문제가 생기기 때문에, 세션은 Redis에, 파일은 오브젝트 스토리지에 외부화하는 구조가 중요합니다. 사이드 프로젝트에서 애플리케이션 서버를 Stateless로 설계한 뒤 로드 밸런서를 추가하니 인스턴스를 늘리는 데 별다른 코드 변경이 필요 없었습니다.
비동기 작업 큐를 도입해 응답 시간이 긴 작업을 분리하자 API 응답 속도가 일정해졌고, 사용자 경험이 개선됐습니다. DB 병목도 스케일링에서 빠지지 않는 과제인데, 읽기 전용 레플리카를 분리하고 자주 조회하는 데이터를 캐시하는 것이 기본 접근입니다. 시스템은 처음부터 완전히 스케일 아웃하기보다 병목을 찾고 순서대로 개선하는 것이 현실적인 결임을 배웠습니다.
사이드 프로젝트에서 마이크로서비스 구조로 전환하면서 직접 스케일링 문제를 마주쳤습니다. API 서버 인스턴스를 두 개로 늘렸는데 로그인 세션이 유지되지 않는 문제가 생겼습니다. 서버마다 메모리에 세션을 저장하고 있었고, 로드 밸런서가 다른 인스턴스로 요청을 보내면 세션을 찾지 못했습니다.
세션 저장소를 Redis로 외부화하는 것으로 해결했습니다. 코드 변경은 생각보다 단순했지만, 이 과정에서 Stateless 서버가 무엇을 의미하는지를 개념이 아닌 실제 현상으로 처음 이해했습니다. 서버가 상태를 갖는 순간 인스턴스를 늘려도 서로 다른 상태를 공유하지 못하는 문제가 생긴다는 것입니다.
이 경험 이후로 새 서비스를 설계할 때 '이 컴포넌트가 상태를 갖는가'를 가장 먼저 확인하는 습관이 생겼습니다. 스케일링 문제는 대부분 상태가 어디에 있는지를 명확히 하지 않은 데서 시작하는 자리라는 것이 이 프로젝트에서 남은 결입니다.
트래픽이 몰릴 때 API 응답 시간이 불규칙하게 튀는 문제가 있었습니다. 분석해보니 이미지 리사이징처럼 처리 시간이 긴 작업이 같은 API 요청 안에서 동기로 처리되고 있었습니다. 요청이 몰리면 이 작업이 쌓이면서 전체 응답 시간이 덩달아 늘어나는 구조였습니다.
비동기 큐를 도입해 리사이징 작업을 백그라운드로 분리했습니다. API는 즉시 응답을 돌려주고 실제 처리는 워커가 담당하는 구조로 바꿨습니다. 변경 전 평균 응답 시간이 2.3초였는데 변경 후 0.4초로 줄었고, P95 응답 시간의 분산도 크게 줄어 응답이 일정해졌습니다.
수치가 목표를 달성했는지 확인하기 전에는 개선이 됐는지 판단하기 어려웠습니다. 스케일링 작업에서 '빨라졌다'는 감각보다 응답 시간과 P95를 직접 찍어서 비교하는 것이 판단 기준이 된다는 것을 이 경험에서 처음 확인했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.