제품 이미지 파일 명명 규칙: 오래된 사진을 보내지 않으려면

지난주 보낸 견적은 2024년에 찍은 사진 한 장으로 만들어졌습니다. 바이어는 예전 베이스 기준으로 가격을 냈고, 우리는 신형을 출고했습니다. 그다음 벌어진 논쟁은 기술도 가격도 아니라 "어느 파일이 맞는 것인가"였습니다. 그 사진의 파일 이름은 양쪽 모두에게 답을 주지 않았습니다.

제품 이미지 파일 명명 규칙은 모든 SKU의 모든 사진에 동일한 고정 패턴을 적용하는 약속입니다. 파일을 열지 않고도 어떤 제품의, 어떤 뷰이고, 몇 번째 버전이며, 언제 승인됐는지 알 수 있게 합니다. 서로 다른 두 나라의 담당자가 같은 폴더를 봐도 어느 것이 현재 버전인지 판단할 수 있습니다. 정리 정돈이 아닙니다. 내가 승인한 사진이 내보낸 사진이라는 사실을 증명하는 가장 값싼 증거입니다.

아래에서는 5년을 버티는 패턴, 실제로 정보를 담는 토큰, 파일 이름이 깨지는 세 지점, 그리고 운영 중인 리스팅을 망가뜨리지 않고 기존 라이브러리를 바꾸는 순서를 정리합니다.

제품 이미지 파일 명명 규칙이 해야 하는 세 가지 일

파일 이름에는 세 가지 임무가 있고, 대부분의 공급사는 첫 번째만 설계합니다.

돈이 걸린 것은 세 번째입니다. 승인 파일을 제시하지 못하는 순간, 바이어의 "합의한 마감과 다르다"는 말에 반박할 근거가 거의 사라집니다. 마감이 완벽히 맞아도 마찬가지입니다. "최신 파일"이 (1)인 폴더에서는 3월에 무엇을 보냈는지 아무도 재구성할 수 없습니다.

다섯 개 토큰, 이 순서로

어휘보다 순서가 중요합니다. 순서를 고정하면 단순 알파벳 정렬만으로 쓸 만한 목록이 됩니다. 같은 SKU가 모이고, 뷰가 정해진 순서로 놓이고, 최신 버전이 마지막에 옵니다.

완성된 이름은 SM-CB-1200_front_v03_2026-10-29.jpg 입니다. 38자, 공백 없음, 이스케이프가 필요한 기호 없음. Finder, 탐색기, 클라우드 드라이브 어디서나 제대로 정렬됩니다.

SKU를 맨 앞에 두는 이유는 바이어의 보관 체계가 SKU를 축으로 짜여 있기 때문입니다. SKU는 발주서에 적히는 번호입니다. 제품명으로 시작하는 이름(walnut-cabinet-1200mm-2.jpg)은 같은 캐비닛을 두 가지 마감으로 파는 순간 한 SKU의 사진을 알파벳 전체로 흩뜨립니다. 날짜를 따로 두는 이유는 버전이 "무엇이 바뀌었나", 날짜가 "바이어가 언제 볼 수 있었나"를 말하기 때문입니다. 반년 뒤 클레임이 오면 판을 가르는 것은 날짜입니다.

이 한 문장만 기억하십시오: 파일 이름은 라벨이 아니라, 어느 사진을 승인했는지에 대한 유일한 기록입니다.

뷰 토큰: 형용사가 아니라 폐쇄 목록

뷰를 자유 입력으로 두는 순간 규칙은 죽습니다. 실제로 공개하는 값으로 목록을 닫으십시오.

아홉 개면 B2B 문의는 거의 덮입니다. 열 번째가 필요하면 누가 쓰기 전에 문서로 목록에 추가하십시오. 한 사람 머릿속에 있는 약속은 약속이 아닙니다.

dim과 scale은 자주 뒤바뀝니다. dim은 측정해 그린 치수 도면, scale은 기준물이 있는 상황 컷입니다. 출입구를 통과하는지 따지는 바이어에게 필요한 것은 scale, 견적을 채우는 바이어에게 필요한 것은 dim입니다. 둘이 한 이름 아래 있으면 전달되는 쪽은 대개 틀린 것입니다.

버전과 날짜는 다른 필드입니다

버전은 "이전과 같은 제품인가", 날짜는 "언제부터 이 파일이 기록상 정본이 되었나"에 답합니다. 제품은 그대로인데 다시 찍는 순간—배경을 더 깔끔하게, 마감 조명을 더 좋게—둘은 갈라집니다. 그리고 이것이 분쟁이 가장 잘 생기는 경우입니다. 제품이 조금 달라 보이니 바이어는 사양이 바뀌었다고 해석합니다.

팀이 볼 수 있는 곳에 세 가지 규칙을 적어 두십시오.

• 버전은 제품·마감·치수가 바뀔 때만 올립니다. 조명만 바꾼 재촬영은 버전을 유지하고 날짜만 새로 씁니다. 둘 다 남겨야 하면 끝에 -res를 붙입니다: SM-CB-1200_front_v03_2026-10-29-res.jpg.
• 승인 파일의 이름은 영원히 바뀌지 않습니다. 새 파일을 만들면 이전 파일은 이름 그대로 archive/로 옮깁니다. old로 개명하지도, 덮어쓰지도 않습니다.
• archive/에서는 아무것도 보내지 않습니다. 지난 시즌 사진을 요청하면 자기 날짜를 단 채 이름만 바꿔 내보냅니다. 파일은 계속 자신을 설명합니다.

마지막 규칙이 버전 토큰의 존재 이유입니다. 같은 이름으로 덮어쓴 파일은 검증이 불가능합니다. 무엇을 보냈는지도, 무엇을 받았는지도 증명할 수 없습니다. 같은 규율이 제품 사양 변경 체크리스트에도 나타납니다. 버전은 모든 문서에 동시에 도달해야 의미가 있습니다.

실제 예: 문의 하나, 파일 여섯 개

바이어가 1,200 mm 월넛 캐비닛, 900 mm 버전, 납작 포장 외장 카톤을 요청했다고 합시다. 답장은 파일 여섯 개이고, 이름만으로 고를 수 있습니다.

정리되지 않은 사진 40장에서는 나오지 않는 두 가지가 표에서 바로 보입니다. 두 모델의 촬영일이 2주 차이 난다는 점—900 mm에 새 힌지가 들어갔느냐는 질문에 유용합니다—그리고 각 파일이 자기 역할을 밝히므로 엔지니어, 포워더, 쇼룸 담당자가 추가 메일 없이 필요한 것을 가져갑니다.

한 SKU 한 장짜리 사양서와 같은 원리입니다. 하나의 SKU, 한 페이지, 하나의 역할. 제품 이미지 파일 명명 규칙은 그 페이지를 이루는 파일에 같은 원리를 적용하는 일이며, 가구 리스팅 주석 사례가 일회성 시연이 아니라 카탈로그 전체에 재현되는 이유이기도 합니다. 여러 플랫폼에서 제품 이미지를 재사용하기 위한 전제이기도 합니다. 어떤 자산이 어느 채널 것인지 추측하지 않아도 됩니다.

파일 이름이 깨지는 세 곳

어느 것도 취향 문제가 아닙니다. 모두 라이브러리를 조용히 둘로 쪼갭니다.

1. 경로 길이: 윈도우 260자

윈도우의 전체 경로 상한은 260자, 단일 파일 이름은 255자입니다. 테스트 폴더에서는 잘 열리던 파일이 바이어의 다운로드 폴더에서 세 단계만 더 들어가도 열리지 않습니다. 긴 설명형 이름과 깊은 폴더가 좋은 파일을 "파일을 찾을 수 없음"으로 바꾸는 방식입니다.

이름은 60자 이내, 경로는 150자 이내로 유지하면 문제는 생기지 않습니다. 제품명을 파일 이름에 넣지 말아야 하는 실무적 이유도 여기 있습니다. 길고, SKU와 중복되며, 가장 먼저 잘리는 부분입니다.

