실시간 번역 업데이트는 유용해야지, 필수여서는 안 됩니다

대기 중에서 작업 중으로, 다시 준비 완료로 바뀌는 번역 상태를 지켜보는 것은 유용합니다. 팀은 새로고침 없이 진행 상황을 확인하고, 완료된 작업을 빠르게 열어보며, 릴리스가 아직 진행 중일 때 실패한 요청을 알아차릴 수 있습니다.

하지만 실시간 업데이트는 표시 기능입니다. 워크플로를 올바르게 만드는 메커니즘이 되어서는 안 됩니다.

내구성 있는 상태가 우선입니다

데이터베이스와 작업 시스템이 번역 상태를 관리해야 합니다. 브라우저가 연결되어 있든 아니든, 모든 단계 전환은 기록되어야 합니다:

• 요청 대기열 등록
• 번역 시작 및 완료
• 푸시 시작 및 완료
• 게시 시작 및 완료
• 실패 및 재시도 이벤트

실시간 이벤트는 그 내구성 있는 변경을 알릴 수 있습니다. 변경이 발생했다는 유일한 기록이어서는 안 됩니다.

이 구분은 탭을 닫았거나, 네트워크 접근을 잃었거나, websocket 인프라가 비활성화된 환경에서 작업하는 사용자를 보호합니다.

실시간 기능에는 운영 비용이 있습니다

브로드캐스팅은 더 많은 구성 요소를 추가합니다: websocket 서비스, 연결 권한 부여, 채널 구성, 프록시 지원, 그리고 브라우저 재연결 동작입니다.

실시간 협업이 필요한 팀에게는 그 비용이 충분히 가치 있을 수 있습니다. 더 작은 배포 환경에서는 일반적인 폴링이 더 단순하고 완전히 충분할 수 있습니다.

실시간 기능을 선택적으로 사용하도록 하면, 각 환경이 핵심 번역 동작을 잃지 않으면서도 자신이 지원할 수 있는 운영 프로필을 선택할 수 있습니다.

우아한 대체 경로를 설계하세요

UI는 실시간 이벤트를 통해서든 주기적 새로고침을 통해서든 동일한 최종 상태에 도달해야 합니다.

실용적인 접근 방식은 다음과 같습니다:

1. 현재의 내구성 있는 상태를 불러옵니다
2. 실시간 기능이 활성화된 경우 관련 이벤트를 구독합니다
3. 요청 ID와 버전을 기준으로 들어오는 업데이트를 병합합니다
4. 활성 작업이 남아 있는 동안 적당한 간격으로 폴링합니다
5. 배치가 종료 상태에 도달하면 빈번한 폴링을 중지합니다

실시간 기능은 화면을 즉각적으로 느껴지게 합니다. 폴링은 재연결 후의 공백을 메우고 대체 수단을 제공합니다.

두 경로가 서로 경쟁하는 상태 규칙을 만들어서는 안 됩니다.

업데이트를 소음으로 만들지 마세요

모든 내부 이벤트가 인터페이스에 들어가야 하는 것은 아닙니다. 모든 토큰, 워커 하트비트, 또는 중간 저장을 브로드캐스트하면 페이지가 불안정해지고 인프라 부하가 증가할 수 있습니다.

사용자에게는 보통 의미 있는 단계 전환과 갱신된 개수가 필요합니다. 빠르게 발생하는 저수준 변경을 더 적은 수의 내구성 있는 이정표로 묶으면 경험이 차분하고 훑어보기 쉬워집니다.

같은 원칙은 알림에도 적용됩니다. 완료된 배치는 주의를 끌 만합니다. 완료된 모든 로캘은 아마 그렇지 않을 것입니다.

조용한 경로를 테스트하세요

실시간 기능을 활성화한 상태로 테스트하고, 대체 경로도 작동한다고 가정하기 쉽습니다. 신뢰성을 위해서는 오히려 반대 연습이 필요합니다:

• 브로드캐스팅 비활성화
• 다중 로캘 배치 시작
• 페이지를 떠났다가 다시 돌아오기
• 진행 상황이 따라잡는지 확인
• 실패한 요청 재시도
• 최종 개수와 사용 가능한 작업 검증

이 경로가 작동한다면, 실시간 기능은 숨겨진 의존성이 아니라 향상 기능이 됩니다.

핵심 요점

실시간 업데이트는 내구성 있는 상태 위에 놓일 때 번역 작업을 개선합니다.

먼저 모든 전환을 기록하고, 브로드캐스팅을 구성 가능하게 만들며, 절제된 폴링 대체 경로를 유지하세요. 가장 즉각적인 전달 채널을 사용할 수 없을 때에도 워크플로는 계속 신뢰할 수 있어야 합니다.