연도 범위 한계 극복과 문서화 강화
목차
discover_groups 봇이 그룹 데이터를 수집할 때 연도 범위가 고정돼 있었다. 이번 작업에서 그 범위를 확대하고 동시에 문서를 정리했다.
시간 범위 제한의 함정
자동화 봇은 보통 처음 설계할 때 "일단 지금부터 역으로 N년"이라는 식의 고정 범위로 짜인다. 개발 당시엔 충분하지만, 시간이 지나면서 문제가 생긴다. 예를 들어 3년 전 데이터만 수집하도록 설정했다면, 8년 전 자료는 영영 놓친다. 특히 주기적인 현상(시즌별, 연도별 트렌드)을 다루는 시스템이라면 더 심각하다.
우리 경우도 마찬가지였다. 초기 설계 시 "최근 데이터만 있으면 되겠다"는 생각으로 연도 범위를 좁게 설정했는데, 나중에 "5년 전 데이터도 봐야 한다"는 요구사항이 들어온 것. 이런 식으로 후속 작업들이 쌓이면 기술 부채가 되고, 결국 한 번에 정리해야 한다.
범위 확대의 결정
단순히 범위를 늘리는 것도 고민이 필요했다. 얼마나 멀리까지 가야 할까?
- 너무 멀면 오래되고 부정확한 데이터까지 끌어온다
- 너무 짧으면 또 다시 이 작업을 반복한다
- 데이터 신뢰도와 커버리지의 트레이드오프
결국 "합리적으로 예상되는 활용 범위"로 설정했다. 도메인 지식과 실제 요청 패턴을 바탕으로 충분한 여유를 두되, 수집 성능이나 데이터 품질을 해치지 않는 선에서.
문서화가 결정적이었던 이유
| 항목 | 변경 전 | 변경 후 |
|---|---|---|
| 연도 범위 설정 | 코드에만 하드코딩 | 명확한 주석 + 문서 |
| 유지보수자 온보딩 | "왜 이 숫자?"라고 물어봄 | "문서 참고, 이유는 여기" |
| 다음 변경 시 판단 | 이 범위가 정말 필요한지 불명확 | 의도가 명확해 합리적 판단 가능 |
자동화 봇은 한 번 설정하면 "숨어서" 동작한다. 누군가 이 코드를 다시 건드릴 때는 보통 1년 이상 지났을 때다. 그 시점에 "왜 2015년부터?"라는 질문에 답할 수 있어야 한다. 문서 없으면 그냥 최대한 보존적으로 건드리지 않거나, 임의로 바꿔버린다.
회고: 시간 관련 설정의 패턴
이 류의 작업을 하면서 배운 건, 초기 설계 시 "고정 범위"는 피하는 게 낫다는 것.
- 의도를 문서화하라 (숫자 뒤의 비즈니스 로직)
- 필요하면 설정 파일로 분리해서 쉽게 바꿀 수 있게 하라
- 특히 자동화 시스템은 "누가 언제 왜 손댈지" 모르니 유지보수성을 최우선으로
이번 작업은 작은 것처럼 보이지만, 팀의 다음 사람이 몇 시간 더 효율적으로 일하게 되는 거다. 그게 자동화의 가치다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.