사이트 구축 기획안

01. 사업 목표와 구축 방향

사이트의 목표는 사진을 많이 보여주는 데서 끝나지 않는다. 매거진 에디터와 브랜드 담당자가 적합한 작업을 발견하고, 사진의 완성도를 확인한 뒤 구체적인 촬영 의뢰를 남기도록 한다. 대관 고객에게는 공간·요금·장비·이용 조건을 충분히 알려 예약 상담까지 연결한다.

핵심 경험: 작품을 발견한다 → 디테일로 실력을 확인한다 → 내 프로젝트와 연결한다 → 문의한다.

브랜드 경험은 절제된 조판과 사진 감상에서 만든다. 화려한 효과가 작품 확인이나 문의를 방해하면 축소한다. Awwwards SOTY는 독창성과 완성도의 목표로 삼고, 수상이나 검색 1위·AI 인용을 계약 결과처럼 보장하지 않는다.

02. 현재 준비 상태와 구축 범위

실제 준비된 것

2026-10-27 저장소의 실제 파일을 확인한 기준이다. 아래 수량은 신규 운영 시스템의 이관 완료나 모든 작업의 권리 확인을 뜻하지 않는다.

1차 출시 필수 범위

• 메인·Work·프로젝트·개별 사진·Studio Guide/Space·Location·Contact.
• 프로젝트/사진 다중 업로드, 순서·대표 컷·크레딧·분류·SEO·홈 큐레이션을 관리하는 백오피스.
• 촬영/대관을 구분한 실제 문의 접수, 저장·중복 방지·전달 실패 재시도.
• 기존 도메인과 핵심 경로·콘텐츠 보존, 검색 메타데이터·사이트맵·명시적 이전 규칙.
• 반응형·접근성·성능 계측, 백업·복구·운영자 교육·출시 후 점검.

별도 고도화 범위

실시간 예약 재고·결제/환불, 고객 납품 갤러리, 전자계약, CRM 전체, 영문 전체 사이트, 대량 콘텐츠 자동 생성, 전 작품 WebGL·전체 이미지 타일 뷰어는 1차에 넣지 않는다. 대표 컷 타일 확대나 시그니처 효과는 실험 통과 후 선택한다. 후속 기능의 추가는 일정과 비용을 다시 산정한다.

03. 타깃과 두 가지 문의 동선

촬영 문의와 대관 문의는 하나의 모호한 양식으로 합치지 않는다. Work의 종료 지점에는 참고 프로젝트가 연결된 촬영 CTA를 두고, Studio에는 날짜·이용 시간을 준비하는 대관 CTA를 둔다. 문의를 시작하기 위해 회원가입을 요구하지 않는다.

04. 정보 구조와 화면 기획

GNB는 Work / Studio Rental / Location / Contact를 기본으로 유지한다. 서비스 설명은 필요한 화면에 짧게 제공하고, 검색을 위한 긴 키워드 나열을 모든 화면에 반복하지 않는다.

아래는 신규 운영 앱의 경로 설계안이다. 기존 URL의 변경을 승인하거나 이전 매핑을 확정한 표가 아니다.

메인과 프로젝트의 문구 원칙

메인에는 예를 들어 “뷰티·패션 촬영과 스튜디오 대관, 스튜디오두잇.”처럼 실제 사업을 이해시키는 한 줄을 둔다. 슬로건은 최종 아트 디렉션에서 확정한다. 메뉴/버튼은 “작업 보기”, “이 작업으로 촬영 문의”, “공간·대관 안내”, “대관 일정 문의”처럼 행동을 명확히 쓴다.

프로젝트 노트는 “촬영 목적 → 담당한 비주얼/촬영 범위 → 사진으로 확인할 특징 → 관련 서비스” 순서로 쓴다. 확인하지 못한 캠페인 성과·매출 기여·매체 게재·인물 이름을 덧붙이지 않는다. 문의 완료 문구는 DB 저장이 확인된 경우에만 사용한다.

05. 디자인 시스템과 인터랙션

