My Flow

[python] 브루잉일지 02. 한 잔을 내리기 전: 전처리와 변수 만들기

Floaty — Sun, 2 Aug 2026 20:00:11 +0900

missing_count = df.isnull().sum()
missing_percent = (missing_count / len(df)) * 100

missing_summary = pd.DataFrame({
    '결측치 개수': missing_count,
    '결측치 비율(%)': missing_percent

})
missing_summary = missing_summary[missing_summary['결측치 개수'] > 0].sort_values(
    '결측치 비율(%)', ascending=False)

print(missing_summary)

3개의 데이터셋애 대해 각각 결측치를 확인했다. 모든 컬럼을 처리하지는 않고, 실제로 분석에 쓸 컬럼에 대해서만 의미 있게 채우거나 버리기로 했다.

결측치 현황 및 처리 방식

Coffee Quality database from CQI

                    결측치 개수  결측치 비율(%)
Lot.Number              1041    79.405034
Farm.Name                356    27.154844
Mill                     310    23.646072
Color                    267    20.366133
Producer                 230    17.543860
altitude_high_meters     227    17.315027
altitude_low_meters      227    17.315027
altitude_mean_meters     227    17.315027
Altitude                 223    17.009916
Company                  209    15.942029
Variety                  201    15.331808
Processing.Method        152    11.594203
ICO.Number               148    11.289092
Region                    57     4.347826
Harvest.Year              47     3.585050
Owner.1                    7     0.533944
Owner                      7     0.533944
Country.of.Origin          1     0.076278
Quakers                    1     0.076278

19개 컬럼에서 결측치가 발생했지만 이 중 실제로 쓸 컬럼은 `altitiude_mean_meters`, `Country.of.Origin`, `Variety` 세 개뿐이다.

`altitude_mean_meters` (결측 17.32%)

low/high 평균으로 재계산
mean이 결측인 행은 low, high도 함께 결측이라 계산 불가
Country.of.Origin별 중앙값
: 36개국 중 14개국이 표본 5개 미만, India는 표본 0개. 그룹 중앙값이 사실상 개별값과 다름없어 신뢰도가 낮음
결측행 제거
: 17%나 날아가는 건 최후의 수단으로만 남겨둠
[v] 전체 중앙값으로 대체
: max값이 190,164m로 에베레스트보다 높은 명백한 입력 오류(이상치)가 섞여 있는데 평균과 달리 중앙값은 이런 이상치에 거의 영향을 받지 않음

`Country.of.Origin` (결측 0.08%)

1건뿐이라 결측행 제거

`Variety` (결측 15.33%)

[v] `Unknown`이라는 별도 카테고리로 대체
: 품종 종류가 원래 다양해서 하나의 카테고리로 둬도 기존 분포를 왜곡하거나 정보를 잃지 않는다고 판단
최빈값 대체
: 15%를 통째로 최빈값에 몰아주면 해당 품종 비중이 실제보다 부풀려져서, 나중에 가설 검정 시 결과가 왜곡될 수 있어 기각
결측행 제거
: `altitude_mean_meters` 등 다른 컬럼과 겹치면 표본의 30%가 날아갈 수 있어 기각 (다른 대안이 전혀 없을 때만 고려할 최후의 옵션)

Coffee Reviews Dataset

      결측치 개수  결측치 비율(%)
roast       15     0.715990
desc_3       2     0.095465

`roast` (결측 0.72%)

`Unknown` 카테고리 추가
: `Dark`처럼 이미 표본이 극히 적은 카테고리가 있어서 초소형 그룹을 하나 더 만드는 건 안정성 측면에서 바람직하지 않음
[v] 결측행 제거
: 2,095행이 2,080행으로 15행만 줄어드는 수준이라 부담 없음

`desc_3` (결측 0.10%)

`desc_1` (테이스팅 노트), `desc_2`(로스터 설명), `desc_3`(한줄평)은 리뷰를 세 파트로 나눈 것. `desc_1`, `desc_2`에서 가공방식을 뽑아낼 수 있으므로 행 자체를 지우지 않고 결합 시 `fillna('')`로 처리

Consumer preference data for black coffee

            결측치 개수  결측치 비율(%)
Titration pH      84     2.636535

사용하지 않는 컬럼이라 별도 처리 없이 넘어감

파생 변수 생성과 이유

Coffee Reviews Dataset

`desc_1 + desc_2 + desc_3` 텍스트에서 가공 방식을 뽑아내는 게 이번 글에서 가장 까다로웠던 부분이다.

PROCESS_KEYWORDS = {
    'Wet-Hulled': [r'wet-hulled', r'wet hulled'],
    'Honey/Pulped Natural': [r'honey process', r'honey-processed', r'honey processed', r'pulped natural'],
    'Anaerobic': [r'anaerobic'],
    'Semi-Washed': [r'semi-washed', r'semi washed'],
    'Washed': [r'wet-processed', r'wet processed', r'\bwashed\b'],
    'Natural': [r'dry-processed', r'dry processed', r'\bnatural\b'],
}

Wet-Hulled: 인도네시아식 특수 가공법으로 덜 마른 상태에서 파치먼트를 벗겨내 건조한 것
Honey/Pulped Natural: 허니 프로세스, 과육 껌질만 벗기고 점액질은 남긴 채 건조
Anaerobic: 혐기성 발효, 밀폐 용기에서 산소를 차단한 채 발효하는 방식
Semi-Washed: 세미 워시드, 점액질을 일부만 제거하고 건조
Washed: 워시드/습식, 과육과 점액질을 물로 완전히 씻어낸 뒤 건조
Natural: 내추럴/건식, 커피 체리를 통째로 말려 과육의 당분이 원두에 스며들게 하는 방식

리뷰 데이터는 형식이 자유롭기 때문에 '워시드는 이렇던데 이 원두는 그것과 달리 세미 워시드라 좋다'같은 문장이 있으면 워시드, 세미 워시드 키워드가 둘 다 잡혀버린다. 실제 가공 방식이 아니라 비교 대상으로 언급된 것까지 걸리는 셈이라 상투적인 비교 문구를 먼저 제거해야 했다.

COMPARISON_BOILERPLATE_PATTERNS = [
    r'as is the case with wet-processed or [“"]?washed[”"]? coffees\.?',
    r'unlike (the )?(more )?typical wet[- ]?(or )?[“"]?washed[”"]? process(es|ing)?'
]

예를 들어 리뷰에 "Unlike the typical washed processing seen in many Ethiopian lots, this natural coffee shows heavy fermented fruit notes." 같은 문장이 있다면 이 원두는 실제로 natural 가공인데 washed 키워드까지 함께 잡힌다. 이런 비교 문구를 정규식으로 먼저 제거하면 washed는 사라지고 natural만 남아 실제 가공 방식만 정확히 추출된다.

리뷰 하나에서 매칭된 가공 방식 리스트를 받아 최종 라벨 1개와 신뢰도를 정한다. 이때, blend 커피는 애초에 여러 원두, 가공 방식을 섞은 것이므로 리뷰에 가공 방식이 2개 이상 나오는 게 자연스럽고 실제로 그 방식들이 다 쓰였을 가능성이 높다. 반면 blend가 아닌 (싱글 오리진 등) 커피인데 키워드가 2개 이상 잡혔다면, 실제로 여러 방식이 섞였다기보다 비교문구를 다 걸러내지 못했거나 리뷰어가 다른 커피와 비교하여 언급했을 가능성이 크다. 그래서 이 경우에는 라벨을 그대로 신뢰하기 어려워 신뢰도를 low로 잡았다.

이렇게 `desc_1+desc_2+desc_3`를 합치고 비교 문구를 제거하고 키워드 패턴을 매칭한 뒤 결과를 라벨(`processing_method`)과 신뢰도(`processing_method_confidence`)로 정리해서 `coffee_analysis_cleaned.csv`를 만들었다.

Consumer preference data for black coffee

이 데이터셋은 README에 Acidity 컬럼의 3이 '적당함'을 의미한다고 명시돼 있었다. 그래서 3을 JAR*Just About Right) 중심으로 두고 산미가 중심에서 얼마나 벗어났는지를 나타내는 변수를 만들었다.

JAR_CENTER = 3 # 산미의 JAR 중심으로부터의 편차, 
df['acidity_jar_devation'] = (df['Acidity'] - JAR_CENTER).abs()

이렇게 만든 `acidity_jar_deviation`을 포함해 `cotter_dataset_cleaned.csv`를 저장했다.

최종적으로 분석에 쓸 컬럼 확정 리스트

Coffee Quality database from CQI

`altitude_mean_meters`: 고도의 평균값 (결측치는 전체 중앙값으로 대체)
`Acidity`: 산미 점수 (0 ~ 10)
`Country.of.Origin`: 생산국 (결측치는 제거)
`Variety`: 품종 (결측치는 `Unknown`행으로 대체)
`Total.Cup.Points`: 아래 항목을 합산한 총점 (0 ~ 100)
`Aroma`, `Flavor`, `Aftertaste`, `Acidity`, `Body`, `Balance`, `Uniformity`, `Clean.Cup`, `Sweetness`, `Cupper.Points`

Coffee Reviews Dataset

`roast`: 로스팅 정도 (결측치는 제거)
`processing_method`: desc_1~3 텍스트에서 washed, natural, honey 등 가공 방식 키워드를 추출한 파생 변수
`desc_1~3`: 리뷰 텍스트 (desc_3에 대한 결측치는 제거하지 않고 `desc_1 + desc_2 + desc_3` 결합 시 `fillna('')`로 대응)
`100g_USD`: 100g 당 원두 가격
`rating`: 평점

Consumer preference data for black coffee

`Judge`: 평가자 ID, 118명
`Cluster`: 평가자 세그먼트
`Acidity`: 산미의 적정성 [1(너무 약함), 2(약간 약함), 3(적당함), 4(약간 강함), 5(너무 강함)]
`Liking`: 전반적 기호도 1 ~ 9
`Purchase.intent`: 구매 의향, 1 ~ 5
품질 속성 점수: 0/1 이진값(해당 향미가 감지됐는지 여부, 0=미감지, 1=감지)
- 긍정적 노트로 분류: `Tea.floral, Fruit, Citrus, Nutty, Dark.chocolate, Caramel, Sweet`
- 부정적 노트로 분류: `Green.veg, Paper.wood, Burnt, Bitter, Astringent, Sour, Rubber`
- 방향성이 불분명/맥락 의존적인 노트(긍/부정 미리 단정하지 않고 상관결과로 판단)
  : `Flavor.intensity, Mouthfeel, Cereal, Roasted, Thick.viscous`

이렇게 세 데이터셋의 결측치를 정리했다. 가공 방식과 JAR편차라는 파생 변수까지 만들고 나니 드디어 분석할 준비가 얼추 끝났다. 다음 글에서는 이렇게 다듬은 데이터로 실제 가설을 세우고 검증하는 과정을 다뤄볼 예정이다.

관측일지 03. 데이터를 보기 전에 질문부터 설계하기

Floaty — Thu, 30 Jul 2026 17:00:52 +0900

이벤트 설계가 필요한 이유

GA4는 검색만 잘한다고 모든 걸 알아서 잘 깔끔하게 분석해주는 도구가 아닙니다. `page_view`, `scroll` 같은 이벤트는 GA4가 자동으로 수집해주지만 '회원가입 과정 중 어디서 이탈하는지', '게시글 작성을 몇 명이나 끝까지 마치는지' 같은 질문에 답하기 위해서는 그 서비스에서만 존재하는 행동을 GA4가 이해할 수 있는 형태로 미리 정의해서 코드에 심어둬야 합니다.

선 질문 후 이벤트

그렇기에 이벤트 설계는 이벤트 이름부터 정하는 게 아니라 풀고 싶은 질문과 사용자 행동 흐름을 먼저 정의한 뒤 그 가설을 검증할 이벤트를 결정하는 순서로 진행해야 합니다.

