이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트로 라이브 스트리밍 플랫폼을 설계했을 때, 가장 고민이 됐던 부분은 동시 접속자가 늘어날 때 지연 시간을 어떻게 안정적으로 유지할 것인가였습니다. 처음에는 단순히 CDN을 붙이면 해결될 거라 생각했는데, 실제로는 스트림 소스 단에서 세그먼트 크기와 버퍼링 전략을 함께 조정해야 했습니다. 서버를 오리진/엣지 계층으로 나눠 오리진은 트랜스코딩에 집중하고 엣지는 캐싱 위주로 동작하게 분리했더니 피크 타임에도 재생이 끊기는 빈도가 크게 줄었습니다.
HLS 세그먼트 크기를 조정하는 과정에서 짧으면 연결 오버헤드가 늘고 길면 초기 버퍼링이 길어지는 트레이드오프도 직접 체감했습니다. 이 경험에서 배운 건, 아키텍처 결정은 데이터 경로가 어디서 막히는지를 먼저 그려본 뒤에 내려야 한다는 점이었고, 지금은 설계 전에 병목 지점을 도식화하는 습관이 생겼습니다.
미디어 스트리밍 아키텍처를 혼자 설계하면서 HLS 세그먼트 크기를 어떻게 잡을지 오래 고민했습니다. 짧게 하면 연결 오버헤드, 길게 하면 초기 버퍼링이 생기는 트레이드오프는 알았는데, 실제 서비스에서 어느 쪽이 더 큰 문제인지 감이 없었습니다. 멘토링 세션에서 선배 개발자에게 질문했더니 라이브 스트리밍이냐 VOD냐에 따라 기준이 다르다 는 것을 처음 알게 됐습니다. 라이브는 낮은 지연이 우선이어서 짧은 세그먼트, VOD는 안정성이 우선이어서 긴 세그먼트가 일반적이었습니다. 이 조언으로 설계 방향을 빠르게 잡을 수 있었고, 혼자 실험으로 알아내는 데 걸렸을 시간을 크게 줄였습니다.
모르는 것을 물어보는 것이 설계 속도를 높이는 결이라는 것을 이 경험에서 배웠습니다.
스트리밍 서버를 오리진과 엣지 계층으로 나누는 설계를 완성했다고 생각했는데, 팀원 리뷰에서 DB 연결이 엣지에도 포함된 것을 발견했습니다. 엣지는 캐싱과 전달에 집중해야 하는데, DB 조회가 섞이면 엣지의 수평 확장 시 DB 커넥션 수가 급격히 늘어날 수 있다는 문제였습니다. 처음엔 왜 문제인지 명확히 이해하지 못했는데, 팀원이 트래픽 급증 시나리오를 그려주니 바로 납득이 됐습니다.
메타데이터 조회는 오리진에서만 하고 엣지는 캐시된 응답만 반환하도록 수정했습니다. 설계는 혼자 완성하는 것이 아니라 다른 시각에서 검증될 때 완성되는 결이라는 것을 이 경험에서 배웠습니다. 지금도 아키텍처 결정을 내리기 전에 한 사람에게 구두로 설명하는 결을 먼저 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.