행동과 데이터 연결 — 변수의 5요소 매핑 절차 (Buisson Ch.2.2)

Behavioralize · Distrust and Verify · Identify the Category — 모호한 변수를 행동 변수로 정제하는 3 단계

Buisson (2021) Ch.2 의 §“How to Connect Behaviors and Data” 를 정리한다. 데이터에 수십~수백 개 변수가 있을 때 어디서부터 시작할지, “behavioralize” 절차로 모호한 변수를 행동 변수로 정제하는 방법, AirCnC 의 CSAT → M6Spend 사례로 변수의 5요소 매핑을 단계별로 시연한다. Sludge·Distrust and Verify·자기 진단 환자 함정 등 직관 풍부히 다룬다.

Experimentation
Causal Inference
저자

Kwangmin Kim

공개

2026년 05월 08일

1 정의

정의: Behavioralize

변수의 정의·수집·해석을 점검하여 그 변수가 측정한다고 주장하는 행동을 정말 측정하는지 검증하고 정제하는 작업. Buisson 의 신조어 (Buisson, 2021, Ch.2).

직관 — “Behavioralize” 가 왜 필요한가

기업 데이터베이스의 변수명은 흔히:

  • customer_action_rate
  • engagement_score
  • is_active_user
  • signup_completed

이 이름들이 진짜 의미하는 것은? 보장 없다. customer_action_rate 가 “고객의 행동률” 인지, “고객별 액션 횟수” 인지, “특정 액션 발생 비율” 인지 명확하지 않다.

변수명을 그대로 믿으면 안 되고, 데이터 생성 과정·비즈니스 규칙·시스템 로깅 방식을 추적해 정제(behavioralize) 해야 한다.

2 개념 및 원리 — 변수 정제의 3 단계

Buisson 은 다음 3 단계를 제안한다.

1. Develop a Behavioral Integrity Mindset (마인드셋)
        ↓
2. Distrust and Verify (변수 의심)
        ↓
3. Identify the Category (5요소 매핑)

각 단계를 자세히 본다.

3 Step 1 — Behavioral Integrity Mindset

3.1 정의

정의

변수와 데이터를 “진실 측정한 것” 이 아니라 “진실의 한 표현” 으로 보는 마인드셋. 변수를 의심하고 검증하는 자세.

3.2 직관 — 다리 점검의 비유

직관 — Buisson 의 구조 엔지니어 비유

“신임 다리 관리자” 가 된 구조 엔지니어가 두 가지 접근을 비교:

접근 A — 인치 단위 점검

  • 한쪽 끝부터 다른쪽 끝까지 cm 단위로 점검
  • 10년 후에 완벽한 구조 무결성 달성 계획
  • 그 사이 포트홀이 악화 → 차량·운전자 위험

접근 B — 우선순위 점검

  • 빠른 전체 훑기
  • 즉시 고칠 수 있는 큰 문제 우선 처리
  • 임시 처방으로 시간·예산 확보
  • 단계적 구조 개선

분석가가 데이터를 처음 만났을 때도 같다.

  • A: 모든 테이블·변수를 알파벳 순으로 검토 — 의미 있는 인사이트 도출 전에 burnout
  • B: 비즈니스 문제 정의 → 가장 관련 있는 변수부터 점검 → 우선순위로 분석

3.3 변수 점검 우선순위

비즈니스 문제가 정의되면, 변수를 다음 우선순위로 점검:

순위 변수 종류 이유
1 관심 인과·결과 변수 이게 부정확하면 모든 분석이 의미 없음
2 매개·조절 변수 (관련 시) 인과 사슬 이해의 핵심
3 잠재 confounder 인과 추정의 편향 결정
4 기타 공변량 정밀도 향상, 부차적
직관 — “What you can get away with”

UX 연구자가 Buisson 에게 한 말:

“비즈니스에서 연구자가 된다는 것은 끊임없이 ‘what you can get away with’ 를 찾는 일이다.”

분석에 변수를 포함할지 말지 — 명확한 기준은 없다. 자기 비즈니스 감각·전문성에 의존.

그러나 잘못 결정하는 명확한 방법은 있다: 결정을 안 하는 척한다. 변수는 포함되거나 안 되거나 둘 중 하나. 회피 불가. 직감이 포함 쪽이라면 다음을 문서화:

  • 포함하는지
  • 잠재 오류 원인 은 무엇인지
  • 변수를 빼면 결과가 어떻게 달라지는지 (sensitivity analysis)

