개발 slecs

재고 export에 git 레포 컬럼 추가로 디버깅 추적 강화

목차

재고 내역 export 기능에 git 레포 컬럼을 추가하고 REPO_MAP을 보강했다. 언뜻 통계 시스템에 왜 코드 저장소 정보가 필요할까 싶겠지만, 이 작은 변경에는 팀의 데이터 추적 전략이 담겨 있다.

왜 레포 정보가 필요했나

inventory_export는 상품, 재고, 재무 관련 통계를 뽑아내는 핵심 스크립트다. 그런데 현장에서 데이터를 검증하거나 이슈를 추적할 때, "이 재고 데이터가 어느 코드베이스에서 나왔는지" 알아야 할 순간이 생긴다. 예를 들어:

  • 여러 git 저장소에서 동시에 운영되는 마이크로서비스 환경
  • 재고 처리 로직이 여러 곳에 �산재해 있고, 각각 다른 팀이 관리하는 상황
  • 버그 리포트가 들어왔을 때 "어느 서비스의 문제인지" 빠르게 파악해야 하는 경우

이런 상황에서 export 데이터에 레포 정보가 있으면, 원인 추적과 책임 영역 파악이 훨씬 빨라진다.

구현 패턴: 레포 매핑 시스템

이번 작업의 핵심은 두 가지다.

첫째, inventory_export에 레포 컬럼 추가:

export 데이터 = [
    {
        sku: "SKU123",
        quantity: 100,
        status: "active",
        git_repo: "service-a",  # 추가됨
        ...
    },
    ...
]

각 재고 항목이 어느 서비스에서 나왔는지 명시적으로 기록하는 것이다.

둘째, REPO_MAP 보강:
단순히 repo 이름만 저장하는 건 불충분하다. REPO_MAP은 저장소와 서비스, 팀, 관련 메타데이터를 매핑하는 딕셔너리 역할을 한다. 이 맵을 보강함으로써:

용도 예시
저장소 이름 데이터 출처 추적 service-a, inventory-core
팀 소유권 이슈 할당 담당자 파악 payments-team, logistics-team
배포 환경 프로덕션/스테이징 구분 prod, staging
컨택 포인트 긴급 연락처 ops-slack-channel

이렇게 하면 export 데이터 하나로도 전체 컨텍스트를 파악할 수 있다.

팀 입장에서의 효과

이런 보강이 왜 중요한지는 운영 관점에서 본다면 명확하다.

디버깅 속도: 이전에는 "재고가 맞지 않다"는 리포트가 들어오면, 여러 서비스를 뒤져가며 "어디서 나왔을까" 찾아야 했다. 이제는 export 데이터에서 바로 레포를 알 수 있으니 직진한다.

책임 분산: 다양한 서비스가 관여하는 시스템에서 "누가 고쳐야 하나"는 조직 문제가 될 수 있다. REPO_MAP에 팀 정보를 명시하면 에스컬레이션이 자명해진다.

데이터 품질 개선: 통계와 코드 정보가 연결되면, 특정 서비스에서 나오는 데이터의 이상 패턴을 더 빨리 감지할 수 있다. "service-a에서만 null 값이 많네?" 같은 질문에 즉시 답할 수 있다.

일반론: 메타데이터 관리의 중요성

이 작업은 사실 작은 feature fix처럼 보일 수 있지만, 더 깊은 원칙을 담고 있다.

시스템이 커질수록 데이터의 출처를 명확히 하는 것이 점점 중요해진다. 로그하나, 통계 하나도 "누가 만들었나, 언제, 왜" 같은 메타데이터가 없으면, 나중에 문제가 터졌을 때 손도 못 쓴다.

비슷한 패턴:
- API 로그에 caller 정보 기록하기
- 배치 작업 결과에 실행 환경/버전 기록하기
- export 데이터에 스냅샷 시간과 데이터 신뢰도 기록하기

이런 것들이 쌓이면 나중에 "2주 전 어떤 일이 있었나" 질문에 거의 완벽하게 답할 수 있는 시스템이 된다.

구현하면서 배운 것

REPO_MAP을 보강하면서 느낀 건, 매핑 시스템은 변경에 강하기도 하고 약하기도 하다는 것이다.

강한 이유: 새 저장소가 생겨도 맵에만 추가하면 되므로 export 코드는 안 건드린다.

약한 이유: REPO_MAP 자체가 항상 최신 상태여야 하는데, 이걸 관리하는 책임이 명확하지 않으면 쉽게 썩는다. 새 팀이 생겼는데 맵을 업데이트 안 하면 기록이 부정확해진다.

그래서 이런 매핑은 보통 다음 중 하나로 관리한다:
- 배포 파이프라인에 자동 검증 단계 추가
- 주기적 감시 배치 ("REPO_MAP과 현재 repo list 비교")
- 리뷰 프로세스 강화 ("새 저장소 생성 시 REPO_MAP 업데이트 필수")

이 프로젝트에서는 어느 쪽을 선택했느냐에 따라, 앞으로 이 기능의 신뢰도가 결정된다.


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

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

댓글 0

첫 댓글 달아줘.