02D의 큰 배치와 사진 중심 방향을 유지하면서 운영 앱을 만든다. 현재 로고·아이콘은 검토 기준이며 최종 브랜드 채택은 별도 확인한다. 템플릿 UI를 얹는 대신 Doit Cut의 원본 토큰·SVG·상태 규칙을 컴포넌트로 옮긴다.

시그니처 후보는 실제 사진의 디테일 창과 프레임 연결 전환이다. 첫 대표 사진은 HTML 이미지로 즉시 제공하고 WebGL·셰이더는 필요할 때만 지연 로드한다. 사진 감상 중 얼굴/피부를 왜곡하거나 AI로 확대 디테일을 만들어 보여주지 않는다. GSAP·Lenis는 필수 설치 목록이 아니며 네이티브 스크롤과 필요한 애니메이션만으로 먼저 검증한다.

320–5120px의 주요 CSS 폭과 실제 모바일/태블릿/데스크톱 입력 방식을 구분해 검사한다. 60fps는 지정 기기의 효과 구간에서 측정할 목표이며 모든 기기 보장이 아니다. 디자인의 시각적 설득력은 기능 테스트와 별도 리뷰로 판단한다.

06. 콘텐츠와 포토그래퍼용 관리자

데이터와 운영 권한

admin/editor 권한을 나누며 문의 개인정보와 비공개 원본은 필요한 역할에만 허용한다. UI를 숨기는 것만으로 권한을 대신하지 않는다. 서버의 읽기·쓰기·업로드·게시 요청을 각각 검증한다.

운영자 검수 시나리오

1. 코드 수정 없이 신규 화보를 만들고 여러 사진을 올린다. 실험은 대표 고해상도 파일 30장으로 시작하며 운영 제한값은 측정 후 확정한다.
2. 실패한 사진만 재시도하고, 드래그 또는 이동 버튼으로 순서를 바꾼다. 원본 ID나 기존 공유 URL은 바뀌지 않는다.
3. 대표 컷·크롭·설명·확인된 크레딧을 넣고 모바일/데스크톱을 미리 본다.
4. 게시 후 홈·Work·사진 URL·사이트맵에 반영된 것을 확인한다. 미완성 변환본은 게시할 수 없다.
5. 잘못된 수정은 이전 버전으로 복구한다. 예약 게시를 포함할 경우 실제 스케줄러 실행·중복 방지·실패 알림까지 확인한다.

일괄 입력은 초안으로 이관하고 검토 상태를 남긴다. 공개 사이트에 있었다는 사실만으로 모든 사진의 재사용 권한이 확정됐다고 판단하지 않는다. 출처 제목이 없던 작업의 편집 이름과 추정 분류를 확정 메타데이터와 구분한다.

07. 기술 구조와 이미지 파이프라인

권장 구현 구조

Next.js App Router + TypeScript 공개 사이트와 Payload 관리자를 한 코드베이스로 시작하고 PostgreSQL을 연결한다. 독립 이미지 작업자와 객체 저장소를 분리한다. 프레임워크/Node/패키지 버전은 앱 초기화 때 Payload가 공식 지원하는 조합을 확인해 lockfile로 고정한다. 현재 저장소에 운영 앱이 설치됐다고 간주하지 않는다. Payload 설치 요구사항

방문자 → 공개 앱/CDN → 게시 콘텐츠 / 포토그래퍼 → 관리자 → DB·원본 저장소 → 큐·작업자 → 공개 파생본이 기본 흐름이다. 게시가 완료된 후 관련 홈·목록·상세·사이트맵 캐시를 갱신하고 실패 시 재시도한다.

호스팅 의사결정

현재 Cloudflare Pages는 정적 제안 공유에 사용 중이다. 관리형 Node.js/Next.js 호스팅에서 앱·CMS를 시작하는 안을 우선 검토하고, PostgreSQL·S3 호환 저장소(R2/S3 등)·작업자 제공자는 샘플 부하와 예산을 보고 정한다. 특정 유료 계정이나 요금제를 이 문서에서 구매 확정하지 않는다.

