Smol Beaver's Data Lab

dbt 스터디 1일차

조구만비버 — Wed, 1 Apr 2026 18:36:31 +0900

ELT vs. ETL

- 주요 차이점 : 데이터 변환 시점

구분	ELT	ETL
의미	Extract, Loard, Transform 추출, 적재, 변환	Extract, Transform, Load 추출, 변환, 적재
데이터 변환	데이터 적재 이후	데이터 적재 이전

* ETL에서 변환을 한다고 하지만, 실제로 의미 있는 변환은 BI에서 다시 하는 경우가 많음

ETL 문제

- 변환 로직이 외부에 있음

- 수정 어려움

- BI에서 로직 중복 발생

- 협업 어려움

ETL 대세인 이유

- 1. 클라우드 성능이 강함 : BigQuery, Snowflake 같은 DW가 계산을 다 해줌

- 2. 데이터 빨리 볼 수 있음 : raw 바로 넣고 조회 가능

- 3. 비용 효율 : ETL 서버/툴 필요 ↓

- 4. 유연성 : 나중에 로직 바꿔도 재처리 가능

dbt

위치

- DW (Load) →. dbt. (Transform) → BI

역할

- SQL 변환 관리

- 버전 관리

- 테스트

- 자동화

[ 추가 정리 ]
PA vs. BI

구분	PA	BI
의미	Product Analytics	Business Intelligence
핵심 역할	유저 행동 분석 퍼널 분석 리텐션 / 코호트 분석	대시보드 리포트 KPI 모니터링
특징	이벤트 기반 데이터 실시간/세션 중심 프로덕트 개선 목적	이미 정리된 데이터 사용 SQL 몰라도 사용 가능 시각화 중심
도구	Amplitude Mixpanel Appsflyer	Tableau Power BI Looker

* PA가 BI를 “대체"할 수는 있지만, “커버”하지는 못한다

ㄴ BI 에서는 내부 거래 시스템 , 결제/PG사, 정산 시스템 등에서 매출 데이터 불러온다

구분	PA	BI	PA가 BI 대체 못하는 이유
데이터 범위	유저 행동 (이벤트)	전사 데이터 (매출, 비용, CRM 등)	PA는 “부분 데이터”만 다룸
데이터 출처	앱/웹 트래킹	여러 시스템 통합 (DB, ERP, Ads 등)	비즈니스 전체를 못 봄
데이터 정확도	트래킹 누락 / 중복 가능	정제 + 검증된 데이터	재무/의사결정에 부적합
데이터 모델	이벤트 기반 (flat)	Fact/Dimension 구조	복잡한 분석 구조 부족
목적	왜 유저가 행동했는지	회사가 어떻게 돌아가는지	질문 자체가 다름
활용자	PM, 마케터	경영진, 전략팀	의사결정 레벨 차이
확장성	빠르지만 제한적	느리지만 안정적	규모 커질수록 한계

* BI 포함 데이터 흐름

[비즈니스 이벤트] 구매, 환불, 재고이동 등 발생

↓

[ERP] 비즈니스 데이터 (매출, 재고 등) 입력 및 저장
   ↓ ELT / ETL
[Data Warehouse] 비즈니스 데이터 raw 저장
   ↓
[dbt]
   ↓
[BI]

---

* PA 포함 데이터 흐름

[User 행동]
↓
[PA]

[바이브코딩] 도시탐험 추천지도 - 기획 : PRD 문서 / 개발 프로세스

조구만비버 — Tue, 17 Mar 2026 18:10:13 +0900

서비스 기획 배경

서울에 살고 있지만, 막상 서울을 잘 안다고 말하기는 어려운 것 같다.
주로 다니는 동네만 계속 반복하게 되고, 새로운 곳을 찾아가려면 매번 검색부터 다시 해야 한다.

가끔은 다른 동네에서 시간을 보내보고 싶다는 생각이 들지만,
어디를 가야 할지 기준이 없어서 결국 익숙한 곳으로 돌아오게 된다.

여러 동네를 돌아다니다 보니, 괜찮았던 장소들이 조금씩 쌓이기 시작했다.
그런데 이걸 체계적으로 정리하거나 다시 활용하기가 쉽지 않았다.
지도에 저장은 해두지만, 그게 나의 취향이나 경험과 연결되지는 않는 느낌이었다.

그래서 단순히 장소를 저장하는 걸 넘어서,
내가 좋아하는 장소들을 모아보고
그걸 기반으로 “다음에는 어디를 가볼지”까지 이어주는 서비스가 있으면 좋겠다고 생각했다.

