"네가 쓰는 그 웹 페이지는 제품이 아니야. 제품의 첫 손님이고, 다른 손님들이랑 같은 줄에 서 있어."
엔진이 제품이다
Loomis 의 제품은 분석 엔진과 그 앞에 놓인 HTTP API 야. 네가 클릭하는 웹 UI 는 그 자체가 아니라 그 API 의 첫 손님이고, 특별한 권한 같은 건 없어. 브라우저에서 초상을 분석할 때 UI 는 다른 클라이언트가 하는 것과 똑같은 요청을 보내는 거야. 엔진과 API 를 먼저 놓고 UI 를 그 위의 소비자로 두는 이 순서가, 이 전체 구조에서 제일 중요한 결정이야.
속을 직접 건드리는 클라이언트는 없다
이 원칙을 지켜주는 규칙이 하나 있어. 어떤 클라이언트도 엔진 속으로 손을 뻗지 않아. UI 도 API 를 건너뛰고 엔진 상태를 직접 만질 수 없어. 다들 쓰는 그 공개된 문으로만 들어가. 이게 왜 중요하냐면, 한 클라이언트한테 뒷문을 열어주는 순간 API 가 조용히 2등 시민이 되거든. 덜 테스트되고 덜 다듬어지고 결국 틀려져. 뒷문을 막아야 API 가 장식이 아니라 진짜로 하중을 받는 문이 돼.
이 원칙의 시험
어떤 도구에도 대볼 수 있는 깔끔한 시험이 하나 있어. UI 를 통째로 잃어도 API 만으로 다 쓸 수 있나? 그렇다면 진짜로 API 가 먼저인 거고, 아니라면 UI 가 몰래 로직을 붙잡고 있는 거야. Loomis 는 깔끔하게 통과해. 명령줄 도구가 UI 없이도 초상이든 포즈든 손이든 사물이든 분석하고, 나중에 붙을 Cinder 패널도 똑같은 엔진을 쓸 거거든. 웹 화면은 위에 얹힌 편의지 밑에 깔린 필수품이 아니야.
UI 부터 만들면 왜 손해인가
UI 부터 만드는 도구는 로직을 화면 안에 숨겨. 만들 땐 빨라 보이고 그다음부터 평생 이자를 내지. 두 번째 손님이 필요해지는 순간, 그러니까 스크립트든 명령줄이든 다른 앱이든 붙이려는 순간, 화면에 엉킨 로직을 떼어내는 수술을 해야 하거든. API 를 먼저 놓으면 선을 일부러 긋는 작은 비용을 앞에서 치르고, 여러 손님과 테스트와 자동화를 첫날부터 공짜로 얻어. 나중에 더 낼 게 없고. Bonfire 가 쓰는 그 모양이야. 엔진이 모델을 갖고 UI 는 첫 손님. 싸 보이는 쪽이 사실 비싼 쪽이라서 이게 이 가족의 기본값이 됐어.