Project Detail

Job Signal Pipeline

live API나 production 운영을 주장하지 않고 채용 데이터 파이프라인 구조를 어떻게 검증할 것인가?

채용 공고 mock 응답을 PostgreSQL raw 적재부터
analytics views, SQL tests, Streamlit dashboard까지 연결해 검증한
local validation data pipeline v1입니다.

GitHub 저장소 보기

Decision Moment

질문이 바뀐 순간

이 프로젝트가 단순 분석에서 의사결정 구조로 넘어간 핵심 장면입니다.

Original Question채용 공고 서비스를 만들 수 있는가?

Reframed Questionlive 운영을 주장하지 않고 검증 가능한 채용 데이터 파이프라인 구조를 어떻게 증명할 것인가?

Key Evidence: Saramin mock ingestion, PostgreSQL raw loading, 5 analytics SQL views, 7 zero-failing SQL tests, Streamlit dashboard
Final Deliverable: Docker-backed PostgreSQL, raw/analytics SQL models, validation script, Streamlit dashboard, verification docs
What this proves: 구현 범위와 미검증 범위를 분리하면서 데이터 품질 검증 루프를 끝까지 연결하는 역량

Evidence Snapshot

근거 스냅샷

숫자가 있는 프로젝트는 검증 지표를 먼저, 데이터가 부족한 프로젝트는 확인 가능한 산출물 중심으로 정리했습니다.

검증 경로Saramin mock ingestion → PostgreSQL raw loading → 5 analytics views → 7 SQL tests PASS → Streamlit dashboard

Raw/Analytics 분리`raw.job_postings`와 `analytics.job_postings_clean`, market summary, skill demand, source quality, weekly trend views를 분리

SQL 품질 검증required fields, salary bounds, source/source_job_id, unique key 등 7개 SQL tests가 zero failing rows로 통과

Dashboard 검증Streamlit dashboard는 live API를 호출하지 않고 검증된 PostgreSQL analytics views를 조회

범위 경계Saramin live API 운영, production ingestion schedule, monitoring, notification delivery는 구현/검증 범위 밖으로 명시

Problem / Context

문제와 맥락

주요 도메인: 데이터 파이프라인
역할: mock ingestion 설계 / raw/analytics schema 분리 / SQL data quality tests / Streamlit dashboard 검증
기간: 2026
형태: 개인 프로젝트

Context

외부 채용 API 승인과 production 운영 환경이 없는 상태에서 live 서비스처럼 보이게 만드는 대신, 채용 공고 데이터가 어떻게 수집·적재·모델링·검증·조회되는지 mock/local 범위 안에서 재현 가능한 파이프라인으로 분리했습니다.

Problem

채용 공고 API 승인과 production 운영이 없는 상태에서도 데이터 파이프라인의 구조와 품질 검증 흐름을 리뷰어가 확인할 수 있어야 했습니다.

Why it mattered

외부 API 제약을 구현 실패처럼 숨기거나 live 서비스처럼 과장하면, 실제로 검증된 범위와 앞으로 필요한 작업이 흐려지기 때문입니다.

Data & Method

데이터와 접근

데이터

Saramin mock response
PostgreSQL raw.job_postings
analytics SQL views
SQL data quality test queries
Streamlit dashboard

접근

Saramin mock 응답을 정규화하고 `--load-db` 옵션으로 PostgreSQL raw table에 upsert
raw schema와 analytics schema를 분리해 원천 보존과 분석 로직을 나눔
정렬된 SQL migrations/models/tests를 `scripts/validate_sql_models.py`에서 순서대로 실행
analytics previews와 SQL tests가 통과한 뒤 Streamlit dashboard에서 views를 조회
VERIFY 문서와 evidence 문서에 mock/local boundary와 미구현 범위를 명시

지표 / 기준

5 analytics views
7 SQL tests
PASS: Validation passed
localhost:8501 dashboard connection

Output

결과물

Saramin mock 응답을 `raw.job_postings`에 upsert하고, `analytics` schema의 5개 views와 7개 SQL data quality tests를 `scripts/validate_sql_models.py`로 검증했습니다. Streamlit dashboard는 live API가 아니라 검증된 analytics views를 조회하는 local portfolio review 화면으로 연결했습니다.

Mock ingestionPostgreSQL raw loading5 Analytics SQL views7 SQL tests + Streamlit dashboard

Key Insight

핵심 포인트

live 서비스 주장이 아니라 mock/local boundary 안에서 검증 가능한 채용 데이터 흐름으로 범위 재정의
raw loading, 5 analytics views, 7 SQL tests, Streamlit dashboard를 한 검증 루프로 연결
Saramin live API 운영, production ingestion, monitoring, notification delivery 미구현 범위를 문서에 명확히 분리

Limits / Notes

한계와 검토 메모

검증 범위와 추가로 확인해야 할 조건을 숨기지 않고 함께 남겼습니다.

Saramin live API 호출 성공이나 production ingestion 운영을 주장하지 않습니다.
실제 live API 검증에는 승인된 `SARAMIN_API_KEY`와 quota/rate limit 확인이 필요합니다.
Work24는 보조 reference/enrichment 성격으로 분리했으며 main job posting source로 적재하지 않았습니다.
n8n production workflow, monitoring, notification delivery는 현재 구현 범위가 아닙니다.
Streamlit dashboard는 local portfolio review용이며 운영 채용 서비스가 아닙니다.
mock 데이터 검증은 파이프라인 구조 검증이지 실제 채용 시장 커버리지 검증이 아닙니다.

Links

확인 가능한 산출물

GitHub 저장소 보기

GitHub README, VERIFY.md, docs/architecture.md, local validation evidence에서 검증 경로와 미검증 범위를 함께 확인할 수 있습니다.

Case Studies