플레이스홀더 날짜로 인한 오류 방지

seed_articles.py 에서 아티클 샘플 데이터를 생성할 때 플레이스홀더 날짜 처리 방식을 개선했다. 지금까지는 게시 날짜를 알 수 없을 때 1월 1일(01-01)로 고정하고 있었는데, 이렇게 하면 나중에 그 데이터가 실제로 1월 1일 게시된 건지, 아니면 단순 플레이스홀더인지 구분이 안 되는 문제가 생긴다. 커밋 메시지에서 "정확일자 단정 방지"라고 한 것도 결국 그 의도다 — 임시 데이터와 실제 데이터의 경계를 명확히 하겠다는 뜻이었다.

플레이스홀더와 "그럴듯함"의 함정

개발 초기에 서비스 샘플 데이터를 만들 때는 보통 진짜 날짜를 일일이 준비할 수 없다. 그래서 플레이스홀더를 쓰는데, 여기서 실수하기 쉬운 게 "그럴듯한" 값으로 채우는 것이다. 01-01은 한 해의 첫날이라 자연스럽고, 코드 리뷰할 때도 "아 플레이스홀더네" 하고 넘어가기 쉽다. 그런데 데이터가 점점 늘어나고, 다른 팀에서 이 데이터를 참조하거나, 마이그레이션을 할 때는 어떨까? "어 이 데이터 1월 1일이 맞나?"라고 다시 확인해야 하는 상황이 생긴다.

실제로 우리 팀에서도 유사한 경험이 있었다. 초기 시드 데이터를 다른 시스템으로 옮길 때, "이 날짜들이 의도적인 건지 플레이스홀더인지"를 일일이 추적해야 했고, 그 과정에서 실수도 있었다. 수십 개의 아티클을 검토하면서 어느 것은 실제 날짜이고 어느 것은 플레이스홀더인지 판단하는 데 시간이 걸렸다. 이건 개인의 실수라기보다는 시스템 설계의 문제였다 — 명확함을 우선하지 않았으니까.

연도만으로 처리하기

이번 개선에서는 월일 부분을 제거하거나 미지정으로 표현하도록 변경했다. 코드 레벨에서는 이렇게 달라진다:

Before (플레이스홀더가 애매함)

articles = [
    {
        "title": "샘플 아티클 1",
        "published_at": "2026-01-01",  # 실제? 플레이스홀더?
    },
]

After (연도만으로 명시)

articles = [
    {
        "title": "샘플 아티클 1",
        "published_year": 2026,  # 명시적으로 연도만
        "published_at": None,    # 정확한 날짜 없음
    },
]

이렇게 하면 데이터를 다룰 때 명확하다 — "이건 정확한 월일이 없는 데이터다. 쿼리할 때 주의하자" 또는 "나중에 실제 날짜로 업데이트해야겠네."

데이터 신뢰도와 설계 원칙

이 변경은 한 줄짜리 수정처럼 보이지만, 사실 더 큰 철학의 문제다. 테스트와 샘플 데이터는 "가능한 한 명확하게" 의도를 드러내야 한다. 혼란의 여지를 남기면, 나중에 누군가는 그걸로 인해 시간을 낭비하거나 실수한다. 특히 팀원들이 이 데이터를 다루거나 마이그레이션할 때 더욱 그렇다.

팀장으로서 이런 개선을 리뷰하고 장려하는 이유:

비슷한 사례들도 있다:
- NULL vs. "0" vs. "unknown" — 의미를 명시적으로 구분
- 테스트 데이터의 특수 식별자 (test_, FIXTURE_)
- 주석으로 "TODO: 실제 값으로 바꾸기"

이런 작은 개선이 모여서 코드와 데이터의 신뢰도가 올라간다. 팀원이 이 코드를 읽을 때, "아 이건 플레이스홀더네. 일단 이 상태로도 돌아가지만, 나중에 실제 값이 필요하면 여기를 고치면 된다"고 명확히 이해할 수 있다. 그게 작지만 중요한 개선이다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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