▽ 데이터를 위한 C.S 지식 정리_네트워크 공부 : HTTP는 무엇일까.

목  차

1. HTTP란? : Hyper Text Transfer Protocol

2. HTTP의 통신 구조

3. HTTP의 무상태성

4. HTTP의 비연결성

5. HTTP의 상태 코드

6. HTTP 메세지

7. HTTP 메서드.

1. HTTP란? : Hyper Text Transfer Protocol

HTTP란 서버와 클라이언트가 서로 데이터를 주고받기 위해 사용되는 "통신 규약"을 의미.

• 웹 문서간에 링크를 통해 연결할 수 있는 프로토콜.
• 문서뿐 아니라 다음과 같은 여러 종류의 데이터들을 폭 넓게 전송 가능.
  • ⓐ HTML, Text
  • ⓑ IMAGE, 음성,영상,파일
  • ⓒ JSON, XML(API)
  • ⓓ 거의 모든 형태의 데이터가 전송 가능.

서버간에 데이터를 주고 받을 때도 대부분 HTTP라는 프로토콜을 사용해서 통신한다고 보면 됨.

• 예를들어 인터넷 주소를 지정할때 http://www.naver.com 와 같이 시작하는 것은 www.naver.com 이라는 인터넷 주소가 가진 데이터 정보 등의 교환을 HTTP의 통신 규약대로 처리하라는 것.

• 인터넷 기반 서비스에는 HTTP외에도 Email, FTP, DNS, NEWS 등이 있음.

HTTP의 역사

① HTTP/0.9 (1991년) : GET 메서드만 지원, HTTP 헤더 X  ② HTTP/1.0 (1996년) : 메서드, 헤더, 상태코드 추가

• ⓐ 요청 헤더 : http 버전이 생김
• ⓑ 응답 헤더 : 상태코드와 content-type이 생겨 html 파일 외 다른 타입의 파일도 전송 
• ⓒ 단기커넥션:
  • connection 하나당 1 요청, 1 응답만 처리 가능.
  • 그래서 매번 새로운 연결로 선능 저하 및 서버 부하 비용 증가 

③ HTTP/1.1 (1997년) : 현재 가장 많이 사용하며, 대부분의 기능이 추가

• ⓐ Persistent connection : 지정한 timeout 동안 연속적인 요청 사이에 커넥션을 닫지 않음 
• ⓑ Pipelining : 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방식. 그러나 Head Of Line Blocking와 같은 문제점이 많아 사장됨
• ⓒ *Head Of Line Blocking *: 우선순위로 들어온 요청의 응답 시간이 길어지면 후 순위에 있는 요청의 응답 시간도 길어진다는 단점
• ⓓ 우리가 아는 대부분의 HTTP 기능이 1.1에 구현 된 것이고, 2와 3에서는 성능 개선에 초점이 맞춰져 있음.

④ HTTP/2.0 (2015년) : HTTP 1.1 성능 개선 및 확장

• ⓐ 메시지 전송 방식의 변화 : 바이너리 프레이밍 계층 사용
• ⓑ 파싱, 전송속도 증가
• ⓒ 오류 발생 가능성 저하
• ⓓ 멀티플렉싱
• ⓔ HPACK 압축 : 헤더 중복값 개선

⑤ HTTP/3.0 (2019년 ~ 진행중): TCP 대신에 UDP를 이용한 QUIC 프로토콜 사용

• ⓐ UDP 기반의 QUIC 프로코콜 바탕으로 제작
• ⓑ 기존 TCP의 고질적인 지연시간(RTT)를 해결함

HTTP/1.1, HTTP/2는 TCP 기반이며 HTTP/3는 UDP 기반 프로토콜

• 기존 TCP는 3 way hanshake부터 내부적으로 포함하거나 추가해야하는 작업들이 너무 많아서 신뢰성이나 연결성은 보장되지만 속도가 떨어짐.
• 그렇기에 UDP프로토콜을 애플리케이션 레벨에서 재설계를 해서 나오는게 HTTP/3.

2. HTTP의 통신 구조

HTTP 통신은 "클라이언트(Front-End)"와 "서버(Back-End)"로 나뉘어진 구조.

• 클라이언트가 요청(Request)하면, 서버가 응답(Response)하는 것.
  • 클라이언트가 HTTP 메시지를 보내고, 서버에서 요청에 대한 응답이 올 때까지 기다림.
  • 서버는 요청에 대한 결과를 만들어서 응답.

HTTP 통신하는데 있어서, 클라이언트와 서버를 분리해야만 하는 이유는?

각자의 역할에 집중할 수 있기 때문.

• 클라이언트에서는 복잡한 비즈니스로직이나 데이터를 다룰 필요없고, UI를 그리는데 집중 가능.

• 서버에서는 복잡한 비즈니스 로직이나, 데이터를 다루는데만 집중하면 됨. 만약 트래픽이 폭주해 고도화가 필요한 경우 클라이언트는 신경쓰지 않고 서버만 개선하면 됨.

• 클라이언트와 서버를 독립적으로 구분한다는 것은 각자의 책임을 나눠 해당 책임에만 집중하여, 클라이언트와 서버 양쪽이 각각 독립적으로 고도화 할수 있다는 것

3. HTTP의 무상태성(Stateless)

무상태(Stateless) : 클라이언트와 서버 사이에 상태를 유지하지 않음.

• 장점: 서버 확장성 높음(스케일 아웃)
• 단점: 클라이언트가 추가 데이터 전송 (메모리 ↑)

상태 유지(Stateful)

• 서버가 클라이언트의 상태를 보존.
• 가장 대표적인 예로 홈페이지에서 회원 로그인을 하면, 페이지를 옮겨가도 서버는 클라이언트의 상태를 보존하기 때문에 그 클라이언트가 회원인지 인지.
• 하지만 중간에 서버가 장애나면 클라이언트는 처음부터 다시 작업을 요청해야함.
• 그래서 서버가 바뀔때마다 클라이언트의 내용을 기록해서 상태를 유지해야 되는데 쉽지 않음.

무상태(Stateless)

• 서버가 클라이언트의 상태를 보존하지 않는다.
• 홈페이지에서 회원 로그인을 하고 페이지를 옮겼는데 또 로그인을 하라는 페이지가 뜬다. 왜냐하면 서버는 클라이언트의 상태를 보존하지 않기 때문에 그 클라이언트가 회원인지 모르기 때문.
• 따라서 무상태 환경에선 회원 정보를 서버가 아닌 클라이언트가 토큰 형태로 들고 있으면서, 서버와 통신할때 실어 보내 인증하는 식.
• 이러한 무상태 환경은 클라이언트가 상태 정보를 갖고 있는 것이기 때문에, 아무 서버나 호출해도 되기 때문에 서버의 스케일아웃(수평확장)에 유리.
• 하지만 상태유지(Stateful)보다 데이터를 많이 사용한다는 단점이 있음.

4. HTTP의 비연결성

• HTTP는 기본이 연결을 유지하지 않는 모델이다. 

• 즉, 서버와 클라이언트의 Connection 연결을 지속하지 않는다.

• 1시간동안 수천명 이상이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 적다. 

  • 예를들어 웹 브라우저 검색페이지에서 검색버튼만 연타하면서 이용하지는 않는듯이 말이다.

• 이러한 비연결성 특성 때문에 서버 자원을 매우 효율적으로 사용 가능.

[ Stateless 와 Connectionless 차이 ]

• Stateless (무상태성):

  • 필요한 상태에 대한 정보를 클라이언트가 가지고 오기 때문에 클라이언트의 요청에 어느 서버가 응답해도 상관 없음.
  • 따라서 클라이언트의 요청이 대폭 증가하면 서버를 증설해 해결할 수 있음.

• Connectionless (비연결성):

  • 클라이언트가 서버에 요청을 하고 응답을 받으면 바로 TCP/IP 연결을 끊어 연결을 유지하지 않음으로써 서버의 자원을 효율적으로 관리하고 많은 클라이언트의 요청에 대응할 수 있게 함

• 즉, 무상태성은 클라이언트와 서버 간에 상태 정보를 들고있지않아 클라이언트가 상태 정보를 일일히 http에 실어 요청해야되는 것을 말하고, 비연결성은 클라이언트와 서버 간에 네트워크 연결이 끊어져 단절된다고 이해하면 됨.

연결을 유지하는 모델

• 연결을 유지한다면, 서버와 클라이언트의 연결은 서로의 네트워킹 요청이 없더라도 계속해서 유지된다.
• 자원이 계속해서 사용된다. (이러한 점 때문에, HTTP는 기본적으로 연결을 유지하지 않는 모델이다)

연결을 유지하지 않는 모델.

• 연결을 유지하지 않는다면, 서버의 자원을 효율적으로 사용할 수 있다.
• 다만, 클라이언트가 연결을 계속 끊는 다는 것은 TCP/IP 연결을 매번 새롭게 맺어야 한다는 것을 뜻한다.
• 즉, TCP 3 way handshake를 매번 해야하고, 이는 시간이 걸린다.
• 이러한 문제는 지금 HTTP 지속 연결(Persistent Connections)로 문제 해결하고 있다.
• HTTP/2, HTTP/3에서 더 많은 최적화가 이루어 졌다.

비연결성의 한계 - 단기 커넥션.

• HTTP 초기 - 연결, 종료 낭비

• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등등 수 많은 자원이 함께 다운로드 되는데, 새로 연결을 맺을 때 마다 TCP Handshake가 발생한다는 문제점이 있음

• 그래서 HTTP 초기에는 모든 자료에 대해서 비연결성으로 각각의 자원에 대해 연결/응답/종료를 반복하다보니 대략적으로 1초가량 소모

비연결성 극복 - HTTP 지속 연결.

• 클라이언트는 서버와 소켓 연결을 한 다음 필요한 자원을 요청/응답으로 다운로드.

• 소켓 연결을 일정 시간 동안 더 유지함으로써, 필요한 자원들을 모두 다운받을때까지 연결이 종료되지않고 요청/응답이 반복된 뒤 종료.

5. HTTP의 상태 코드

6. HTTP 메세지

7. HTTP 메서드.

▽ 데이터를 그리기 위한 Front_End 언어 공부하기 : React 프로젝트의 폴더 구조 _ FSD(Feature-Sliced Design) 아키텍쳐.

목  차

1. 📌 FSD 아키텍쳐란?

2. 📌 레이어 (Layers)

3. 📌 슬라이스 (Slices)

4. 📌 세그먼트 (Segments)

5. 📌 엄격한 공개 API 정의 규칙

6. 📌 결론 및 정리.

1. 📌 FSD 아키텍쳐란?

Feature-Sliced Design(FSD) 은 대규모 프론트엔드 애플리케이션(특히 React 기반)의 구조를 "기능 단위로 구조화"하는 아키텍처 패턴.!

직역하면 "기능 분할 설계"입니다. 간단히 말하면, 코드를 조직적으로 구성하기 위한 규칙과 관계의 모음.

“기능(feature) 중심의 독립적이고 유지보수 가능한 구조를 만드는 것” — FSD 공식 철학

• 이 방법론의 주요 목적은 애플리케이션을 '기능 단위로 분할'하여 프로젝트를 더 이해하기 쉬운 구조로 만들기.
  • 프로젝트의 규모가 커져도 유지보수에 유리하도록 하는 데 있음.

🎯 핵심 목적

• 기능 단위로 코드 분리 → 유지보수성과 재사용성 향상

• UI와 비즈니스 로직의 결합도 최소화

• 확장 가능한 구조로 리팩토링 부담 최소화

💡 기존 구조와 비교.

• FSD의 계층 구조는 크게 {레이어,슬라이스,세그먼트}로 나뉘며, 이는 프로젝트의 폴더 구조 트리로 볼 수 있음.

• 폴더 구조의 최상위에는 '레이어(Layers)'가 위치하고,

  • 각 레이어는 슬라이스(Slices)를 포함.
    • 단 app과 shared는 슬라이스를 가지지 않고 직접 세그먼트를 포함.
  • 또한, 각 슬라이스는 세그먼트를 포함.

• 레이어의 이름은 제한적이지만,

  • 슬라이스(Slice)와 세그먼트(segment)의 이름은 자유롭게 선택 가능하며 필요한 만큼 만들 수 있음.
    • 슬라이스는 보통 비즈니스 도메인 별로 분류,
    • 세그먼트는 일반적으로 몇 가지 관례적인 이름을 사용.

2. 📌 레이어 (Layers)

레이어란?

"레이어"는 프로젝트를 최상위부터 가장 기본적인 요소까지 단계적으로 나누어 구성한 폴더구조의 기본 계층.

• FSD의 레이어는 [ app, process, pages, widgets, features, entities, shared ] 총 7개로 구성.(현재는 processes 레이어 제외 6개의 레이어만 사용).
  • 각 레이어는 "명확한 역할과 의존 방향(하위 -> 상위)을 가짐.

src/
├── app/
├── processes/  <-- 현재는 사용되지 않는 레이어.
├── pages/
├── widgets/
├── features/
├── entities/
└── shared/

⚙️ 의존성 방향 규칙: shared → entities → features → widgets → pages → processes → app (하위 레이어는 상위 레이어를 절대 import하지 않는다.)

• 말했다시피, 각 레이어는 고유한 목적을 가지고 있으며, 반드시 모든 레이어를 사용할 필요는 없음.

• 그러나, 사용시에는 일관된 구조와 명명 규칙을 지켜 프로젝트를 더 이해하기 쉽고 유지보수가 용이하게 해야 함.

  • 따라서, 사용 시에는 각 레이어의 이름을 정확히 지켜야 함.

💡 App 레이어.

프로젝트의 진입점이자, 가장 상위의 '전역 설정'을 포함하는 레이어.

• 주로 앱의 시작점이나, 주요 설정을 관리.
• '라우팅', '글로벌 스타일', '최상위 프로바이더' 등을 포함.

• 앱이 시작할 때 특정 테마를 적용하거나, 글로벌 상태 관리를 초기화할 필요가 있는 경우, 'App' 레이어에서 이를 설정 가능.

• 쉽게 말하자면, 'App' 레이어는 애플리케이션의 전반적인 구성을 관리하는 곳.
  • 프로젝트의 루트 구성과 초기 설정이 이루어지는 곳.
  • 모든 애플리케이션의 구성 요소가 이 레이어에서 시작.
    • Ex) 'ThemeProvider'를 사용해 전체 앱에 다크모드 또는 라이트모드를 적용하는 설정을 포함 가능.

• 'App' 레이어는 "애플리케이션 전체의 전역 설정"만 담당하는 레이어이기에 슬라이스가 없고 세그먼트만 가짐.

  • 애플리케이션의 전역 설정들이 한 곳에서 모여 있어야 관리가 편리하기 때문.
    • 예를 들어, 라우팅, 전역 스타일, 테마 설정은 애플리케이션 전반에 걸쳐서 한 번만 설정해두면 되며, 여러 위치에 분산될 필요가 없다.

• 세그먼트로 바로 모아두면 프로젝트 시작 시 설정해야 하는 모든 전역 설정들을 쉽게 찾아 수정 가능.

• 반면, 슬라이스는 기능별로 더 세분화해 나누는 구조라 App 레이어의 간단한 전역 설정에 사용될 필요가 없다.

💡 Processes 레이어 (현재는 사용되지 않음).

Processes 레이어는 페이지 간의 복잡한 시나리오나 워크플로를 관리하기 위해 사용.

• 예를 들어, 사용자 가입이나 결제 처리처럼 여러 페이지에 걸쳐 진행되는 복잡한 절차를 포함했었음.

• 복잡성 증가와 다른 레이어와의 중복성 때문에 현재는 사용이 권장되지 않음.

대신!, 이와 같은 흐름은 Pages 또는 Widgets 레이어로 분산하여 관리 가능.

💡 Pages 레이어.

Pages 레이어는 앱 내 개별 페이지를 정의하는 레이어.

• 특정 URL에 매핑되는 전체 페이지를 구성.

• 주로 라우팅과 관련된 파일이나 페이지에 해당하는 최상위 컴포넌트를 포함.

Ex)

• /home, /profile, /settings와 같은 각각의 페이지를 구성하는 컴포넌트들이 이에 해당.

Pages 레이어는 사용자에게 바로 노출되는 UI 요소이므로 복잡한 비즈니스 로직보다는 사용자 인터페이스와 관련된 로직을 처리.

• 이 레이어는 사용자에게 보여지는 완전한 페이지를 구성.

• UserPage와 같은 경우 사용자 관련 정보와 관련된 여러 widgets와 features가 함께 모여 하나의 페이지를 이룸.

  • ex) UserPage는 사용자 프로필 정보, 설정 관리, 활동 내역 등의 다양한 위젯을 포함해 구성

💡 Widgets 레이어.

Widgets 레이어는 페이지 내에서 독립적으로 작동하는 큰 기능 단위를 포함하는 레이어.

• 이 레이어는 독립적으로 기능하는 큰 규모의 UI 컴포넌트나 기능 블록을 구성하여 다양한 페이지에서 재사용 가능.
  • ex) 검색 바, 대시보드, 사이드바 메뉴 등등.

Widgets는 독립적으로 기능할 수 있으며 다양한 페이지에서 재사용 가능.

• 쉽게 말해, 하나의 위젯은 여러 개의 features와 entities를 포함하여 더 높은 수준의 UI를 구성.
  • Ex) UserProfile 위젯은 사용자의 정보(사진, 이름, 팔로워 수 등)를 표시하는 컴포넌트로 구성
    • 이 위젯에는 FollowUser와 같은 features 레이어의 기능이 포함되어 사용자가 다른 사용자를 팔로우할 수 있는 기능을 제공.
      • 이러한 위젯은 UserPage, HomePage 등 여러 페이지에서 재사용 가능.

💡 Features 레이어.

Features 레이어는 재사용 가능한 비즈니스 기능을 위한 레이어로, '독립적으로 동작'할 수 있는 하나의 특정 동작을 정의.

EX)

• 사용자 팔로우 기능 (FollowUser)은 features 레이어에 위치해 재사용 가능하고 독립적인 비즈니스 기능으로 동작.

features는 다양한 페이지와 위젯에서 사용할 수 있도록 기능을 추상화하는 레이어.

일부 슬라이스의 model 세그먼트에 비즈니스 로직이 포함되어 있더라도, features 레이어는 여전히 필요.

• 이유는 features 레이어가 여러 페이지와 위젯에서 재사용 가능한 독립적 비즈니스 로직을 제공하기 때문.
  • 이 레이어가 없으면 동일한 비즈니스 기능을 구현할 때마다 중복 코드가 발생할 가능성이 높아짐.
    • 특정 기능을 유지보수하거나 업데이트할 때 여러 페이지와 위젯에서 동일한 수정이 필요해 비효율적.

• 따라서 특정 레이어의 model 세그먼트에 해당 레이어 전용 로직을 포함할 수는 있지만, 재사용성과 독립성을 위해 보편적인 비즈니스 로직은 features 레이어에 두는 것이 좋음.

  • 이렇게 하면 여러 페이지에서 동일한 features 기능을 가져다 사용할 수 있어서 확장성과 유지보수성이 향상된다.

💡 Entities 레이어.

Entities 레이어는 프로젝트에서 다루는 비즈니스의 핵심 데이터를 나타내는 레이어.

• 이 레이어에는 주로 데이터 모델과 해당 데이터에 대한 로직이 포함.

Ex)

• User 엔터티는 사용자 관련 정보를 관리하며, 이름, 이메일, 프로필 사진 등 사용자의 주요 정보를 다룸.

• Entities 레이어는 다양한 페이지와 위젯에서 사용되는 비즈니스 핵심 데이터와 관련 로직을 제공

💡 Shared 레이어.

Shared 레이어는 프로젝트 전반에서 재사용할 수 있는 유틸리티, 기본적인 컴포넌트, 스타일 등의 전반적인 리소스를 포함하는 레이어

• 이 레이어의 요소들은 특정 기능이나 비즈니스에 국한되지 않고 전반적으로 사용.

Ex)

• Button 컴포넌트는 shared 레이어에서 제공.
  • 이 컴포넌트는 스타일과 인터랙션을 정의해 여러 기능과 페이지에서 재사용.
  • 다양한 스타일을 지원하는 Button 컴포넌트는 FollowUser 기능이나 UserPage와 같은 여러 페이지와 위젯에서 쉽게 활용.

shared 레이어도 app 레이어와 마찬가지로 슬라이스가 없는데, 이유는 이 레이어가 전역적으로 재사용 가능한 요소들만 모아두기 위한 공간이기 때문.

shared는 프로젝트 전반에서 공통으로 사용할 수 있는 유틸리티, 기본 컴포넌트, 스타일 등을 포함하며, 특정 기능이나 비즈니스 로직과는 무관.

슬라이스는 보통 특정 기능이나 비즈니스 도메인에 맞춰 세분화할 때 사용되는데,

• shared 레이어는 모든 기능에서 공통으로 사용할 수 있는 요소들을 제공하기 때문에 따로 나누지 않고 하나의 모음으로 관리하는 것이 더 효율적.
  • 이로 인해 shared의 요소들은 프로젝트 어느 부분에서도 자유롭게 사용할 수 있으며, 코드의 중복을 줄이고 유지보수성을 높일 수 있음.

3. 📌 슬라이스 (Slices)

4. 📌 세그먼트 (Segments)

5. 📌 엄격한 공개 API 정의 규칙

6. 📌 결론 및 정리.

▽ [데이터를 위한 자격증 공부] 정보 처리 기사 인강 듣기.

정처기 실기를 진짜 이번에는 따기 위해서 인강을 듣고 벼락치기로 공부해보겠습니다 ㅋㅋㅋ

