[Git Ranker #1] 홈랩에서 배우는 대용량 배치 처리 - 기획편
1. 텅 빈 미니 PC 서버에 활기를 불어넣자
홈랩 구축과 남겨진 숙제
최근 개인 학습과 서버 관리 역량을 키우기 위해 미니 PC를 장만하여 개인 서버 환경을 구축했습니다. 하드웨어는 준비되었지만, 아직 제 서버는 운영체제만 설치된 ‘텅 빈 깡통’ 이나 다름없습니다.
앞으로 이 위에 Docker 컨테이너 환경, CI/CD 파이프라인, 인프라 보안 등등 하나씩 직접 구축해 나갈 예정입니다.
하지만, 단순히 인프라 기술만 공부해서는 “왜 이 기술이 필요한지” 체감하기 어렵다는 생각이 들었습니다.
“실제 트래픽이 발생하고, 의미 있는 데이터가 쌓이는 애플리케이션이 있어야 인프라 구축의 재미도 느끼지 않을까?”
트래픽 없는 서버에서 모니터링을 배울 수 있을까 ?
단순히 혼자 쓰는 도구나 사용자가 없는 CRUD 게시판 정도로는 서버가 한계에 부딪히는 상황(CPU Spike, I/O 병목, OOM 등) 을 경험하기 어렵습니다.
저는 서버가 힘들어하는 환경을 만들고 제가 그 원인을 찾아 튜닝하는 운영 경험이 필요했습니다.
프로젝트의 조건
그래서 저는 나름대로 두 가지 조건을 만족하는 프로젝트를 기획하게 되었습니다.
- 높은 접근성 : 로그인 장벽 없이 누구나 재미로 사용하여 트래픽이 쉽게 모일 것
- 기술적 밀도 : 겉보기엔 단순해도, 뒷단에서는 대용량 데이터 처리(Batch) 와 복잡한 연산이 돌아가 서버 리소스를 극한으로 활용할 것
2. Git Ranker란 무엇인가 ?
GitHub의 잔디는 개발자의 성실함을 보여주는 직관적인 지표지만, 맹점도 존재합니다. 단순 오타 수정도 1commit, 핵심 로직 리팩토링도 1commit으로 처리됩니다.
즉 ‘양(Quantity)’은 보여주지만 ‘질(Quality)’은 보여주지 못합니다.
( 추후 커밋 메시지 분석을 위한 AI/NLP 도입도 고려 중입니다…! )
핵심 기능
Git Ranker는 GitHub 사용자의 Public 활동 데이터를 분석하여 활동의 가치를 반영한 점수(Score)를 산정합니다. 그리고 이를 실시간 랭킹 배지 형태로 제공하여 자신의 README.md 에도 달 수 있게 합니다.
- 사용자 등록 (No-Login): 웹사이트에서 GitHub ID만 입력하면 즉시 분석 시작
- 데이터 수집 (Batch): 매일 새벽, 등록된 유저들의 활동 데이터를 수집 및 가공
- 랭킹 산정 (Batch): 전체 유저 대비 백분율(상위 N%) 및 티어(Tier) 산출
- 배지 서빙 (API):
https://api.gitranker.com/badge/{username}호출 시 최신 SVG 이미지 반환.
가중치 시스템 (Beta)
현재 기획된 초기 가중치는 아래와 같으며, 추후 데이터 분석을 통해 지속적으로 튜닝할 예정입니다.
- Commit (1점): 기본 활동
- Issue Open (2점): 문제 제기 및 커뮤니케이션
- Code Review (3점): 타인의 코드 검증 및 기여
- PR Open (5점): 적극적인 기여 활동
- PR Merged (10점): 기여 인정
3. 프로젝트 목표
이 프로젝트는 단순히 서비스를 런칭하는 것을 넘어, 주니어 백엔드 개발자로써 세 가지 경험을 깊이 있게 파고드는 것을 목표로 합니다.
1. 인프라 구축과 모니터링 경험
애플리케이션을 개발하면서 Docker 기반의 배포 환경과 Jenkins/Github Actions를 활용한 CI/CD를 직접 밑바닥부터 구성해볼 계획입니다.
또한, 배치 작업이 도는 새벽 시간대에 CPU가 치솟고 HikariCP 커넥션 풀이 바닥나는 상황을 관찰하며, 미니 PC라는 제한된 리소스 환경에서 서버가 뻗지 않게 튜닝하는 경험을 쌓고자 합니다.
2. Spring Batch의 엔터프라이즈급 활용
단순한 스케줄러(@Schedueld)가 아닌, 대량의 데이터를 Chunk 단위로 쪼개서 처리하고, 실패 시 재시도하거나 건너뛰는 배치 프레임워크와
몇 명의 사용자가 사용할지는 미지수이지만, 사용자가 늘어남에 따라 매일 발생하는 대량의 UPDATE 쿼리와 DB I/O 병목을 해결하는 과정을 경험해보고자 합니다.
3. 데이터 파이프라인 설계 (ETL)
GitHub라는 외부 소스에서 데이터를 추출(Extract)하고, 가중치를 적용해 변환(Transform)하고, 저의 DB에 적재(Load)하는 전체 파이프라인을 설계하며 데이터 정합성을 지키도록 신경쓰려고 합니다.
4. 기획 단계에서의 기술적 의사결정
기획 단계에서 고민한 문제들과, 이를 해결하기 위해 선택한 기술적 대안들을 비교 분석했습니다.
Issue 01. 데이터 접근 권한과 사용자 경험의 충돌
Q. Private Repository의 활동까지 포함할 것인가 ?
- 선택지 A : 인증 및 인가 시스템을 도입하여 Private 활동도 포함
- 보안상 비공개(회사 업무)로 작업하는 활동들에 대해서도 모두 집계가 가능해 데이터가 정확
- 보안 토큰 관리 복잡성 증가
- 선택지 B : 로그인 없이 Public 활동만 사용 (선택)
- ID 입력만으로 끝나기 때문에 접근성이 좋아 초기 트래픽 확보에 유리함
- 회사 업무와 같은 Private 활동들에 대해서는 누락
⇒ 이 프로젝트의 1차 목표는 트래픽 확보를 통한 모니터링 경험입니다. 완벽한 데이터보다는, 누구나 쉽게 들어와서 내 서버에 로그를 남겨주는 것이 더 중요하다고 판단하여 과감하게 로그인을 제거했습니다.
Issue 02. 신규 유저의 데이터 초기화
Q. 오늘 가입한 유저의 점수는 0점부터 시작할 것인가 ?
- 선택지 A : 0점부터 시작
- 로직이 단순하다는 장점이 있음
- 그동안 열심히 해온 개발자에 대해서도 가입 첫날에는 “랭킹 꼴찌”가 되기 때문에, 사용자가 배지를 달 동기가 사라짐
- 선택지 B : 최근 1년 데이터부터 시작 (선택)
- 가입 즉시 유의미한 랭킹을 제공할 수 있음
- 가입 시점에 API 호출 비용이 발생
⇒ 서비스의 매력도를 위해 UX를 우선했습니다. 가입 시점에는 ‘최근 1년’ 데이터를 실시간으로 가져오고, 그 이후부터는 ‘어제 하루’ 데이터만 배치로 더해나가는 방식으로 기획했습니다.
5. 기획을 마치며
단순히 돌아가는 코드를 짜는 것이 아니라, “왜 이 기술을 썻는가?” 에 대해 계속해서 묻고 답하는 과정으로 개발해 나갈 생각입니다.
앞으로 미니 PC라는 제약된 환경에서 수많은 데이터를 어떻게 소화해내는지, 그리고 그 과정에서 발생하는 이슈들을 어떻게 해결해 나가는지 블로그를 통해 꾸준히 기록하고 공유하겠습니다 !
댓글남기기