기사 데이터 생성 시 날짜 임의 단정 제거

우리 팀에서 관리하는 기사 시드 데이터 생성 스크립트(bot/seed_articles.py)에 날짜 관련 fix를 적용했다. 그간 테스트·개발 편의상 과거나 미래 연도를 구체적으로 박아놓던 관행을 버리고, 연도 기준 중립표현으로 통일하기로 한 것이다. 겉보기엔 사소한 수정이지만, 이걸 통해 팀의 데이터 정책을 어떻게 강제할지, 그리고 왜 시드 스크립트 같은 "주변" 코드까지 신경 써야 하는지를 다시 생각해 봤다.

문제: 정책과 실제 코드의 괴리

회사 전사 기준으로 "명시적인 미래·과거 날짜 단정을 피하라"는 규칙이 있다. 이건 외부 문서나 공식 채널에선 잘 지켜지는데, 개발 영역의 시드 데이터에선 자주 빠진다. 개발자 입장에선 "테스트용이니까 상관없지 않나"라고 생각하기 쉽기 때문이다.

하지만 시드 스크립트에 "published": "2023-03-15" 같은 고정값이 들어가면, 이 데이터는 여러 곳에서 재사용된다:
- 문서화 예시
- 통합 테스트 셋
- 새 팀원 온보딩 시 학습 자료
- 다른 팀의 API 테스트

그러면서 정책 위반이 자연스럽게 확산된다. 팀에서 "왜 이 기사는 2025년인데 시스템에 있지?"라는 질문이 나오면, 그때는 이미 여러 곳에 영향을 미친 상태다.

해결: 정책을 코드로 강제하기

이번 fix의 핵심은 "정책을 코드 수준에서 강제하자"는 의사결정이었다. 단순히 "앞으로 날짜를 이렇게 하세요"라고 말하는 대신, 시드 스크립트 자체를 수정해서 미래/과거 명시 구조를 원천 차단하는 것이다.

코드 레벨로는 이렇게 바뀌었다:

# Before: 구체적 미래/과거 날짜 고정
articles = [
    {"title": "AI 트렌드", "date": "2025-12-01"},   # 미래?
    {"title": "지난 성과", "date": "2022-06-15"},   # 과거 고정
]

# After: 연도만 명시, 일자 제거
articles = [
    {"title": "AI 트렌드", "year": "2026"},
    {"title": "지난 성과", "year": "2026"},
]

필드 이름도 date 에서 year 로 바꿔서, 스키마 레벨에서 "이건 연도 데이터입니다"를 명확히 했다. 그러면 누군가 이 스크립트를 보거나 수정할 때 자동으로 "아, 여기선 연도만 쓰는 구나"를 인지하게 된다.

코드 리뷰 관점: 시드 데이터도 "코드다"

이 작업을 하며 느낀 건, 시드 데이터나 테스트 픽스처는 보통 코드 리뷰의 맹점이 된다는 것이다. 리뷰할 때 "어차피 테스트용인데"라며 대충 패스하기 쉽다. 하지만 시드는 문서이자 표준이다. 신입이 시스템을 배울 때 제일 먼저 본다. 팀의 관례와 패턴이 녹아 있는 곳이다.

그래서 코드 리뷰 때 시드 스크립트에 특히 신경 쓰도록 팀에 강조하기 시작했다:
- 우리 정책을 위반하는 부분이 있나?
- 새 팀원이 이걸 보고 잘못 배우진 않을까?
- 이 패턴이 다른 곳에 복사되면 문제가 안 될까?

작은 수정일수록 더 꼼꼼하게 본다. "사소한 부분"이 그대로 팀의 표준이 되기 쉽기 때문이다.

멘토링 측면: 정책을 구조로 만들다

이 fix를 팀과 논의할 때, 처음엔 "그냥 문서에 규칙을 쓰면 되지 않나?"라는 의견도 있었다. 하지만 결국 우리가 택한 건 "정책을 코드 구조로 만들자"는 것이다. 이유는 단순하다.

기억에 의존하지 않기: "규칙이 있다"는 말보다 "스크립트가 이렇게 돼 있다"는 게 훨씬 강하다. 새 팀원도, 문서를 읽지 않으면 코드를 봐야 한다. 자연스레 배운다.

정책 강제 vs 신뢰 기반 리딩 — 팀 리딩에서 자주 마주치는 트레이드오프다. 신뢰 기반은 팀원의 성숙도에 의존하고, 구조 기반은 실수를 처음부터 못 하게 만든다. 반복되는 실수나 크리티컬한 정책일수록 구조로 강제하는 게 맞다. 이번 경우가 바로 그것이었다.

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

• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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