brunch

7장. 이해관계자 인터뷰 스크립트

운영/마케팅/개발/CS

by jeromeNa

인터뷰 개요


이해관계자 인터뷰는 각 부서의 관점을 하나의 설계 언어로 통합하기 위한 과정이다. 질문은 단순히 확인이 아니라, 실제 업무 기준과 시스템 제약을 명확히 드러내기 위한 수단이다.


이 장은 각 부서별로 실무에서 바로 사용할 수 있는 인터뷰 템플릿으로 구성되어 있다.


질문은 구체적 예시를 포함해 작성되었으며, 인터뷰 진행자는 이를 기반으로 실시간 대화를 기록하고 후속 액션을 도출한다.


인터뷰 진행 구조 (30분 기준)


맥락 공유 (5분)
프로젝트의 목표와 인터뷰의 목적을 간략히 설명한다. 예를 들어 “오늘은 결제와 상품 탐색 구조를 구체화해 FO·BO 연동 기준을 확정하려 합니다.”처럼 논의 범위를 분명히 한다.

질문 및 답변 (20분)
3~4개의 핵심 주제를 중심으로 질문을 진행한다. 모호한 답변이 나오면 “구체적인 예시로 설명해주실 수 있을까요?”로 다시 묻는다.

정리 및 합의 (5분)
요약과 확인으로 마무리한다. 명확하지 않은 답변은 ‘후속 질문’ 목록에 남긴다.

개발팀 인터뷰 스크립트


개발팀 인터뷰의 목적은 기술적 제약과 데이터 스키마, 성능, 보안 정책 등 시스템 구조의 근간을 명확히 정의한다.


질문 1. 상품 탐색 스키마 정의

질문: 상품 탐색 스키마는 어떤 구조로 설계할 계획인가요?

카테고리 구조는 몇 단계(depth)까지 구성하나요?
예: 상위 카테고리 → 중위 카테고리 → 하위 카테고리 형태.
예: 의류 → 상의 → 티셔츠 / 뷰티 → 스킨케어 → 토너

BO 등록 시 하위 카테고리까지 필수 선택하도록 하나요?
예: ‘상의’까지만 필수인지, ‘티셔츠’까지 필수인지

FO 필터에서 노출할 상품 속성은 어떤 항목인가요?
예: 공통 속성 = 가격대, 브랜드, 색상 / 카테고리별 속성 = 의류는 재질·핏·시즌, 뷰티는 피부타입·용량·성분 등

각 속성은 단일 선택인가요, 복수 선택(체크박스)인가요?

정렬 기준은 어떤 순서를 따르나요?
예: 인기순, 신상품순, 낮은 가격순, 높은 가격순 중 기본값 설정 기준

‘인기순’은 어떤 데이터로 계산하나요?
예: 최근 7일 판매량, 누적 조회수, 찜 수 등


예상 답변 예시: “카테고리는 3depth로 구성하고, BO 등록 시 최하위까지 필수 선택합니다. FO 필터는 카테고리별 속성을 다르게 구성하되 가격·브랜드·색상은 공통으로 노출합니다. 정렬 기본값은 최근 7일간 판매량 기준 인기순입니다.”


후속 확인:

BO 상품 등록 시 카테고리 선택 UI는 드롭다운 3단 구조인가요, 트리형 구조인가요?
속성 추가·수정은 BO 내에서 가능해야 하나요?


질문 2. 간편결제 우선순위 및 대체 플로우

질문: 결제 수단의 구성과 우선순위는 어떻게 설정하나요?

PG 기준으로 제공 가능한 간편결제 수단은 무엇인가요?
예: 네이버페이, 카카오페이, 페이코, 토스페이

애플페이·구글페이는 별도 계약이 필요한가요?

PG 장애가 발생할 경우, 백업 PG 또는 수기 주문 프로세스가 있나요?
예: CS팀이 전화로 주문을 받고, BO에서 직접 등록 가능 여부

결제 실패 시 FO 화면에서 바로 재시도 기능을 제공하나요?