이 프로젝트는 그런 고민에서 시작했다.

시장 조사

아이디어를 얻고 차별화 포인트를 생각해보고자 유사 서비스를 찾아보았다.

카카오맵 - 테마지도 (콘텐츠 형식의 장소 추천)
네이버지도 - 저장탭 + 리스트 공유 (장소 저장 및 공유 기능)
망고플레이트 - 맛집 특화 테마 지도 (리뷰 기능 포함)
당근마켓 - 우리 동네 지도 (하이퍼로컬 지도)

PRD ( Product Requirements Document)

1. 제품 개요

제품 이름

Urban Discovery Map (도시탐험 추천 지도)

제품 비전

사용자가 데이터를 기반으로 어디 가볼까? > 어디 가보고 싶다 로 이어지게 만드는 도시 탐험 지도 서비스

문제 정의

많은 사람들은 좋은 장소를 발견해도 체계적으로 저장하거나 다시 찾기 어렵다.

또한 특정 취향에 맞는 장소나 동네를 탐험하기 위한 도구가 부족하다.

현재 지도 서비스는 많지만, 다음과 같은 한계가 있다.

장소 저장 기능은 있지만 취향 중심 구조가 약하다.
개인이 저장한 장소를 기반으로 탐험 경험을 제공하지 않는다.
취향 기반 장소 분포를 시각적으로 이해하기 어렵다.

해결 방법

사용자가 좋아하는 장소를 저장하고 태그를 붙이면, 아래 서비스를 제공하여 새로운 동네를 탐험하도록 유도한다.

지도에서 취향 기반 장소 분포를 시각화
관심 태그 기반 탐험 추천
지역별 탐험 밀도 분석

2. 목표

주요 목표

사용자가 쉽게 장소를 저장할 수 있다
저장된 장소 데이터를 기반으로 취향 분포를 시각화한다
사용자에가 새로운 동네를 탐험하고 싶어지게 취향 기반의 새로운 탐험 지역을 추천한다

성공 기준 (MVP)

사용자가 3개 이상의 장소를 저장
지도에서 저장 분포 확인 가능
태그 기반 밀도 변화 확인 가능
최소 1개 추천 지역 노출

3. 핵심 사용자

Primary User

도시 탐험을 좋아하는 사람

예:

카페 탐방
전시 관람
공방 체험
산책 장소 탐색

특징

장소 저장 습관 있음
취향 기반 추천 선호
새로운 동네 탐험 관심

4. 핵심 사용자 시나리오

시나리오 1

사용자가 카페를 발견한다 → 앱에서 검색 → 저장 → 태그 추가

시나리오 2

사용자가 지도를 열어본다 → 저장된 장소 분포 확인 → 특정 지역 밀도 확인 → 새로운 동네 탐험

시나리오 3

사용자가 취향 태그 선택 → 관련 장소 추천

5. 핵심 기능 (MVP)

5.1 로그인

사용자 인증
데이터 저장

5.2 장소 검색

장소명 검색
결과 리스트 표시
선택 가능

5.3 장소 저장

저장 버튼
태그 선택
메모 (선택사항)

5.4 지도 시각화

저장 장소 핀 표시
지도 중심 탐험 UX

5.5 지역 밀도 시각화

저장 많은 지역 강조
히트맵 or 색상 구분

5.6 간단 추천

태그 기반
지역 기반

5.7 태그 기반 밀도 필터

특정 태그 선택 시 해당 태그 데이터만 필터링
필터된 데이터 기준으로 밀도 재계산

5.8 태그 기반 밀도 필터

링크 공유 : 저장된 리스트 공유 가능
이미지 카드 공유 : 저장된 리스트를 이미지 형태로 생성, SNS 공유 가능

6. 사용자 흐름

User Flow

검색 → 장소 선택 → 태그 추가 → 저장 → 지도 확인 → 탐험

7. 데이터 로그 설계

수집 이벤트

place_search
place_view
place_save
tag_select
map_view
region_click

목적

사용자 행동 분석
추천 로직 개선

8. 데이터 구조 개요

핵심 엔티티

users : 사용자 정보
spots : 장소 (가게, 공간)
saves : 유저가 저장한 장소
tags : 태그 목록
save_tags : 저장 + 태그 연결
events : 유저 행동 로그

9. Cold Start 전략

초기 서비스 데이터 부족 문제 해결

