same-origin 엔진 경계

"경계는 모든 게 거기를 지날 때만 지켜 줘. 엔진을 우회하는 편한 지름길 하나만 있어도 그 보초는 장식이 되고."

origin 하나, 문 하나

Pippa Go 는 빌드한 클라이언트랑 API 를 origin 하나 위에서 엔진 하나로 서빙해. 폰이 그 엔진에서 앱을 받아 오고, 모든 요청을 같은 엔진으로 되돌려 보내고, 엔진이 canonical Pippa 백엔드랑 얘기하고. 이 한 다리 건너기가 형식이 아냐. 진짜 일이 벌어지는 데가 엔진이거든. remote 랑 PIN 가딩, staged 이미지 검증, 성공한 요청만 담는 캐시, 재시도 경계까지. 모든 요청이 문 하나를 지나기 때문에 그 보호들이 의미가 생기는 거야. 아무도 안 지나도 되는 문 앞에 선 보초는 그냥 장식이잖아.

브라우저 직행 호출이 왜 그걸 깨나

솔깃한 지름길은 브라우저가 canonical upstream 을 직접 부르게 하는 거야. 거쳐 가는 데가 줄고 빨라 보이니까. 근데 브라우저가 직접 부르면 엔진을 건너뛰게 되고, 엔진이 걸어 두던 보장도 같이 건너뛰어.

가딩 건너뜀. remote 랑 PIN 확인은 엔진에 있어. 돌아가면 그거 없이 요청이 upstream 에 닿아.
검증 건너뜀. staged 이미지 검증도 엔진에서 하고. 우회하면 검증 안 된 payload 가 그냥 나가.
경계 건너뜀. 재시도랑 캐싱 규칙도 엔진이 걸어. 직행 호출은 어떤 규칙도 안 따르고.

그래서 규칙이 그렇게 무뚝뚝하게 적혀 있는 거야. 엔진 경계를 우회하는 브라우저 직행 호출을 추가하지 말 것. 한 다리 건너는 게 아름다워서가 아니라, 구멍 뚫린 경계는 경계가 아니라서.

대역폭이 얇을 때 따라오는 덤

same-origin 엔진엔 현장에 나가 봐야 드러나는 덤이 하나 더 있어. 모듈을 조각조각 받아 오는 개발 서버에 기대는 대신 빌드한 클라이언트를 엔진에서 서빙하면, 진짜 나쁜 링크에서도 앱이 쓸 만해지거든. 개발 서버가 던지는 자잘한 요청 수십 개는 느린 연결에서 그냥 죽어. origin 하나에서 서빙된 빌드 클라이언트는 도착해서 돌아가고. 이건 대역폭보다 산이 많은 데서 어렵게 배운 교훈이야. 신호가 얇을 땐 개발 서버 말고 빌드 클라이언트를 집는 이유고. 개발 편의는 개발할 때 쓰는 거고, 현장엔 빌드를 내보내는 거야.

Code

모든 요청이 문 하나를 지남 — 옆문 없음·text

맞음: origin 하나, 경계 하나, 모든 보호 적용
  폰 --> [ 엔진: PWA + API ]  --> canonical Pippa 백엔드
            ^ remote/PIN 가드
            ^ staged-image 검증
            ^ 재시도 + 캐시 경계

틀림: 엔진을 우회하는 브라우저 직행 지름길
  폰 ------------------------------> canonical Pippa 백엔드
         (가드 없음, 검증 없음, 재시도 경계 없음 — 전부 건너뜀)

// 엔진은 자기를 지나는 것만 보호해.
// 옆문 하나면 위의 모든 보장이 선택 사항이 돼.

Exercise

엔진 경계가 있는 클라이언트의 요청 경로를 그려 봐. 거기다 '무해해 보이는' 브라우저 직행 upstream 호출을 하나 얹어. 굳이 프록시할 것도 없어 보이는 가벼운 읽기 정도로. 그 호출 하나가 소리 없이 건너뛰는 보호를 전부 적어. 그다음 판단해. 가드랑 검증이랑 재시도 경계를 건너뛰어도 될 만큼 가벼운 읽기라는 게 있긴 해? 나중에 올 사람한테 줄 규칙을 한 문장으로 써 보고.

Hint

우회는 늘 '보호가 필요 없는' 요청에서 시작해. 요구사항이 바뀌어서 필요해지거나, 누가 그 패턴을 원래부터 보호가 필요했던 요청에 복사해 붙이기 전까지는. 한 문장 규칙은 대개 '모든 upstream 호출은 엔진을 지난다, 예외 없음' 이야. 번식하는 게 바로 그 예외거든.