강의 수만 108개?...? 진자 빡시게 공부해가지고 C/Java/Python 코딩 언어 맞추고, SQL 맞추고 이론 몇 문제만 맞춰서 합격을 노려보겠습니다.

제발 이번엔 합격을...

제가 듣고 있는 강의는 인프런의 주말코딩 : (2025) 일주일만에 합격하는 정보처리기사 실기 라는 강의를 듣고 있습니다.

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요. 🤗

강의 링크

▽ [DevOps] Github Action과 필요한 개념정리.

목      차

1. CI/CD란 무엇이고 왜 필요할까?

2. Github Action이란

3. Github Action 명령어 사용법

1. CI/CD란 무엇이고 왜 필요할까?

DevOps 철학 : 문화, 프로세스, 도구의 결합.

DevOps (Development + Operations)는 단순히 도구의 집합이 아니라, 소프트웨어 개발과 IT 운영 팀 간의 협업과 자동화를 강조하는 문화적, 전문적 변화.

• 목표는 소프트웨어를 더 빠르게, 더 안정적으로, 더 자주 배포하는 것.

직군별 초점(백엔드/데브옵스/데이터엔지니어)

CI/CD란 무엇인가??

CI/CD는 개발 프로세스의 반복적인 부분을 자동화하는 일련의 관행을 의미하며, DevOps 문화의 핵심적인 기술 구현체.

CI/CD의 목적은?

반복적인 일(빌드,테스트,배포 작업 등)들을 처리하고 문제가 있을 때 경고를 해주는 등 '자동화된 파이프라인'을 통해서 코드 변경과 배포 단계를 원활하게 진행 가능.

• 즉, 자동화를 통해 시간 절약 및 휴먼에러를 관리 가능함.

CI: 지속적 통합(Continuous Integration)

정의.

• 개발자들이 각자의 작업 코드를 공유 레포지토리에 자주 통합(Merge)하는 관행.

• 코드를 통합할 때마다 자동화된 "빌드(Build) 및 테스트(Test)"를 실행하여 문제가 없는지 검증 가능.

  • 추가,변경(push나 pull request)된 코드를 빌드하고 테스트 하는 프로세스를 자동화하는 것
  • 위와 같은 프로세스를 거친후에 병합(통합) 즉, 코드를 merge해주는 것
  • 다수의 인원이 함께 개발할때 충돌과 같은 일들을 미연에 방지 가능하며 Lint(코드 규칙)를 잘 지켰는지, 제대로 동작하는지 등 확인가능

목표.

• 코드 통합 과정에서 발생하는 충돌이나 오류를 조기에 발견하고 해결하여, 메인 브랜치의 코드 품질과 안정성을 지속적으로 유지하는 것.

CD : 지속적 제공/배포(Cotinuous Delivery / Continuous Deployment)

CI를 통과하여 안정성이 검증된 코드를 사용자에게 제공하는 단계.

• Delivery과정은 CI 과정을 거친후에 병합하여 실행테스트를 할 수 있도록 하는 것
• Deployment는 뜻 그대로 배포 과정을 자동으로 처리 해주는 것

지속적 제공(Continuous Delivery, CDe)

• 의미 : 코드가 테스트를 통과하고 릴리스 준비가 완료된 상태로 "배포 가능한 저장소"에 항상 유지되는 것.
• 최종 단계 : "수동 승인" 후 실제 운영 환경에 배포.

지속적 배포(Continuous Deployment, CDp)

• 의미 : 코드가 테스트를 통과하면 사람의 개입 없이 자동으로 운영 환경까지 릴리스되는 것

• 최종 단계 : "자동 배포"까지 완료.

CI/CD는 왜 필요할까??

CI/CD는 개발 팀의 효율성을 극대화하고, 사용자에게 더 빠르고 안정적인 서비스를 제공하기 위해 필수적.

개발 속도 향상 및 효율성 극대화.

• 배포 주기의 단축 : 수동 배포에 드는 시간과 노력을 자동화하여,

  새로운 기능을 몇 시간 또는 몇 분 만에 릴리스 가능.
    - 시장 변화에 민첩하게 대응 가능하게 해줌.

• 개발 집중 : 개발자가 반복적이고 지루하며 실수하기 쉬운 빌드, 테스트, 배포 작업 대신 핵심적인 코딩 및 문제 해결에 집중할 수 있도록 함.

위험 감소 및 코드 품질 향상.

• 오류의 조기 발견(CI) : 코드를 자주 통합하고 테스트하기 때문에, 버그가 큰 문제로 발전하기 전에 작은 단계에서 즉시 발견하고 수정 가능.

  - 통합 문제(Integration Hell)를 방지.

• 안정적인 릴리스(CD) : 자동화된 테스트를 거친 코드만 배포되므로, 수동 배포 과정에서 발생하는 사람의 실수(Human Error)가 줄어들고 서비스의 안정성이 높아짐.

• 신속한 롤백 : 배포 실패나 심각한 운영 문제가 발생할 경우, CI/CD 파이프라인을 통해 이전의 안정적인 버전으로 신속하게 롤백(Rollback)하는 과정을 자동화할 수 있어 서비스 중단을 최소화.

협업 강화 및 피드백 루프 단축.

• 투명성 : 모든 팀원(개발, QA, 운영)이 빌드, 테스트, 배포의 진행 상황을 실시간으로 모니터링할 수 있어 협업이 투명.

• 피드백 가속화 : 사용자나 테스터의 피드백이 서비스에 반영되는 시간이 짧아져, 제품 개선이 지속적으로 이루어지는 선순환 구조.

CI/CD 파이프라인의 필수 구성 요소

현업의 CI/CD 파이프라인은 단순히 빌드와 배포를 넘어서 다양한 검증 단계를 포함.

$$\text{CI} \rightarrow \text{코드 분석/보안 스캔} \rightarrow \text{테스트 (단위/통합)} \rightarrow \text{Artifact 생성} \rightarrow \text{CD (배포)} \rightarrow \text{모니터링 연동}$$

• 데브옵스 관점 : 파이프라인 내에 terraform plan (IaC 검증) Job이나 SonarQube Scan (코드 품질) Job을 의무적으로 포함하여 안정성을 강화.

• 데이터 엔지니어 관점 : dbt test나 데이터 품질 검사 Job을 포함하여, 데이터셋에 대한 변경이 파이프라인에 통합되기 전에 검증.

2. Github Action이란

GitHub Actions는 GitHub 저장소 내부에서 소프트웨어 개발 워크플로를 자동화, 사용자 지정 및 실행할 수 있도록 하는 CI/CD 및 자동화 플랫폼.

1. GitHub Actions의 기본 개념.

GitHub Actions는 이벤트 기반 자동화 엔진으로, GitHub 리포지토리에서 발생하는 특정 이벤트(예: 코드 푸시, 풀 리퀘스트 생성 등)를 감지하여 일련의 자동화된 작업(Workflow)을 실행.

자동화된 워크플로 (Automated Workflow)

• YAML 기반:

  • 모든 자동화 로직은 리포지토리의 .github/workflows 디렉터리 내에 YAML 파일 형식으로 정의.

• 통합 환경 :

  • 코드가 있는 동일한 플랫폼(GitHub) 내에서 CI/CD 및 기타 자동화 작업을 처리함으로써, 별도의 외부 CI 서버(예: Jenkins)를 구축하고 연동할 필요성을 없애줌.

주요 구성 요소(Components)

GitHub Action의 현업 활용 범위(Beyond CI/CD)

GitHub Actions는 단순히 CI/CD(빌드/테스트/배포)뿐만 아니라, 리포지토리 관리 및 개발 프로세스 전반을 자동화하는 데 사용.

활용 분야 : 백엔드/데브옵스 개발자 관점.

CI/CD

• 코드 푸시 시 Docker 이미지 빌드 및 EKS/EC2에 자동 배포.

코드 품질

• Pull Request 시 정적 분석 도구(SonarCloud, Lint) 실행 및 결과 보고.

인프라 관리

• Terraform 코드 변경 시 terraform plan 실행 결과를 PR에 댓글로 자동 게시.

자동화 관리

• 오래된 브랜치나 이슈 자동 종료, 릴리스 노트 자동 생성.

활용 분야 : 데이터 엔지니어 관점.

CI/CD

• Airflow DAGs 변경 시 Syntax 검사 후 Airflow 서버로 자동 동기화.

  코드 품질

• dbt test 또는 Great Expectations를 실행하여 데이터 품질 사전 검증.

인프라 관리

• 데이터셋 변경 이벤트 발생 시 ML 모델 학습 파이프라인 자동 트리거.

자동화 관리

• 주기적인 Cron 기반 스케줄링으로 데이터 통계 생성 및 Slack 알림.

심화 개념.

Secrets 및 Environment를 통한 보안 관리

현업에서는 환경 변수 대신 GitHub Secrets를 사용하여 민감 정보를 안전하게 주입.

• Environment (배포 환경) :

  • 개발, 스테이징, 운영 등 환경별로 Job을 분리하고, 각 환경에 필요한 Secret을 할당하여 격리 관리.

• 수동 승인 (Approval) :

  • 운영 환경(Production Environment) 배포 시 Required reviewers 기능을 통해 특정 팀 리더나 데브옵스 엔지니어의 수동 승인 없이는 Job이 실행되지 않도록 설정.

Caching 전략을 통한 성능 최적화

CI의 실행 시간을 줄이는 가장 중요한 방법.

• actions/cache :
  • Node Modules, Maven .m2, Python .venv 등 의존성 파일을 캐시하여 반복적인 설치 시간을 제거.
  • 캐시 키를 package-lock.json이나 pom.xml의 해시값에 연동하여 정확한 복원(Hit)율을 유지하는 것이 핵심.

Job 간의 데이터 공유 (Artifacts)

Job은 독립적인 환경에서 실행되므로, 파일이나 데이터 공유를 위해 Artifacts를 사용.

• 활용 예시:

  • 빌드 Job: JAR 파일(Artifact)을 업로드.

  • 테스트 Job: 업로드된 JAR 파일을 다운로드하여 통합 테스트 실행.

  • 배포 Job: JAR 파일을 다운로드하여 운영 서버에 배포.

Self-hosted Runner (데브옵스 관점)

• 필요성 :

  • GitHub 호스팅 러너의 제한적인 사양이나 시간을 초과하는 대용량 작업(예: 대규모 데이터 처리, 무거운 빌드)이 필요할 때,
  • 또는 기업 내부망(VPC)에만 접근 가능한 리소스에 배포해야 할 때 사용.

• 장점 : 비용 절감 및 인프라 환경 사용자 정의가 가능.

3. Github Action 명령어 사용법

셀 명령어 직접 실행: run

run 키워드는 Runner(가상 환경)의 기본 셸(Bash, PowerShell 등)을 사용하여 스크립트나 명령어를 실행할 때 사용.

기본 사용법.

가장 일반적인 형태는 단일 명령어를 실행하는 것

YAML

steps:
  - name: Install Dependencies
    run: npm install # 단일 셸 명령어 실행

멀티라인 스크립트 사용.

여러 줄의 명령어를 순차적으로 실행해야 할 때는 YAML의 파이프(|) 문법을 사용. 이는 특히 복잡한 빌드나 환경 설정을 할 때 유용.

YAML

steps:
  - name: Build and Test Application
    run: | # 파이프 문법으로 여러 줄의 셸 명령어 실행
      echo "Starting build process..."
      npm run build
      npm run test
      echo "Build successful."

환경 변수 사용.

Step이나 Job 레벨에서 정의된 환경 변수(env)를 셸 스크립트 내에서 사용.

YAML

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      NODE_ENV: production # Job 레벨 환경 변수

    steps:
      - name: Deploy to Server
        env:
          TARGET_HOST: ${{ secrets.SERVER_IP }} # Step 레벨 환경 변수 (Secrets 사용)
        run: |
          echo "Deploying to $TARGET_HOST in $NODE_ENV mode."
          ssh user@$TARGET_HOST 'sudo systemctl restart api-server'

재사용 가능한 액션 사용: uses

uses 키워드는 미리 정의되고 패키징된 Action을 가져와 실행할 때 사용. 이는 복잡한 설정 과정을 한 줄로 단순화하여 Workflow의 가독성과 효율성을 높여줌.

기본 사용법 및 버전 관리

{소유자}/{리포지토리}@{버전} 형태로 Action을 지정하며, 안정성을 위해 특정 버전(태그, 커밋 SHA)을 명시하는 것

YAML

steps:
  - name: Checkout Code
    uses: actions/checkout@v4 # GitHub 공식 Action 사용

  - name: Set up Python
    uses: actions/setup-python@v5 # 서드파티 Action 사용
    with:
      python-version: '3.11' # Action의 입력 값(Input) 지정

액션의 입력 (with)

대부분의 Action은 with 키워드를 통해 설정을 위한 입력 값(Input)을 받습니다. 이는 Action의 동작 방식을 사용자 정의할 때 사용

YAML

steps:
  - name: AWS Credentials Setup
    uses: aws-actions/configure-aws-credentials@v4
    with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} # Secrets을 입력으로 전달
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: ap-northeast-2

액션 결과 사용 (Outputs)

일부 Action은 실행 결과를 출력 값(Output)으로 제공합니다. 이 출력 값은 Step ID와 outputs 컨텍스트를 사용하여 후속 Step에서 접근가능.

YAML

steps:
  - name: Get Short Commit SHA
    id: get_sha # 이 Step에 ID 지정
    run: echo "short_sha=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT
    # get_sha Step의 출력 값으로 short_sha 정의

  - name: Tag and Push Docker Image
    run: docker push my-repo/my-image:${{ steps.get_sha.outputs.short_sha }}
    # 이전 Step의 출력 값을 사용하여 Docker 태그에 적용

심화 명령어 제어: 조건부 실행

IF 조건문

if 키워드를 사용하여 표현식(Expression) 기반의 조건을 정의.

YAML

steps:
  - name: Deploy to Production
    if: github.ref == 'refs/heads/main' && success()
    # main 브랜치에 대한 push 이벤트이고, 이전 Step/Job이 성공했을 때만 실행
    run: echo "Initiating production deployment..."

상태 함수 활용

if 문에서 사용할 수 있는 기본 상태 함수는 다음과 같음.

YAML

steps:
  - name: Send Failure Notification
    if: failure() # 이전 Job/Step이 실패했을 때만 실행
    uses: slackapi/slack-notify-action@v1
    # ... 알림 설정

▽ 데이터를 위한 Back_End 공부하기 : Tomcat.

목  차

1. 톰캣의 주요 개념 및 역할.


2. 톰캣의 특징 및 장점.

1. 톰캣의 주요 개념 및 역할.

톰캣이란

Apache Tomcat은 Java 웹 애플리케이션을 구동하기 위한 오픈 소스 소프트웨어이며, 웹 서버(Web Server) 기능과 서블릿 컨테이너(Servlet Container) 기능을 결합한 웹 애플리케이션 서버(WAS)

Java 개발 환경에서 웹 애플리케이션을 실행하는 데 가장 널리 사용되는 사실상의 표준(de facto standard).

톰캣의 정체 : WAS(웹 어플리케이션 서버)

• 정의 : 톰캣은 클라이언트의 HTTP 요청을 받고 처리하며, 특히 동적인 콘텐츠를 생성하여 응답하는 역할을 수행.

• 구성 : 톰캣은 HTTP 웹 서버의 기능(요청/응답 처리)과 서블릿 컨테이너의 기능을 모두 갖추고 있어 WAS로 불림.

핵심 역할 : 서블릿 컨테이너 (Servlet Container)

톰캣의 가장 핵심적인 역할.

• 서블릿과 JSP 실행 환경

  • 톰캣은 Java Servlet과 JSP(Java Server Pages) 코드를 실행할 수 있는 환경을 제공
  • 클라이언트로부터 요청이 들어오면, 이 코드를 실행하여 동적인 콘텐츠(데이터베이스 조회 결과, 로직 처리 결과 등)를 생성.

• 수명 주기 관리

  • 서블릿의 생성, 초기화, 요청 처리, 소멸에 이르는 서블릿의 수명 주기(Lifecycle)를 관리.

• 표준 구현체

  • 톰캣은 Java EE(현재 Jakarta EE) 표준 중 Servlet 및 JSP 명세에 대한 공식 레퍼런스 구현체.

웹 애플리케이션 서버 (WAS, Web Application Server)

톰캣은 웹 서버 기능과 서블릿 컨테이너 기능을 모두 수행하므로 WAS로 분류.

• 동적 콘텐츠 처리:

  • 데이터베이스 조회, 비즈니스 로직 처리 등 동적인 데이터를 처리하고 HTML 형태로 클라이언트에게 응답을 제공.

• 독립 실행:

  • 톰캣은 자체적인 HTTP 웹 서버 기능을 내장하고 있어, 단독으로 실행되어 클라이언트의 HTTP 요청을 받고 처리 가능.

Apache HTTP Server와의 관계

톰캣이 "아파치 톰캣"이라고 불리는 이유는 Apache Software Foundation(아파치 소프트웨어 재단)에서 개발하고 관리하기 때문.

• Apache HTTP Server (웹 서버, WS):

  • 주로 HTML, 이미지, CSS, JS 파일과 같은 정적 콘텐츠를 효율적이고 빠르게 처리.

• Apache Tomcat (WAS): 주로 동적 콘텐츠를 처리.

대규모 서비스에서는 성능과 안정성을 위해 Apache HTTP Server(WS)를 톰캣(WAS)의 앞단(프론트)에 두고, 정적 파일은 웹 서버가 처리하고 동적 요청만 톰캣으로 넘기는 방식으로 연동하여 사용하기도함.

2. 톰캣의 특징 및 장점.

경량성 및 속도:

• 상용 WAS 제품들에 비해 가볍고 시작 및 구동 속도가 빨라 중소규모 프로젝트나 개발 테스트 환경에 매우 적합.

오픈 소스:

• Apache License를 따르는 오픈 소스 소프트웨어로, 누구나 자유롭게 사용가능.

높은 점유율:

• 전 세계적으로 가장 널리 사용되는 Java 기반 WAS 중 하나이므로, 관련 자료나 커뮤니티 지원이 풍부.

Spring Boot의 내장 서버:

• Spring Boot 애플리케이션을 개발할 때 기본적으로 내장되어 함께 실행되는 서버가 바로 톰캣(Embedded Tomcat).
• 덕분에 개발자가 별도의 설치 과정 없이 쉽게 애플리케이션을 실행하고 배포 가능.

▽ 데이터를 위한 Back_End 공부하기 : Spring과 Spring Boot의 차이.

목  차

1. Spring Framework와 Spring Boot의 개념 💡

2. Spring과 Spring Boot의 공통점 및 차이점 🔄

3. 개발 관점에서의 장단점 (Java Backend Developer View) 🧑‍💻

4. 확장 관점에서의 분석 (Data Engineer / DevOps View) 🛠️

Spring과 Spring Boot는 Java 백엔드 개발의 핵심 기술이지만, 그 역할과 접근 방식에는 명확한 차이가 있음. ->두 기술의 개념, 공통점, 차이점, 그리고 개발 및 운영 관점에서의 장단점을 깊이 있게 정리

1. Spring, Spring Framework와 Spring Boot의 개념 💡

이 세 용어는 서로 밀접하게 연결되어 있지만, 정확한 역할과 범위를 구분하는 것이 중요.

Spring Framework (핵심 기반 / 프레임워크) ⚙️

• 의미 : Spring 생태계의 '가장 근간'이 되는 '핵심 프레임워크'.

• 핵심 기능.

  • IoC (Inversion of Control)와 DI (Dependency Injection):

    • 객체의 생성 및 관계 설정을 Spring 컨테이너가 대신 관리하여 개발자가 비즈니스 로직에 집중 가능하도록 함.

  • AOP (Aspect-Oriented Programming):

    • 횡단 관심사(보안,로깅,트랜잭션 등)를 모듈화하여, 코드의 중복을 줄이고 유지보수를 용이하게 함.

• 역할 : 개발자가 엔터프라이즈 애플리케이션의 기본 구조와 핵심 비즈니스 로직을 구축할 수 있도록 가장 기본적인 토대와 프로그래밍 모델을 제공.

• 목표 : 복잡한 엔터프라이즈 환경에서 POJO (Plain Old Java Object) 방식의 개발을 가능하게 하여 생산성과 테스트 용이성을 높이는 것.

• 요약 : Spring Framework는 IoC, DI, AOP라는 철학을 기반으로 하는 가장 중요한 핵심 모듈의 집합.

Spring (광의의 개념 / 생태계) 🌐

• 의미 : Spring 생태계(Ecosystem) 전체를 통칭하는 광범위한 용어.

  • Spring Framework의 핵심 모듈들을 기반으로 한 프레임워크로 엔터프라이즈 애플리케이션 개발을 지원하기 위한 대규모 오픈 소스 프로젝트

• 포함 범위

  • Spring Framework를 기반으로 하며, 그 외 데이터 접근, 보안, 클라우드 환경 통합, 배치 처리 등을 위한 모든 공식 서브 프로젝트와 모듈을 포함.

• 핵심 프로젝트 예시.

  • Spring Data: 데이터베이스 접근 편의성 제공 (JPA, MongoDB 등).

  • Spring Security: 인증 및 권한 부여 기능 제공.

  • Spring Batch: 대규모 배치 처리 기능 제공.

  • Spring Cloud: 분산 시스템 및 클라우드 환경 개발 지원.

• 요약 : Spring은 Java 엔터프라이즈 개발을 위한 도구와 프로젝트의 거대한 총집합.

Spring Boot (도구 / 개발 가속기) 🚀

• 정의 : Spring Framework를 더 쉽고 빠르게 활용할 수 있도록 도와주는 도구 및 관례 기반의 접근 방식.

  • Spring Framework의 단점(복잡한 초기 설정)을 해결해줌.

