HWANG YUBIN — PORTFOLIO02 PROJECTS · IN PRODUCTION · 2026

현장의 문제를,
AI와 자동화로
끝까지.

복지 현장의 종이 서류부터 커머스 실무의 반복 소싱까지 —
제가 직접 겪은 비효율을, 실제 사람들이 매일 쓰는 시스템으로 바꿉니다.

Stack Node · Playwright · Electron · React · Claude Code

64자동 수집 쇼핑몰
1,097자동 테스트 통과
2운영 중인 실서비스
30분 → 3분현장 출석 처리
01풀스택 웹서비스 · 2026 · 운영 중

CH.1 — 문제

종이에 적고, 전화로 받고,
서류철에 쌓이던 하루

사회복무요원으로 지역아동센터의 하루를 지켜봤습니다. 출석은 수기로, 결석 연락은 개별 전화로, 기록은 종이로 — 선생님의 시간이 아이들이 아니라 행정에 쓰이고 있었습니다.

성산지역아동센터 통합 운영 플랫폼 · 2026년 4월부터 실제 운영 중 · 아동 개인정보 보호로 링크 비공개

첫 현장

수기 출석부와
종이 서류의 세계

센터장님께 직접 제안하고 승인을 받아 혼자 개발을 시작했습니다. 학생·학부모·교사가 각자의 화면으로 쓰는 웹 서비스로 4주 만에 바꿨습니다.

하루 30분 걸리던 출석 처리는 3분으로 줄었습니다. 이 첫 현장이 "반복 노동을 시스템으로"라는 이야기의 출발점입니다.

sungsan-center — 메인

실제 운영 중인 서비스의 구동 화면

1인기획 · 개발 · 운영
4주첫 배포까지
3사용자 역할 · 학생 · 학부모 · 교사
02데스크톱 앱 · 자동화 파이프라인 · 매일 사용

CH.2 — 자동화

사람이 매일 반복하던
수십 개 사이트 순회

K-pop 구매대행 실무의 이벤트 소싱을, 64개 쇼핑몰을 자동 수집·검증하는 데스크톱 앱으로 통합했습니다. 단순 크롤러가 아니라 목록 → 디테일 → 주문서 실측 → 브리핑까지 도는 파이프라인입니다.

macOS·Windows 설치형 배포 · 실무에서 매일 사용 중 · v1.0.7

STEP 01

목록 수집

플랫폼별 디스패치로 64개 쇼핑몰 이벤트 목록을 긁고 상태(진행/만료/품절)를 판정.

STEP 02

디테일 추출

본문·기간·특전·응모 조건을 파싱. OCR로 포스터 응모 마감까지 회수.

STEP 03

주문서 실측

로그인→상품→장바구니→주문서까지 진입해 받아야 할 입력 항목을 실측, 장바구니는 원복.

STEP 04

브리핑

새 이벤트·마감 임박·할 일을 하루 요약으로. 사람이 검토할 것만 남긴다.

kpop-event-scraper — 실행 로그 발췌 · 가독성 위해 재조판
$ npm run scrape:cli

# 01 목록 수집 — 플랫폼별 디스패치로 순회
[cli-scrape]  [62/64] 올리브영 Global (JS)
[cli-scrape]  [64/64] · 64 shops / 1,355 events

# 02 디테일 추출 — 정적/동적 자동 분기
[detail-pass] yg_select         events=9   detailTargets=7   static=7
[detail-pass] oliveyoung_global events=24  detailTargets=24  dynamic=10

# 03 주문서 실측 — 로그인 → 상품 → 장바구니 → 주문서
[follow] withmuu OK  …/goods_view.php?goodsNo=1000016  fields=12 reqInfo=10
[follow] oliveyoung_global skipped: parent has usable form (5 fields)

# 상태 판정(결정적) — 만료·오래된 이벤트 자동 회수
[expired] AMPERS&ONE 4th Mini 'DEFINITION' — ended 2026-07-05
[scraper] trim: filter kept 0/2 (dropped 2 events older than 90d)

✓ 수집 사이클 완료  64개 쇼핑몰 순회 · 1,355 이벤트 · 새 이벤트·마감 임박만 브리핑 상단에

실제 수집 1회 실행의 로그 발췌 — 수치·경로는 그대로, 한국어 주석·색은 가독성용.

실측

목록만 긁지 않고,
주문서까지 들어가 확인합니다

가능한 쇼핑몰은 로그인 → 상품 → 장바구니 → 주문서까지 자동 진입해, 고객에게 실제로 받아야 할 입력 항목(응모자명·생년월일·연락처 등)을 실측합니다.

사이트별 예외는 64개 샵을 포함한 77개 모듈에 격리하고, 공통 엔진은 플래그로만 확장합니다. 한 사이트를 고쳐도 나머지가 깨지지 않는 구조입니다.

kpop-event-scraper — 실행 데모

실제 실행 — 64개 쇼핑몰 수집(고속 재생) → 이벤트 그리드·리스트·성과 대시보드 · 무음 자동재생