이 문서화가 분석의 신뢰도를 결정한다.

4 Step 2 — Distrust and Verify

4.1 정의

정의

CustomerDidX 라는 변수가 진짜 “고객이 X 를 했음” 을 의미한다고 가정하지 않는다. 유죄 증명 전까지 의심.

4.2 직관 — 변수 명과 의미의 간극

“고객이 X 를 했다” 의 의미가 흔들리는 시나리오

customer_did_X = TRUE 가 의미할 수 있는 것:

  1. 체크박스 동의 — 고객이 fine print 를 안 읽고 자동 체크된 박스를 통과
  2. Default 처리 — 고객이 아무 응답 안 해서 default 값으로 X 설정
  3. 자기 보고 — 고객이 X 했다고 주장했지만 검증 불가
  4. 외부 데이터 구매 — 벤더가 “이 고객이 과거 X 한 적 있다” 라고 알려줌

심지어 진짜 고객이 X 를 했다 해도, 의도 는 다를 수 있다:

  1. 우리가 보낸 알림 이메일 때문에 X
  2. 페이지가 새로고침 안 돼서 4번 연속 X
  3. Y 를 의도했는데 실수로 X
  4. 일주일 전 했지만 규제 때문에 오늘 기록
직관 — The Princess Bride 의 인용

“You keep using that variable. I do not think it means what you think it means.” (Buisson 의 Inigo Montoya 패러디)

영화 명대사 “You keep using that word…” 의 변수 버전. 변수 이름과 실제 의미의 간극을 항상 의심하라.

4.3 Sludge — 의도적 friction 함정

Sludge 정의

회사가 의도적으로 사용자를 혼란시키는 friction·misleading communication. 흔히 다음 형태:

  • 폼에 이메일 입력하면 자동으로 “마케팅 이메일 수신” 박스가 다시 체크됨 (이전에 본인이 unchecked 한 후)
  • 구독 가입은 1 클릭, 해지는 7 단계
  • 가격은 큰 글씨, 추가 수수료는 fine print
  • “지금 안 사면 영원히 못 산다” 같은 가짜 긴급성

marketing_consent = TRUE 데이터가 진짜 동의를 의미하는가? Sludge 가 있으면 그 변수의 의미가 왜곡된다.

4.4 Business Behavior 가 변수 해석을 바꾸는 함정

직관 — “구매 성향 모형” 의 숨은 caveat

영업 팀이 “구매 가능성 높은” 고객 5,000명을 식별. 그들에게 전화 → 30% 구매. “구매 성향 모형 정확도 30%” 라고 보고.

함정: 모형의 진짜 caveat 은 “우리 영업 팀이 전화 결정한 사람들 안에서” 30%. 영업 팀의 전화 결정 자체가 강한 selection bias 다.

올바른 해석:

  • 영업 결정 (Business Behavior) 이 누락되면 confounder
  • 영업 보상 구조 같은 메타 변수도 영업 결정에 영향 → 캐스케이드된 confounder

영업 보상 구조는 비즈니스 의사결정자가 가장 신경 쓰는 변수임에도, 고객 행동 모형에는 거의 포함되지 않는다. 이 누락이 모형을 왜곡한다.

5 Step 3 — Identify the Category (5요소 매핑)

5.1 직관 — “이게 어느 책의 한 챕터인가” 질문

직관 — 철학 에세이의 비유

Buisson 의 대학 시절 철학 교수 조언:

에세이 주제가 너무 큰 질문 (“진보란 무엇인가?”, “인간과 기계”) 일 때 — “이 질문이 어느 더 큰 책의 한 챕터인가” 를 물어라.

분석가도 같다. 비즈니스 문제가 막막하게 클 때 — “이 문제가 5요소 모형의 어느 단계 문제인가” 를 묻는다.

5.2 AirCnC CSAT → M6Spend 사례

AirCnC 의 비즈니스 문제

AirCnC (Air Coach and Couch — 가상 여행·숙박 예약 회사) 가 분석가에게 의뢰한다.

“CSAT (고객 만족도) 가 향후 6 개월 지출 (M6Spend) 에 미치는 효과를 측정하라.”

