공부저장소

📘 SyncMon

1. 문제의 출발점

웹 서비스는 기본적으로 요청-응답 모델 위에서 동작합니다.

클라이언트가 요청을 보내면 서버가 응답하고, 요청이 없으면 서버도 별다른 일을 하지 않습니다. 조회, 등록, 수정처럼 사용자의 명시적인 행동을 기준으로 동작하는 기능은 이 모델만으로도 충분합니다.

하지만 운영 도구나 모니터링 시스템은 성격이 다릅니다.

이런 시스템에서는 사용자가 먼저 요청하지 않아도, 서버에서 발생한 상태 변화를 즉시 사용자에게 알려야 하는 순간이 자주 생깁니다. 예를 들어 장애 징후, 임계치 초과, 작업 실패, 지연 증가 같은 이벤트는 사용자가 새로고침할 때까지 기다렸다가 보여주면 의미가 크게 떨어집니다.

즉, 이 문제는 단순히 “실시간처럼 보이게 만들자”의 문제가 아니라, 서버가 먼저 알고 있는 이벤트를 클라이언트에 언제, 어떤 방식으로 전달할 것인가의 문제였습니다.

2. HTTP만으로는 왜 불편했는가

이 요구사항을 HTTP만으로 풀 수 없는 것은 아닙니다.

가장 흔한 방식은 polling입니다. 클라이언트가 일정 주기마다 서버에 요청을 보내 상태 변화를 확인하는 방식입니다.

처음에는 이 방식이 구현하기 가장 단순해 보입니다.

하지만 운영 관점에서 보면 몇 가지 한계가 분명합니다.

첫째, 이벤트가 없어도 요청은 계속 발생합니다.

즉, 실제 변화가 없는데도 클라이언트는 정해진 주기마다 서버를 조회해야 합니다. 화면 수가 늘어나고 사용자가 많아질수록 이 불필요한 요청은 누적 비용이 됩니다.

둘째, 이상 상황을 감지해도 전달은 polling 주기에 종속됩니다.

서버에서 장애를 감지한 시점과 클라이언트가 그 사실을 인지하는 시점 사이에는 최소 polling 간격만큼의 지연이 생깁니다. 주기를 짧게 잡으면 즉시성은 조금 나아지지만, 그만큼 요청 수가 더 늘어납니다. 반대로 주기를 길게 잡으면 부하는 줄지만 이벤트 전달이 느려집니다. 결국 즉시성과 비용 사이에서 계속 손해를 보는 구조가 됩니다.

셋째, 이벤트 중심 시스템과 잘 맞지 않습니다.

모니터링 시스템은 본질적으로 “조회 시스템”이 아니라 “이상 이벤트 전달 시스템”에 가깝습니다. 그런데 polling은 이벤트가 발생했을 때만 보내는 구조가 아니라, 이벤트가 없어도 계속 확인하는 구조입니다. 즉, 문제의 성격과 통신 방식이 어긋나 있습니다.

3. SyncMon의 요구사항은 무엇이었는가

SyncMon은 단순 상태 조회 화면이 아니라, 운영자가 이상 징후를 빠르게 인지할 수 있도록 돕는 모니터링 시스템입니다.

여기서 중요한 것은 “현재 상태를 보여주는 것”보다 이상이 발생한 순간을 놓치지 않게 하는 것입니다.

특히 요구사항 중 하나는, 서버가 특정 이상 상황을 감지하면 화면에서 즉시 경고를 표시하고, 필요하면 TTS 음성까지 바로 재생되어야 한다는 것이었습니다.

이 요구사항을 기준으로 보면 핵심은 명확합니다.

  • 이상 여부는 서버가 먼저 안다.
  • 운영자는 그 사실을 즉시 알아야 한다.
  • 클라이언트의 다음 조회 시점까지 기다리면 늦다.

즉 SyncMon에서 필요한 것은 “주기적인 상태 조회”가 아니라, 서버가 감지한 이벤트를 지연 없이 밀어넣을 수 있는 통신 모델이었습니다.

4. 그래서 WebSocket을 선택했다

WebSocket은 서버와 클라이언트가 한 번 연결을 맺은 뒤, 그 연결을 유지하면서 양방향으로 데이터를 주고받을 수 있는 방식입니다.

핵심은 연결을 매번 새로 만드는 것이 아니라, 연결을 유지한 상태에서 서버가 필요할 때 바로 메시지를 보낼 수 있다는 점입니다.

