[Claude Code] AI에게 39개 기능을 피드백하고, 피그마 대신 디자인했더니

📝 한줄 요약

Phase 1에서 배운 "기획의 중요성"을 무기로, 6일 만에 Music 페이지를 기획부터 완성까지 해냈다. AI에게 기능 목록을 뽑아달라고 해서 39개를 전수 피드백하고, 피그마 대신 AI 디자인 도구로 시안을 만들어 코드로 변환한 과정.

바쁘시면 이것만 읽어도 돼요:

• Claude Code로 Music 페이지를 기획 → 구현 → 디자인 → 최적화까지 6일 만에 완성

• "기능 39개 전수 피드백" 방식 — AI가 정리한 목록에 내가 하나하나 디렉팅

• Pencil.dev 시안을 보여주면 AI가 코드로 바로 변환 — 피그마 경험자라면 신세계

• 이전 세션 맥락을 AI가 기억하고 있어서 연속성 있는 작업이 가능했음

• Phase 1의 교훈 "기획을 충분히 하고 들어가라"가 Phase 2에서 빛을 발함

🎯 이런 분들께 도움돼요

• 이전 게시글("'이쁘게 해줘'는 안 통한다")을 읽고 "그래서 그 다음은?"이 궁금했던 분

• AI 코딩으로 뼈대는 세웠는데, 디테일 잡는 단계에서 막힌 분

• 피그마를 쓰다가 AI 디자인 도구가 궁금한 분

😫 문제 상황 (Before)

Phase 1을 마무리하고 나니 뼈대는 있었다. 6개 카테고리의 홈페이지, 네비게이션, 어드민 CMS까지. 하지만 "작동은 하는데 진짜 쓸 수 있나?"라고 물으면 솔직히 아니었다.

이전 버전을 여러 번 엎으면서 DB에 유령 데이터가 꼬여 있었고, 이미지 저장소는 임시방편이었고, Music 페이지는 PRD만 있지 실제 구현은 안 된 상태. Phase 1에서 가장 크게 배운 건 "기획 없이 코딩하면 결국 엎게 된다"는 거였다.

그래서 Phase 2는 달랐다. 방향이 잡힌 상태에서, 한 페이지를 제대로 끝내보자.

🛠️ 사용한 도구

• Claude Code (Claude Opus 4.5 → 4.6)

• Pencil.dev — VS Code 내 AI 디자인 도구 (MCP 연동)

• 21st.dev Magic MCP — UI 컴포넌트 영감/생성

🔧 작업 과정

엎은 흔적부터 정리하기 — Day 12

Phase 1에서 프로젝트를 여러 번 엎었던 흔적이 곳곳에 남아 있었다. FocusRail(Work 페이지의 3D 카드 레일)에서 리오더하면 이미지는 그대로인데 텍스트만 바뀌는 버그가 있었는데, 혼자 고민하다가 깨달았다 — 이건 코드 문제가 아니라 이전 버전 DB 데이터가 꼬인 거였다.

내가 리오더 버그에 대해서 혼자 고민하다가 깨달은게 있는데, 이전 버전에서 생성한 DB 데이터가 꼬인 것 같아.

Claude가 근본 원인을 찾아서 3가지 버그를 한번에 해결했고, DB에서 유령 데이터 14개를 정리했다. 그리고 "더미 데이터 절대 금지" 규칙을 세웠다. AI가 친절하게 샘플 데이터를 넣어주는 건 좋지만, 실제 운영할 사이트에서는 그게 나중에 혼란을 만든다는 걸 배웠다.

개발자 피드백 → 인프라 결정 — Day 13

주변 개발자에게 프로젝트를 보여줬더니 "이미지 저장소를 Supabase Storage 말고 S3나 GCS 같은 전용 오브젝트 스토리지로 바꿔라"는 피드백을 받았다.

개발자 피드백: 이미지는 S3/GCS 추천. Supabase Storage보다 전용 오브젝트 스토리지가 좋다.