• 핵심 기능.

  • 자동 설정(Auto Configuration). : 클래스 패스를 분석하여 필요한 라이브러리와 환경 설정을 자동으로 추론하고 구성.

    • Spring Boot는 애플리케이션의 설정을 자동으로 구성.
    • @EnableAutoConfiguration, @SpringBootApplication 어노테이션을 통해 자동 설정을 활성화.

    • Starter 의존성.(의존성 관리 간소화) : 특정 기능에 필요한 모든 라이브러리를 하나의 의존성 패키지로 묶어 제공하여 의존성 관리를 간소화.

      • 특정 기능을 쉽게 추가할 수 있도록 여러 개의 라이브러리와 의존성을 하나의 패키지로 묶어 제공하는 starter 의존성 통합 모듈을 제공.
      • 예: spring-boot-starter-web, spring-boot-starter-data-jpa, spring-boot-starter-security

    • 내장 웹 서버를 통해 Spring의 초기 설정과 복잡한 의존성 관리를 자동화. : Tomcat, Jetty 등 웹 서버를 내장하여 별도의 WAS 설정 없이 JAR 파일로 독립 실행 및 배포가 가능.

      • 배포를 위해 War 파일을 생성해서 Tomcat에 배포할 필요 없으며, JAR 파일에는 모든 의존성 라이브러리가 포함되어 있어 외부 서버 없이도 애플리케이션을 실행 가능.

• 역할 : 설정을 최소화하고, 개발자의 생산성을 극대화하여 "Just Run"할 수 있는 애플리케이션을 신속하게 만들고 운영하기 쉽게 만들어줌.

• 목표 : "Just Run"할 수 있는 독립 실행형(Standalone) Spring 애플리케이션을 신속하게 구축하고 실행하는 것.

• 요약 : Spring Boot는 Spring Framework 기반의 애플리케이션을 빠르고 쉽게 만들고 실행하게 해주는 편의 기능과 자동화 도구.

2. Spring과 Spring Boot의 공통점 및 차이점 🔄

공통점.

기반 기술.

• 둘 다 Spring Framework 기반.

• Spring Boot는 Spring Framework의 기능을 활용하고 확장하여 사용.

핵심 원리.

• IoC(제어의 역전), DI(의존성 주입), AOP와 같은 Spring의 핵심 설계 원리를 그대로 공유.

모듈 사용.

• Spring Data JPA, Spring Security, Spring Web 등 Spring Framework의 핵심 모듈을 모두 사용 가능.

차이점.

설정 방식.

Spring Framework(Core)

• 수동 구성(XML 또는 Java Config),
• 개발자가 {빈, 의존성, 환경 설정} 등을 상세히 정의해야 함.

Spring Boot.

• 자동 구성(Auto Configuration) : 클래스패스 기반으로 설정을 추론하고 대부분 자동 처리.

의존성 관리.

Spring Framework(Core)

• 각 라이브러리와 버전을 '개별적으로 명시'하고 충돌을 수동으로 해결.

Spring Boot.

• Starter 의존성' 제공,
  • 기능 단위로 필요한 모든 의존성을 통합하고 버전 관리까지 자동 처리.

웹 서버.

Spring Framework(Core)

• 외부 WAS (Web Application Server) (Tomcat, Jetty 등)를 별도로 설치하고 WAR 파일을 배포해야 함.

Spring Boot.

• 내장 WAS (Embedded Tomcat, Jetty)를 제공하여 JAR 파일로 독립 실행 및 배포 가능.

개발 속도.

Spring Framework(Core)

• 초기 설정 및 환경 구성에 시간이 많이 소요됨.

Spring Boot.

• 개발 시작이 매우 빠르며, 최소한의 설정으로 즉시 실행 가능.

배포 방식.

Spring Framework(Core)

• 전통적인 WAR 파일 배포 방식이 일반적.

Spring Boot.

• '실행 가능한 JAR'파일을 통한 독립 실행 방식이 일반적.

3. 개발 관점에서의 장단점 (Java Backend Developer View) 🧑‍💻

Spring Framework의 장/단점..

Spring Boot의 장/단점..

4. 확장 관점에서의 분석 (Data Engineer / DevOps View) 🛠️

Spring Boot는 단순히 개발의 편리성을 넘어, 데이터 파이프라인 구축 및 운영 환경(DevOps)에 큰 이점을 제공.

데이터 엔지니어 관점 📊

Spring Framework.

• 데이터 엔지니어 관련 장점.
  • 대규모 배치 처리 :
    • Spring Batch를 사용하여, 복잡하고 상세한 제어가 필요한 대용량 배치 작업을 구축할 때 유용.

• 예시
  • 매일 새벽 DB 데이터 정리, ETL(Extract, Transform, Load) 작업 중 T(Transform) 레이어 구현.

Spring Boot.

• 데이터 엔지니어 관련 장점.

  • 빠른 마이크로서비스 구축:

    • 데이터 처리 파이프라인의 각 단계를 독립적인 REST API 서비스(마이크로서비스)로 빠르게 구축할 수 있음.

  • 간편한 클라우드 통합:

    • Spring Cloud 프로젝트와 연계하여 서비스 디스커버리, 설정 관리 등 클라우드 환경에 최적화된 데이터 파이프라인을 쉽게 구성.

• 예시
  • 데이터 검증 서비스, Kafka/RabbitMQ 리스너, 데이터 로깅 서비스.
  • AWS, GCP, Azure 등의 클라우드 환경에서 분산된 데이터 처리 서비스 구축.

데브옵스 관점 🚀

Spring Framework.

• DevOps 관련 장점

  • WAS 최적화 배포:
    • 외부 WAS를 사용하여 WAS 수준에서의 최적화(Connection Pool 튜닝 등) 및 인프라 표준화가 가능.

• 설명

  • 전통적인 온프레미스 환경 또는 엄격한 규제가 있는 환경.

Spring Boot.

• DevOps 관련 장점

  • 1. 독립 실행형 JAR:
       • 애플리케이션과 서버가 하나로 묶여 Immutable Infrastructure(불변 인프라) 구축에 최적. (컨테이너화 용이)
  • 2. Actuator:
       • /health, /metrics, /info 등의 엔드포인트를 기본 제공하여 모니터링 및 상태 확인에 대한 오버헤드가 없음.
  • 3. 설정 관리 표준화:
       • application.properties나 application.yml을 통해 외부 설정(환경 변수)을 쉽게 주입받아 12 Factor App 원칙을 준수하기 용이.

• 설명

  • Docker, Kubernetes (K8s) 환경에서 배포 표준화 및 스케일 아웃이 극도로 용이.
  • Prometheus, Grafana와 같은 모니터링 툴과 연동하여 서비스 상태 및 성능을 쉽게 파악.
  • 개발/스테이징/운영 환경별 설정을 일관되게 관리.

▽ [ 데이터를 위한 Python : From Scratch to Master. ] 파이썬 웹 백엔드 개발의 필요 요소 : WSGI-guicorn & ASGI-uvicorn

목  차

1. 정리하는 계기

2. WSGI란?

3. guicorn이란?

4. ASGI란?

5. uvicorn이란?

1. 정리하는 계기

파이썬으로 데이터를 서빙하는 백엔드 서버를 구성해보고 싶다는 생각에 진행했던 최근 프로젝트인 '자세 교정 웹' 프로젝트에서 파이선 프레임워크를 FastAPI로 선택하면서 웹을 띄우는 과정에서 uvicorn이 사용되었는데, 이걸 좀 더 알아보고 정리하고자 포스팅합니다.

2. WSGI란?

로컬 개발 환경에서의 파이썬-Django,Flask.

로컬에서 장고 서버를 구동하기 위해서는 python manager.py runserver 처럼 장고의 내장 서버를 구동하는 방식을 사용.

장고의 내장서버

• 장고의 내장 서버는 이번 장에서 설명할 웹 서버와 WSGI 서버의 기능을 모두 포함하고 있다. 다만 내장 서버는 기능이 단순하고 '대량 요청'이나 '동시 요청'을 효율적으로 처리하지 못하므로 운영 환경에는 적합하지 않다.

웹 브라우저.

웹 브라우저(Web Browser)는 사용자가 인터넷상의 웹 페이지와 기타 콘텐츠에 접근하고, 상호 작용하며, 그 내용을 볼 수 있도록 하는 소프트웨어 애플리케이션.

• 정적 페이지와 동적 페이지로 구성.

정적 페이지.

정적 페이지는 서버에 파일 형태로 저장되어 있으며, 사용자에게 요청될 때마다 동일한 내용을 제공하는 웹 페이지.

• 정의: 내용이 미리 완성되어 파일 시스템에 저장되어 있음. 사용자의 신원, 시간, 요청 내용과 관계없이 항상 똑같은 HTML, CSS, JavaScript 파일이 전송.

• 특징:

  • 고정된 내용: 파일 내용 자체가 변하지 않습니다.

  • 빠른 속도: 서버는 단순히 저장된 파일을 읽어 전송하기 때문에 처리 속도가 매우 빠릅니다.

  • 낮은 부하: CPU 연산이나 데이터베이스(DB) 접근이 필요 없어 서버 부하가 낮습니다.

• 처리 주체: 주로 웹 서버 (예: Nginx, Apache)가 직접 처리.

• WSGI와의 관계: 정적 파일 요청은 WSGI 서버로 전달되지 않고 웹 서버가 직접 처리하므로, WSGI는 관여하지 않음.

동적 페이지.

동적 페이지는 사용자의 요청 시점에 서버 측 프로그램(웹 애플리케이션)이 데이터베이스 조회나 비즈니스 로직을 수행하여 내용을 생성한 후 사용자에게 제공하는 웹 페이지.

• 정의: 요청마다 서버에서 데이터 처리 후 콘텐츠가 실시간으로 만들어지므로, 사용자나 시점에 따라 페이지 내용이 달라집니다.

• 특징:

  • 가변적인 내용 : 요청 매개변수나 DB 상태에 따라 페이지 내용이 바뀜.

  • 높은 유연성 : 사용자별 맞춤 정보, 검색 결과, 로그인 등 복잡한 기능을 구현할 수 있음.

  • 상대적 부하 : DB 접근, 연산, 템플릿 렌더링 등의 과정이 필요하여 정적 페이지보다 처리 시간이 길고 서버 부하가 높음.

• 처리 주체: 웹 애플리케이션 서버(WAS) 또는 웹 프레임워크 (예: Django, Flask)가 담당.

• WSGI와의 관계: 웹 서버가 동적 요청을 받으면, 이 요청을 파이썬 웹 애플리케이션으로 전달하기 위해 WSGI 표준을 따르는 WSGI 서버 (예: Gunicorn)를 중개자로 사용합니다. WSGI가 핵심적으로 작동하는 영역.

WSGI 환경에서의 요청 흐름.

WSGI를 사용하는 일반적인 구성(Nginx/Apache + Gunicorn/uWSGI + Django/Flask)에서 요청은 다음과 같이 분리.

1. 클라이언트 요청 수신: 웹 브라우저가 웹 서버(Nginx 등)에 요청을 보냅니다.

2. 요청 종류 판단:

   • 정적 요청 (.css, .js, .png 등): 웹 서버가 자신의 저장 공간에서 파일을 찾아 직접 클라이언트에 응답합니다.

   • 동적 요청 (/login, /posts/123 등): 웹 서버는 요청을 WSGI 서버 (Gunicorn 등)로 전달(프록시)합니다.

3. 동적 요청 처리: WSGI 서버는 WSGI 규약에 따라 요청을 파이썬 웹 애플리케이션으로 전달하고, 앱이 생성한 동적 콘텐츠를 받아 다시 웹 서버를 통해 클라이언트에게 응답합니다.

• 이러한 분리 덕분에 웹 서버는 단순하고 빠른 정적 파일 서빙에 집중하고, WAS는 복잡한 동적 로직 처리에 집중하여 시스템의 효율성을 극대화.

WSGI란?

WSGI는 웹 서버(Web Server) 소프트웨어와 파이썬으로 작성된 웹 애플리케이션 또는 웹 프레임워크 간의 통신을 위한 표준 인터페이스(규약).

• 이 표준은 2003년 PEP 333으로 처음 제안되었고 이후 PEP 3333으로 개정되며 파이썬 웹 개발의 사실상 표준으로 자리 잡음.

WSGI 정의 및 필요성.

• 정의.

  • Web Server Gateway Interface의 약자로, 파이썬으로 작성된 웹 애플리케이션(예: Django, Flask)이 Apache, Nginx 같은 웹 서버와 통신할 수 있도록 하는 호출 가능한(Callable) 규약을 정의

  • WSGI의 역할은 웹 서버가 보낸 HTTP 요청을 파이썬 애플리케이션이 이해할 수 있는 형태로 변환하여 전달하고, 애플리케이션의 응답을 다시 웹 서버가 클라이언트에게 보낼 수 있는 형태로 변환하는 중개자 역할.

• 주요 목적.

웹 서버와 어플리케이션 사이의 모든 상호작용에 대해 간단하고도 포괄적인 인터페이스를 제공하는 것.

• ex) 웹 서버로부터 HTTP 요청을 받은 경우 어플리케이션으로 전달할 때 어떤 형식(dict, str 혹은 bytes 등)으로 전달할지, 또 통신 중 예외 상황이 발생한 경우 어떻게 처리할지 등에 대한 명세를 담고 있음.

• 덕분에, Django,Flask를 사용하는 어플리케이션 개발자는 WSGI 내부 설계나 배포에 대한 고민 없이 어플리케이션 내부 프레임워크에만 집중 가능해짐.

• 필요성.

  • 호환성 및 이식성 확보:

    • WSGI 표준 덕분에 어떤 파이썬 웹 프레임워크(Django, Flask 등)를 사용하든, WSGI를 지원하는 모든 웹 서버(Gunicorn, uWSGI 등)에서 쉽게 구동 가능.
    • 웹 서버와 웹 애플리케이션이 독립적으로 개발 및 교체될 수 있도록 함.

  • 효율성 개선:

    • 기존의 CGI(Common Gateway Interface) 방식이 요청마다 새로운 프로세스를 생성했던 것과 달리, WSGI 서버는 프로세스와 스레드를 재사용하여 리소스 효율성을 높임.

WSGI의 구성 요소.

WSGI 아키텍처는 크게 3가지 핵심 컴포넌트로 구성.

서버/게이트웨이 (Server/Gateway)

• 역할:

  • 클라이언트(웹 브라우저)로부터 HTTP 요청을 받아 WSGI 애플리케이션으로 전달하고, 애플리케이션의 응답을 받아 다시 클라이언트에게 HTTP 응답으로 반환.

• 예시:

  • Gunicorn, uWSGI, Waitress 등이 대표적인 파이썬 WSGI 서버입니다. (Apache나 Nginx 같은 웹 서버와 연동하여 사용됨).

애플리케이션/프레임워크 (Application/Framework)

• 역할:

  • WSGI 표준을 준수하며 서버로부터 받은 요청을 처리하고, 비즈니스 로직을 수행한 후 응답을 생성하여 서버에 반환.

• 예시:

  • Django, Flask, Pyramid 등 파이썬 웹 프레임워크가 WSGI 인터페이스를 통해 서버와 통신.

미들웨어 (Middleware)

• 역할:

  • 서버와 애플리케이션 사이에 위치하여 요청(environ)이나 응답을 가로채고 수정하는 추가 기능을 제공.
  • 미들웨어는 WSGI 서버의 입장에서는 WSGI 애플리케이션처럼 작동하고, WSGI 애플리케이션의 입장에서는 WSGI 서버처럼 작동하는 특성.

• 예시:

  • 세션 관리, 인증/권한 부여, 로깅, URL 라우팅, 디버깅 페이지 제공 등.

WSGI의 작동 방식(인터페이스 규약)

WSGI는 본질적으로 서버와 애플리케이션 간의 호출 가능한 객체(Callable Object)를 통한 통신 규약.

WSGI 애플리케이션 인터페이스

WSGI 표준을 따르는 파이썬 애플리케이션은 반드시 다음 두 인수를 받는 '호출 가능한 객체'여야 함.

• 1. environ (환경 변수 딕셔너리):

  • 웹 서버로부터 전달된 HTTP 요청 관련 정보(헤더, 경로, 쿼리 스트링 등)를 포함하는 파이썬 딕셔너리.

  • REQUEST_METHOD, PATH_INFO, SERVER_NAME 등의 CGI 환경 변수와 wsgi.input, wsgi.errors 등의 WSGI 관련 변수들을 담고 있음.

• 2. start_response (콜백 함수):

  • 응답의 상태 코드(200 OK, 404 Not Found 등)와 HTTP 응답 헤더를 설정하기 위해 WSGI 서버가 제공하는 콜백 함수.
  • 애플리케이션은 응답 본문을 반환하기 전에 반드시 이 함수를 한 번 호출해야 함.

요청 및 응답 처리 흐름

• 1. 요청 수신 : 웹 서버(예: Nginx)가 클라이언트의 HTTP 요청을 수신.

• 2. WSGI 서버 호출 : 웹 서버는 요청을 WSGI 서버(예: Gunicorn)로 프록시(전달).

• 3. 애플리케이션 호출 : WSGI 서버는 HTTP 요청 정보를 파싱하여 environ 딕셔너리를 만들고,

  자신의 콜백 함수인 **start_response**와 함께
  WSGI 애플리케이션의 호출 가능한 객체를 실행.

      # WSGI 애플리케이션의 기본 형태
      def application(environ, start_response):
         # 1. 응답 상태 및 헤더 설정
         status = '200 OK'
         headers = [('Content-type', 'text/plain')]
         start_response(status, headers)

        # 2. 응답 본문 반환 (반드시 이터러블한 바이트열(byte string)이어야 함)
         return [b"Hello, WSGI World!"]

• 4. 응답 생성 : 애플리케이션은 environ을 기반으로 로직을 처리하고,

  **start_response를 호출하여 상태/헤더를 설정한 후**,
   응답 본문(바이트열의 이터러블 객체)을 **반환**.

• 5. 응답 전송. : WSGI 서버는 **start_response로 받은 상태/헤더와 애플리케이션이 반환한

  응답 본문을 조합**하여 완전한 HTTP 응답을 만든 후,
   **웹 서버를 통해 최종적으로 클라이언트에게 전송.**

흐름 정리.

Application 방면.

• 어플리케이션 객체는 두 변수를 입력받는 callable 객체 형태여야함.
  • 즉, 파이썬에서 함수 형태거나 혹은 call 메소드가 정의된 클래스 객체를 이용하여 어플리케이션 작성이 가능.
  • 서버 및 게이트웨이로부터 요청이 반복되어 들어올 수 있으므로 반복 호출이 가능해야 함.

# main.py
def wsgi_app(environ, start_response):
    status = "200 OK"
    headers = [("Content-type", "text/plain")]
    start_response(status, headers)
    return [b"It Works!"]

Server 방면

• 웹서버는 HTTP 클라이언트로부터 요청이 들어올 때마다 어플리케이션 측에서 제공하는 callable 객체를 한 번씩 호출.

상세 스펙.

어플리케이션은 반드시 callable 객체이어야 하며 다음 두 변수 environ, start_response를 입력받음.

• 다만, 어플리케이션 호출 시 위치 인자(positional arguments)로 입력받기 때문에 변수명을 동일하게 가질 필요는 없음.

• environ.

  • environ은 CGI 정보를 포함한 dict 객체.
  • 반드시 다른 파이썬 mapping 객체를 상속받은 객체가 아닌 파이썬 builtin dict 객체 형태.
  • 어플리케이션에서는 해당 dictionary 객체를 원하는 대로 가공 가능.
  • 아래의 정보는 필수.

• start_response

  • start_response는 두 인자 status, response_headers와 선택적으로 exc_info를 입력받는 callable 객체.

    • 입력값으로 받는 status는 “200 OK”, “404 Not Found”와 같이 상태를 나타내는 스트링.
    • response_headers는 HTTP 응답 헤더의 (header_name, header_value) 튜플 쌍을 담은 list 객체
      • 헤더는 파이썬 list 타입이어야 하고, 필요에 따라 서버 측에서 해당 리스트 내용을 가공가능.
      • 헤더의 header_name 값에는 구두점이나 세미콜론이 포함되어서는 안 되며 모든 스트링에 \n, \r과 같은 개행 문자가 들어가서는 안 됨. (이는 추후 설명할 서버의 검증 단계에서 복잡성을 줄이기 위해서)

  • 호출 시 HTTP 응답 처리를 시작하며, 리턴값으로 write(body_data) callable 객체를 반환.

WSGI 순서도.

3. guicorn이란?

WSGI의 Guicorn은 파이썬 웹 환경을 배포할 때 가장 널리 사용되는 핵심 도구 중 하나.

• Gunicorm 은 Green Unicorn의 약자로, 파이썬 웹 애플리케이션을 구동하기 위한 WSGI HTTP 서버의 일종.

Gunicorn의 개요.

• 정의 : Python WSGI HTTP 서버 (Python Web Server Gateway Interface HTTP Server)

• 역할 : 웹 서버(예: Nginx)와 파이썬 웹 애플리케이션(예: Django, Flask) 사이에서 WSGI 표준을 준수하며 요청을 처리하고 응답을 관리하는 게이트웨이 역할.

• 특징 : 구현이 심플하고, 서버 리소스 사용이 적으며, 비교적 빠른 속도로 동작하여 프로덕션(실제 서비스) 환경에 적합.

• 기반 : Ruby의 Unicorn 프로젝트에서 영감을 받아 이식된 Pre-fork(프리-포크) 워커 모델을 사용

Gunicorn은 왜 쓰이는걸까.