질문 없이 이벤트부터 설계하면 방향성 없이 '일단 다 찍어보자' 식으로 태깅하게 되고 결과적으로 정작 필요한 데이터는 빠진 채 아무도 안 보는 이벤트만 잔뜩 쌓이는 경우가 많습니다. 반대로 질문이 먼저 있으면 이 질문에 답하려면 어떤 순간을 이벤트로 남겨야 하는지가 자연스럽게 정해지고, 어떤 파라미터를 같이 보내야 하는지도 함께 결정됩니다. 즉, 질문 → 가설 → 이벤트 순서를 지켜야 합니다.

예를 들어 보자면, '회원가입 과정에서 어디서 이탈하는가?'라는 질문에 대해 '입력 항목이 많아 폼 작성 중 이탈할 것이다.'라는 가설을 세우면 이 가설을 확인할 이벤트가 자연스럽게 정해집니다. `signup_page_view`에서 시작해 `signup_start`를 거쳐 `signup_complete` 혹은 `signup_error`로 끝나는 흐름입니다. 좀 더 쪼개서 보도록 하겠습니다.

`signup_page_view`: 가입 페이지에 도달
`signup_click`: '가입하기' 버튼 클릭
`signup_start`: 실제 입력 폼 작성 시작
`signup_complete`: 가입 완료
`signup_error`: 시도했지만 실패함

그렇다면 왜 이렇게 복잡하게 쪼개야할까

생각보다 복잡합니다. 하나로 뭉쳐도 될 것 같은데 굳이 5개로 쪼개는 이유가 있을 겁니다. 이유는 '어느 타이밍에서 이탈하는지'를 알아내기 위해서입니다. 이벤트를 하나로 뭉치면 가입했다/안했다라는 결과값만 남지만 여러 개로 쪼갤 경우 각 단계 사이의 전환율을 확인할 수 있습니다.

`page_view`는 많은데 `click`이 적다 → 버튼 자체가 눈에 안 띄거나 매력이 없다.
`click`은 많은데 `start`가 적다 → 폼 진입 자체에서 이탈한다.
`start`는 있는데 `complete`가 적다 → 입력 과정 자체가 길거나 번거롭다.

complete와 error를 나누는 이유

그렇다면 성공이든 실패든 `signup_start`와 세트로 `signup_end` 하나로 합치면 되지 않을까요? 이유는 앞서 단계를 쪼갠 이유와 같습니다. `signup_end` 하나로 뭉치면 가입 시도가 끝났다는 것만 알 수 있을 뿐 성공했는지 실패했는지, 실패했다면 왜 실패했는지 알 수 없습니다. `complete`와 `error`를 나누고 `error_code` 같은 파라미터를 따로 붙여야만 어떤 이유로 실패가 몰리는지를 분석할 수 있습니다. 이렇게 하면 성공률과 실패율을 각각 계산하고 실패 원인별 대응이 가능해집니다.

이벤트 네이밍 규칙

이벤트가 많아질수록 이름이 제각각 만들어지는 문제가 자주 발생합니다. 그렇기에 개인마다, 팀마다 다르겠지만 대략적으로는 다음 규칙을 따릅니다.

이벤트 이름은 영문 소문자와 `snake_case`를 사용한다.
같은 행동은 항상 같은 동사를 사용한다. ex. 클릭은 항상 `_click`
이벤트 이름만 보아도 어떤 행동인지 이해할 수 있어야 한다.
화면 이름이나 버튼 이름 자체를 이벤트 이름으로 사용하지 않는다. (파라미터의 역할을 침범함)
이벤트(무슨 행동인가)와 파라미터(어떤 조건에서인가) 역할을 구분한다.

많은 이벤트가 발생할 수 있기에 이벤트 설계 표라는 것을 만듭니다.

사용자 행동	이벤트 이름	발생 조건	파라미터	분석 목적
가입 페이지 도달	signup_page_view	가입 페이지 로드 시	-	가입 페이지 유입 수 확인
회원가입 버튼 클릭	signup_click	가입 버튼 클릭 시	button_location	가입 시도 사용자 수 확인
가입 완료	signup_complete	서버 응답 성공 시	signup_method	회원가입 전환율 확인
가입 실패	signup_error	서버 응답 실패 시	error_code	주요 실패 원인 확인

사례. 블로그 글 완독률

다음 글에서 더 많은 사례가 있겠지만 대략적으로 하나의 질문을 가져왔습니다.

질문: 사용자가 observatory 시리즈 글을 끝까지 읽을까?
가설: 글이 너무 길거나 초반 구성이 지루해서 끝까지 스크롤하지 않을 것이다.
필요한 이벤트 / 데이터
- `page_view`
- `scroll` (90% 스크롤 도달 여부)
- 평균 참여 시간
- 다음 글 링크 클릭 수
예상: 조회 수는 높은데 90% 스크롤 도달 비율은 낮게 나타남
해석
- 조회수는 높은데 스크롤 완료율이 낮다면, 글이 너무 길거나 초반에 이탈이 많을 수 있음
- 완독률은 높은데 다음 글 클릭률이 낮다면, 시리즈 간 연결이 약할 수 있음
개선 액션
- 글 상단에 목차 추가
- 글 중간에 요약 박스 추가
- 다음 편 링크를 시각적으로 강조
- 시리즈 전용 내비게이션(이전글/다음글 바) 추가

관측일지 02. GA4 화면에서 길을 잃지 않는 법

Floaty — Tue, 28 Jul 2026 17:00:16 +0900

GA4에 들어가면 왼쪽 사이드바에 큰 탭이 있어요. 각 탭 안에서는 뭘 할 수 있는지 하위 메뉴 단위로 하나씩 뜯어볼게요.

홈

최근에 본 보고서랑 GA4가 추천해주는 카드들이 모여있는 곳입니다. 깊게 파고드는 용도라기보다는 로그인했을 때 요즘 상황을 보는 정도로 쓰이는 화면입니다.

보고서

획득: 사람들이 어디서 들어왔는지
참여도: 들어와서 뭘 했는지
수익창출: 돈을 썼는지
리텐션: 다시 왔는지

이미 정해진 틀 안에서 데이터를 보는 곳입니다. 위와 같이 카테고리가 나뉘어 있고, 각 카테고리 안에 더 세부적인 리스트들이 있어요. 정해직 양식이라 빠르게 훑어보기엔 좋지만 내가 원하는 조합으로 자유롭게 보기엔 어렵습니다.

탐색

보고서가 차려진 밥상이라면, 탐색은 직접 재료를 골라서 차려먹는 곳입니다. 측정기준과 측정항목을 내가 직접 조합해서 표도 만들고 퍼널도 만들고 사람들이 사이트 안에서 어떤 경로로 움직였는지도 볼 수 있어요. 보고서보다 자유도가 훨씬 높은 대신 처음에는 좀 헤맬 수 있습니다.

내가 돈을 써서 돌리는 광고 성과를 보는 곳입니다. 애드센스처럼 내 사이트에 붙는 광고 수익과는 다른 얘기라 여기서 애드센스 수익은 보이지 않아요. 애드센스 수익은 애드센스랑 GA4를 따로 연결하면 보고서 탭의 수익 창출에서 나타납니다. 이 부분은 애드센스 승인이 난 뒤에 확인해볼 수 있을 것 같네요.

관리

데이터를 어떻게 수집하고 설정할지 만지는 곳입니다. 이벤트 등록, 외부 도구(Search Console, BigQuery, 애드센스 등) 연결, 계정 권한 관리가 다 여기서이뤄집니다.

좀 더 깊게 살펴보기

우리가 같이 봤던 5가지 탭들 중에서 보고서, 탐색 탭이 특히 중요합니다. 이 두 탭에 대해서는 조금 더 자세한 설명이 필요할 것 같아요. 너무 깊게 정리해봤자 한 번에 받아들이기엔 한계가 있을 것 같아서 러프하게나마 윤곽만 잡아볼게요.

보고서(Reports)

실시간: 지금 이 순간 사이트에 몇 명이 있고, 어디서 뭘 보고 있는지 확인
획득: 사람들이 어디서 들어왔는지. 검색이나 SNS, 직접 접속 등 유입 채널별로 확인
참여도: 들어와서 어떤 페이지, 이벤트를 얼마나 많이/오래 봤는지 확인
수익 창출: 구매나 결제 같은 매출 데이터 확인 (일반 블로그에서는 대부분 해당 없음)
리텐션: 한 번 온 사람이 다시 돌아오는지 재방문율 확인
사용자: 방문자가 어떤 살마들인지. 국가나 기기, 나이, 관심사 같은 속성 확인

탐색(Explore)

자유 형식: 측정기준, 측정항목을 원하는 대로 조합한 표/막대/선/분산형/지도 차트
유입경로 탐색 분석(퍼널): 여러 단계를 정의해 단계별 이탈율/전환율 확인
경로 탐색 분석: 특정 시작점이나 끝점을 기준으로 사용자가 실제로 어떤 이벤트/페이지 순서로 움직였는지 나뭇가지 형태로 시각화
동질 집단(코호트) 탐색 분석: 특정 기간에 처음 유입된 사용자 그룹이 이후 며칠/몇 주 뒤에도 돌아오는지 추적
세그먼트 중복: 두세 개이 세그먼트(ex. 모바일 사용자, 재방문자)가 서로 얼마나 겹치는지 벤 다이어그램으로 확인
사용자 개별화(사용자 탐색기): 익명화된 개별 사용자 한 명을 골라 그 사람의 전체 이벤트 흐름을 시계열로 확인
사용자 전체 기간(LTV): 사용자가 처음 유입된 이후 전체 기간 동안 누적 매출, 이벤트 수 등 생애 가치 분석

데이터를 어떻게 GA4까지 보낼까?

GA4 자체는 데이터를 받아서 보여주는 도구입니다. 데이터를 GA4까지 실어 나르는 방법은 크게 2가지가 있는데 이 부분이 특히 헷갈리기 쉽습니다.

Google 태그(gtag.js) 직접 설치

GA4 속성을 만들면 발급되는 스크립트 코드 조각을 사이트의 모든 페이지 `<head>` 태그에 직접 붙여넣는 방식입니다.

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');
</script>

티스토리처럼 스킨 편집기에 HTML을 직접 넣을 수 있는 블로그 플랫폼에서 흔히 쓰는 방법입니다. 위의 코드가 익숙하다면, gtag 방식을 통해 해당 사이트에 GA4를 심었다고 생각하면 됩니다.

gtag의 장점은 간단하다는 것입니다. 이걸 심어두기만 하면 되는거니까요. 하지만 단점은 새 이벤트를 추가할 때마다 코드를 직접 수정하고 재배포해야 한다는 거죠. 하루 안에 모든 세팅을 할 수 있다면 아주 큰 장점이지만, 조금씩 공부하면서 이벤트를 추가한다면 제일 귀찮은 방법입니다.

GTM (Google Tag Manager, 구글 태그 관리자)

GTM은 태그를 관리하는 컨테이너라고 생각하면 됩니다. 사이트에 GTM 컨테이너 코드를 딱 하나만 심어두면 그 안에서 GA4 태그, 다른 마케팅 태그를 코드 수정없이 웹 UI에서 추가/수정할 수 있습니다.

GTM에는 세 가지 구성요소가 있습니다.

태그: 무엇을 보낼지 ex. GA4 이벤트
트리거: 언제 발동할지 ex. 특정 버튼 클릭 시
변수: 어떤 값을 담을지

프론트엔드 개발자가 `dataLayer`라는 자바스크립트 객체에 값을 미리 담아두면 GTM이 그 값을 읽어 이벤트로 변환해 GA4로 보내는 구조가 일반적입니다.

그렇다면 언제 뭘 써야할까요?

선택지가 없다면 상관없겠지만 두 가지 중 하나를 선택해야 합니다. 이렇게 생각할 수 있을 것 같네요.

gtag: 개인 블로그나 정적 사이트 등 직접 설치로 충분한 경우
GTM: 이벤트 종류가 많아지거나(로그인, 검색, 필터링 등), 개발팀과 마케팅팀이 나눠서 태그를 관리해야 하는 서비스의 경우

