productdb.json: 제품 데이터의 단일 출처

이 글은 productdb가 모든 제품 데이터, 즉 구성 요소, 기능, 호환성 규칙, 그리고 자재 명세서를 하나의 중앙 집중화된 파일에 정의함으로써 단일 출처로서 어떻게 작동하는지 설명합니다.

문제점: 흩어진 제품 데이터

제품 데이터는 여러 시스템에 걸쳐 흩어져 있을 수 있습니다:

재고 시스템: 부품 원가와 재고 수준
ERP 시스템: 자재 명세서와 생산 데이터
웹사이트: 제품 설명과 사양
회계: 가격 책정 및 원가 계산 규칙

데이터가 흩어져 있으면 불일치가 발생합니다:

웹사이트는 16GB RAM을 표시하지만, ERP는 8GB라고 표시함
가격 책정에 오래된 원가 데이터가 사용됨
자재 명세서가 실제 제품과 동기화되지 않음
기능이 현실과 일치하지 않음

우리는 모든 시스템이 참조할 수 있는 단일 출처가 필요합니다.

해결책: productdb.json

productdb.json은 모든 구성 요소, 그 기능, 호환성 규칙, 그리고 구성 요소들을 정의하는 JSON 파일입니다. 모든 시스템은 시작 시 이 파일을 로드합니다.

이 파일은 Git에서 버전 관리되어, 모든 변경 사항이 추적되고 감사 가능하도록 보장합니다.

파일 구조

파일은 구성 요소 카테고리별로 구성되어 있습니다:

