상품 데이터는 한 번만 관리하고, 테스트 상품은 검수에서만 보이게 운영하기

배포는 하나, 노출은 다르게: 상품 플래그로 환경별 표시/숨김 처리

테스트 상품 자동 분기는 운영 화면에서의 노출 사고를 줄이기 위한 운영 장치입니다. 보안(민감 데이터 보호, 권한 통제)이 아니라, “운영 화면에서 테스트 상품이 섞여 보이지 않게” 만드는 데 초점을 둡니다. 민감 데이터를 숨겨야 한다면 서버 측 차단 같은 별도 조치가 필요합니다.

쇼핑몰처럼 상품이 많고 운영/검수가 동시에 돌아가는 서비스에서는, 이 패턴이 특히 실용적입니다. 상품 데이터는 한 번만 관리하면서도 운영에서는 테스트 상품이 구조적으로 걸러지기 때문입니다.

테스트 상품이 운영에 섞이면 생기는 일

테스트 상품은 필요합니다. 아래 항목들은 실제 판매와 거의 동일한 조건에서 검증해야 합니다.

• 쿠폰/프로모션 적용(할인, 중복 쿠폰, 최소 구매 금액)
• 가격 정책 변경(옵션가, 기간 한정가, 반올림 규칙)
• 결제/환불 흐름(PG 응답, 실패 케이스, 영수증)
• 재고/품절/노출 상태(품절 문구, 알림 신청 등)

문제는 이 테스트 상품이 운영에 노출될 때 일어납니다. 예를 들어 결제 테스트용 1원짜리 상품이 프로모션 페이지에 올라간다고 상상해 봅시다. 고객은 실제 상품인 줄 알고 주문을 넣고, CS팀은 원인 파악과 환불 처리에 매달리게 됩니다. 상품이 하나면 수습이 되지만, 카테고리 필터나 추천 영역에까지 퍼졌다면 피해 범위는 훨씬 넓어집니다.

이런 사고의 공통점은 “수동으로 테스트 상품을 숨기거나 삭제하는 과정”에서 빠뜨린다는 것입니다. 사람의 실수에 의존하는 구조 자체가 위험하므로, 시스템이 자동으로 걸러주는 방식이 안전합니다.

목표: 상품 데이터는 하나, 노출은 환경별로 자동 분기

이 글의 목표는 간단합니다.

• 상품 데이터는 한 번만 관리합니다(운영/검수용 DB를 분리하지 않음).
• 운영에서는 테스트 상품을 자동 숨김합니다.
• 검수(스테이징)나 로컬에서는 테스트 상품도 노출합니다.

핵심 원리는 “상품 관리”와 “상품 노출”을 분리하는 것입니다. 관리(데이터)는 하나로 유지하고, 노출(정책)은 환경에 따라 자동 분기합니다.

구현 개념: 상품 플래그 + 런타임 hostname 판별

구현은 2가지 요소로 구성됩니다.

1) 상품 플래그로 테스트 상품 구분

상품 데이터에 테스트 여부를 나타내는 필드를 추가합니다. 여기서는 isTestProduct를 예시로 사용합니다.

• 판매 상품: isTestProduct = “false”
• 테스트 상품: isTestProduct = “true”

2) 런타임 hostname 판별로 환경 분기

환경을 빌드 타임(환경 변수)으로 나누는 대신, 실행 시점(런타임)에 hostname을 읽어 분기합니다. window.location.hostname 값을 확인해서, hostname이 stg 또는 localhost처럼 검수/개발 환경이면 테스트 상품을 보여주고, 그 외(운영 도메인)에서는 테스트 상품을 숨깁니다.

이 방식은 프론트엔드에서만 노출을 제어하므로, URL을 직접 알면 볼 수는 있습니다. 하지만 운영팀의 실수로 인한 대규모 노출 사고를 구조적으로 막는 데 초점이 맞춰져 있습니다.

왜 hostname인가: 방법별 비교

환경 분기를 구현하는 방법은 여러 가지입니다. 각 방법의 차이를 정리하면 아래와 같습니다.

방법	배포 횟수	데이터 중복	운영 도메인 확장성	프론트만으로 가능?	운영 사고 방지력
환경별 빌드	여러 번	없음	좋음	예	중
서버사이드 필터링	1번	없음	좋음	아니오	높음
런타임 hostname (이 글)	1번	없음	매우 좋음	예	높음

환경별 빌드는 운영/검수마다 빌드를 따로 만들어야 합니다. 서비스 규모가 커지면 빌드 파이프라인 관리가 부담이 됩니다. 서버사이드 필터링은 방지력이 가장 높지만, API 수정이 수반되어 프론트 단독으로 도입할 수 없습니다. 백엔드 리소스가 바로 확보되지 않는 상황이라면 착수 자체가 지연됩니다.

hostname 방식은 이 둘 사이의 실용적인 지점에 있습니다. CDN·로드밸런서·서브도메인을 여러 개 써도 접속한 hostname 기준으로 정책을 적용할 수 있고, 빌드를 1회로 끝낼 수 있습니다. 물론 보안 수준의 은닉이 필요하다면 서버사이드 필터링이 맞습니다. hostname 방식은 “프론트에서 빠르게 도입 가능한 운영 안전장치”로 이해하는 것이 적절합니다.