CH.3 — AI

AI를 붙이는 게 아니라,
AI가 틀리면 어떻게 잡는가

이벤트 분류·OCR·구글폼 초안 에이전트·런북 RAG — 그리고 그 위에 결정적 회귀 가드. 판단은 AI에 맡기되, 결론은 재현 가능한 규칙으로 못박습니다.

npm run eval:golden 실행 결과 — 골든셋 112케이스 100% 통과(112/112), 회귀 새로 깨짐 0, 도입 95.5% → 결함 5건 수정 → 100%

결정적 회귀 하네스 — 만료·품절·기간·분류 판정을 골든셋 112케이스에 재실행. 무엇이 새로 깨졌는지 매번 즉시 보고. 112/112 통과 · 새로 깨짐 0 · 95.5% → 100%

구글폼 초안 에이전트 실행 — 주문서 raw 실측 113필드를 문항 15개로 정리(약 7.5:1), tool 3회, 자동 발행 안 함

구글폼 초안 에이전트 — 노이즈 113필드 → 문항 15개(≈7.5:1). tool-use 멀티스텝, 자동 발행 없이 사람 검토.

런북 RAG 질의 — 답변에 근거 문서 경로·섹션([1][3]) 인용, 근거 없는 질문엔 '문서에 없음'

런북 RAG — 답마다 근거 문서·섹션 인용. 근거 없으면 지어내지 않고 "문서에 없음".

결정적 가드레일

만료·품절·진행중 판정은 AI가 아니라 결정적 로직. 골든셋 회귀 하네스가 매번 "무엇이 새로 깨졌는지"를 즉시 말한다 — AI 비결정성을 평가 밖으로 분리합니다.

CH.4 — 신뢰성

만든 것을
계속 돌게 하는 능력

서킷 브레이커, 인증 자동복구 에스컬레이션, 장애 진단, 감사 이력 — 혼자 운영해도 조용한 회귀가 돌아오지 않게 만드는 SRE 감각.

서킷 브레이커

3연속 실패 샵을 자동 격리, 직전 정상 데이터는 지키고 복구 경로를 연다.

인증 자동복구

세션 만료 감지 → 6h → 24h → manual 에스컬레이션. 안티봇을 자극하지 않는 백오프.

sleep-guard

수면 중 600s 타임아웃 오탐의 근본원인 진단 → 하트비트 갭 감지로 근절.

테스트 · 감사

유닛 1,097개 + 라이브 실측 감사. 리팩터가 회귀를 만들면 즉시 잡힌다.

23자동 로그인 사이트
12지원 플랫폼
77격리 샵 모듈 · 활성 64
v1.0.7DMG · Windows CI 배포

아키텍처

한 사이트를 고쳐도
나머지가 안 깨지는 구조

공통 엔진은 플랫폼별로 디스패치되고, 사이트별 예외는 샵 모듈에 격리됩니다. 엔진의 예외 동작은 오직 플래그 게이트로만 켜져 — 플래그가 없는 샵은 그 코드 경로에 아예 진입하지 않습니다.

CH.5 — 임팩트

도입 전 / 후

문제에서 출발해 수치로 증명합니다. 실무 워크플로(소싱 → 공유 → 구매) 안에서 병목을 도구로 바꿨습니다.

출석 처리

하루 30분 수기 → 3분. 선생님의 시간을 아이들에게 돌려줌.

이벤트 소싱

수십 개 사이트 수작업 순회 → 하루 5~6회 자동 수집·검증.

AI-NATIVE

어떻게 혼자
64개 샵을 유지하는가

앱 본체 약 5.7만 줄(테스트·fixture 제외)·64개 샵을 한 사람이 유지합니다. 손이 빠른 게 아니라, 검증을 확장하는 워크플로입니다.

규약을 코드로 (CLAUDE.md)

샵별/공통 편집 경계·git 위생·프로세스 보호를 문서로 못박아 매 세션 주입. 같은 실수를 반복하지 않는 표준.

병렬 검증 오케스트레이션

독립 하위 작업을 여러 에이전트에 팬아웃. "혼자 못 보는 것"을 여러 눈으로 본다.

적대적 리뷰

만든 것을 스스로 반박. 그럴듯하지만 틀린 것을 머지 전에 거른다.

메모리 · 감사 루프

배운 것을 파일 메모리로 축적, 상시 하네스로 회귀를 막는다. 문서화가 감사를 강제해 잠재 버그를 잡은 실사례(PR #66).

규약 → 병렬 검증 → 적대적 리뷰 → 문서화 중 버그 발견 → 당일 수정. 다섯 축이 하루에 다 돌아간 사건을 케이스 스터디 ④에서 전문으로 읽기

다음 현장을
찾고 있습니다.

사람에게만 쌓이던 업무 경험을, 회사에 남는 시스템으로 바꾸는 일을 합니다.

ubin0612@icloud.com

이력서·상세 경력은 이메일로 요청해 주세요.