같은 프로세스도 계약은 건너뛰지 마

"같은 프로세스는 계약을 건너뛸 핑계가 아냐. 하지만 계약과 HTTP가 같은 말도 아냐."

유혹적인 지름길

Bonfire의 내장 UI와 엔진은 가까이서 돌아. 브라우저 UI라면 서버 포트의 HTTP API로 말을 걸 수 있고, 테스트나 다른 셸은 같은 프로세스에서 엔진을 부를 수도 있어. 가까이 있다는 이유로 UI가 내부 모델이나 저장소를 바로 import하고 싶어지는 순간이 와. 코드가 짧고 당장은 잘 돌아가는 것처럼 보이거든.

문제는 직접 호출 자체가 아니라 무엇을 직접 부르느냐야. UI가 공개 계약 대신 엔진의 내부 타입과 저장 방식에 기대면, 리팩터링만으로 클라이언트가 깨져. 모델도 다른 클라이언트가 쓸 수 없는 비밀 통로로 흘러가. 반대로 같은 요청·응답 계약을 구현한 client port를 두면 transport는 바꿀 수 있어. 브라우저에서는 HTTP adapter를, 테스트나 한 프로세스 셸에서는 in-process adapter를 써도 클라이언트가 보는 계약은 같아.

원격처럼 설계하되 transport는 골라

규율은 이렇게 쓰는 편이 정확해. 클라이언트는 엔진 내부가 아니라 공개 계약에만 의존해. 다른 머신으로 옮겨도 성립할 요청과 응답을 먼저 정하고, 배치에 맞는 transport를 adapter로 붙여. Bonfire의 브라우저 UI는 HTTP 경계를 실제로 밟아서 API가 충분한지 검증해. 그렇다고 모든 in-process 호출까지 HTTP로 돌려야 한다는 뜻은 아냐. 보장해야 하는 건 transport 하나가 아니라 계약 하나야.

Code

계약 하나, transport adapter는 여러 개·typescript

// 틀림. UI가 엔진 내부 구현에 직접 결합:
import { MusicModel } from "../../backend/model";
const song = MusicModel.load(trackId);

// 맞음. UI는 공개 계약만 알아:
interface BonfireClient {
  getTrack(id: string): Promise<TrackDTO>;
}

const httpClient: BonfireClient = {
  getTrack: (id) => fetch(`/api/v1/tracks/${id}`).then((r) => r.json()),
};

// 테스트나 한 프로세스 셸은 같은 계약의 in-process adapter를 쓸 수 있어.
// 바뀌는 건 transport고, 클라이언트 계약은 그대로야.

Exercise

프로젝트에서 두 부분이 같은 프로세스를 쓰며 내부 import, 전역, 직접 DB 읽기로 연결된 자리를 찾아. 둘이 다른 머신에 있다면 어떤 요청과 응답이 그 연결을 대신할까? 그 계약을 먼저 적은 뒤, 지금 배치에는 HTTP와 in-process adapter 중 무엇이 맞는지 정해 봐.

Hint

'다른 머신'은 계약을 찾는 사고 실험이지 모든 호출을 HTTP로 만들라는 명령이 아냐. transport를 바꿔도 요청·응답 의미가 그대로라면 경계가 제대로 잡힌 거야.

유혹적인 지름길

원격처럼 설계하되 transport는 골라

Code

External links

Exercise

Progress

댓글 0