화면 구조와 데이터가 실려오는 방식까지 봤으니 이제 진짜 손으로 눌러볼 차례입니다. 다음 편에서는 구글 데모 계정으로 들어가서 오늘 본 보고서 탭과 탐색 탭을 직접 만져보면서 실습해볼게요.

[python] 브루잉일지 01. 좋은 커피는 어떻게 만들어질까: 질문부터 내리기

Floaty — Tue, 28 Jul 2026 12:00:46 +0900

가설

번호	질문	가설
H1	고도가 높을수록 산미가 높아질까?	원두의 평균 고도(`altitude_mean_meters`)가 높아질수록 산미 점수(`Acidity`)도 높아질 것이다.
H2	생산국이나 품종도 영향을 미칠까?	생산국(`Country of Origin`)과 품종(`Variety`)에 따라 품질점수(`Total Cup Points`)에 유의한 차이가 있을 것이다.
H3	로스팅 정도에 따라 원두 가격은 달라질까?	로스팅 정도(`roast`)에 따라 원두 가격(100g당 가격)에 유의한 치아기 있을 것이다.
H3'	가공 방식(워시드, 네추럴, 허니 등)에 따라 원두 가격은 달라질까?	리뷰 텍스트에서 추출한 가공 방식(washed, natural, honey 등)에 따라 원두 가격(100g당 가격)에 유의한 차이가 있을 것이다.
H4	로스팅 정도에 따라 품질 평가도 달라질까?	로스팅 정도(`roast`)에 따라 평점(`rating`)에 유의한 차이가 있을 것이다.
H4'	가공 방식(워시드, 네추럴, 허니 등)에 따라 품질 평가도 달라질까?	리뷰 텍스트에서 추출한 가공 방식에 따라 평점(`rating`)에 유의한 차이가 있을 것이다.
H5	소비자는 산미가 높은 커피를 선호할까?	산미가 적정 수준(JAR 척도상 ‘딱 알맞음’)에 가까울수록 소비자의 전반적 만족도(`Liking`)가 높아질 것이다.
H6	전문가의 품질 평가와 소비자의 취향은 일치할까?	전문가의 품질 평가(산미/향미 점수)와 소비자의 만족도/구매 의향 사이에 뚜렷한 상관관계가 없을 것이다.

데이터 소개

가설을 검증하려면 생산(H1, H2), 가공(H3, H4), 소비(H5, H6) 세 단계를 각각 판단할 수 있는? {커버 말고 다른 단어} 데이터가 필요했다.

`생산 단계` - [kaggle] Coffee Quality database from CQI

H1, H2를 검증하려면 고도와 산미, 원산지, 품종, 품질 점수가 한 테이블에 있어야 하고, 이 데이터셋에는 존재하기 때문에 이 데이터를 선택했다.

`arabica_data_cleaned.csv` (아라비카 데이터셋)
`merged_data_cleaned.csv` (통합 데이터셋)
`robusta_data_cleaned.csv` (로부스타 데이터셋)

이 중 아라비카 데이터셋을 최종적으로 선택했는데 소거법을 통해 골랐다. 로부스타 데이터셋은 28행뿐이라 통계적으로 의미 있는 분석이 어렵고, 아라비카와 컬럼 체계 자체가 다르다. 통합 데이터셋은 아라비카와 로부스타를 합쳐놓은 파일인데 로부스타 쪽 컬럼 체계가 아라비카와 다르다 보니 로부스타 행 입장에서는 아라비카 관련 컬럼들이 비어버린다. 반대로 아라비카 입장에서 봐도 통합 데이터셋은 "아라비카 데이터에 로부스타라는 노이즈만 얹은 것"에 가깝다.

결국 표본 수가 충분하고 노이즈가 적은 쪽은 아라비카 데이터셋이라는 결론이 나와서, 이 데이터셋 하나로 분석을 진행하기로 했다.

`가공 단계` - [kaggle] Coffee Reviews Dataset

H3, H4를 검증하기 위한 커피 리뷰 데이터셋이다. 이 데이터셋에는 2개의 파일이 있는데 이 중 `coffee_analysis.csv`를 선택했다.

`coffee_analysis.csv`: 향미 서술이 `desc_1`, `desc_2`, `desc_3` 세 필드로 세분화되어 있어서 텍스트 분석에 유리
`simplified_coffee.csv`: 이 서술이 `review` 필드 하나로 합쳐져 있어서 세분화된 정보가 뭉개질 가능성이 있다.

정보 손실이 적은 쪽을 골랐다.

소비 단계 - [DRYAD] Consumer preference data for black coffee

H5, H6를 검증하기 위한 소비자 선호 데이터셋인데 이 데이터셋은 `cotter_dataset.csv` 하나뿐이라 별도로 고를 필요가 없다.

전체 컬럼과 각 컬럼의 뜻

세 데이터셋의 컬럼을 정리했다. 컬럼 이름만으로 뜻이 분명하지 않은 항목 특히 커핑 점수 항목들은 깃허브 레포지토리의 설명만으로는 부족해서 SCA(Specialty Coffee Association)의 커핑 프로토콜을 참고해서 뜻을 보충했고, 이렇게 보충한 설명 끝에는 표시(with SCA)를 해두었다.

생산 단계 - [kaggle] Coffee Quality database from CQI > arabica_data_cleaned.csv

이 데이터는 R로 전처리된 파일이라 컬럼명에 공백 대신 점(.)이 들어가 있어서 점을 띄어쓰기로 읽으면 된다. 컬럼 구성은 여기에서 큰 틀만 확인했고, 개별 컬럼 뜻은 저장소에 별도로 없었기에 SCA 커핑 폼을 참고했다.

품질 지표(Quality Measures)

컬럼명	설명
Aroma	향 점수, 0~10 (with SCA)
Flavor	맛 점수, 0~10 (with SCA)
Aftertaste	뒷맛 점수, 0~10 (with SCA)
Acidity	산미 점수, 0~10 (with SCA)
Body	바디감(질감) 점수, 0~10 (with SCA)
Balance	균형감 점수, 0~10 (with SCA)
Uniformity	균일성 점수 — 여러 컵 간 맛 편차가 적을수록 높음, 0~10 (with SCA)
Clean.Cup	클린컵 점수 — 잡미·결점 없이 깔끔한 정도, 0~10 (with SCA)
Sweetness	단맛 점수, 0~10 (with SCA)
Cupper.Points	커퍼(평가자)의 종합 주관 점수, 0~10 (with SCA)
Total.Cup.Points	위 항목을 합산한 총점, 보통 0~100
Moisture	생두 수분 함량(%)
Category.One.Defects	1군 결점두 개수(품질에 큰 영향)
Category.Two.Defects	2군 결점두 개수(상대적으로 영향 작음)
Quakers	덜 익은 콩 개수(로스팅 후 색이 다르게 나오는 콩)

원두 정보 (Bean Metadata)

컬럼명	설명
Species	Arabica / Robusta 종 구분
Variety	품종 (Bourbon, Caturra, Typica 등)
Processing.Method	가공 방식 (Washed/Wet, Natural/Dry, Honey 등)
Color	생두 색상

농장/생산 정보 (Farm & Origin Metadata)

컬럼명	설명
Owner / Owner.1	원두 소유자(농장주) 이름
두 컬럼은 값이 거의 동일한 중복 컬럼으로, 스크래핑 과정에서 생긴 것으로 추정
Country.of.Origin	생산국
Farm.Name	농장 이름
Lot.Number	생산 로트(배치) 번호
Mill	가공(정제)한 공장 이름
ICO.Number	국제커피기구(ICO) 등록번호
Company	유통·수출 회사명
Producer	생산자(농장주와 다를 수 있음)
Region	생산 지역(국가보다 세분화된 단위)
Number.of.Bags	포대 수
Bag.Weight	포대당 무게
In.Country.Partner	현지 품질 평가 협력기관
Harvest.Year	수확 연도
Altitude	고도 원본값(텍스트로 "1950-2200"처럼 뒤섞여 있어 계산엔 부적합)
unit_of_measurement	고도 단위(m 또는 ft)
altitude_low_meters	고도 최저값(미터로 정제)
altitude_high_meters	고도 최고값(미터로 정제)
altitude_mean_meters	고도 평균값(미터로 정제) — 분석에 사용할 컬럼

평가/인증 정보 (Grading & Certification Metadata)

컬럼명	설명
Grading.Date	커핑(품질 평가) 진행 날짜
Expiration	평가 유효기간 만료일
Certification.Body	인증기관명
Certification.Address	인증기관 주소
Certification.Contact	인증기관 연락처
Unnamed: 0	행 번호(인덱스), 분석에는 의미 없음

이 데이터에서는 `Altitude`(고도), `Species`(품종 대분류), `Country.of.Origin`, `Variety`, `Aroma`, `Flavor`, `Aftertaste`, `Acidity`, `Total.Cup.Points`를 중심으로 볼 예정이며, 나머지 컬럼은 필요할 때만 보조적으로 참고할 생각이다.

가공 단계 - [kaggle] Coffee Reviews Dataset > coffee_analysis.csv

kaggle 데이터셋 페이지의 소개를 참고해서 정리했다.

컬럼명	설명
name	원두·블렌드 이름
roaster	로스터리(판매 업체) 이름
roast	로스팅 정도 (Light, Medium-Light, Medium, Medium-Dark, Dark 등)
loc_country	로스터리가 위치한 국가(원두 생산국이 아님)
origin_1	원두의 주 원산지 국가
origin_2	원두의 보조(2차) 원산지 국가 — 블렌드일 때 존재
100g_USD	원두 100g당 가격(미국 달러)
rating	평점(대체로 80~100점대)
review_date	리뷰 작성 시점(연·월)
desc_1	리뷰 텍스트 1 — 주로 향미 프로파일 묘사
desc_2	리뷰 텍스트 2 — 원두·블렌드 소개
desc_3	리뷰 텍스트 3 — 한 줄 요약

이 데이터셋에서는 크게 두 가지를 보려고 한다. 하나는 `roast`(로스팅 정도), 다른 하나는 가공 방식 관련 향미 정보인데, 이는 별도의 컬럼으로 존재하지 않고, `desc_1~3` 리뷰 텍스트 안에서 ‘washed’, ‘natural’, ‘honey’ 같은 표현으로 섞여 있어서 텍스트를 추출하는 방식으로 접근할 예정이다.

소비 단계 - [DRYAD] Consumer preference data for black coffee > cotter_dataset.csv

이 데이터셋의 컬럼 설명은 Drayd 페이지 자체에서 README.txt 파일을 다운로드 받아서 열어보면 컬럼에 대한설명이 있는데 영어이기 때문에 한국어로 바꾸는 작업을 했다.

실험 설계 정보

컬럼명	설명
Judge	평가자(소비자) ID, 1~118
Cluster	소비자 선호 세그먼트 군집 번호(1 또는 2)
Week	실험 진행 주차(1, 2, 3주차)
Session Number	18개 테이스팅 세션 중 번호
Position	한 세션 내 시음 순서(1~10번째)

목표 브루잉 조건

컬럼명	설명
Brew	목표 브루잉 조건(온도-TDS-추출률), 예: 87-1.0-16
Temp.x	목표 브루 온도 수준(low=87℃, medium=90℃, high=93℃)
TDS.x	목표 농도(TDS) 수준(low=1%, medium=1.25%, high=1.5%)
PE.x	목표 추출률 수준(low=16%, medium=20%, high=24%)
Dose	사용한 원두 양(g)
Setting	브루어(Curtis) 장비 설정 코드
Grind	그라인더(Mahlkönig) 분쇄도 설정값

실측 추출값

컬럼명	설명
Empty Carafe	빈 서버(카라페) 무게(g)
Full Carafe	커피가 담긴 후 서버 무게(g)
Brew Mass	추출된 커피 액체의 질량(g)
TDS__1	실제 측정된 총용존고형물(TDS, %) — 굴절계로 측정
Percent Extraction	실제 추출률(%) — TDS와 브루 질량으로 계산

