[CS | 실시간 시스템] 병목이 발생하는 이유

실시간 시스템에서 병목이 발생하는 이유

실시간 시스템을 처음 설계할 때 가장 많이 착각하는 부분 중 하나는
“성능을 충분히 높이면 병목은 없앨 수 있다”는 생각입니다.
저 역시 SpeakNote 프로젝트를 시작할 당시에는, 처리 속도를 빠르게 만들면 실시간성은 자연스럽게 따라올 것이라고 생각했습니다.

하지만 실제로 실시간 음성 스트리밍, STT, AI 요약, 그리고 PDF 주석 렌더링까지 연결해보니 병목은 ‘없앨 수 있는 문제’가 아니라, 반드시 관리해야 하는 대상라는 점을 체감하게 되었습니다.

이 글에서는 SpeakNote 프로젝트를 진행하며 느꼈던 경험을 바탕으로, 왜 실시간 시스템에서는 병목이 필연적으로 발생하는지, 그리고 이를 어떻게 바라봐야 하는지 정리해보려고 합니다.

---

1. 실시간 시스템은 항상 “흐름”으로 동작합니다

일반적인 웹 애플리케이션은 요청(Request)이 들어오면 응답(Response)을 반환하는 구조입니다.
이 경우, 처리 시간이 다소 길어지더라도 사용자는 단순히 “조금 느리다”라고 느낄 뿐, 시스템이 깨졌다고 인식하지는 않습니다.

하지만 실시간 시스템은 다릅니다.
SpeakNote의 경우 다음과 같은 흐름을 가집니다.

1. 사용자의 음성 입력
2. 오디오 스트림 전송
3. STT 처리
4. 일정 단위의 텍스트 누적
5. AI 요약 및 주석 생성
6. 클라이언트로 주석 전송
7. 화면에 즉시 반영

이 중 어느 한 단계라도 지연이 발생하면, 그 지연은 다음 단계로 그대로 전파됩니다.
즉, 실시간 시스템은 “개별 기능의 합”이 아니라 연속된 파이프라인으로 동작합니다.

이 구조에서는 병목이 생기지 않는 것이 오히려 더 이상한 상태에 가깝습니다.

 

1. 1 병목 현상이란?

병목(Bottleneck)이란, 시스템을 구성하는 여러 단계 중 전체 처리 속도를 결정해버리는 가장 느린 지점을 의미합니다.

중요한 점은, 병목은 “특정 컴포넌트가 느려서” 발생하는 것이 아니라 서로 다른 속도를 가진 단계들이 하나의 흐름으로 연결될 때 자연스럽게 생긴다는 점입니다. 실시간 시스템에서는 이 병목이 다음과 같은 특징을 가집니다.

• 한 지점의 지연이 연쇄적으로 전파됨
• 누적되며, 되돌릴 수 없음
• 사용자에게 즉시 체감됨

즉, 실시간 시스템에서 병목은 성능 문제가 아니라 구조적 특성에 가깝습니다.

 

---

2. 병목은 ‘느린 코드’ 때문이 아니라 ‘속도가 다른 단계들’ 때문에 생깁니다

처음에는 병목의 원인을 흔히 코드 최적화 문제로 생각하게 됩니다.
하지만 실제로는 각 단계가 요구하는 처리 속도가 서로 다르기 때문에 병목이 발생합니다.

SpeakNote에서 예를 들면,

• 오디오 스트리밍은 밀리초 단위로 발생합니다.
• STT는 짧은 지연을 허용하지만 완전히 실시간은 아닙니다.
• AI 요약은 수백 ms ~ 수 초의 시간이 필요합니다.
• PDF 주석 렌더링은 브라우저 성능에 영향을 받습니다.

이처럼 각 단계는 서로 다른 시간 스케일을 가집니다.
아무리 개별 단계의 성능을 개선하더라도,
가장 느린 단계가 전체 흐름의 속도를 결정하게 됩니다.

결국 병목은 “잘못 만든 코드”의 결과가 아니라,
서로 다른 속도를 가진 컴포넌트들이 하나의 흐름으로 연결되었을 때 자연스럽게 발생하는 현상입니다.

---

3. 실시간 시스템에서 병목은 숨길 수 없습니다

배치 처리나 비동기 작업 위주의 시스템에서는 병목을 어느 정도 숨길 수 있습니다.

• 작업 큐에 쌓아두고
• 백그라운드에서 처리하고
• 사용자는 결과만 나중에 확인하게 만드는 방식입니다.

하지만 실시간 시스템에서는 이런 방식이 통하지 않습니다.
SpeakNote처럼 “지금 말하고 있는 강의 내용이 바로 화면에 나타나야 하는” 시스템에서는
지연이 곧바로 사용자 경험 저하로 이어집니다.

• 주석이 늦게 뜨면 “안 된다”라고 느껴지고
• 일정 시점 이후 한꺼번에 쏟아지면 “끊긴다”라고 느껴집니다.

즉, 병목은 숫자 지표가 아니라 체감 경험으로 드러납니다.
이 때문에 실시간 시스템에서는 병목을 감추는 것이 아니라,
사용자가 받아들일 수 있는 형태로 조절하는 것이 중요해집니다.

---

4. 그래서 중요한 것은 ‘병목 제거’가 아니라 ‘병목 정의’입니다

SpeakNote 프로젝트를 진행하며 가장 크게 바뀐 관점은 이것이었습니다.

병목을 없애려고 하기보다,
어디에서 병목이 발생하는지를 명확히 정의해야 한다.

이를 위해 다음과 같은 질문을 먼저 정리했습니다.

• 실시간이라고 판단할 수 있는 기준은 무엇인가?
• 어느 단계까지의 지연은 허용 가능한가?
• 사용자가 가장 민감하게 느끼는 지점은 어디인가?

이 과정을 통해, 모든 단계를 동일한 기준으로 빠르게 만들 필요는 없다는 결론에 도달했습니다.
오히려 사용자 경험에 직접 영향을 주는 구간을 중심으로 병목을 관리하는 것이 중요했습니다.

---

5. SpeakNote에서의 선택: 병목을 인정한 설계

SpeakNote 초기 버전에서는 다음과 같은 선택을 했습니다.

• STT는 최대한 실시간에 가깝게 처리
• AI 요약은 일정 텍스트 단위로 묶어서 실행
• 주석 생성은 “즉시 반영”이 아닌 “빠른 주기 반영”으로 설계

즉, 모든 단계를 완전한 실시간으로 만들기보다는
병목이 발생하는 지점을 명확히 인지하고, 그 영향 범위를 제어하는 방식을 택했습니다.

이 선택 덕분에 시스템은 단순해졌고,
단일 사용자 기준에서는 충분히 안정적인 동작을 확보할 수 있었습니다.

 

다음 게시물에서 어떤 방식으로 병목을 제어하여, 안정적인 동작을 할 수 있게끔 했는지 기록해보겠습니다. 

https://ye-seul0-0.tistory.com/187

[Architecture] 병목 현상을 줄이기 위한 실시간 아키텍처 설계(Project:SpeakNote)