운영 앱을 기존 Pages 폴더에 그대로 올리는 방식으로 정하지 않는다. Cloudflare의 현재 안내도 정적 Next.js export와 Workers의 풀스택 실행 경로를 구분한다. Workers를 선택한다면 Payload·DB 드라이버·미디어 작업·캐시의 호환성을 별도 POC로 검증한다. DNS·이미지 CDN·리다이렉트와 앱 호스팅의 책임을 구분한다. Cloudflare Next.js 안내

사진 처리와 확대

• 원본 체크섬·가로세로·버전을 보존하고, 웹 마스터의 방향·색상 처리를 검토한다. 공개 파일의 GPS 등 민감 메타는 제거한다.
• AVIF/WebP와 필요한 폴백을 비동기로 생성한다. 피부·메이크업·섬유 질감을 대표 샘플로 비교하고 용량만을 기준으로 화질을 낮추지 않는다.
• 카드·Hero·뷰어의 srcset/sizes와 width/height를 명시한다. 처음 사진만 우선 로드하고 다음 컷은 제한적으로 준비한다.
• 기본은 승인된 고해상도 파생본과 1:1 감상이다. 초대형 대표 컷만 메모리 실험 후 타일을 검토한다. 손실 JPEG를 무손실 원본이라고 부르지 않는다.
• OpenAI 이미지는 아트 디렉션/UI 그래픽 탐색에 사용한다. 키는 서버/로컬 비밀 설정으로 관리하며, 비공개 촬영물의 외부 전송과 AI 자동 게시를 기본 동작으로 두지 않는다.

08. 검색·AI 검색과 기존 사이트 이전

콘텐츠가 적은 사진 사이트의 검색 설계

서버 HTML의 제목·설명·img·내부 링크, 정규 URL·메타데이터, XML/이미지 사이트맵을 먼저 구현한다. 모든 사진에 기계적으로 긴 설명을 붙이거나 필터별 유사 문서를 대량 생성하지 않는다. 개별 사진의 공유 주소는 모두 유지하되 색인은 독립적인 정보가 있는 페이지 중심으로 정한다.

구조화 데이터는 확인된 사업체의 LocalBusiness, 실제 작가의 Person, Service, CollectionPage/CreativeWork, ImageObject·필요한 VisualArtwork, BreadcrumbList를 내용과 맞게 사용한다. 폐기된 ProfessionalService를 새로 쓰지 않으며, FAQ는 실제 문답으로 제공하되 리치 결과 노출을 성과로 약속하지 않는다.

AI 검색에서도 사실 정보·일관된 사업체/작가 표기·공식 프로필·실제 게재 출처·발견 가능한 콘텐츠가 우선이다. Google은 AI Overviews/AI Mode를 위한 별도 필수 최적화나 특수 AI 파일/스키마를 요구하지 않는다고 안내한다. llms.txt와 선택적 Markdown은 같은 데이터에서 만드는 보조 안내로 두고, 사용자와 봇에 다른 사실을 제공하지 않는다. Google AI 검색 안내

네이버는 서치어드바이저 소유 확인, 수집/색인 상태·robots·사이트맵을 확인한다. 실제 주소와 공식 프로필 정보를 일치시키고, 유입을 문의와 연결해 관찰한다. 사이트맵 제출 자체를 순위 보장으로 설명하지 않는다. 네이버 사이트맵 안내

레거시 이전의 두 단계

도메인 승계와 URL 개편은 같은 작업으로 묶지 않는다. 먼저 Creatorlink의 실제 경로·본문·이미지·문의 동작을 보존한 상태로 운영 전환을 검증하고, 안정화 후 필요한 경로만 새 표준 주소로 이전한다.

