전부 서비스가 된 가족
한 사람이 몇 년에 걸쳐 같은 스타일, 같은 관례로 지어온 형제 앱 무리를 떠올려봐. 여행 엔진 하나, 건강 엔진 하나, 자산 엔진 하나, 퀘스트 작업장 하나. 전부 옆에 데이터베이스를 끼고 있는 작은 백엔드고, 전부 포트를 하나씩 갖고 있어. 자기만 쓰는 번호, 재부팅해도 살아나게 해주는 서비스 정의, 살아 있냐고 물으면 대답하는 헬스 엔드포인트까지. 새 형제를 들일 때 의식도 정해져 있어. 다음 빈 포트를 잡고, 서비스 파일을 쓰고, 헬스 체크를 연결해.
그리고 Beacon 이 있는데, Beacon 은 그게 하나도 없어. 포트 없어. 서비스 정의 없어. 헬스 엔드포인트 없어. 재시작할 것도 없어. 돌고 있는 게 없으니까. 명령줄에서 부르면 영상을 하나 뽑고 끝나.
주변이 전부 반대라서 이 거부가 읽혀
여기서 좀 머물러야 해. 서버 없는 도구 하나만 놓고 보면 증명되는 게 없거든. 스크립트는 원래 대부분 서버가 없어. Beacon 이 흥미로운 건 대조 때문이야. 만든 사람은 포트 의식을 이미 전부 자동화해뒀어. 하나 더 붙이는 데 한 시간도 안 걸렸을 거야. 양옆 형제들은 아무 논의 없이 하나씩 받아 갔고. 그런데도 Beacon 엔 없어. 누군가 기본값을 보고 일부러 사양했다는 뜻이야.
아키텍처 문서는 이 거부를 '지금 사실'이 아니라 불변식으로 적어놨는데, 그 차이가 이 강의의 전부야. 지금 사실은 어쩌다 참인 거라 편해지면 바뀌어. 불변식은 이유가 같이 적힌 약속이야. 그래서 다음 사람은, 반년 뒤에 다 까먹은 저자 본인까지 포함해서, 빈자리를 발견하고 채우는 게 아니라 그 이유랑 싸워야 해.
비어 있는 자리 읽기
시스템이 뭔지 알아내는 제일 빠른 길은 뭘 거부하는지 세어보는 거일 때가 많아. Beacon 목록은 짧고, 항목 하나가 일거리 한 종류씩을 지워:
- 서버 없음 — 살려둘 것도, 감시할 것도 없고, 요청 생명주기를 설계할 일도 없어.
- 포트 없음 — 가족 주소 공간에 자리를 안 잡으니 충돌 협상도, 방화벽 고민도 없어.
- 스케줄러 없음 — 혼자 발화하는 게 없어. 모든 실행 뒤엔 그걸 원한 사람이 있어.
- 두뇌 없음 — 모형을 안 들고 있고 혼자 루프 돌며 판단하지도 않아. 지능은 실행할 때마다 밖에서 들어와.
넷을 같이 읽으면 기능 목록으론 절대 안 보이는 형태가 떠올라. Beacon 은 작은 엔진이 아냐. 아예 다른 종류야. 누가 일하러 왔을 때 일이 벌어지는 장소. 작업장이 딱 그거잖아.