화학적 측정값

컬럼명	설명
pH	추출된 커피의 pH
Initial NaOH	적정 전 0.1M NaOH 부피(mL)
Final NaOH	적정 후 0.1M NaOH 부피(mL)
Titration pH	NaOH 첨가 후 최종 pH
Volume	pH 8.2에 도달할 때까지 사용된 NaOH 부피(mL) — 적정 산도 지표

온도 측정

컬럼명 설명

Brew Temperature 브루잉 완료 직후 서버 내 온도(℃)

Pour Temp 종이컵에 따른 직후 온도(℃)

90Sec Temp 따른 후 90초 뒤 온도(℃)

소비자 평가 - 전반 만족도

컬럼명	설명
Liking	소비자의 전반적 만족도(9점 척도)
Temp	온도 적정성 평가(JAR 척도: 1=너무 차가움 ~ 5=너무 뜨거움)
Flavor.intensity	풍미 강도 적정성 평가(JAR 척도: 1=너무 약함 ~ 5=너무 강함)
Acidity	산미 적정성 평가(JAR 척도: 1=너무 약함 ~ 5=너무 강함)
Mouthfeel	마우스필(질감) 적정성 평가(JAR 척도: 1=너무 묽음 ~ 5=너무 진함)
Purchase.intent	$3 가격대 구매 의향(5점 척도: 1=전혀 안 살 것 ~ 5=꼭 살 것)

소비자 평가 - 향미 노트 감지 여부 (0/1)

컬럼명	설명
Tea.floral	차·꽃 향 감지 여부
Fruit	과일 향 감지 여부
Citrus	시트러스 향 감지 여부
Green.veg	풋내·채소 향 감지 여부
Paper.wood	종이·나무 향 감지 여부
Burnt	탄내 감지 여부
Cereal	곡물 향 감지 여부
Nutty	견과류 향 감지 여부
Dark.chocolate	다크초콜릿 향 감지 여부
Caramel	카라멜 향 감지 여부
Bitter	쓴맛 감지 여부
Astringent	떫은맛 감지 여부
Roasted	로스팅(탄) 향 감지 여부
Sour	신맛 감지 여부
Thick.viscous	걸쭉함 감지 여부
Sweet	단맛 감지 여부
Rubber	고무 냄새 감지 여부(결점 향)

분석방향

비교하는 두 대상이 어떤 성격의 데이터인지 - 숫자형(연속형) vs. 범주형
그 성격에 맞는 통계 검정 방법이 무엇인지
숫자 ↔ 숫자(상관분석): 하나가 커지면 다른 것도 같이 커지는 가에 대해서 -1 ~ 1 사이의 숫자로 확인
범주 ↔ 숫자(t검정/ANOVA): 그룹별로 평균이 다른가에 대해서 그룹이 2개면 t-검정, 3개 이상이면 ANOVA
범주 ↔ 범주(카이제곱검정): 두 범주가 서로 관련이 있는가에 대해서 확인
결과를 어떤 그래프로 보여줄지
숫자 ↔ 숫자(산점도): (목적) 관계의 방향과 강도를 보는 것 점들이 우상향/우하향으로 몰려있는지만 봐도 관계가 있는지 바로 확인 가능
범주 ↔ 숫자(박스플롯/막대그래프): (목적) 그룹별 평균 차이를 보는 것 박스플롯으로 평균, 그룹 내 값이 얼마나 퍼져 있는지까지 볼 수 있어서 얼마나 다른지 판단 가능
범주 ↔ 범주(누적 막대그래프/히트맵): (목적) 두 범주의 조합이 얼마나 자주 나타나는지를 보는 것 비율을 쌓아 보여주는 막대그래프나 색 농도로 표현한 히트맵이 조합 빈도 차이 확인 가능

가설	비교컬럼	성격	방법
H1: 고도 ↔ 산미	`altitude_mean_meters`↔ `Acidity`	숫자 ↔ 숫자	상관분석 + 산점도
H2: 생산국/품종 ↔ 품질	`Country` / `Variety`↔ `Total.Cup.Points`	범주 ↔ 숫자	ANOVA + 박스플롯
H3: 로스팅 ↔ 가격	`roast`↔ `100g_USD`	범주 ↔ 숫자	ANOVA + 박스플롯
H3’: 가공 공정 ↔ 가격	`desc_1~3`↔ `100g_USD`	범주 ↔ 숫자	ANOVA/t-검정 + 박스플롯
H4: 로스팅 ↔ 품질	`roast`↔ `rating`	범주 ↔ 숫자	ANOVA + 박스플롯
H4’: 가공 공정 ↔ 품질	`desc_1~3`↔ `rating`	범주 ↔ 숫자	ANOVA/t-검정 + 박스플롯
H5: 산미 ↔ 소비자 선호	`Acidity`↔ `Liking`	범주(JAR: 1~5등급) ↔ 숫자	상관분석 or ANOVA + 산점도/박스플롯
H6: 전문가 vs. 소비자	두 데이터셋 비교	직접 비교 불가	각자 분포 비교 후 탐색적 서술

H6은 두 데이터셋이 애초에 같은 표본을 대상으로 한 게 아니라서 통계적으로 딱 떨어지게 검정하기는 어렵지만 전문가 점수 분포와 소비자 만족도 분포를 나란히 놓고 경향이 비슷한지 살펴보는 탐색적 비교로 접근할 생각이다.

관측일지 01. 왜 조회수만 보면 안 될까?

Floaty — Mon, 27 Jul 2026 17:00:05 +0900

GA4를 공부하게 된 이유

솔직히 GA4라는 이름, 어디선가 한 번쯤을 들어보셨을 거예요. 구글에서 관련 자격증까지 만들었고, 서점에 가도 GA4를 다루는 책이 꽤 여러 권 꽂혀 있어요. 근데 막상 "그래서 이게 뭔데?"라고 물으면 딱 떨어지게 대답하기가 쉽지 않습니다. "그 외 그거 있잖아 이탈율" 이것 말고는 딱히 GA4를 표현할 말을 찾지 못했어요.

그래서 궁금해졌습니다. 이 GA4라는 건 대체 누구고, 왜 다들 공부하라고 하는걸까? 그리고 이걸 배우면 실질적으로 어떠한 것을 할 수 있을까? 이 질문에 답을 찾아가는 과정을 하나씩 기록해보려고 합니다.

관측일지는 GA4에 대해서 알아본 뒤 애널리틱스 데모 계정을 통해 시도해보고, 미리 이 블로그에 심어둔 GA4를 분석하는 순서로 진행 될 예정입니다.

GA4의 기본 개념과 이벤트 기반 구조

일단 GA4(Google Analytics 4)가 누구인지부터 알고 넘어가야겠어요. 한 줄로 정리하자면, 웹 사이트와 앱에서 사용자가 어떻게 행동하는지를 하나의 데이터 모델로 모아서 보여주는, 구글의 무료 분석 도구입니다.

기존에는 UA(Universal Analytics)라는 서비스가 따로 있었는데, 2023년 7월에 서비스가 종료되면서 지금은 GA4만 남았습니다. Mixpanel이나 Amplitude처럼 GA4를 대신할 도구가 존재하긴 하지만 무료로 웹앱 기본 분석을 하고 싶다면 GA4가 유일한 선택지이긴 합니다.

GA4를 공부하다 보면 계속 등장하는 용어가 5개 정도 있습니다. '측정기준을 추가하세요'라거나 '측정항목을 골라보세요' 같은 말이 화면 곳곳에 등장합니다. 그렇기에 이 용어들을 먼저 정리하고 가는 게 좋을 것 같아요.

이벤트(Event) - 사용자가 한 행동

페이지를 보거나 버튼을 누르고, 스크롤을 내리고, 구매를 하는 등에 대한 것도 GA4에서는 전부 '이벤트'라는 하나의 개념으로 묶입니다. `page_view`, `click`, `scroll`, `purchase` 모두 다 이벤트죠. 페이지 하나 보는 것까지 이벤트라고 부르는 게 좀 낯설 수 있지만, 사용자가 어떠한 액션(action)을 취했다.싶으면 다 이벤트라고 생각하면 이해하기에 쉬울 것 같네요.

ex. `page_view`, `scroll`, `purchase`

매개변수(Parameter) - 이벤트에 딸려오는 부가정보

이벤트만으로는 부조간 정보를 옆에서 살짝 붙여주는 역할을 합니다. `page_view`라는 이벤트가 '페이지를 봤다'는 사실만 알려준다면, 매개변수를 통해서 어떤 페이지인지에 대한 부가정보를 볼 수 있어요. 페이지 제목이나 페이지 주소 등을 답해줘요. 이벤트가 무슨 일이 일어났는지를 설명한다면, 매개변수는 그 일이 어떤 조건에서 일어났는지를 채워주는 겁니다.

ex. `page_view`의 `page_title`, `page_location`

사용자 속성(User Property) - 사람 자체에 계속 붙는 정보

이벤트나 매개변수가 그 순간 한 번 일어난 행동에 대한 정보라면, 사용자 속성은 세션이 바뀌고 페이지를 몇 번을 옮겨 다녀도 그 사람한테 계속 붙어있는 정보를 말합니다. 예를 들어 누군가 '프리미엄 회원'이 됐다면, 그건 한 번의 클릭으로 갑자기 생긴 게 아니라 여러 번의 구매와 활동이 쌓여서 만들어진 상태죠. 이렇게 한 사람을 계속 따라다니는 정보다 싶으면 사용자 속성으로 봐야 해요.

ex. 로그인 여부, 선호 언어, 회원 등급

측정기준(Dimension) - 데이터를 무엇으로 쪼개볼지

같은 숫자라도 어떤 기준으로 쪼개보느냐에 따라 완전히 다른 이야기가 나옵니다. 방문자 수를 국가별로 쪼개보면 한국에서는 이만큼, 일본에서는 저만큼 오는지가 보이고, 기기별로 쪼개면 PC, 태블릿, 모바일 중 어디서 많이 들어오는지가 보입니다. 이렇게 기준을 나누는 이유는 결국 우선순위를 정하기 위해서예요. 모바일 사용자가 압도적으로 많다면, 반응형 작업도 모바일부터 신경 써야 한다는 뜻이 되니까요.

ex. 국가, 채널, 기기 카테고리

측정 항목(Metric) - 실제 숫자값

측정기준이 '어떻게 쪼갤지'를 정하는 거라면, 측정항목은 그렇게 쪼개진 다음 실제로 보게 되는 숫자를 의미합니다. GA4에서 자주 보게 될 측정항목으로는 조회수, 활성 사용자 수, 참여율, 평균 참여 시간, 전환율 같은 게 있어요. 음.. 가장 많이 들어본 이탈률로 예시를 들어볼게요. '이탈률'이라는 측정항목을 보면 사용자가 언제쯤 사이트를 떠나는지를 수치로 확인할 수 있어요. 결국 측정기준으로 쪼개고, 측정항목으로 그 결과를 숫자로 확인하는 겁니다.

ex. 조회수, 활성 사용자 수, 전환율

정리를 한 번 해볼게요. 어떤 기준으로 쪼개서(측정 기준) 무슨 숫자를 볼지(측정항목)를 고른다고 생각하면 이 둘은 비교적 쉽게 이해할 수 있어요. 문제는 이벤트와 매개변수, 사용자 속성입니다. 이 셋은 공부하다보면 자꾸 헷갈려요. 그래서 코드로 어떻게 구분되는지 한 번 보도록 할게요. gtag가 정확히 뭔지는 나중에 다룰 예정이지만, 지금은 코드 모양만 봐주세요.

gtag("event", "signup_complete", {
	signup_method: "email",
	page_location: "/signup",
	user_type: "new",
});

여기서 `signup_complete`가 이벤트이고, `signup_method`, `page_location`, `user_type`은 이 이벤트에 딸린 매개변수입니다. 그 행동(event)이 어떤 상황에서 일어났는지를 설명해주는 부가 정보이죠.