{
  "Chassis": { ... },
  "Board": { ... },
# ... (구현 세부 사항 생략)

각 카테고리는 해당 속성을 가진 구성 요소들을 포함합니다.

구성 요소 정의

각 구성 요소는 여러 속성을 가집니다:

기본 속성

class: 호환성 매칭을 위한 구성 요소 클래스

"class": "THIN_MINI_ITX"

internal: 재고 및 생산을 위한 내부 이름

"internal": "Chassis, Treo"

external: 웹사이트 및 마케팅을 위한 고객 대상 이름

"external": "Thinvent® Treo Mini PC"

weight: 그램 단위의 물리적 무게

"weight": 590

호환성 규칙 (allows)

allows 필드는 어떤 구성 요소들이 함께 사용될 수 있는지를 정의합니다:

"allows": {
  "Board": [
    {"class": "THIN_MINI_ITX"}
# ... (구현 세부 사항 생략)

이는 다음을 의미합니다:

Board: 클래스가 THIN_MINI_ITX인 보드만 호환됨
Flash: 클래스가 m.2_SATA인 플래시 저장 장치만 호환됨
Accessories: 모든 액세서리가 호환됨

호환성은 다음과 같이 지정될 수 있습니다:

클래스 기반 (동적):

{"class": "THIN_MINI_ITX"}

부품 ID 기반 (명시적):

["N100", "N150", "i5-1335U"]

자재 명세서 (constituents)

constituents 필드는 이 구성 요소를 구성하는 부품들을 정의합니다:

"constituents": [
  {
    "Category": "Custom",
# ... (구현 세부 사항 생략)

이는 다음을 가능하게 합니다:

원가 계산: 모든 구성 요소의 원가 합산
생산: 조립을 위한 피킹 리스트 생성
재고: 구성 요소 사용량 추적

기능 제공 (provides)

provides 필드는 이 구성 요소가 제공하는 기능들을 정의합니다:

"provides": {
  "Operating Temperature": "0°C ~ 40°C",
  "Operating Humidity": "20% ~ 80% RH, non condensing",
# ... (구현 세부 사항 생략)

이러한 기능들은 SKU 내 모든 구성 요소에서 집계되어 제품의 완전한 사양을 생성합니다.

예시: Treo 케이스

{
  "Treo": {
    "class": "THIN_MINI_ITX",
# ... (구현 세부 사항 생략)

예시: N100 보드

{
  "N100": {
    "class": "THIN_MINI_ITX",
# ... (구현 세부 사항 생략)

productdb.json 로드

파일은 애플리케이션 시작 시 로드됩니다:

import json

with open(PRODUCTDB_JSON_PATH, "r", encoding="utf-8") as productdb_file:
    productdb = json.load(productdb_file)

이는 메모리 내 사전을 생성합니다:

productdb = {
    "Chassis": {
        "Treo": { ... },
# ... (구현 세부 사항 생략)

모든 코드는 제품 데이터를 위해 이 사전을 참조합니다.

구성 요소 데이터 접근

카테고리 및 ID로 구성 요소 가져오기

chassis = productdb["Chassis"]["Treo"]
board = productdb["Board"]["N100"]
ram = productdb["RAM"]["8"]

외부 이름 가져오기

name = productdb["Board"]["N100"]["external"]
# 결과: "Intel® N100 Processor"

기능 가져오기

features = productdb["Board"]["N100"]["provides"]
# 결과: {"Generation": "12th", "Series": "N", ...}

구성 요소 가져오기

constituents = productdb["Chassis"]["Treo"]["constituents"]
# 결과: [{"Category": "Custom", "PartID": "base_treo", "qty": 1}, ...]

SKU 검증

우리는 productdb.json을 사용하여 SKU를 검증합니다:

def check_sku(sku:str) -> bool:
    parts = sku.split("-")
    mapped_parts = map_parts_to_fields(parts)
# ... (구현 세부 사항 생략)

자세한 내용은 SKU 구조를 참조하세요.

기능 집계

우리는 SKU 내 모든 구성 요소의 기능을 집계합니다:

def get_product_features(sku: str) -> dict:
    partids = sku.split("-")
    features = {}
# ... (구현 세부 사항 생략)

예시:

SKU: Treo-N100-8-256-2H-W6-11P

기능:

- 폼 팩터: Mini PC (Treo에서)

- 세대: 12세대 (N100에서)

- 시리즈: N (N100에서)

- 코어: 4 (N100에서)

- 메인 메모리: 8 (8에서)

- SSD 저장 공간: 256 (256에서)

- HDMI: 2 (2H에서)

- 운영 체제: Windows 11 Pro (11P에서)

자세한 내용은 기능 추출을 참조하세요.

원가 계산

구성 요소 원가를 합산하여 SKU 원가를 계산합니다:

def calculate_cost(item: dict, partid: str) -> tuple:
    if "constituents" in item:
        # 복합 항목: 구성 요소 원가 합산
# ... (구현 세부 사항 생략)

이 재귀적 계산은 중첩된 구성 요소들을 처리합니다.

복합 항목

일부 구성 요소는 복합적입니다(다른 구성 요소들로 만들어짐):

예시: 키보드 + 마우스 콤보

{
  "KM": {
    "internal": "Keyboard + Mouse",
# ... (구현 세부 사항 생략)

이는 다음을 가능하게 합니다:

BOM 생성: 필요한 모든 구성 요소 나열
원가 계산: 키보드 + 마우스 + 동글 원가 합산
재고 추적: 구성 요소 사용량 추적

productdb.json 업데이트

수동 편집

파일은 텍스트 편집기나 IDE에서 수동으로 편집됩니다. 변경 사항은 Git에 커밋됩니다:

git add PATH_TO_FILE/productdb.json
git commit -m "Add new N150 board configuration"
git push

검증

편집 후, JSON 구문을 검증합니다:

python -m json.tool PATH_TO_FILE/productdb.json > /dev/null

이는 구문 오류를 확인합니다.

배포

Git에 푸시한 후, 파일은 프로덕션에 배포됩니다.

애플리케이션은 재시작 시 파일을 다시 로드합니다.

다른 시스템과의 통합

웹사이트

웹사이트는 productdb.json을 사용하여:

제품 페이지 생성
사양 표시
기능별 제품 필터링
비교표 생성

ERP

ERP는 productdb.json을 사용하여:

SKU 검증
BOM 생성
원가 계산
재고 추적

회계

회계는 productdb.json을 사용하여:

제품 원가 계산
송장 생성
매출 원가(COGS) 추적

SEO 파이프라인

SEO 파이프라인은 productdb.json을 사용하여:

문구 매핑을 위한 기능 추출
필터 추출을 위한 필터 생성
기능별로 쿼리를 제품과 매칭

자세한 내용은 SEO 파이프라인 개요를 참조하세요.

단일 출처의 이점

1. 일관성

모든 시스템이 동일한 데이터를 사용합니다. 불일치가 없습니다.

2. 유지보수성

한 번 업데이트하면 모든 곳에 전파됩니다. 여러 시스템을 업데이트할 필요가 없습니다.

3. 감사 가능성

모든 변경 사항이 Git에서 추적됩니다. 누가 무엇을 언제 변경했는지 쉽게 확인할 수 있습니다.

4. 테스트 가능성

변경 사항은 프로덕션 배포 전 스테이징 환경에서 테스트할 수 있습니다.

5. 단순성

이해하기 쉬운 하나의 파일입니다. 복잡한 데이터베이스 스키마나 API가 없습니다.

6. 성능

메모리 내 사전은 O(1) 조회를 제공합니다. 데이터베이스 쿼리가 필요 없습니다.

7. 이식성

JSON은 사람이 읽기 쉽고 언어에 구애받지 않습니다. 어떤 언어로든 쉽게 파싱할 수 있습니다.

한계점

1. 수동 편집

변경 사항은 수동 편집과 Git 커밋이 필요합니다. 비기술 사용자를 위한 웹 UI가 없습니다.

2. 재시작 필요

애플리케이션은 변경 사항을 로드하기 위해 재시작해야 합니다. 핫 리로드가 없습니다.

3. 검증 부족

JSON 구문은 검증되지만, 의미론적 검증(예: "이 부품이 존재하나요?")은 자동으로 이루어지지 않습니다.

4. 동시성

여러 사람이 동시에 편집하면 병합 충돌이 발생할 수 있습니다.

참고 자료

기술 개념

JSON - Wikipedia
단일 출처 - Wikipedia
자재 명세서 - Wikipedia

SKU 구조 - 하이픈으로 구분된 SKU 아키텍처
기능 추출 - 기능이 추출되는 방법
문구-필터 매핑 - 필터에 기능 사용하기
SEO 파이프라인 개요 - 완전한 파이프라인 아키텍처

요약

productdb.json은 모든 제품 데이터의 단일 출처입니다:

구조:

구성 요소 카테고리별 구성 (Chassis, Board, RAM 등)
각 구성 요소는 속성을 가짐 (class, internal, external, weight)
호환성 규칙 (allows)
자재 명세서 (constituents)
기능 제공 (provides)

이점:

모든 시스템 간 일관성
유지보수성 (한 번 업데이트)
감사 가능성 (Git 추적)
테스트 가능성 (스테이징 배포)
단순성 (하나의 파일)
성능 (메모리 내 O(1) 조회)
이식성 (JSON 형식)

사용 사례:

SKU 검증
기능 집계
원가 계산
BOM 생성
웹사이트 제품 페이지
SEO 파이프라인 기능 추출

이 중앙 집중화된 접근 방식은 모든 시스템이 동일한 제품 데이터를 참조하도록 보장하여 불일치를 제거하고 유지보수를 단순화합니다.

← 문서 색인으로 돌아가기

Produkte

Beliebte Suchanfragen und Blogs