질문 재정의부터 산출물 설계까지
판단이 만들어지는 방식
Case Studies는 프로젝트 뒤에 반복되는 문제 해결 방식을 보여줍니다. 모호한 질문을 판단 기준으로 바꾸고, 데이터를 리스크·우선순위 신호로 해석하며, 분석을 검토 가능한 의사결정 도구로 연결하는 과정입니다.
신호를 읽고 기준을 세운 뒤, 리뷰어가 판단 근거와 결과물을 함께 확인할 수 있게 남깁니다.
반복되는 판단 방식을 확인하는 근거
상권·공공·커머스·스포츠 분석
대시보드·웹 서비스·검증 문서
단순 분석 결과를 검토자가 보류·비교·대체 후보를 판단할 수 있는 흐름으로 재구성합니다.
판단 가능한 산출물로 이어지는 5가지 파일
각 파일은 추상적인 작업 방식이 아니라, 어떤 신호를 보고 어떤 기준으로 판단했으며 무엇을 남겼는지까지 확인할 수 있게 정리했습니다.
Decision Question Design
분석 주제를 판단 질문으로 바꾸는 방식
요구사항이 모호한 상황에서 분석 질문을 재정의할 수 있음
사고 이력이 부족한 하남교산에서도 현장 점검 우선 격자를 정해야 하는 상황
100m 격자, 공간 좌표 포함 RF, LORO, 위험 신호, Top-k 기준
안전시설 현장 검토 우선 후보
Signal-first Framing
선택을 서두르기 전에 먼저 확인할 신호를 정리하는 방식
시간 민감 신호와 데이터 신뢰 상태를 함께 설계할 수 있음
현재 유효하며 D-Day~D-3 안에 보호 종료가 가까운 공고
KST 30일, noticeEdt, days_left, source, cacheStatus, fallbackReason
current·urgent 분리, 지역별 탐색, cache/fallback 상태 패널
Actionable Segmentation
고객군을 액션과 KPI로 번역하는 방식
고객 데이터를 마케팅/CRM 실행 언어로 번역할 수 있음
고객군마다 다른 반응, 이탈, 구매 완료 신호
고객 가치, 구매 빈도, 채널 반응, 재방문 가능성
캠페인 목표, 우선 채널, 확인 KPI, A/B 테스트 제안
Data Structure Design
분석 가능한 테이블을 만드는 방식
흩어진 데이터를 분석 가능한 grain으로 재구성할 수 있음
원천 데이터만으로는 바로 판단할 수 없는 분리된 데이터 구조
조인 기준, 이벤트 정의, 분석 단위, 지표 grain
고객-오퍼 테이블, 주문-세션 지표, 재현 가능한 파이프라인
Deliverable Design
분석을 검토 가능한 산출물로 남기는 방식
분석 결과를 동료와 채용 담당자가 검토 가능한 형태로 남길 수 있음
노트북만으로는 문제, 접근, 결과, 한계를 빠르게 검토하기 어려움
문제 정의, 접근 방식, 핵심 결과, 한계, 확인 경로
README, 방법론 문서, 재현성 가이드, 대시보드, 웹 화면, 실행 파이프라인
프로젝트를 가로질러 반복되는 3가지 분석 패턴
도메인이 달라도 질문을 좁히고, 판단 신호를 설계하고, 결과를 검토 가능한 언어와 화면으로 전달하는 방식은 반복됩니다.
Risk Signal Design
무엇을 추천할지보다 먼저, 무엇을 보류·검토·비교·우선 처리해야 하는지 설명하는 신호를 설계합니다.
- Redveil의 매입 보류 사유와 대체 후보처럼 선택 전 확인 기준을 앞에 둡니다.
- LH 교통안전의 100m 위험 격자처럼 검증된 공간 신호를 현장 점검 자원 배분 기준으로 바꿉니다.
- Shelter Signal의 noticeEdt와 D-Day~D-3 분류처럼 공고 생명주기를 보호 종료 임박 신호로 번역합니다.
Decision Flow Design
분석 결과를 차트나 점수에서 멈추지 않고, 사용자가 다음 판단을 이어갈 수 있는 검토 흐름과 산출물로 연결합니다.
- Redveil의 리스크 점수·보류 사유·대체 후보를 하나의 웹 검토 순서로 연결합니다.
- Shelter Signal의 region/page API와 current·urgent view를 대량 공공데이터 탐색 흐름으로 연결합니다.
- Starbucks 분석의 고객·오퍼·채널 비교를 Tableau 대시보드와 액션 인사이트로 정리합니다.
Business / Public Interpretation
분석 지표와 모델 결과를 리뷰어가 실제 행동, 우선순위, 한계와 함께 이해할 수 있는 판단 언어로 번역합니다.
- Starbucks의 반응 지표를 어떤 고객군·오퍼·채널을 검토할지에 대한 CRM 언어로 바꿉니다.
- LH 교통안전의 LORO AUC와 Lift를 어떤 100m 격자를 먼저 검토할지 설명하는 공간 근거와 함께 제시합니다.
- Shelter Signal의 source·cacheStatus·fallbackReason처럼 공공데이터 상태와 한계를 응답과 화면에서 함께 설명합니다.
Pipeline Validation Design
live 운영 주장을 앞세우기보다, 어떤 데이터 경로가 실제로 검증됐는지 SQL tests와 dashboard로 확인 가능한 구조를 설계합니다.
- Job Signal Pipeline은 Saramin mock ingestion에서 raw.job_postings 적재, analytics views, SQL tests, Streamlit dashboard까지 한 경로로 검증합니다.
- raw와 analytics schema를 분리해 원천 응답 보존과 리뷰 가능한 business logic을 나눕니다.
- Saramin live API, production ingestion, notification 운영은 검증 범위 밖이라고 문서와 한계 섹션에서 분리합니다.