기기 간 동기화 : 언제 어디서든 Focus Together!

이전 글에서 소셜 로그인 구현을 다루었다.

구글 로그인 : 기기 간 동기화를 위한 소셜 로그인

 

이번 글에서는 소셜 로그인을 기반으로 기기 간 동기화 구현과 배운 것을 다루어보겠다.

 

앞선 글에서 나는 '내 기록을 한곳에서 모아볼 수 없는 것'은 치명적이라고 말했다. 특히, 내가 가장 크게 불편을 느끼고 있었다. 내가 원하는 모습은 데스크탑 브라우저에서 집중할 작업을 시작하고, 이후에 이동 중 모바일 기기를 통해 작업을 종료 및 새로운 작업을 시작하는 것이었다.

 

지난 시간, 소셜 로그인을 구현했기 때문에 이제 어떤 기기에서도 자신의 계정으로 로그인할 수가 있다. 하지만 A라는 기기에서 작업을 시작한 것이 B라는 기기에 표시되지는 않았다. 로그인만 되었다 뿐이지 데이터를 실시간으로 공유하지는 못하기 때문이다. 

 

즉, 언제 어디서든 FocusTogether을 사용하려면 '기기 간 실시간 동기화'는 필수적이었다.

 

 

동기화하려면

기기 간 동기화를 하려면 먼저 어떤 방법으로 이를 구현할지 고민해야했다. 이전에 실시간 동기화를 작업해 본 적은 없었지만 직전에 Supabase의 Realtime 기능을 경험했기에 이를 활용해 보기로 했다.

 

Supabase의 Realtime은 Broadcast와 Presence 등을 통해 메시지나 데이터 변경 사항에 대한 실시간 동기화 기능을 제공한다. (자세한 내용은 공식문서를 참고)

 

대략적인 동기화 흐름은 다음과 같다.

1) 사용자(클라이언트)는 DB에 데이터를 추가한다. (작업 생성)

2) DB에 데이터가 추가되면 트리거 함수가 동작하고 sync_signals 테이블에 이벤트를 기록한다.

3) sync_signals 테이블에 데이터가 변경되면 Realtime이 이를 감지하여 이벤트를 발행한다.

4) 이벤트를 수신받은 사용자(클라이언트)는 화면을 업데이트하여 사용자에게 동기화된 정보를 제공한다.

 

이때, sync_signals 테이블에는 하나의 계정이 하나의 Row만 가지도록 했다. 그리고 변경사항이 일어날 떄마다 해당 Row를 수정하고 버전을 높여 최신 버전만 유지하도록 했다.

 

이렇게 한 이유는 만약 모든 변경 이벤트를 누적하여 기록하면 데이터양과 조회에 드는 비용이 크게 높아진다고 생각했다. 사용자(클라이언트)는 자신의 버전과 서버의 버전이 일치하는지만 확인하고 일치하지 않을 때에만 데이터를 갱신하면 된다.

 

 

실시간 동기화 성공

실제로 잘 동작하는지 보자. 

 

오른쪽 브라우저에서 작업을 종료하면 왼쪽 브라우저에서도 종료가 되는 것을 볼 수 있다. 이제 한 곳에서 수정을 하면 동일한 계정으로 로그인된 다른 곳에서도 동일한 최신 데이터를 받아 볼 수 있게 되었다!

 

하지만 아직 문제가 남아있다. 바로 속도..! 위의 이미지를 보면 느껴지겠지만 동기화하는데 몇 초간의 딜레이가 생긴다. 이때 다른 브라우저에서 다른 작업을 한다면? 데이터가 충돌이 나고 꼬일 것이다.

 

그나마 다행스러운 점은 FocusTogether 서비스를 정상적으로 사용하는 사용자라면 굳이 여러 브라우저를 켜고 다중 작업을 하진 않을거라는 점이다. 물론 이것은 이상적인 상황이고 결국 사용자에게만 기대할 수 없으므로 이 문제를 앞으로 해결해 나가야 한다.

 

 

 

작업 후기

계정을 전환하고 실시간 동기화를 구현하기 까지 다양한 변수가 있었다. 이들을 테스트하는데 꽤나 오래 걸렸는데 아직도 문제가 계속 튀어나오고 있는 상황이다.

 

처음에는 서버에 데이터를 저장하고 호출하는 단일화 방식을 고려했었는데 생각보다 응답 속도가 느렸다. 아무래도 로컬에서 데이터를 함께 다루는 편이 속도면에서 더 빠르고 사용이 쾌적했다. 때문에 서버와 로컬에서 데이터를 함께 다루고 정합성을 위해 백그라운드에서 비동기로 통신하다 보니 복잡도가 높아졌다. 여기서 버그나 사이드 이펙트가 많이 발생하고 있어서 고생을 하고 있다.. 흠...

 

이 과정에서 테스트 코드의 필요성을 느꼈고 TDD 방식으로 개발하기 시작했다. TDD란, '테스트 주도 개발'이라는 의미로 코드를 작성하기 전에 먼저 테스트 케이스를 작성하고, 이 테스트를 통과하는 코드를 작성한 뒤, 다시 코드를 개선하는 개발 방식이다.

 

그럼 왜 TDD를 하는가? 의문이 들 수 있는데 TDD는 크게 다음 세 가지의 이점을 가진다.

1. 요구사항을 정확히 구현할 수 있다는 점.
2. 실패에 대한 피드백이 굉장히 빠르다는 점.
3. 한 번 개발하면 마음 놓고 잠들 수 있다는 점.

 

물론 TDD가 만능은 아니고 엣지 케이스가 나오기도 하지만(그래서 새로운 문제를 만날 때마다 테스트를 보강해야 한다) 기본적으로 안정감 있게 개발을 할 수 있다. 서비스가 커지면 커질수록 변경에 대한 사이드 이펙트의 부담이 커지는데 테스트 코드의 수만큼 이를 예방할 수 있다는 것도 큰 장점이다. 

 

당신도 함께 집중하고 싶다면?👇

https://www.focustogether.live/