Home / Design

DCA답게 보이는가보다, 실제로 작동하는가.

이 사이트의 모든 섹션은 세 가지 질문을 통과해야 한다. 사진에서만 좋은지, 실제 스튜디오 맥락에서 자연스러운지, 사람이 강요 없이 쓰고 싶어 하는지.

WEBSITE DESIGN SYSTEM

읽고 쓰기 위한 화면.

DCA의 웹사이트는 폰트나 색 자체로 멋을 부리기보다, 실제 자료를 읽고 찾고 비교하기 쉬운 위계와 그리드로 성격을 만든다. 아래 규칙은 화면을 새로 만들 때마다 먼저 확인한다.

05 / IDENTITY / FAVICON DEVELOPMENT

16px에서도 DCA의 첫 글자가 읽혀야 한다.

파비콘은 웹사이트에서 가장 작은 표식이다. 여기서 중요한 px는 로고 안의 복잡한 좌표가 아니라, 브라우저가 실제로 읽는 정사각형의 크기다. 그래서 작은 탭에서도 D가 먼저 읽히는지, 검은 필드와 내부 빈 공간이 무너지지 않는지를 기준으로 다시 정리했다.

CURRENT APPLICATION / 2026-07-25

Corner D를 현재 사이트, 브라우저 탭, Apple 터치 아이콘의 공통 표식으로 적용했다. 512px는 다시 내보내기 위한 기준 파일이고, 실제 탭에서는 주로 32px 또는 16px로 읽힌다. Deep Cut D는 같은 조건에서 비교할 수 있도록 보관한 대안이다.

출력 크기	실제 쓰임	이 크기에서 확인할 것
512 × 512px	보관, 문서, 다시 내보내기를 위한 기준 파일	선의 밀도와 전체 비례가 안정적인지 본다.
180 × 180px	iPhone·iPad 홈 화면의 Apple 터치 아이콘	검은 필드와 D의 빈 공간이 답답하지 않은지 본다.
32 × 32px	일반적인 데스크톱 브라우저 탭	D의 외곽과 오른쪽 곡선이 한 덩어리로 읽히는지 본다.
16 × 16px	가장 작은 탭과 오래된 인터페이스의 fallback	세부 묘사 대신 D의 실루엣과 중앙 빈 공간만 남는지 본다.
내부 x/y 좌표	제작 중 재현을 위한 참고값	공개 규격이 아니다. 좌표를 외우기보다 16px에서 시각적으로 중앙에 보이는지 확인한다.

SVG / MASTER

색과 좌표를 유지하는 벡터 원본. 브라우저가 우선 읽는다.

PNG / 512PX

문서, 미리보기, 다시 내보낼 때 쓰는 기준 크기.

PNG / 180PX · 32PX · 16PX

Apple 터치 아이콘과 브라우저 탭에서 실제로 읽히는 크기.

ICO / FALLBACK

여러 PNG 크기를 담은 호환용 파일. Corner D 내려받기.

DECISION / WHY THIS ONE IS LIVE

현재 파비콘은 Corner D다.

DCA는 아카이브의 첫 탭처럼 보이는 표식이 필요했다. Corner D는 왼쪽의 단단한 시작점, 넓은 내부 빈 공간, 우측으로 시각 보정한 곡선을 한 덩어리로 유지한다. 정중앙의 좌표보다 16px 화면에서 더 가운데처럼 읽히는 쪽을 선택했다. 이후 자료는 이 두 안의 정식 SVG, PNG, ICO만 남기고, 중간 후보와 비교 보드는 정리했다.

Live evidence / 1:1마우스를 올리거나 키보드로 포커스하면 같은 물건의 실사 증거로 전환된다.

Same subject / 1:1전환 전후에도 1:1 프레임과 판단 대상은 그대로 유지한다.

Identity / 1200×630손그림과 외부 공유 이미지는 사진 규칙의 예외로, 중앙의 여백을 보존한다.

SPACE 014px

SPACE 028px