이 질문은 책 마지막 (Ch.12) 에서 IV 회귀 1 줄로 답하지만, 지금은 framing 단계다.

매핑 절차:

변수 1: CSAT (고객 만족도)

  Personal? — 고정·영구 안 함 → 아님
  Action? — 사람이 하는 행동 아님 → 아님
  Intention? — "할 의도" 아님 → 아님
  Business? — 회사 측 행동 아님 → 아님
  Cognition·Emotion? → 매핑됨

변수 2: M6Spend (6개월 지출)

  Action — 명백히 고객의 구매 행동 → 매핑됨

비즈니스 문제 재공식화:

“Cognition·Emotion (CSAT) 이 Action (M6Spend) 에 미치는 인과적 효과는?”

직관 — 매핑이 분석을 바꾸는 이유

매핑 전: “CSAT 와 매출의 관계는?” — 모호. 회귀? 상관? 인과?

매핑 후: “Cognition → Action 의 인과 효과” — 명확. 인과 분석 도구 (RCT, IV, mediation) 가 자동으로 떠오른다.

5요소 모형은 추상 개념이 아니라 분석 결정의 가이드. 어떤 도구를 쓸지 매핑이 결정한다.

5.3 비즈니스 파트너의 “자기 진단 함정”

“Self-diagnosing patient” 함정

Buisson 의 개인 사례:

비즈니스 파트너가 “직원들이 특정 교육을 듣게 해달라” 요청.

분석가의 첫 반응은 “교육 참여율 데이터를 보자” — 직원의 행동 (Action) 분석.

대화 후 진짜 문제는 다른 것이었다:

비즈니스 파트너가 진짜 원한 것: 직원이 특정 비즈니스 규칙을 준수.

그녀의 가설: “직원들이 규칙을 모르니 준수 못 한다.”

그래서 “교육을 듣게 하면 알게 되어 준수할 것” 이라고 자기 진단.

올바른 분석 방향: “왜 직원들이 준수하지 않는가” 를 먼저 답한다. 진짜 이유가 무지가 아니라 다른 데 있다면 (예: 규칙이 비현실적, 시스템적 friction, 인센티브 미스매치), 교육은 무의미.

직관 — “환자가 의사를 자기 진단 결과로 끌고 가게 두지 말라”

의사·환자 비유:

  • 환자: “감기약 처방해 주세요” (자기 진단 + 처방까지 제시)
  • 의사: 진짜 진단 (인플루엔자, 알레르기, 코로나 등) 을 먼저 한다

분석가도 비즈니스 파트너의 자기 진단을 그대로 받지 말고, 5요소 매핑부터 다시 해야 한다.

매핑 후 발견:

  • “교육 부족” → 가설 (Cognition 단계 처치)
  • “규칙 자체의 문제” → Business Behavior 단계 처치
  • “인센티브 미스매치” → Business Behavior + Personal 상호작용

→ 진짜 원인이 어디에 있는지에 따라 처방이 완전히 달라진다.

5.4 “Engagement” 의 두 의미 (재방문)

Engagement 의 두 가지 의미

비즈니스에서 “engagement” 는 두 의미로 혼용된다.

  1. Action 으로서의 engagement: 사용자가 더 자주 로그인, 더 오래 머물, 더 많은 기능 사용
  2. Cognition·Emotion 으로서의 engagement: 사용자가 몰입·즐기·관심

이 둘이 분리되지 않으면:

  • “engagement 를 높이자” 의 처방이 모호
  • 행동적 engagement 만 높이면 (예: 알림으로 강제 재방문) 감정적 engagement 는 떨어질 수 있음
직관 — Buisson 의 세탁기 비유

“내 세탁기가 고장났을 때 나는 세탁기와 더 ‘engaged’ 되어 있다 — 첫 번째 의미로.”

세탁기와 더 자주 상호작용 (수리·전화·검색) 하지만, 세탁기에 더 만족하지는 않는다 (오히려 정반대).

비즈니스 적용:

  • 앱 사용자가 알림 폭격으로 더 자주 들어오게 만든다 → 첫 번째 의미 engagement ↑
  • 실제 만족도·충성도 → 떨어짐 (또는 변화 없음)
  • 단기 KPI 는 좋아 보이지만 장기 이탈률 ↑

