서버 속도는 빠른데, 왜 앱은 답답할까?
Design-First Software Engineering 시리즈 2탄
이 글은 세계적으로 영향력 있는 기술 뉴스레터이자 팟캐스트인 Pragmatic Engineer의 에피소드 Design-First Software Engineering 을 바탕으로, 실무 AI 엔지니어의 시선에서 재해석한 글입니다. 팟캐스트에서 다룬 핵심 내용을 요약하고, 현업에서 겪은 고민과 소회를 함께 나눕니다.
감각을 지키기 위한 구조 설계의 선택들
Craft는 애초부터 Local-first 구조를 선택했습니다.
검색 인덱스도, 텍스트 데이터도 대부분 로컬에 저장되고 연산됩니다. 그 이유는 단 하나입니다.
“반응이 빠르기 위해서가 아니라, 느낌이 즉각적이기 위해서입니다.”
이 글에서는 Craft가 왜 로컬 퍼스트를 선택했는지,
어떻게 3~4명의 앱 개발자가 수백만 사용자를 위한 앱을 유지하는지,
그리고 작은 팀이 복잡한 소프트웨어를 만들기 위한 구조적 전략은 무엇이었는지 살펴봅니다.
모든 것이 로컬에 있다는 감각
Craft는 사용자의 모든 데이터를 기기에 저장합니다. 검색도, 편집도, 대부분의 상호작용이 클라우드가 아닌 로컬에서 실행됩니다. 이는 단순히 오프라인 지원이 아니라, 다음과 같은 감각을 설계하기 위함입니다:
즉각 반응하는 느낌
데이터가 내 손 안에 있다는 안정감
“내가 이 앱을 온전히 통제하고 있다”는 주도감
Balint는 이렇게 말합니다:
“클릭 후 10ms가 아니라 2ms만에 반응하는 경험을 만들기 위해, 시스템 전체 구조를 다르게 가져가야 했어요.”
AI 비전 시스템에서의 실무 경험
제가 비전 시스템을 설계할 때, 모델의 정확도보다 예측값이 얼마나 빠르게 전달되는지가 더 중요한 경우를 여러 번 경험했습니다.
“정확하지만 2초 걸리는 결과”보다 “조금 부정확해도 즉시 보이는 결과”가 사용자에게 훨씬 더 신뢰를 준다는 것을 실감했습니다.
Craft가 Local-first를 선택한 이유도 여기에 있다고 생각합니다.
빠른 것이 아니라, 즉각적인 감각을 위한 구조 설계.
검색 인덱스를 사용자마다 따로 관리한다는 것
Craft는 200만 명의 사용자 각각에 대해 개별 검색 인덱스를 운영합니다.
거대한 엘라스틱서치 클러스터 하나가 아니라, 유저마다 파일 단위로 분리된 인덱스를 갖는다는 뜻이죠.
이는 서버 비용이나 성능 최적화 관점에서 보면 이상해 보일 수 있지만, 아래와 같은 장점이 있습니다.
사용자의 데이터가 완전히 독립적으로 관리됨
인덱스를 로컬로 내려받아 클라이언트에서 실행 가능
백엔드와 프론트엔드 아키텍처의 일관성 확보
작은 팀이 복잡한 앱을 만드는 구조
Craft의 앱 팀은 단 3~4명. 그런데도 전 세계 수백만 사용자의 요청을 처리하는 앱을 유지합니다.
그 이유는 아래과 같은 구조 덕분입니다.
기능 중심이 아니라 플랫폼 중심 팀 구성
코드의 모든 요소를 자체적으로 그리는 설계 철학
성능보다 감각 중심의 최적화
이 구조는 저에게도 익숙합니다.
작은 팀이 빠르고 유연하게 일하려면, 서로가 서로의 코드를 이해하고, 전체 흐름을 파악하는 구조여야 했습니다. 기능을 나누기보다, 맥락을 공유하는 팀 구조가 더 중요했던 경험이 떠올랐습니다.
우리는 어떻게 구조를 설계해야 하는가?
이 에피소드를 통해 저는 다시 이런 질문을 던지게 됩니다:
사용자의 감각을 위해, 지금의 시스템 구조는 어떤 제약을 주고 있는가?
데이터가 클라우드에만 있을 필요가 있는가?
기능보다 중요한 ‘느낌’을 지키기 위해, 어떤 구조를 재설계해야 할까?
다음 편에서는 Craft가 어떻게 디자인과 개발의 경계를 허물며,
"코드로 감정을 설계하는 문화"를 만들어왔는지 이야기해보려 합니다.
