remote 는 설정이지 topology 가 아냐

"뇌가 어디 사는지를 하드코딩하는 순간, 클라이언트를 네트워크 하나에 용접해 버린 거야. 설정으로 빼두면 클라이언트는 어디든 갈 수 있고."

하드코딩하고 싶어지는 순간

내 백엔드랑 얘기하는 클라이언트를 만들다 보면 그냥 주소를 적어 넣고 싶어져. 서버가 어딨는지 뻔히 아는데 굳이 설정으로 뺄 이유가 있나 싶고. 그 주소가 소스에 구워지는 순간 세 가지가 한꺼번에 틀어지거든. 클라이언트가 네트워크 한 군데에서만 돌아가고, topology 가 코드 읽는 사람 아무나 알게 되는 사실이 되고, 같이 딸려 들어간 PIN 이나 token 이 절대 있으면 안 되는 자리에 살게 돼. 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 은 보안 저장소로. 그러면 코드가 시스템 모양은 보여줘도 구체적인 주소나 키는 안 보여주게 돼.