engagement 가 KPI 면 정확히 어느 의미인지 명시해야 한다. 아니면 잘못된 처방을 낳는다.

6 왜 필요한가 — 매핑이 분석 도구 선택을 결정

매핑 → 도구 선택의 흐름
변수 매핑 적합한 도구
Personal → Action 인구통계 segment 분석, 매칭 (matching)
Cognition → Intention NPS·CSAT 와 행동 의도 설문 분석
Intention → Action 의도-행동 간극 분석, friction 분석
Business → Action A/B 테스트, RCT
Cognition → Action IV 회귀, mediation 분석 (Buisson Ch.12)

매핑 없이 회귀만 돌리면 “어떤 도구로 인과를 추론할지” 가 떠오르지 않는다.

7 응용 분야 — 매핑 절차 실무 사례

7.1 사례 1: 이커머스 — “장바구니 이탈”

원래 질문: "왜 장바구니 이탈이 늘어나나?"

Step 1: Behavioral Integrity — "장바구니 이탈" 변수 점검
  - 변수 정의: 결제 페이지 진입 후 5분 내 종료
  - 검증: 실수로 닫은 사용자 vs 정말 이탈 사용자 구분 가능?

Step 2: Distrust and Verify — 데이터 추적
  - 결제 단계 페이지뷰 로그 + 시간 stamp 분석
  - 이탈 시점 패턴 발견: 특정 결제수단 선택 화면 직후 이탈 폭증

Step 3: Identify Category
  - "이탈" = Action
  - "이탈 원인" — 어디 단계?
    - 결제 화면 디자인 (Business Behavior)
    - 결제 페이지의 신뢰 결여 (Cognition)
    - 결제수단 선호 (Personal)

분석 방향:
  - Business Behavior 가설 → A/B 테스트로 결제 페이지 redesign
  - Cognition 가설 → 사용자 인터뷰 + survey
  - Personal 가설 → 결제수단별 이탈률 segment 분석

7.2 사례 2: HR — “직원 retention”

원래 질문: "고성과자 retention 을 어떻게 올리는가?"

Step 1: 변수 점검
  - "retention" = 1년 후 재직 (Action)
  - "고성과자" = 평가 점수 상위 20% (Action 의 누적)

Step 2: Distrust and Verify
  - 평가 점수의 정의 — 매니저 주관 vs 객관 KPI?
  - 매니저별 평가 분포 점검 — 평가 자체가 confounder?

Step 3: Identify Category
  - 고성과 → 이직 의도 → 이직 행동 의 인과 사슬
  - 비즈니스 파트너의 자기 진단: "보상이 부족해서" → Business Behavior 처치
  - 진짜 원인 가능성: Cognition (성장 정체감) 또는 Personal (커리어 단계)

분석 방향:
  - Exit interview 의 자기 보고 (Cognition) — introspection illusion 주의
  - 외부 잡 시장 활동 (Action) — 진짜 의도의 proxy
  - Business Behavior (보상·승진·매니저) 와의 매칭 분석

8 코드 예시 — 변수 매핑 결정 워크플로우

import pandas as pd
from typing import Dict, List, Optional

class VariableInspection:
    """Buisson 의 3 단계 변수 점검 워크플로우."""

    def __init__(self, name: str, raw_definition: str):
        self.name = name
        self.raw_definition = raw_definition
        self.is_inspected = False
        self.category: Optional[str] = None
        self.suspicion_flags: List[str] = []
        self.behavioral_definition: Optional[str] = None

    def step1_behavioral_integrity(self, business_problem: str):
        """비즈니스 문제 우선순위에서 이 변수의 위치."""
        priority_levels = {
            "primary_cause_or_outcome": 1,
            "mediator_or_moderator": 2,
            "potential_confounder": 3,
            "covariate": 4,
        }
        # 분석가가 결정 (judgment call)
        return self

    def step2_distrust_and_verify(self):
        """변수 정의의 함정 점검."""
        suspicion_patterns = {
            "default_assignment": "사용자 응답 없을 때 default 처리?",
            "checkbox_consent": "체크박스 자동 체크?",
            "self_reported": "자기 보고 vs 검증된 행동?",
            "external_purchased": "외부 벤더 데이터?",
            "intent_not_action": "의도 vs 실제 행동 구분?",
            "delayed_logging": "기록 시점이 행동 시점과 다름?",
            "sludge": "Sludge — 의도적 friction?",
        }
        # 각 패턴에 대해 점검
        for code, question in suspicion_patterns.items():
            print(f"  [{code}] {question}")
        # 분석가가 답변 후 flag 추가
        return self

    def step3_identify_category(self) -> str:
        """5요소 매핑 — 소거법."""
        questions = [
            ("Personal? (변하지 않거나 매우 천천히 변하는가)", "Personal"),
            ("Cognition? (생각·감정·태도)", "Cognition"),
            ("Intention? (할 의도)", "Intention"),
            ("Action? (관찰 가능한 행동)", "Action"),
            ("Business? (회사가 통제하는 변수)", "Business"),
        ]
        # 소거법으로 매핑
        return self.category