실패 사유(비밀번호 오류, 카드 정지 등)에 따라 안내 문구가 다르게 표시되나요?


예상 답변 예시: “네이버페이와 카카오페이는 기본 연동, 애플페이·구글페이는 별도 계약 필요합니다. PG 장애 시 백업 PG는 없으며, CS팀이 BO에서 수기 주문 등록으로 대응할 수 있습니다. 결제 실패 시 FO에서 재시도 가능하며, PG 응답 코드에 따라 실패 문구를 구분 표시합니다.”


후속 확인:

수기 주문 등록 화면에는 어떤 항목이 필요하나요? (고객명, 상품명, 금액, 결제 수단 등)
간편결제 버튼 노출 순서는 수수료 또는 사용률 기준 중 어느 쪽인가요?



질문 3. 측정 계획 및 주요 지표

질문: 측정은 어떤 지점에서 이루어지나요?

GA4 전자상거래 이벤트는 어디에 심나요?
view_item, add_to_cart, begin_checkout, purchase 등 필수 이벤트 + view_item_list, view_promotion, refund 같은 추가 이벤트

NSM(월 거래액)은 어떤 기준으로 계산하나요?
총 주문 금액 – 취소/환불 금액 or 결제 완료 금액 등

대시보드는 어디에서 관리하나요? (GA4, Looker Studio, BO 내부 통계 등)

A/B 테스트는 어떤 도구로 운영할 예정인가요?
예: 자체 분기 처리 or 외부 툴 사용


예상 답변 예시: “GA4 이벤트는 상품 상세, 장바구니, 결제, 구매 완료 화면에 심습니다. 배너 클릭과 환불 이벤트를 추가로 측정하고, NSM은 결제 완료 금액 기준으로 집계합니다. 대시보드는 Looker Studio 기반으로 주간 단위로 관리합니다.”


후속 확인:

이벤트 태깅은 개발팀이 직접 담당하나요, 마케팅팀이 GTM으로 관리하나요?
BO 통계에 포함되어야 할 지표(거래액, 전환율, 이탈률)는 어떤 항목인가요?



질문 4. 이미지·미디어 정책

질문: 상품 이미지와 미디어 파일의 관리 기준은 어떻게 설정하나요?

업로드 시 자동 변환(WebP, AVIF)은 서버에서 처리하나요?
예: 원본 업로드 후 서버 변환 / 클라이언트 사전 변환

썸네일, 중간, 원본 이미지는 각각 몇 px로 리사이징하나요?
예: 썸네일 400px, 중간 800px, 원본 유지

CDN은 어떤 서비스를 사용할 예정인가요? (CloudFront, Cloudflare 등)

캐시 정책은 어떻게 관리하나요?
예: 수정 후 즉시 반영 vs 24시간 유지

동영상은 어떤 방식으로 지원하나요?
예: 유튜브 임베드만 허용 / 직접 업로드 가능 여부 / 용량 제한 등


예상 답변 예시: “업로드 시 서버에서 WebP 변환, 썸네일 400px, 중간 800px, 원본은 그대로 유지합니다. CDN은 CloudFront를 사용하며, 캐시는 24시간 유지합니다. 동영상은 1차 버전에서는 유튜브 임베드만 허용하고, 직접 업로드는 추후 기능으로 추가 예정입니다.”


후속 확인:

BO 업로드 화면에서 변환 상태를 표시해야 하나요?
이미지 alt 텍스트 입력을 필수 항목으로 지정해야 하나요?


운영팀 인터뷰 스크립트


운영팀은 BO의 주 사용자로, 상품 등록, 재고 관리, 주문·배송 등 일상적인 운영의 효율을 결정한다.


질문 5. 콘텐츠 등록 체계

질문: 상품 등록은 어떤 흐름으로 이루어지나요?

촬영, 편집, 등록은 각각 누가 담당하나요?
예: 외주 촬영 / 내부 등록 등

상품명과 상세설명은 운영팀이 직접 작성하나요, 브랜드에서 제공하나요?

한 번의 등록 주기(예: 주 2회 등록 시)당 몇 개 상품을 처리하나요?

