PhaseLock가 입력 직후 화면을 갱신하는 방법을 제시했다

사용자가 입력창을 고치고 엔터를 누르면 글자가 원래 값으로 돌아갔다가 반 초 뒤 새 값으로 바뀐다. 동기화 엔진을 쓰는 앱에서 낙관적 업데이트를 처리하지 못하면 이런 깜박임이 편집할 때마다 생긴다.

PhaseLock는 서버 상태를 앱에 동기화하는 엔진으로, 클라이언트가 편집 결과를 먼저 화면에 반영하고 서버의 확정 결과를 기다리는 방식을 설명했다. 웹·모바일 앱과 백엔드에서 같은 동기화 엔진을 쓰려는 개발자에게 관련된 접근이다.

PhaseLock는 어떤 방식으로 동기화하나?

이벤트 로그는 상태를 바꾼 사건을 기록하는 방식이다. 이를 일기장에 빗대면 이해하기 쉽다. 로그를 복제하고 리듀서(reducer, 이벤트를 적용해 현재 상태를 만드는 함수)를 실행해 상태를 구성한다. 리듀서는 서버와 클라이언트 양쪽에서 실행된다.

PhaseLock에는 명령을 처리하는 함수가 두 종류 있다. precommit은 서버에서 현재 상태를 바탕으로 명령을 처리해 이벤트를 만들고, reducer는 그 이벤트를 적용해 상태를 갱신한다.

편집 결과를 어떻게 먼저 보여주나?

PhaseLock가 소개한 세 번째 함수는 forecast다. 이는 클라이언트에서 실행되는 precommit의 짝으로, 클라이언트가 보는 상태만 바탕으로 예상 이벤트를 만든다. 예상 이벤트는 서버가 최종적으로 만드는 이벤트와 다를 수 있다.

명령을 처리할 때는 명령을 보낼 권한이 있는지 확인하는 일과 어떤 이벤트를 만들지 결정하는 일이 필요하다. forecast는 이벤트 생성만 맡는다. precommit은 권한을 확인한 뒤 보통 forecast를 호출하므로, 기존 업무 로직을 분리해 활용할 수 있다는 것이 PhaseLock의 설명이다.

처리 흐름은 다음과 같다.

1. 사용자의 동작에서 명령을 만든다.
2. forecast가 예상 이벤트를 만들고, 리듀서가 이를 오버레이에 적용한다. 화면에는 예상 상태가 나타난다.
3. 서버의 precommit이 확정 이벤트를 만들어 로그에 저장한다.
4. 저장된 이벤트가 클라이언트에 도착하면 리듀서가 클라이언트 저장소에 적용한다.
5. 기존 오버레이와 이에 대응하는 예상 이벤트를 버린다. 화면은 확정된 상태를 반영한다.

흐름 그림

여러 명령이 처리 중이거나 서버에서 관련 없는 이벤트가 도착하면, 기존 오버레이를 버리고 갱신된 클라이언트 상태와 아직 처리 중인 명령으로 예상 이벤트를 다시 만든다. 새 오버레이를 구성해 화면을 갱신한다. 오프라인 상태도 네트워크가 매우 느린 상황처럼 다룰 수 있어, 사용자의 편집 결과를 먼저 화면에 반영하는 흐름이 이어진다.

충돌과 되돌리기는 어떻게 처리하나?

PhaseLock에서는 서버가 들어온 명령을 하나씩 순서대로 처리하며 적용하거나 거부한다. 클라이언트는 최신으로 알고 있는 서버 상태를 기준으로 forecast를 실행해 처리 중인 명령의 결과를 예측한다. 명령이 거부돼도 화면 전체를 되돌리는 대신 오버레이를 버리고 다시 구성한다.

개발자는 각 명령이 현재 상태에서 어떤 이벤트를 만들지 정의한다. PhaseLock가 이를 바탕으로 서버와 클라이언트의 동기화 흐름을 처리한다는 것이 제품 설명의 핵심이다. 이 방식이 필요한 앱을 만든다면 기존 precommit의 권한 확인과 이벤트 생성 로직을 어떻게 나눌지 살펴볼 만하다. 원문은 PhaseLock의 가격, 지원 범위, 성능 측정 결과나 forecast와 서버 결과가 달라지는 경우의 구체적 처리 조건을 밝히지 않는다.