방법

초기 시드 지역 설정
장소 API 기반 데이터 확보

10. 향후 확장 기능

저장 리스트 공유 : 사용자가 자신의 탐험 리스트 공유 (예) 성수 하루 탐험 코스
이미지 카드 생성 : 저장 리스트를 이미지로 생성 (예) SNS 공유
사진 업로드 : 장소 사진 저장
추천 알고리즘 고도화 : 취향 클러스터링, 유저 유사도 기반 추천

11. 기술 스택 (예상)

장소 검색 / 지도 제공 : 네이버지도 API (장소검색 API, 지도 JavaScript SDK)
프론트엔드 : Next.js
백엔드 / 데이터베이스 : Supabase (PostgreSQL, Auth, Storage 가능)
데이터분석 : Python

12. 포트폴리오 포인트

위치 기반 서비스 설계
데이터 모델링
사용자 행동 로그 설계
추천 로직 설계
지도 시각화

13. MVP 범위 요약

필수

로그인
장소 검색
장소 선택 및 저장
태그 선택
지도에 저장 장소 표시
지역 밀도 시각화
간단 추천
공유 기능 (링크 / 이미지 카드)

후순위

메모 기능
필터 기능

제외

사진 업로드
리뷰
소셜 네트워크
고도화 추천

개발 프로세스 (feat. AI 협업 역할 정의)

1단계: ChatGPT + Perplexity

시장조사
PRD 정리
MVP 범위 확정
핵심 사용자 흐름 확정

2단계: Claude Code

기술 설계
DB 스키마
API 연동 구조
기능 명세 기반 초기 구축

3단계: Antigravity

Claude가 만든 기능 구조를 바탕으로
화면 구조, 레이아웃, 디자인 시스템 구체화

4단계: Claude Code

Antigravity 결과 반영해서 UI 구현
상태관리, 컴포넌트 정리, 반응형 처리

*Claude Code : 제품 설계와 동작 로직

PRD를 바탕으로 기능 범위 정리
기술 스택 결정
프로젝트 폴더 구조 설계
DB 스키마 설계
Supabase 연동
네이버 지도 API 연동
장소 검색 흐름 구현
저장 기능 구현
태그 구조 설계
추천 로직 1차안
이벤트 로깅 구조 설계
배포 가능한 코드 작성

*Antigravity : UI/UX와 시각적 방향성

브랜드 무드
컬러 시스템
지도 화면 레이아웃
검색창/저장버튼/태그 선택 UI
저장 리스트 카드 디자인
지역 밀도 시각화 표현 방식
추천 카드 비주얼
공유용 이미지 카드 시안
모바일 우선 화면 플로우
인터랙션 제안

요약

마케터에서 데이터 엔지니어로 — Smol Beaver's Data Lab을 시작하며

조구만비버 — Sun, 15 Mar 2026 17:44:42 +0900

나는 약 4년 동안 퍼포먼스 마케팅 일을 해왔다. 커리어의 전부를 에이전시에서 보냈다.

에이전시에서의 퍼포먼스 마케팅 일은 생각보다 재미있는 부분이 많았다. 무엇보다 다양한 산업군의 고객사를 경험해 볼 수 있었고, 데이터를 기반으로 미디어 믹스를 계획하고, 광고 소재를 기획하고, 이벤트를 설계하면서 실제 사용자 반응을 바로 확인할 수 있었다. 내가 기획한 캠페인이 실제 성과로 이어지는 것을 보는 경험은 분명 매력적이었다.

특히 데이터를 기반으로 의사결정을 시도하는 과정 자체는 늘 흥미로웠다. 성과 데이터를 분석하고, 그 결과를 다음 캠페인 전략에 반영하는 흐름은 마케팅이라는 일이 얼마나 데이터와 가까운지 보여주는 일이기도 했다.

하지만 일을 하면서 점점 더 크게 느끼게 된 문제가 있었다.

데이터가 많다고 해서 항상 의미 있는 건 아니었다.

데이터를 기반으로 의사결정을 하려고 해도, 정작 데이터 수집 단계부터 제대로 이루어지지 않는 경우가 생각보다 많았다.

이벤트가 제대로 수집되지 않거나, 데이터 정의가 명확하지 않거나, 같은 지표가 서로 다른 의미로 사용되는 경우도 있었다. 이런 상황에서는 "데이터 기반 의사결정"이라는 말 자체가 흔들린다. 데이터의 양이 아니라 데이터의 신뢰도가 더 중요한 문제라는 것을 점점 더 체감하게 되었다.

