Readium 개발기 #6 — 서버를 없애려다, 경계를 만들게 되었다
서버를 만들지 않으려는 선택은 자연스러웠다. 하지만 외부 API, 보안, 그리고 구조적 경계라는 문제를 마주하면서 그 선택은 더 이상 유지될 수 없었다. 이 글은 “서버를 없애는 설계”가 어떻게 “경계를 만드는 설계”로 바뀌었는지에 대한 기록이다.
system design
Featured post
Latest posts
Readium 개발기 #1 — 나는 문제를 잘못 정의한 상태에서 시작했다
기록이 없는 게 문제라고 생각했다.
하지만 실제로는, 기록을 어떻게 정의해야 하는지 모르는 상태였다.
이 글은 그 오판에서 시작된 설계의 첫 번째 균열을 다룬다.
우리는 어떻게 시스템을 고칠 수 없는 상태로 만드는가
시스템은 한 번에 무너지지 않는다.
검증이 멈추고, 기준이 흐려지고, 해석이 사라지면서
결국 수정이 복구 수단이 아닌 상태로 전이된다.
Readium 개발기 #0 — 우리는 왜 틀린 설계에서 시작하는가
설계는 처음부터 맞지 않는다. 대부분의 프로젝트는 문제를 정확히 정의하지 못한 상태에서 시작되고, 그 결과 틀린 구조 위에서 개발이 진행된다. 이 글은 Readium 개발기를 시작하기 전에, 왜 이 시리즈가 “정답”이 아니라 “설계가 무너지는 과정”을 기록하려 하는지에 대한 선언이다.
AI가 코드를 빠르게 만들수록, 시스템은 더 느려진다
AI는 코드를 10배 빠르게 만든다.
하지만 그 코드를 이해하는 속도는 그대로다.
Amazon의 장애는 단순한 사고가 아니라,
AI 시대에 개발 프로세스가 어디서 무너지는지를 보여준다.
작은 명령어 뒤에 숨은 Unix 설계 이야기 — 수십 년을 살아남은 가장 작은 인터페이스
터미널에서 무심코 사용하는 작은 기호들 — stdout, 파이프, fork, 그리고 파일 디스크립터.
이 시리즈는 그 단순한 인터페이스 뒤에 숨어 있는 Unix의 설계 철학을 따라가 보았다.
수십 년이 지나도 여전히 살아 있는 작은 인터페이스들의 이야기.
셸 리디렉션은 실제로 어떻게 동작할까 — fork, exec, dup2 뒤에 숨은 Unix 프로세스 이야기
우리가 매일 사용하는 >, |, 2>&1 같은 셸 문법은 단순한 출력 리디렉션이 아니다.
이 글에서는 fork, exec, dup2 같은 Unix 시스템 호출이 어떻게 결합되어 셸 리디렉션과 파이프라인을 만들어 내는지 살펴본다.
pipe(|) 는 왜 세상을 바꿨을까 Unix 파이프의 탄생 이야기
우리가 터미널에서 아무 생각 없이 사용하는 `|` 기호는 사실 Unix 역사에서 가장 중요한 발명 중 하나였다. 작은 프로그램들을 연결해 하나의 시스템처럼 동작하게 만든 Unix 파이프의 탄생 이야기.
2>&1 뒤에 숨은 Unix 설계 이야기
이상한 문장 하나에서 시작된 질문 — 2>&1
터미널을 조금이라도 오래 사용해 본 사람이라면 이런 명령을 한 번쯤은 보았을 것이다.
command > file 2&
작은 명령어 뒤에 숨은 Unix 설계 이야기
커맨드라인에서 자주 보이는 작은 명령어들 뒤에는 Unix의 오래된 설계와 철학이 숨어 있습니다. 이 시리즈는 2>&1, 파이프, 리디렉션 같은 문법을 출발점으로 Unix 시스템의 아이디어를 따라가 봅니다.