SPACE 0416px

SPACE 0624px

SPACE 1248px

Home / Development

웹사이트는 파일 하나가 아니라, 기록과 배포가 이어지는 운영 구조다.

DCA 웹사이트는 로컬 작업 폴더, GitHub의 변경 기록, Vercel의 배포, 도메인의 DNS 연결, 운영자 글 작성 도구가 연결된 상태로 운영된다. 이 페이지는 그 구조와 실제 설정 과정을 클라이언트가 확인할 수 있도록 남긴 개발일지다.

이 페이지를 읽는 법.

웹사이트의 구조·디자인을 바꾸는 일은 Local에서 시작한다. 글과 이미지를 빠르게 발행하는 일은 Editor에서 시작한다. 두 경로 모두 GitHub에 기록된 뒤 Vercel을 거쳐 같은 대표 주소에 공개된다. 즉, 작업 시작점은 달라도 공개되는 결과와 기록의 기준은 하나다.

01 / PUBLISHING FLOW

수정은 로컬에서 시작하고, 공개는 Vercel에서 끝난다.

디자인, 레이아웃, 고정 페이지, 이미지 자산을 고칠 때는 dca-website 폴더에서 작업한다. 변경이 완성되면 Commit으로 이유를 남기고 Push로 GitHub main에 보낸다. Vercel은 main을 감지해 새 Production 버전을 만들고, 준비 상태가 되면 대표 도메인이 그 버전을 보여준다.

1. Local / dca-websiteHTML, 이미지, 글 구조를 수정하는 실제 작업 폴더다.
2. GitHub / Repository변경된 파일과 버전을 보관하는 원격 기록이다. Commit은 한 단위의 기록, Push는 그 기록을 GitHub로 보내는 일이다.
3. Vercel / Productionmain 브랜치에 Push가 들어오면 Vercel이 자동으로 새 버전을 배포한다. 별도의 수동 업로드는 필요하지 않다.
4. deepcoucharchive.krGabia DNS가 Vercel을 가리킨다. 방문자는 최종적으로 이 주소에서 HTTPS로 사이트를 본다.

로컬 변경을 공개하는 순서.

1. 1. Pull먼저 GitHub의 최신 내용을 로컬 폴더로 받아온다. Editor나 다른 기기에서 발행한 글이 있다면 이 단계에서 작업 폴더와 맞춰진다.
2. 2. EditHTML, CSS, 이미지 파일, 문서 내용을 수정한다. 이 단계는 방문자에게 아직 보이지 않는다.
3. 3. Local check로컬 미리보기에서 화면, 링크, 이미지, 한글·영문 전환을 확인한다.
4. 4. Commit무엇을 왜 바꿨는지 짧은 메시지와 함께 하나의 버전으로 확정한다.
5. 5. Push확정된 버전을 GitHub main으로 보낸다. 이 순간부터 Vercel의 자동 배포가 시작된다.
6. 6. Production checkVercel이 Ready 상태가 된 뒤 대표 도메인에서 실제 공개 결과를 확인한다.

02 / OPERATING ROUTES

바꾸려는 것에 따라 시작하는 도구가 다르다.

모든 작업을 한 도구에서 처리하지 않는다. 사이트의 형태를 바꾸는 일, 글을 발행하는 일, 보안·도메인을 관리하는 일은 시작 지점이 다르다. 대신 최종 공개는 항상 GitHub의 기록과 Vercel의 배포를 통과한다.

03 / EDITOR

글은 브라우저에서 작성하고, 공개 저장은 GitHub를 거쳐 배포된다.

운영자 도구는 공개 메뉴에 넣지 않은 #editor 경로다. 운영자 비밀번호를 통과하면 제목, 분류, 날짜, 요약, 본문, 링크, 이미지를 넣고 공개 저장할 수 있다. 공개 저장은 GitHub의 글 데이터와 이미지 파일을 업데이트하고, Vercel이 이를 다시 배포한다.

