subinz 님의 블로그

AARRR 프레임워크

subinz — Wed, 5 Aug 2026 14:51:05 +0900

AARRR 프레임워크란? 사용자 여정을 5단계로 분석하는 방법

서비스가 성장하려면 단순히 사용자를 많이 모으는 것만으로는 부족하다.

사용자가 어디에서 유입되고, 서비스의 가치를 경험하고, 다시 돌아오며, 결제하고, 다른 사람에게 추천하는지까지 전체 흐름을 확인해야 한다.

이러한 사용자 여정을 5단계로 나누어 분석하는 프레임워크가 AARRR이다.

AARRR이란?

AARRR은 다음 다섯 단계의 앞 글자를 딴 이름이다.

Acquisition → Activation → Retention → Revenue → Referral
유입 → 활성화 → 유지 → 수익 → 추천

해적의 외침인 AARRR과 비슷하다고 해서 해적 지표(Pirate Metrics)라고도 부른다.

단계핵심 질문

Acquisition	사용자는 어디에서 들어오는가?
Activation	사용자가 서비스의 가치를 경험했는가?
Retention	사용자가 다시 돌아오는가?
Revenue	사용자가 수익을 발생시키는가?
Referral	사용자가 다른 사람에게 추천하는가?

1. Acquisition: 유입

Acquisition은 사용자가 어떤 경로를 통해 서비스에 들어왔는지를 확인하는 단계다.

대표적인 유입 경로에는 검색, 광고, SNS, 커뮤니티, 추천 링크 등이 있다.

대표 지표

신규 방문자 수
회원가입자 수
채널별 유입 수
광고 클릭률
사용자 획득 비용
회원가입 전환율

회원가입 전환율
= 회원가입자 수 ÷ 방문자 수 × 100

예를 들어 광고를 통해 1,000명이 방문하고 100명이 가입했다면 회원가입 전환율은 10%다.

100 ÷ 1,000 × 100 = 10%

Acquisition 단계에서는 단순히 유입량만 보는 것이 아니라, 어떤 채널에서 가치 있는 사용자가 들어오는지를 확인해야 한다.

2. Activation: 활성화

Activation은 사용자가 서비스의 핵심 가치를 처음 경험했는지를 확인하는 단계다.

회원가입만 했다고 해서 사용자가 서비스의 가치를 경험한 것은 아니다.

따라서 서비스마다 활성화 행동을 별도로 정의해야 한다.

서비스별 활성화 행동 예시

서비스활성화 행동

쇼핑몰	첫 상품 조회 또는 장바구니 추가
음악 서비스	첫 음악 재생
채용 플랫폼	첫 채용공고 조회
숙박 서비스	첫 숙소 검색
협업 도구	첫 프로젝트 생성
학습 서비스	첫 강의 수강

대표 지표

핵심 기능 사용률
첫 행동 완료율
온보딩 완료율
가입 후 첫 행동까지 걸린 시간
활성화 전환율

활성화 전환율
= 활성화 사용자 수 ÷ 신규 가입자 수 × 100

가입자 100명 중 60명이 핵심 기능을 사용했다면 활성화 전환율은 60%다.

Activation은 AARRR에서 특히 중요한 단계다. 사용자가 서비스의 가치를 경험하지 못하면 다시 방문하거나 결제할 가능성도 낮기 때문이다.

3. Retention: 유지

Retention은 사용자가 한 번 이용한 뒤 다시 서비스로 돌아오는지를 확인하는 단계다.

신규 사용자가 많아도 대부분 한 번만 사용하고 떠난다면 서비스가 안정적으로 성장하기 어렵다.

대표 지표

재방문율
재구매율
DAU, WAU, MAU
이탈률
코호트별 리텐션
Classic, Range, Rolling Retention

리텐션
= 재방문 사용자 수 ÷ 최초 사용자 수 × 100

예를 들어 가입자 100명 중 7일 뒤 20명이 다시 방문했다면 7일 리텐션은 20%다.

Retention 단계에서는 전체 사용자 평균만 보는 것보다 가입 시점이 같은 사용자를 코호트로 묶어 비교하는 것이 좋다.

4. Revenue: 수익

Revenue는 사용자가 실제로 매출이나 이익을 발생시키는지를 확인하는 단계다.

사용자가 서비스를 자주 이용해도 결제로 이어지지 않는다면 사업 성과로 연결되기 어렵다.

대표 지표

구매 전환율
매출
객단가
사용자당 평균 매출
고객 생애가치
유료 구독 전환율
재구매율

구매 전환율
= 구매 사용자 수 ÷ 전체 사용자 수 × 100

사용자 1,000명 중 50명이 구매했다면 구매 전환율은 5%다.

50 ÷ 1,000 × 100 = 5%

Revenue 단계에서는 단순 매출뿐만 아니라 한 명의 사용자가 장기적으로 얼마나 많은 가치를 만드는지를 함께 확인해야 한다.

5. Referral: 추천

Referral은 기존 사용자가 다른 사람에게 서비스를 추천하는지를 확인하는 단계다.

사용자가 자발적으로 서비스를 공유하고 새로운 사용자를 데려온다면 광고비를 크게 늘리지 않고도 성장할 수 있다.

대표 지표

추천 링크 공유 수
초대 발송 수
추천 가입자 수
바이럴 계수
추천 전환율
리뷰 및 후기 작성률

추천 전환율
= 추천을 통해 가입한 사용자 수
  ÷ 추천 링크 방문자 수 × 100

추천 기능은 단순히 버튼을 추가한다고 활성화되지 않는다.

사용자가 먼저 서비스에 만족해야 다른 사람에게 추천할 가능성이 높아진다. 따라서 Referral은 Retention과 밀접하게 연결되어 있다.

AARRR 분석 예시

온라인 쇼핑몰을 AARRR로 분석하면 다음과 같이 구성할 수 있다.

단계사용자 행동대표 지표

Acquisition	광고를 클릭하고 쇼핑몰 방문	채널별 방문자 수
Activation	상품을 조회하거나 장바구니에 추가	장바구니 추가율
Retention	며칠 뒤 다시 방문	7일 재방문율
Revenue	상품 구매	구매 전환율, 매출
Referral	친구에게 상품 링크 공유	공유 수, 추천 가입률

사용자 1,000명이 방문한 뒤 다음과 같이 행동했다고 가정해 보자.

방문             1,000명
회원가입           300명
장바구니 추가       150명
재방문              60명
구매                30명
추천                 5명

이 데이터를 통해 어느 단계에서 사용자가 많이 이탈하는지 확인할 수 있다.

예를 들어 가입자는 많지만 장바구니 추가 사용자가 적다면 유입보다 Activation 단계의 개선이 우선일 수 있다.

AARRR은 반드시 순서대로 진행될까?

AARRR은 사용자 여정을 이해하기 위한 프레임워크지만, 모든 사용자가 정확히 같은 순서로 행동하는 것은 아니다.

사용자는 다음과 같이 움직일 수도 있다.

유입 → 구매 → 재방문 → 추천

또는 구매하지 않은 상태에서 서비스를 먼저 추천할 수도 있다.

따라서 AARRR을 절대적인 순서로 보기보다, 사용자의 주요 행동을 단계별로 구분하는 기준으로 사용하는 것이 좋다.

또한 Revenue와 Referral의 순서를 바꾸어 AARRR을 다음과 같이 설명하는 경우도 있다.

Acquisition → Activation → Retention → Referral → Revenue

중요한 것은 단계의 순서보다 각 단계에서 어떤 사용자 행동을 측정할 것인지 명확하게 정하는 것이다.

분석할 때 주의할 점

지표를 너무 많이 설정하지 않는다

각 단계마다 지표를 많이 설정하면 오히려 어떤 지표가 중요한지 알기 어려워진다.

단계별로 핵심 지표를 한두 개 먼저 선택하는 것이 좋다.

Activation 행동을 명확하게 정의한다

Activation을 단순 회원가입으로 설정하면 실제로 가치를 경험한 사용자를 구분하기 어렵다.

