Signal over Noise

Readium 개발기는 하나의 독서 기록 앱이 만들어지는 과정을 기록한 시리즈다. 단순히 앱 기능을 구현하는 이야기가 아니라, 왜 그런 구조를 선택했는지, 어떤 설계가 무너졌고 어떻게 다시 세워졌는지, 그리고 실제로 앱이 스토어에 올라가기까지 어떤 현실적인 문제들을 마주했는지를 차근차근 따라간다. 이 시리즈는 한 개인이 독서 기록 앱을 직접 만들기로 결심한 순간에서 시작해, 도메인 설계의 붕괴와 재정렬, 세션 기반 기록 모델의 구현, 이벤트 중심 Timeline 구조의 선택 같은 기술적인 고민을 다룬다. 그리고 그 과정에서 자연스럽게 등장한 로컬 우선(Local-first) 아키텍처, 외부 책 메타데이터 API를 보호하기 위한 최소 서버, 그리고 실제 Android와 iOS 앱을 출시하기까지의 경험까지 ..

— 서버 없는 앱을 만들려다 서버를 만들게 된 이유독서 기록 앱을 직접 만들겠다고 마음먹었을 때, 나는 꽤 단순한 그림을 머릿속에 그리고 있었다. 사용자가 책을 읽고, 세션을 기록하고, 그 기록이 타임라인 형태로 쌓여가는 앱. 서버는 굳이 필요 없을 것 같았다. 모든 기록은 개인적인 것이고, 기기 안에만 있어도 충분했기 때문이다. 심지어 그게 더 자연스럽다고 느껴졌다. 독서는 원래 개인적인 활동이고, 독서 기록 역시 누군가에게 공유하기 위해 남기는 것이 아니라 스스로의 시간을 돌아보기 위해 남기는 것이니까.그래서 Readium의 초기 설계는 처음부터 Local-first 방향으로 시작됐다. 핵심 데이터는 서버가 아니라 앱 내부에 저장하고, 네트워크 연결이 없어도 앱은 완전히 동작해야 한다는 원칙이었다. ..

개발자가 세상을 바라보는 방식에는 조금 특이한 점이 있다.어떤 사람들은 인간 관계를 감정으로 이해하고, 어떤 사람들은 철학으로 설명하고, 또 어떤 사람들은 심리학 언어로 풀어낸다. 그런데 개발자는 종종 완전히 다른 방식으로 생각한다. 인간 관계를 시스템으로 본다. 상호작용을 인터페이스로 보고, 오해를 프로토콜 오류처럼 이해하고, 갈등을 일종의 예외 처리 문제로 바라본다.처음 들으면 조금 이상하게 느껴질 수 있다. 인간 관계를 코드로 설명한다는 발상 자체가 어딘가 건조하고 차갑게 들리기 때문이다. 하지만 “What Requests Taught Me About Marriage”라는 글을 읽다 보면 이 비유가 단순한 농담이 아니라는 것을 깨닫게 된다. 글의 저자는 세계에서 가장 유명한 Python HTTP 라..