포트폴리오 라이브 데모 4개를 한 세션에 밀어넣은 날

오후 6시에 시작할 때 목표는 딱 하나였다. esign-pdf 데모 하나 마무리하고 썸네일 붙이고 끝. 근데 그게 안 됐다. 정확히는, esign-pdf 작업을 끝내고 나서 "어차피 데모 카드 틀이 잡혀있는데 나머지 것들도 다 올리자"는 생각이 들었고, 자정이 넘어서야 손을 놨다. 결과적으로 키워드 분석 대시보드, AS 접수·조회·관리자, 엑셀 업로드 조회 대시보드까지 총 4개 라이브 데모를 한 세션에 추가했다.

라이브 데모를 이 시점에 몰아서 올린 맥락

포트폴리오 사이트에 그간 올린 프로젝트들이 스크린샷과 설명 텍스트로만 구성돼 있었다. 정적 이미지만 보고 "이 툴이 실제로 어떻게 작동하는지"를 설명하려면 미팅마다 별도로 데모를 켜야 했는데, 그게 꽤 번거로웠다. 리드 포지션에서 클라이언트나 내부 이해관계자에게 프로젝트를 소개할 때 "직접 눌러보세요" 한마디로 끝낼 수 있는 링크 하나가 있으면 훨씬 낫다는 걸 체감한 게 이미 오래됐는데, 실제로 손이 간 건 이날이었다.

각 데모는 demo/<slug>/index.html 단일 파일로 제작한다는 규칙을 이미 정해뒀다. 외부 API 의존 없이 브라우저에서 완결되는 구조. 그래야 CF(CDN) 앞에서 별도 서버 없이 정적으로 서빙되고, 어디서든 로드가 빠르다. 이 구조가 이미 잡혀있었기 때문에 첫 번째 데모(esign-pdf)만 구조 잡는 데 시간이 걸렸고, 나머지 세 개는 상대적으로 빠르게 이식할 수 있었다.

데모를 추가할 때 체크하는 항목은 크게 이 정도다.

이 절차를 그냥 기억에 의존하다 보면 썸네일 빠트리거나 CF 퍼지 잊어버리는 일이 생긴다. 그래서 이날 CLAUDE.md에 표준 절차로 박았다. 다음에 데모 추가할 때 이 파일 보고 체크리스트처럼 쓰면 된다.

esign-pdf: 기능 완성보다 버그 하나가 더 신경 쓰였다

이날 가장 먼저 손댄 게 esign-pdf였는데, 기능 자체는 이미 만들어져 있었다. 캔버스 위에 서명을 그리고, 도장 이미지를 올리고, PDF를 생성해서 다운로드하는 흐름. 문제는 서명을 한 번 그린 다음 "초기화" 버튼을 누르면 캔버스가 지워지는 건 맞는데, 결과 영역에 이미 렌더된 서명 이미지와 도장 이미지가 그대로 남아서 엑박으로 깨지는 현상이었다.

원인은 단순했다. 초기화 시 캔버스 데이터만 지우고, 미리보기 <img> 태그의 src는 건드리지 않은 것. src가 빈 문자열이 되거나 유효하지 않은 상태로 남으면 브라우저가 깨진 이미지 아이콘을 띄운다.

수정은 어렵지 않았다. 서명이 없는 상태에서는 img 요소와 도장 컨테이너를 display: none 처리하고, 서명이 생성될 때만 다시 보이도록 했다. 핵심 로직은 이런 식이다.

function clearSignature() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);
  signaturePreview.style.display = 'none';
  stampContainer.style.display = 'none';
  signatureDataUrl = null;
}

function renderSignature() {
  signatureDataUrl = canvas.toDataURL('image/png');
  signaturePreview.src = signatureDataUrl;
  signaturePreview.style.display = 'block';
  // 도장 이미지는 별도 업로드 여부로 판단
}

작은 버그지만 데모에서 엑박이 뜨면 신뢰도에 바로 영향이 간다. 클라이언트 앞에서 "이 부분은 버그인데 실제 서비스는 괜찮아요"라고 말하는 상황은 만들고 싶지 않다. 데모는 실서비스 수준으로 작동해야 한다는 게 원칙이라, 이 수준의 버그도 그냥 올리기가 싫었다.

세 개 데모를 연달아 이식하면서 느낀 것

esign-pdf 버그 잡고, 썸네일 만들고, 카드 올리고 나니 9시쯤 됐던 것 같다. 그때부터 키워드 분석 대시보드, AS 접수·조회·관리자, 엑셀 업로드 조회 대시보드를 순서대로 붙였다.