1. 1. #editor 열기운영자만 알고 있는 경로로 접속하고 액세스 코드를 입력한다. 이 경로는 상단 메뉴에 노출하지 않는다.
2. 2. 기본 정보 입력제목, 분류, 날짜, 요약을 먼저 적는다. 제목은 Writing 목록의 첫 인상이고, 요약은 글의 성격을 빠르게 판단하게 하는 문장이다.
3. 3. 본문 편집본문에서는 제목 단계, 굵게, 목록, 인용, 링크, 이미지 첨부를 필요한 만큼 사용한다. 링크는 문장을 선택한 뒤 넣고, 이미지는 커서 위치에 첨부한다.
4. 4. 이미지 점검사진은 긴 변과 용량을 웹용으로 줄인다. 이미지가 본문 흐름을 끊지 않는지, 공개해도 되는 자료인지, 모바일에서도 읽히는지 확인한다.
5. 5. 공개 저장공개 상태로 저장하면 GitHub에 기록되고 Vercel이 자동 배포한다. 저장 직후 바로 보이지 않아도 배포가 Ready가 될 때까지 잠시 기다린다.
6. 6. 발행 결과 확인Writing 목록과 글 상세 주소를 열어 제목, 날짜, 이미지, 링크가 의도대로 보이는지 확인한다. 이어서 로컬에서 작업할 때는 Pull부터 한다.

글을 만들 때 확인할 항목.

04 / DOMAIN AND DNS

도메인은 주소이고, DNS는 그 주소가 향하는 길이다.

Gabia에서 관리하는 DNS 레코드가 Vercel의 서버를 가리키도록 설정했다. 루트 주소는 A 레코드, www는 CNAME 레코드로 연결한다. 설정이 전 세계에 반영되는 데에는 시간이 걸릴 수 있으며, Vercel이 SSL 인증서를 만든 뒤 HTTPS가 활성화된다.

DCA 주소 정책.

DNS에서 실제로 하는 일.

05 / SECURITY AND RECOVERY

공개되는 정보와 서버에만 남아야 하는 정보를 분리한다.

웹사이트의 HTML, 이미지, 공개 글은 GitHub에 기록된다. 반면 Editor 액세스 코드와 GitHub 쓰기 권한처럼 외부에 보이면 안 되는 값은 Vercel의 Environment Variables에만 저장한다. 이 분리는 글을 어디서 발행하든 같은 보안 기준을 유지하기 위한 최소 장치다.

문제가 생겼을 때 먼저 보는 곳.

07 / HOME INTERACTION

Home은 JavaScript 없이 중심과 hover를 유지한다.

Home의 역할은 한 장의 이미지를 화면 중심에 정확히 두고, 좌측 메뉴와 우측 제어를 조용히 유지하는 것이다. 다크 모드에서도 밝은 띠를 만들지 않고, 배경에 따라 메뉴 색을 계산하지 않는다. JavaScript는 방문할 때마다 세 장의 필름 사진 중 하나를 고르는 일만 맡고, 중심 정렬과 hover·keyboard focus는 CSS가 처리한다.

const updateRandomHomeImage = () => {
  const candidates = homeFilmImages.filter((image) =>
    image.src !== previousHomeImageSrc);
  const pool = candidates.length ? candidates : homeFilmImages;
  const image = pool[Math.floor(Math.random() * pool.length)];
  randomHomeImage.src = image.src;
};

.home-landing {
  display: grid;
  place-items: center;
  min-height: 100dvh;
  padding: var(--space-6);
}

방문자에게 보이는 결과.

11 / 2026-07-19

현재 운영 구조가 만들어진 순서.

아래 기록은 현재 실제로 연결된 도구와 주소를 기준으로 쓴다. 미완성 계획이 아니라, 현재 사이트가 어떻게 발행되고 어디에서 확인되는지를 남기는 운영 이력이다.