서비스의 핵심 기능을 처음 사용한 행동을 기준으로 설정해야 한다.

단계별 전환율을 함께 확인한다

각 단계의 사용자 수만 보는 것보다 이전 단계에서 다음 단계로 얼마나 이동했는지 확인해야 한다.

단계별 전환율
= 다음 단계 사용자 수 ÷ 이전 단계 사용자 수 × 100

전체 평균만 보지 않는다

유입 채널, 가입 시기, 사용자 유형에 따라 성과가 다를 수 있다.

따라서 채널별·코호트별·사용자 그룹별로 나누어 분석하는 것이 좋다.

마무리

AARRR은 사용자가 서비스에 들어온 순간부터 추천과 수익으로 이어지는 과정을 분석하는 프레임워크다.

Acquisition → 어떻게 들어왔는가?

Activation → 핵심 가치를 경험했는가?

Retention → 다시 돌아오는가?

Revenue → 수익을 발생시키는가?

Referral → 다른 사람에게 추천하는가?

AARRR 분석의 목적은 모든 지표를 한꺼번에 높이는 것이 아니다.

현재 사용자 여정에서 가장 큰 문제가 발생하는 단계가 어디인지 찾고, 해당 단계를 우선적으로 개선하는 것이 핵심이다.

리텐션 - classic, range, rolling

subinz — Wed, 5 Aug 2026 14:46:32 +0900

리텐션 분석의 3가지 방법: Classic, Range, Rolling Retention

서비스에 들어온 사용자가 시간이 지난 뒤에도 다시 돌아오는지를 보여주는 지표가 리텐션(Retention)이다.

신규 사용자가 계속 유입되더라도 대부분 한 번만 이용하고 떠난다면 서비스가 안정적으로 성장하기 어렵다. 따라서 사용자 수뿐만 아니라 얼마나 많은 사용자가 다시 돌아오는지를 함께 확인해야 한다.

리텐션이란?

리텐션은 처음 서비스를 이용한 사용자 중 일정 시간이 지난 뒤 다시 서비스를 이용한 사용자의 비율이다.

리텐션 = 재방문 사용자 수 ÷ 최초 사용자 수 × 100

예를 들어 가입자 100명 중 7일 뒤 다시 서비스를 이용한 사용자가 20명이라면 리텐션은 20%다.

리텐션을 계산하려면 먼저 두 가지 행동을 정해야 한다.

시작 이벤트: 회원가입, 앱 설치, 첫 구매 등
재방문 이벤트: 앱 실행, 상품 조회, 구매 등

사용자가 시작 이벤트를 수행한 날을 Day 0이라고 한다.

1. Classic Retention

Classic Retention은 사용자가 정확히 N일 차에 다시 방문했는지를 측정하는 방식이다.

N-Day Retention이라고도 한다.

예를 들어 Day 7 Classic Retention은 가입 후 정확히 7일 차에 다시 방문한 사용자의 비율이다.

Day 7 Classic Retention
= 정확히 7일 차에 방문한 사용자 수
  ÷ Day 0 사용자 수 × 100

가입자 100명 중 정확히 7일 차에 15명이 방문했다면 Day 7 Classic Retention은 15%다.

15 ÷ 100 × 100 = 15%

사용자가 6일 차나 8일 차에 방문했더라도 7일 차에 방문하지 않았다면 포함되지 않는다. Amplitude에서는 이러한 방식을 N-Day 또는 Return On으로 표현한다.

적합한 서비스

사용자가 일정한 주기로 이용하는 서비스에 적합하다.

모바일 게임
SNS
학습 앱
운동 기록 앱

특징

계산과 해석이 쉽다.
날짜별 재방문율을 확인하기 좋다.
특정 날짜만 확인하므로 리텐션이 낮게 측정될 수 있다.
날짜에 따라 수치가 오르내릴 수 있다.

2. Range Retention

Range Retention은 사용자가 정해진 기간 안에 한 번이라도 방문했는지를 측정하는 방식이다.

예를 들어 Day 1~7 Range Retention은 가입 후 1일부터 7일 사이에 한 번이라도 방문한 사용자의 비율이다.

Day 1~7 Range Retention
= 1일부터 7일 사이에 방문한 사용자 수
  ÷ Day 0 사용자 수 × 100

가입자 100명 중 1일부터 7일 사이에 한 번이라도 방문한 사용자가 40명이라면 Range Retention은 40%다.

40 ÷ 100 × 100 = 40%

사용자가 해당 기간에 여러 번 방문했더라도 사용자 수는 한 명으로 계산한다.

Range Retention은 자료나 분석 도구에 따라 Bracket Retention, Custom Retention처럼 표현되기도 한다. Amplitude의 API 역시 기간을 구간으로 묶는 방식을 bracket으로 구분한다.

적합한 서비스

정확한 날짜보다 일정 기간 안의 재방문이 중요한 서비스에 적합하다.

주 단위 학습 서비스
정기 구매 쇼핑몰
구독 서비스
숙박 및 여행 서비스

특징

서비스의 이용 주기에 맞게 기간을 설정할 수 있다.
일별 변동을 줄이고 전체적인 흐름을 확인하기 좋다.
구간이 넓을수록 리텐션이 높게 측정될 가능성이 크다.
구간 설정에 따라 결과가 달라질 수 있다.

3. Rolling Retention

Rolling Retention은 사용자가 N일 차 또는 그 이후에 한 번이라도 방문했는지를 측정하는 방식이다.

Unbounded Retention이라고도 한다.

예를 들어 Day 7 Rolling Retention은 정확히 7일 차뿐만 아니라 8일, 10일, 30일 차에 방문한 사용자도 포함한다.

Day 7 Rolling Retention
= 7일 차 이후 한 번이라도 방문한 사용자 수
  ÷ Day 0 사용자 수 × 100

가입자 100명 중 7일 차 이후 한 번이라도 방문한 사용자가 30명이라면 Day 7 Rolling Retention은 30%다.

30 ÷ 100 × 100 = 30%

Amplitude에서는 이를 Return On or After라고 표현하며, 특정 날짜 이후에 재방문한 사용자를 모두 포함한다.

적합한 서비스

사용자의 방문 주기가 일정하지 않은 서비스에 적합하다.

쇼핑몰
채용 플랫폼
부동산 플랫폼
여행 예약 서비스
금융상품 비교 서비스

특징

사용자가 장기적으로 다시 돌아왔는지 확인하기 좋다.
방문 주기가 불규칙한 서비스에 적합하다.
사용자가 얼마나 자주 방문했는지는 알 수 없다.
N값이 커질수록 수치는 일반적으로 같거나 낮아진다.

세 가지 방식의 차이

사용자들의 방문 기록이 다음과 같다고 가정해 보자.

사용자 A: Day 7 방문
사용자 B: Day 3, Day 10 방문
사용자 C: Day 10 방문
사용자 D: Day 1 방문

Day 7을 기준으로 계산하면 다음과 같다.

방식포함되는 사용자판단 기준

Classic	A	정확히 Day 7에 방문했는가?
Range	A, B, D	Day 1~7 사이에 방문했는가?
Rolling	A, B, C	Day 7 이후에 방문했는가?

핵심 차이는 다음과 같다.

Classic → 정확히 그날 돌아왔는가?

Range → 정해진 기간 안에 돌아왔는가?

Rolling → 그날 또는 그 이후에 돌아왔는가?

리텐션 방식 비교

구분측정 기준Day 7의 의미적합한 경우

Classic	정확히 N일 차 방문	정확히 7일 차에 방문	이용 주기가 규칙적인 서비스
Range	설정한 기간 내 방문	1~7일 사이에 방문	기간 단위의 재방문이 중요한 서비스
Rolling	N일 차 이후 방문	7일 이후 한 번이라도 방문	이용 주기가 불규칙한 서비스

어떤 방식을 사용해야 할까?

리텐션 계산 방식에는 절대적인 정답이 없다. 서비스의 정상적인 이용 주기에 맞게 선택해야 한다.