각 데모의 성격이 조금씩 달랐다.

• 키워드 분석 대시보드: 검색 키워드를 입력하면 트렌드 그래프, 관련 키워드 추천, 경쟁도 분포 같은 분석 결과를 시각화해서 보여준다. 실제 외부 API 없이 목 데이터로 동작하지만, 인터랙션이 자연스럽게 느껴지도록 로딩 딜레이와 에러 케이스를 구현했다.
• AS 접수·조회·관리자: 탭 구조로 접수/조회/관리자 세 역할을 하나의 파일에 담았다. 접수 쪽에서 폼을 제출하면 조회 탭에서 목록이 갱신되고, 관리자 탭에서 상태를 변경할 수 있다. 상태가 localStorage에 임시 저장되니 새로고침 전까지 흐름이 살아있다.
• 엑셀 업로드 조회 대시보드: SheetJS를 CDN에서 끌어와서 브라우저에서 직접 xlsx 파싱. 파일을 드래그앤드롭하면 테이블이 렌더되고, 컬럼 필터링, 정렬 기능이 붙어있다. 외부 서버 전혀 없이 브라우저에서 완결된다는 걸 보여주기 좋은 케이스라 데모 효과가 크다.

세 개를 연달아 만들면서 체감한 건, 첫 번째 데모를 제대로 만들어두면 나머지는 패턴 따라가는 속도가 확실히 빨라진다는 점이다. HTML 뼈대, CSS 리셋, 공통 유틸 함수 구조가 일관되면 이식 시 머리 쓰는 부분이 줄어든다.

데모 제작 표준 절차를 CLAUDE.md에 박은 이유

데모 하나 추가하는 데 관여하는 단계가 생각보다 많다. 파일 제작, 썸네일 생성, 카드 등록, CF 퍼지, 검증. 이걸 순서대로 빠짐없이 하면 문제없는데, 피곤하거나 급할 때 CF 퍼지를 빠트리면 구 버전 파일이 한동안 캐시에서 서빙된다. 썸네일 없이 카드만 올리면 레이아웃이 무너진다.

CLAUDE.md에 절차를 박아두는 이유는 단순히 잊어버리지 않으려는 것도 있지만, 나중에 다른 사람이 이 레포에서 작업할 때도 같은 기준으로 데모를 추가할 수 있게 하려는 것도 있다. 지금은 혼자 관리하지만, 언젠가 누군가 합류했을 때 "어떻게 추가해요?"라는 질문에 답하는 문서가 되는 셈이다.

포트폴리오 전체 구조와 배포 방식도 같이 정리해서 넣었다. 라이브 데모 카드와 일반 프로젝트 카드를 어떻게 구분하는지, 데모가 갖춰야 할 기준이 뭔지, index.html 카드 목록 수정 방법까지. 문서 자체가 길지 않은데 이게 있고 없고 차이가 나중에 꽤 크게 난다.

Bing SEO 온보딩 문서 보강

데모 작업 중간에 SEO 문서도 손봤다. Bing 웹마스터 도구에 외부 apex 도메인과 바이럴 도메인 14개를 추가로 등록하면서 기존 23개에서 39개로 늘어났는데, 이 SubmitFeed·POST 절차를 신규 사이트 온보딩 문서에 명시하지 않았더니 누락이 발생했던 적이 있었다.

docs/NEW-SITE-ONBOARDING.md와 docs/seo-infra.md에 Bing 등록 절차를 온보딩 필수 항목으로 명시했다. 새 사이트를 올릴 때 빠짐없이 체크하도록. Google Search Console 등록만 챙기다가 Bing을 빠트리는 패턴이 반복되고 있었는데, 문서에 박아두는 게 가장 확실한 예방이다.

돌아보면 이 시간대는 기술적으로 어려운 작업은 거의 없었다. 버그 하나 잡고, 데모 네 개 붙이고, 문서 두 군데 정리한 게 전부다. 그럼에도 실제로 시간이 많이 걸린 건 각 데모를 "그냥 작동하는 수준"이 아니라 "클라이언트 앞에서 켜도 창피하지 않은 수준"으로 만드는 데 들인 공 때문이다. 인터랙션의 자연스러움, 에러 케이스 처리, 빈 상태 처리 - 이런 부분을 신경 쓰다 보면 단순 이식 작업도 시간이 꽤 먹는다. 그게 맞는 방향이라고 생각한다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.