(참고 : Django의 runserver 역시 똑같은 역할을 수행하지만 보안적으로나 성능적으로 검증이 되지 않았기 때문에 production 환경에서는 사용할 수 없다.) - 개발용으로는 유용

• 하지만 WSGI는 멀티 쓰레드를 만들 수 있기 때문에 Request가 많아지더라도 효율적으로 처리할 수 있음.

• 즉, production(제품) 환경에 적합

Gunicorn의 핵심 역할(WSGI 서버로서)

Gunicorn은 WSGI 아키텍처에서 WSGI 서버/게이트웨이 역할을 수행.

1. 웹 서버와의 통신 중개:

• 외부 웹 서버(Nginx, Apache)로부터 HTTP 요청을 받음.
• WSGI 규약에 맞게 이 요청 데이터를 environ 딕셔너리 형태로 파이썬 애플리케이션에 전달.
• 애플리케이션이 생성한 응답 본문과 start_response 콜백 함수로 받은 헤더를 다시 HTTP 응답 형태로 변환하여 웹 서버로 돌려보냄.

2. 프로덕션 환경 구동:

• 앞서 말했듯이, Django나 Flask의 내장 서버(runserver 등)는 개발 용도로만 적합하고 동시 요청 처리 및 보안에 취약.

• Gunicorn은 멀티 프로세스/멀티 스레드 환경에서 동작하며 높은 동시성과 안정성을 제공하여 실제 서비스 환경(Production)에서 애플리케이션을 구동하는 데 사용.

Gunicorn의 아키텍처 및 작동 방식.

Gunicorn은 'Master-Worker(마스터-워커)' 구조로 동작하여, 효율적으로 요청을 처리.

1. 마스터 프로세스(Master Process)

• Gunicorn이 실행될 때 가장 먼저 생성되는 메인 프로세스.

• '워커 프로세스'를 관리하고 모니터링하는 역할을 수행.

• 워커 프로세스가 비정상적으로 종료되면, 자동으로 새로운 워커를 생성하여 서버의 안정성을 유지.

2. 워커 프로세스(Worker Process)

• 마스터 프로세스가 복제(fork)하여 생성하는 실제 요청 처리 담당 프로세스

• 각 워커는 요청을 독립적으로 처리하며, 워커 수만큼 동시 요청을 처리 가능

• Gunicorn은 기본적으로 '동기(Sync)'워커를 사용하지만, '비동기(Async)워커'도 지원.

  • Sync(동기)
    • 특징 : 한 번에 하나의 요청을 처리하며, 요청이 블로킹되면 다른 요청을 처리 가능
      • 가장 간단하고 안정적.
    • 적합한 상황 : Cpu 연산이 많은 작업

• Async(비동기)
  • 특징 : I/O작업(DB 접근, 외부 API 호출 등)시 작업을 양보하여

     해당 시간에 다른 요청을 처리(비동기적 동시성)

  • 적합한 상황 : I/O 작업이 많은 작업

3. 워커 개수 설정.

Gunicorn의 성능을 좌우하는 중요한 설정. 일반적으로 권장되는 워커 수는 다음과 같음.

• CPU 자원을 최대한 활용하면서도 여분의 워커를 두어 안정성을 확보.

WSGI 서버로서의 Gunicorn 사용 예시.

Gunicorn은 명령 한 줄로 파이썬 애플리케이션을 WSGI 서버로 구동 가능.

4. ASGI란?

최근 파이썬 웹 개발 환경에서는 WSGI의 후속으로 ASGI(Asynchronous Server Gateway Interface)가 등장.

• WSGI의 특징:
  • 동기(Synchronous) 방식을 기반.
  • 하나의 요청이 완전히 처리될 때까지 다른 요청을 차단(Blocking)하는 구조.
  • HTTP 1.0/1.1 같은 '동기식 요청 처리'에 적합.

ASGI (Asynchronous Server Gateway Interface)는 파이썬 웹 서버와 비동기(Asynchronous)를 지원하는 파이썬 웹 애플리케이션 및 프레임워크 간의 통신을 위한 표준 인터페이스이자 WSGI의 정신적 후계자.

WSGI의 한계 & ASGI의 등장 배경

WSGI는 웹소켓(WebSocket)이나 롱 폴링(Long Polling)과 같이 지속적 연결이나 비동기 통신이 필요한 현대적인 웹 환경을 효율적으로 처리하기 어렵기에 이를 해결하기 위해 등장.

• WSGI가 동기적(Synchronous) 요청 처리에만 초점을 맞췄던 한계를 극복하고,
• 비동기 통신(Async)*과 지속적인 연결을 지원하기 위해 설계.

ASGI의 특징

• 비동기(Asynchronous) 방식을 지원

  • 하나의 프로세스/스레드 내에서 여러 요청을 동시에 처리(Concurrency)가능.

• 웹소켓, HTTP/2 등 비동기 및 동시성이 필요한 서비스에 적합

• Uvicorn, Daphne, Hypercorn 등이 대표적인 ASGI 서버이며, FastAPI와 같은 최신 프레임워크가 이를 기반.

ASGI의 핵심 역할 및 필요성.

ASGI의 핵심은 파이썬의 async/await 기능을 웹 서버와 애플리케이션 간의 통신에 통합하여 높은 동시성과 새로운 웹 프로토콜을 지원하는 것.

WSGI의 한계 극복.

• 기존의 WSGI는 요청-응답(Request-Response)의 단일 동기 호출 방식에 고정되어 있어서 다음과 같은 현대 웹 기술을 효율적으로 지원하기 어려웠음.

  • 웹소켓(WebSocket) : 클라이언트와 서버 간에 지속적인 양방향 통신 채널을 유지하는 프로토콜.

    - (WSGI는 단발성 HTTP 요청에만 적합)

  • HTTP/2 : 하나의 연결로 여러 요청을 병렬 처리하는 동시성(Concurrency) 기능.

  • 롱 폴링/서버 센트 이벤트(SSE) : 서버가 클라이언트에게 실시간 데이터를 보내는 기술.

ASGI의 해결책.

• ASGI는 이러한 문제들을 해결하기 위해 비동기 이벤트 기반의 인터페이스를 제공.
  • 하나의 프로세스나 스레드가 여러 네트워크 연결(I/O 작업)을 차단(Blocking)하지 않고 효율적으로 처리가능.

ASGI의 구성 요소 및 인터페이스.

WSGI와 마찬가지로 ASGI도 서버와 애플리케이션 사이의 통신 규약을 정의하지만, 비동기 처리를 위해 인수의 구성이 다름.

ASGI 애플리케이션 인터페이스.

ASGI 애플리케이션은 "호출 가능한 비동기 객체(Asynchronous Callable) 형태여야 하며, 3 가지 인수를 받음.

1. scope (연결 범위):

• 현재 연결(Connection)에 대한 상세 정보가 담긴 딕셔너리.
• 연결 유형(http, websocket, lifespan 등), Http경로, 쿼리 문자열 등을 포함.
• 이 scape는 연결 수명 동안 불변.

2. receive (수신 함수):

• ASGI 서버로부터 비동기 이벤트 메시지를 '수신'하는 await 가능한 함수.
  • ex) HTTP 요청 본문 청크, 웹소켓 메시지 등등...

3. send (전송 함수):

• ASGI 애플리케이션이 ASGI 서버로 비동기 이벤트 메시지를 '전송'하는 await 가능한 함수.
  • ex) HTTP 응답 상태/헤더, 웹소켓 메시지 등등...

ASGI 서버 및 프레임워크.

ASGI 서버

• ASGI 표준에 따라서, 클라이언트의 요청을 받아 애플리케이션을 호출하고 결과를 전송하는 서버.
  • ex) Uvicorn, Daphne, Hypercorn

ASGI 프레임워크

• ASGI 인터페이스를 기반으로 구축되어, 비동기 기능을 기본으로 제공하는 프레임워크.
  • (예: FastAPI, Starlette, Django Channels (Django 3.0+부터는 코어 Django도 ASGI 지원))

WSGI와 ASGI의 주요 차이점 비교.

• ASGI는 WSGI가 사용되던 역할을 대체하거나 확장하는 관계.!

• ASGI는 I/O 바운드 작업(네트워크 통신, DB접근 등)이 많아 동시성이 중요한 애플리케이션,
  • 특히, {실시간 채팅, 게임 서버 API, 스트리밍 서비스} 등에서 탁월한 성능을 발휘.

5. uvicorn이란?

Uvicorn은 파이썬으로 작성된 '초고속 ASGI(Asynchronous Server Gateway Interface) 서버 구현체.

• Gunicorn이 WSGI 표준을 구현하여 동기 웹 애플리케이션(Django, Flask 등)을 구동하는 역할을 한다면,
• Uvicorn은 ASGI 표준을 구현하여 비동기 웹 애플리케이션 (FastAPI, Starlette, 비동기 모드로 실행되는 Django 등)을 구동하는 역할을 수행.

Uvicorn의 역할 및 특징.

Uvicorn은 현대적인 비동기 파이썬 웹 서비스 환경에서 필수적인 역할을 수행하며, 특히 그 성능과 간결함으로 유명.

ASGI 서버로서의 역할.

인터페이스 구현

• 클라이언트의 HTTP 요청을 받아 ASGI 표준에 맞는 {scope, receive, send 구조}로 변환하여 애플리케이션에 전달 후,

• 반대로, 애플리케이션의 응답을 HTTP 응답 형태로 변환하여 클라이언트에게 전달.

비동기 구동.

• async/await로 작성된 파이썬 애플리케이션을 구동하여 I/O 바운드 작업에서 높은 동시성(Concurrency)을 확보.

고성능의 비결.

Uvicorn의 놀라운 속도는 다음 두 가지 핵심 라이브러리를 활용하기 때문.

uvloop

• 파이썬의 기본 이벤트 루프인 asyncio를 대체하는 C 기반의 이벤트 루프 구현체.
• OS와의 효율적인 상호작용을 통해 매우 빠른 비동기 처리 속도를 제공.

httptools

• HTTP 프로토콜 파싱 및 직렬화를 담당하는 라이브러리로, C로 구현되어 빠른 속도를 보장.

Uvicorn과 Gunicorn의 일반적인 결합 구조.

실제 프로덕션 환경에서는 Uvicorn을 단독으로 사용하기보다는 Gunicorn과 결합하여 사용하는 것이 일반적.

• 구조: 클라이언트 ➡️ (Nginx) ➡️ Gunicorn (마스터) ➡️ Uvicorn (워커) ➡️ FastAPI/Starlette

▽ [D.S : 데이터 분석 및 데이터 사이언스] RFM 분석이란.

목  차

1. RFM의 개념

2. RFM 분석 프로세스

3. RFM 분석 활용.

4. RFM 적용 시 고려할 점.

5. RFM 분석의 장단점.

6. 추천 학습 루트.

1. RFM의 개념 (Recency, Frequency, Monetary Value) 💡

RFM은 고객 세분화의 척도인 "CLV : 고객 생애 가치"를 예측하는 가장 효율적인 휴리스틱(Heuristic) 방법론입니다. 3가지 지표(R,F,M)는 상호 보완적으로 고객의 행동을 정의합니다.

RFM 분석에서는 '회사 매출에 가장 중요한 요인은 최근성(Recency), 행동 빈도(Frequency), 구매금액(Monetary)이다' 라는 가정을 두고 있으며, 이 3가지 관점에서 고객의 가치를 분석.

즉, 사용자별로 이 3가지 관점에서 (얼마나 최근에, 얼마나 자주, 얼마나 많은 금액을 지출했는지) 에서 1) 사용자들의 분포를 확인 하거나 2) 사용자 그룹이나 등급을 나누어 분류(Segmentation) 하는 분석 기법

• 구매 가능성이 높은 고객을 선정할 때 용이한 분석 방법이며, 사용자들의 평소 구매 패턴을 기준으로 분류를 진행하기 때문에, 각 사용자 그룹의 특성에 따라 차별화된 마케팅 전략을 수립 가능.

정리 : RFM은 고객의 과거 구매 행동을 기반으로 고객 가치를 평가하고 세분화하는 분석 기법.

CRM/그로스 마케팅

Recency (최근성)

• 고객의 활성도 척도. 최근 구매 고객일수록 마케팅 메시지에 대한 반응률(Response Rate)과 재구매 가능성이 높음.

• 이탈 방지 전략의 핵심 지표

Frequency (빈도)

• 고객의 충성도 척도. 반복 구매는 제품/서비스에 대한 만족도를 의미하며, 장기적인 고객 관계의 기반

Monetary Value (구매 금액)

• 고객의 기여도 척도. 기업 수익에 직접적인 영향을 미치며, 가장 가치 있는 고객을 식별하는 데 사용.

데이터 엔지니어링

Recency (최근성)

• 기준일(오늘)로부터 마지막 구매일까지의 경과 일수를 계산하는 지표.

• 주로 SQL의 DATEDIFF()나 Python의 datetime 연산을 사용.

• 값이 작을수록 좋습니다.

Frequency (빈도)

• 특정 기간 내의 순 주문(결제 완료) 건수를 COUNT() 집계 함수로 계산.

• 기간 설정이 데이터 모델링의 중요한 요소.

Monetary Value (구매 금액)

• 특정 기간 내의 실 결제 금액(환불/취소 제외)을 SUM() 집계 함수로 계산.

• 데이터 정제 과정에서 할인, 쿠폰 적용 여부를 명확히 해야함.

ML 엔지니어링

Recency (최근성)

• 고객의 상태 변화(Transition)를 예측하는 데 가장 중요한 Feature.

• R 값이 높아지면(구매가 오래될수록) 이탈 확률이 급격히 증가.

Frequency (빈도)

• 이탈 예측(Churn Prediction)이나 구매 확률 예측(Propensity to Buy) 모델에서 고객의 참여 수준을 나타내는 핵심 Feature.

Monetary Value (구매 금액)

• 고객 생애 가치(CLV) 예측 모델에서 고객의 과거 재정적 가치를 나타내는 직접적인 입력 Feature.

2. RFM 분석 프로세스.

1. 데이터 준비

CRM/그로스 마케팅 측면.

• 분석 목표 설정 (예: 이탈률 10% 감소).
• 기간 정의 (예: 최근 1년 구매 기록).

데이터 엔지니어링 측면.

• 거래 데이터 ETL/ELT 파이프라인 확보.
• 데이터 웨어하우스(DW)에서 고객ID, 주문일, 결제액 등 원천 데이터 추출.
• 데이터 정제(Cleansing) 로직 구현 (환불, 테스트 거래 제외).

ML 엔지니어링 측면.

• 모델 학습에 사용할 피처(Feature)로 R,F,M 값을 계산하는 스크립트 작성.

2. 지표 계산

CRM/그로스 마케팅 측면.

• R,F,M 세 지표를 계산하고, R은 낮을수록, F, M은 높을수록 좋다는 점을 이해.

데이터 엔지니어링 측면.

• SQL의 GROUP BY 및 Aggregation(집계) 함수를 사용해 효율적으로 R,F,M 값을 계산하고 DW에 저장. (예: dbt를 활용한 모델링)

ML 엔지니어링 측면.

• 지표 값의 분포 분석(Exploratory Data Analysis, EDA)을 수행하여 이상치(Outlier)를 확인하고 필요 시 변환(Transformation) 방법 검토.

3. 점수화 & 세분화

CRM/그로스 마케팅 측면.

• 5x5x5 매트릭스 기반의 고객 세그먼트 정의 및 이름 부여 (예: Champions, Loyal, Hibernating).

데이터 엔지니어링 측면.

• 지표의 분포를 기반으로 분위수(Quantile) 경계값을 결정하고, 각 고객에게 1~5점의 RFM 점수를 부여하는 로직 구현.

ML 엔지니어링 측면.

• R,F,M 값에 대한 K-means 클러스터링을 적용하여 데이터 기반의 최적 세그먼트를 자동으로 도출.
• 최적의 K 결정 로직 구현.

4. 전략 실행.

CRM/그로스 마케팅 측면.

• 정의된 세그먼트별로 개인화된 캠페인 실행 (예: 111 이탈 고객에게 50% 할인 쿠폰).
• 캠페인의 A/B 테스트 기획.

데이터 엔지니어링 측면.

• 최종 세그먼트 정보를 CRM/CDP 시스템으로 동기화하는 안정적인 데이터 전송(Data Load) 파이프라인 구축.

ML 엔지니어링 측면.

• 세그먼트 정보를 활용하여 타겟 그룹별 예측 모델을 실행하고 결과를 마케팅 팀에 제공.

3. RFM 분석 활용.

CRM/그로스 마케팅 측면

타겟팅 효율화.

• 마케팅 자원(예산, 인력)을 R,F,M 점수가 높은 고객군에 집중하여 ROI(투자 대비 효과)를 극대화.

이탈 고객 재활성화(Retention)

• 'R 점수' 가 급격히 낮아지는 고객(Hibernation/At Risk)을 실시간으로 감지하고,

• 이들에게 {Push 알림, 이메일, 광고 리타겟팅} 등의 채널을 통해 맞춤형 오퍼를 제공하여 이탈을 방지.

업셀링/크로스셀링(Revenue)

• F,M이 높은 VIP 고객에게는 고가 상품(Up-selling)**이나 관련 상품 카테고리(Cross-selling)를 추천하여 고객당 평균 수익(ARPU)을 높임.

데이터 엔지니어링 측면 :

데이터 파이프라인 구축 :

• Apache Airflow를 사용하여 R,F,M 계산을 매일(Daily) 자동으로 실행하고, 최신 RFM 점수를 DW의 고객 마스터 테이블에 업데이트하는 자동화된 ETL 워크플로우를 구축.

데이터 품질 관리 :

• R,F,M 지표의 값이 정상 범위(Valid Range)를 벗어나는지 주기적으로 모니터링하여, 원천 데이터의 이상(Anomaly) 여부를 감지하고 데이터 오류를 방지

ML 엔지니어링 측면.

Feature Engineering:

• R,F,M을 기본 피처로 사용하고, 이를 Log 변환이나 정규화(Scaling)하여 ML 모델의 예측 성능을 높임.

예측 모델링:

• R 값의 변화 속도나 F,M 점수의 과거 추이를 Feature로 추가하여 이탈 확률, 다음 구매 시점 등을 예측하는 시계열(Time-series) 분석이나 확률론적 모델을 개발.

모델 서빙 (Serving):

• 실시간으로 유입되는 신규 고객에 대해 RFM 점수를 계산하고, 이 점수를 기반으로 자동화된 세그먼트 예측 결과를 반환하는 API를 구축하여 마케팅 시스템과 연동.

4. RFM 적용 시 고려할 점.

CRM/그로스 마케팅

비즈니스 주기의 반영

• 구매 주기가 긴 산업(가구, 자동차 등)은 R의 기간을 길게 설정해야 하며, R의 점수 기준을 보수적으로 잡아야 함.

지표별 가중치.

• 단순히 R/시간, F/시간, M 의 곱으로 평가하는 대신, 비즈니스 목표에 따라 특정 지표에 더 큰 가중치를 부여하여 핵심 고객을 정의해야 함. (예: 초기 성장이 목표일 때 F 가중치 상향)

데이터 엔지니어링

기준 기간 설정.

• F와 M을 계산할 때 기준 기간(Window)을 몇 개월 또는 몇 년으로 설정할지 신중하게 결정해야 함.
  • 이 기간이 다르면 고객의 F,M 점수도 달라짐.

데이터 정의의 통일.

• '구매'의 정의를 순매출액으로 할지, 총매출액으로 할지, 세금 및 배송비 포함/제외 여부를 데이터 팀과 마케팅 팀이 명확히 합의해야함.

ML 엔지니어링

변수 간 상관관계.

• F와 M은 강한 양의 상관관계를 가질 가능성이 높음.

  • 다중공선성 문제가 발생 가능.

• 주성분 분석(PCA) 등을 통해 차원을 축소하거나 변수를 결합하는 방안을 고려해야 함.

비(非)구매 활동 반영.

• 콘텐츠 시청 시간, 앱 접속 빈도 등 구매가 아닌 참여 활동(Engagement) 지표를 R ′ F ′ M 형태로 확장하여 잠재 고객의 가치를 더 정확하게 평가해야함.

5. RFM 분석의 장단점.

장점.

CRM/그로스 마케팅

• 높은 실용성:
  • 분석 결과가 곧바로 실행 가능한 마케팅 전략으로 연결.
  • 단기적인 성과 예측에 유리.

데이터 엔지니어링

• 구현 용이성:
  • 기본적인 거래 데이터만 있으면 계산할 수 있어 구축 비용이 낮고 데이터 소스가 명확.

ML 엔지니어링.

• 강력한 Feature:
  • 개발하는 예측 모델(이탈, 구매 확률)에서 가장 중요한 설명 변수 중 하나로 높은 예측력을 제공.

단점.

CRM/그로스 마케팅

• 정적 분석의 한계:
  • 특정 시점의 과거 데이터만 반영하므로,
  • 잠재적인 미래 가치(LTV)를 온전히 예측하기 어려움.

데이터 엔지니어링

• 데이터 민감성:
  • 이상치(Outlier)에 민감하며, 몇몇 초대량 구매 고객(Whales)이 전체 분위수 기준을 왜곡 가능.

ML 엔지니어링.

• 설명력 부족:
  • 왜 구매했는지, 어떤 상품을 좋아하는지 등 고객의 니즈나 선호도는 설명하지 못함. (추가 데이터 필요).

6. 추천 학습 루트.

신입 마케터/데이터 엔지니어로서 RFM 분석을 마스터하기 위한 체계적인 학습 로드맵입니다. CRM/그로스 마케팅과 데이터/ML 엔지니어링 관점을 모두 담아 실무에 바로 적용할 수 있도록 구성했습니다.