예시 코드: 필터링 결과 확인

아래는 운영 환경(stg/local이 아닌 경우)에서 어떻게 필터링되는지 보여주는 코드입니다.

// mock 상품 데이터 예시
const data = {
list: [
{ id: 1, name: "실제 판매 상품 A", isTestProduct: "false", price: 10000 },
{ id: 2, name: "테스트용 할인 쿠폰 검수용", isTestProduct: "true", price: 5000 },
{ id: 3, name: "운영용 베스트셀러", isTestProduct: "false", price: 25000 },
{ id: 999, name: "내부용 초특가 테스트", isTestProduct: "true", price: 1000 }
]
};
<p class="font-claude-response-body break-words whitespace-pre-wrap leading-[1.7]">// 운영 환경 (stg/local 아닌 경우)
const filtered = data.list.filter(item =&gt; item.isTestProduct !== 'true');
// 결과: A, 베스트셀러만 남음 (테스트 2개 자동 숨김)

필터링 전(원본 목록 4개)

• id=1 / 실제 판매 상품 A / isTestProduct=false / 10,000원
• id=2 / 테스트용 할인 쿠폰 검수용 / isTestProduct=true / 5,000원
• id=3 / 운영용 베스트셀러 / isTestProduct=false / 25,000원
• id=999 / 내부용 초특가 테스트 / isTestProduct=true / 1,000원

운영 환경에서 필터링 후(노출 목록 2개)

• id=1 / 실제 판매 상품 A / 10,000원
• id=3 / 운영용 베스트셀러 / 25,000원

운영 화면에서는 판매 상품만 남고, 테스트 상품은 자동으로 숨겨집니다. 여기에 hostname 판별을 얹으면 아래처럼 됩니다.

const testVisibleHosts = ["stg.example.com", "localhost"];
const isTestVisibleEnv = testVisibleHosts.includes(window.location.hostname);
<p class="font-claude-response-body break-words whitespace-pre-wrap leading-[1.7]">const visibleList = isTestVisibleEnv
? data.list
: data.list.filter(item =&gt; item.isTestProduct !== "true");

운영 도메인이 늘어나도 기본값은 “숨김”이라 영향이 적고, 테스트 상품이 필요한 환경만 예외로 allowlist 처리합니다.

운영 체크리스트: 목록 외에도 빠뜨리기 쉬운 구간

테스트 상품 자동 분기는 “상품 목록”에서만 적용하면 끝나지 않는 경우가 많습니다. 실제 운영에서 빠뜨리기 쉬운 구간을 정리합니다.

1. 검색과 추천 영역

사이트 내 검색 결과와 추천/연관상품 영역은 별도 API를 타는 경우가 많습니다. 목록 필터링과 다른 경로로 데이터를 가져오기 때문에, 검색 인덱스나 추천 로직에도 동일한 숨김 정책이 반영되어 있는지 확인해야 합니다. 검색엔진에 테스트 상품이 색인되지 않도록 robots 처리나 noindex 태그를 적용하는 것도 함께 검토할 필요가 있습니다.

2. 캐시된 페이지

카테고리 페이지나 기획전 페이지가 CDN이나 서버 캐시에 물려 있다면, 캐시가 갱신되기 전까지 테스트 상품이 노출될 수 있습니다. 캐시 TTL과 퍼지(purge) 정책을 함께 점검하는 것이 안전합니다.

3. 상품 등록 경로의 일관성

테스트 상품 플래그가 상품 등록, 복제, 일괄 업로드 등 모든 경로에서 일관되게 들어가는지 확인합니다. 예를 들어 관리자 페이지에서 상품을 복제할 때 isTestProduct 값이 초기화되지 않는지, 엑셀 일괄 업로드 시 필드 매핑에서 빠지지 않는지 등이 점검 대상입니다.

4. 외부 연동 채널

네이버 쇼핑, 쿠팡 등 외부 채널에 상품 피드를 내보내고 있다면, 피드 생성 로직에서도 테스트 상품이 제외되는지 확인해야 합니다. 외부 채널에 테스트 상품이 노출되면 내부 사이트보다 수습이 더 어렵습니다.

이 체크리스트의 요점은, 테스트 상품이 도달할 수 있는 모든 경로를 한 번 훑어보는 것입니다. 필터링 로직 자체는 단순하지만, 적용 범위를 빠뜨리면 사고가 거기서 일어납니다.

맺음말

테스트 상품 자동 분기는 쇼핑몰처럼 상품이 많은 서비스에서 운영 노출 사고를 줄이는 실용적인 방법입니다. 상품 데이터는 한 번만 관리하고, 런타임 hostname 판별로 환경을 나눠 테스트 상품을 검수에서만 노출시키면 배포는 1회로 단순화할 수 있습니다. 다만 이 방식은 보안이 아니라 운영 사고 방지를 위한 장치라는 전제를 팀 내에 명확히 공유하는 것이 안전합니다.