1. GitHub Pages에서 Vercel로 전환정적 페이지 공개뿐 아니라 운영자 글 발행과 서버 환경변수를 안전하게 다루기 위해 Vercel을 연결했다.
2. GitHub 권한을 발행 용도로 한정Editor가 글과 이미지를 기록할 수 있도록 필요한 저장소에만 연결하고, Contents 쓰기 권한만 사용하도록 구성했다. 실제 토큰 값은 Vercel에만 저장한다.
3. 운영자 Editor 연결브라우저에서 작성한 글과 이미지를 GitHub 저장소에 기록하고, Vercel이 이어서 배포하도록 구성했다. 공개 저장 테스트도 Writing 목록에서 확인했다.
4. 이미지 발행 기준 확정글당 최대 8장, 장당 2MB, 총 3MB로 제한해 저장소와 배포 용량을 관리한다. 영상 원본은 외부 영상 서비스에서 임베드한다.
5. .kr을 대표 주소로 확정deepcoucharchive.kr은 실제 사이트, www·.com 주소는 308 이동으로 대표 주소에 정리했다. 주소가 여러 개여도 방문자는 하나의 URL을 보게 된다.
6. 배포 이력 보존GitHub Commit과 Vercel Deploy 기록을 통해 어느 시점의 사이트라도 확인하고 필요하면 마지막 정상 배포를 기준으로 복구할 수 있다.

02 / INQUIRY DELIVERY

문의 발송 환경

문의 폼을 실제 이메일 발송으로 연결하기 전에, 계정 소유자와 발신 기준을 DCA 기준으로 정리합니다.

1. 01

   대표 확인 필요

   Resend 계정 생성 및 팀 초대

   Resend는 DCA 소유 계정으로 개설하고 대표님이 계정 소유자가 됩니다. 웹사이트 설정 담당자는 비밀번호 공유 대신 팀 초대로만 연결합니다.

   필요한 확인

   DCA 소유 이메일, Resend 가입 완료, 문의 수신 주소, 발신 주소 또는 도메인

   권한 전달 원칙

   비밀번호와 API 키는 이 페이지에 적지 않습니다. 팀 초대 또는 별도 비공개 채널로만 전달합니다.

03 / SERVICE INFORMATION

서비스 자료

웹사이트에 공개할 서비스는 이름보다 실제 제공 범위와 진행 조건이 먼저 읽혀야 합니다. 현재 판매하거나 제공 중인 항목만 확인해 정리합니다.

1. 02

   자료 전달 대기

   판매·제공 중인 서비스 목록

   서비스별로 실제로 가능한 일과 고객이 알아야 할 기본 조건을 한 줄씩 확인합니다. 가격이나 상세 계약 조건은 공개 여부를 함께 결정한 뒤 반영합니다.

   필요한 자료

   서비스명, 한 줄 설명, 포함 범위, 대상, 기본 진행 방식

   공개 기준

   가격 공개 여부, 견적 방식, 최소 단위, 일정·예약 조건

04 / SELECTED WORK

작업물 선정

그동안 참여한 작업 중 DCA가 실제로 어떤 역할을 해왔는지 보여 주는 사례만 선별합니다. 작업의 규모보다 공개 가능 여부와 맥락이 더 중요합니다.

1. 03

   자료 전달 대기

   공개 후보 작업 6–12개

   초기에는 대표 사례를 너무 많이 나열하지 않고, 사운드·세션·공간의 성격이 다른 작업을 균형 있게 봅니다. 최종 공개 전에는 각 프로젝트의 사용 허가를 다시 확인합니다.

   필요한 자료

   프로젝트·아티스트·브랜드명, 연도, DCA 역할, 공개 가능한 사진·영상·음원·링크

   사용 확인

   공개 허가 여부, 크레딧 표기, 편집·썸네일 사용 범위

05 / DELIVERY METHOD

전달 방식

이 페이지는 무엇이 필요한지 확인하는 목록입니다. 원본 파일, 계정 권한, 비밀번호, API 키처럼 민감한 정보는 공개 문서에 올리지 않습니다.