실제로 많은 기업들이 데이터를 중요하게 이야기하지만, 데이터의 품질에 대한 신뢰가 낮기 때문에 결국 경험이나 감각에 의존해 의사결정을 내리는 경우도 적지 않았다.

그럴 때마다 나는 늘 비슷한 자리에 있었다.

문제가 있다는 것은 느낄 수 있었지만, 그 문제를 직접 해결할 수 있는 위치는 아니었다. 나는 내부 개발자도 아니었고, 데이터 인프라를 직접 관리하는 사람도 아니었기 때문이다.

그래서 내가 할 수 있는 일은 보통 이런 정도였다. 로그를 확인하고 간단한 QA를 진행하면서, 어느 지점에서 데이터 수집이 잘못되고 있는지 어렴풋이 추측하고, 그 내용을 개발팀에 전달하는 것.

그 과정에서 나는 한 가지를 느꼈다.

나는 데이터를 사용하는 것보다, 데이터가 만들어지는 과정 자체가 궁금해지고 있었다.

처음에는 단순히 반복적인 작업을 줄이기 위한 자동화에 흥미를 느꼈다. 데이터를 추출하고 정리하는 작업을 자동화하면서 Python이나 SQL을 조금씩 사용하기 시작했고, GitHub 같은 도구도 자연스럽게 접하게 되었다.

하지만 raw 로그 데이터를 직접 들여다보기 시작하면서, 관심은 점점 다른 방향으로 옮겨갔다.

특히 로그 데이터의 taxonomy 구조를 보게 되었을 때, 나는 처음으로 이런 생각을 하게 되었다.

데이터는 분석 이전에 이미 설계된 구조 속에서 만들어지고 있다. 그리고 그 구조가 제대로 설계되지 않으면, 아무리 많은 데이터가 쌓여도 의미 있는 분석이 어려워진다.

이때부터 나는 데이터 분석보다, 데이터가 흐르는 구조 자체에 더 관심을 가지기 시작했다.

이후 Python, SQL, Git 같은 도구를 개별적으로 익히고, 데이터 파이프라인을 관리하는 방식에 관심이 생기면서 Airflow 같은 오케스트레이션 도구도 알게 되었다. AWS와 GCP 같은 클라우드 환경을 이해하기 위한 공부도 이어졌다.

회사를 다니면서 관련 부트캠프를 수강하게 된 것도 이 과정의 연장선이었다. 부트캠프를 통해 Spark, Docker, Kubernetes 같은 도구들을 접하게 되었고, 데이터 처리 방식뿐만 아니라 데이터 스트리밍 구조에 대해서도 고민하게 되었다.

아직 모든 것을 깊이 이해했다고 말할 수는 없다. 데이터 엔지니어링이라는 분야는 생각보다 훨씬 넓고 복잡하다. 그래서 이 길이 나에게 완벽하게 맞는지, 지금 당장 확신한다고 말할 수는 없다.

하지만 한 가지는 분명하게 느끼고 있다.

데이터 엔지니어링은 분명 어려운 분야지만, 지금까지 해왔던 일보다 더 오래 흥미를 가지고 탐구할 수 있을 것 같은 분야라는 점이다.

이 블로그의 이름은 Smol Beaver's Data Lab이다.

비버는 생태계에서 물의 흐름을 바꾸는 댐을 설계하는 동물이다. 작은 구조 하나가 환경 전체를 바꾸기도 한다.

데이터 엔지니어 역시 데이터를 직접 분석하기보다는, 데이터가 흐르는 구조를 설계하는 역할에 가깝다고 생각한다. 그 역할이 지금 내가 나아가고 싶은 방향이기도 하다.

이 블로그는 완벽한 정답을 정리하는 공간이 아니다. 데이터 엔지니어링을 배우면서 겪는 시행착오와 실험을 기록하는, 작은 비버의 연구 노트가 될 것이다.

앞으로 이런 기록들이 쌓일 것 같다.

데이터 엔지니어링 공부 기록
기술 트렌드에 대한 정리와 개인적인 생각
프로젝트를 진행하면서 겪은 문제와 해결 과정
데이터 구조와 파이프라인에 대한 실험

아직은 작은 실험실이지만, 데이터를 배우고 실험하는 과정들을 차근차근 기록해 보려고 한다.

Smol Beaver’s Data Lab, 이제 시작이다.