Claude에게 이 피드백을 전달했더니, 비용과 성능을 비교해서 Cloudflare R2를 추천했다. S3 호환이라 코드 변경이 적고, 무료 티어가 넉넉하다는 이유였다. 마이그레이션을 한 세션에 끝냈다 — 이미지 업로드 API 수정, Public URL 설정, 기존 컴포넌트 연동까지.

이런 인프라 의사결정을 직접 했다는 게 Phase 2에서 가장 "개발자스러워진" 순간이었다.

39개 기능 전수 피드백 — Day 14

Music 페이지가 어느 정도 돌아가기 시작하면서, 이제 디테일을 잡아야 했다. 근데 내가 만든 기능인데도 전체 목록이 머릿속에서 정리가 안 됐다. 그래서 Claude에게 물었다.

지금 '뮤직 페이지'에서 구현한 모든 기능들을 아주 디테일하게 쪼개서 나한테 말해줘

Claude가 A~F 6개 카테고리로 39개 기능을 정리해서 보여줬다. 뷰 전환 9개, YouTube 관련 7개, 별점+데이터 13개, 트랙리스트 7개, 리오더 2개, 에러핸들링 1개. 내가 만든 건데 AI가 나보다 잘 정리했다.

이 목록을 하나하나 보면서 피드백을 줬다:

최애트랙 URL 임베드 방식 삭제, 별점 없음 기능 삭제, 작성중 이탈 경고 필수, 트랙 순서 변경 추가...

한번에 8개 항목이 수정됐다. 이 방식이 정말 효율적이었다 — AI가 만든 걸 AI에게 정리시키고, 내가 디렉팅하는 패턴. 하나씩 "이거 고쳐줘"라고 하는 것보다 전체를 보고 판단하는 게 훨씬 빠르고 정확했다.

피그마 대신 AI 디자인 — Day 15

Music 페이지의 레일 디자인을 리뉴얼할 차례였다. 예전에 피그마를 써본 적이 있는데, 이번에는 Pencil.dev라는 VS Code 내장 AI 디자인 도구를 썼다.

Pencil.dev에서 시안을 잡고, 21st.dev에서 비슷한 느낌의 컴포넌트를 찾아서 프롬프트를 참고했다.

레일뷰 디자인: 중앙에서 멀어지면 작아지는 앨범커버 레일, 호버 시 헤드폰 아이콘 CTA,
Pencil 시안 참고, 14개 요구사항 + 21dev 프롬프트 참고

시안을 보여주니까 Claude가 바로 코드로 변환했다. 말로 "중앙이 크고 양옆이 작은 레일"이라고 설명하는 것보다, 시각적 레퍼런스를 주는 게 10배는 정확했다. 피그마 경험이 있는 분이라면 이 워크플로우가 신세계일 거다 — 디자인 도구에서 시안 → AI가 코드 → 바로 프리뷰.

이후 Grid 뷰를 삭제하고 레일 단일 뷰로 전환, 어드민 기능까지 레일에 통합하는 대공사를 했다. 위치를 bottom 30% → 38% → 43%로 여러 번 미세 조정했는데, 이런 디테일 잡기가 뼈대 세우기보다 오히려 더 오래 걸렸다.

안 보이는 트랙리스트의 미스터리 — Day 17

마무리 단계에서 황당한 문제를 만났다. DB에 트랙리스트 데이터가 분명히 있는데, 배포된 웹사이트에서는 안 보이는 거다.

DB에서 뮤직 페이지에 E라는 타이틀을 가진 앨범에 트랙리스트 데이터가 있어?
문제는 해당 트랙리스트가 DB에만 있고, 실제 웹에는 보이지 않아.

Claude와 함께 DB 확인(데이터 있음) → RLS 정책 확인(허용됨) → 코드 로직 확인(문제없음) → 직접 API 테스트(정상 반환)까지 전부 체크했는데 코드상 문제가 없었다. 결국 배포 환경에서 클라이언트가 DB를 직접 호출하는 구조 자체가 문제라는 결론에 도달해서, 서버에서 앨범과 트랙을 한번에 가져오는 구조로 바꿨다.