gtag("set", "user_properties", {
	membership_level: "premium",
	is_subscribed: true,
})

반면 사용자 속성은 이벤트 하나에 딸려오는 게 아니라, 그 사람 자체에 계속 붙어다니는 정보입니다. 이렇게 회원 등급이나 구독 여부 같은 걸 이벤트와는 별도로 설정해요.

이벤트는 코드에 'event'라고 명시되니까 구분이 쉬운데, 매개변수와 사용자 속성은 어떻게 구분해야 할까요? 기준은 생각보다 간단합니다.

이 정보가 이번 행동 하나만 설명하는가?
- Yes(파라미터),
- No(사용자 속성)
여러 이벤트와 세션에 걸쳐 계속 유효한가?
- Yes(사용자 속성)
- No(파라미터)

이 질문에 따라서 `signup_method`는 이번에 어떤 방식으로 가입했는지이기 때문에 이번 행동 하나만 설명하므로 매개변수이고, `membership_level`은 어느 한순간 갑자기 프리미엄이 된 게 아니라 여러 이벤트가 쌓여서 만들어진 상태니까 사용자 속성인거죠.

그럼 `user_type: "new"`는 여기서 뭘까요? 이건 좀 애매합니다. '가입하는 시점의 상태'만 보고 싶다면 매개변수로 충분하지만, 이 사람이 나중에도 계속 신규/기존 여부에 따라 행동이 달라지는지 추적하고 싶다면 사용자 속성으로 따로 등록하는 게 맞죠.

그럼 용어 정리가 끝났으니 이벤트의 종류를 나눠보도록 할게요. 이걸 구분하지 못하면 '내가 직접 이벤트를 만들어야 하나, 아니면 있는 걸 써도 되나'하는 물음표가 계속 돌아다니게 됩니다.

자동 수집: 태그만 심으면 설정 없이 자동으로 잡힘 ex. `session_start`, `first_visit`
향상된 측정: 관리 탭에서 스위치만 켜먼 자동으로 잡힘 ex. `scroll`, `outpound_click`, `page_view`
추천 이벤트: 구글이 이름과 규격을 미리 정해둔 걸 직접 코드에 심음 ex. `add_to_cart`, `purchase`
맞춤 이벤트: 내 서비스에만 필요한 걸 완전히 자유롭게 이름 붙여서 만듦 ex. `floaty_click`

조회수 외에 확인할 수 있는 데이터

그럼 GA4로 대체 어디서부터 어디까지 볼 수 있을까요? 같은 GA4라고 해도 개인 블로그에서 쓸 때랑 넷플릭스급 서비스에서 쓸 때는 완전히 다르겠죠. 그래서 가장 작은 것부터 가장 큰 것까지 한 번 나열해봤어요.

티스토리 글 하나에 '몇 명이 봤는지' 조회수 확인하기
어떤 시리즈 글이 재방문을 부르는지, 어느 SNS 링크가 효자인지 채널별로 쪼개보기
커스텀 이벤트로 '글을 끝까지 읽었는지'까지 정의해서 전환으로 등록하고 BigQuery로 원본 데이터를 SQL로 직접 조회하기
수백만 사용자의 실시간 행동 데이터를 기반으로 추천 알고리즘이나 A/B 테스트, 개인화 전략을 실시간으로 조정하기

저는 일단 가장 사소한 것부터 시작해서 할 수 있는 만큼 큰 것까지 시도해보려고 합니다. 방금 언급한 BigQuery 외에도 Looker Studio라는 도구가 하나 더 있습니다. 세트 메뉴처럼 같이 등장하는 녀석들이니 이 셋의 관계를 정리해볼게요.

GA4: 데이터 수집 + 기본적인 보고서 / 탐색 분석
Looker Studio: GA4 데이터를 예븐 대시보드로 시각화
BigQuery: GA4의 가공되지 않은 원본 이벤트 데이터를 SQL로 직접 조회

티스토리 데이터로 알아보고 싶은 질문

개념은 어느 정도 잡혔으니, 이제 이 블로그 데이터로 뭘 확인해보고 싶은지 적어볼게요.

조회수는 높은데, 실제로 끝까지 읽은 사람은 얼마나 될까?
시리즈물로 쓴 글, 첫 편을 본 사람 중 마지막 편까지 따라오는 사람은 몇 명이나 될까?
어떤 채널로 들어온 사람이 다시 찾아올 확률이 높을까? (검색 vs. SNS)
카테고리별로 글 하나당 평균적으로 얼마나 머무를까? 편수가 많다고 꼭 오래 읽는 건 아닐 것 같은데

이 질문들에 대한 답은 나중에 실제 데이터를 열어보면서 하나씩 확인해볼 생각이에요. 다음 편에서는 이 개념들을 들고 GA4 화면 구조부터 하나씩 뜯어볼게요.

KB국민은행 IT부문 하계 체험형 인턴십 지원 후기 | AI 면접 KB다움

Floaty — Sat, 25 Jul 2026 22:35:05 +0900

어쩌다 KB국민은행에 지원하게 되었을까

사실 KB국민은행에서 인턴을 뽑는 줄도 몰랐다. 부트캠프 매니저님께서 “한 번 경험 삼아 지원해보세요.”라고 추천해 주셨고, 마침 그렇게 바쁜 시기도 아니어서 한 번 시도해보기로 했다.

그런데 문제가 하나 있긴 했다. 고등학교 3학년 때의 나는 글쓰기에 정말 재능이 1도 없다는 사실을 깨달았고, 당시에는 지금처럼 AI가 글을 함께 다듬어주는 시대도 아니었다. 그래서 자기소개서가 필요했던 학생부종합전형에는 아예 지원하지 않았다. 전공을 컴퓨터로 정한 뒤에도 긴 글을 작성할 일은 거의 없었다. 프로그래밍을 배웠으니 코드를 설명하는 문서나 프로젝트 기록은 작성했지만, 나 자신을 800자나 1,200자 안에 녹여내는 글은 처음이었다. 개발자를 준비하면서도 자기소개서보다는 포트폴리오가 더 중요하다고 생각했기 때문에, 제대로 된 자기소개서를 작성해본 적은 한 번도 없었다.

그래서 이번 지원은 합격보다는 처음으로 자기소개서를 써보는 경험 자체에 의미를 두기로 했다. 물론 붙으면 기분이 날아갔겠지만...

생각보다 지금까지 살아오면서 겪은 일이 꽤 많았기 때문에 자기소개서에 녹일 이야기는 많았다. 학과 동아리부터 부트캠프, 아르바이트 형식으로 잠깐 일했던 회사까지 이것저것 다양한 경험을 했다. 흠.. 굴곡이라고 하면 보통 올라갔다 내려갔다 해야 할 것 같은데, 나는 올라간 기억보다 내려간 기억이 더 많기는 하다. 그래도 덕분에 자기소개서에 쓸 이야기는 정말 많았다.

전체적인 방향은 금방 잡았다. 다만 한 번 정도는 거의 처음부터 다시 쓰는 수준으로 크게 갈아엎었다. 그 이후에는 만들어둔 내용을 기둥으로 삼아 KB국민은행에 맞는 경험이나 내용을 한두 가지씩 추가하는 정도로 마무리했다. 결과적으로 합격하지는 못했지만, 이번 지원을 통해 자기소개서의 뼈대 하나는 만들어두었다. 다음에 다른 기업에 지원하더라도 완전히 처음부터 시작하지 않아도 된다는 점에서는 나름 수확이 있었던 경험이었다.

지원서는 어떻게 작성했을까

세상 사람들이 다른 사람의 지원서를 궁금해하는 건 보통 합격자의 지원서일 것이다. 나는 이렇게 작성해서 떨어졌으니, 정답이라기보다는 "이 사람은 이런 방향으로 작성했는데 떨어졌구나" 정도로 보면 될 것 같다.

지원서에는 총 네 개의 문항이 있었다.

지원 동기와 인턴십 목표

KB국민은행 IT부문 하계 체험형 인턴십에 지원한 동기와, 인턴십을 통해 이루고자 하는 목표를 구체적으로 작성해 주시기 바랍니다.

첫 번째 문항에서는 왜 여러 기업 중 KB국민은행이어야 하는지, 그리고 인턴십을 통해 무엇을 얻고 싶은지를 구체적으로 보여주려고 했다. 나는 스타트업에서 개발과 QA 업무를 함께 맡았던 경험을 중심으로 작성했다. 사용자가 실제로 서비스를 이용하는 과정에서 발생하는 불편함을 발견하고 개선했던 경험을 이야기한 뒤, 많은 사용자가 이용하는 금융 서비스에서는 작은 오류나 불편도 신뢰와 연결될 수 있다고 생각했다는 점을 담았고, 인턴십을 통해 이루고 싶은 목표는 두 가지로 정리했다. 첫 번째는 대규모 금융 서비스가 기획되고 개발되고 운영되는 전체 과정을 경험하는 것, 두 번째는 안정성과 사용자 편의성을 함께 고려하는 개발자로 성장하는 것이었다.

정리하면 이 문항의 핵심은 다음과 같았다.

왜 KB국민은행의 IT 부문인지
기존 경험이 지원 동기와 어떻게 연결되는지
인턴십을 통해 구체적으로 무엇을 배우고 싶은지

새로운 시도를 통해 문제를 해결한 경험

기존 방식에서 벗어나 새로운 시도를 통해 문제를 해결하거나 성과를 창출한 경험을 작성하고, 그 과정에서 본인이 구체적으로 어떻게 행동하였는지와 그 결과를 작성해 주시기 바랍니다.

두 번째 문항에는 스타트업에서 QA 프로세스를 직접 만들었던 경험을 작성했다. 당시에는 기획서도 없었고, 기존 QA 프로세스도 없었다. 노션에 간단한 서비스 설명서만 있었는데, 실제 서비스와 다른 내용도 있었다. 기준이 생길 때까지 기다리기보다는 직접 검증 기준을 만들기로 했다. 서비스를 파악하는 이틀 동안 버그 28건, 개선사항 11건, 설명서 오류 3건을 발견해 공유했고, 이후에는 구글 스프레드시트로 QA 시트를 만들어 기능별 테스트 케이스와 예외 상황을 정리했다.

이 문항에서는 단순히 "열심히 했습니다."를 말하는 것이 아니라

기존 방식으로 해결하기 어려웠던 이유
새로운 방법을 선택한 이유
내가 실제로 어떤 행동을 했는지
그 결과 무엇이 달라졌는지

를 보여주는 데 집중했다.

부족함을 인지하고 개선한 경험

본인의 실수나 부족함을 인지한 이후 대처한 경험을 구체적으로 작성하고, 그 과정에서 얻은 교훈도 함께 작성해 주시기 바랍니다.

세 번째 문항에는 웹 접근성을 제대로 고려하지 못했던 경험을 작성했다. 개발을 처음 시작했을 때는 화면이 원하는 대로 동작하면 좋은 코드라고 생각했다. 마크업도 화면을 구성하기 위한 수단 정도로만 여겼다. 그러다 웹 접근성 특강을 들으면서 키보드만으로 서비스를 이용하는 사용자, 화면의 구조와 이미지 설명이 필요한 사용자도 있다는 사실을 알게 됐다. 내가 작성한 코드가 누군가에게는 불편함이 될 수 있다는 점을 깨달은 뒤, 페이지 구조와 이미지 설명, 페이지별 제목 등을 고려하기 시작했다. 관련 도구와 라이브러리를 활용해 사람이 놓칠 수 있는 부분도 보완하려고 했다.

이 문항에서는 실수 자체보다는

어떤 부족함을 발견했는지
그 사실을 알게 된 뒤 어떻게 행동했는지
이후 개발 방식이 어떻게 달라졌는지

를 중심으로 작성했다.

서로 다른 관점을 가진 사람들과 협업한 경험

다양한 배경이나 의견을 가진 사람들과 협업하는 과정에서 갈등을 극복하거나 시너지를 창출한 경험을 작성해 주시기 바랍니다.