매일 또는 매주 정기적으로 이용해야 한다면 Classic Retention
특정 기간 안에 다시 방문하는지가 중요하다면 Range Retention
사용자가 필요할 때 불규칙하게 방문한다면 Rolling Retention

예를 들어 게임은 정확히 다음 날 다시 접속했는지가 중요하므로 Classic Retention이 적합하다.

반면 쇼핑몰은 사용자가 정확히 7일 차에 방문하지 않더라도 이후 다시 구매할 수 있으므로 Rolling Retention이 더 적합할 수 있다.

분석할 때 주의할 점

리텐션을 계산할 때는 다음 기준을 명확하게 정해야 한다.

1. 어떤 행동을 시작 이벤트로 볼 것인가?
2. 어떤 행동을 재방문으로 볼 것인가?
3. 하루를 달력 날짜로 나눌 것인가, 24시간 단위로 나눌 것인가?
4. Classic, Range, Rolling 중 어떤 방식을 사용할 것인가?

특히 Day 7 리텐션을 계산하려면 가입 후 최소 7일이 지난 사용자만 포함해야 한다.

아직 가입 후 7일이 지나지 않은 사용자를 포함하면 재방문할 기회가 충분하지 않기 때문에 리텐션이 실제보다 낮게 계산될 수 있다.

또한 분석 도구마다 날짜 구간과 명칭이 다를 수 있으므로, 다른 서비스나 자료의 리텐션과 비교할 때는 계산 기준이 같은지 확인해야 한다. Amplitude 역시 달력 날짜와 사용자별 24시간 구간에 따라 결과가 달라질 수 있다고 설명한다.

마무리

리텐션은 사용자가 서비스에 유입된 뒤 실제로 다시 돌아오는지를 보여주는 지표다.

같은 사용자 데이터라도 어떤 방식을 사용하느냐에 따라 결과가 달라진다.

Classic → 특정 날짜의 재방문

Range → 특정 기간의 재방문

Rolling → 특정 날짜 이후의 재방문

따라서 리텐션 수치만 확인하기보다 서비스의 이용 주기와 분석 목적에 맞는 계산 방식을 선택하는 것이 중요하다.

Airflow

subinz — Fri, 31 Jul 2026 18:55:33 +0900

Apache Airflow란? DAG·Task·Operator 핵심 개념 정리

Apache Airflow는 데이터 수집, 전처리, 저장과 같은 여러 작업의 실행 순서와 일정, 의존관계를 관리하는 워크플로 오케스트레이션 도구다.

Airflow가 직접 데이터를 분석하는 것은 아니다. 어떤 작업을 언제 실행하고, 앞선 작업이 성공했을 때 어떤 작업을 이어서 실행할지를 관리한다.

예를 들어 일일 매출 데이터 파이프라인을 다음과 같이 자동화할 수 있다.

주문 데이터 수집
→ 데이터 전처리
→ 데이터베이스 저장
→ 매출 보고서 생성
→ 완료 알림

Airflow의 핵심 구성 요소

Airflow의 기본 구조는 다음 세 가지 개념으로 이해할 수 있다.

구성 요소의미

DAG	전체 작업 흐름과 실행 순서를 정의
Task	DAG 안에서 실제로 실행되는 개별 작업
Operator	Task가 어떤 작업을 수행할지 정의하는 템플릿

1. DAG란?

DAG(Directed Acyclic Graph)는 여러 Task의 실행 순서와 의존관계를 정의한 전체 작업 흐름이다.

DAG 자체가 데이터를 처리하는 것은 아니며 다음 내용을 관리한다.

어떤 Task를 실행할 것인지
Task를 어떤 순서로 실행할 것인지
언제 실행할 것인지
앞선 Task가 실패했을 때 어떻게 처리할 것인지

DAG는 방향성이 있고 작업 흐름이 이전 단계로 되돌아가는 순환 구조를 가지지 않는다.

데이터 수집 → 전처리 → 저장 → 알림

2. Task란?

Task는 DAG 안에서 실제로 실행되는 하나의 작업 단위다.

예를 들어 다음 작업들이 각각 하나의 Task가 될 수 있다.

API에서 데이터 수집
결측값 처리
데이터베이스에 결과 저장
보고서 생성
이메일 전송

데이터 수집 → 데이터 전처리 → DB 저장 → 완료 알림
   Task 1        Task 2         Task 3       Task 4

각 Task는 독립적인 작업이지만 의존관계를 설정하여 앞선 Task가 성공한 뒤 다음 Task가 실행되도록 만들 수 있다.

DAG와 Task의 관계

DAG가 전체 업무 프로세스를 나타내는 설계도라면, Task는 설계도 안에서 실행되는 개별 작업이다.

DAG
├─ 데이터 수집 Task
├─ 데이터 전처리 Task
├─ 데이터 저장 Task
└─ 완료 알림 Task

하나의 DAG 안에는 여러 Task가 포함될 수 있으며, DAG가 Task 사이의 실행 순서를 관리한다.

3. Operator란?

Operator는 Task가 어떤 작업을 수행할지 정의한 템플릿이다.

DAG 안에서 Operator를 생성하면 실제로 실행되는 Task가 된다.

예를 들어 파이썬 함수를 실행하는 Operator를 사용해 데이터 전처리 Task를 만들거나, 이메일 발송 Operator로 완료 알림 Task를 만들 수 있다.

Operator: 작업 방식 정의
Task: DAG 안에서 실행되는 Operator의 인스턴스

주요 Operator

Operator기능활용 사례

PythonOperator	파이썬 함수 실행	데이터 전처리, 집계, 분석
BashOperator	Bash 명령어 실행	스크립트 실행, 파일 처리
EmailOperator	이메일 발송	작업 완료 또는 오류 알림
HttpOperator	외부 HTTP API 호출	주문·날씨·환율 데이터 수집
BranchPythonOperator	조건에 따라 실행 경로 선택	매출 목표 달성 여부에 따라 작업 분기
ShortCircuitOperator	조건이 거짓이면 후속 Task 생략	신규 데이터가 없을 때 작업 중단
DockerOperator	Docker 컨테이너에서 작업 실행	독립된 환경에서 전처리·모델 실행
KubernetesPodOperator	Kubernetes Pod에서 작업 실행	작업별 독립 자원 할당
TriggerDagRunOperator	다른 DAG 실행 요청	수집 DAG 완료 후 분석 DAG 실행

BranchPythonOperator와 ShortCircuitOperator의 차이

두 Operator 모두 조건에 따라 실행 흐름을 제어하지만 역할이 다르다.

구분BranchPythonOperatorShortCircuitOperator

목적	여러 경로 중 하나를 선택	조건이 거짓이면 후속 작업 중단
예시	목표 달성 시 보고서, 미달 시 경고	신규 데이터가 없으면 분석 생략

BranchPythonOperator는 조건에 따라 실행할 Task를 선택한다.

매출 목표 달성 여부 확인
├─ 달성 → 보고서 생성
└─ 미달 → 경고 알림

ShortCircuitOperator는 조건이 충족되지 않으면 이후 Task를 건너뛴다.

신규 데이터 존재 여부 확인
├─ 있음 → 전처리 실행
└─ 없음 → 후속 작업 생략

4. Airflow 활용 예시

쇼핑몰의 일일 매출 데이터를 처리한다고 가정한다.

HttpOperator
쇼핑몰 API에서 주문 데이터 수집
        ↓
ShortCircuitOperator
신규 주문 데이터가 있는지 확인
        ↓
PythonOperator 또는 DockerOperator
데이터 전처리 및 매출 집계
        ↓
BranchPythonOperator
매출 목표 달성 여부에 따라 경로 선택
        ↓
EmailOperator
결과 또는 경고 메시지 전송

각 Operator가 하나의 Task를 담당하고, Task 사이의 실행 순서와 의존관계를 DAG가 관리한다.

5. Airflow를 사용하는 이유

Airflow를 사용하면 복잡한 데이터 작업을 일정에 맞춰 자동으로 실행하고 관리할 수 있다.