6. 🚀 추천 학습 방식.

▽[데이터를 위한 Python : From Scratch to Master.] 연휴동안 인프런 강의 녹이기 : "실리콘밸리 엔지니어가 가르치는 파이썬 기초부터 고급까지"._03.

목  차

1. List data Structure(리스트 자료구조)에 대해 알아보기.

2. List 사용시 많이 접하는 Erros와 Nested list(에러와 중첩되는 리스트)에 대해서 알아보기.

1. List data Structure(리스트 자료구조)에 대해 알아보기.

# 13. List data Structure(리스트 자료구조)에 대해 알아보기.

# 언제 쓰이는가??
# 1. 데이터를 순차적으로 저장하고 관리하는 데 사용된다.
# 2. 데이터를 인덱스를 사용하여 접근할 수 있다.

countries = ["Korea", "USA", "Japan", "Germany", "Canada"]

print(countries)

# 인덱스를 통해 리스트의 값에 접근하고, 수정할 수 있다.

countries[4] = "Australia"

print(countries)

# 변수에 값을 담아서, 리스트에 변수로 추가할 수 있다.

element = "mars"

planets  = ["Mercury", "Venus","Earth", element]

print(planets)

# list의 메소드, append()는 리스트의 마지막에 값을 추가한다.

planets.append("Jupiter")

print(planets)

# +=[list]는 리스트의 마지막에 리스트를 추가한다.

planets += ["Saturn", "Uranus", "Neptune"]
print(planets)

# list의 insert()는 지정한 인덱스에 앞에 값을 추가한다.
planets.insert(0,"Sun")
print(planets)
planets.insert(0,"Bigbang")
print(planets)

# 파이썬에서 인덱스 -1은 리스트의 마지막 요소를 의미한다.

planets.append("Pluto")
print(planets)  # 전체 리스트 출력
print(planets[-1]) # 마지막 요소 출력

# list의 pop()은 지정한 인덱스의 요소를 제거하고 반환한다. 만약 인덱스를 지정하지 않으면, 마지막 요소를 제거하고 반환한다.
planets.pop()
print(planets)

#pop의 인덱스를 지정해주면, 해당 부분의 요소를 제거하고 반환한다.

planets.pop(0)
print(planets)

2. List 사용시 많이 접하는 Erros와 Nested list(에러와 중첩되는 리스트)에 대해서 알아보기.

# 리스트의 인덱스를 초과하여 접근하면, IndexError가 발생한다.
corps = ['alpha','beta','gamma','delta','epsilon']

print(corps[5])

# Nested list(중첩된 리스트) : 리스트 안에 리스트가 있는 것.

corps = ['alpha','beta','gamma','delta','epsilon']
print(corps)

corps = [['alpha','beta','gamma'],['delta','epsilon','zeta']]
print(corps)

# Nested list의 인덱스를 접근하면, 리스트 안의 리스트의 요소를 출력한다.
print(corps[0])
#중첩된 리스트안에 담긴 인덱스를 접근하면, 리스트 안의 리스트의 요소를 출력한다.
print(corps[0][0])

공부하면서 듣고 있는 인프런의 '실리콘밸리 엔지니어가 가르치는 파이썬 기초부터 고급까지' 강의 링크입니다.

https://inf.run/NfKUW

이 링크를 통해 구매하시면 제가 수익을 받을 수 있답니다. 🤗

▽ [D.S : 데이터 분석 및 데이터 사이언스] CRM에 관련 데이터 지표들.

목   차

1. 고객 생애 가치 (CLV: Customer Lifetime Value)

2. 고객 유지율 (CRR: Customer Retention Rate) & 고객 이탈률 (CCR: Customer Churn Rate)

3. 재구매율 (Repurchase Rate) / 재구매 주기 (Repurchase Cycle)

4. 객단가 (AOV: Average Order Value) / ARPPU (Average Revenue Per Paying User)

5. 캠페인 반응률 (Open Rate, Click Rate, Conversion Rate 등)

6. 첫 구매 전환율 (First Purchase Conversion Rate)

1. 고객 생애 가치 (CLV: Customer Lifetime Value)

개념.

CLV는 고객 한 명이 우리 기업과 거래를 시작한 시점부터 관계를 종료할 때까지 총 창출할 것으로 예상되는 매출 또는 이익의 현재 가치.

• 단순한 단기 매출이 아닌, 고객과의 장기적인 관계 가치를 평가하는 가장 중요한 지표

• CLV가 CAC(고객 획득 비용)보다 높아야 사업의 지속 가능성이 확보.

계산 공식

CLV=평균 구매 가치×평균 구매 빈도×평균 고객 유지 기간

• 더 정교하게는 코호트별(Cohort) 월평균 수익을 해당 코호트의 이탈률(Churn Rate)로 나누는 방식을 사용하거나, 머신러닝 기반의 LTV 예측 모델을 사용하기도 함.

분석 포인트.

• 그로스/CRM 마케터 관점.

  • ROI 판단

    • CLV를 기준으로 마케팅 예산과 채널별 효율성을 평가하여, CLV가 높은 고객이 유입되는 채널에 예산을 집중.

  • VIP 전략

    • CLV가 높은 고객을 대상으로 차별화된 프리미엄 리텐션 프로그램이나 맞춤형 혜택을 제공하여 가치를 극대화.

• DA/DS 분석가 관점.

  • 세분화 분석

    • 유입 경로, 첫 구매 제품, 인구 통계학적 특징 등 세그먼트별 CLV를 측정하여 '고가치 고객'의 특징을 정의하고 이를 타겟팅 전략에 활용.

  • 예측 모델링.

    • 통계적 모델이나 머신러닝을 활용하여 신규 고객의 초기 행동 데이터를 기반으로 3개월, 6개월 뒤의 CLV를 예측하는 모델을 개발하여 마케팅의 선제적인 의사결정을 지원

2. 고객 유지율 (CRR: Customer Retention Rate) & 고객 이탈률 (CCR: Customer Churn Rate)

개념

CRR(고객 유지율)은 일정 기간 동안 서비스를 계속 이용하기로 결정한 고객의 비율이며, CCR(고객 이탈률)은 그 반대로 해당 기간 동안 서비스를 떠난 고객의 비율

• 이 두 지표는 고객 충성도와 관계 관리의 성공 여부를 직접적으로 보여줌.

• 일반적으로 신규 고객 획득보다 기존 고객 유지 비용이 훨씬 저렴하기 때문에 CRR 관리가 매우 중요.

계산 공식.

두 지표는 100%가 되지 않을 수 있으며, CCR을 개선하면 CRR이 높아짐.

분석 포인트.

• 그로스/CRM 마케터 관점.

  • 리텐션 캠페인 효과 측정:

    • 특정 리텐션 캠페인이나 온보딩 프로그램 시행 전후의 CRR/CCR 변화를 측정하여 전략의 유효성을 평가.

  • 선제적 대응:

    • 높은 CCR이 관찰되면, 그 원인을 파악하여 고객 만족도 개선이나 맞춤형 재활성화(Re-activation) 캠페인을 즉시 실행.

• DA/DS 분석가 관점.

  • 이탈 원인 분석:

    • 이탈 고객들이 이탈 직전에 보인 행동 패턴 (예: 앱 접속 빈도 급감, 특정 기능 사용 중단)을 분석하여 이탈을 예측할 수 있는 핵심 지표(Leading Indicator)를 도출

  • 이탈 예측 모델링:

    • 이탈 위험이 높은 고객을 사전에 식별하여 마케터에게 타겟 리스트를 제공하는
    • 이탈 예측 모델(Churn Prediction Model)*을 구축하고 정확도를 개선

3. 재구매율 (Repurchase Rate) / 재구매 주기 (Repurchase Cycle)

개념

재구매율은 전체 구매 고객 중 한 번 이상 재차 구매한 고객의 비율을 나타내며, 고객의 제품/서비스에 대한 충성도와 만족도를 반영.

재구매 주기는 고객이 첫 구매 후 다음 구매까지 걸리는 평균 시간(간격)을 의미하며, 이는 상품의 특성(소모품, 내구재 등)을 반영한 마케팅 타이밍을 결정하는 데 중요.

계산 공식.

분석 포인트.

• 그로스/CRM 마케터 관점.

  • 캠페인 타이밍:

    • 재구매 주기를 기준으로 '다음 구매가 예상되는 시점'에 맞춰 리마인드 메시지나 맞춤형 쿠폰을 발송하는 트리거(Trigger) 마케팅을 설계.

  • 충성 고객 육성:

    • 재구매율이 높은 고객을 충성 고객으로 분류하고, 이들에게만 독점적인 혜택을 제공하여 락인(Lock-in) 효과를 높임.

• DA/DS 분석가 관점.

  • 최적 구매 간격 분석:

    • 상품 카테고리나 고객 세그먼트별로 재구매 주기가 상이하게 나타나는지 분석하고, 이를 기반으로 통계적으로 유의미한 최적의 리마인드 시점을 도출.

  • 생애 첫 재구매 분석:

    • 첫 구매 고객이 두 번째 구매로 이어지는 행동 패턴을 분석하여,
    • 재구매를 유도하는 핵심 행동을 파악하고 마케팅 퍼널을 개선*.

4. 객단가 (AOV: Average Order Value) / ARPPU (Average Revenue Per Paying User)

개념

AOV는 고객이 1회 주문 시 평균적으로 지출하는 금액이며, ARPPU는 구매 고객 1명당 평균 수익을 의미.

• 이 지표들은 고객의 구매력을 측정하고, 교차/상향 판매(Cross/Up-selling) 전략이 매출 증대에 얼마나 기여했는지 평가하는 데 사용.

계산 공식.

분석 포인트.

• 그로스/CRM 마케터 관점.

  • 매출 증대 전략:

    • AOV를 높이기 위해 무료 배송 최소 기준 금액 상향 조정, 세트 상품/번들 판매 캠페인을 기획하고 그 효과를 AOV 변화로 측정.

  • 교차/상향 판매 효과:

    • '함께 구매하는 제품'이나 '프리미엄 제품' 추천 캠페인을 진행하고, AOV와 ARPPU의 상승 여부를 통해 캠페인 성공을 평가.

• DA/DS 분석가 관점.

  • 연관 상품 분석:

    • 장바구니 데이터를 분석하여 어떤 상품 조합이 AOV를 높이는지 파악하고, 이를 기반으로 추천 알고리즘을 정교화.

  • 가격 민감도 분석:

    • 할인 쿠폰이나 프로모션이 AOV와 ARPPU에 미치는 영향을 통계적으로 분석하여, 매출 증대와 수익성 사이의 최적점을 찾아냄.

5. 캠페인 반응률 (Open Rate, Click Rate, Conversion Rate 등)

개념

CRM 마케팅에서 발송하는 이메일, 푸시 알림, 문자 메시지 등의 개별 메시지에 대한 고객의 반응 수준을 측정하는 지표.

• 오픈율은 고객의 관심도, 클릭률은 행동 유도 능력, 전환율은 최종적인 비즈니스 목표 달성도를 나타냄.

계산 공식.

분석 포인트.

• 그로스/CRM 마케터 관점.

  • 메시지 최적화:

    • A/B 테스트를 통해 제목, CTA(Call to Action) 버튼 디자인, 콘텐츠 등의 요소를 끊임없이 실험하여 반응률을 개선.

  • 개인화 수준 평가:

    • 개인화된 메시지 (예: 고객 이름 언급, 맞춤 추천 상품 포함)를 사용했을 때와 일반 메시지를 사용했을 때의 반응률 차이를 분석하여 개인화 전략의 ROI를 측정.

• DA/DS 분석가 관점.

  • 최적 발송 시간 분석:

    • 시간대별, 요일별로 고객의 반응률을 분석하여 타겟 그룹별 최적의 발송 시간을 통계적으로 도출하고 마케팅 효율을 극대화

  • 채널 효율 비교:

    • 동일한 메시지를 이메일, 푸시, SMS 등 다양한 채널로 발송했을 때의 반응률과 최종 전환 기여도를 비교하여 채널별 예산 배분의 근거를 마련

6. 첫 구매 전환율 (First Purchase Conversion Rate)

개념

신규 유입된 잠재 고객(가입자, 웹사이트 방문자 등) 중 실제로 첫 번째 구매까지 이어진 고객의 비율.

• 이는 신규 고객 확보 전략의 성공 여부와 고객이 우리 서비스를 탐색하고 구매에 이르기까지의 온보딩(Onboarding) 프로세스 효율성을 평가하는 핵심 지표.

계산 공식.

분석 포인트.

• 그로스/CRM 마케터 관점.

  • 퍼널 분석:

    • 신규 유입부터 구매까지의 고객 여정(Funnel)에서 이탈이 가장 많이 발생하는 단계를 파악하고, 해당 단계에 대한 타겟팅 온보딩 메시지나 인센티브(쿠폰 등)를 제공.

  • 채널 효율성 비교:

    • 어떤 마케팅 채널(검색 광고, SNS, 추천 등)을 통해 들어온 고객의 첫 구매 전환율이 높은지 비교하여 획득 전략을 조정하고 예산을 재분배.

• DA/DS 분석가 관점.

  • Aha! Moment 정의:

    • 첫 구매 전환에 성공한 고객들이 첫 구매 이전에 공통적으로 보인 핵심 행동 (예: 특정 콘텐츠 조회, 3개 이상 제품 장바구니 담기)을 데이터로 정의하고, 이를 'Aha! Moment'로 설정하여 마케팅에 활용.

  • 기여도 모델링:

    • 첫 구매에 영향을 미친 모든 접점(Touchpoint)의 기여도를 분석하는 Multi-Touch Attribution 모델을 적용하여 각 마케팅 활동의 실질적인 전환 기여도를 정확히 측정.

▽ [D.S : 데이터 분석 및 데이터 사이언스] SCM에 관련 데이터 지표들.

목  차

1. 재고 회전율 (Inventory Turnover) 🔄


2. 예측 정확도 (Forecast Accuracy) 🎯

3. 주문 주기 시간 (Order Cycle Time, OCT) ⏱️


4. 단 하나의 주문 충족률 (Perfect Order Rate, POR)

5. 현금 전환 주기 (Cash-to-Cash Cycle Time, CCC)

1. 재고 회전율 (Inventory Turnover) 🔄

개념.

• 재고 회전율은 일정 기간 동안 기업의 재고가 판매되는 속도를 나타내는 지표.

• 재고가 얼마나 효율적으로 관리되고 있는지, 그리고 자본이 재고에 묶여 있는 기간이 얼마나 짧은지를 측정.

이 수치가 높을수록 재고 관리가 효율적이며 자본 회수가 빠름.

관련수식.

재고 회전율은 매출원가(Cost of Goods Sold, COGS)를 평균 재고액(Average Inventory Value)으로 나누어 계산.

• 매출원가를 사용하는 이유는 판매 가격(매출액)에는 이윤이 포함되어 있어 재고의 실제 원가와 비교하기 어렵기 때문.

• 평균 재고액은 일반적으로 (기초 재고액 + 기말 재고액) / 2로 계산.

활용 방법.

• DA

  • 추이 분석 및 비교 진단: 월별/분기별 재고 회전율 추이를 모니터링하여 갑작스러운 변동을 파악
  • 특히, 상품군별(SKU별) 또는 창고별 회전율을 비교 분석하여 회전율이 낮은(Slow-moving) 품목을 식별
  • 이들이 과잉 재고(Overstock)로 이어지는지 분석하여 재고 폐기 리스크를 보고

• DS

  • 최적화 모델의 목표 설정: 수요 예측 모델의 결과를 재고 회전율 예측에 활용하여, 미래의 재고 상태를 시뮬레이션.
  • 재고 최적화 알고리즘을 개발할 때, 서비스 수준(예: 98% 충족률)이라는 제약 조건 내에서 재고 회전율을 최대화하는 발주량 및 발주 시점을 계산하는 목표 함수로 활용.

2. 예측 정확도 (Forecast Accuracy) 🎯

개념.

예측 정확도는 기업이 예상한 수요(Forecast)와 실제로 발생한 수요(Actual) 간의 오차 수준을 측정하는 지표.

• SCM의 모든 계획(조달, 생산, 재고)은 이 예측에 기반하므로, 이 지표는 공급망 전체의 계획 품질을 나타내는 가장 중요한 지표.

관련수식

• 예측 정확도를 측정하는 가장 일반적인 방법은 평균 절대 백분율 오차(MAPE: Mean Absolute Percentage Error)

  • 이는 각 예측 오차를 실제값으로 나눈 후 절댓값을 취하고 평균을 낸 값으로, 백분율로 나타나기 때문에 해석이 용이.

• Actual t는 t 시점의 실제 수요, Forecast t는 t 시점의 예측 수요, n은 측정 기간의 수

활용 방법.

• DA

  • 오차 편향(Bias) 분석: 단순히 MAPE 값만 보는 것이 아니라, 예측이 지속적으로 과소(Underforecast) 되었는지 혹은 과대(Overforecast) 되었는지 편향(Bias)을 분석.

  • 과소 예측은 백오더를 유발하고, 과대 예측은 과잉 재고를 유발하므로, 이에 따른 재고 비용 증가를 산출하여 예측팀에게 보고.

• DS

  • 모델 성능 평가 및 개선: 시계열 분석, 머신러닝(ML), 딥러닝 등 다양한 예측 모델을 구축하고 MAPE를 비롯한 다양한 오차 지표(WMAPE, RMSE 등)를 사용하여 모델의 성능을 평가

  • 모델의 예측 정확도를 높이기 위해 외부 요인(프로모션, 경쟁사 활동, 날씨 등)을 반영하는 피처 엔지니어링을 지속적으로 수행.

3. 주문 주기 시간 (Order Cycle Time, OCT) ⏱️

개념.

관련수식

활용 방법.

4. 단 하나의 주문 충족률 (Perfect Order Rate, POR)

개념.

관련수식

활용 방법.

5. 현금 전환 주기 (Cash-to-Cash Cycle Time, CCC)

개념.

관련수식

활용 방법.

▽ [데이터를 위한 Python : From Scratch to Master.] Python 3.14, 데이터와 성능을 혁신하다: 주요 업데이트 정리 및 분야별 영향 분석 💡

목   차

1. Python 3.14 핵심 업데이트 요약

2. 주요 업데이트가 각 분야에 끼칠 영향 분석

1. Python 3.14 핵심 업데이트 요약

업데이트 공식 문서

Python 3.14는 언어의 근본적인 성능 한계를 해결하고 개발 생산성을 높이는 데 중점을 둔 업데이트. -> 특히, "병렬 처리(Concurrency)"와 "코드 견고성(Robustness)"에 대한 혁식적인 변화가 돋보임.

병렬 처리의 혁명 : GIL의 극복과 성능 향상.

다중 인터프리터의 표준 라이브러리 도입 (PEP 734)

• 오랫동안 CPython의 GIL(Global Interpreter Lock)은 CPU 코어의 병렬 사용을 제한하는 주요 원인.

• 기존에 C-API를 통해서만 접근 가능했던 다중 인터프리터 기능이 concurrent.interpreters 모듈을 통해 공식적으로 파이썬 개발자들에게 개방.

• 이 기능은 단일 프로세스 내에서 여러 개의 파이썬 환경을 격리된 상태로 실행하며, 각 인터프리터는 GIL의 제약 없이 독립된 CPU 코어를 사용가능하게 됨.

이는 기존의 multiprocessing보다 훨씬 가볍고 효율적이면서도, GIL 문제를 우회하여 진정한 멀티코어 병렬 처리를 가능하게함.

Free-threaded 모드의 공식 지원 (PEP 779)

• 이와 함께, GIL 없이 작동하도록 설계된 Free-threaded Python 빌드가 공식적으로 지원. -> 이는 파이썬 생태계 전체에 큰 파장을 예고.

• NumPy, PyTorch와 같은 고성능 라이브러리들이 이 모드를 염두에 두고 스레드 안전성을 확보하게 되면, -> 라이브러리 내부 연산에서 '스레드 기반 병렬 처리의 효율'이 선형적으로 증가할 잠재력을 가짐.

코드 품질 및 개발자 경험 개선.

템플릿 문자열 (t-string) 도입 (PEP 750)

• 새로운 t 접두사를 사용하는 템플릿 문자열 리터럴은 기존 f-string과 달리, 최종 문자열을 즉시 생성하지 않고 Template 객체를 반환.

  • 이 객체는 문자열의 '정적인 부분'과 '보간된 변수 부분'을 분리된 구조로 담고 있음

• 이 템플릿 객체를 사용자 정의 함수에 전달하여서

  • 변수 값에 대한 HTML 이스케이프
  • SQL 인젝션 방지 정제(Sanitization)
  • 특정 포매팅 규칙 등을 적용

• 이후에 최종 문자열 렌더링.

• 코드를 통한 보안 및 데이터 처리의 안정성을 비약적으로 높여줌.

어노테이션 지연 평가 (Deferred Annotations, PEP 649, 749)

• 함수, 클래스, 모듈에 붙는 타입 힌트(Type Hint)의 평가 시점이 지연.

• 이전에는 타입 힌트에 등장하는 클래스가 아직 정의되지 않은 경우(정방향 참조)에는 타입 이름을 '문자열로 감싸야 했음.'

• 이제는 이럴 필요가 없어져서, 코드의 가독성이 크게 향상되고, 타입 힌트를 사용하는 것이 훨씬 자연스러워짐.

  • 이는 MyPy나 Pydantic 같은 타입 검증/스키마 라이브러리를 활용하는 견고한 코드 작성을 장려.

표준 라이브러리 및 인프라 개선.

Zstandard (Zstd) 압축 지원 (PEP 784)

• 표준 라이브러리에 고속 압축 알고리즘인 Zstandard를 위한 모듈이 추가.

