설치라는 단위가 없다 — 고치면 다음 접속에 이미 바뀌어 있다

앞 글에서 장치가 자기 화면을 건넨다고 했다. 이 글은 그 화면이 어떻게 도착하느냐다.

여기에 이 구조의 가장 조용한 차이가 있다.

앱의 세계에서 배포의 단위

설치된 소프트웨어의 세계에서는 배포의 단위가 바이너리다.

화면의 문구 하나를 고쳐도 절차가 같다. 코드를 고치고, 빌드하고, 서명하고, 올리고, 심사를 받고, 사용자 기기가 내려받는다. 그래서 "그 한 줄만 고쳐 주세요"가 며칠짜리 일이 된다.

이건 누구의 게으름이 아니라 단위의 문제다. 배포되는 것이 기기 안에 설치되는 물건이기 때문에, 그 물건을 통째로 다시 만들어 통째로 다시 보내는 것 말고는 방법이 없다.

여기서는 접속할 때 건네받는다

이 구조에서 배포의 단위는 접속할 때 건네받는 문서다.

장치가 자기 화면을 서술로 갖고 있고, 클라이언트가 붙을 때 그것을 받는다. 그러니 서술을 고치면 다음 접속에 이미 그 화면이다. 중간에 빌드가 없고, 서명이 없고, 내려받기가 없다.

이 매거진에 무인 매장을 다룬 샘플이 있다. 앱은 폴더 하나로 되어 있고 빌드 산출물이 없다. 화면을 고치고 다시 열면 그 화면이다 — 검증에 편집 전후 두 장이 나란히 남아 있다. 앞 장과 뒷 장 사이에 빌드가 없다.

그러니 스토어의 주인도 없다

이게 앞선 「울타리와 땅」과 이어지는 자리다.

설치가 있으면 그 설치를 관리하는 자리가 생긴다. 무엇이 설치될 수 있는지 정하는 쪽, 심사하는 쪽, 몫을 정하는 쪽. 그 자리가 있기 때문에 울타리가 성립한다.

설치가 없으면 그 자리도 없다. 장치를 만든 쪽이 자기 화면을 자기가 정하고, 그 화면은 자기 장치에 붙은 사람에게만 간다. 사이에 낄 자리가 구조적으로 생기지 않는다.

편의의 문제가 아니라 누구를 거치느냐의 문제다.

편집이 실제로 어떻게 생겼나

여기서 원문 편집 장면을 보여 주는 것은 정직하지 않다. 서술을 손으로 고칠 수 있다는 것과, 그것이 실용적인 저작 방식이라는 것은 다른 얘기다. 실제로는 저작 도구에서 만들고 붙이고 확인한다.

그래서 이 글이 보이는 것은 결과다. 고쳤고, 다시 열었고, 바뀌어 있다. 그 사이에 무엇이 없었는지가 요점이다.

이 샘플이 잡은 사고 하나

같은 샘플에서 로그와 그림이 어긋난 적이 있다. 로그에는 재고 부족 품목이 셋이라고 찍혀 있는데, 캡처에는 "부족한 것 없음"이 떠 있었다.

원인은 화면을 옮길 때 새 화면이 자기 초기 상태로 시작하는 것이었다. 앞 화면이 들고 있던 데이터가 따라오지 않는다. 로그는 서버 쪽 사실을 찍고 있었고 화면은 자기 사실을 그리고 있었으니, 둘 다 거짓말은 아니었다.

고친 뒤에 검증에 규칙을 하나 넣었다 — 로그와 캡처의 시점이 맞는지를 검사한다. 화면을 옮긴 다음 줄에 그 값이 있어야 통과한다.

"화면이 서버를 따라온다"는 말은 이렇게 어긋날 수 있고, 어긋난 것을 눈으로만 잡으면 놓친다.