반복 작업 자동화
Task 실행 순서 관리
정해진 시간에 DAG 실행
작업 성공·실패 상태 확인
실패한 Task 재실행
조건에 따른 실행 흐름 제어
로그와 실행 이력 관리

예를 들어 매일 오전 9시에 데이터를 수집하고, 수집이 성공했을 때만 전처리와 저장 작업을 실행하도록 설정할 수 있다.

Airflow 사용 시 주의할 점

Airflow는 데이터를 직접 처리하는 분석 도구가 아니라 작업 실행을 관리하는 도구다.

따라서 대용량 데이터 연산은 Airflow 내부에서 직접 처리하기보다 Spark, Docker, Kubernetes, 데이터베이스 등의 외부 실행환경에 맡기고 Airflow가 실행 순서를 관리하도록 구성하는 것이 좋다.

또한 Task 사이에 대용량 데이터를 직접 전달하기보다 파일 저장소나 데이터베이스에 저장한 뒤 다음 Task가 읽도록 설계하는 것이 일반적이다.

정리

Apache Airflow는 여러 데이터 작업의 일정과 실행 순서를 관리하는 워크플로 오케스트레이션 도구다.

DAG: 전체 작업 흐름과 의존관계
Task: 실제로 실행되는 개별 작업
Operator: Task가 수행할 작업을 정의하는 템플릿

Operator로 Task를 만들고
→ 여러 Task를 DAG로 연결하고
→ Airflow가 일정과 실행 상태를 관리한다.

Airflow를 활용하면 데이터 수집, 전처리, 저장, 분석, 알림으로 이어지는 파이프라인을 자동화하고 안정적으로 관리할 수 있다.

Git 브랜치

subinz — Fri, 31 Jul 2026 18:52:57 +0900

Git 브랜치란? 사용하는 이유와 기본 흐름

Git은 파일의 변경 이력을 기록하고 관리하는 분산 버전 관리 시스템이다.

코드가 언제, 어떻게 변경되었는지 기록할 수 있으며 문제가 발생하면 이전 상태로 되돌릴 수 있다. 여러 사람이 같은 프로젝트를 함께 작업할 때도 각자의 변경 내용을 관리하고 병합할 수 있다.

브랜치란?

브랜치(Branch)는 기존 코드에서 독립적으로 작업할 수 있도록 만든 별도의 작업 흐름이다.

기본 브랜치인 main을 직접 수정하지 않고 새로운 브랜치를 만들어 기능을 개발하거나 오류를 수정할 수 있다.

main
 └─ feature/login

feature/login 브랜치에서 로그인 기능을 개발하더라도 main 브랜치의 코드는 그대로 유지된다.

작업이 완료되면 변경 내용을 검토한 뒤 main에 병합한다.

브랜치를 사용하는 이유

독립적인 작업 가능

여러 사람이 서로 다른 기능을 동시에 개발할 수 있다.

main
├─ feature/login
├─ feature/payment
└─ fix/signup-error

각 브랜치의 작업은 서로 분리되어 있으므로 다른 기능에 영향을 주지 않고 개발할 수 있다.

안정적인 main 브랜치 유지

완성되지 않은 코드나 오류가 있는 코드를 main에 바로 반영하지 않아도 된다.

기능 개발과 테스트가 끝난 코드만 병합하면 main 브랜치를 비교적 안정적인 상태로 유지할 수 있다.

변경 내용 검토

GitHub의 Pull Request를 사용하면 브랜치의 변경 내용을 병합하기 전에 팀원이 코드를 검토할 수 있다.

문제 발생 시 관리가 쉬움

기능별로 작업 내용이 분리되므로 어떤 변경으로 문제가 발생했는지 확인하고 수정하기 쉽다.

브랜치 기본 명령어

현재 브랜치 확인

git branch

현재 작업 중인 브랜치 앞에는 *가 표시된다.

* main
  feature/login

새 브랜치 생성

git branch feature/login

이 명령어는 브랜치만 생성하며 현재 위치는 바뀌지 않는다.

브랜치 이동

git switch feature/login

이전에는 다음 명령어도 많이 사용했다.

git checkout feature/login

브랜치 생성과 이동을 동시에 수행

git switch -c feature/login

브랜치 목록 확인

git branch

원격 브랜치까지 함께 확인하려면 다음 명령어를 사용한다.

git branch -a

브랜치 작업 흐름

일반적인 협업 흐름은 다음과 같다.

main 최신화
→ 작업 브랜치 생성
→ 코드 수정
→ 커밋
→ 원격 저장소에 푸시
→ Pull Request 생성
→ 검토 후 main에 병합

1. main 브랜치로 이동

git switch main

2. 원격 main의 최신 내용 가져오기

git pull origin main

3. 작업 브랜치 생성

git switch -c feature/login

4. 변경 내용 확인

git status

5. 변경 파일 추가

git add .

6. 커밋

git commit -m "로그인 기능 추가"

7. 원격 저장소에 브랜치 올리기

git push -u origin feature/login

이후 GitHub에서 Pull Request를 생성하고 main에 병합한다.

merge란?

Merge는 한 브랜치의 변경 내용을 다른 브랜치에 합치는 작업이다.

예를 들어 feature/login의 작업을 main에 합치려면 먼저 main으로 이동한다.

git switch main

그다음 병합한다.

git merge feature/login

협업에서는 로컬에서 직접 병합하기보다 GitHub의 Pull Request를 통해 검토 후 병합하는 경우가 많다.

충돌이란?

충돌(Conflict)은 서로 다른 브랜치에서 같은 파일의 같은 부분을 다르게 수정했을 때 발생한다.

예를 들어 main과 feature/login에서 같은 코드 줄을 각각 다르게 수정하면 Git이 어느 내용을 선택해야 할지 판단할 수 없다.

<<<<<<< HEAD
main 브랜치의 코드
=======
feature 브랜치의 코드
>>>>>>> feature/login

충돌이 발생하면 필요한 코드를 직접 선택하거나 합친 뒤 표시 문자를 제거해야 한다.

수정이 끝나면 다시 커밋한다.

git add .
git commit -m "병합 충돌 해결"

브랜치 삭제

작업이 병합된 뒤 필요 없는 로컬 브랜치를 삭제할 수 있다.

git branch -d feature/login

아직 병합되지 않은 브랜치를 강제로 삭제하려면 다음 명령어를 사용한다.

git branch -D feature/login

원격 브랜치는 별도로 삭제해야 한다.

git push origin --delete feature/login

GitHub에서 원격 브랜치를 삭제해도 로컬 브랜치는 자동으로 삭제되지 않는다.

브랜치 이름 예시

브랜치 이름은 작업 목적이 드러나도록 작성하는 것이 좋다.

접두어사용 목적예시

feature/	새로운 기능 개발	feature/login
fix/	오류 수정	fix/payment-error
refactor/	코드 구조 개선	refactor/user-service
docs/	문서 수정	docs/readme
test/	테스트 코드 작성	test/login

팀마다 브랜치 이름 규칙은 다를 수 있으므로 협업 규칙을 먼저 확인해야 한다.

주의할 점

작업 브랜치를 만들기 전에는 main을 최신 상태로 맞추는 것이 좋다.

git switch main
git pull origin main
git switch -c feature/login

또한 브랜치를 이동하기 전에 작업 중인 변경 사항을 커밋하거나 임시 저장해야 한다.

git status

커밋하지 않은 변경 사항이 있는 상태에서 브랜치를 이동하면 다른 브랜치에도 변경 내용이 따라가거나 충돌이 발생할 수 있다.

정리

Git 브랜치는 기존 코드와 분리된 공간에서 안전하게 작업하기 위한 기능이다.

여러 사람이 서로 다른 기능을 동시에 개발할 수 있음
완성되지 않은 코드가 main에 바로 반영되는 것을 방지
기능별 변경 이력을 관리하기 쉬움
Pull Request를 통해 코드 검토 후 병합 가능

일반적인 흐름은 다음과 같다.

main 최신화
→ 작업 브랜치 생성
→ 수정 및 커밋
→ 원격 브랜치 푸시
→ Pull Request
→ main 병합

