새로운 브라우저 탭을 여는 것이 마치 길들여지지 않은 야생마를 풀어놓는 듯했던 날들을 기억하는가? 각 탭은 자기주장만 할 뿐, 다른 탭들은 안중에도 없었다. 우리는 localStorage를 통한 속삭임, BroadcastChannel을 통한 필사적인 신호 보내기 등 복잡한 시스템을 짜 맞추며, 오직 하나의 탭만이 주목받도록 강제하려 애썼다. 그것은 개발자라면 누구나 거쳐야 하는 통과의례이자, 실제보다 훨씬 복잡하게 느껴졌던 퍼즐이었다.
그리고 오랫동안, 그것이 당연한 방식이었다. 주어진 것이었고, 불가피한 악이었다. 우리는 낡은 데이터나 악명 높은 경쟁 조건(race condition)이라는 무게에 짓눌려 무너질까 두려워하며, 조악하고 수동적인 조정 시스템을 구축해야 한다고 예상했다. 액티브 탭이 희망적으로 닫혔음을 신호하기 위해, 악명 높은 불안정성의 유령 같은 이벤트인 beforeunload를 영리하게 사용했다고 스스로를 칭찬하기도 했다.
하지만 만약 브라우저 자체가 이미 우리를 위해 정교한 잠금 및 대기열 시스템을 갖추고 있었고, 우리가 그것을 활용하기만을 조용히 기다리고 있었다고 말한다면? 우리가 해왔던 그 지저분하고 불안정한 JavaScript 춤이 사실은 바퀴를, 그것도 형편없이 재발명하는 것이었다고 말한다면?
핵심은 이것이다. Web Locks API는 단순히 개발자의 도구함에 추가되는 또 하나의 도구가 아니다. 그것은 근본적인 플랫폼의 변화다. 마치 손으로 우물을 파고 있었는데, 이미 압력이 가해져 준비된 지하수가 바로 발밑에 있었다는 것을 발견한 것과 같다. 이 API는 멀티 탭 상호작용에 마침내 안정을 가져오고, 잠재적인 악몽을 우아하고 브라우저가 관리하는 발레로 바꿔놓는 조용한 천재다.
탭 금기의 시대는 끝났는가?
수년간 개발자들은 ‘싱글 액티브 탭’ 문제로 씨름해 왔다. 목표는 다음과 같았다: 잠재적으로 수십 개의 열린 동일 애플리케이션 탭 중에서 오직 하나만이 요청을 능동적으로 처리하거나 동적 콘텐츠를 표시하도록 보장하는 것. 나머지는 정중하게 잠긴 상태로, 차례를 기다려야 했다. 이는 미적인 문제뿐만 아니라, 데이터 손상을 방지하거나 일관된 사용자 경험을 보장하기 위한 필수 요건인 경우가 많았다.
우리는 고심해서 로직을 만들었다. 먼저 각 탭에 대한 고유 식별자 – 디지털 지문. 그런 다음, 보통 localStorage인 중앙 진실의 원천에 ‘이 탭이 보스다!’라고 선언했다. 새 탭은 도착해서 localStorage를 확인하고, 이미 보스 탭이 선언되어 있다면 정중하게 물러나 잠겼다. 보스 탭을 닫는 것은? 신경 곤두서는 순간이었고, 다른 탭들이 올바르게 바통을 이어받기를 바라며 이벤트를 트리거했다. 그것은 통제된 혼돈의 연습이었다.
우리는
localStorage를 통한 속삭임,BroadcastChannel을 통한 필사적인 신호 보내기 등 복잡한 시스템을 짜 맞추며, 오직 하나의 탭만이 주목받도록 강제하려 애썼다.
원본 내용에서 지적하듯이, localStorage 솔루션은 기본적인 잠금에는 기능했지만 실제 세계에 직면하면 무너졌다. 브라우저 재시작 후에도 낡은 데이터가 지속되었고, 두 탭이 동시에 열리면서 둘 다 자신이 선택되었다고 생각하는 경쟁 조건은 여전히 우리의 끈질긴 골칫거리였다. BroadcastChannel은 탭 간에 더 직접적인 통신 경로를 제공했지만, 누가 능동적이 될 수 있는지를 안정적으로 관리하는 핵심 문제는 해결하지 못했다.
브라우저의 비밀 무기 투입: Web Locks
Web Locks API의 아름다움은 단순함과 견고함에 있다. 공유 리소스에 대한 동시 액세스를 처리하기 위해 브라우저의 내부 메커니즘을 활용한다. 이 시나리오에서 애플리케이션 자체가 공유 리소스다.
탭이 열리면 특정 이름(예: 'dev:app')을 사용하여 잠금을 요청하기만 하면 된다. 다른 탭이 현재 해당 잠금을 보유하고 있지 않으면, 요청한 탭이 잠금을 획득하고 ‘액티브’ 탭이 되어 진행할 수 있다. 다른 탭이 이미 잠금을 보유하고 있다면, 새 탭은 자동으로 대기열에 배치되어 인내심 있게 기다린다. 마치 독점 클럽의 벨벳 로프처럼, 검문소(브라우저)가 관리하는 것과 같다.
이것은 이러한 지저분한 엣지 케이스들을 우아하게 피해 간다:
- 다음 액티브 탭: 현재 액티브 탭이 닫히면, 브라우저는 자동으로 잠금을 해제한다. 대기열의 다음 탭이 자동으로 잠금을 획득하여 액티브가 된다. 수동 선택 과정도, 복잡한 정렬 배열도 필요 없다. 브라우저가 인수인계를 처리한다.
- 낡은 액티브 탭: 잠금은 브라우저에 의해 관리되며
localStorage처럼 사용자에게 접근 가능한 방식으로 상태를 유지하지 않기 때문에 낡은 데이터 걱정이 없다. 브라우저가 예기치 않게 닫히면, 브라우저 프로세스가 종료될 때 잠금이 해제된다. 다시 열면, 가장 먼저 잠금을 요청하는 탭이 액티브가 된다. 깔끔하다. - 경쟁 조건: Web Locks API가 진정으로 빛을 발하는 부분이다. 브라우저의 내부 대기열 시스템은 본질적으로 경쟁 조건을 방지한다. 한 번에 하나의 탭만 잠금을 획득할 수 있다. 두 탭이 동시에 요청하면, 하나가 잠금을 얻고 다른 하나는 차례를 기다린다. 결정론적이다.
이것은 엄청난 단순화다. 상태를 관리하고, 메시지를 브로드캐스트하고, 불안정한 이벤트를 처리하기 위해 페이지에 달하는 JavaScript를 작성하는 대신, 개발자는 이제 이러한 종류의 조정을 위해 정확히 설계된 브라우저 네이티브 API에 의존할 수 있다. React의 useEffect 훅 안에 있는 몇 줄의 코드 스니펫은 이 전체 패러다임 전환을 요약한다.
const [active, setActive] = useState(false);
useEffect(() => {
navigator.locks.request("dev:app", () => {
setActive(true);
});
}, []);
if (!active) {
return <div>This tab is not available</div>;
}
return <div>This tab is available</div>;
그리고 바로 이처럼, 브라우저는 무거운 작업을 대신 처리한다. 우리가 한때 씨름했던 복잡성은 이제 우리 애플리케이션이 실행되는 바로 그 환경에서 관리된다.
웹 애플리케이션을 위한 패러다임 전환
이것은 단지 하나의 탭을 활성화하는 것에 관한 것이 아니다. 그 의미를 생각해 보라. 애플리케이션의 단일 인스턴스만 특정 시점에 중요한 작업을 수행해야 하는 모든 시나리오는 이제 이 API로 처리될 수 있다. 중요한 데이터 업데이트를 동기화하든, 탭 간 중복 폼 제출을 방지하든, 백그라운드 작업을 관리하든, Web Locks API는 강력한 멀티 탭 애플리케이션을 위한 기반을 제공한다.
수년 동안 우리는 복잡한 미들웨어를 구축하며 혼란스러운 환경에 질서를 부여하려 했다. 이제 브라우저가 우리에게 배관을 제공하고 있다. 때로는 가장 우아한 해결책이 더 많은 코드가 아니라, 기본 플랫폼을 더 효과적으로 이해하고 활용하는 것임을 상기시켜 준다. 이것이 진정한 플랫폼 전환의 느낌이다: 갑자기 불가능했던 것이 사소해지고, 웹 애플리케이션의 미래가 조금 더… 합리적으로 느껴진다.
🧬 관련 인사이트
자주 묻는 질문
Web Locks API란 정확히 무엇인가요?
Web Locks API는 웹 애플리케이션이 명명된 잠금을 획득하고 해제할 수 있도록 하는 브라우저 기능입니다. 이 메커니즘은 경쟁 조건을 방지하고, 코드의 단일 조각(또는 이 경우 탭)만이 한 번에 중요 섹션을 실행하여 공유 리소스에 대한 액세스를 관리할 수 있도록 합니다. 서로 다른 브라우저 탭과 창 간의 활동을 조정하도록 설계되었습니다.
이것이 프론트엔드 개발자로서 제 일자리를 대체하나요?
절대 아닙니다! Web Locks API는 복잡한 탭 조정 작업을 자동화하지만, 숙련된 개발자의 필요성을 대체하지는 않습니다. 여전히 사용자 인터페이스를 디자인하고, 기능을 구현하고, 애플리케이션 상태를 관리하고, Web Locks와 같은 API를 애플리케이션에 효과적으로 통합하는 방법을 이해해야 합니다. 이 도구는 특정 복잡한 작업을 훨씬 더 쉽고 안정적으로 만들어, 더 창의적이고 영향력 있는 개발에 집중할 수 있도록 해줍니다.
Web Locks API 사용에 단점은 없나요?
주요 고려 사항은 브라우저 지원입니다. 최신 브라우저는 Web Locks API를 널리 지원하지만, 이전 버전은 지원하지 않을 수 있습니다. 개발자는 호환성을 보장하거나 이를 지원하지 않는 환경에 대한 우아한 폴백을 구현해야 합니다. 또한, API의 대기열 동작 및 잠금 해제 메커니즘을 이해하는 것이 진정으로 강력한 애플리케이션을 구축하는 데 중요합니다.
