개발 slecs

신규 사이트 온보딩, 40번째를 채우기까지

목차

어제 밤 9시부터 자정 언저리까지 한 일을 한마디로 요약하면 이렇다 — "사이트 하나 추가했다." 근데 그게 그렇게 단순하지 않다. 사이트 하나를 제대로 온보딩한다는 건, 우리 인프라 위에 얹혀 있는 파싱 파이프라인·PV 집계·대시보드·포트폴리오 쇼케이스까지 최소 네 군데를 일관되게 건드려야 한다는 뜻이다. 그리고 그 마지막 퍼즐 조각이 맞물렸을 때 카운터가 40을 찍었다.


왜 이 시간에 이 작업을?

솔직히 말하면 낮에 밀려있던 거다. cpsrush.com 자체는 이미 서비스 중이었고, 도메인도 올라가 있었지만 우리 모니터링·집계 체계에는 아직 등록이 안 된 상태였다. 이런 상황이 생기는 이유는 늘 비슷하다 — 배포 먼저, 연동 나중. 급하게 사이트를 띄우고 나서 "나중에 통계 붙이지 뭐" 하고 넘어가는 패턴. 팀장 입장에서 가장 위험한 기술 부채 중 하나인데, 정작 본인이 이걸 가장 많이 만들어내고 있다는 아이러니가 있다.

그래서 이날 밤에 잡아서 처리하기로 했다. 미뤄봤자 하루가 지나면 PV 데이터가 더 날아가고, 주간 대시보드 리포트에 구멍이 생긴다.


작업 순서와 흐름

커밋 순서가 실제 작업 흐름을 거의 그대로 반영한다.

순서 파일 핵심 변경
1 overseas-parse.py, site-pv.py HOST_LOGS에 cpsrush.com 추가, PV 집계 라우팅
2 scripts/stats-dashboard.py DISPLAY_ORDER 40번째 슬롯 등록
3 index.html, thumbs/cpsrush.jpg 포트폴리오 tools 카테고리에 썸네일 포함 등재

가장 먼저 손댄 건 overseas-parse.py였다. 우리 PV 집계 구조상 해외 서버에서 오는 로그는 overseas-parse가 먼저 받아서 정제한 뒤 site-pv 쪽으로 넘기는 방식이다. 여기에 HOST_LOGS 엔트리가 빠지면 아무리 다른 데서 설정해도 데이터가 0으로 잡힌다. 이게 첫 관문이다.

# overseas-parse.py — HOST_LOGS 등록 예시 (실제 값 마스킹)
HOST_LOGS = {
    ...
    "cpsrush.com": "/var/log/nginx/cpsrush.access.log",
    ...
}

그 다음 site-pv.py에서 display 레이어 연결. overseas-parse가 파싱해서 던진 PV 수치를 화면에 올려주는 쪽이다. 여기도 사이트 키가 일치해야 하기 때문에 반드시 같은 이름으로 등록해야 한다. 이름 하나 삐끗하면 대시보드에서 0 또는 None으로 뜨는데, 처음에 이걸 모르고 오타 하나로 30분 날린 기억이 있다. 그 이후로는 복붙 + 확인 루틴을 반드시 밟는다.


대시보드 DISPLAY_ORDER — 40이라는 숫자

stats-dashboard.py에 cpsrush.com을 등록하면서 DISPLAY_ORDER가 40번째로 채워졌다. 숫자 자체가 뭔가를 보장하진 않는다. 사이트 품질이 고르지도 않고, 활성도도 다 다르다. 그냥 우리가 운영하거나 관리 중인 웹 자산이 40개 라인업이 됐다는 것.

근데 팀장 입장에서 이 숫자는 꽤 의미가 있다. 각각의 사이트가 파이프라인에 정상 등록됐다는 건 — 최소한 PV가 집계되고, 대시보드에서 상태를 볼 수 있고, 문제가 생겼을 때 모니터링 체계 안에 포함된다는 뜻이다. 등록 안 된 사이트는 사실상 블랙박스다. 뭔가 잘못돼도 우리가 먼저 알 수가 없다.

DISPLAY_ORDER는 단순한 나열 순서처럼 보이지만, 실제로는 대시보드 리포트에서 섹션 배치와 우선순위 정렬에 영향을 준다. 그래서 새 사이트를 어디에 꽂을지도 대충 하면 안 된다. cpsrush.com은 tools 카테고리 계열이라 해당 그룹 끝자락에 배치했다.


포트폴리오 등재 — 작지만 빠뜨리면 안 되는 이유

마지막 커밋이 index.html + 썸네일이다. 이건 기술적으로 가장 단순한 작업이지만, 팀 차원에서는 "이 사이트 우리가 만든 거 맞아요"를 외부에 선언하는 행위다. tools 카테고리에 넣었고, 썸네일 이미지(cpsrush.jpg)도 함께 커밋했다.

포트폴리오 업데이트를 깜빡하면 나중에 레퍼런스 요청이 왔을 때 "어, 그거 만들었는데 왜 없지?"가 된다. 이런 누락이 쌓이면 포트폴리오 신뢰도가 전체적으로 떨어진다. 그래서 사이트 온보딩 체크리스트에 포트폴리오 등재를 명시적으로 넣어놨고, 이번에도 그 흐름대로 마무리했다.


이 작업에서 건진 것

  • 온보딩 루틴의 순서는 바꾸지 마라. 파이프라인 → 대시보드 → 포트폴리오. 역순으로 하면 반드시 뭔가 빠진다.
  • 40이라는 숫자는 관리 비용이기도 하다. 사이트가 늘수록 overseas-parse와 site-pv의 HOST_LOGS 관리가 복잡해진다. 언젠가 이 부분을 설정 파일로 분리해서 코드 수정 없이 등록할 수 있게 만들어야 할 시점이 오고 있다.
  • 밤에 하는 연동 작업은 집중력이 좋다. 대신 테스트 사이클을 줄이는 경향이 있어서, 다음날 아침에 꼭 대시보드 수치 확인을 한 번 더 해야 한다.

자정 넘어서 마지막 커밋 푸시하고 대시보드 새로고침했을 때 cpsrush.com 행에 PV 숫자가 올라오는 걸 보는 게 이 작업의 마무리다. 별거 아닌 것 같아도 그 숫자 하나가 "이 사이트는 이제 우리 체계 안에 있다"는 확인이다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.