예시 답변 1
약 86초
기술 선택 이유·성능 지표 설정·처리 구조 분리 중심으로 푸는 결
졸업 프로젝트에서 실시간 요청 처리량을 측정하는 모니터링 컴포넌트를 간단히 구현해본 경험이 있습니다. WebSocket으로 클라이언트와 연결하고, 서버 측에서 초당 요청 수(RPS)를 집계해 대시보드에 스트리밍하는 방식을 택했습니다. HTTP 폴링 방식보다 연결 유지 비용이 낮고 즉각적인 데이터 전달이 가능하다는 판단에서였습니다. 성능을 측정할 때는 응답 지연(latency)과 처리량(throughput) 두 가지를 기준으로 삼았고, Prometheus를 붙여 시계열 데이터로 남겼습니다. 데이터 처리는 집계 주기를 1초 단위로 설정하고, 급격한 스파이크가 생길 때는 이동 평균으로 smoothing하는 방법을 실험했습니다. 대규모 시스템에서는 메시지 큐로 버퍼링하는 구조가 더 적합하다는 것을 공부하면서, 이벤트 수집과 집계 단계를 분리하는 것이 핵심임을 배웠습니다.
이 결의 특징
WebSocket으로 초당 요청 수를 집계해 스트리밍하는 구조를 택한 이유를 HTTP 폴링과 비교해 밝히고, Prometheus로 지연·처리량을 시계열로 남긴 흔적이 있습니다. 이벤트 수집과 집계를 분리하는 것이 핵심이라는 결론으로 매듭짓는 결이 보입니다.
이 결이 통하는 자리
기술 선택의 이유가 대안과 비교로 살아 있을 때 통합니다. 대규모 환경에서의 한계까지 공부하며 인지했다는 확장이 있을 때 통하는 결이 보입니다.