# AirCnC CSAT 사례
csat = VariableInspection(
    name="csat_score",
    raw_definition="고객 만족도 1~10 점 평가",
)

print(f"=== {csat.name} 점검 ===\n")

print("Step 1 — Behavioral Integrity:")
csat.step1_behavioral_integrity("CSAT 가 6개월 지출에 미치는 영향")
print("  → 1순위 (관심 인과 변수)\n")

print("Step 2 — Distrust and Verify:")
csat.step2_distrust_and_verify()
csat.suspicion_flags = ["self_reported"]
print(f"  → flags: {csat.suspicion_flags}\n")

print("Step 3 — Identify Category:")
csat.category = "Cognition"
print(f"  → category: {csat.category}\n")
직관 — 이 코드의 의미

3 단계가 단순하지 않다. 매 단계가 분석가의 판단 을 요구한다.

  • Step 1: 우선순위 결정 (어떤 변수를 먼저 점검할지)
  • Step 2: 변수의 잠재 함정 점검
  • Step 3: 5요소 매핑 결정

코드는 체크리스트 수준 이고, 진짜 분석은 사람의 비즈니스 감각·도메인 지식·인과 추론 직관에서 나온다. 자동화 불가.

→ Buisson 의 책 가치: 이 판단을 위한 명확한 프레임워크 제공.

9 코드 예시 — Sludge 점검 자동화 시도

def detect_potential_sludge(form_html: str) -> List[str]:
    """폼 HTML 에서 sludge 패턴 자동 감지 (휴리스틱)."""
    sludges = []

    # 1. 자동 체크박스 (사용자 입력 후 체크 변경)
    if "checked" in form_html.lower() and "marketing" in form_html.lower():
        sludges.append("자동 체크된 마케팅 동의 박스 — 진짜 동의 의심")

    # 2. fine print 스타일
    if "font-size: 0.7em" in form_html or "color: #ccc" in form_html:
        sludges.append("작거나 흐릿한 글씨로 중요 정보 표시 — fine print sludge")

    # 3. 부정적 옵션이 default 배치
    if 'value="opt_in" checked' in form_html.lower():
        sludges.append("Opt-in 이 default — 사용자 의식 없이 동의 처리 가능")

    return sludges


# 가상 폼 점검
form = '''
<input type="checkbox" name="marketing_consent" checked>
<span style="font-size: 0.7em">By checking, you agree to terms and...</span>
<input type="radio" name="data_share" value="opt_in" checked>
'''

sludges = detect_potential_sludge(form)
print("감지된 sludge 패턴:")
for s in sludges:
    print(f"  - {s}")
직관 — Sludge 자동 감지의 한계

이 휴리스틱은 명백한 패턴만 잡는다. 정교한 sludge — 예를 들어 결제 페이지의 흐름이 의도적으로 길게 설계된 경우 — 는 자동으로 감지 안 된다. 결국 사용자 인터뷰 + qualitative 분석 으로 보완해야 한다.

그러나 자동 감지의 의미는 작지 않다. 회사 내 데이터 수집 폼·UI 를 정기 점검 하는 도구로서 가치가 있다. “우리도 모르게 sludge 를 만들고 있는가?” 의 질문에 1차 답을 준다.

10 관련 주제

10.1 Ch.2 의 형제 글

10.2 후속 챕터

10.4 카테고리 진입점

Subscribe

Enjoy this blog? Get notified of new posts by email: