변형과 번들을 포함한 제품 카탈로그: 스키마와 UI 패턴

변형과 번들이 빠르게 복잡해지는 이유

모든 제품이 하나의 품목, 하나의 가격, 하나의 재고 수치로 보일 때 카탈로그는 단순해 보입니다. 색상, 사이즈, 구독 기간, 지역별 포장 등 옵션을 추가하면 그 단순함은 깨집니다. 단일 “Products” 테이블만으로는 더 이상 기본적 질문에 답하기 어렵습니다: 우리가 정확히 무엇을 팔고 있으며, 어떻게 추적할 것인가?

구매자들도 세부 정보가 정확하길 기대합니다. 옵션을 선택하면 즉시 올바른 가격을 보고, 선택한 항목이 오늘 배송 가능한지 알기를 원합니다. 페이지에 "재고 있음"이라고 표시되지만 선택한 사이즈가 없으면 신뢰는 빠르게 떨어집니다. 가격이 결제 단계에서만 바뀌면, 고객지원 문의와 반품이 뒤따릅니다.

번들은 제품처럼 보이지만 규칙처럼 작동하기 때문에 복잡도가 한층 추가됩니다. "스타터 키트"는 한 병, 펌프 하나, 필터 세트로 구성될 수 있습니다. 그 가용성은 부품에 의해 결정되고, 비용과 보고 역시 일관되게 유지되어야 합니다.

카탈로그가 흔들리기 시작했다는 징후:

• 옵션을 표현하기 위해 중복 SKU를 생성한다.
• 번들 판매 후 재고 수치가 이상해진다.
• 관리자 화면이 거의 동일한 항목들의 긴 목록이 된다.
• 할인과 세금이 단품에서는 작동하지만 키트에서는 깨진다.
• 보고서가 “실제로 무엇이 팔렸나?”에 답하지 못한다.

해결책은 주로 규율입니다: 일관된 데이터 모델과, 고객과 팀 모두에게 옵션 선택과 가용성을 명확히 보여주는 UI 패턴이 필요합니다.

쉬운 용어 정리: 옵션, 변형, SKU, 번들

사람들이 "변형(variants)"이라고 말할 때 몇 가지 다른 개념을 섞어 쓰는 경우가 많습니다. 초기부터 용어를 분명히 해두면 이후 스키마, UI, 재고 결정이 훨씬 쉬워집니다.

대부분 팀이 사용하는 정의는 다음과 같습니다:

• 옵션(Option): 구매자가 선택할 수 있는 유형, 예: 사이즈(Size)나 색상(Color).
• 옵션 값(Option value): 옵션 내의 하나의 값, 예: Size = M, Color = Black.
• 변형(Variant): 옵션 값들의 정확한 조합, 예: Size M + Color Black.
• SKU: 운영과 재고에서 추적하는 판매 단위. 변형이 보통 하나의 SKU에 매핑되지만 항상 그런 건 아님.
• 번들 / 키트 / 멀티팩: 다른 제품들로 구성된 제품. 번들은 마케팅적 묶음(부품을 따로 팔 수 있음), 키트는 함께 배송되어야 하는 세트, 멀티팩은 동일 품목의 반복(예: 양말 3팩).

ID도 실무에서는 혼동됩니다. 내부 ID는 데이터베이스에서 쓰는 값이고, SKU는 운영 코드(피킹, 보충, 보고서에 사용). 바코드(UPC/EAN)는 스캐너가 읽는 것. 하나의 SKU에 지역별로 여러 바코드가 있을 수 있고, 바코드가 전혀 없는 항목도 있습니다.

스스로에게 유용한 규칙: 가격, 재고, 무게, 배송 규칙이 달라질 수 있다면 그것은 판매 가능한 변형으로 취급하세요. 같은 티셔츠라도 사이즈 M과 XL은 별도의 재고가 필요하므로 별도의 SKU여야 합니다.

카탈로그가 지원해야 할 것을 결정하기

스키마를 선택하기 전에, 비즈니스가 매일 답해야 할 질문들부터 시작하세요. 누군가 항목을 볼 때 자신 있게 말할 수 있나요: 지금 사용 가능한가, 가격은 얼마인가, 어떻게 배송되나, 어떤 세금 규칙이 적용되나?

사실을 어디에 둘지 결정하는 방식이 유용합니다. 공유되는 사실은 product에 두고, 변하는 사실은 variant(SKU)에 두세요. 섞어두면 같은 버그를 두 군데 고치게 됩니다.

제품 수준 vs 변형 수준을 결정하는 데 일반적으로 쓰이는 질문들:

• 사이즈/색/재질에 따라 바뀌면 변형에 둔다.
• 모든 옵션 조합에 대해 참이라면 제품에 둔다.
• SKU 단위로 보고할 항목(판매, 마진, 반품)은 변형에 저장한다.
• 운영이 피킹/포장/배송에 사용하는 정보는 창고가 쓰는 위치(SKU)에 저장한다.
• 표시명 같은 파생 가능한 항목은 원본만 저장하고 필요시 파생해서 보여라.

진실의 단일 출처(single source of truth)를 유지하세요. 예를 들어 가격을 product와 variant 둘 다에 저장하지 마세요(단, product는 MSRP, variant는 실제 판매가 같은 역할이 명확할 때는 예외).

변경에 대비하세요. 나중에 새로운 옵션(예: 길이)을 추가하거나 변형을 퇴역시키거나 공급업체 변경 후 SKU를 병합할 수 있습니다. 변형을 1등 시민 레코드로 다루면 이런 변경이 더 원활합니다.

AppMaster로 빌드한다면 Data Designer에서 명확한 엔터티 명칭을 쓰면 요구사항 변화에 따라 유지보수가 쉬워집니다.

제품과 변형을 위한 실용적 스키마

깔끔한 스키마는 단순한 제품이 수십 개의 판매 가능한 조합으로 바뀌어도 카탈로그를 이해하기 쉽게 유지합니다. 목표는 쇼핑객이 선택하는 것(choices)과 실제로 재고로 보유하고 배송하는 항목(sellable items)을 분리해서 모델링하는 것입니다.

신뢰할 만한 엔터티 집합:

• Product: 부모 항목(이름, 설명, 브랜드, 카테고리, 기본 이미지)
• Option: 선택 유형(예: Size, Color)
• OptionValue: 허용 값(예: Small, Medium, Red, Blue)
• Variant: 판매 단위(값들의 한 조합)
• VariantOptionValue: Variant와 OptionValue를 연결하는 조인 테이블

변형의 고유성(uniqueness)은 많은 카탈로그가 실패하는 지점입니다. 가장 안전한 방법은 정규화된 구조로, 각 Variant에 대해 각 Option마다 하나의 OptionValue만 허용하고 중복 조합을 방지하는 것입니다. 성능을 원하면 Variant에 계산된 "variant key"(예: color=red|size=m 또는 그 해시)를 저장하고 Product별로 고유하게 강제하세요.

조합별로 달라지는 필드는 Product가 아니라 Variant에 두세요: SKU, 바코드, 가격, 비교 가격, 원가, 무게, 치수, 상태(활성/단종), 이미지(메인 이미지 또는 작은 이미지 집합).

커스텀 속성(예: 재질, 세탁 방법)은 컬럼을 계속 추가하지 마세요. PostgreSQL의 JSONB 필드와 간단한 검증 레이어가 좋은 조합입니다.

오래 지속되는 SKU 규칙

SKU는 판매한 정확한 항목을 식별하는 식별자이며 안정적으로 유지되어야 합니다. SKU에 마케팅명, 전체 옵션 텍스트, 시즌 정보 같은 이야기를 부담시키지 마세요. 그렇게 하면 나중에 변경할 때 보고서가 깨집니다.

초기에 SKU를 수동으로 배정할지 생성할지 결정하세요. 수동 SKU는 이미 ERP, 바코드, 공급업체 SKU가 있어 일치해야 할 때 안전합니다. 생성된 SKU는 변형이 많은 경우 일관성을 위해 안전하지만 규칙이 중간에 바뀌지 않아야 합니다. 일반적인 절충안은 고정된 베이스 SKU와 변형 속성을 위한 짧은 생성 접미사를 조합하는 것입니다.

읽기 쉽고 확장 가능한 규칙:

• 주문이 존재한 이후에는 SKU를 변경하지 마세요. 오래된 SKU를 "수정"하지 마세요.
• 내부 ID와 SKU를 분리하세요. 사람은 SKU를 보고, 데이터베이스는 ID를 사용합니다.
• 제품군에 대해서는 짧은 접두사(TSH, MUG 등)를 쓰세요, 전체 단어는 피하세요.
• 변경될 가능성이 큰 의미(예: "2026", "SUMMER")는 피하세요, 비즈니스가 실제로 그렇게 작동한다면 예외.

단종된 SKU는 삭제하지 말고 비활성으로 표시하세요. 가격 이력과 과거 주문, 환불, 보고서에서 선택 가능하도록 유지하세요. SKU를 대체하면 "대체됨(replaced by)" 참조를 저장해 지원팀이 추적할 수 있게 하세요.

검증 규칙으로 시간이 지남에 따른 손상을 예방하세요: 모든 판매 가능 항목에 대해 SKU 고유성 강제, 문자/숫자/하이픈만 허용, 명확한 최대 길이(보통 20-32자), 특수한 경우를 위한 접두사 예약(예: 번들에 대해 "BND-"). AppMaster에서는 데이터 제약과 저장 차단 비즈니스 프로세스로 이러한 검사를 구현하면 좋습니다.

단순한 재고 상태 이상의 재고 로직

동일한 "제품"이 여러 판매 단위를 의미할 수 있을 때 재고는 혼란스러워집니다. 규칙을 작성하기 전에 재고 단위를 결정하세요: 제품 수준, 변형 수준, 혹은 둘 다로 재고를 추적할 건가요?

사이즈나 색상을 고객이 선택한다면 변형 수준 재고가 보통 안전합니다. 티셔츠는 전체적으로는 "재고 있음"이지만 Small-Blue 변형은 품절일 수 있습니다. 제품 수준 재고는 변형이 물리적으로 저장 방식에 영향을 주지 않는 항목(예: 청구 플랜이 다른 디지털 라이선스)에 적합합니다. 일부 팀은 둘 다 유지합니다: 제품 수준은 보고용, 변형 수준은 판매용.

과판매(overselling) 방지는 하나의 마법 같은 플래그가 아니라 명확한 상태 정의에 가깝습니다. 대부분 카탈로그는 예약(장바구니나 미결제 주문을 위해 일시적으로 보류), 백오더(명확한 배송일을 표시하며 판매 허용), 재고 버퍼(동기 지연을 커버하기 위한 숨은 수량), 그리고 원자적 업데이트(주문 확정과 동시에 재고 차감)를 필요로 합니다.

엣지 케이스에서 "알 수 없는 재고(mystery stock)"가 생깁니다. 반품은 반품 라벨 생성 시점이 아니라 검사 후에만 재고에 더해야 합니다. 손상된 품목은 별도 상태나 위치로 옮겨 판매 가능으로 보이지 않게 하세요. 재고 조정에는 감사지(trace)가 필요합니다(누가, 무엇을, 왜 변경했는지), 특히 여러 채널이 재고를 업데이트할 때 중요합니다.

번들과 키트에는 한 가지 핵심 규칙이 추가됩니다: 번들이 단순 묶음이라면 번들 레코드 자체를 차감하지 마세요. 구성 부품을 차감하세요. 3팩은 동일 SKU 3개를 줄여야 하고, 키트는 각 구성품을 1개씩 줄여야 합니다.

예: "스타터 키트"에 병 1개와 필터 2개가 포함되어 있다면, 병이 10개, 필터가 15개라면 키트 가용성은 필터가 한계를 만듭니다: min(floor(10/1)=10, floor(15/2)=7) => 7 키트. 구성요소 기반 계산은 보고, 환불, 재입고를 일관되게 유지합니다.

AppMaster에서는 이는 Data Designer의 변형 테이블과 Business Process Editor의 예약/차감 로직으로 자연스럽게 매핑되어 모든 체크아웃이 동일한 규칙을 따르게 됩니다.

보고를 망가뜨리지 않는 번들·키트 모델링

번들은 카탈로그가 특수 사례로 흘러가기 쉬운 지점입니다. 가장 단순한 접근은 번들을 정상적인 판매 항목으로 모델링한 뒤 명확한 구성요소 목록을 붙이는 것입니다.

깨끗한 구조는: **Product(판매 항목)**와 BundleLines. 각 BundleLine은 구성품 SKU(또는 구성품 제품과 필요한 변형)를 가리키고 수량을 저장합니다. 주문은 여전히 "한 개의 항목"으로 보이지만, 비용, 재고, 이행 세부가 필요할 때 부품으로 확장할 수 있습니다.

대부분의 번들 설정은 다음 중 하나에 속합니다:

• 고정 번들(kit): 항상 동일한 구성품과 수량.
• 구성 가능한 번들: 고객이 허용된 구성품에서 선택(선택값은 주문 라인에 저장).
• 가상 번들: 재고 영향이 없는 마케팅 묶음, 머천다이징에 유용.

가격 설정은 팀이 실수로 보고를 망가뜨리는 지점입니다. 주문 라인에 무엇이 표시되는지, 무엇이 마진과 재고 보고로 들어가는지 미리 결정하세요. 일반적 접근은 고정 번들 가격, 부품 합산, 또는 구성품별 규칙이 적용된 할인 합산(예: "아무 3개 선택, 가장 싼 항목 50% 할인")입니다.

재고도 동일하게 엄격해야 합니다: 키트는 모든 필수 구성품이 필요한 수량만큼 가용할 때만 판매 가능해야 합니다. 보고를 위해 판매에 대해 두 가지 뷰를 저장하세요:

• 판매된 항목: 번들 SKU(매출, 전환, 머천다이징용)
• 소비된 구성품: 확장된 BundleLines(재고 이동, 매출원가, 피킹리스트용)

AppMaster에서는 Bundle 테이블과 BundleLine 행, 그리고 체크아웃 시 구성품을 확장해 번들 판매와 부품 소비를 하나의 트랜잭션으로 기록하는 Business Process가 자연스럽게 들어맞습니다.

옵션과 변형 선택을 위한 UI 패턴

좋은 옵션 UI는 사용자가 흐름을 유지하게 합니다. 나쁜 옵션 UI는 사용자를 추측하게 만들고, 오류를 발생시키며, 이탈을 유발합니다. 핵심은 쇼핑객이 초기에 실제 구입 가능한 변형을 찾도록 안내하고, 선택이 무엇을 변경하는지 분명히 보여주는 것입니다.

고객용: 옵션 우선, 변형은 그 다음

신뢰할 만한 패턴은 옵션(Size, Color, Material)을 먼저 제시하고, 선택 가능한 조합만 계산해 보여주는 것입니다.

고객이 아무 조합이나 선택하고 Add to cart에서 실패하게 하지 말고, 사용자가 선택할 때 불가능한 조합을 즉시 비활성화하세요. 예를 들어 Color = Black을 선택하면 Black에 존재하지 않는 사이즈는 제거하지 말고 비활성화하여 고객이 무엇이 불가능한지 이해하게 하세요.

선택이 바뀔 때 가장 중요한 부분을 업데이트하세요: 가격(세일 가격과 번들 할인 포함), 메인 이미지(선택한 색상/스타일과 일치), 재고 상태(일반 제품 재고가 아닌 정확한 변형 재고), 배송 예상일(변형별로 다르면), 그리고 필요하면 지원용 SKU 또는 "품목 코드"를 보여주세요.

인터페이스는 차분하게 유지하세요. 한 번에 옵션 그룹을 몇 개만 보여주고, 스와치나 버튼이 더 나은 경우 거대한 드롭다운을 피하며 현재 선택을 명확히 표시하세요.

관리자용: 스프레드시트처럼 변형 편집

관리자에게는 속도가 중요합니다. 각 행이 SKU인 변형 그리드는 효과적입니다: 각 열은 옵션 또는 규칙(가격, 바코드, 무게, 재고, 활성/비활성). 가격 업데이트, 가용성 전환, 이미지 할당 같은 일반 작업을 위한 일괄 작업을 추가하세요.

AppMaster에서 구성한다면 Variant 테이블에 바인딩된 그리드, 옵션 값/활성 상태/저재고 필터, 저장 전에 규칙을 검증하는 일괄 업데이트 액션을 실용적으로 구현할 수 있습니다.

단계별: 변형 선택과 번들 가용성 확인

선택 흐름은 단순하게 느껴져야 하지만 내부적으로 엄격한 규칙이 필요합니다. 목표는 쇼핑객이 구성 중인 정확한 SKU와 지금 구매 가능한지 여부를 항상 아는 것입니다.

변형 선택(단일 제품)

제품 이름과 이미지 이상을 로드하세요. 전체 옵션 값 집합(예: Size, Color)과 SKU로 존재하는 유효 변형 조합 목록(또는 압축된 조합 맵)이 필요합니다.

신뢰할 만한 흐름:

1. 제품, 옵션, 그리고 존재하는 모든 변형(또는 유효 조합 맵)을 가져옵니다.
2. 사용자의 현재 선택(예: Size=M, Color=Black)을 저장하고 클릭마다 업데이트합니다.
3. 선택이 바뀔 때마다 선택한 옵션 값을 변형 목록과 비교해 일치하는 변형을 찾습니다.
4. 일치하고 구매 가능(활성, 가격 설정, 차단 없음)하면 Add to cart를 활성화합니다.
5. 일치하는 변형이 없으면 Add to cart를 비활성화하고 사용자를 유효한 선택으로 안내합니다.

작은 UI 디테일로 좌절을 예방하세요: 앞선 선택이 이뤄지면 불가능한 옵션 값을 즉시 비활성화하세요. 예: Size=M이 Black에서만 존재하면 M이 선택되면 다른 색상은 이용불가로 표시합니다.

번들 가용성(구성품으로 이루어진 키트)

번들에서 "재고 있음"은 단일 숫자가 아닙니다. 구성품에 따라 달라집니다. 일반 규칙은:

bundle_available = minimum over components of floor(component_stock / component_qty_per_bundle)

예: "스타터 키트"가 병 1개와 필터 2개를 필요로 하고, 병이 10개, 필터가 9개라면 가용성은 min(floor(10/1)=10, floor(9/2)=4) = 4 키트입니다.

오류 메시지는 구체적이어야 합니다. "재고 없음"보다 "키트는 4개만 남았습니다(필터가 이 번들의 제한입니다)"처럼 표시하세요. AppMaster에서는 이 검사를 Business Process로 표현해 먼저 해당 변형을 찾고, 번들 한계를 계산한 다음 UI에 표시할 명확한 상태를 반환하는 것이 간단합니다.

피해야 할 일반적인 실수와 함정

카탈로그는 "존재할 수 있는 모든 것"을 모델링하려고 할 때 망가집니다. 전개 초기에 가능한 모든 옵션 조합을 생성한 다음 카탈로그가 커지면서 이를 정리하려 들면 곤란해집니다.

재고가 절대 채워지지 않을 변형을 만드는 것이 고전적 함정입니다. 예를 들어 4색 x 6사이즈 x 3재질이면 72개의 변형이 됩니다. 실제로는 10개만 팔릴 예정이라면 나머지 62개의 레코드는 혼란을 초래하고 실수를 유발하며 보고를 느리게 합니다.

가격은 또 다른 은근한 버그 원인입니다. 동일한 가격을 제품, 변형, 가격 테이블, 프로모션 테이블 등 여러 곳에 저장하면 소스가 불분명해집니다. 단순한 규칙: 기본 가격은 한 곳에만 저장하고, 예외가 진짜로 필요할 때만 오버라이드를 저장하세요(예: 특정 변형만 다른 가격).

번들·키트의 인벤토리 실패는 번들과 구성품을 둘 다 차감할 때 발생합니다. "스타터 키트"를 판매하면서 1 키트와 동시에 병 1개와 필터 2개를 모두 차감하면 재고가 너무 빨리 0이 됩니다. 번들은 판매 항목으로 유지하되 가용성과 차감은 구성품으로부터 계산하세요.

관리자 도구는 잘못된 데이터를 허용하면 피해를 줍니다. 초기부터 가드레일을 추가하세요:

• 아카이브된 항목을 포함해 중복 SKU를 차단하세요.
• 모든 변형이 모든 옵션 값을 갖도록 요구하세요(예: "사이즈 누락" 없음).
• 두 변형이 동일한 옵션 조합을 공유하지 못하게 하세요.
• 번들 구성품을 검증하세요(수량 0 금지, SKU 누락 금지).

마지막으로 변경을 대비하세요. 나중에 "Width" 같은 옵션을 추가하는 것은 체크박스가 아니라 마이그레이션입니다. 기존 변형에 무슨 일이 일어나는지, 기본값은 어떻게 설정되는지, 과거 주문이 원래 SKU와 옵션 스냅샷을 어떻게 유지하는지 결정하세요.