2. 예약 문자, 공백, 대소문자

윈도우는 < > : " / \ | ? *를 금지하고 CON, PRN, AUX, NUL 같은 장치 이름을 예약합니다. URL에 넣으면 나머지가 망가집니다. 공백은 %20, #은 프래그먼트에서 링크를 끊고, ?는 뒤를 쿼리 문자열로 바꿉니다. 내 노트북에서는 열리는 파일이 메신저에서는 404가 됩니다.

대소문자는 더 조용한 함정입니다. 윈도우와 macOS는 기본적으로 대소문자를 구분하지 않아 SM-CB-1200_front.jpg와 sm-cb-1200_front.jpg가 맥에서는 한 파일, 리눅스 서버에서는 두 객체입니다. 둘 다 올리면 리스팅이 어느 것을 보여주는지 말할 수 없습니다.

소문자, 숫자, 하이픈, 점만 쓰십시오. 하이픈은 모든 클라이언트, 게이트웨이, URL 파서를 통과합니다. 밑줄과 공백은 그렇지 않습니다.

3. 악센트와 유니코드 정규화

똑같이 보여도 바이트가 다른 문자가 있습니다. "é"는 합성된 한 글자일 수도, e에 결합 악센트일 수도 있습니다. macOS는 파일 이름을 정규화 구분 없이 비교하지만 리눅스 서버와 클라우드 스토리지는 대개 구분합니다. 맥에서 서버로 폴더를 복사하면 악센트가 있는 이름이 두 파일이 되거나, 더 나쁘게는 하나가 다른 하나를 덮어씁니다.

카탈로그에 악센트나 중국어가 있다면 파일 이름은 ASCII로 유지하고 현지어 이름은 제품 데이터에 두십시오. 그래야 같은 파일이 경로상 모든 기계에서 작동합니다.

이름 자체와 무관한 네 번째 균열도 있습니다. CDN은 URL로 파일을 내보내므로 같은 경로에서 파일을 교체해도 캐시가 옛 이미지를 계속 보냅니다. 이름에 버전을 넣으면 무료로 해결됩니다. 새 버전은 새 URL이라 무효화할 것이 없고, URL 자체가 감사 기록이 됩니다.

이미 있는 라이브러리 바꾸는 순서

기존 라이브러리에 제품 이미지 파일 명명 규칙을 적용하는 일은 누구나 미룹니다. 4,000개 파일부터 시작하지 마십시오. 살아 있는 파일부터 시작합니다.

1. SKU 목록은 견적 시스템에서 내보냅니다. 사진 폴더에서 뽑지 마십시오—판매 중인 SKU가 빠져 있고 단종품이 남아 있습니다.
2. 최근 12개월 안에 리스팅, 카탈로그, 견적에 등장한 SKU를 표시합니다. 보통 라이브러리의 10~20%입니다.
3. 그것만 이름을 바꿉니다. 승인된 최신 파일부터 하고, 이전 버전은 이름 그대로 archive/로 옮깁니다.
4. 참조는 같은 날 갱신합니다. 이름을 바꾸면 새 URL이므로 옛 경로를 가리키는 곳은 조용히가 아니라 눈에 띄게 깨집니다.
5. 긴 꼬리는 필요할 때까지 두십시오. 판매 중인 200개 SKU에서 실제로 지켜지는 규칙이 아무도 지키지 않는 완벽한 규칙을 이깁니다.

한 번에 전부 바꾸는 방식의 실패는 정형화돼 있습니다. 금요일에 폴더 이름을 바꾸고, 주말에 리스팅이 비고, 그 규칙은 "사이트를 망친 그 일"로 폐기됩니다. 공개된 것부터 순서대로 하면 이전 비용은 일주일이 아니라 한 시간입니다.

발송 전 체크리스트