상품당 평균 등록 소요 시간은 얼마인가요?

CSV나 ZIP 파일을 통한 일괄 업로드 기능이 필요한가요?


예상 답변 예시: “촬영은 외주, 편집과 등록은 내부 담당입니다. 1회당 15~20개 상품을 등록하며, 상품당 평균 30분 정도 소요됩니다. CSV 업로드 기능이 있으면 등록 시간을 절반으로 줄일 수 있습니다.”


후속 확인:

CSV 템플릿 항목은 SKU, 카테고리, 상품명, 가격, 옵션, 재고 등이 포함되어야 하나요?
업로드 후 형식 검증(누락, 중복 등)이 필요한가요?


질문 6. 재고·입출고 관리

질문: 재고는 어떤 시점에서 차감하나요?

주문 완료, 결제 완료, 출고 시점 중 어느 단계인가요?

미결제 주문이 일정 시간 후 자동 취소되면 재고는 복구되나요?

옵션별 품절은 FO에서 어떻게 표시되나요?
예: 선택 불가 / 회색 처리 / 품절 배지 표시 등

재입고 알림 기능은 제공하나요?
예: 자동 알림 or BO에서 수동 발송


예상 답변 예시: “재고는 결제 완료 시 차감하고, 미결제 주문은 30분 후 자동 취소 시 복구됩니다. 옵션별 품절은 FO에서 비활성 처리하며, 재입고 알림은 추후 기능으로 예정되어 있습니다.”


후속 확인:

BO에서 재고를 일괄 조정하는 기능이 필요한가요?
안전재고를 설정해 FO 노출 수량을 제한하나요?


질문 7. 배송 정책

질문: 배송비 정책과 출고 기준은 어떻게 운영하나요?

기본 배송비는 얼마인가요?

무료배송 기준 금액은 얼마인가요?

도서산간, 제주 지역 추가 요금은 얼마인가요?

출고 마감 시간은 몇 시로 설정할 계획인가요?

주말·공휴일 주문은 언제 출고되나요?

부분 배송은 허용하나요? (예: 일부 상품만 먼저 출고 가능 여부)


예상 답변 예시: “기본 배송비는 3,000원, 3만 원 이상 무료 배송입니다. 도서산간 지역은 3,000원, 제주도는 5,000원 추가 요금이 있습니다. 출고 마감은 평일 오후 4시이며, 주말 주문은 월요일 출고합니다. 부분 배송은 1차에서는 비활성화하고, 전체 출고만 허용합니다.”


후속 확인:

FO 결제 화면에서 배송비 자동 계산이 가능한가요?
배송비 정책은 BO에서 수정할 수 있어야 하나요?


마케팅팀 인터뷰 스크립트


마케팅팀은 쿠폰, 프로모션, 배너, 리텐션 전략 등 고객 유입과 유지, 재구매 전환을 설계한다.


질문 8. 쿠폰 정책

질문: 쿠폰의 종류와 적용 규칙은 어떻게 설정하나요?

신규가입, 첫 구매, 재구매, 이벤트 쿠폰 등 각 유형의 발급 조건은 무엇인가요?

쿠폰 적용 범위는 전체 상품인가요, 특정 카테고리·브랜드로 제한되나요?

세일 상품에는 쿠폰을 사용할 수 있나요?

한 번의 결제에서 여러 장 쿠폰을 중복 사용할 수 있나요?

적립금과 쿠폰을 동시에 사용할 수 있나요?


예상 답변 예시: “신규가입 시 10% 자동 쿠폰 발급, 첫 구매는 3만 원 이상 시 5,000원 할인, 재구매 쿠폰은 회원 등급별(실버 5%, 골드 10%, VIP 15%) 차등 지급. 세일 상품은 쿠폰 제외, 1회 결제 시 1매만 사용 가능하며 적립금과 동시 사용 가능합니다.”


후속 확인:

BO 쿠폰 생성 시 필요한 항목(할인금액, 최소결제금액, 유효기간 등)은 무엇인가요?
쿠폰 사용 내역과 잔여 수량은 BO에서 확인 가능한가요?