• 조사 대상: /Contact_, /Rental-Guide_, /Rental%20Guide_, /Studio%20Space_, /Studio-Space_, /Guide_Contact, /Location 및 검색/내부 링크/로그에서 발견한 전체 URL.
• 기존 5행 pending CSV와 295개 작업의 공개 수집 목록은 자료 일부다. Search Console·네이버·사이트맵·Creatorlink 내보내기·방문 로그·가능한 백링크 자료의 합집합으로 이전 대상을 만든다.
• 공백·대소문자·언더스코어를 정확히 유지한다. 전역 소문자화/공백 치환/반복 디코딩을 하지 않는다. 새 slug는 기존 ID/URL과 대응표를 갖는다.
• 02D의 새 서비스 화면이 존재해도 초기 레거시 핵심 페이지의 내용·시각적 형태·문의 동작 보존 요구가 자동 철회되지는 않는다. 기존 핵심 페이지의 초기 보존안과 02D 리뉴얼 전환 시점을 출시 설계 검토에서 확정한다. 중복 공개 URL은 canonical/색인 정책까지 함께 결정한다.
• 영구 이전은 명시적 301/308로 최종 주소에 연결하고, 엉뚱한 홈 일괄 이동·루프·불필요한 체인을 막는다. 존재하지 않는 주소는 실제 404/410 정책을 따른다.
• Cloudflare Edge 또는 Next.js 중 매핑 책임 계층을 하나로 정한다. DNS only 연결에 Edge 규칙이 실행된다고 가정하지 않는다.
• 외부 이미지 호스트는 직접 통제할 수 있는지 따로 조사한다. 기존 이미지 URL을 유지/리다이렉트할 권한이 없는 경우 가능한 보존 방법과 위험을 명시하고 기존 계정을 먼저 해지하지 않는다.

모든 중요 URL에 최초 HTTP 응답·Location·최종 내용/상태·canonical·사진 매칭 증거를 남긴다. 컷오버 전에 미확인 중요 매핑을 해소하고 strict 이전 검사를 통과해야 한다.

09. 문의 접수와 성과 측정

필수 항목은 응대에 필요한 최소 정보로 정한다. 첨부는 1차 기본에서 파일명/참고 링크 또는 직접 전달 방식으로 시작하고, 실제 파일 업로드가 필요하면 용량·형식·보유/접근 정책을 별도 구현한다. 개인정보 수집 안내·보유 기간·수신 담당자·운영 답변 기준은 공개 전에 운영자가 확정한다.

접수 성공은 DB 저장 기준이다. 메일 실패는 자동 재시도하고 관리자에서 미전달 건을 찾는다. DB 실패를 성공으로 표시하지 않는다. 대관 문의 접수 화면을 예약 확정처럼 표현하지 않는다. 현재 시안의 초안/복사 동작을 실제 접수로 오인하지 않게 운영 구현 시 교체한다.

출시 전 최근 28일/가능하면 90일의 기존 지표를 확보하고, 출시 후 첫 4주에 비교 가능한 기준선을 만든다. 현재 방문·문의·수주 실측이 없어 임의의 증가율을 약속하지 않는다. 예를 들어 “CTA 클릭”은 접수나 수주와 다르게 센다. 분석 이벤트에는 문의 원문·이름·이메일·전화번호·첨부 URL을 보내지 않는다.

10. 일정·산출물·예산 구조

기존 실행 계획과 같은 디자인 방향 확정 이후 1인 시니어 개발 기준 약 10–14주 + 출시 후 30일 점검을 초기 가정으로 둔다. AI는 구현·검증·문서 작성을 보조하며 운영자 검토·권리 확인·실기기 검수를 대신하지 않는다. 담당자·콘텐츠 확인 속도·인프라 POC 결과에 따라 재산정하는 일정이며 확정 납기는 아니다.

콘텐츠/검색 조사는 앞 단계부터 병행하되, 실제 CMS 게시 흐름이 동작하기 전에 전체 수작업 이관을 시작하지 않는다. 첫 위험 실험 후 일정·예산을 재산정한다. 일정 압박 시 선택적 효과나 확대 타일을 줄이고, URL 보존·문의 안정성·권한·복구 게이트는 줄이지 않는다.

비용 산정 항목

현재 확정된 예산 합의나 공급자 견적은 없다. 최종 화면·기능·콘텐츠 정리·이전 범위를 기준으로 구축비를 산정한다. 고정비·사용량 비용·유지보수 범위를 분리해 제안하고, 변환/이미지 전송 샘플을 측정한 후 월 비용 한도를 정한다. 유료 리소스 생성은 계정·대상·예산이 정해진 단계에서 진행한다.

11. 품질 게이트와 출시·운영

성능 목표

현재 config/performance-budgets.json은 계획값이며 실제 성능 측정 결과가 아니다. 같은 기기·네트워크·브라우저·콜드 캐시 프로파일로 실험실 5회 중앙값을 비교한다.

Core Web Vitals의 일반적인 양호 경계는 LCP 2.5초·INP 200ms·CLS 0.1이며 p75 기준으로 평가한다. 내부 목표·실험실 TBT·실사용 INP를 혼동하지 않는다. Web Vitals 안내

출시를 승인할 증거

• 운영자가 코드 수정 없이 실제 화보 등록→정렬→게시→되돌리기와 스튜디오 안내 수정을 완료한다.
• 초안·비공개 원본·문의 데이터가 공개 API·검색·공유 캐시로 노출되지 않는다. 관리자 인증과 운영 MFA 방식을 검증한다.
• 모든 중요 레거시 URL·이미지가 의도한 내용에 도달하고 예상치 못한 404·루프·잘못된 사진 연결이 없다.
• 문의 성공/DB 실패/메일 실패/중복/스팸·재시도와 운영자 열람을 확인한다.
• 사진 직접 접속·모달 뒤로/앞으로·초점 복귀·실기기 터치·키보드·200% 확대·모션 축소를 확인한다.
• DB·파일 복원을 별도 환경에서 수행하고 이전 앱 배포로의 복귀를 리허설한다. 배포 롤백이 DB/파일까지 자동 복구한다고 가정하지 않는다.
• 대표 실기기와 지정 프로파일 성능 결과, 운영 canonical·robots·사이트맵·메일 수신처·모니터링 설정을 기록한다.

치명적 문의 장애·개인정보/초안 누출·광범위한 5xx/자산 실패·핵심 URL 오매핑이 있으면 출시에 통과시키지 않는다. 효과만 문제라면 효과를 먼저 끈다. 새 문의가 생긴 DB를 과거 백업으로 덮어쓰지 않으며, 데이터 변경과 문의 보존을 고려해 복구한다.

운영 리듬

매일 문의/전달 실패·가용성 알림을 확인하고, 매주 신규 콘텐츠·404·미응대·이미지 처리 실패를 본다. 매월 검색/전환/실사용 성능·비용과 의존성 업데이트를 검토한다. 정기적으로 복원 훈련을 수행하고 운영 담당자/연락 경로·백업 위치·만료/삭제 정책을 비공개 운영 문서로 인계한다. 공개 문서나 로그에 개인정보·비밀값을 넣지 않는다.

12. 착수 전 결정과 최종 인계

기획 기본안으로 독립적인 로컬 설계·실험을 진행할 수 있다. 이 문서만으로 최종 디자인 승인, 유료 계정 생성, 운영 DB 이전이나 도메인 전환 권한을 대신하지 않는다.

인계 패키지

운영 앱 소스/lockfile·디자인 토큰/SVG·데이터 스키마·검증된 이관 매핑·배포/복구 기록·운영자 매뉴얼·콘텐츠/문의 관리 교육·테스트/성능 증거·알림/백업 담당 체계를 전달한다. AGENTS.md·CLAUDE.md·작업 하네스에는 실제 실행 명령과 최신 상태를 유지하고, 미완료 항목을 숨기지 않는다.

바로 다음 작업

첫 구현 단위는 실제 화보 1개의 업로드 → 게시 → Work → 사진 확대 → 해당 작업 문의 접수 → 알림 실패 재시도를 연결하는 작은 운영 흐름이다. 여기에 호환 버전·사진 처리·공개 권한·문의 저장의 핵심 위험을 먼저 검증하고, 그 결과를 기준으로 전체 구축을 확장한다. 이번 요청에서는 이 실행을 시작하지 않고 기획과 수용 기준까지 정리한다.

부록. 근거와 문서 관계

이 기획안은 기존 요구사항/아키텍처를 삭제하거나 현재 시안을 운영 구현으로 간주하지 않는다. 실제 진행 상태는 STATUS·BACKLOG가 원본이다. 공식 문서는 2026-10-27 확인했으며 패키지·호스팅·봇 정책은 구현 시 재확인한다.