브랜치를 적절히 사용하면 협업 과정에서 코드 충돌을 줄이고 안정적으로 프로젝트를 관리할 수 있다.

절대 경로와 상대 경로

subinz — Fri, 31 Jul 2026 17:47:14 +0900

절대 경로와 상대 경로의 차이

파일이나 폴더의 위치를 나타내는 방법에는 절대 경로와 상대 경로가 있다.

두 방식의 차이는 경로를 어디에서부터 시작해서 표현하는지에 있다.

절대 경로란?

절대 경로(Absolute Path)는 파일이나 폴더의 위치를 최상위 디렉터리부터 전체 경로로 표현하는 방식이다.

현재 작업 위치와 관계없이 항상 같은 파일을 가리킨다.

Windows 예시

C:\Users\user\project\data.csv

Linux·macOS 예시

/home/user/project/data.csv

절대 경로는 파일의 위치를 명확하게 지정할 수 있지만, 사용자명이나 폴더 구조가 다른 컴퓨터에서는 그대로 사용할 수 없다는 단점이 있다.

상대 경로란?

상대 경로(Relative Path)는 현재 작업 중인 폴더를 기준으로 파일이나 폴더의 위치를 표현하는 방식이다.

현재 위치가 프로젝트 폴더라면 같은 폴더의 파일은 파일명만으로 접근할 수 있다.

data.csv

하위 폴더에 있는 파일은 다음과 같이 표현한다.

data/data.csv

상위 폴더에 있는 파일은 ../를 사용한다.

../data.csv

경로에서 사용하는 기호

표현의미

.	현재 폴더
..	상위 폴더
./data.csv	현재 폴더의 data.csv
../data.csv	상위 폴더의 data.csv
data/data.csv	현재 폴더 안의 data 폴더에 있는 파일

./는 생략할 수 있으므로 ./data.csv와 data.csv는 일반적으로 같은 파일을 의미한다.

절대 경로와 상대 경로 비교

구분절대 경로상대 경로

기준	최상위 디렉터리	현재 작업 폴더
경로 길이	길고 구체적	짧고 간단함
현재 위치 영향	받지 않음	영향을 받음
다른 환경으로 이동	경로가 깨질 수 있음	프로젝트 구조가 같으면 유지 가능
주요 활용	특정 파일 위치를 명확히 지정	프로젝트 내부 파일 연결

파이썬에서 경로 사용하기

현재 작업 폴더에 data.csv가 있다면 상대 경로로 불러올 수 있다.

import pandas as pd

df = pd.read_csv("data.csv")

data 폴더 안에 있다면 다음과 같이 작성한다.

df = pd.read_csv("data/data.csv")

절대 경로를 사용할 수도 있다.

df = pd.read_csv(
    r"C:\Users\user\project\data\data.csv"
)

Windows 경로에서는 \가 특수문자로 해석될 수 있으므로 문자열 앞에 r을 붙이거나 /를 사용할 수 있다.

df = pd.read_csv(
    "C:/Users/user/project/data/data.csv"
)

현재 작업 폴더 확인

상대 경로는 현재 작업 폴더를 기준으로 해석되므로, 경로 오류가 발생하면 현재 위치를 먼저 확인하는 것이 좋다.

import os

print(os.getcwd())

os.getcwd()는 현재 작업 디렉터리를 반환한다.

파일이 존재하는지도 확인할 수 있다.

import os

print(os.path.exists("data/data.csv"))

결과가 False라면 현재 작업 폴더나 파일 경로가 잘못되었을 가능성이 있다.

어떤 경로를 사용하는 것이 좋을까?

개인 컴퓨터에서 특정 파일을 한 번 불러오는 경우에는 절대 경로를 사용할 수 있다.

하지만 협업 프로젝트나 GitHub에 올릴 코드는 상대 경로를 사용하는 것이 좋다.

project/
├─ data/
│  └─ data.csv
├─ notebook/
│  └─ analysis.ipynb
└─ src/
   └─ main.py

프로젝트 내부 구조를 기준으로 상대 경로를 사용하면 다른 사람이 프로젝트를 내려받아도 같은 구조에서 실행할 수 있다.

반면 C:\Users\user\...와 같은 절대 경로는 작성자의 컴퓨터에만 존재하기 때문에 다른 환경에서는 오류가 발생한다.

정리

절대 경로는 최상위 디렉터리부터 파일의 전체 위치를 표현하고, 상대 경로는 현재 작업 폴더를 기준으로 위치를 표현한다.

절대 경로: 위치가 명확하지만 환경이 바뀌면 경로가 깨질 수 있음
상대 경로: 현재 위치의 영향을 받지만 프로젝트 이동과 협업에 유리함

프로젝트 내부 파일을 다룰 때는 상대 경로를 사용하고, 경로 오류가 발생하면 현재 작업 디렉터리와 파일 존재 여부를 먼저 확인하는 것이 좋다.

장바구니 분석

subinz — Fri, 31 Jul 2026 17:45:41 +0900

장바구니 분석이란? Support·Confidence·Lift 해석하기

장바구니 분석(Market Basket Analysis)은 고객의 거래 데이터를 바탕으로 어떤 상품이 함께 구매되는지 찾는 분석 방법이다.

예를 들어 Coffee를 구매한 고객이 Toast도 자주 구매한다면 다음과 같은 연관 규칙을 만들 수 있다.

Coffee → Toast

이는 Coffee를 구매했을 때 Toast도 함께 구매하는 경향이 있다는 의미다.

장바구니 분석은 상품 추천, 세트 메뉴 구성, 프로모션 기획 등 고객의 추가 구매를 유도하는 데 활용할 수 있다.

장바구니 분석의 활용 사례

활용 사례설명비즈니스 활용

교차 판매	함께 구매되는 상품 추천	추가 구매 유도
상품 진열 최적화	연관 상품을 가까이 배치	고객 편의와 충동구매 증가
추천 시스템	구매 상품과 관련된 상품 노출	구매 전환율 향상
프로모션 기획	연관 상품을 묶어 할인	효과적인 세트 상품 구성
재고 관리	함께 판매되는 상품을 동시에 관리	연관 상품의 품절 위험 예방
신상품 마케팅	신상품을 인기 상품과 연결	신상품 노출과 초기 판매 증가

연관 규칙의 주요 지표

장바구니 분석에서는 규칙의 의미를 판단하기 위해 Support, Confidence, Lift를 사용한다.

지표의미계산 방법

Support	전체 거래에서 A와 B가 함께 구매된 비율	A와 B 동시 구매 건수 ÷ 전체 거래 수
Confidence	A를 구매한 거래 중 B도 구매한 비율	Support(A, B) ÷ Support(A)
Lift	A 구매가 B 구매 가능성을 얼마나 높이는지 측정	Confidence(A→B) ÷ Support(B)

Support: 지지도

Support는 특정 상품 조합이 전체 거래에서 얼마나 자주 등장하는지를 나타낸다.

전체 거래 1,000건 중 Coffee와 Toast가 함께 구매된 거래가 150건이라면 다음과 같다.

Support(Coffee, Toast) = 150 ÷ 1,000 = 0.15

즉, 전체 거래의 15%에서 Coffee와 Toast가 함께 구매되었다는 의미다.

Support가 너무 낮으면 강한 연관성이 있더라도 실제 활용할 수 있는 거래 수가 적을 수 있다.

Confidence: 신뢰도

Confidence는 A를 구매한 고객이 B도 함께 구매한 비율이다.

Coffee 구매 거래가 300건이고, 그중 Coffee와 Toast를 함께 구매한 거래가 150건이라면 다음과 같다.

Confidence(Coffee → Toast) = 150 ÷ 300 = 0.5

즉, Coffee를 구매한 거래의 50%에서 Toast도 함께 구매되었다는 의미다.

다만 Toast 자체가 원래 매우 인기 있는 상품이라면 Confidence가 높게 나타날 수 있으므로 Lift도 함께 확인해야 한다.

Lift: 향상도

Lift는 A를 구매한 고객이 일반 고객보다 B를 구매할 가능성이 얼마나 높은지를 나타낸다.