돌이켜보면 이건 내 기획과 디렉팅의 문제였다. 처음부터 데이터 흐름을 설계하고 들어갔으면 안 생겼을 문제. 첫 프로젝트니까 이런 시행착오가 있었지만, 다음에는 좀 더 잘할 수 있을 것 같다.

이전 기록을 기억하는 AI — 전체 기간

인상적이었던 건, Claude가 이전 세션의 개발 기록을 자체적으로 확인해서 이번 작업에 녹여준 것이다. "저번에 이 부분에서 이런 결정을 했으니까 이번에는 이렇게 가자"라는 식으로 맥락이 이어졌다. 매번 처음부터 설명할 필요 없이, 프로젝트의 히스토리를 공유하는 파트너와 일하는 느낌이었다.

✅ 결과 (After)

Before vs After

결과물

• 라이브 사이트: personal-web-five-coral.vercel.app/music

• Music 페이지: 무한 순환 레일, 인라인 상세 패널, 어드민 CRUD 전부 동작

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. "기능 목록 뽑아달라고 해서 전수 피드백하기" — AI한테 내가 뭘 만들었는지 정리시키고, 그 위에서 디렉팅. 하나씩 수정 요청하는 것보다 전체를 보고 판단하는 게 훨씬 빠름

2. "시각적 레퍼런스 > 말로 설명" — Pencil.dev 시안이나 21st.dev 컴포넌트 예시를 보여주면 AI가 의도를 정확하게 파악. "이쁘게 해줘"보다 목업 하나가 10배 효율적

3. "기획을 충분히 하고 들어가기" — Phase 1에서 뼈저리게 배운 교훈. Phase 2에서는 PRD 먼저 쓰고, 기능 목록 정리하고, 피드백 한 다음에 구현. 덕분에 엎는 일이 없었음

이렇게 하면 안 돼요

1. 디테일을 AI한테 맡기기 — 레이아웃 위치, 간격, 크기 같은 건 직접 눈으로 보고 디렉팅해야 함. AI는 "적당히"를 모름

2. 구조를 나중에 생각하기 — 데이터 흐름(서버에서 가져올지 클라이언트에서 가져올지)은 처음에 정해야 함. 나중에 바꾸면 연쇄적으로 문제가 생김

🌍 다른 업무에 적용한다면?

• 포트폴리오 사이트 아닌 다른 프로젝트에도 같은 패턴 적용 가능: PRD 작성 → AI 구현 → 기능 목록 뽑기 → 전수 피드백 → 디자인 도구 시안 → AI 코드 변환

• 피그마 대신 Pencil.dev 워크플로우는 개인 프로젝트나 빠른 프로토타이핑에 특히 유용. 디자이너 없이 혼자 하는 사람에게 추천

• 39개 기능 피드백 패턴은 코딩뿐 아니라 문서 작성, 기획서 검토 같은 데도 적용 가능 — AI에게 현재 상태를 정리시키고, 그 위에서 판단

🚀 앞으로의 계획

• 나머지 4개 페이지 완성: Read & Write, Photo Dump, Guestbook, About Me

• Music 페이지에서 잡은 패턴(서버 fetch, 레일 UI, 어드민 통합)을 다른 페이지에도 적용

• 최종적으로 커스텀 도메인 연결하고 실제 포트폴리오로 활용

📋 재사용 가능한 프롬프트

프롬프트 1: 기능 전수 피드백

지금 [페이지/기능명]에서 구현한 모든 기능들을 카테고리별로 분류해서 디테일하게 쪼개서 목록으로 보여줘. 각 기능마다 현재 상태(작동/미작동/부분작동)도 같이 표시해줘.

프롬프트 2: 디자인 시안 → 코드 변환

[디자인 도구명] 시안을 참고해서 [컴포넌트명]을 구현해줘. 추가 요구사항: [구체적인 요구사항 나열] [레퍼런스 URL/프롬프트]도 참고해줘.

프롬프트 3: 인프라 의사결정

[현재 사용 중인 서비스]를 [목적]에 더 적합한 서비스로 바꾸고 싶어. 비용, 성능, 마이그레이션 난이도 비교해서 추천해줘. 결정하면 바로 마이그레이션 진행해줘.