remote 는 설정이지 topology 가 아냐

"뇌가 어디 사는지 하드코딩하는 순간, 클라이언트를 네트워크 하나에 용접한 거야. 설정으로 만들면 클라이언트는 어디든 가."

하드코딩 유혹

내 백엔드랑 얘기하는 클라이언트를 만들 땐, 그냥 주소를 적어넣고 싶어져. 서버가 어딘지 아는데, 왜 설정 가능하게 해? 그 주소가 소스에 구워지는 순간 세 가지가 한꺼번에 틀어지니까: 클라이언트가 네트워크 하나에서만 작동하고, topology 가 코드 읽는 아무나 볼 수 있는 사실이 되고, 딸려간 secret(PIN, token)이 secret 이 절대 살면 안 되는 데 살게 돼. remote 위치랑 인증은 설정 이야 — 런타임에 해소되는 사용자 설정 — 절대 클라이언트에 컴파일된 상수가 아냐.

소스에서 항상 빠지는 것

규칙은 엄격하고 목록으로 적을 만해. 어기면 각 항목이 진짜 실패니까:

remote origin — Pippa 백엔드가 사는 데 — 은 설정이라, 같은 클라이언트가 집에서, 폰 네트워크에서, 사용자가 설정하는 어디서든 작동해.
인증 자료 — PIN, token, 발급된 세션 자격 — 은 절대 소스 코드나 커밋된 config 파일에 안 들어가. 사용자가 입력하고 적절한 보안 저장소에 쥐어지지, repo 에 있지 않아.
네트워크 좌표 — 구체적 주소랑 접근 세부 — 는 커밋된 코드에서 완전히 빠져. 사적 topology 를 드러내는 코드는 private repo 에서도 누출이야.

설정 가능한 게 더 정직하기도 하다

안전을 넘어, 설정이 더 정직한 설계야. 하드코딩된 주소는 백엔드가 사는 진짜 데가 하나뿐인 척해; 설정은 그게 사는 데가 사용자의 선택이고 바뀔 수 있다는 진실을 인정해. 이건 퀘스트 나머지랑 같은 소유자-존중 본능을 배포에 겨눈 거야: 클라이언트를 돌리는 사람이 topology 를 정하고, secret 을 공급하고, 접근을 통제해 — 그중 뭐도 코드 쓴 사람이 추정하고 얼려선 안 돼. 설정으로 만들면, 클라이언트는 한 빌더의 네트워크에 용접된 게 아니라 사용자가 소유하고 조종하는 게 돼.

Code

remote + auth 를 런타임에 해소, 절대 상수에서가 아니라·typescript

// 틀림: topology 랑 secret 이 소스에 용접됨.
const REMOTE = "http://<어떤-고정-주소>";  // 클라이언트가 한 곳에서만 작동
const PIN = "1234";                          // repo 안의 secret — 절대 안 됨

// 맞음: remote 랑 auth 는 사용자 설정, 런타임에 해소.
async function getRemoteConfig(): Promise<RemoteConfig> {
  return {
    origin: await settings.get("pippaOrigin"),    // 사용자 설정
    // auth 자료는 사용자가 입력하고 보안 저장소에 쥐어짐,
    // 절대 소스나 커밋된 config 파일에서 안 읽음
  };
}

// 같은 빌드된 클라이언트가 사용자가 겨누는 어느 네트워크에서든 작동해.

Exercise

네가 만든 클라이언트를 하드코딩된 topology 로 감사해: 소스에서 리터럴 주소, host, endpoint 로서의 port, 자격 증명을 찾아. 각각에 대해, 대신 어디 살아야 할지(사용자 설정, 보안 저장소, 환경 값) 그리고 클라이언트가 런타임에 어떻게 해소할지 정해. 그다음 누출 질문을 해: 이 repo 가 내일 공개되면, 하드코딩된 값들이 드러내면 안 될 뭘 드러냈어?

Hint

판별점은 문자열 리터럴로 grep 할 수 있는 네트워크 좌표나 secret 이야. 해법은 각각을 런타임 조회로 바꾸는 거 — 위치엔 설정, secret 엔 보안 저장소 — 그래서 코드가 시스템의 모양은 드러내되 구체적 주소나 키는 안 드러내게.