Coffee를 구매한 고객의 Toast 구매율이 50%이고, 전체 거래에서 Toast 구매율이 20%라면 다음과 같다.

Lift(Coffee → Toast) = 0.5 ÷ 0.2 = 2.5

즉, Coffee 구매 고객은 전체 고객보다 Toast를 구매할 가능성이 2.5배 높다는 의미다.

Lift 해석

Lift 값의미

Lift < 1	A와 B가 함께 구매될 가능성이 상대적으로 낮음
Lift = 1	A와 B가 서로 독립적임
Lift > 1	A 구매가 B 구매와 양의 연관성을 가짐

Lift가 클수록 두 상품의 연관성이 강하다고 볼 수 있다.

다만 Lift > 2 또는 Lift > 3을 무조건 강한 규칙으로 판단하는 고정 기준은 없다. 상품 종류, 거래량, Support와 Confidence를 함께 고려해야 한다.

분석 결과 예시

규칙SupportConfidenceLift

Coffee → Toast

15%

50%

2.5

해석

전체 거래의 15%에서 Coffee와 Toast가 함께 구매되었다.

또한 Coffee를 구매한 거래의 50%에서 Toast도 구매되었으며, Coffee 구매 고객은 전체 고객보다 Toast를 구매할 가능성이 2.5배 높았다.

따라서 다음과 같은 전략을 고려할 수 있다.

Coffee 구매 시 Toast 추천
Coffee와 Toast 세트 메뉴 구성
두 상품의 묶음 할인 제공
매장 또는 화면에서 두 상품을 가까이 배치

Apriori 알고리즘

장바구니 분석에서는 대표적으로 Apriori 알고리즘을 사용한다.

Apriori는 자주 등장하는 상품 조합을 먼저 찾고, 이를 바탕으로 의미 있는 연관 규칙을 생성한다.

빈번하게 등장하는 상품 조합 탐색
→ 연관 규칙 생성
→ Support·Confidence·Lift로 규칙 평가

상품 종류가 많으면 가능한 조합의 수가 급격히 증가하므로 최소 Support와 Confidence 기준을 설정해 불필요한 규칙을 줄인다.

분석 시 주의할 점

장바구니 분석의 결과는 상품 간의 연관성을 보여줄 뿐 인과관계를 증명하지는 않는다.

Coffee가 Toast 구매를 직접 발생시켰다고 단정할 수는 없다. 아침 시간대, 할인 행사, 세트 메뉴 등 다른 요인이 영향을 주었을 수 있다.

또한 Lift가 높더라도 Support가 지나치게 낮다면 극소수 거래에서만 나타난 규칙일 수 있다.

따라서 다음 지표를 함께 확인해야 한다.

규칙이 충분히 자주 발생하는가?
A 구매자 중 B를 구매한 비율이 높은가?
일반적인 B 구매율보다 실제로 높은가?
비즈니스에서 활용할 수 있는 상품 조합인가?

정리

장바구니 분석은 거래 데이터에서 함께 구매되는 상품의 패턴을 찾는 방법이다.

Support: 해당 상품 조합이 전체 거래에서 얼마나 자주 등장하는가?
Confidence: A를 구매했을 때 B도 구매한 비율은 얼마인가?
Lift: A 구매가 B 구매 가능성을 얼마나 높이는가?

세 지표를 함께 분석하면 단순히 많이 판매되는 상품이 아니라, 실제로 함께 구매되는 경향이 강한 상품 조합을 찾을 수 있다.

주성분 분석과 요인 분석

subinz — Fri, 31 Jul 2026 17:40:35 +0900

주성분 분석과 요인 분석의 차이

주성분 분석(PCA)과 요인 분석(FA)은 모두 여러 변수를 더 적은 수의 변수로 줄이는 방법이다.

하지만 목적은 다르다.

주성분 분석: 기존 변수의 정보를 최대한 유지하면서 차원을 축소
요인 분석: 관측된 변수에 공통으로 영향을 주는 잠재 요인을 발견

주성분 분석이란?

주성분 분석(Principal Component Analysis)은 여러 변수의 정보를 서로 독립적인 새로운 변수인 주성분으로 압축하는 방법이다.

첫 번째 주성분은 전체 데이터의 변동을 가장 많이 설명하고, 두 번째 주성분은 첫 번째 주성분과 겹치지 않는 범위에서 남은 변동을 최대한 설명한다.

기존 변수 여러 개
→ 정보가 많이 담긴 소수의 주성분으로 변환

예를 들어 고객 데이터에 다음 변수가 있다고 가정한다.

구매 횟수
구매 금액
방문 횟수
체류시간
상품 조회 수

PCA를 적용하면 이러한 변수들을 조합하여 고객 활동성, 구매 규모와 유사한 몇 개의 주성분으로 줄일 수 있다.

다만 주성분의 의미는 분석자가 각 변수의 가중치를 보고 해석해야 한다.

요인 분석이란?

요인 분석(Factor Analysis)은 여러 관측 변수 사이의 상관관계를 설명하는 잠재 요인을 찾는 방법이다.

잠재 요인은 직접 측정할 수 없지만 여러 변수에 공통으로 영향을 주는 개념이다.

예를 들어 고객 만족도 설문에 다음 문항이 있다고 가정한다.

직원이 친절했다.
문의 응답이 빨랐다.
문제 처리가 원활했다.
상품 품질이 좋았다.
가격이 합리적이었다.

요인 분석을 적용하면 다음과 같은 잠재 요인을 발견할 수 있다.

고객 서비스 만족도
상품 가치 만족도

즉, 개별 문항을 단순히 압축하기보다 여러 문항 뒤에 존재하는 공통 개념을 찾는 데 초점을 둔다.

PCA와 요인 분석의 차이

구분주성분 분석요인 분석

주요 목적	데이터 압축과 차원 축소	잠재 요인 발견
분석 대상	변수의 전체 분산	변수 간 공통 분산
생성 결과	주성분	잠재 요인
주성분·요인의 의미	수학적 정보 압축 결과	변수에 영향을 주는 숨은 개념
주요 활용	시각화, 전처리, 변수 축소	설문 분석, 심리·마케팅 연구
오차 고려	별도의 측정 오차를 가정하지 않음	고유 요인과 측정 오차를 고려

쉽게 구분하기

PCA는 다음 질문에 적합하다.

변수는 많지만 정보 손실을 줄이면서 변수 수를 줄일 수 있을까?

요인 분석은 다음 질문에 적합하다.

여러 변수의 상관관계를 만들어내는 공통된 원인은 무엇일까?

PCA: 여러 변수를 압축
요인 분석: 변수 뒤에 숨은 원인을 탐색

PCA의 주요 활용

변수가 많은 데이터의 차원 축소
머신러닝 모델의 입력 변수 축소
다중공선성 완화
고차원 데이터의 2차원 시각화
군집화 전 전처리

PCA를 사용하면 변수 수와 계산량을 줄일 수 있지만, 새롭게 생성된 주성분은 원래 변수보다 해석하기 어려울 수 있다.

요인 분석의 주요 활용

고객 만족도 설문 분석
브랜드 이미지 구성 요소 파악
심리적 특성과 태도 측정
비슷한 설문 문항 통합
측정 척도의 구조 검토

요인 분석에서는 각 변수가 특정 요인과 얼마나 관련되어 있는지를 나타내는 요인 적재량을 확인한다.

요인 적재량의 절댓값이 클수록 해당 변수가 그 요인과 강하게 관련되어 있다고 해석한다.

분석 시 주의할 점

PCA와 요인 분석은 변수의 단위 차이에 영향을 받을 수 있다.

예를 들어 구매 횟수는 0~20 범위인데 구매 금액은 수백만 원 단위라면, 구매 금액이 결과에 지나치게 큰 영향을 줄 수 있다. 따라서 단위가 다른 변수는 일반적으로 표준화한 뒤 분석한다.

