자동화 slecs

연도 범위 한계 극복과 문서화 강화

목차

discover_groups 봇이 그룹 데이터를 수집할 때 연도 범위가 고정돼 있었다. 이번 작업에서 그 범위를 확대하고 동시에 문서를 정리했다.

시간 범위 제한의 함정

자동화 봇은 보통 처음 설계할 때 "일단 지금부터 역으로 N년"이라는 식의 고정 범위로 짜인다. 개발 당시엔 충분하지만, 시간이 지나면서 문제가 생긴다. 예를 들어 3년 전 데이터만 수집하도록 설정했다면, 8년 전 자료는 영영 놓친다. 특히 주기적인 현상(시즌별, 연도별 트렌드)을 다루는 시스템이라면 더 심각하다.

우리 경우도 마찬가지였다. 초기 설계 시 "최근 데이터만 있으면 되겠다"는 생각으로 연도 범위를 좁게 설정했는데, 나중에 "5년 전 데이터도 봐야 한다"는 요구사항이 들어온 것. 이런 식으로 후속 작업들이 쌓이면 기술 부채가 되고, 결국 한 번에 정리해야 한다.

범위 확대의 결정

단순히 범위를 늘리는 것도 고민이 필요했다. 얼마나 멀리까지 가야 할까?
- 너무 멀면 오래되고 부정확한 데이터까지 끌어온다
- 너무 짧으면 또 다시 이 작업을 반복한다
- 데이터 신뢰도와 커버리지의 트레이드오프

결국 "합리적으로 예상되는 활용 범위"로 설정했다. 도메인 지식과 실제 요청 패턴을 바탕으로 충분한 여유를 두되, 수집 성능이나 데이터 품질을 해치지 않는 선에서.

문서화가 결정적이었던 이유

항목 변경 전 변경 후
연도 범위 설정 코드에만 하드코딩 명확한 주석 + 문서
유지보수자 온보딩 "왜 이 숫자?"라고 물어봄 "문서 참고, 이유는 여기"
다음 변경 시 판단 이 범위가 정말 필요한지 불명확 의도가 명확해 합리적 판단 가능

자동화 봇은 한 번 설정하면 "숨어서" 동작한다. 누군가 이 코드를 다시 건드릴 때는 보통 1년 이상 지났을 때다. 그 시점에 "왜 2015년부터?"라는 질문에 답할 수 있어야 한다. 문서 없으면 그냥 최대한 보존적으로 건드리지 않거나, 임의로 바꿔버린다.

회고: 시간 관련 설정의 패턴

이 류의 작업을 하면서 배운 건, 초기 설계 시 "고정 범위"는 피하는 게 낫다는 것.

  • 의도를 문서화하라 (숫자 뒤의 비즈니스 로직)
  • 필요하면 설정 파일로 분리해서 쉽게 바꿀 수 있게 하라
  • 특히 자동화 시스템은 "누가 언제 왜 손댈지" 모르니 유지보수성을 최우선으로

이번 작업은 작은 것처럼 보이지만, 팀의 다음 사람이 몇 시간 더 효율적으로 일하게 되는 거다. 그게 자동화의 가치다.


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

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

댓글 0

첫 댓글 달아줘.