"적어둔 건 가설이고, 머신이 지금 하고 있는 게 진실이야. 이 둘을 헷갈리지 마."
허브가 있어야 하는 이유가 이 틈이야
첫 트랙에서 허브의 핵심은 '뭐가 멀쩡하냐'에 답하는 거였지. 북마크로는 못 건드리는 질문. 여기서 그 질문이 이빨을 드러내. roster 에 'Ember 는 port 8100' 이라고 적힌 거랑, Ember 가 지금 진짜로 8100 에 떠 있는 거는 완전히 다른 사실이야. 앞엣것은 누가 언젠가 적어두고 아직 맞기를 바라는 말이고, 뒤엣것은 지금 이 순간 host 에서 재본 값이지. 적힌 걸 보여주면서 그걸 상태라고 부르는 허브는 좀 예쁜 북마크일 뿐이야.
host 에서 확인하고, 본 대로 보여줘
그래서 Firelink 는 적힌 걸 가설로, 본 걸 답으로 다뤄. 준비 상태든 설치된 서비스든 풀린 URL 이든 찾아낸 버전이든 돌아가는 상태든, 전부 진짜 host 에서 확인하고 본 대로 내놔. 적힌 건 census 한테 어디를 보고 뭘 기대할지 알려줄 뿐이고, 실제로 뭐가 있는지는 probe 가 알려줘. 둘이 맞으면 좋고. 어긋나면 그 어긋남이 drift 야. 덮을 에러가 아니라 그 자체로 다뤄야 할 사실이지.
이 순서가 왜 중요하냐면
방향이 곧 규율이야. 본 게 적힌 걸 이겨. 늘. probe 는 서비스가 죽었다는데 roster 엔 떠 있어야 한다고 적혀 있으면, 허브는 '적힌 건 살아있음, 본 건 죽음' 이라고 보고해. roster 를 믿고 초록불 켜지 않아. 적힌 게 현실을 이기는 일은 없어. 뻔한 소리 같지? 근데 얼마나 많은 대시보드가 config 를 띄워놓고 그걸 건강이라 부르는지 보면 생각이 달라져. 걔들은 뭐가 돌아야 하는지를 그려놓고, 안 돈다는 건 네가 고생해서 알아내게 둬. Firelink 는 반대로 가. 뭐가 있는지를 보여주고, 적힌 것과 갈라지는 자리를 짚어줘.