출시 전 점검 목록

런칭 전에 실제로 깨지는 지점을 점검하세요: SKU 찾기, 재고 업데이트, 불가능한 구매 차단.

모든 판매 가능한 SKU가 쉽게 검색되는지 확인하세요. 검색은 이름, SKU 코드, 바코드/GTIN, 주요 속성(사이즈나 색상 등)으로 찾아야 합니다. 창고에서 스캐닝을 사용한다면 몇 가지 물리적 스캔을 테스트해 정확한 SKU에 매핑되는지 확인하세요(부모 제품이 아닌).

재고 변경이 발생하는 위치를 엄격히 하나로 정하세요(재고 이동 로직). 모든 이벤트(주문, 취소, 환불, 수동 조정, 번들 조립)가 이 단일 소스에 의존하도록 하세요. 재고가 두 화면이나 두 워크플로에서 편집될 수 있으면 드리프트가 발생합니다.

실행할 가치가 있는 런치 체크:

• UI에서 옵션을 선택해 무효 조합이 장바구니 담기 전에(체크아웃 전) 차단되는지 확인하세요.
• 번들의 경우 가용성이 가장 부족한 구성품과 필요한 수량에 의해 결정되는지 확인하세요(예: 키트당 배터리 2개면 가용성이 절반이 되어야 함).
• SKU를 은퇴시키고 브라우징 및 검색 결과에서 사라지는지, 하지만 과거 주문·송장·보고서에서는 올바르게 보이는지 확인하세요.
• 테스트 주문을 하고 취소한 뒤 다시 주문하세요; 재고가 반환되고 다시 예약되는지 확인합니다.

AppMaster로 빌드한다면 재고 업데이트 규칙을 하나의 Business Process에 모아 모든 경로에서 호출하세요. 이 한 가지 습관이 대부분의 재고 버그를 예방합니다.

예시 시나리오와 실용적 다음 단계

심각한 카탈로그가 필요한 의류 샵을 상상해보세요.

티셔츠를 판매하며 두 가지 옵션이 있습니다: Size(S, M, L)와 Color(Black, White). 각 구매 가능한 조합은 자체 변형과 SKU, 필요하면 가격, 재고를 가집니다.

스키마에서는 "Classic T-shirt"라는 Product 레코드 하나, 두 개의 Option 레코드(Size, Color), 그리고 여러 Variant 레코드를 유지하세요. 각 Variant는 선택된 옵션 값(예: Size=M, Color=Black)과 SKU(예: TSH-CL-M-BLK)를 저장합니다. 재고는 Product 수준이 아닌 Variant 수준에서 추적하세요.

UI에서는 선택지를 좁히고 막다른 길을 막으세요. 깔끔한 패턴은: 모든 색상을 먼저 보여주고 선택된 색상에 존재하는 사이즈만 표시(혹은 그 반대). "White + L"이 존재하지 않으면 선택 불가로 하거나 비활성화해 명확히 알리세요.

이제 번들 "Gift Set"을 추가해 보세요. 구성:

• Classic T-shirt 1개(임의 변형 허용)
• Sticker pack 1개(단순 SKU)

번들 가용성은 가장 제한적인 구성요소에 의해 결정됩니다. Sticker pack 재고가 5이면 티셔츠 재고가 충분하더라도 번들은 5개까지만 판매 가능합니다. 번들이 특정 티셔츠 변형(예: Black M)을 요구하면 번들 재고는 min(StickerPackStock, BlackMStock)입니다.

AppMaster에서의 실용적 다음 단계:

• Data Designer에 테이블 생성(Products, Options, OptionValues, Variants, VariantOptionValues, Inventory, Bundles, BundleComponents).
• Business Process Editor에서 "유효 변형 찾기"와 "번들 가용성 계산" 구현.
• 동일 프로젝트에서 웹과 네이티브 모바일 UI를 생성해 모든 곳에서 동일한 변형 필터링 및 가용성 규칙을 사용.

끝으로, 전체를 빠르게 프로토타입하고자 한다면 AppMaster (appmaster.io)은 실제 비즈니스 로직을 포함한 완전한 앱을 구축하도록 설계되어 있어 변형 선택과 번들 재고 규칙에 꼭 필요한 도구입니다.