HUB SOLUTION · EDITORIAL
토토솔루션 실시간 화면, 재연결 뒤 갱신 시각을 언제 바꿀까
토토솔루션 구매자가 실시간 관리자 화면에서 확인할 것은 연결 표시와 데이터 갱신 시각이 함께 움직이는 조건이다. 카지노솔루션을 비교할 때도 이전 수치가 남아 있는 동안 무엇을 확인한 상태인지 구분해야 한다. 이 글은 제공된 MDN 공식 문서를 바탕으로 제안하는 화면 설계와 검수 기준이다. 특정 공급자의 구현이나 시험 결과를 설명하는 글은 아니다.
24초 핵심 요약
글의 핵심을 자막과 도식으로 정리한 자체 제작 설명 영상입니다. 음성은 포함하지 않습니다.
영상 대본 보기
연결과 자료 상태를 분리 연결이 다시 열려도 이전 자료가 남을 수 있습니다. 자료 확인 단계를 따로 표시하도록 요구하세요.
시각의 의미부터 합의 자료 기준 시각과 마지막 확인 시각을 구분하세요. 연결 유지 신호만으로 시각을 바꾸는지 점검합니다.
부분 복구를 드러내기 한 영역이 갱신돼도 다른 영역은 지연될 수 있습니다. 영역별 시각과 상태를 함께 비교하세요.
완료 조건을 검수표에 연결 차단부터 현재 범위의 자료 확인까지 재현을 요청하고, 각 단계의 문구와 시각을 기록하세요.
연결 복구와 데이터 복구를 따로 판정한다
MDN의 WebSocket 문서는 연결이 열리는 open 이벤트와 데이터가 도착하는 message 이벤트를 구분한다. 이를 구매 검수에 적용하면 재연결 직후 정상 문구를 표시할 조건부터 물어볼 수 있다. 연결만 열린 단계, 현재 조회 범위의 자료를 확인하는 단계, 확인된 자료를 화면에 반영한 단계를 각각 정의하도록 제안한다. 복구 완료의 근거는 연결 성공 여부에 더해 표시 자료의 확인 결과까지 포함하도록 합의하자.
허브솔루션 운영 안내는 장애 알림과 로그 관리 기준을 상담 전 확인사항으로 제시한다. 이 설명만으로 화면의 복구 판정 방식이 확인되는 것은 아니다. 가상의 관리자 처리 현황판을 대상으로 공급자에게 연결 중단과 복구를 재현해 달라고 요청하자. 검수표에는 연결 상태, 표시 자료의 기준 시점, 복구 안내를 별도 칸에 적는다. 이전 수치가 남아 있다면 그 수치가 어느 시점의 자료인지 읽을 수 있어야 한다는 요구도 넣는다.
최신 갱신 시각이 가리키는 대상을 정한다
최신 갱신이라는 이름을 쓰기 전에 시각의 정의를 문서로 받자. 원본 자료가 변경된 시각, 브라우저가 자료를 받은 시각, 화면에 반영한 시각 가운데 무엇인지 명시하도록 제안한다. MDN은 message를 데이터 수신 이벤트로 설명하지만, 업무 자료의 시각 의미까지 정해 주지는 않는다. 따라서 단순 수신을 화면 반영으로 취급하지 않도록 하고, 자료 기준 시각과 마지막 확인 시각을 구분할 필요가 있는지도 검토하자.
예를 들어 가상 현황판에 자료 기준 14:20, 마지막 확인 14:23이 표시된다면 두 시각의 차이를 설명할 수 있어야 한다. 재연결 과정에서 연결 유지 신호만 받았다면 자료 확인 시각을 바꾸지 않는 기준을 제안한다. 실제 조회 결과 값이 이전과 같더라도 현재 범위를 다시 확인했다면 확인 시각은 갱신할 수 있다. 시각마다 시간대를 명시하고, 처음부터 자료를 받지 못한 경우에는 현재 시각을 채우는 대신 아직 확인되지 않았다고 표시하도록 요구하자.
참고: [1]
연결됨 표시 옆에서도 지연을 드러낸다
MDN은 navigator.onLine이 네트워크 연결을 판단하는 단서이며, 로컬 네트워크에 연결돼도 인터넷에 접근하지 못할 수 있다고 설명한다. 이를 적용하면 브라우저의 온라인 표시만으로 해당 서비스가 복구됐다고 판정하기 어렵다. 검수에서는 기기의 네트워크 연결 상태와 대상 서비스의 응답 여부를 나누어 확인하자. 원인을 확인하지 못한 상태에서는 서버 장애로 단정하는 대신 갱신 확인이 지연되고 있다는 문구를 제안한다.
자료가 바뀌지 않는 정상적인 구간과 수신이 멈춘 구간을 구별할 방법도 공급자에게 묻는다. 업무별 확인 주기와 지연 판정 시간을 합의하고, 그 시간을 넘겼을 때 마지막 확인 시각 옆에 지연 상태가 나타나는지 살펴보자. 이 시간은 구매자가 정할 요구사항이며 여기서 임의의 성능 기준을 제시하지 않는다. 네트워크 표시가 온라인으로 돌아와도 서비스 응답이 없다면 지연 안내가 유지되는지 별도 시나리오로 확인하도록 제안한다.
참고: [2]
일부 영역만 돌아온 화면을 정상으로 묶지 않는다
WebSocket의 readyState는 연결의 현재 상태를 나타낸다. 이를 현황판 전체의 자료 상태로 해석하지 않도록 하는 것이 이 글의 제안이다. 여러 영역이 하나의 연결을 공유하거나 서로 다른 자료원을 이용하는 구성이라면, 공급자에게 복구 판정 단위를 설명해 달라고 요청하자. 회원 현황과 처리 대기 현황이 함께 있는 가상 화면에서는 각 영역의 마지막 확인 시각과 지연 여부를 따로 표시하는 방식을 검토할 수 있다.
검수 예시는 두 영역 중 하나의 자료만 다시 전달하는 상황으로 잡는다. 회원 현황이 갱신돼도 처리 대기 현황은 이전 자료임을 유지하는지 확인하자. 화면 상단에는 일부 갱신 지연처럼 전체 범위를 설명하고 해당 영역에는 구체적인 상태를 두는 방식을 제안한다. 복구 중에는 현재 조회 범위에 맞는 전체 자료를 다시 확인하거나 누락분을 보완하는 절차를 합의하자. 어느 방식을 택하든 범위와 반영 결과를 확인한 뒤 해당 영역을 정상으로 전환하도록 요구한다.
참고: [1]
인수 조건은 끊김부터 복구 완료까지 한 줄로 연결한다
허브솔루션 운영 안내가 제시하는 유지보수와 긴급 대응 항목을 구체화하려면 복구 상태표를 산출물로 요청하는 편이 좋다. 상태표에는 진입 조건, 안내 문구, 유지할 자료, 시각 변경 조건, 종료 근거를 적도록 제안한다. 자동 재연결을 제공한다면 재시도 중인지와 언제 수동 확인이 필요한지도 명시하자. MDN의 연결 이벤트 설명은 이런 업무 정책을 대신 정하지 않으므로 제공 범위와 인수 기준은 별도로 합의해야 한다.
공급자가 허용한 검수 환경에서 정상 수신, 연결 차단, 연결만 복구, 일부 자료 반영, 현재 범위 확인 완료 순서를 요청하자. 각 단계에서 표시 문구와 시각이 합의한 조건에 맞게 변하는지 기록한다. 복구 중 다른 조회 범위를 선택하는 경우에는 이전 범위의 응답으로 완료 표시가 바뀌지 않는지도 확인 대상으로 넣는다. 결과물에는 재현 조건, 기대 상태, 관찰 상태, 증거 위치를 남기고 재현하지 못한 단계는 미확인으로 적어 후속 확인 담당자를 정하자.
참고자료 및 출처
아래 공식 문서와 사이트 안내를 참고해 작성한 설명입니다. 검수 시나리오와 체크리스트는 이를 적용한 제안이며, 실제 제품 테스트 결과를 뜻하지 않습니다.
- WebSocket - Web APIs | MDN자료 확인: 2026-09-13
- Navigator: onLine property - Web APIs | MDN자료 확인: 2026-09-13
- 토토솔루션 운영 | 안정성·유지보수 안내자료 확인: 2026-09-13