마지막 문항에는 졸업 프로젝트에서 디자인 팀원들과 협업했던 경험을 작성했다. 개발팀은 유저 플로우를 버튼 클릭과 페이지 이동 같은 상호작용 중심의 흐름으로 생각했다. 반면 디자인 팀원들은 페이지 단위의 화면 전개 흐름으로 이해하고 있었다. 처음에는 결과물이 잘못 전달된 줄 알았지만, 이야기를 나누다 보니 같은 단어를 사용하면서도 서로 전혀 다른 의미로 이해하고 있다는 사실을 알게 됐다. 이후 개발 관점의 플로우를 직접 작성해 공유했고, 디자인 팀원들은 사용자 경험 관점에서 흐름을 보완했다. 두 관점을 함께 비교하는 과정에서 특정 페이지 사이에 무한루프가 발생할 수 있다는 문제도 발견해 개발 전에 수정할 수 있었다.

이 문항에서는 단순히 "팀원들과 잘 협업했습니다."라고 작성하는 대신

서로의 관점이 어떻게 달랐는지
그 차이를 어떻게 발견했는지
내가 중간에서 어떤 역할을 했는지
협업을 통해 어떤 결과를 만들었는지

를 보여주려고 했다.

서류를 제출했더니 KB다움을 하라고 했다

서류 제출 마감은 2026년 6월 24일 오후 5시였다. 어찌저찌 지원서를 제출하고 결과를 기다리고 있었는데, 서류 발표도 나기 전인 6월 26일에 연락이 왔다. KB다움 검사를 6월 29일까지 완료해달라는 안내였다.

처음에는 이게 붙었다고? 내가 붙으면 비리 아닌가? 싶었다. 하지만 서류 합격 여부와 관계없이 지원자 모두가 진행하는 전형이었다.

KB다움

이건 정말 할 말이 너무 많다.

생각할 시간이 아니라 읽은 시간이 부족했던 인성검사

인성검사는 다섯 개의 선택지 중 하나를 고르는 방식이었다. 그런데 문제는 생각할 시간이 부족한 게 아니라 읽을 시간이 부족했다는 것이다.문장을 다 읽기도 전에 선택해야 했다. 아무리 짧은 문장이라도 읽고 뜻을 받아들이는 데는 시간이 필요한데, 그러거나 말거나 남은 시간은 점점 줄어들었다. 시간 표시가 빨간색으로 변하면 그때부터는 더 조급해졌다. 나는 아직 내용을 제대로 이해하지도 못했는데 뭘 골라야 하는지 모르겠고, 시간은 계속 줄어들고 있고. 인성을 검사하기 전에 읽기 속도를 검사받는 기분이었다.

게임이라고 하기에는 재미가 없었던 게임형 검사

그다음은 게임형 검사였다. 차라리 42서울 라피신에 들어가기 전에 했던 게임형 시험이 더 재미있었다. 이건 게임이라기보다는 그냥 검사에 가까웠다. 게임이라는 단어에는 최소한 재미가 조금이라도 포함되어 있어야 하는 것 아닌가. 그런데 이건 무슨 능력을 확인하려는 건지도 잘 모르겠고, 재미도 없고, 감동도 없었다. 그냥 검사 그 자체였다. 게임의 정의를 다시 생각해봐야 할 것 같다.

블로그 후기 작성자들에게 배신당한 면접

마지막은 면접이었다. 솔직히 나는 서류에서도 떨어질 거라고 예상했다. 내 경험이 에베레스트를 등반했다거나, 세상을 뒤흔든 서비스를 만들었다거나 하는 대단한 경험은 아니었다. 대부분은 누구나 비슷한 환경에 놓이면 겪을 수 있는 사소한 문제에서 시작된 경험이었다. 이러니 내가 붙으면 비리라고 생각했지.

그래도 ‘면접’이라는 단어에서 오는 무서움이 있지 않은가. 아마 이 글을 찾아본 사람도 면접이 무서워서 여기까지 읽고 있을 것이다. 나도 마찬가지로 여러 블로그 후기를 찾아봤다. 대부분 면접 질문이 3개에서 5개 정도라고 적혀 있었다.

이 글은 전체 과정을 순서대로 작성하고 있지만, 실제로는 가장 긴장되는 면접부터 먼저 진행했다. 어차피 세 가지 검사 중 원하는 순서대로 할 수 있었고, 정신이 갈릴 거라면 가장 무서운 것부터 끝내자는 생각이었다.

그런데 나는 블로그 글을 써준 누군가에게 큰 배신을 당했다. 질문은 3개에서 5개가 아니었다. 11개였다. “에이, 어차피 서류에서 떨어질 텐데. 그냥 경험이라고 생각하자.” 라는 마음으로 가볍게 시작했지만, 예상보다 정신이 훨씬 많이 갈렸다. 기억나는 질문만 적어보면

지원 동기
내가 가장 중요하게 생각하는 가치
나의 장점과 단점
KB 서비스에서 개선하고 싶은 점
부당한 지시를 받는다면 어떻게 할 것인지
팀 프로젝트에서 힘들었던 경험
마지막으로 하고 싶은 말

이 외에도 질문이 더 있었다. 중간쯤부터는 이미 정신이 탈탈 털렸다. 검사 사이에 쉬는 시간은 가질 수 있었지만, 혹시라도 창이 꺼질까 무서워 노트북 앞을 떠나지는 못했다. 그렇다고 그냥 나갈 수도 없었다. 나가면 그대로 전형이 종료된다고 했다. 그래도 여기까지 해냈는데 엔딩이라도 봐야지 싶었다. 새벽에 시작해서 그런지 너무 졸려 하품을 오천만 번 정도 한 것 같기는 하다. 영상에 전부 찍혔겠지.

결과

앞서 말했듯 나는 떨어졌다. 그런데 결과가 나온 과정도 조금 웃겼다. 나는 최종 결과가 7월 10일에 한 번에 나오는 줄 알았다. 그런데 7월 3일에 서류 결과가 먼저 발표됐다. 결과는 서류 탈락. 그런데 이렇게 금방 서류 결과가 나올 예정이었다면, 그냥 서류 합격자만 KB다움 검사를 진행하면 되는 것 아닌가? 뭔가 대학교 성적을 확인하기 위해 강의 평가를 먼저 작성해야 하는 기분이었다. 그나마 강의 평가는 내가 평가하는 입장이고 금방 끝나기라도 한다. KB다움은 길고, 힘들고, 면접까지 해야 했다. 다음에는 그냥 서류 합격자만 KB다움을 진행하면 좋을 것 같다. 물론 이 의견이 반영되려면 KB국민은행 관계자가 이 글을 봐야 할 텐데. 안 보겠지.

결과는 7월 초에 나왔지만 이러저러한 현생 이슈 때문에 글은 이제야 등장했다. 그래도 기록했으니 다행이다.

정신없던 두 달, 새싹 중간평가까지

Floaty — Sat, 25 Jul 2026 17:00:40 +0900

지금까지 있었던 일

새싹을 시작하면서 다짐한 게 하나 있었다. 이번에는 기술 블로그를 다시 꾸준히 해보자. 그래서 새싹 2주 차 즈음에 블로그를 만들고 글도 하나 둘 작성하기 시작했다. 그런데 정신 차려보니 중간평가가 끝난 지도 벌써 2주가 넘어가고 있다. 물론 TIL이나 WIL을 작성할 생각이 없긴 했다. 그렇다고 두 달 동안 새싹 이야기를 하나도 안 적을 생각도 아니었는데, 블로그에 중간중간 들어오긴 했어도 이 정도면 새싹 다니는 줄도 모를 것 같았다.

그래서 늦었지만 그동안 있었던 이야기를 한 번 정리해보려고 한다. 2주차부터 지금까지 정말 많은 일들이 있었다.

가장 먼저 있었던 일은 노로바이러스. 새싹 4주차 즈음에 갑자기 노로바이러스에 걸려서 일주일 동안 수업을 통째로 쉬게 됐다. 굴도 안 먹었고 회도 안 먹었는데 노로바이러스에 걸릴 수 있다는 걸 그때 처음 알았다. 억울하긴 했지만 그래도 다행인 건 빠진 기간 동안 Git/GitHub 특강, 데이터 모델링, 현업자 특강이 진행됐다는 점이다. 대부분 한 번쯤 접했던 내용이라 일주일을 쉬었음에도 괜찮았다.

호랭이가 담배 피우던 시절에 배웠던 파이썬만 기억에 남아서 걱정했었는데 정자스민의 스터디로 하게 된 Flask도 새록새록 기억나고 꽤 괜찮았다. 걱정했던 게 파이썬뿐이었지만 사실상 아니었던 것이었다. 개인적으로 크게 힘겨웠던 세 번의 순간이 있었다.

첫 번째는 통계였다. 사전 강의를 통해 미리 배우긴 했지만 솔직히 말하면 '어디선가 들어본 적은 있음' 정도의 상태였다. 3일 안에 통계를 끝내는 수업이라고 해서 쉽지 않을 것 같다고 예상했는데 예상보다 훨씬 더 쉽지 않았다.

두 번째는 matplotlib였다. 특정 컬럼을 통해서 막대그래프를 그리라고 하면 할 수 있지만 데이터를 하나 던져주고 여기서 적절한 그래프를 선택해서 그려보라고 하면 머리가 멈춘다. 아니 내가 뭘 알아야 그리죠...? AI한테 코드 좀 짜달라고 해도 그 코드가 왜 그렇게 생겼는지도 모르겠고, 왜 하필 그 그래프를 선택했는지도 모르겠고, 결국 그래프를 그리는 것보다 왜 그 그래프를 선택해야 하는지를 이해하는 과정이 훨씬 어려웠다.

그래도 그나마 다행인 건 모든 과목이 그렇게 어렵지는 않았다. 크롤링은 HTML을 알고 있어서 생각보다 금방 적응했고, 머신러닝도 코딩테스트를 준비하면서 알고리즘에 대해 왜?라는 질문을 던지지 않고 그냥 그런 것.이라는 방식으로 공부했었기에 크게 힘들지는 않았다. 딥러닝부터는 조금씩 정신을 놓기 시작했다. 머신러닝, 신경망, 딥러닝 순으로 배웠는데 신경망부터는 한 번 놓치면 계속 놓치는 느낌이었다. 그래서 그런지 아직 딥러닝도 쉽지 않았다.

그러다가 중간평가를 봤다. 오전에는 코딩 테스트(인 듯 아닌 코드 치는 시험)를 보고, 오후에는 한 명씩 돌아가면서 이야기를 나누는 시간이었다. 거창하게 말하면 면접이지만 실제로는 취업 의지나 수업에 대한 이야기를 나누는 시간에 더 가까웠다. 설문조사도 미리 작성하고 그 내용을 바탕으로 이런저런 이야기를 했는데 생각보다 편한 분위기라서 부담은 없었다.

그리고 이쯤 되니 통계에서 정신이 나간 사람이 나만은 아니었던 모양이다. 기술 코치님께서 지금까지의 수업 내용을 바탕으로 지금 당장 필요한 것과 나중에 공부해도 되는 것을 나누고, 버릴 건 버리고 가져갈 건 확실히 가져가도록 세션을 진행했다. 개인적으로 이게 정말 아주 큰 도움이 되었다. 괜히 모든 걸 다 이해하려고 붙잡고 있기보다는 지금 필요한 걸 먼저 가져가는 게 훨씬 마음이 편했다.

운 좋게도 7기 사람들의 포트폴리오 컨설팅에도 참여할 수 있었다. 컨설팅 시간에 빈자리가 생겨서 그 자리에 들어갈 수 있게 되었다. 8기는 포트폴리오가 있는 사람들만 참여하는 게 좋다고 하셔서 이러나저러나 프론트엔드 개발자를 준비하면서 만들었던 포트폴리오가 있었기에 참여할 수 있었다. 데이터 분석 포트폴리오는 아니었지만 앞으로 어떤 방향으로 준비하면 좋을지 정리해 볼 수 있어서 꽤 의미 있는 시간이었다.

