처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.06.08 54

리니어(Linear)는 왜 이렇게 빠를까? '로컬 우선' 아키텍처의 비밀을 파헤쳐봤어요

Hacker News 원문 보기
리니어(Linear)는 왜 이렇게 빠를까? '로컬 우선' 아키텍처의 비밀을 파헤쳐봤어요

클릭하면 '즉시' 반응하는 그 느낌

프로젝트 관리 툴 한 번이라도 써본 분들은 아실 거예요. 이슈 하나 누르면 화면이 잠깐 멈췄다가 빙글빙글 로딩 돌고 나서야 내용이 뜨는 그 답답함이요. 그런데 Linear(리니어)라는 협업 툴을 써보면 느낌이 완전히 달라요. 이슈를 클릭하든, 보드를 휙휙 넘기든, 필터를 걸든 거의 '딜레이가 없다'는 느낌을 받거든요. 마치 웹 앱이 아니라 옛날 데스크톱 프로그램을 쓰는 것 같은 즉각적인 반응이죠.

이게 단순히 서버가 빨라서가 아니에요. 아예 설계 철학 자체가 다릅니다. 오늘은 Linear가 도대체 무슨 마법을 부려서 이렇게 빠른지, 그 핵심 아이디어를 주니어 분들도 이해할 수 있게 천천히 풀어볼게요.

핵심은 '로컬 우선(Local-first)' 이라는 발상

보통 웹 앱은 이렇게 동작해요. 내가 버튼을 누르면 → 서버에 '이 데이터 주세요' 요청을 보내고 → 서버가 데이터베이스를 뒤져서 → 결과를 돌려주면 → 그제서야 화면에 그려줍니다. 이 왕복(round-trip) 과정에서 네트워크 지연이 무조건 생기죠. 한국에서 미국 서버를 쓰면 한 번 왕복에 200~300ms는 우습게 깨져요.

Linear는 이 발상을 뒤집었어요. 데이터를 서버에서 매번 받아오는 게 아니라, 처음 앱을 켤 때 내 작업 공간 데이터를 통째로 브라우저 안에 내려받아 둡니다. 이게 뭐냐면, 브라우저에는 IndexedDB라는 작은 데이터베이스가 내장돼 있는데(쉽게 말해 브라우저 안에 들어있는 미니 DB예요), 여기에 내 이슈, 프로젝트, 댓글 같은 걸 미리 저장해두는 거죠. 그래서 한 번 켜고 나면 이후의 모든 조회는 서버까지 갈 필요 없이 내 컴퓨터 메모리 안에서 즉시 처리됩니다. 필터링이든 정렬이든 검색이든 전부 로컬에서 일어나니까 0에 가까운 속도가 나오는 거예요.

'낙관적 업데이트'와 동기화 엔진

그럼 데이터를 수정하면 어떻게 될까요? 여기서 두 번째 핵심이 나옵니다. 바로 낙관적 업데이트(optimistic update) 예요. 이게 뭐냐면, '어차피 성공할 거니까 일단 화면부터 바꿔놓자'는 전략이에요. 내가 이슈 상태를 '진행 중'으로 바꾸면, 서버 응답을 기다리지 않고 화면을 즉시 바꿔버려요. 그리고 뒤에서 조용히 서버에 '이거 바뀌었어요'라고 알려주죠. 사용자 입장에선 0.3초의 기다림조차 사라지는 거예요.

이때 모든 변경 사항은 작은 단위의 트랜잭션(거래 기록) 으로 차곡차곡 쌓입니다. 마치 통장 거래 내역처럼요. 이 기록들은 WebSocket(서버와 계속 연결을 열어두고 실시간으로 데이터를 주고받는 통신 방식)을 통해 서버와 양방향으로 동기화돼요. 중요한 건 전체 데이터를 다시 주고받는 게 아니라, 바뀐 부분(델타)만 오간다는 점이에요. 그래서 동료가 같은 이슈를 수정해도 거의 실시간으로 내 화면에 반영되고, 잠깐 인터넷이 끊겨도 로컬에 쌓아둔 변경 사항을 나중에 한꺼번에 밀어 넣어 충돌 없이 맞춰줍니다.

업계 흐름에서 보면

Notion, Jira, Asana 같은 전통적인 툴들은 대부분 '서버 왕복' 방식에 기대고 있어요. 그래서 무겁고 느리다는 평을 종종 듣죠. 반면 Linear는 Figma나 Superhuman 같은 'local-first' 진영에 속합니다. 이 흐름의 뿌리에는 CRDT(여러 사람이 동시에 편집해도 자동으로 충돌을 해결해주는 자료구조)라는 연구가 있고, 요즘은 Replicache, ElectricSQL, RxDB 같은 오픈소스 동기화 엔진들이 이런 패턴을 누구나 쓸 수 있게 만들어주고 있어요. Linear는 이걸 자체 엔진으로 정교하게 다듬어서 제품화한 대표적인 성공 사례인 셈이죠.

한국 개발자에게 주는 시사점

사내 어드민이나 대시보드, 협업 툴을 만드는 분이라면 이 패턴은 정말 배워둘 가치가 있어요. 매번 API를 때리는 구조에 익숙하다면, '데이터를 클라이언트에 미리 캐싱해두고 메모리에서 처리한다'는 발상 전환만으로도 체감 속도가 확 달라지거든요. 다만 동기화 엔진을 처음부터 직접 짜는 건 충돌 처리, 오프라인 큐잉 등 난이도가 꽤 높으니, 처음엔 TanStack Query의 낙관적 업데이트나 Replicache 같은 검증된 라이브러리로 작게 시작해보길 추천해요. 작은 화면 하나라도 'local-first'로 만들어보면 사용자 반응이 확 달라지는 걸 느끼실 거예요.

마무리

한 줄로 정리하면, Linear의 속도는 서버가 빨라서가 아니라 '서버를 거의 안 거치기 때문' 이에요. 데이터를 미리 가져와 로컬에서 처리하고, 변경은 일단 화면부터 반영한 뒤 뒤에서 동기화하는 거죠.

여러분은 지금 만드는 서비스에 이런 로컬 우선 구조를 도입할 수 있을 것 같나요? 아니면 우리 서비스 특성상 서버 왕복이 꼭 필요한 부분이 있다면, 어디서 타협점을 찾는 게 좋을까요? 댓글로 같이 이야기해봐요.


🔗 출처: Hacker News

이 뉴스가 유용했나요?

TTJ 코딩클래스 정규반

월급 외 수입,
코딩으로 만들 수 있습니다

17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.

144+실전 강의
17개수익 모델
4.9수강생 평점
정규반 자세히 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.