질문 9. 리텐션 및 알림 운영

질문: 리텐션(재방문 유도)과 알림은 어떤 채널로 운영하나요?

이메일, 푸시, SMS 중 어떤 채널을 사용하나요?

장바구니 이탈 알림은 몇 시간 후 발송하나요?
예: 장바구니 담은 후 24시간 경과 시 푸시 발송

알림에 할인 혜택을 포함하나요?

마케팅 정보 수신 동의는 언제 받고, FO 마이페이지에서 채널별 수신 거부가 가능한가요?


예상 답변 예시: “푸시와 이메일을 중심으로 운영하며, SMS는 배송 알림용으로만 사용합니다. 장바구니 이탈 알림은 24시간 후 발송하고, 별도 할인 혜택은 없습니다. 가입 시 마케팅 수신 동의를 받고, 마이페이지에서 채널별 수신 거부가 가능합니다.”


후속 확인:

알림 템플릿은 BO에서 작성하나요, 외부 툴(Braze 등)을 사용하나요?
예약 발송 기능이 필요한가요?



CS팀 인터뷰 스크립트


CS팀은 주문, 반품, 교환, 환불 등 고객 대응 전반을 담당한다.

이 단계에서의 질문은 FO 마이페이지 구조와 BO 주문 관리 화면 설계의 기준이 된다.


질문 10. 교환·반품 정책

질문: 교환 및 반품 정책은 어떻게 설정하나요?

반품 가능한 기간과 조건은 어떻게 되나요? (예: 배송 완료 후 7일 이내, 미사용 상품 등)

단순 변심 시 배송비는 고객 부담인가요, 판매자 부담인가요?

하자 상품일 경우 처리 방식은 어떻게 되나요?

부분 반품은 가능한가요? (예: 2개 주문 중 1개만 반품)

회수는 자동 택배 예약으로 진행하나요, 고객이 직접 발송하나요?

환불은 어떤 시점에 이루어지나요? (검수 완료 후 / 승인 즉시)


예상 답변 예시: “반품은 배송 완료 후 7일 이내, 태그 제거 전까지 가능합니다. 단순 변심은 왕복 6,000원 고객 부담, 하자 상품은 판매자 부담. 부분 반품 가능하며, 고객이 직접 회수 택배를 보내고 검수 완료 후 3영업일 이내 환불합니다.”


후속 확인:

BO에서 반품 승인/거절 버튼과 사유 입력 기능이 필요한가요?
반품 상품 재입고는 검수 완료 시 자동 복구되나요?


인터뷰 기록 예시


[개발팀 인터뷰 - 2025.01.20]

Q1. 상품 탐색 스키마
- 3depth 구조, 최하위까지 필수 선택
- 공통 필터: 가격·브랜드·색상
- 카테고리 속성: 의류(핏, 재질), 뷰티(피부타입, 용량)
- 정렬: 최근 7일 판매량 기준 인기순
→ 액션: 카테고리 트리 UI 설계, 속성 관리 화면 추가


인터뷰 답변은 이후 8장에서 유스케이스(“~할 수 있다”) 형태로 전환되고, 각 기능의 수용 기준(AC) 은 Given–When–Then 구조로 작성한다. 각 유스케이스에는 “출처: 개발팀 인터뷰(1/10)” 형태로 근거를 명시하여 요구사항의 추적성을 확보한다.


큰 프로젝트일 경우 요구사항 수집과 분석을 별도의 프로젝트로 발주하는 경우가 있다. 그만큼 요구사항 분석은 중요한 요소이다. 요구사항 분석이 미흡하거나 잘못될 경우 프로젝트 자체가 망가지거나, 최악의 경우 폐기될 수도 있다.


대면이건 서면이건 인터뷰를 통해 요구사항을 명확히 하는 작업은 반드시 필요하다. 타인이 됐건 자신이 됐건 정확히 무엇을 원하는지가 명확해야 명확한 결과가 나올 수 있다.




keyword