SyncMon에서는 이 특성이 요구사항과 잘 맞았습니다.

서버가 모니터링 이상 이벤트를 감지하면, 해당 이벤트를 즉시 화면으로 push하고, 클라이언트는 이를 받아 화면 경고나 TTS 재생 같은 후속 동작을 수행할 수 있습니다.

이 구조의 장점은 명확합니다.

  • 이벤트가 없을 때는 불필요한 반복 조회를 줄일 수 있습니다.
  • 서버가 이상을 감지한 직후 바로 전달할 수 있어 전달 지연을 최소화할 수 있습니다.
  • “이상이 생겼는지 확인하는 화면”이 아니라, “이상이 생기면 즉시 반응하는 화면”으로 바꿀 수 있습니다.

즉 WebSocket을 도입한 이유는 단순히 실시간 기술을 사용해보기 위해서가 아니라, 모니터링 시스템의 핵심 요구사항이 서버 주도 이벤트 전달에 있었기 때문입니다.

5. WebSocket이 만능은 아니다

여기서 중요한 점은 WebSocket이 모든 경우에 정답은 아니라는 것입니다.

단순 조회 화면이나 사용자의 요청에 따라 데이터가 바뀌는 일반적인 CRUD 화면이라면 HTTP만으로도 충분합니다. 오히려 그런 곳에 무조건 WebSocket을 붙이면 연결 관리와 복잡도만 늘어날 수 있습니다.

실제로 WebSocket은 도입 이후 고려해야 할 운영 포인트도 분명합니다.

  • 연결이 끊겼을 때 재연결을 어떻게 처리할 것인지
  • 다수의 동시 연결을 서버가 어떻게 관리할 것인지
  • 인증 정보와 세션을 어떤 방식으로 연결에 반영할 것인지
  • 특정 이벤트를 누구에게까지 전달할 것인지
  • 일시적인 네트워크 단절 이후 이벤트 유실을 어떻게 다룰 것인지

즉, WebSocket은 “실시간이라서 무조건 좋다”가 아니라, 서버가 먼저 알려야 하는 이벤트가 실제로 존재하고, 그 비용과 복잡도를 감수할 가치가 있을 때 선택해야 하는 기술입니다.

6. SyncMon에서는 왜 가치가 있었는가

SyncMon에서는 그 가치가 분명했습니다.

이 시스템에서 가장 중요한 것은 이상 상황을 가능한 빨리 운영자에게 전달하는 것입니다. 이벤트를 몇 초 늦게 보여주는 것은 단순 UI 지연이 아니라, 경우에 따라 운영 대응 자체를 늦추는 문제가 될 수 있습니다.

특히 TTS 알림처럼 이벤트 발생 직후 곧바로 반응해야 하는 기능은 요청-응답 기반보다 서버 push 모델이 훨씬 자연스럽습니다. 클라이언트가 계속 “무슨 일 생겼나요?”를 묻는 구조보다, 서버가 “지금 이상이 발생했다”를 즉시 전달하는 구조가 문제 자체에 더 잘 맞기 때문입니다.

결국 SyncMon에서 WebSocket은 부가 기능이 아니라, 이상 징후 전달 시간을 줄이고 운영자의 인지 속도를 높이기 위한 핵심 수단이었습니다.

7. 정리

WebSocket은 모든 웹 서비스에 필요한 기술은 아닙니다.

하지만 서버에서 발생한 이벤트를 클라이언트가 즉시 알아야 하는 시스템에서는 매우 강력한 선택지가 됩니다.

SyncMon에서 WebSocket이 필요했던 이유도 여기에 있습니다.

이상 상황은 서버가 먼저 감지하고,

운영자는 그 사실을 즉시 인지해야 하며,

그 순간 화면 경고와 TTS 같은 반응이 바로 이어져야 했습니다.

이 요구사항을 polling으로 풀면 지속적인 불필요 요청과 전달 지연을 감수해야 합니다. 반면 WebSocket은 연결을 유지한 채 서버가 이벤트를 즉시 전달할 수 있기 때문에, 모니터링 시스템이 요구하는 반응성과 더 잘 맞습니다.

결국 SyncMon에서 WebSocket은 “실시간 통신 기술”이어서 선택된 것이 아니라,

운영자가 장애 징후를 늦지 않게 인지하도록 만들기 위해 가장 자연스러운 통신 모델이었기 때문에 선택된 것입니다.

참고