세 번째로 힘들었던 건, 혼자 준비했던 정보처리기사 실기 시험이었다. 딥러닝을 배우면서 정보처리기사도 준비하고 스터디도 하고 개인 프로젝트도 조금씩 하고 블로그도 쓰고... 하나둘 욕심을 내다 보니 스노우볼을 굴린다는 게 아차산이 아니라 에베레스트에서 굴려버렸다. 그 와중에 단순포진까지 올라오면서 몸도 마음도 꽤 지쳤다. 그래도 시험이 끝난 지금은 정말 홀가분하다. 시험 하나 끝났다고 이렇게 기분이 좋아질 수 있나 싶을 정도로.

이렇게 적고보니 생각보다 많은 일이 있었다. 앞으로는 미니 프로젝트가 시작되고, 그다음에는 한 달 동안 진행하는 팀 프로젝트가 기다리고 있다. 느낌상 다음 글은 팀 프로젝트를 시작하면서 쓰는 글이거나 프로젝트가 끝난 뒤 회고가 될 것 같다. 아니면 정신 차려보니 수료후기일 수도 있고... 이번에는 너무 오래 비우지 않도록 해봐야겠다.

앞으로 할 일

가장 먼저 통계를 공부하려고 한다. '데이터 분석을 위한 통계(2판)'을 구매했는데, 이번에는 단순히 이론만 읽는 것이 아니라 직접 파이썬으로 실습하면서 이해해볼 생각이다. 결국 데이터 분석을 하려면 통계와 파이썬은 계속 함께 가야 하는 것 같아서 조금 오래 걸리더라도 제대로 공부해보려고 한다.

그리고 GA4도 슬슬 만져보려고 한다. 블로그를 시작할 즈음에 미리 심어두긴 했는데 아직 데이터가 많지는 않지만 그래도 쌓이고는 있다. 우선은 Google Analytics 데모 계정으로 이것저것 연습해 보고 나중에 데이터가 조금 더 쌓이면 이 블로그도 직접 분석해 볼 생각이다. 공공 데이터도 좋지만 내가 직접 만들어낸 데이터를 분석하는 것도 꽤 재미있을 것 같다는 생각이 든다.

마지막은 개인 프로젝트. 타이타닉 항해일지와 탐사일지는 마무리됐다. 클로드가 만들어준 튜토리얼을 따라가면서 공부했기 때문에 흐름을 잡기에는 좋았지만 홀로 한 프로젝트라고는 할 수 없었다. 가설도 과정도 다 클로드가 해줬으니까. 이번에는 정말 처음부터 끝까지 내가 질문을 만들고 데이터를 찾고 분석하는 프로젝트르 해보려고 한다. 주제는 커피인데 바리스타 자격증을 준비하면서 생긴 궁금증들이 정말 많았는데 그걸 데이터로 하나씩 확인해보고 싶어졌다. 잘 될지는 모르겠지만 첫 번째 개인 데이터 분석 프로젝트인 만큼 재미있게 해보려고 한다.

[python] 브루잉 일지 00. 왜 나는 커피를 데이터로 보기 시작했을까?

Floaty — Fri, 24 Jul 2026 12:00:39 +0900

프로젝트를 시작한 이유

커피를 공부하면서 '고도가 높을수록 산미가 좋다', '가공 방식에 따라 맛이 달라진다' 같은 이야기를 자주 접했다. 그럴듯하게 들리지만 실제 데이터에서도 확인되는 이야기인지는 아무도 알려주지 않았다.

그래서 첫 번째 데이터 분석 프로젝트의 주제를 이 질문으로 시작하기로 했다. 막연한 궁금증을 데이터로 검증하는 과정을 한 번은 직접 경험해보고 싶었다.

질문

좋은 커피는 어떻게 만들어질까? 전문가가 평가하는 좋은 커피와 소비자가 생각하는 좋은 커피는 같은 기준일까?

이 질문에 대해서 생산, 가공, 소비의 세 단계로 나눠서 살펴보려고 한다.

생산
- 고도가 높을수록 산미가 높아질까?
- 생산국이나 품종도 영향을 미칠까?
가공
- 가공 방식에 따라 원두 가격은 달라질까?
- 가공 방식에 따라 품질 평가도 달라질까?
소비
- 소비자는 산미가 높은 커피를 선호할까?
- 전문가의 품질 평가와 소비자의 취향은 얼마나 일치할까?

사용할데이터

처음에는 하나의 데이터셋으로 모든 질문에 답할 수 있을 것이라고 생각했다. 하지만 데이터를 찾아보니 생산, 가공, 소비를 모두 포함하는 공개 데이터셋은 찾을 수 없었다. 그래서 이번 프로젝트에서는 목적에 맞는 공개 데이터셋 세 개를 함께 사용하기로 했다.

CQI 원두 품질 데이터: 고도 ↔ 산미, 품질
Coffee Reviews Datasets: 가공방식 ↔ 가격
소비자 선호 데이터: 산미 ↔ 소비자 선호

예상하는 이 프로젝트의 한계

분석을 시작하기 전부터 이번 프로젝트의 한계는 분명하다고 생각한다.

각 데이터셋 내부에서는 변수 간의 관계를 분석할 수 있지만, 서로 다른 데이터셋의 결과를 하나의 인과관계로 연결해 해석하기는 어렵다. 예를 들어 CQI 원두 품질 데이터와 소비자 선호 데이터를 함께 사용하더라도 '고도가 높은 커피를 소비자가 더 선호한다'는 결론을 내릴 수는 없다.

따라서 이번 프로젝트에서는 각 데이터셋 안에서 관찰되는 관계를 설명하는 것을 목표로 한다. 데이터셋 간의 연결은 어디까지나 탐색적인 해석 수준에서만 다룰 예정이다.

이 프로젝트 이후에 해보고 싶은 것

이 한계를 인식하고 나니 자연스러게 다음 목표도 생겼다. 만약 동일한 원두에 대해 생산 환경, 품질 평가, 가격, 소비자 평가가 모두 포함된 데이터셋을 직접 구축할 수 있다면 회귀분석이나 인과분석을 통해 각 요인이 가격과 소비자 선호에 어떤영향을 미치는지 더욱 정교하게 분석해보고 싶다. 그래서 이번 프로젝트는 하나의 완성된 결론이라기보다, 다음 단계로 나아가기 위한 첫 잔의 커피라고 생각한다.

[python] 두 항해를 마치며....

Floaty — Thu, 16 Jul 2026 15:00:36 +0900

새싹에서 데이터 분석 수업을 들으면서 이상한 갈증이 있었어요. 강의는 계속 듣는데 뭔가 하나 제대로 끝낸 게 없다는 느낌이었어요. input은 계속 쌓이는데 output은 없으니까 그래서 나 뭐 할 줄 아는데?라는 질문에 딱히 보여줄 게 없더라고요.

그럴 때 걸려든 게 타이타닉 데이터였습니다. 00편에서도 적었듯 데이터 분석 입문자들에게는 거의 필수 코스처럼 쓰이는 유명한 데이터셋이었죠. 어차피 배우는 김에 처음부터 끝까지 한 번 제대로 끝내보자 싶어서 도구를 익히는 항해일지와 실제로 가설을 세우고 검증하는 탐사일지로 나눠서 쓰기 시작했습니다. 겸사겸사 블로그에도 올려보기로 했어요. 누구 하나는 도움받겠지 하는 마음도 있었습니다.

지금 와서 생각해보면 이 시도는 잘한 것 같아요. 열두 편이 넘는 글을 쓰는 동안 `numpy`부터 `pandas`, `matplotlib`, `seaborn`, 로지스틱 회귀까지 하나씩 손에 익혔고 무엇보다 가설을 세우고, 검정하고, 왜 그런 결과가 나왔는지 의심하고, 다시 들여다보는 흐름을 한 번 겪어봤다는 게 컸습니다. 이게 딱 제가 원하던 output이었던 것 같아요.

탐사일지에 나온 그래프들은 전부 AI의 도움을 받아서 그렸습니다. 색상 하나, 축 하나까지 어떻게 해야 할지 스스로 그릴 수 있는 영역이 아니라고 생각했고 지금도 같은 생각인 것 같아요. 그런데 다시 생각해보면 이 시리즈를 통해서 카이제곱 검정 결과가 뭘 의미하는지 판단하고 요금이 진짜 원인인지 아니면 등급 때문에 그렇게 보이는건지 의심하고 그 의심을 다시 검증해보는 과정을 거쳐봤습니다. AI의 도움을 너무 많이 받아서 제가 데이터 분석을 하는건지 AI가 데이터 분석을 하는건지 잘 모르겠다 싶었거든요.

생각했던 것보다 훨씬 오래 걸렸습니다. 그 사이에 다른 일들로 바빠서 며칠씩 손을 못 대기도 했고 중간에 다시 앞으로 돌아가서 코드를 고친 적도 있고요. 그래도 결국 마침표를 찍었다는 게 지금은 이게 가장 크게 느껴지네요. 끝까지 안 끌고 흐지부지됐던 것들이 꽤 있었는데 이번엔 그렇지 않았어요.

흥미있는 데이터를 찾아서 데이터 분석을 해볼 예정이지만 이렇게 타이타닉 튜토리얼처럼 흐름을 가져가면서 블로그 글을 연재할지는 모르겠습니다. 투비컨티뉴는 아니고 그냥 뭐.. 네 그렇습니다.

지금까지 타이타닉 항해일지부터 탐사일지까지 읽어주셔서 감사합니다.

[python] 탐사일지 05. 항해도를 완성하다: 교차검증, 변수 선택, 결론과 한계

Floaty — Thu, 16 Jul 2026 11:00:51 +0900

다변량 교차검증

가설을 하나씩 따로 검증하면 놓치는 부분이 있어요. 변수들이 서로 얽혀 있을 때는 여러 변수를 동시에 높고 봐야 진짜 그림이 보입니다.

우리가 가설검정에 가장 중요한 변수 두 개를 객실 등급과 성별이라고 했죠? 이 부분을 좀 봐야겠어요.

pivot = df.pivot_table(values="survived", index="pclass", columns="sex", aggfunc="mean")
print(pivot.round(3))
"""
sex     female   male
pclass               
1        0.968  0.369
2        0.921  0.157
3        0.500  0.135
"""

pivot_pct = (
    pivot.mul(100)
    .reindex(index=[1, 2, 3], columns=["female", "male"])
    .rename(
        index={1: "1등실", 2: "2등실", 3: "3등실"},
        columns={"female": "여성", "male": "남성"},
    )
)

set_plot_theme()
set_korean_font()

colors = get_palette(3)
cmap = LinearSegmentedColormap.from_list("custom_slate", [colors[1], colors[2]])

fig, ax = plt.subplots(figsize=(6, 5))

sns.heatmap(
    pivot_pct,
    annot=True,
    fmt=".1f",
    cmap=cmap,
    vmin=0,
    vmax=100,
    linewidths=2,
    linecolor="white",
    cbar_kws={"label": "생존율(%)"},
    annot_kws={"fontsize": 12},
    ax=ax,
)

ax.set_title("객실 등급 × 성별 생존율 (%)", fontsize=14, pad=15)
ax.tick_params(left=False, bottom=False)

plt.tight_layout()
save_fig(fig, "h1_h2_heatmap", "analysis")
plt.show()

H1(성별)과 H2(등급) 각각의 효과는 두 변수를 함께 봤을 때가 더 극단적입니다. 1등실 여성의 생존율은 96.8%로 사실상 전원 생존에 가깝지만 3등급 남성은 13.5%로 거의 전멸에 가깝네요. 같은 여성이라도 등급에 따라 50.0%(3등실)에서 96.8%(1등실)까지 차이가 나는데 이는 등급이 성별과 무관하게 독립적으로도 강하게 작용한다는 것을 보여줍니다. 두 변수는 서로를 대체하는 것이 아닌 곱셈적으로 함께 작용하게 됩니다.

