Context
풀어야 했던 문제.
배경
LG.com IT(모니터·노트북·프로젝터) 카테고리의 글로벌 사이트 운영 PMO를 맡았습니다.
본사 요청(글로벌 리퀘스트)과 신제품 콘텐츠 등록이 44개 로케일에서 어디까지 진행됐는지 매주 보고하는 것이 핵심 업무였습니다.
문제 정의
진행 현황 엑셀, 제작 벤더의 일일 작업 로그, 신제품 등록 데이터가 서로 다른 형식으로 흩어져 있어 매번 손으로 합쳐야 했습니다.
그 과정에서 완료율이 국가 수와 어긋나거나, 이미 내려간 페이지가 라이브로 표시되는 오류가 반복됐습니다.
제약사항
데이터 소스는 모두 외부 시스템의 내려받기 파일이라 형식이 예고 없이 바뀌었습니다.
내부 주소가 외부에 노출되지 않도록 산출물의 공개 범위도 엄격히 나눠야 했습니다.
Insight
핵심 판단.
- 01완료율의 기준을 "작업 행 수"에서 "국가별 사이트"로 바꿔야 본사가 보는 숫자와 운영팀이 보는 숫자가 일치했습니다.
- 02라이브 여부는 로그가 아니라 실제 URL 응답으로 판정해야 했습니다. 크롤러 실측을 리퀘스트 등록 전 필수 단계로 올렸습니다.
- 03소스 파일이 바뀔 때 조용히 틀린 숫자가 나가는 것이 가장 큰 위험이었습니다. 소스 점검과 빌드 검증을 통과해야만 배포되게 했습니다.
Solution
제가 맡아 해낸 일.
진행 현황·제작 로그·신제품 등록 데이터를 매일 정해진 시각에 합쳐, 분석용·고객 공유용 엑셀과 웹 대시보드 데이터를 생성하는 파이프라인을 만들었습니다.
대시보드에는 리퀘스트별 국가 진행률, 신제품 등록 추적, 라이브 URL 라이브러리, 통합 검색을 담았습니다.
라이브 URL은 크롤러로 실측해 등록하고, 내부 주소가 섞이면 빌드가 실패하도록 검증을 넣었습니다.
함께한 조직
본사 IT 카테고리 담당, 제작·게시 벤더, 번역 벤더, 사내 대시보드 운영팀
화면·기획 자료
대시보드 화면은 구조만 보이도록 고객 데이터를 흐림 처리한 것입니다. 파이프라인 코드와 엑셀 산출물은 내부 자료로 제외했습니다.
운영 대시보드 — 리퀘스트 상세
직접 구축한 대시보드의 리퀘스트 상세 화면. 왼쪽은 리퀘스트 목록과 진행률, 가운데는 사이트·페이지 수와 단계별 파이프라인, 아래는 국가별 현황표입니다. 리퀘스트명·모델명 등 고객 데이터는 흐림 처리했습니다.
LG.com 공식 사이트
운영 대상 사이트 참고 화면(미국) · 2026.09.12 캡처.
Walkthrough
화면을 차례로.
01 / 02
운영 대시보드 — 리퀘스트 상세
직접 구축한 대시보드의 리퀘스트 상세 화면. 왼쪽은 리퀘스트 목록과 진행률, 가운데는 사이트·페이지 수와 단계별 파이프라인, 아래는 국가별 현황표입니다. 리퀘스트명·모델명 등 고객 데이터는 흐림 처리했습니다.
Performance
범위와 성과.
약 2,000개 모델 · 27,000여 개 URL
라이브 URL 라이브러리
매일 자동 · 소스 점검 통과 시 배포
갱신 주기
이 프로젝트에서 얻은 것
- 01운영 보고의 신뢰는 "숫자의 기준"을 먼저 합의하는 데서 나옵니다. 같은 데이터라도 행 기준과 사이트 기준은 다른 답을 냅니다.
- 02자동화의 핵심은 계산이 아니라 소스가 바뀌었을 때 멈추는 장치입니다.
- 03공개 산출물과 내부 산출물을 처음부터 분리해 설계해야 나중에 노출 사고를 막을 수 있습니다.