한 고객사는 승인 단계를 하나 더 원하고, 다른 고객사는 알림 시간을 바꾸고 싶어 한다. 개발자가 `if 고객사 == A`를 추가하면 당장은 빠르다. 그러나 몇 년 뒤에는 왜 그 조건이 있는지, 어느 고객이 실제로 쓰는지, 새 버전에서도 안전한지 알기 어렵다. 고객사별 설정은 예외 코드를 늘리는 수단이 아니라, 제품이 허용하는 차이를 관리하는 계약이어야 한다.
Microsoft의 멀티테넌트 App Configuration 안내는 공통 설정과 테넌트별 설정을 구분하고, 저장소 분리·키 접두어·캐시 갱신을 요구에 맞게 선택하도록 설명한다. 특정 클라우드를 쓰지 않아도 같은 문제를 겪는다. 설정값의 위치보다 누가 어떤 범위에서 왜 바꿀 수 있는지가 먼저다.
세 가지를 혼동하지 않는다: 설정, 권한, 기능 플래그
설정은 시간대나 알림 정책처럼 허용된 동작의 값을 고르는 것이다. 요금제 권한은 고객이 어떤 기능을 계약상 사용할 수 있는지 정의한다. 기능 플래그는 새 기능을 단계적으로 출시하거나 긴급히 끄는 임시 운영 스위치일 수 있다. 이 셋을 하나의 불리언 값 저장소로 만들면 결제 조건, 보안 권한, 실험 상태가 뒤섞인다.
Microsoft의 멀티테넌트 배포·구성 가이드도 고객의 라이선스 권한을 일시적인 기능 플래그로만 다루지 말라고 구분한다. ‘이 고객은 유료 기능을 쓸 권리가 있다’와 ‘이 기능을 이번 주에 이 고객에게 먼저 열어 본다’는 서로 다른 질문이다. 제품 기획, 영업, 개발이 같은 정의를 사용해야 운영 화면도 명확해진다.
기본값과 덮어쓰기 순서를 명시한다
대부분의 고객은 공통 기본값을 사용한다. 일부 고객에게만 허용된 설정을 별도로 저장한다. 기본값, 환경별 값, 요금제, 테넌트 값이 겹칠 때 어떤 순서로 최종 값이 결정되는지 문서화한다. 보안 제한이나 계약 한도를 고객 설정으로 높일 수 없도록 상한·하한을 검증한다. ‘설정이 없으면 기본값’이라는 규칙과 ‘설정값이 비어 있으면 기능 끄기’라는 규칙도 구분해야 한다.
설정에는 자료형, 허용 범위, 단위, 기본값, 적용 범위, 변경 가능한 역할, 변경 시점을 스키마로 정의한다. 예를 들어 보관기간 값을 정수로만 검사하면 초인지 일인지 혼동할 수 있다. 새 설정을 도입할 때 기존 고객에게 어떤 기본값이 들어가는지 테스트한다. 고객별 데이터를 같은 저장소에 넣는 경우에는 키나 레이블에 테넌트 범위를 분명히 하고, 읽을 때 다른 고객의 설정을 가져오지 않도록 서버에서 검증한다.
설정 변경에도 배포 절차가 있다
설정을 DB에서 즉시 바꿀 수 있다고 해서 검증 없이 운영에 반영해도 된다는 뜻은 아니다. 초안, 검증, 승인, 예약 적용, 활성화, 되돌리기 같은 상태를 둔다. 변경 전후 값, 변경자, 사유, 영향을 받는 고객 범위를 기록한다. 위험이 큰 설정은 테스트 고객사에 먼저 적용하고 지표를 확인한 뒤 넓힌다. 실패하면 이전에 검증된 버전으로 돌아갈 수 있어야 한다.
캐시는 운영의 함정이다. 여러 앱 인스턴스가 서로 다른 시점에 설정을 갱신하면 같은 고객이 요청마다 다른 동작을 볼 수 있다. 고객사별 캐시 키, 갱신 신호, 허용된 지연을 정한다. 급히 차단해야 하는 보안 설정은 일반적인 캐시 만료를 기다려도 되는지 별도로 판단한다. 각 요청의 로그에는 비밀값 자체가 아니라 적용된 설정 버전을 남겨 문제를 재현할 수 있게 한다.
모든 고객 맞춤을 설정으로 만들 필요는 없다
설정 항목이 너무 많으면 제품은 하나인데 사실상 고객마다 다른 소프트웨어가 된다. 어떤 요구는 공통 제품 기능으로 승격하고, 어떤 요구는 계약상 제공하지 않는 편이 낫다. 설정의 조합 수가 커지면 테스트 가능한 범위를 넘는다. 자주 함께 쓰는 조합을 지원 프로필로 정의하거나 서로 모순되는 값을 스키마에서 거부한다. 특별한 외부 연동이 필요한 고객은 설정값 하나가 아니라 별도 통합 설계가 필요할 수 있다.
운영 화면은 ‘고객 A에 값 37’만 보여 주지 말고 그 값의 의미와 출처를 보여 줘야 한다. 공통 기본값을 상속했는지, 고객사가 직접 설정했는지, 운영자가 임시 예외를 둔 것인지 알아야 지원팀이 답할 수 있다. 고객이 직접 바꿀 수 있는 설정이라면 적용 시점과 되돌리는 방법도 화면에 설명한다.
민감한 값은 일반 설정과 분리한다. 외부 연동 API 키나 비밀번호를 고객별 설정 JSON에 섞어 저장하고 운영 화면에서 그대로 보여 주면 접근 통제가 어려워진다. 비밀정보는 전용 저장·권한 체계를 사용하고 설정에는 참조만 남긴다. 운영자는 어느 키 버전이 적용됐는지 알 수 있어야 하지만 비밀값 자체를 읽을 필요는 없을 수 있다. 브라우저로 내려보내는 설정은 공개해도 되는 값만 포함한다.
환경 간 차이도 관리 대상이다. 시험 환경에서 검증한 설정 묶음이 운영 환경에서는 다른 기본값과 합쳐져 예상치 못한 결과를 만들 수 있다. 변경 전 최종 해석값을 미리 보여 주고, 적용 후 특정 고객의 핵심 업무 시나리오를 검사한다. 값 하나가 여러 고객사에 영향을 준다면 고객사별 설정 변경보다 범위가 넓은 공통 릴리스로 다뤄야 한다.
설정 관리 체크리스트
- 설정·요금제 권한·출시 플래그를 구분했는가?
- 기본값과 테넌트 덮어쓰기 순서가 명확한가?
- 범위·단위·조합을 스키마로 검증하는가?
- 고객사 범위를 서버에서 격리하는가?
- 설정 변경자·사유·버전을 추적하는가?
- 시험 적용과 이전 버전 롤백이 가능한가?
- 캐시 갱신 지연과 긴급 변경 경로를 정했는가?
좋은 테넌트 설정은 고객마다 다른 코드를 배포하지 않게 하면서도, 제품이 허용하는 차이를 통제한다. 값을 저장하는 기술보다 그 값이 언제, 누구에게, 어떤 근거로 적용되는지가 운영 품질을 결정한다.