• 이름이 SKU로 시작하고, 카톤·견적서 인쇄와 완전히 일치한다
• 뷰 값은 폐쇄 목록에서 가져왔고 기억으로 입력하지 않았다
• 버전은 제품·마감·치수 변화 때문에만 올랐다
• 날짜는 승인일이며 촬영일이 아니다
• 하이픈만 사용, 소문자, 공백·악센트·#·? 없음
• 이름이 60자 이내이고 세 단계 폴더에서도 열린다
• 이전 버전이 archive/에 원래 이름으로 남아 있다
• 운영 중인 리스팅, 카탈로그 페이지, 보낸 견적이 현재 파일을 가리킨다
• dim과 scale을 바꿔 넣지 않았다

FAQ

제품 이미지 파일 이름은 어떻게 짓는 것이 좋습니까?

SKU_뷰_버전_날짜.확장자를 소문자, 고정 순서로 씁니다. 동료와 바이어가 필요로 하는 네 가지 사실—어떤 제품, 어떤 뷰, 몇 번째 버전, 언제 승인—을 담고, 데이터베이스 없이 어떤 파일 탐색기에서도 올바르게 정렬됩니다.

파일 이름 맨 앞에는 SKU와 제품명 중 무엇이 와야 합니까?

항상 SKU입니다. 발주서, 카톤, 인보이스에 적히는 번호이고 바이어 보관 체계의 열쇠이기 때문입니다. 제품명은 시장, 마감, 언어에 따라 달라집니다. 제품명 순으로 정렬하면 마감이 두 개가 되는 순간 한 SKU가 알파벳 양끝으로 찢어집니다.

제품 이미지 파일 이름에서 피해야 할 문자는 무엇입니까?

공백, #, ?, %, &, <, >, :, ", /, \, |, *, 그리고 악센트나 비라틴 문자를 피하십시오. 윈도우가 몇 가지는 아예 금지하고, 공백은 URL에서 %20이 되며, #은 링크를 조용히 자릅니다. 가장 안전한 구분자는 하이픈입니다.

같은 제품의 다른 뷰 사진은 어떻게 이름을 붙입니까?

각 뷰에 폐쇄 목록의 한 단어를 고정으로 부여합니다—front, main, dim, detail, scale, pack, assembled, packed, break. 일회성 요청 때문에 새 단어를 만들지 마십시오. 이 목록이 있어야 알파벳 정렬이 콘택트 시트처럼 동작하고, 한 SKU의 모든 뷰가 항상 같은 순서로 모입니다.

사진이 바뀌면 버전 번호는 어디에 넣습니까?

뷰 바로 뒤, 날짜 앞에 넣습니다. 제품·마감·치수가 바뀔 때만 올리고 조명이 좋아졌을 때는 올리지 않습니다. 노출만 바꾼 재촬영은 버전을 유지하고 새 날짜를 받습니다. 파일 자체를 바꿔야 하는데 버전을 움직일 수 없으면 -res 같은 접미사를 붙여 두 파일을 영구히 구분합니다.

치수 변경으로 버전이 뛰는 경우에는 이름만 바꿔서 해결되지 않습니다. 옛 도면의 숫자가 이미 제품과 맞지 않기 때문입니다. 여기서 워크플로가 값을 합니다. 한 번 측정하고, 그 값을 사진 속 제품의 실제 모서리에 고정하고, 각 채널이 요구하는 크기로 다시 내보내십시오. 새 버전은 눈으로 다시 그리는 대신 같은 원천에서 나옵니다. 생성된 장면은 보기 좋게 다듬을 수 있지만, dim 파일에는 측정한 값만 올라가야 합니다.

출처 및 참고 자료

• Microsoft Learn — Naming Files, Paths, and Namespaces(예약 문자, 예약 장치 이름, 260자 경로 제한)
• RFC 3339 — Date and Time on the Internet: Timestamps(ISO 8601에서 파생된 YYYY-MM-DD 형식)
• GS1 — GTIN 거래 상품 식별 키
• Unicode Standard Annex #15 — 유니코드 정규화 형식(합성 문자와 결합 문자)
• RFC 3986 — URI: 예약 문자와 퍼센트 인코딩
• AWS — CloudFront 파일 무효화(캐시 객체는 요청 경로를 키로 사용)