환경별 허용 정책 — 이메일·도메인 화이트리스트

"어떤 방에 들어올 수 있는 사람 명단을, 상황별로 따로 관리하는 법" 이에요. 관리자 페이지처럼 아무나 들어오면 안 되는 곳에, "이 이메일은 들어와도 됨" 하는 명단을 두고, 그 명단을 운영 상황(진짜 서비스) 과 연습 상황(개발) 별로 다르게 관리해요.

비유: 파티 초대 명단 🎟️

멋진 파티가 열려요. 문 앞에 경비 아저씨가 명단을 들고 서 있어요. 누가 오면 아저씨는 명단을 보고 들여보낼지 정해요. 명단에는 두 가지가 적혀 있어요.

이름 콕 집기 (개별 이메일) — "김철수, 이영희는 들여보내." 특정 사람을 딱 지정.
소속 통째로 (도메인) — "우리 회사(company.com) 사람이면 다 들여보내." 무리째 허용.

경비 아저씨 판단 순서는 이래요.

여기서 이름표 다듬기가 은근 중요해요. "Kim@Company.com"과 "kim@company.com"을 다른 사람으로 착각하면 안 되니까, 먼저 공백을 지우고 소문자로 통일해서 비교해요.

상황마다 명단이 달라요 (환경별)

똑같은 파티라도 진짜 개장일(운영) 과 리허설 날(개발) 은 명단이 달라요.

진짜 개장일 (prod) — 아주 엄격하게, 콕 집은 사람만. 실수로 아무나 들어오면 큰일이니까.
리허설 날 (개발) — 좀 느슨하게, 우리 회사 사람이면 다. 이것저것 테스트해야 하니까.

판단하는 방식은 똑같은데, 거기 채워 넣는 명단만 상황별로 갈아끼우는 게 핵심이에요.

용도마다 명단이 또 달라요 (트레이드오프)

명단은 용도별로도 갈려요. 관리자 로그인 명단, 로그인 링크 보내기 명단, 연습용 알림 받을 사람 명단이 서로 섞이면 안 돼요. 그래서 같은 방식을 쓰되 명단은 용도별로 따로 둬요.

그리고 명단을 어디에 적어둘지도 골라요.

설정 파일에 적기 — 바꾸려면 다시 배포해야 하지만, 가볍고 git 으로 누가 언제 바꿨는지 다 보여요.
데이터베이스에 적기 — 서비스 돌아가는 중에도 바로 바꿀 수 있지만, 좀 더 무거워요.

자주 안 바뀌면 설정 파일, 운영 중 수시로 바꿔야 하면 데이터베이스를 골라요.

핵심만 다시

들어올 수 있는 사람 명단을 두고, 경비가 그 명단으로 판단해요.
콕 집은 이름이 회사 소속보다 우선, 비교 전엔 이름표를 다듬어요(공백·대소문자).
운영은 엄격 / 개발은 느슨 — 판단 방식은 같고 명단만 상황별로 갈아끼워요.
용도(로그인·링크·알림)마다 명단을 따로 두고, 자주 안 바뀌면 설정 파일에 적어요.

더 자세한 진짜 코드·설계는 옆의 개요 / Variants / Apply Recipe 탭에서 볼 수 있어요.