또한 두 방법 모두 변수 사이에 일정한 상관관계가 있어야 의미 있는 결과를 얻을 수 있다. 서로 거의 관계없는 변수를 억지로 축소하거나 요인으로 묶는 것은 적절하지 않다.

정리

주성분 분석과 요인 분석은 모두 변수 수를 줄이는 데 활용되지만 목적이 다르다.

주성분 분석은 전체 정보 손실을 줄이면서 변수를 압축하는 방법이다.
요인 분석은 변수들의 상관관계를 설명하는 잠재 요인을 찾는 방법이다.

데이터 전처리와 시각화가 목적이라면 PCA가 적합하고, 설문 문항이나 관측 변수 뒤에 숨은 개념을 찾고 싶다면 요인 분석이 적합하다.

부스팅

subinz — Fri, 31 Jul 2026 17:27:34 +0900

부스팅이란?

부스팅(Boosting)은 여러 개의 약한 모델을 순차적으로 학습시키고, 이전 모델의 오류를 다음 모델이 보완하도록 만드는 앙상블 학습 방법이다.

하나의 복잡한 모델을 만드는 대신 성능이 낮은 여러 모델을 이어 붙여 강한 예측 모델을 만든다.

주로 얕은 결정트리를 기본 모델로 사용하며, 분류와 회귀 문제 모두에 활용할 수 있다.

부스팅의 학습 방식

부스팅은 모델을 동시에 만드는 것이 아니라 순서대로 학습한다.

첫 번째 모델 학습
→ 잘못 예측한 데이터 확인
→ 두 번째 모델이 이전 오류를 보완
→ 다음 모델이 남은 오류를 다시 보완
→ 여러 모델의 결과를 결합

예를 들어 첫 번째 트리가 결제 고객 일부를 미결제로 잘못 예측했다면, 다음 트리는 해당 데이터를 더 잘 맞히는 방향으로 학습한다.

이 과정을 반복하면서 전체 모델의 예측 성능을 높인다.

배깅과 부스팅의 차이

구분배깅부스팅

학습 방식	여러 모델을 독립적으로 학습	이전 모델의 오류를 순차적으로 보완
모델 관계	서로 독립적	앞 모델의 결과에 영향을 받음
결과 결합	평균 또는 다수결	모델별 예측을 가중 결합
주요 목적	분산 감소	편향 감소 및 성능 향상
대표 모델	랜덤 포레스트	AdaBoost, Gradient Boosting, XGBoost

배깅은 여러 모델을 병렬로 학습할 수 있지만, 부스팅은 이전 모델의 결과가 필요하므로 기본적으로 순차적으로 학습한다.

대표적인 부스팅 알고리즘

AdaBoost

AdaBoost는 이전 모델이 잘못 예측한 데이터에 더 높은 가중치를 부여한다.

다음 모델은 가중치가 높아진 데이터를 더 중요하게 학습한다.

오분류 데이터에 집중
구조가 비교적 단순함
이상치와 노이즈에 민감할 수 있음

Gradient Boosting

Gradient Boosting은 이전 모델의 실제 오차를 다음 모델이 예측하도록 학습한다.

각 모델이 남아 있는 잔차를 줄이는 방향으로 추가된다.

다양한 손실함수 사용 가능
높은 예측 성능
학습 속도가 느릴 수 있음
파라미터 설정에 민감함

XGBoost

XGBoost는 Gradient Boosting을 성능과 속도 측면에서 개선한 알고리즘이다.

정규화를 통한 과적합 제어
결측값 처리 기능
병렬 연산 지원
높은 예측 성능

정형 데이터 기반 머신러닝 문제에서 자주 활용된다.

LightGBM

LightGBM은 대용량 데이터를 빠르게 학습할 수 있도록 설계된 부스팅 알고리즘이다.

학습 속도가 빠름
메모리 사용량이 비교적 적음
데이터가 적으면 과적합될 수 있음

CatBoost

CatBoost는 범주형 변수를 효율적으로 처리하는 부스팅 알고리즘이다.

범주형 데이터 처리에 강점
별도의 원-핫 인코딩 부담 감소
기본 설정으로도 안정적인 성능을 보이는 경우가 많음

부스팅의 장점

단일 결정트리보다 예측 성능이 높은 경우가 많음
비선형 관계와 변수 간 상호작용을 학습할 수 있음
분류와 회귀 모두 사용 가능
별도의 스케일링이 거의 필요하지 않음
변수 중요도를 확인할 수 있음

부스팅의 단점

순차적으로 학습해 시간이 오래 걸릴 수 있음
파라미터 설정에 따라 과적합될 수 있음
단일 결정트리보다 결과 해석이 어려움
노이즈와 이상치까지 반복해서 학습할 가능성이 있음
학습률과 트리 개수의 조정이 필요함

주요 하이퍼파라미터

파라미터의미

n_estimators	순차적으로 생성할 트리 개수
learning_rate	각 트리가 최종 예측에 반영되는 정도
max_depth	개별 트리의 최대 깊이
min_samples_leaf	리프 노드에 필요한 최소 데이터 수
subsample	각 트리 학습에 사용할 데이터 비율

일반적으로 학습률을 낮추면 각 트리의 영향력이 작아지므로 더 많은 트리가 필요하다.

낮은 학습률 + 많은 트리
높은 학습률 + 적은 트리

학습률이 너무 높으면 빠르게 학습하지만 과적합될 수 있고, 너무 낮으면 학습 시간이 길어진다.

파이썬 예시

from sklearn.ensemble import GradientBoostingClassifier
from sklearn.metrics import classification_report

model = GradientBoostingClassifier(
    n_estimators=100,
    learning_rate=0.05,
    max_depth=3,
    random_state=42
)

model.fit(X_train, y_train)

y_pred = model.predict(X_test)

print(classification_report(y_test, y_pred))

XGBoost 예시

from xgboost import XGBClassifier
from sklearn.metrics import classification_report

model = XGBClassifier(
    n_estimators=300,
    learning_rate=0.05,
    max_depth=4,
    subsample=0.8,
    colsample_bytree=0.8,
    random_state=42,
    eval_metric="logloss"
)

model.fit(X_train, y_train)

y_pred = model.predict(X_test)

print(classification_report(y_test, y_pred))

과적합을 줄이는 방법

개별 트리의 깊이를 제한한다.
학습률을 낮춘다.
데이터와 변수의 일부만 사용한다.
트리 개수를 교차검증으로 결정한다.
정규화 파라미터를 조정한다.
검증 성능이 개선되지 않으면 학습을 중단한다.

XGBoost나 LightGBM에서는 Early Stopping을 활용하여 검증 성능이 더 이상 좋아지지 않을 때 학습을 멈출 수 있다.

정리

부스팅은 여러 약한 모델을 순차적으로 학습시키며, 이전 모델의 오류를 다음 모델이 보완하도록 만드는 앙상블 방식이다.

주로 얕은 결정트리를 반복해서 사용
단일 트리보다 높은 예측 성능을 기대할 수 있음
대표 알고리즘은 AdaBoost, Gradient Boosting, XGBoost, LightGBM, CatBoost
학습률과 트리 개수의 균형이 중요
성능은 높지만 과적합과 해석 난도가 증가할 수 있음

부스팅은 특히 정형 데이터에서 강력한 성능을 보이지만, 좋은 결과를 얻기 위해서는 교차검증과 하이퍼파라미터 조정이 필요하다.

결정트리

subinz — Fri, 31 Jul 2026 17:23:36 +0900

결정트리란?

결정트리(Decision Tree)는 데이터를 여러 조건으로 반복해서 나누며 결과를 예측하는 머신러닝 알고리즘이다.

사람이 의사결정을 내리는 방식처럼 “이 조건을 만족하는가?”를 순서대로 판단하기 때문에 결과를 이해하고 설명하기 쉽다.

분류와 회귀 문제에 모두 사용할 수 있다.

분류: 결제 여부, 이탈 여부, 불량 여부 예측
회귀: 매출, 가격, 수요량 등 연속적인 값 예측

결정트리의 구조

결정트리는 다음 세 가지 요소로 구성된다.

구성 요소의미