• Zstandard는 기존의 Gzip이나 Bz2보다 압축 효율과 속도 면에서 모두 우수하여, 대용량 데이터를 처리하는 데이터 엔지니어링 환경에서 I/O 성능과 저장 효율을 동시에 개선하는 데 직접적인 도움이 됨.

2. 주요 업데이트가 각 분야에 끼칠 영향 분석

DA(데이터 분석)분야.

데이터 분석가들은 대용량 데이터 셋을 '빠르게 로딩'하고, 분석 결과를 '효율적으로 시각화'하는데 중점.

• 성능 부스팅. : 'Zstandard 지원'은 분석 데이터를 보관할 때 파일 크기를 줄이면서도,

  로딩 속도를 유지하거나 개선하여, 데이터 분석 준비 시간을 단축.

• 앱 반응성 개선. : 대시보드 백엔드나 웹 기반 분석 툴을 구축할 때 '다중 인터프리터'를 활용하면, 동시에 발생하는 여러 사용자 요청이나 복잡한 계산 요청을 병렬로 처리하여 "애플리케이션의 반응성(Latency)"을 높일 수 있음.

DS (데이터 사이언스) 분야.

데이터 사이언티스트는 모델 개발과 실험에 많은 시간을 할애하며 '연산 효율'이 중요.

• 학습 및 튜닝 효율화. : '다중 인터프리터'는 하이퍼파라미터 튜닝(Hyperparameter Tuning)이나 교차 검증(Cross-validation)과 같이 독립적인 반복 작업을 '가벼운 병렬 환경'에서 효율적으로 실행할 수 있는 새로운 경로를 제공.

• 고성능 연산의 잠재력. : 'Free-threaded 모드'가 Pandas, Scikit-learn 등 핵심 라이브러리에 적용되면, 데이터 전처리나 모델 연산 과정에서 CPU 코어 활용률이 극대화되어 전반적인 '실험 시간이 단축'될 것.

DE (데이터 엔지니어링) 분야.

데이터 엔지니어는 '대규모 파이프라인의 안정성, 성능, 보안'을 책임.

• 파이프라인 속도 혁신 : 다중 인터프리터는 데이터 추출, 변환, 적재(ETL/ELT) 작업 중 CPU 사용량이 높은 변환 단계를 GIL의 제약 없이 병렬화하여 배치 작업 시간을 획기적으로 단축.

• 쿼리 보안 및 안정성 : t-string은 동적으로 SQL 쿼리를 생성할 때 SQL 인젝션을 방지하는 보안 로직을 강제 적용할 수 있어, 파이프라인의 데이터 무결성과 보안을 강화하는 핵심 도구가 됨.

• 인프라 효율 : Zstandard를 통해 데이터 레이크의 스토리지 비용을 줄이고 I/O 병목 현상을 완화하여, 대규모 데이터 인프라의 경제성과 성능을 동시에 개선.

AI/ML 엔지니어링 분야.

ML 엔지니어는 모델을 배포하고 운영하며 처리량과 안정성을 확보해야 함.

• 실시간 서빙 처리량 증대 : 다중 인터프리터를 사용하면 웹 서버 내에서 여러 개의 모델 추론 요청을 격리된 상태로 동시 처리할 수 있어, GIL로 인한 병목 현상 없이 API의 처리량(Throughput)을 크게 늘릴 수 있음.

• 운영 코드의 견고성 : 지연 어노테이션 덕분에 복잡한 입출력 스키마 정의(예: Pydantic 모델)를 깔끔하게 작성할 수 있어 MLOps 파이프라인의 코드 가독성과 유지 보수성이 높아짐.

• 안전한 설정 관리 : ** t-string**을 통해 모델 설정, 로깅 형식 등을 안전하고 일관된 형식으로 생성하고 관리할 수 있어, 운영 환경에서 발생할 수 있는 오류를 줄임.

파이썬-백엔드 분야.

웹 및 API 서비스를 개발하는 백엔드 개발자에게는 높은 처리량과 보안 안정성이 필수적.

• API 성능 혁신 : 다중 인터프리터는 Django, Flask와 같은 동기식(Synchronous) 웹 프레임워크에서도 CPU 멀티코어를 더 효과적으로 활용하여 요청 처리 능력을 극대화할 수 있는 강력한 대안을 제시.

• 보안 취약점 사전 차단 : t-string을 활용하여 사용자 입력이 포함된 HTML 응답이나 데이터베이스 쿼리 생성 시 자동적인 보안 필터링을 적용, XSS나 SQL 인젝션과 같은 웹 보안 취약점을 소스 코드 레벨에서부터 방지.

• 개발 경험 개선 : 지연 어노테이션이 복잡한 클래스 구조나 순환 참조가 있는 대규모 백엔드 코드베이스의 타입 힌트 사용을 간소화하여 개발 생산성을 높임.

▽ [비즈니스 데이터를 위한 금융. : From Scratch to Master.] 적정주가 산정 및 가치주 선정.

목  차

1. 절대가치 평가의 핵심: 잔여이익 모델 (RIM)

2. RIM 모델의 한계와 보완 (금융공학적 관점)

3. 상대가치 평가의 심층 분석: ROE와 PBR의 관계.

퀀트 투자자의 시선: 금융공학적 관점에서의 적정주가 산정법 📊.

주식 투자의 본질은 "기업 가치와 시장 가격 간의 괴리"를 찾아서 수익을 얻는 것.

금융공학적 관점에서 '적정주가 산정'은 단순히 지표를 나열하는 것을 넘어서, "할인율(리스크)"과 "미래 이익 추정(성장 잠재력)"을 모델링하는 과정.

1. 절대가치 평가의 핵심: 잔여이익 모델 (RIM:Residual Income Model)

RIM:Residual Income Model은 미래 초과 이익(잔여이익)을 현재 가치로 환산하여서 기업의 본질적 가치를 측정하는 "절대가치 평가 모델". -> 시장 상황의 변화에 따라 목표주가가 바뀌는 "상대가치 모델(PER,PBR)"의 한계를 보완.

RIM 공식의 구조적 이해.

RIM에 따른 주주지분가치(Equality Value)는 아래 공식으로 정의

기초 자기자본(Book Value)

현재 시점의 기업 장부가치(순자산)

• RIM은 이 기초 자본을 이미 확보된 가치로 봄.

잔여 이익(Residual Income, RIt)

특정 기간(t) 동안 기업이 투자자들의 요구수익률(자기자본비용)을 초과하여 벌어들인 이익.

• 이는 기업의 경제적 이익(Economic Profit)을 측정하는 지표.

자기자본비용 (Cost of Equity, Ke):

잔여이익을 현재 가치로 할인하는 데 사용되는 할인율.

• 금융공학적 관점에서 이는 주주가 해당 기업의 주식에 투자하여 요구하는 최소한의 기대 수익률이며, 일반적으로 CAPM을 통해 산정.

RIM의 장점과 실무 유용성.

재무제표 연관성:

• RIM은 재무제표상의 장부가치와 순이익을 직접 활용하므로, 회계 정보와의 연계성이 높고 이해하기 쉬움.

종료가치 비중 축소:

• 현금흐름할인법(DCF)과 비교했을 때, RIM은 장부가치가 기업 가치의 상당 부분을 설명
• 불확실성이 큰 종료가치(Terminal Value)의 비중이 상대적으로 줄어들어 예측 정확도가 높다는 연구 결과.

가치 창출 동인 명확화:

• 잔여이익(RI)이 곧 초과 수익을 의미하므로, 투자자는 기업이 자본 비용 대비 얼마나 효율적으로 이익을 창출하는지(즉, ROE>Ke 인지)를 직관적으로 파악 가능.

2. RIM 모델의 한계와 보완 (금융공학적 관점)

RIM은 매우 유용하지만, 미래를 예측해야 하는 모든 절대가치 모델과 마찬가지로 한계

RIM의 주요 유의점

COE 민감도.

• 할인율인 자기자본비용(Ke)의 아주 작은 변화에도 산출되는 적정 주가는 큰 폭으로 변동가능

• 금융공학적 관점에서 Ke를 합리적이고 일관된 기준으로 설정하는 것이 RIM 모델의 안정성에 핵심적

초과이익의 지속 가정

• RIM은 미래 특정 기간 이후의 초과이익이 영원히 유지되거나 일정한 성장률로 증가한다고 가정

• 현실적으로 매우 강력한 가정이며, 기업의 경쟁 우위(Economic Moat)를 면밀히 분석해야함.

다른 주요 절대가치 평가 모델과의 비교 (DCF)

RIM은 '이익' 기반, DCF는 '현금흐름' 기반 모델로, 두 모델을 상호 보완적으로 사용하여 적정주가의 범위를 설정하는 것이 가장 이상적인 금융공학적 접근법.

3. 상대가치 평가의 심층 분석: ROE와 PBR의 관계.

PBR, PER, ROE는 RIM을 보완하는 상대가치 평가의 핵심입니다. 특히 PBR과 ROE의 관계는 가치주 선별의 기본 원리.

• PBR (Price-to-Book Ratio): 시장 가격이 장부가치 대비 몇 배인지 나타냄.

• ROE (Return on Equity): 주주의 자본 효율성을 나타냄.

금융공학적으로, 기업의 가치는 자본을 얼마나 효율적으로 사용하느냐에 따라 결정되므로, ROE가 높은 기업일수록 시장에서 높은 PBR 배수를 부여받는 것이 일반적.

🔥 가치주 선별의 퀀트 전략:

• 'ROE는 높지만 PBR은 동종 산업 평균 대비 낮은' 기업은 시장에서 저평가되었을 가능성이 높다고 판단.

• 이는 RIM 분석을 시작하기에 좋은 선별 기준.

▽ [AI&ML_Eng : 개념 공부.] : 텍스트 감성 분석 (Sentiment Analysis) 01.

목  차

1. Article at a Glance (요약 및 확장)

2. 감성 분석이란 무엇인가? (Definition & Scope)

3. 어떻게 분석하나? (Analysis Methods)

4. 감성 분석과 딥러닝 (Deep Learning)

1. Article at a Glance (요약 및 확장)

2. 감성 분석(Sentiment Analysis)이란 무엇인가? (Definition & Scope)

감정/감성의 뜻 정리.

• 감정 분석.

  • "감정"은 인간이 느끼는 기쁨, 슬픔, 분노 등의 감정 상태를 의미
  • "감정분석"은 텍스트에서 감정 상태를 분석한다는 의미를 명확히 전달
  • 이 표현은 특히 인간의 감정 상태에 초점을 맞춘 분석을 할 때 적합

• 감성 분석.

  • "감성"은 감정뿐만 아니라 감각, 직관, 느낌 등을 포함하는 더 넓은 의미
  • "감성분석"은 텍스트에 담긴 정서적 반응이나 주관적 느낌을 분석하는 데에 더 넓은 의미를 포함할 수 있음
  • 감정을 포함한 보다 포괄적인 분석을 의미할 때 사용될 수 있음

• 일반적으로 감정보다는 '감성분석'이라고 쓰임.

감성 분석 정의

위키 : 언어 처리, 텍스트 분석, 계산 언어학 및 생체 인식을 활용하여 감정 상태와 주관적인 정보를 체계적으로 식별, 추출, 정량화 및 연구하는 기술

AWS : 디지털 텍스트를 분석하여 메시지의 감정적 어조가 긍정적인지, 부정적인지 또는 중립적인지를 확인하는 프로세스

주관적 요소의 정량화.

감성 분석은 '자연어 처리(NLP)' 분야의 한 갈래로, 텍스트 데이터에 담긴 주관적인(Subjective) 정보를 객관적인 수치로 변환하는 작업.

• 주관적 요소 : 단순히 사실(Fact)을 나열한 문장(→ 객관적 탐지)이 아닌 작성자의 의견(Opinion), 감정(Emotion), 평가(Evaluation), 태도(Attitude) 등이 포함된 부분을 의미.

• 정량화 : 분석된 감정을 컴퓨터가 처리할 수 있는 형태, 즉 {수치, 도식, 등급 } 등의 객관적 지표로 나타내는 것.

  • ex) "이 제품은 훌륭하다!" → 긍정 (+1) 또는 감성 점수 +0.9

단순 분류를 넘어선 분석 목표.

감성 분석은 단순히 텍스트 전체를 '긍정/부정'으로 분류하는 것을 넘어, 훨씬 더 복잡하고 디테일한 목표를 가짐.

• 개체(Entity) 및 속성(Aspect) 추출 : 어떤 대상(제품,서비스,인물)의 '어떤 속성'에 대한 감성인지를 파악.

  - ex) "새 휴대폰의 디자인은 예쁘지만, 배터리 수명은 실망스럽다." 
         - → '디자인'에 대해 긍정, '배터리 수명'에 대해 부정.
            (이러한 방식을 속성 기반 감성 분석이라고 합니다.)

• 의견 보유자(Opinion Holder) 분석 : 누가(어떤 사용자 그룹이, 어떤 인물이) 그 감성을 표현했는지까지 파악하여 더욱 심층적인 고객 세분화 분석이 가능.

감성 표현의 정량화 방식.

3. 어떻게 분석하나? (Analysis Methods)

감성 분석은 기존에는 크게 두 가지 접근 방식으로 나룰 수 있다고 하지만, 이제는 4가지로 나눌 수 있다고 봅니다.

감성사전 기반 분석(Lexicon-based Approach)

• 원리 : 미리 구축된 감성 사전(Sentiment Lexicon)을 사용하여 텍스트 내 단어들의 감성 점수를 합산하거나 통계적으로 처리하여 최종 감성을 판별

• 감성 사진 구성 : 감성 단어("좋다","나쁘다","만족","실망" 등등)와 그에 해당하는 "극성 범주(긍정/부정) 및 감성 점수"로 구성.

• 장점

  • 학습 데이터가 필요 없어 '데이터 라벨링(Labeling) 비용이 절감'
  • 새로운 도메인에 적용하기 비교적 용이.

• 단점

  • 감성 사전의 품질이 분석 성과에 직결되며, 사전에 없는 단어나 새로운 유행어, 도메인 특화 단어 (ex: 의학 용어, 금융 용어)의 처리가 어려움.

• "부정어(Not)나 수식어(매우,조금)"의 영향을 처리하기 위한 복잡한 규칙이 필요.

• '문맥 의존성'을 파악하기 어려움

  • ex) 가격은 싸지만, 만족스럽지 않다 -> '만족스럽다'를 긍정으로만 판단할 수 있음.

• 예전 방식이며, 요즘은 잘 사용을 안하는 듯 함.

기계학습 기반 분석(Machine Learing-based Approach)

• 원리 : 대량의 '라벨링된 텍스트 데이터'(긍정/부정으로 미리 분류된 데이터)를 학습하여,

  텍스트의 패턴과 감성 간의 관계를 스스로 파악하는 "분류 모델(Classification Model)"을 구축.

• 특징

  • 지도 학습(Supervised Learing)방식이 주로 사용
  • 충분하고 잘 라벨링된 학습 데이터가 필수적.

• 전통적 머신러닝 모델

  • 나이브 베이즈(Naive Bayes) : 단순하지만 효율적이며, 각 단어가 독립적이라고 가정하고 분류.

  • 서포트 벡터 머신(SVM) : 데이터를 잘 분리하는 최적의 경계(Hyperplane)를 찾아 분류 성능이 우수.

  • 결정 트리(Decision Tree) 및 앙상블 기법(Random Forest, Gradient Boosting) : 복잡한 규칙을 이해하기 쉽도록 분류.

• 전통적 기계학습의 어려움

  • 텍스트 데이터는 단어의 종류가 많고(높은 차원)
  • 각 단어의 출현 빈도는 낮아서(희소성,Sparsity)
  • 데이터의 효율적인 표현과 특징 추출이 분석 성과에 매우 중요.

속성 기반 감성 분석 (Aspect-Based Sentiment Analysis, ABSA).

• 원리. : 텍스트 전체의 감성이 아닌, "특정 개체의 세부 속성(Aspect)"에 대한

   감성만을 분리하여 분석.

• 분석의 정교함 : 고객이 "제품-가격" 에 만족하는지, "디자인"에 불만족하는지 등등

   세밀한 고객 목소리(Voc)를 파악하여 '제품 개선 우선수위' 셀렉에 활용.

• 단계 : ① 개체 및 속성 추출 → ② 속성에 대한 의견 표현 추출 → ③ 각 속성별 감성 극성 분류.

• 난이도 : 일반 감성 분석보다 훨씬 복잡하며, 딥러닝 기술이 필수적으로 요구.

AI 및 대규모 언어 모델 기반 접근 (AI and Large Language Model-based Approach)

• 원리. : 최근 가장 우수한 성능을 보이는 방법으로, '딥러닝(Deep Learning)' 기술과

  '트랜스포머(Transformer)' 구조를 기반으로 하는 LLM을 활용.

  워드 임베딩과 딥러닝 모델의 활용

  이 접근법은 전통적인 기계 학습의 한계였던, "단어의 의미 및 문맥 부족" 문제를 "워드 임베딩(Word Embedding)"을 통해 해결

  • *워드 임베딩(Word EMbedding) * : 단어를 "저차원의 밀집 벡터(Dense Vector)"로 변환하여 단어간의 "의미적,문법적 관계"를 수학적으로 표현.

    • ex) Word2Vec, GloVe, 이를 통해 딥러닝 모델은 단어의 단순한 존재 유무가 아닌,

      "**의미 유사성**을" 파악 가능.

      

  • 대표 딥러닝 모델

    • RNN/LSTM

      • 텍스트의 "순서 정보"를 처리하여 문맥을 파악.
      • 특히 LSTM은 장기적인 문맥 의존성을 처리하는 데 강점.

    • CNN

      • 문장에서 감성을 나타내는 "핵심 구절(Local Features)"이나 패턴을 효율적으로 추출하는데 사용.

대규모 언어 모델(LLM) 기반의 혁신.

• LLM은 '트랜스포머(Transformer)' 구조를 기반으로 하며, 방대한 양의 텍스트 데이터로 "사전 학습(Pre-training)"되어 언어의 문맥과 의미를 매우 깊이 이해.

4. 감성 분석과 딥러닝 (Deep Learning)

최근에는 전통적인 기계 학습을 넘어서 "딥러닝(Deep Learning)" 모델이 감성 분석의 성능을 혁신적으로 향상시키는 중.

워드 임베딩 (Word Embedding)의 등장과 중요성.

전통적인 방식은 단어를 단순히 카운트하거나(TF-IDF 등) 원-핫 인코딩(One-Hot Encoding)을 사용하여 표현했는데, 이는 단어 간의 의미적 유사성이나 문맥적 관계를 전혀 반영하지 못하는 문제(희소성 문제)

• 개념 : 단어를 "저차원 공간의 실수 벡터"로 변환하여 표현하는 기법.

• 특징 : 의미가 유사한 단어일수록 벡터 공간에서 "가깝게 배치"되어

   단어들 간의 어휘적, 문맥적 관계를 수학적으로 표현.

  • 예: Vector(’왕’)−Vector(’남자’)+Vector(’여자’)≈Vector(’여왕’)

• 대표 기법 : Word2Vec (Google), GloVe 등이 있으며, 이 임베딩 벡터를 딥러닝 모델의 입력값으로 사용하면 텍스트의 의미를 훨씬 깊이 있게 학습

대표적인 딥러닝 모델들

워드 임베딩을 통해 입력된 텍스트 데이터를 처리하여 감성을 분류하는 데 사용되는 주요 딥러닝 모델은 다음과 같음.

합성곱신경망: CNN (Convolutional Neural Network)

• 원리 : 원래는 이미지 처리에 사용되던 모델
  • 텍스트에서도 "주요 특징(Feature)", 즉 문장에서 감성을 나타내는 "핵심 구절이나 패턴"을 필터(Kernel)를 통해 추출하는데 효과적.
• 장점 : 지역적 특성(N-gram과 같은 짧은 구절) 추출에 능하며, 처리 속도가 비교적 빠름.

순환신경망: RNN/장단기 기억: LSTM (Recurrent Neural Network / Long Short-term Memory Network)

• 원리 : 텍스트는 "순서(Sequence)"를 가지므로, 이전 단어의 정보가 다음 단어의 해석에 영향을 미치는 "시퀸스 데이터"

  • RNN은 이러한 순환 구조를 통해 텍스트의 "문맥(Context)"을 파악.

• LSTM : 기본적인 RNN의 장기 의존성(Long-term Dependency) 문제와 기울기 소실(Vanishing Gradient) 문제를 해결하기 위해

  • 게이트(Gate) 구조(입력, 망각, 출력 게이트)를 도입.
  • 먼 과거의 중요한 정보도 기억할 수 있게 함.
  • 감성 분석에서 문장 전체의 의미를 파악하는데 매우 중요.

Transformer 기반 모델 (BERT 등)

• 최신 트렌드 : 최근에는 Attention 메커니즘을 기반으로 한 Transformer 구조가 압도적인 성능을 보임.

• BERT

  • 구글에서 개발한 모델로, 문맥을 양방향으로 이해(기존 RNN은 단방향)
  • 사전 학습(Pre-Training)된 대규모 언어 모델을 감성 분석 등 특정 작업에 미세 조정(Fine-tuning)하여 사용하는 방식으로 우수한 결과..

[D.S : 데이터 분석 및 데이터 사이언스] 코호트 분석(Cohort Analysis)이란.

▽ [D.S : 데이터 분석 및 데이터 사이언스] 코호트 분석(Cohort Analysis)이란.

목   차

1. 코호트 분석이란?

2. 왜 코호트 분석이 필요한가?

3. 코호트 분석 핵심 구성요소.

4. 코호트 분석 종류와 기준.

5. 핵심 지표와 시각화 방법 & 핵심 인사이트 도출 방법.

