본문 바로가기
C.W.K.
Stream
Lesson 01 of 04 · published

API 가 먼저, UI 는 손님이다

~12 min · api-first, headless, boundary, bonfire-pattern

Level 0빈 종이
0 XP0/35 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"네가 쓰는 그 웹 페이지는 제품이 아니야. 제품의 첫 손님이고, 다른 손님들이랑 같은 줄에 서 있어."

엔진이 제품이다

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 는 첫 손님. 싸 보이는 쪽이 사실 비싼 쪽이라서 이게 이 가족의 기본값이 됐어.

Code

API 하나에 손님 여럿, 뒷문은 없음·python
# The engine owns the model and exposes an HTTP API. THAT API is the product.
# Every client calls it the SAME way -- none reaches past it into internals:
#
#   POST /api/v1/portrait/analyze   <- the web UI calls this
#   POST /api/v1/portrait/analyze   <- the `loomis overlay` CLI calls this
#   POST /api/v1/portrait/analyze   <- the future Cinder panel will call this

# The test of API-first: delete the UI and the engine is STILL fully usable.
#   $ loomis overlay reference.jpg --json     # no UI involved at all

# UI-first would hide the logic INSIDE the interface -- and then a second client
# costs you extraction surgery. API-first pays the boundary cost once, up front.

External links

Exercise

네가 만들었거나 쓰는 것 중에 로직이 화면 안에 들어앉은 걸 하나 골라. 이제 거기에 두 번째 손님이 필요해졌다고 해보자. 명령줄이든 정기 실행 스크립트든 다른 앱이든. 화면에서 로직을 떼어내려면 얼마나 큰 수술이 필요할지 어림해봐. 그다음 처음부터 API 를 먼저 놓았다면 앞에서 뭘 냈을지, 그리고 뒤에서 뭘 아꼈을지 적어봐.
Hint
수술은 대개 크고 위험해. 화면 이벤트와 상태와 렌더링에 엉킨 로직을 동작 안 깨고 떼어내야 하는데, 그것도 아무도 어떻게 돌아가는지 기억 못 하게 된 한참 뒤에 말이야. API 를 먼저 놓는 건 작고 싼 결정 하나를 앞으로 당기는 거고, 그 대가로 나중의 모든 손님이 수술이 아니라 전화 한 통이 돼. 느려 보이던 길이 사실 빠른 길이었던 거지.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.