전체 수치형 변수 상관관계

cols = ["survived", "pclass", "age", "fare", "family_size"]
corr = df[cols].corr().round(2)

labels = ["생존", "등급", "나이", "요금", "가족크기"]
corr.index = labels
corr.columns = labels

cmap = LinearSegmentedColormap.from_list("custom_slate", [colors[1], colors[2]])

fig, ax = plt.subplots(figsize=(7, 5.5))

sns.heatmap(
    corr,
    annot=True,
    fmt=".2f",
    cmap=cmap,
    vmin=-1,
    vmax=1,
    linewidths=1.5,
    linecolor="white",
    square=True,
    cbar_kws={"shrink": 0.8},
    annot_kws={"fontsize": 10},
    ax=ax,
)

ax.set_title("주요 변수 간 상관관계", fontsize=14, pad=15)
ax.set_xlabel("")
ax.set_ylabel("")
ax.tick_params(left=False, bottom=False)
plt.setp(ax.get_xticklabels(), rotation=45, ha="right")
plt.setp(ax.get_yticklabels(), rotation=0)

plt.tight_layout()
save_fig(fig, "corr_heatmap", "analysis")
plt.show()

`survived`와 가장 강하게 상관된 변수는 `pclass`이고, `fare`는 양의 상관을 보이지만 앞서 확인했듯 `pclass`와 강한 역상관 때문에 생기는 간접 효과에 가깝습니다. `family_size`는 `sibsp`, `parch`와 당연히 강하게 연결되어 있으니 모델에 셋을 모두 넣으면 다중공선성이 생깁니다. (그래서 `family_size`만 히트맵에 담았습니다.)

로지스틱 회귀로 영향력 종합 정리

지금까지는 가설 하나당 변수 하나씩(성별, 등급, 요금 등) 따로 검정했고, H5, H7에서는 등급 하나만 수동으로 통제해 봤어요. 그런데 실제로 성별과 등급, 나이, 가족크기, 요금, 선실기록, 탑승학구가 전부 동시에 얽혀있습니다. 로지스틱 회귀를 쓰면 이 변수들을 전부 한 모델에 넣고 다른 조건이 다 같을 때 변수 하나만 바뀌면 생존 확률이 얼마나 변하는가를 한 번에 계산할 수 있어요.

먼저 파생 변수를 만들어보도록 할게요.

# 파생 변수 만들기
df["sex_male"] = (df["sex"] == "male").astype(int)
df["age_imputed"] = df["age"].fillna(df["age"].median())
df["has_cabin_record"] = df["has_cabin_record"].astype(int)

embarked_dummies = pd.get_dummies(  # 범주형 변수를 해당 항구인지 아닌지를 나타내는 0/1 컬럼들로 쪼개는 원-핫 인코딩
    df["embarked"],     # embarked 컬럼에 대해서
    prefix="embarked",  # 새로 만들 컬럼 이름 앞에 붙일 접두어
    drop_first=True,    # C가 기준이 되고, embarked_Q, embarked_S만 남음
)
df = pd.concat(  # 여러 개의 데이터프레임을 하나로 이어 붙이는 함수
    [df, embarked_dummies],  # 이어 붙일 데이터프레임들을 리스트로 나열
    axis=1,                  # 좌우로 이어 붙여서 열이 늘어남
)

`sex`, `embarked`처럼 문자로 된 값은 회귀모델이 계산할 수 없어서 전부 0과 1로 된 숫자 컬럼으로 바꿔주는 작업입니다. 특히 `get_dummies`는 탑승 항구가 3개 중 어디였는지를 Q항구인가? S항구인가? 두 컬럼으로 표현했어요. C항구에 대해서는 Q항구도 S항구도 아닌 항구면 알 수 있기 때문에 기준값으로 남겨둡니다.

# 모델 학습 & 계수 해석
X = df[
    [
        "pclass",
        "sex_male",
        "age_imputed",
        "family_size",
        "fare",
        "has_cabin_record",
        "embarked_Q",
        "embarked_S",
    ]
]
y = df["survived"]

# StandardScaler: 각 변수를 평균 0, 표준편차 1로 맞춤
X_scaled = StandardScaler().fit_transform(X)
# LogisticRegression: 생존(1)/사망(0)처럼 결과가 두 가지뿐인 문제에 쓰는 회귀 모델
model = LogisticRegression().fit(X_scaled, y)

print(f"train accuracy = {model.score(X_scaled, y):.3f}")  # train accuracy = 0.800
coef = pd.Series(
    model.coef_[0],  # 각 변수에 대응하는 계수 배열
    index=X.columns,  # 계수 배열의 각 값에 붙일 이름표
).sort_values(
    key=abs,  # 부호와 상관없이
    ascending=False,  #  영향력이 큰 순서대로 정렬
)
print(coef.round(3))
"""
sex_male           -1.301
pclass             -0.702
age_imputed        -0.502
family_size        -0.355
has_cabin_record    0.310
embarked_S         -0.186
fare                0.065
embarked_Q         -0.035
"""

정확도는 80.0%로 8개 변수만으로도 생존 여부를 꽤 잘 맞히는 모델이 나왔습니다. 계수를 보면 `sex_male`이 -1.301로 압도적으로 큽니다. 다른 모든 조건이 같아도 남성이라는 것 자체가 생존 확률을 가장 크게 깍아먹는다는 뜻입니다. `pclass`, `age_imputed` 도 뒤를 잇네요. 흥미로운 건 `has_cabin_record`가 유일하게 확실한 양수네요. H6에서 봤던 것처럼 등급을 비롯한 다른 변수들을 다 통제한 뒤에도 선실 기록이 남아있으면 생존에 유리했다는 뜻이니, 앞서 H6에서 내린 결론과 맞아떨어집니다.

# 시각화
label_map = {
    "sex_male": "남성 여부",
    "pclass": "객실등급",
    "age_imputed": "나이",
    "family_size": "가족크기",
    "has_cabin_record": "객실기록 유무",
    "embarked_S": "Southampton 탑승",
    "fare": "요금",
    "embarked_Q": "Queenstown 탑승",
}

coef_plot = coef.rename(index=label_map)

# 계수가 음수면 진한 색, 양수면 연한 색
bar_colors = [colors[0] if v < 0 else colors[1] for v in coef_plot.values]

fig, ax = plt.subplots(figsize=(8, 5.5))

# [::-1]: 영향력이 가장 큰 변수가 그래프 맨 위에 오도록
ax.barh(coef_plot.index[::-1], coef_plot.values[::-1], color=bar_colors[::-1])
ax.axvline(0, color=colors[2], linewidth=1)

ax.set_title("로지스틱 회귀 — 변수별 영향력 비교", fontsize=14, pad=15)
ax.set_xlabel("표준화 회귀계수 (생존에 미치는 영향, +면 생존에 유리)")
ax.grid(axis="y", visible=False)

plt.tight_layout()
save_fig(fig, "logreg_coef", "analysis")
plt.show()

7개 가설을 하나씩 뜯어봤을 때와 전체 변수를 한 모델에 넣고 봤을 때 결론이 거의 일치했어요. 특히 H5(요금)와 H7(탑승 항구)에서 등급을 통제하면 효과가 약해진다고 봤던 부분이 이번 회귀에서도 `fare`(0.065)와 `embarked_Q`(-0.035)의 계수가 다른 변수들보다 훨씬 작게 나오면서 다시 한 번 확인됐습니다.

결국 타이타닉 생존을 가장 크게 갈랐던 것은 성별과 등급이고 나머지 변수들은 이 둘의 영향을 부분적으로 대신 보여주는 역할에 가까웠다고 정리할 수 있겠네요.

최종 변수 선택 정리

우리가 탐사일지에서 내릴 모든 결정을 한 곳에 모아볼 겁니다. 15개였던 컬럼이 분석에 실제로 쓰이는 9개의 변수로 정리됩니다. 이게 진짜 분석에서 전처리가 의미하는 거죠. 컬럼을 깨끗하게 만드는 것뿐만 아니라 어떤 정보를 남기고 어떤 정보를 버릴지 근거를 가지고 결정하는 것입니다.

최종 변수	원본 출처	역할
survived	survived	타겟 변수
pclass	pclass	핵심 설명변수 (사회경제적 지위)
sex	sex	핵심 설명 변수
age_imputed	age (결측 보완)	등급x성별 그룹 중앙값으로 채움
who	who	나이+성별 통합 파생변수 (어린이 식별용)
family_size / family_group	sibsp + parch	가족 동반 규모, 3구간 버킷화
fare	fare	보조 변수(pclass와 다중공선성 주의)
has_cabin_record	deck (결측 패턴 활용)	선실 기록 유무 이진 변수
embarked	embared (결측 보완)	보조 변수 (pclass로 대부분 설명됨)

버려진 컬럼과 이유

`class`: `pclass` 중복
`alive`: `survived` 데이터 누수
`alone`: `family_size` 중복
`adult_male`: `who`에서 결정됨
`embark_town`: `embarked` 중복
`deck`: `has_cabin_record`로 대체(원본은 결측 77%로 직접 사용 불가)

결론과 한계

가설	내용	판정
H1	여성 > 남성 생존율	O
H2	등급이 높을수록 생존율 높음	O
H3	어린이 > 성인 생존율	△ 부분 지지 (등급별 불균등)
H4	중간 규모 가족이 가장 유리	O
H5	운임이 높을수록 생존율 높음	△ 부분 지지 (pclass와 다중공선성)
H6	선실 기록 있으면 생존율 높음	O 지지됨 (조건부, 기록 편향 가능)
H7	탑승 항구별 생존율 차이	X 기각 (독립 효과 아님)

"여성과 아이 먼저 원칙이 모든 승객에게 동일하게 적용되었는가"에 대한 답은 NO입니다. 그 원칙은 분명 존재했지만 객실 등급이라는 또 다른 변수가 그 원칙의 적용 강도를 결정했어요. 1등실과 2등실 어린이는 거의 전원 생존했지만 3등실 어린이의 생존율은 같은 등급 여성보다도 낮았습니다. 결국 이 데이터가 보여주는 가장 중요한 그림은 "성별과 나이의 효과가 사회경제적 지위에 의해 증폭되거나 상쇄되었다"는 것입니다.

상관관계 ≠ 인과관계
통계적으로 유의한 연관성을 확인했을 뿐 '여성이라서 구조되었다'는 인과적 주장을 증명한 것은 아닙니다. 실제 구조 과정의 의사결정 기록이 없는 한 인과는 추정의 영역입니다.
기록 자체의 생존자 편향
H6에서 다뤘듯 선실 정보는 사고 이후 생존자 증언과 보험 청구로 보완된 자료입니다. 사망자에 대한 기록이 상대적으로 부실할 수 있어 일부 변수는 생존했기 때문에 기록이 남았다는 역방향 편향을 포함할 수 있어요.
단일 사건, 일반화 불가
891명의 단일 침몰 사건 데이터입니다. 다른 재난 상황에서 이 패턴 (여성/아이/고등급 우선)을 일반화할 근거는 없습니다.
컬럼 한계
이번에 사용한 seaborn 버전 데이터셋은 이름, 티켓번호, 승객ID가 없어 이름에서 귀족 호칭을 추출해 더 정교한 신분 변수를 만든다 같은 흔한 후속 분석은 이 데이터로 시도하지 못했습니다.
표본 크기 불균형
일부 교차 구간(ex. 2등실 어린이 6명)은 표본이 매우 작아 비율 수치가 극단적으로 나올 수 있습니다.

여기까지 타이타닉 데이터로 떠난 데이터 분석 이야기였습니다. 후기 아닌 후기는 두 항해를 마치는 글로 나타나도록 할게요.

컬럼명	설명
Brew Temperature	브루잉 완료 직후 서버 내 온도(℃)
Pour Temp	종이컵에 따른 직후 온도(℃)
90Sec Temp	따른 후 90초 뒤 온도(℃)