6. 코호트 분석의 실질적인 활용

1. 코호트 분석이란?

정의 : 사용자 집단("코호트")을 일정 기준으로 묶어서 '시간 경과(시계열 데이터)'에 따른 행동 패턴이나 성과를 분석하는 방법. == "같은 시점/같은 조건으로 시작한 그룹이 시간이 지나면서 어떻게 변화했는가??"를 보는 분석 기법.

정의 : '코호트'와 '분석'

• 코호트(Cohort, 동질 집단)

  • 특정 기간 동안 '공통적인 특성이나 경험'을 공유하는 사용자들의 집단.
  • 코호트는 한번 형성되면 시간이 지나도 그 구성원이 변하지 않는 '정적인 그룹'.

• 코호트 분석(Cohort Analysis)

  • 이 코호트들의 '행동 변화나 성과'를 '시간의 흐름에 따라서' 추적하고 비교분석하는 기법.

목적.

• 사용자 유지율(Retention) 확인.

• 특정 이벤트/행동의 효과 측정

• 장기적 LTV(Lifetime Value) 예측

• CRM : 그로스 마케팅 전략 수립.

언제 쓰이는가

• 앱/웹 서비스의 사용자 활동 분석

• 프로모션, 캠페인 효과 검증

• 기능 개선 전후 비교

2. 왜 코호트 분석이 필요한가?

일반적인 지표 분석의 한계.

• 대부분의 비즈니스 지표(예: 월간 활성 사용자 수, 전체 유지율)는 모든 사용자를 하나의 집단으로 평균 내어서 보여줌.

• 이러한 '전체 평균'은 특정 기간의 마케팅 효과, 제품 업데이트의 장기적인 영향 등을 '숨기거나 왜곡'할 수 있음.

  • ex) 6월에 훌륭한 신규 고객 획득 캠페인을 진행했지만, 7월에 유입된 고객들의 품질이 매우 낮다면, 7월의 전체 유지율은 낮아질 것. 코호트 분석 없이는 6월 캠페인의 진정한 성공을 파악하기 어려움.

고객 유지율(Retention) 및 이탈 원인 파악 ( 가장 중요 )

문제점.

• "이탈률이 높아졌다"는 사실만으로는 어떤 고객이, 왜 이탈했는지를 알기 어려움.
• 단순 평균 지표는 왜곡이 많음.

코호트 분석의 역할

• 코호트별로 나눠보면, 특정 시점/캠페인 효과가 명확히 드러남.
• 특정 시기에 유입된 그룹(코호트)이 시간이 지남에 따라 얼마나 남아있는지(유지율)를 정확히 보여줌.
  • 이를 통해, "어떤 유입 시점의 고객"이 가장 빠르게 이탈했는지, 그리고 "이탈이 발생하는 시점"이 언제인지를 명확하게 파악하여 선제적 대응 전략 수립 가능.

변화의 원인 분석 (Why did the metric change?)

문제점.

• 단순 지표의 함정 :
  • 전체 지표(ex: 월간 사용자 수)가 하락했을 때, 그 원인이 '신규 고객 문제' 때문인지, 아니면 '기존 고객 이탈' 때문인지 구분하기 어려움.

코호트 분석의 역할

• 원인 집단 특정 :
  • 지표 변화를 코호트별로 분리하여 관찰.
  • 특정 기간(코호트)에 유입된 집단에서만 문제가 발견된다면,
    • 그 '유입 시점의 특정 요인(마케팅 채널, 온보딩 오류, 경쟁사 이슈)'을 문제의 원인으로 즉시 특정 가능해짐.

전략 수립에 직접 활용 (How to act?)

문제점.

• 획일적 전략의 비효율성 :
  • 모든 고객에게 동일한 마케팅 예산이나 리소스를 투입하여 '가치가 높은 고객'에게 더 많은 투자를 하지 못하는 비효율이 발생.

코호트 분석의 역할.

• 가치 기반 리소스 배분 :
  • 장기적으로 가장 높은 고객 생애 가치(LTV)를 보이는 코호트를 식별.
    • 이를 통해 해당 코호트가 유입되는 마케팅 채널에 예산을 집중하거나, 해당 고객들이 좋아하는 기능에 제품 개발 자원을 우선적으로 배분하는 데이터 기반 전략을 수립 가능.

마케팅 및 캠페인 효과의 정확한 측정.

문제점.

• 마케팅 캠페인 직후의 단기적인 매출 증가가 일시적인 현상인지 아니면, 장기적인 고객 가치(LTV)를 창출하는지 판단하기 어려움.

코호트 분석의 역할

• 캠페인별로 유입된 코호트의 장기적인 행동과 평균 LTV를 비교 분석.
  • 이를 통해 진정으로 가치 있는 고객을 데려오는 가장 효율적인 마케팅 채널과 캠페인을 객관적으로 식별하여 예산 배분의 근거로 활용함.

제품/서비스 개선 효과 검증.

문제점.

• 새로운 기능 출시나 UI/UX 개선 후 지표가 변동했을 때.
  • 이 변화가 개선 자체의 효과 때문인지, 아니면 단순히 외부 이벤트나 계절적 요인 때문인지 구분하기 어려움.

코호트 분석의 역할.

• 개선 이전 코호트와 개선 이후 코호트의 행동 지표(예: 재방문율, 특정 기능 사용률)를 비교.
  • 이를 통해 개선 사항이 신규 사용자 유지에 긍정적인 영향을 주었는지 객관적으로 평가.
  • 개선의 성공 여부를 확실하게 검증.

사용자 세분화 및 맞춤 전략 수립.

문제점.

• 모든 고객을 하나의 집단으로 간주하고 획일적인 메시지나 전략을 적용.
  • 고객별 고유한 특성과 니즈를 무시하게 되어 비효율적인 전략이 수립됨.

코호트 분석의 역할.

• 행동 기반이나 유입 경로 기반의 코호트를 생성하여 각 그룹의 고유한 패턴을 파악.
  • 이를 통해 각 코호트의 특성과 니즈에 맞는 맞춤형 온보딩, 메시지, 기능 추천을 제공하여 전환율과 인게이지먼트를 극대화하는 세분화 전략을 수립

3. 코호트 분석 핵심 구성요소.

코호트 분석을 수행하려면 다음 세 가지 요소를 정의해야 함.

코호트 정의 기준(Cohorts)

코호트 그룹을 나누는 기준.

시간 기반 코호트 (Time-Based Cohorts)

• 사용자가 서비스를 획득(Acquisition)한 시점(날짜, 주, 월)을 기준으로 그룹으로 나눔.

  • ex) 2024년 5월 1일 웹사이트에 최초로 방문한 모든 사용자 그룹. (가장 일반적이며, 리텐션 분석에 필수)

행동 기반 코호트 (Behavioral Cohorts)

• 사용자가 '특정 행동'을 처음으로 수행한 시점을 기준으로 그룹을 나눔.

  • ex) 서비스 가입 후 '첫 번째 유료 구독을 결제'한 모든 사용자 그룹.

속성 기반 코호트

• 사용자의 '영구적인 특성'을 기준으로 나눔.

  • ex) 특정 지역 사용자, 특정 디바이스(IOS/Android) 사용자 그룹.

시간 경과 (Time Delta / Period).

코호트의 행동을 측정하는 시간 단위와 기간.

시간 단위

• 분석하고자 하는 행동의 주기와 빈도에 따라서, 일별(Day), 주별(Week), 월별(Month)로 설정.

  • ex) 모바일 게임의 경우, 일별 추적이 중요하며,

    구독 서비스는 월별 추적이 일반적.

경과 시간(Time Delta)

• 코호트가 시작된 시점을 기준으로 얼마나 시간이 지났는지 나타내는 값.

측정 지표 (Metrics).

코호트별로 추적하고 비교할 핵심 성과 지표(KPI).

유지율 (Retention Rate):

• 코호트가 시작된 후 특정 경과 시간까지 남아있는 (재방문, 재구매 등) 사용자의 비율.
  • (코호트 분석의 가장 대표적인 지표)

이탈률 (Churn Rate):

• 서비스에서 이탈한 사용자의 비율.
  • (유지율의 반대 개념)

평균 구매 금액 / 누적 매출:

• 시간이 지남에 따라 코호트가 발생시킨 총수익을 추적하여 고객 생애 가치(LTV)를 계산하는 데 활용.

4. 핵심 지표와 시각화 방법 & 핵심 인사이트 도출 방법.

코호트 분석의 핵심 지표.

코호트 분석은 시간의 흐름에 따른 사용자 행동을 추적하므로, 주로 장기적인 가치와 충성도를 측정하는 지표를 사용.

지표명 : 유지율 (Retention Rate)

• 측정 내용 : 특정 기간 이후, 해당 코호트가 서비스에 남아있는 비율.

• 비즈니스 중요성 : 가장 핵심 지표. 고객 만족도 및 제품의 핵심 가치를 반영하며, 이탈 시점을 파악하게 해줌.

지표명 : 이탈률 (Churn Rate)

• 측정 내용 : 특정 기간 동안 코호트에서 이탈한 사용자 비율.

• 비즈니스 중요성 : 유지율의 반대 지표. 위험 코호트를 식별하여 집중적인 관리가 필요한 대상을 알려줌.

지표명 : 고객 생애 가치 (LTV)

• 측정 내용 : 코호트의 사용자당 평균 누적 매출 또는 수익

• 비즈니스 중요성 : 마케팅 효율 측정에 필수적. 어떤 유입 채널 코호트가 장기적으로 돈을 더 버는지 알려줌.

지표명 : 참여 빈도 (Engagement)

• 측정 내용 : 코호트의 사용자당 평균 세션 수 또는 핵심 기능 사용 횟수.

• 비즈니스 중요성 : 서비스의 '끈끈함' (Stickiness)을 측정. 높은 참여 빈도는 이탈 가능성이 낮음을 의미.

지표명 : 전환율 (Conversion Rate)

• 측정 내용 : 코호트가 특정 목표 행동(예: 첫 구매, 유료 구독 전환)을 완료한 비율.

• 비즈니스 중요성 : 온보딩 및 초기 마케팅의 성공 여부를 판단하는 데 중요.

효과적인 시각화 방법: 코호트 테이블 (Heatmap).

코호트 분석 결과를 시각화하는 가장 강력한 방법은 색상 농도를 활용한 코호트 테이블 (Heatmap)

시각화 해석 방법.

• 1. 가로 방향 분석(같은 코호트).

     • 특정 코호트(한 행)가 시간이 지남에 따라 지표가 어떻게 감소(Decay)하는지를 확인.
       • → 제품 생애주기 내의 이탈 시점 파악.

• 2. 세로 방향 분석(같은 경과 시간).

     • 모든 코호트가 가입 후 동일한 경과 시간에서 어떤 지표를 보이는지 비교.
       • → 제품/마케팅 변화의 영향 확인.
         • (예: Day 7 지표가 5월 코호트부터 갑자기 높아졌다면, 5월 이전에 진행된 제품 개선이 효과적이었음을 의미).

• 3. 대각선 방향 분석(같은 달).

     • 모든 코호트의 특정 달(기간) 지표를 비교하여 시기적 이벤트(Period Effect)의 영향을 확인.
       • → 예: 11월 블랙프라이데이에는 모든 코호트의 구매액이 일시적으로 증가.

핵심 인사이트 도출 방법.

시각화된 코호트 테이블에서 다음 세 가지 주요 패턴을 찾아내고 그 원인을 탐구하는 것이 인사이트 도출의 핵심.

1. 급격한 하락 지점 (Drop-off Inflection Point) 식별.

• 패턴. : 특정 경과 시간(예: 가입 후 3일차, 4주차)에서 모든 코호트의 지표가 급격히 하락하는 지점.

• 인사이트. : 이는 제품 자체의 온보딩/사용자 경험(UX)에 문제가 있거나, 사용자가 핵심 가치를 경험하지 못하고 이탈하는 결정적인 순간이 있음을 의미.

  • 이 시점에 집중하여 고객 여정을 개선해야 함.

2. 이상치 코호트 (Outlier Cohorts) 분석.

• 패턴 : 다른 코호트들에 비해 유난히 높거나 낮은 성과를 보이는 특정 코호트 (특정 행).

• 인사이트:

  • 성과가 높은 코호트 : 이들이 유입된 특정 마케팅 채널, 캠페인, 프로모션이 고가치 고객을 데려오는 요인일 수 있음.

    • 해당 유입 경로와 온보딩 경험을 표준화해야함.

  • 성과가 낮은 코호트 : 이들의 유입 시점에 경쟁사 이벤트가 있었거나, 광고 메시지의 오해를 불러일으켜 부적절한 고객이 유입되었을 가능성이 높음.

    • 해당 마케팅 활동을 중단하거나 수정해야함.

3. 지표 개선의 지속성 확인.

• 패턴 : 특정 시점 이후에 유입된 모든 신규 코호트의 유지율 곡선이 이전 코호트보다 뚜렷하게 더 높게 유지되는 경우.

• 인사이트 : 이는 그 시점 직전에 진행된 제품 업데이트나 마케팅 전략의 변화가 지속적인 효과를 발휘하고 있음을 의미.

  • 이 변화가 고객의 장기적인 행동에 긍정적인 영향을 주었음을 공식적으로 검증하고, 해당 변화를 서비스의 영구적인 부분으로 확정할 수 있음.

5. 코호트 분석의 실질적인 활용.

코호트 분석은 단순한 현상 파악을 넘어 비즈니스 의사결정에 직접적인 근거를 제공.

마케팅 효율 최적화

• 특정 마케팅 채널/광고 캠페인으로 유입된 코호트를 분석.
• 당장의 전환율은 낮더라도 장기적으로 LTV가 높은 채널을 식별하고 예산을 집중.

제품 개선 효과 검증

• 특정 기능을 릴리스하거나 UX를 개선했을 때, 그 이후에 유입된 코호트의 1개월 차 유지율이 이전 코호트보다 개선되었는지 확인.

• 개선이 없었다면 다른 방식으로 재접근해야 함을 알려줌.

이탈 방지 전략 수립

• 사용자가 급격히 이탈하는 '위험 시기'를 정확히 포착.
• 이 시기 직전에 고객에게 맞춤형 푸시 알림, 이메일, 혹은 인앱 보상을 제공하여 이탈을 선제적으로 방지.

고객 세그먼트의 가치 평가

• 예를 들어, '모바일 앱 사용자 코호트'와 '웹사이트 사용자 코호트'를 나누어 비교하여, 어느 플랫폼 사용자가 더 활발하고 가치가 높은지 파악

▽ [D.S : 데이터 분석 및 데이터 사이언스] '디지털 애널리틱스의 종말'이라는 글을 읽고서.

원문 글 : 디지털 애널리틱스의 종말.

원본 글 정리.

서막 : 무엇이 끝났는가??

• Amplitude가 구글 애널리틱스를 상징하는 인물을 영입 → 단순한 인사가 아님.

• 이것은, "디지털 애널리틱스"라는 개념 자체가 막을 내렸음을 알리는 신호.

• GA4 중심의 마케팅 분석 시대는 붕괴 중이며, Amplitude는 사실상 “새로운 구글 애널리틱스”를 자처.

• 하지만, 더 이상 'GA 같은 것' 자체가 필요없는 시대로 나아가고 있음.

디지털 애널리틱스가 세워졌던 불안정한 기반.

• 겉모습 : "데이터 기반 의사결정"

  • 방문자 수, 전환율, 클릭률 등 측정 -> 대시보드를 만들어서 숫자들을 표시.
  • 복잡한 트래킹/태깅 -> 사용자 행동 데이터 축적.

• 내부에 존재하는 모순.

  • "우리가 보고 있는 이 데이터가 실제 비즈니스에 무슨 의미가 있나??"
  • ex) 200명이 특정 버튼을 클릭했다는 데이터가 존재 -> 그런데 이 데이터로 뭘 해야하는지 알려주지는 못함.

• 디지털 애널리틱스를 활용할 때의 효과.

  • 회의에서 숫자와 차트로 정량적인 지표를 제시하는 느낌을 줄 수 있음
  • 그런, 제품/비즈니스를 위한 의사결정은 여전히 직관 * 피드백 * 시장조사에 의존.

애널리틱스가 정말 효과를 낸 두 가지.

(1) 마케팅 어트리뷰션(MVP)

• 진짜로 매출/이익의 흐름을 바꾼 유일한 영역
• 예전엔 광고 채널마다 “내가 매출 기여했다” 주장 → 중복 계산 문제.
• GA가 중립적 심판 역할: 어느 채널이 전환에 기여했는지 보여줌.
• 예산 최적화·ROI 측정 가능 → CFO 설득 가능.

⚠️ 그러나 현재는 붕괴:

• 애플/브라우저의 추적 제한, 쿠키 동의 절차.
• 마케팅 채널이 폭증 → 어트리뷰션 불가능.
• 구글·페이스북 등은 확률적 모델로 전환: “우리를 믿어라, AI가 계산해준다.”

(2) "어두운 공간에 빛을 비춤"

• 예전엔 웹사이트 내부에서 무슨 일이 벌어지는지 아무도 몰랐다.

• 애널리틱스가 최소한 “보이는 언어(이해 가능한 문서) ”를 제공:

  • 인기 페이지 파악
  • 유저 이탈 지점 파악
  • 블로그 포스트/모바일 행동 차이 등

• 한계 :

  • 데이터는 "무슨 일이 발생하고 있는지"만 알려줌.
  • "왜 그런지"는 알 수 없음 -->> 실행으로는 이어지지 못함.

냉혹한 현실.

• 지난 20년간 디지털 애널리틱스의 실질적 비즈니스 임팩트 80% = 마케팅 어트리뷰션.

• 나머지 (퍼널 분석, 세그먼트, 리텐션 분석 등) = 흥미롭지만 “빛 비추기” 수준.

• 업계는 “고객 이해 혁신”을 약속했지만, 사실은 마케팅 측정 문제 해결에 국한.

• 결과: 데이터 기반이라는 착각을 만들어낸 것에 불과.

기반이 무너지는 이유.

• 외부 요인 : 개인 정보 접근 규제, 쿠키 제한, 애플의 반(反)추적 정책.

• 근본 요인 : 마케팅 자체가 너무 복잡해짐.

  • 과거 : 검색 광고 + 소셜 광고 = 단순 구조

  • 현재 : 유튜브, 인플루언서, 팟캐스트, 커뮤니티, 오프라인 이벤트, PR 등 수십 개 채널.

  • -->>"어트리뷰션"은 이 복잡성을 포착 불가.

• ++ 광고 플랫폼들은 "결정적 어리트뷰션" 포기.

  • "우리가 만든 AI가 최적화해줄 테니 믿어라"라는 스탠스로 전환.

앞으로 있을 두 가지 길.

• 1. 운영적 고객 경험 최적화.
     • 속도를 중시.
     • “사용자가 막히는 지점 개선” 같은 실용적 최적화.
• 2. 전략적 레베뉴 인텔리전수
     • 비즈니스 성과와 사용자 행동을 연결.
     • 단순 클릭·전환율을 넘어, 수익과 직결되는 지표 중심 분석.

✨ 핵심 요약. 디지털 애널리틱스 시대는 끝났다.

• 남은 건 단 두 가지 가치: 1.마케팅 어트리뷰션 (이미 붕괴 중) 2.사용자 행동 가시화 (빛 비추기)
• 앞으로의 분석은 기존 GA 방식이 아니라:
  • 빠른 실행을 돕는 고객 경험 최적화
  • 수익과 행동을 직접 연결하는 레베뉴 인텔리전스
• 즉, 단순히 “데이터 기반”이 아니라, 비즈니스 중심 데이터 활용이 필요한 시대.

📌 디지털 애널리틱스의 종말 — 핵심 정리 & 신입 인사이트.

✨ 핵심 정리.

• 디지털 애널리틱스는 지난 시간 동안 크게 두 가지에서 의미를 가짐.

  • 1. 마케팅 어트리뷰션(ROI 측정) : 광고 예산 최적화에 실제 기여
  • 2. 사용자 행동 가시화 : 웹/앱 내부에서 무슨 일이 일어나는지 보여줌.

• 하지만 한계도 명확해짐.

  • 비즈니스 인사이트 부족 : 데이터가 "왜" 그런지 설명 못함
  • 복잡한 마케팅 환경 : 수많은 채널과 제한된 추적 기술 -> 정확한 어트리뷰션 불가능
  • 규제 강화 : 개인정보 보호, 쿠키 제한 등으로 전통적 분석 모델 붕괴.

결론적으로, “구글 애널리틱스 같은 툴”의 시대는 끝났습니다. 앞으로는 단순 지표 나열이 아니라 비즈니스 가치와 직접 연결된 분석이 필요.

✨ 앞으로 필요한 변화.

디지털 애널리틱스 이후의 방향성은 크게 두 가지.

• 1. 운영적 최적화(Operational Optimization)

     • 사용자가 어디서 막히는지, 어떤 지점에서 이탈하는지 빠르게 파악
     • 즉각적인 개선 → UX, 퍼널 전환율 개선

• 2. 전략적 레베뉴 인텔리전스(Revenue Intelligence)

     • 단순 클릭·트래픽이 아니라 실제 매출/고객 생애가치(LTV)와 연결
     • 제품·마케팅·세일즈가 같은 언어(매출, 수익성)로 데이터를 해석하는 체계 구축

👉 즉, 앞으로의 데이터 분석은 “실험 → 실행 → 성과 연결 → 반복”의 순환 구조가 필요.

✨ 신입 입장에서 얻을 인사이트 & 준비 방안.

📌 공통 인사이트 (세 직무 모두 해당)

