디자이너의 개발 환경: 2026년 Claude Code와 VSCode로 포트폴리오 웹사이트를 만든다면
1. CLAUDE.md를 살아 있는 디자인 시스템으로 만들기
생성 결과의 개성은 프롬프트보다 먼저 적어둔 제약에서 갈립니다.
- 프로젝트 루트의 `CLAUDE.md`에 구체적인 판단 기준을 기록
- 색상·타입 스케일·간격·라운드·그림자처럼 해석의 여지가 없는 브랜드 토큰
- 카드 동작·호버·모션처럼 반복 적용될 컴포넌트 규칙
- 원하는 것만큼 피해야 할 패턴과 페이지 의도도 명시
- AI 특유의 보라색 그라디언트나 글래스모피즘 같은 금지 항목
- “갤러리처럼 느껴져야 한다”처럼 각 페이지가 달성할 경험
- 결과가 어긋날 때 개별 코드를 고치기 전에 `CLAUDE.md`를 갱신
- 한 번 쓰는 브리프가 아니라 계속 조정하는 단일 기준점
2. 스크린샷 루프로 시각 품질 좁히기
포트폴리오에서는 텍스트 지시보다 실제 화면을 비교하는 반복 과정이 더 효과적입니다.
- 로컬 서버 실행 → 스크린샷 → 레퍼런스 비교 → 수정 → 재촬영의 루프
- Dribbble 이미지, 경쟁 사이트, Figma 프레임을 시각적 기준으로 활용
- 코드 설명만으로는 놓치기 쉬운 간격과 비례를 빠르게 교정
- 전체 페이지보다 내비게이션·히어로·카드·푸터를 나눠서 작업
- 먼저 하나의 컴포넌트로 디자인 시스템을 검증
- 기준이 맞은 뒤 페이지 전체로 확장해 재작업을 줄임
3. 콘텐츠 저장 위치는 작업 방식에 맞춰 선택하기
디자인은 다시 만들 수 있지만 사례 연구와 소개 문구는 작성 비용이 크기 때문에 관리 방식이 중요합니다.
- VSCode에 익숙하다면 프로젝트 안의 Markdown 파일이 기본 선택
- Claude Code가 직접 읽을 수 있고 콘텐츠와 코드의 버전이 함께 유지됨
- 긴 글을 쓰기에는 편집 환경이 다소 건조함
- 긴 글을 혼자 다듬는다면 Obsidian이 자연스러운 확장
- Markdown과 Git을 그대로 활용하면서 더 편안하게 글을 작성
- 협업자에게 피드백을 받는 과정은 다소 불편함
- 협업과 진행 상태 관리가 필요하다면 Notion이 적합
- 사례 연구별 초안·이미지 준비·게시 상태를 데이터베이스로 관리
- 코드용 Markdown으로 옮길 때 정리 작업이 생길 수 있음
4. 제작 순서가 포트폴리오의 유지 비용을 바꾼다
완벽한 첫 공개보다 실제 콘텐츠와 작은 단위의 검증이 더 오래가는 결과를 만듭니다.
- `CLAUDE.md` → 실제 콘텐츠 → 컴포넌트 하나 → 스크린샷 QA → 빠른 공개 순서
- 플레이스홀더로 꾸민 화면보다 거친 초안이라도 실제 사례 연구가 우선
- 작은 컴포넌트에서 제약을 검증한 뒤 범위를 넓힘
- 시스템이 갖춰지면 포트폴리오 업데이트 비용이 크게 낮아짐
- 타입 스케일이나 디자인 토큰의 한 번 수정이 전체 페이지에 반영
- 구직 직전에 몰아서 만드는 사이트가 아니라 계속 관리하는 자산으로 전환
- AI가 실행을 맡을수록 디자이너의 판단 과정이 더 중요한 작업물이 됨
- 선택한 제약과 금지 패턴이 취향을 보여주는 디자인 아티팩트
- 미래의 포트폴리오는 결과뿐 아니라 결정 과정까지 보여줄 가능성이 큼
