웹 데이터 수집을 위한 대부분의 계획은 스크레이퍼를 위한 예산은 세우지만 사람은 잊어버린다. 첫 번째 버전은 작성하는 데 몇 주밖에 걸리지 않으므로 한 사람으로 이루어진 팀으로도 충분해 보인다. 그러다 사이트가 변경되고, 물량이 늘어나고, 고객이 잘못된 수치를 발견하면 그제서야 이 일이 스크레이퍼를 작성하는 일이 아니었다는 것이 드러난다. 이 일은 스크레이퍼를 계속 정확하게 유지하는 일이었다.
이 작업에 몇 명이 필요한지에 대한 신뢰할 만한 공개 벤치마크를 찾을 수 없었고, 어차피 단일 비율은 오해를 불러일으킬 것이다. 그래서 이 가이드는 역할들, 여러분 자신의 수치로 돌려볼 수 있는 작은 모델, 그리고 각 규모에서 먼저 무너지는 경향이 있는 지점을 제시한다.
인원 규모를 좌우하는 요소
데이터 양은 생각보다 중요하지 않다. 같은 소스에서 열 배 더 많은 페이지를 가져오는 것은 대체로 예산과 인프라의 문제다. 인원 규모는 네 가지 요소를 따른다:
- 소스의 수. 각 소스는 독립적으로 깨질 수 있기 때문이다.
- 얼마나 자주 깨지는가. 이는 사이트가 얼마나 자주 변경되는지, 접근하기가 얼마나 어려운지에 달려 있다.
- 얼마나 틀려도 괜찮은가. 주간 리서치 데이터셋은 기다릴 수 있다. 고객이 그에 따라 행동하는 가격 피드는 그럴 수 없다.
- 새로 추가하는 소스의 수. 온보딩은 유지보수와 같은 인력을 두고 경쟁하기 때문이다.
역할들
이것들은 직함이 아니라 역할이다. 작은 팀에서는 한 사람이 여러 역할을 맡을 수 있으며, 각 역할에 이름이 명확히 붙어 있는 한 문제없다.
| 역할 | 담당 업무 | 흔히 누락되는 시점 |
|---|---|---|
| 수집 엔지니어 | 스크레이퍼, 추출, 장애 수정 | 결코 빠지지 않음 |
| 플랫폼 엔지니어 | 스케줄링, 큐, 프록시, 브라우저, 스토리지, 비용 | 여러 사람이 같은 배관 작업을 반복할 때 |
| 데이터 품질 책임자 | 검증, 드리프트, “정확하다”의 의미 | 고객이 오류를 먼저 발견할 때 |
| 제품 또는 데이터 책임자 | 무엇을 수집할지, 우선순위, 소스 결정 | 모든 것이 긴급할 때 |
| 법무 및 컴플라이언스 담당자 | 범위, 약관, 개인정보, 승인 | 새로운 소스가 아무도 답할 수 없는 질문을 제기할 때 |
마지막 역할은 정규직일 필요는 거의 없지만, 이름이 지정된 사람이어야 한다. 짧게라도 작성된 데이터 수집 정책이 있으면 그 사람이 같은 질문에 반복해서 답하는 것을 막을 수 있다.
계획 모델
이 스크립트는 반복되는 작업을 시간으로, 시간을 사람 수로 변환한다. Python 3.9 이상 외에는 아무것도 필요하지 않다. 모든 숫자는 여러분 자신의 수치로 교체해야 할 가정이다. 지난 분기에 몇 번의 수정을 했는지, 그리고 그것이 얼마나 걸렸는지 세어보라.
"""A planning model for how many engineers a data collection operation needs.
Every default is an assumption to replace with your own numbers.
"""
from __future__ import annotations
import math
HOURS_PER_FTE = 30 # focused engineering hours per person per week
def team_size(sources, breaks_per_source_per_month, hours_per_fix, new_sources_per_month,
hours_per_new_source, weekly_platform_hours=20, weekly_support_hours=8):
"""Recurring hours become people; reserve a quarter of the time for project work."""
fixes = sources * breaks_per_source_per_month * hours_per_fix / 4.33
onboarding = new_sources_per_month * hours_per_new_source / 4.33
weekly = fixes + onboarding + weekly_platform_hours + weekly_support_hours
fte = weekly / (HOURS_PER_FTE * 0.75)
return {"fixes": round(fixes), "onboarding": round(onboarding),
"platform": weekly_platform_hours, "support": weekly_support_hours,
"weekly_hours": round(weekly), "fte": round(fte, 1), "people": math.ceil(fte)}
if __name__ == "__main__":
scenarios = {
"10 sources, stable": (10, 0.25, 4, 1, 16),
"50 sources, mixed": (50, 0.5, 4, 3, 16),
"200 sources, mixed": (200, 0.5, 4, 8, 16),
"200 sources, hard": (200, 1.5, 6, 8, 24),
}
print(f"{'scenario':22}{'fixes':>6}{'new':>5}{'platform':>9}{'support':>8}{'hrs/wk':>7}{'FTE':>6}{'people':>7}")
for name, args in scenarios.items():
r = team_size(*args)
print(f"{name:22}{r['fixes']:>6}{r['onboarding']:>5}{r['platform']:>9}{r['support']:>8}"
f"{r['weekly_hours']:>7}{r['fte']:>6}{r['people']:>7}")출력:
scenario fixes new platform support hrs/wk FTE people
10 sources, stable 2 4 20 8 34 1.5 2
50 sources, mixed 23 11 20 8 62 2.8 3
200 sources, mixed 92 30 20 8 150 6.7 7
200 sources, hard 416 44 20 8 488 21.7 22이 시나리오들은 측정값이 아니라 예시적인 입력값을 사용하며, 스크립트의 인자에 각각이 나타나 있다. 안정적인 소스는 넉 달에 한 번 깨지고 수정하는 데 네 시간이 걸린다. 까다로운 소스는 한 달에 한 번 반 꼴로 깨지고 여섯 시간이 걸린다.
두 가지가 눈에 띈다. 소스 50개에서 200개로 늘어날 때(혼합 난이도), 소스 수는 4배가 되지만 팀 규모는 약 2.4배만 늘어난다. 플랫폼 작업이 공유되기 때문이다. 그런 다음 같은 200개의 소스가 단지 유지하기가 더 어려워졌다는 이유만으로 7명에서 22명으로 늘어난다. 소스 수보다 장애 발생률이 인원 규모를 더 크게 움직인다. 그러므로 이것이 가장 먼저 측정해야 할 수치다.
이 모델은 각 사람의 시간 중 4분의 1을 프로젝트 작업을 위해 남겨둔다. 이는 빠듯한 수준이다. Google의 SRE 책은 운영 작업이 아닌 엔지니어링 작업에 최소 50%의 시간을 쓰는 것을 목표로 제시하며, 그 비율이라면 이 팀들은 1.5배 더 커질 것이다. 근본 원인을 고칠 시간이 아무에게도 없다면, 같은 장애가 계속 되돌아온다.
가장 먼저 무너지는 것
1~2명. 버스 팩터 문제다. 모든 것이 한 사람의 머릿속에만 있고, 휴가가 곧 장애가 된다. 각 소스가 어떻게 작동하는지, 어떻게 고치는지 기록해 두라. 인프라는 직접 운영하기보다 구매하라.
3~5명. 품질 문제다. 팀은 눈에 보이는 장애를 고치느라 바쁜 동안, 200 상태 코드와 함께 잘못된 필드를 반환하는 셀렉터 같은 조용한 장애가 쌓여간다. 품질 책임자를 지정하고, 상태 코드뿐 아니라 콘텐츠에 대해서도 파이프라인을 모니터링하라.
6~10명. 중복과 우선순위 문제다. 각 엔지니어가 자신만의 재시도 로직과 프록시 처리 방식을 만들었고, 모든 이해관계자의 소스가 긴급하다. 이때 플랫폼 책임자가 제 역할을 하며, “아니오”라고 말할 수 있는 제품 책임자도 함께 필요하다.
10명 이상. 조율과 온콜 문제다. Google의 SRE 책에 따르면, 두 명이 온콜을 서고 일주일 단위 교대 근무를 하는 단일 사이트 팀은 최소 8명의 엔지니어가 필요하다고 계산한다. 그런 체계를 구축해야 하는 데이터 팀은 거의 없다. 파이프라인이 혼자서 복구하고 나중에 따라잡을 수 있도록 설계하고, 고객이 진정으로 의존하는 부분에 대해서만 24시간 대응 체계를 유지하라.
필요한 인원 줄이기
- 범용 계층은 구매하라. 우리의 빌드 대 구매 가이드에서 직접 인프라를 운영하는 데 실제로 무엇이 필요한지 다룬다.
- 소스를 줄여라. 가치가 가장 낮은 소스 열 개를 폐기하는 것이 흔히 가장 저렴한 채용이다.
- 안정적인 경로를 선호하라. 공식 API, 피드, 구조화된 데이터는 HTML 셀렉터보다 덜 깨진다.
- 장애의 유형을 고쳐라. 공유된 재시도, 공유된 검증, 공유된 파서는 여러 개의 작은 불을 하나로 줄여준다.
결론
비율로 인원을 배치하지 말라. 소스 수, 장애 발생률, 얼마나 틀려도 괜찮은지에 따라 인원을 배치하고, 다음 채용 논의 전에 그 수치들을 측정하라. 품질 책임자를 일찍 지정하고, 경쟁력이 아닌 부분은 구매하며, 성장함에 따라 병목 지점이 이동할 것을 예상하라.
출처 및 참고자료
- Google, Site Reliability Engineering, Being On-Call: sre.google
- Google, Site Reliability Engineering, Eliminating Toil: sre.google