• 1. 데이터 리포팅 -> 실행 연결.

     • 단순히 "숫자를 보여주는 역할"은 가치가 급격히 줄어듦.
     • 데이터를 통해 "실행 가능한 가설 제시 -> 실험 -> 결과 해석"으로 이어져야 함.

• 2. 비즈니스 지표 중심.
     • 트래픽, 클릭률, PV 같은 지표는 보조적.
     • 이제는 LTV (고객 생애 가치), CAC (고객 획득 비용), Retention, Churn Rate 같은 지표를 다룰 수 있어야 함.

• 3. 실험 문화 이해

     • 실험(AB Test, Test vs Control)을 설계하고, 작은 시도라도 결과를 숫자로 해석해내는 역량 필수.
     • “왜 이런 결과가 나왔는지”를 비즈니스 맥락에서 설명할 수 있어야 함.

🎯 1) CRM & 그로스 마케터

• 핵심 관점: 고객 여정을 이해하고, 리텐션·재활성화·업셀링을 통해 매출 기여.

• 필요 역량:

  • 코호트 분석(가입 시점/캠페인별 행동 변화 추적)
  • 세그먼트 마케팅 (고객 특성별 맞춤 전략)
  • CRM 툴(Braze, Iterable, Salesforce Marketing Cloud) 경험

• 준비 포인트:

  • SQL로 활성 고객 수, 이탈 고객 비율, 캠페인 반응률 계산 연습
  • 리텐션 곡선(사용자 유지율 그래프) 읽고 인사이트 도출
  • 고객 Lifecycle 기반 CRM 전략 시뮬레이션

• 실무 적용 예시 :

  • “지난달 가입한 신규 고객의 30일 Retention이 낮음 → 웰컴 이메일 시퀀스 개선 필요”
  • “고객 세그먼트 중 고가 상품군 고객의 재구매율 ↑ → VIP 전용 캠페인 기획”

🎯 2) Assistant MD (상품 기획/운영)

• 핵심 관점: 상품/프로모션 기획이 어떤 고객 행동 변화를 일으켜 매출에 기여하는가를 분석.

• 필요 역량 :

  • 매출 기여도 분석 ( 상품군 * 카테고리별 퍼널 추적 )
  • 가격/할인 전략이 고객 행동에 미치는 영향 파악
  • 기본적인 통계 실험 (t-test, 회귀분석으로 프로모션 효과 검증)

• 준비 포인트 :

  • SQL/Python으로 프로모션 참여 그룹 vs 비참여 그룹 비교 실습
  • GMV(Gross Merchandise Value), AOV(Average Order Value) 이해 및 분석
  • 상품군별 전환율 추이 분석 → 카테고리 전략 제안

• 실무 적용 예시 :

  • “할인율 20% 프로모션 참여 고객은 미참여 고객 대비 평균 객단가 +15%”
  • “카테고리 A는 전환율은 높으나 이익률 낮음 → 묶음 판매 전략 필요”

🎯 3) 데이터 분석가 / 데이터 사이언티스트

• 핵심 관점 : 단순 보고용 대시보드가 아닌 실험 설계와 인과 관계 분석을 통해 전략적 의사결정 지원.

• 필요 역량 :

  • SQL, Python (Pandas, Statsmodels, Scikit-learn)
  • AB Test 설계 및 통계적 유의성 해석
  • 코호트 분석, 서바이벌 분석(이탈 예측)
  • 마케팅/상품 데이터 모델링 (LTV 예측, 고객 세그먼트 클러스터링)

• 준비 포인트 :

  • Kaggle/공공데이터 기반으로 리텐션 예측 모델 실습
  • causal inference(인과추론), uplift modeling 개념 학습
  • Tableau/Power BI로 퍼널 & 리텐션 대시보드 제작 경험

• 실무 적용 예시 :

  • “신규 유저 온보딩 실험군의 7일차 Retention이 12%p 개선 → 정식 적용 권장”
    • “고객 세그먼트별 LTV 예측 모델링 결과, 상위 20% 고객이 매출의 70% 차지 → 집중 관리 필요”

📌 신입인 내가 준비해야 할 3가지 준비 방향.

1. 숫자만 뽑기 -> 실행 연결.

• 단순 리포팅에서 벗어나, "이 숫자들을 기반으로 어떤 실험/실행을 해야 하는가?"를 제안할 수 있어야 함

2. 비즈니스 지표 이해

• 트래픽/전환율보다 LTV, CAC, Retention, AOV, GMV 같은 수익 * 고객 가치 중심 지표에 익숙해져야 함

3. 작은 실험 경험 축적.

• 실제 프로젝트에서 AB Test나 캠페인 효과 검증을 작은 단위라도 경험 -> 포트폴리오에 녹이기

👉 즉, “디지털 애널리틱스의 종말”이란 단순 수치 보고의 종말이고, 신입에겐 오히려 실행·실험·비즈니스 연결력을 키울 기회라는 의미.

# 1) 고객만족도 결측치 채우기.
cus_satismean = df['고객만족도'].mean()
# print(cus_satismean)

df['고객만족도'] = df['고객만족도'].fillna(cus_satismean) #fillna(value) = 결측치를 특정 value로 대체.
# print(df.isnull().sum())

# 2) 근속연수 없는 직원(근속연수 결측치) 제거. 
df = df.dropna(subset=['근속연수']) #dropna() = 결측치 있는 행 제거, subset으로 특정 컬럼만 기준으로 NaN이 있는 행 자체를 제거.
print(df.isnull().sum())

# 3) 직원의 고객만족도의 4분위 중 3사분위수 값을 계산. quantile()

q3 = df['고객만족도'].quantile(0.75)
print(int(q3))

▽[데이터를 위한 Python : From Scratch to Master.] 연휴동안 인프런 강의 녹이기 : "실리콘밸리 엔지니어가 가르치는 파이썬 기초부터 고급까지"._02.

목   차

1. Primitive data type(원시 자료형)에 대해 알아보기.

2. Type error(자료형 타입 에러) 처리해보기

3. Mathmatical opertaion(수학 연산자)에 대해서 알아보기

4. f-string에 대해 알아보기

5. Conditional Expression(조건절)에 대해 알아보기

6. Multiple if Conditional Expression(복합 조건절)에 대해 알아보기

7. Logicla Operator(논리 연산자)에 대해서 알아보기

8. Randomization(임의) 모듈에 대해서 알아보기

9. 동전 앞뒤 맞추기

1. Primitive data type(원시 자료형)에 대해 알아보기.

# 04. Primitive data type(원시 자료형)에 대해 알아보기.

# Integers(정수형)
progile_number = 7216
print(progile_number)


# Floats(실수형으로 변환)
score = float(60)
print(score)

# Booleans(불리언형, 참/거짓)
is_student = True
print(is_student)


# Strings(문자열형)
dba_name = "data_forge" #따옴표 2개로 표시.
db_name = 'andamiro' #따옴표 1개로 표시.
schema_detatil ="""this shcema is about
data_forge"""  #여러줄 문자열은 큰따옴표 3개로 표시.

print(dba_name)
print(db_name)
print(schema_detatil)


# string indexing(문자열 인덱싱)
name = "data_forge"
print(name[0])
print(name[1])
print(name[2])
print(name[3])
print(name[4])
print(name[5])
print(name[6])
print(name[7])
print(name[8])
print(name[9])

# check object type (객체 타입 확인)
print(type(name))

2. Type error(자료형 타입 에러) 처리해보기

# 05. Type error(타입 오류)에 대해 알아보기.

# str + int = error
print("Hello" + 1 + "World")

• +로 연결할때는 모든 타입이 동일해야함.

• 타입을 변환해주면 + 연산이 가능해짐

# convert type (타입 변환) int to str
print(type(1))
print(type(str(1)))

print("Hello" + str(1) + "World")

3. Mathmatical opertaion(수학 연산자)에 대해서 알아보기

# 06.Mathmatical opertaion(수학 연산자)에 대해서 알아보기

print(1 + 2)
print(1 - 2)
print(1 * 2)

# /의 리턴값은 float = /(나누기 연산자)
print(1 / 2)
print(1/1)

# floor division(몫) = //(몫 연산자)
print(3//2)
print(7//3)

# Exponentiation(제곱) = **(제곱 연산자)
print(2**3)
print(3**3)

# modulo(나머지) = %(나머지 연산자)
print(60 % 13)
print(52 % 8)

• 수학 연산의 우선 순위는 PEMDAS.

# PEMDAS(수학 연산자 우선순위)
Parentheses(괄호)
Exponents(제곱)
Multiplication(곱셈)
Division(나눗셈)
Addition(덧셈)
Subtraction(뺄셈)
And Left To Right(왼쪽에서 오른쪽으로 계산)

• 연산자 축약.

  sum = 8
  

sum += 1 #sum = sum + 1 print(sum)

![](https://velog.velcdn.com/images/c_d_c/post/80a7032e-0416-4720-8938-14eea9ca2c40/image.png)



![](https://velog.velcdn.com/images/c_d_c/post/0b423158-9929-4a4f-8228-3a77df539c21/image.png)
### 4. f-string에 대해 알아보기
--- 

#07. f-string(문자열 포맷팅)에 대해 알아보기.

name = "data_forge" age = 30 print("Hello, %s" %name) #%s는 문자열 포맷팅 print("Hello, %s, you are %s years old" %(name, age)) #%s는 문자열 포맷팅, ()안에 변수를 넣어준다. print("--------------------------------") #문제는 변수를 하나씩 넣어줘야 하는 번거로움.

번거로움을 피하기 위해 {}안에 인덱스를 넣어서 하는 방법이 2.6부터 고안됨.

print("Hello, {0}, i am {1} years old".format(name, age)) #{}안에 인덱스를 넣어서 하는 방법.

print("--------------------------------")

딕셔너리를 사용하는 방법

person = {"name": "data_forge", "age": 30} print("Hello, {name}, i am {age} years old".format(name=person["name"], age=person["age"])) #format_map를 사용하여 딕셔너리를 풀어서 하는 방법. print("Hello, {name}, i am {age} years old".format(person)) #를 사용하여 딕셔너리를 풀어서 하는 방법.

딕셔너리는 키-값 쌍으로 이루어져 있기 때문에, 키를 사용하여 값을 가져올 수 있다.

print("--------------------------------")

#f-string 방법

#""앞에 f를 붙여서 사용하는 방법. 중괄호를 넣고 변수 이름을 넣으면 자동으로 할당

print(f"Hello, {name}, i am {age} years old") #f-string 방법.

![](https://velog.velcdn.com/images/c_d_c/post/126c4e75-e063-47ba-94c3-248d84246904/image.png)








![](https://velog.velcdn.com/images/c_d_c/post/0b423158-9929-4a4f-8228-3a77df539c21/image.png)
### 5. Conditional Expression(조건절)에 대해 알아보기
--- 

08. Conditional statement(조건문)에 대해 알아보기.

condition(조건절) : if, else

if 10 > 20: print("10 is greater than 20") else: print("10 is less than 20")

print("--------------------------------")

condition(조건절) : if, elif, else

if 20 > 20: print("10 is greater than 20") elif 20 == 20: print("10 is equal to 20") else: print("10 is less than 20")

print("--------------------------------")

input에 int값을 받는 condition 조건절

if int(input("How tall, are you in cm?")) > 180: print("You are over 180cm") else: print("You are under 180cm")

![](https://velog.velcdn.com/images/c_d_c/post/1fdb6e46-ef5c-4507-b900-41cd4ecf16bb/image.png)






![](https://velog.velcdn.com/images/c_d_c/post/0b423158-9929-4a4f-8228-3a77df539c21/image.png)
### 6. Multiple if Conditional Expression(복합 조건절)에 대해 알아보기
--- 

09. 복합 조건절(Multiple if Conditional Expression)에 대해서.

print("--------------------------------")

#복합 조건절 = 단일 조건절을 조합하여 사용하는 것.

my_stock = 100

if my_stock > 0: print(f"My stock, {my_stock} is greater than 0") if my_stock > 100: print(f"My stock, {my_stock} is greater than 100") if my_stock > 1000: print(f"My stock, {my_stock} is greater than 1000") if my_stock > 10000: print(f"My stock, {my_stock} is greater than 10000")

print("--------------------------------")

복합 조건문 and, or, not

#and my_stock = 100

if my_stock > 0 and my_stock <= 100: print("My stock is between 1 and 100") elif my_stock > 100 and my_stock <= 1000: print("My stock is between 101 and 1000") elif my_stock > 1000 and my_stock <= 10000: print("My stock is between 1001 and 10000") else: print("My stock is 0 or more than 10000")

print("--------------------------------")

#or

my_stock = 100

100보다 작거나, 1000보다 큰 경우

if my_stock < 100 or my_stock > 1000: print("Stock is either less than 100 OR greater than 1000") else: print("Stock is between 100 and 1000")

print("--------------------------------") #not my_stock = 100

0 이상이 아닌 경우

if not (my_stock >= 0): print("Stock is negative") else: print("Stock is zero or positive")

print("--------------------------------")

or + not

my_stock = 100

(100보다 작거나 1000보다 큰 상태)가 아닌 경우

if not (my_stock < 100 or my_stock > 1000): print("Stock is between 100 and 1000 (inclusive)") else: print("Stock is outside 100~1000 range")

![](https://velog.velcdn.com/images/c_d_c/post/718673d5-8c59-451b-b219-004c080243c3/image.png)







![](https://velog.velcdn.com/images/c_d_c/post/0b423158-9929-4a4f-8228-3a77df539c21/image.png)
### 7. Logicla Operator(논리 연산자)에 대해서 알아보기
--- 

10. Logical operator(논리 연산자)에 대해 알아보기.

value = 100

파이썬은 한 줄로 코드를 작성할 수 있지만, 여러 줄로 코드를 작성할 수 있도록 하는 방법이 있다. == \

#“이 문장이 아직 끝난 게 아니야, 다음 줄도 이어서 읽어줘” 라고 알려줘야 하는데, 그 역할을 하는 게 바로
if isinstance(value, int) and
value > 50: print("Value is an integer greater than 50") else: print("Value is not an integer or not greater than 50")

print("--------------------------------")

if not isinstance(value, float): print(f"{value} is not a float")

![](https://velog.velcdn.com/images/c_d_c/post/ad91e850-1264-4fe3-b5dd-bd2449d63548/image.png)

value = 30

파이썬은 한 줄로 코드를 작성할 수 있지만, 여러 줄로 코드를 작성할 수 있도록 하는 방법이 있다. == \

#“이 문장이 아직 끝난 게 아니야, 다음 줄도 이어서 읽어줘” 라고 알려줘야 하는데, 그 역할을 하는 게 바로
if isinstance(value, int) and
value > 50: print("Value is an integer greater than 50") else: print("Value is not an integer or not greater than 50")

print("--------------------------------")

if not isinstance(value, float): print(f"{value} is not a float")

![](https://velog.velcdn.com/images/c_d_c/post/6de86cf5-1f0f-4250-a2e4-2d497c86b11b/image.png)


![](https://velog.velcdn.com/images/c_d_c/post/0b423158-9929-4a4f-8228-3a77df539c21/image.png)
### 8. Randomization(임의) 모듈에 대해서 알아보기
--- 

11. Randomization(임의) 모듈에 대해서 알아보기.

#random module

모듈이란, 함수, 클래스, 변수 등을 미리 작성해둔 코드 묶음을 재사용 가능하게 한 단위.

import random

print(random.randint(1, 100)) #양 끝값 a와 b를 포함해서 무작위 정수를 반환

random_float = random.random() print(random_float) #0.0과 1.0 사이의 무작위 실수를 반환

![](https://velog.velcdn.com/images/c_d_c/post/2e7b24e8-323c-4f8f-9ce0-3343891f1b4f/image.png)





![](https://velog.velcdn.com/images/c_d_c/post/0b423158-9929-4a4f-8228-3a77df539c21/image.png)
### 9. 동전 앞뒤 맞추기
--- 

12. 동전 앞뒤 맞추기.

import random

random_value = random.randint(0,10)

if random_value %2 ==0: print("Head") else: print("Tail")

![](https://velog.velcdn.com/images/c_d_c/post/b04a04d1-38f4-4971-9f18-a7039c087f69/image.png)


#### 횟수 카운팅. & 확률 구하기.

30번 실행해서, Head와 Tail이 몇 번 나왔는지 카운트해서 출력하기.

import random head_count = 0 tail_count = 0

for i in range(30): random_value = random.randint(0,10) if random_value %2 ==0: head_count += 1 else: tail_count += 1

print(f"Head: {head_count}, Tail: {tail_count}")

30번 실행해서, Head가 나올 확률 구하기.

head_probability = head_count / 30 print(f"Head probability: {head_probability}")

tail_probability = tail_count / 30 print(f"Tail probability: {tail_probability}")

```

공부하면서 듣고 있는 인프런의 '실리콘밸리 엔지니어가 가르치는 파이썬 기초부터 고급까지' 강의 링크입니다.

https://inf.run/NfKUW

이 링크를 통해 구매하시면 제가 수익을 받을 수 있답니다. 🤗

▽ [데이터를 위한 Python : From Scratch to Master.] 연휴동안 인프런 강의 녹이기 : "실리콘밸리 엔지니어가 가르치는 파이썬 기초부터 고급까지".

목  차

1. 소프트웨어 엔지니어링이란??

2. 파이썬 기초 -입출력,조건절  : 26~32

1. 소프트웨어 엔지니어링이란??

• 한국에서는 흔히 '프로그래머'라고 하지만, 해외에서는 'SE(software engineer)'라고 부름.

• black box(혹은 function)에 Input 혹은 Action을 넣어서 Output 혹은 Reaction을 이끌어내는 것.

2. 파이썬 기초 -입출력,조건절 : 26~28

Print 명렁어 Hello World로 시작하기.

Print란? , ""란?

• Print는 'Function' 중의 하나.

• ""안에 들어가 있으면 문자열로 인식.

""을 활용해서 문자 사이에 띄어쓰기 넣기.

print문 안에 딕셔너리{} 를 넣을 수도 있음.

print문 안에 리스트[] 를 넣을 수도 있음.

print문 안에 튜플() 를 넣을 수도 있음.

print문 안에 숫자,소수점,불리언 값도 넣을 수 있음.

Input 명령어에 대해 알아보기.

• Input은 문자열을 파라미터로 받고, 파라미터를 출력 후에 사용자가 추가 입력을 할 때 까지 대기.

• 문자열 + input을 하게 되면, input이 먼저 실행후에 그 결과값을 가지고 문자열과 추후 출력.

len에 대해 알아보기.

• 문자열을 파라미터로 받아서, 그 문자열의 길이를 측정해서 리턴.

variable(변수)에 대해서 알아보기.

input으로 만든 값을 name이라는 '변수'에 할당을 하고, print문으로 출력.

변수명은 항상 의미있는 것으로 선언하기.

공부하면서 듣고 있는 인프런의 '실리콘밸리 엔지니어가 가르치는 파이썬 기초부터 고급까지' 강의 링크입니다.

https://inf.run/NfKUW

이 링크를 통해 구매하시면 제가 수익을 받을 수 있답니다. 🤗

▽ AI&ML_Eng : 이론 공부 : 통계학이란 무엇인가.

목   차

1. 통계학 정의와 활용

2. 기술통계와 추론통계

3. 통계학의 중요성

1. 통계학 정의와 활용

핵심 개념.

• 통계학(Statistics): 데이터를 수집, 정리, 분석하여 의미 있는 결론을 도출하는 학문.

• 분류

  • 1. 기술통계(Descriptive Statistics): 데이터를 요약·정리하여 패턴을 파악.
  • 2. 추론통계(Inferential Statistics): 표본 데이터를 통해 모집단의 특성을 추정하고 의사결정을 지원.

AI/ML·데이터사이언스 관점.

• 데이터 전처리와 탐색적 분석(EDA)의 핵심 도구

• 모델링 전에 데이터 패턴, 이상치, 분포를 이해하고 확인하는 과정에서 필수

• AI/ML 알고리즘 성능 평가에서 통계적 지표(예: p-값, 신뢰구간, 분산)를 활용

학습 포인트.

• 기술통계: 평균, 표준편차, 사분위수, 시각화

• 추론통계: 가설 검정, 신뢰구간, 표본 추출 방법 이해

• 실무 적용: AI/ML 프로젝트에서 데이터 신뢰성과 품질 검증

2. 기술통계와 추론통계

기술 통계

• 목적 : 데이터를 요약하고 이해

• 예시 : 데이터셋의 평균, 분산, 히스토그램, 상관관계

• AI/ML 적용

  • 데이터 이상치 탐지
  • Feature scaling, normalization 필요성 판단
  • EDA(Exploratory Data Analysis) 필수 과정

추론 통계

• 목적: 표본을 통해 모집단의 특성을 추정하고 가설 검정

• 예시: t-검정, 카이제곱 검정, ANOVA

• AI/ML 적용

  • 모델 성능 비교(예: 두 모델의 정확도 차이 유의성 검정)

  • 실험 설계(A/B 테스트)와 결과 해석

3. 통계학의 중요성.

이유 1: 데이터 기반 의사결정

• 데이터 분석과 모델링은 통계학적 사고 없이는 의미 있는 결과 도출 불가

• 표본, 분포, 확률 개념을 이해해야 모델 과적합/과소적합을 방지 가능

이유 2: AI/ML 모델 설계와 검증

• 회귀, 분류, 군집 등 모든 모델은 통계적 개념 기반

• 예: 선형회귀 계수 해석, 로지스틱 회귀 p-값, 신뢰구간 확인

이유 3: 실험 및 평가

• A/B 테스트, 하이퍼파라미터 튜닝, 모델 성능 평가에서 통계학적 방법 필수

• 정확도, 정밀도, 재현율, F1-score 등 지표 해석의 근거