Readium 개발기 #6 — 서버를 없애려다, 경계를 만들게 되었다
서버를 만들지 않으려는 선택은 자연스러웠다. 하지만 외부 API, 보안, 그리고 구조적 경계라는 문제를 마주하면서 그 선택은 더 이상 유지될 수 없었다. 이 글은 “서버를 없애는 설계”가 어떻게 “경계를 만드는 설계”로 바뀌었는지에 대한 기록이다.
📱 Apps
category-applications
Featured post
Latest posts
Readium 개발기 #4 — Timeline은 왜 ‘기록’이어야 했는가
Timeline을 UI를 위한 데이터로 만들면 편하다.
하지만 그 순간 기록은 깨지기 시작한다.
이 글은 Timeline을 상태가 아닌 ‘사실’로 재정의하면서,
이벤트를 얇게 만들 수밖에 없었던 설계 과정을 다룬다.
Readium 개발기 #3 — 세션 토글은 왜 그렇게 단순하지 않았는가
토글은 단순한 버튼처럼 보였다.
하지만 그 안에는 세션, 상태, 이벤트, 그리고 모든 도메인 정책이 걸려 있었다.
이 글은 가장 작은 기능이 어떻게 설계를 무너뜨리는지를 기록한다.
Readium 개발기 #2 — 도메인 설계는 왜 반드시 무너지는가
도메인 설계는 처음부터 틀린다. 문제는 틀렸다는 사실이 아니라, 왜 틀렸는지 보이지 않는다는 데 있다. 이 글은 상태 기반 모델이 어떻게 무너지고, 왜 이벤트와 시간 개념으로 재구성될 수밖에 없는지를 구조적으로 추적한다.
Readium 개발기 #1 — 나는 문제를 잘못 정의한 상태에서 시작했다
기록이 없는 게 문제라고 생각했다.
하지만 실제로는, 기록을 어떻게 정의해야 하는지 모르는 상태였다.
이 글은 그 오판에서 시작된 설계의 첫 번째 균열을 다룬다.
Readium 개발기 #0 — 우리는 왜 틀린 설계에서 시작하는가
설계는 처음부터 맞지 않는다. 대부분의 프로젝트는 문제를 정확히 정의하지 못한 상태에서 시작되고, 그 결과 틀린 구조 위에서 개발이 진행된다. 이 글은 Readium 개발기를 시작하기 전에, 왜 이 시리즈가 “정답”이 아니라 “설계가 무너지는 과정”을 기록하려 하는지에 대한 선언이다.