루트 노드	가장 먼저 데이터를 나누는 시작점
내부 노드	특정 조건에 따라 데이터를 분할하는 지점
리프 노드	최종 예측 결과가 결정되는 지점

예를 들어 고객의 결제 여부를 예측한다면 다음과 같은 구조를 만들 수 있다.

방문 횟수 ≥ 3회?
├─ 아니오 → 미결제
└─ 예
   └─ 평균 체류시간 ≥ 2시간?
      ├─ 아니오 → 미결제
      └─ 예 → 결제

결정트리는 어떻게 기준을 선택할까?

결정트리는 데이터를 가장 잘 구분할 수 있는 변수와 기준값을 선택한다.

분류 문제에서는 주로 지니 불순도나 엔트로피를 사용한다.

불순도는 하나의 노드에 서로 다른 클래스가 얼마나 섞여 있는지를 나타낸다.

한 클래스만 존재하면 불순도가 낮음
여러 클래스가 섞여 있으면 불순도가 높음

결정트리는 분할 후 불순도가 가장 크게 감소하는 조건을 선택한다.

결정트리의 장점

결과를 시각화하고 해석하기 쉬움
변수 간 비선형 관계를 학습할 수 있음
스케일링이 거의 필요하지 않음
수치형과 범주형 데이터를 활용할 수 있음
변수 중요도를 확인할 수 있음

결정트리의 단점

트리가 깊어지면 과적합이 발생하기 쉬움
데이터가 조금만 바뀌어도 트리 구조가 크게 달라질 수 있음
하나의 트리는 랜덤 포레스트나 XGBoost보다 예측 성능이 낮을 수 있음
복잡한 트리는 해석하기 어려워짐

과적합을 줄이는 주요 설정

파라미터의미

max_depth	트리의 최대 깊이 제한
min_samples_split	노드를 나누기 위한 최소 데이터 수
min_samples_leaf	리프 노드에 필요한 최소 데이터 수
max_leaf_nodes	리프 노드의 최대 개수
ccp_alpha	불필요한 가지를 제거하는 가지치기 강도

트리의 깊이를 무제한으로 두면 학습 데이터를 지나치게 세밀하게 나누어 과적합될 가능성이 높다.

파이썬 예시

from sklearn.tree import DecisionTreeClassifier
from sklearn.metrics import classification_report

model = DecisionTreeClassifier(
    max_depth=4,
    min_samples_leaf=10,
    random_state=42
)

model.fit(X_train, y_train)

y_pred = model.predict(X_test)

print(classification_report(y_test, y_pred))

트리 구조를 시각화할 수도 있다.

import matplotlib.pyplot as plt
from sklearn.tree import plot_tree

plt.figure(figsize=(16, 8))

plot_tree(
    model,
    feature_names=X_train.columns,
    class_names=["미결제", "결제"],
    filled=True,
    rounded=True
)

plt.show()

변수 중요도

결정트리는 각 변수가 데이터를 분할하면서 불순도를 얼마나 감소시켰는지를 기준으로 변수 중요도를 계산한다.

import pandas as pd

importance = pd.Series(
    model.feature_importances_,
    index=X_train.columns
).sort_values(ascending=False)

print(importance)

변수 중요도가 높다는 것은 해당 변수가 예측 과정에서 자주 사용되거나 불순도를 크게 줄였다는 의미다.

다만 변수 중요도만으로 인과관계를 판단할 수는 없다.

정리

결정트리는 조건문을 반복하여 데이터를 나누고 최종 결과를 예측하는 모델이다.

분류와 회귀 모두 사용 가능
구조가 직관적이고 해석하기 쉬움
별도의 스케일링이 거의 필요하지 않음
트리가 너무 깊어지면 과적합 가능성이 높음

따라서 결정트리는 단독 예측 모델뿐 아니라 데이터의 주요 분기 기준과 변수의 영향력을 파악하는 해석용 모델로도 유용하다.

K-폴드 교차

subinz — Fri, 31 Jul 2026 17:19:38 +0900

K-폴드 교차 검증이란?

K-폴드 교차 검증(K-Fold Cross Validation)은 데이터를 K개의 구간으로 나누고, 학습과 검증을 반복하여 모델의 성능을 평가하는 방법이다.

한 번만 학습·검증 데이터를 나누는 방식보다 데이터 분할에 따른 우연을 줄이고, 모델의 일반화 성능을 더 안정적으로 확인할 수 있다.

K-폴드 진행 방식

데이터를 5개 구간으로 나누는 5-Fold를 예로 들면 다음과 같다.

1회차: 1번 검증 / 나머지 학습
2회차: 2번 검증 / 나머지 학습
3회차: 3번 검증 / 나머지 학습
4회차: 4번 검증 / 나머지 학습
5회차: 5번 검증 / 나머지 학습

각 구간이 한 번씩 검증 데이터로 사용되며, 마지막에는 5번의 평가 점수를 평균 내어 최종 성능으로 사용한다.

장점

모든 데이터를 학습과 검증에 활용할 수 있음
데이터 분할에 따른 성능 편차를 줄일 수 있음
모델 간 성능 비교와 하이퍼파라미터 튜닝에 유용함

단점

모델을 K번 반복 학습하므로 시간이 오래 걸림
K값이 커질수록 계산량이 증가함
시계열 데이터에는 일반 K-Fold를 그대로 사용하기 어려움

분류 문제에서는 Stratified K-Fold

분류 데이터의 클래스 비율이 불균형하다면 일반 K-Fold보다 Stratified K-Fold를 사용하는 것이 좋다.

Stratified K-Fold는 각 폴드에서 타깃 클래스의 비율이 원본 데이터와 비슷하게 유지되도록 분할한다.

예를 들어 전체 데이터의 결제 고객 비율이 10%라면, 각 폴드에서도 결제 고객 비율이 약 10%가 되도록 나눈다.

파이썬 예시

from sklearn.model_selection import cross_val_score
from sklearn.ensemble import RandomForestClassifier

model = RandomForestClassifier(
    random_state=42
)

scores = cross_val_score(
    model,
    X,
    y,
    cv=5,
    scoring="f1"
)

print("각 폴드 점수:", scores)
print("평균 점수:", scores.mean())

K값 선택 시 고려사항

K값은 일반적으로 5 또는 10을 많이 사용한다.

K값특징

K가 작음	학습 데이터가 줄어 평가 편향이 커질 수 있지만 계산 속도가 빠름
K가 큼	더 많은 데이터를 학습에 사용해 안정적인 평가가 가능하지만 계산량이 증가함

데이터가 충분히 많다면 보통 K=5를 사용하고, 데이터가 비교적 적고 더 안정적인 평가가 필요하다면 K=10을 고려할 수 있다.

다만 K가 너무 크면 각 폴드의 검증 데이터가 지나치게 적어지고 학습 시간이 길어질 수 있다. 특히 데이터 수만큼 폴드를 나누는 Leave-One-Out 방식은 계산 비용이 매우 크고 평가 결과의 변동성도 커질 수 있다.

분류 문제에서는 K값뿐 아니라 각 폴드에 모든 클래스가 충분히 포함되는지도 확인해야 한다. 예를 들어 소수 클래스 데이터가 5개뿐이라면 K=10은 사용할 수 없으며, K는 소수 클래스의 데이터 수보다 크지 않게 설정해야 한다.

주의할 점

교차 검증 과정에서도 결측치 대체, 스케일링, 인코딩 같은 전처리는 각 학습 폴드에서만 학습해야 한다.

전체 데이터를 먼저 전처리하면 검증 데이터의 정보가 학습 과정에 포함되는 데이터 누수가 발생할 수 있다.

이 문제를 방지하려면 Scikit-learn의 Pipeline을 사용하는 것이 좋다.

정리

K-폴드 교차 검증은 데이터를 K개로 나누어 학습과 검증을 반복하고, 여러 평가 점수의 평균으로 모델 성능을 판단하는 방법이다.

일반적인 분류 문제에서는 클래스 비율을 유지하는 Stratified K-Fold를 자주 사용한다.