🎬 우리 회사 디자이너는 피그마를 안써요

▶️ 유튜브

• 원본 링크: https://youtu.be/M8lX45hzaMs?si=E-Ur9wJzgm6o2RGA

🖼️ 4컷 인포그래픽

💡 한 줄 결론

디자이너의 경쟁력은 더 이상 피그마 산출물 제작이 아니라, 실제 코드 맥락에서 AI와 함께 변경 영향 범위를 읽고 직접 수정·검증·배포 직전 단계까지 밀어붙이는 실행력에 있다. 초기 스타트업일수록 이 방식이 디자인-개발 왕복 비용을 줄이면서 제품 완성도와 속도를 동시에 끌어올릴 수 있다.

📌 핵심 요점

1. 코드에 연결된 AI를 쓰면 디자이너도 특정 화면 수정이 온보딩 플로우, 재사용 컴포넌트, 인접 UX에 어떤 파급을 주는지 감이 아니라 코드 근거로 파악할 수 있다.
2. CTA 버튼 비활성화처럼 원래는 가이드 전달과 개발 재구현으로 나뉘던 작업이, 자연어 요청→로컬 확인→수정 승인→PR 연결 흐름으로 압축되면서 이중 작업이 크게 줄어든다.
3. 코드 맥락을 아는 AI는 단순 레퍼런스 추천이 아니라 현재 구조에서 실제 구현 가능한 시각화 방식과 상태별 UI 시나리오까지 제안할 수 있어 제안의 실현 가능성이 높다.
4. 초기 제품에서는 개발자가 먼저 기능 뼈대를 만들고 디자이너가 실제 동작 제품 위에서 다듬는 방식이, 도메인 이해 부족으로 생기는 시안-구현 간 괴리를 줄이는 데 유리하다.
5. 이 운영 방식의 핵심 조건은 툴 이름이 아니라 역할 경계를 유연하게 보는 조직 신뢰, 코드 접근 허용, 그리고 AI 역량을 초기에 과소평가하지 않고 문서·위키·코드 맥락을 충분히 연결하는 태도다.

🧠 상세 요약

1) 배경과 문제 정의

스타트업 제품 개발에서는 기획서, 피그마, 실제 서비스가 분리될수록 커뮤니케이션 왕복과 해석 오차가 커진다. 이 영상은 그 문제를 줄이기 위해 디자이너가 정적 산출물 중심에서 벗어나 실제 코드와 AI를 작업 기반으로 삼을 때 무엇이 달라지는지를 보여 준다.

2) 섹션별 상세 정리

1. 피그마보다 실제 제품의 오류 신호를 먼저 잡는 방식 [00:00]

• 영상은 프로젝트 생성 화면에서 이름을 입력하지 않았는데도 CTA가 활성화처럼 보이는 문제를 바로 보여 주며 시작한다.
• 핵심은 “디자인 가이드를 어떻게 만들까”가 아니라 “실제 사용자에게 잘못된 기대를 주는 상태를 어떻게 즉시 바로잡을까”에 맞춰져 있다.

2. 디자이너 역할이 기획·개발 접점까지 넓어진 배경 [00:49]

• 출연자는 본업이 디자이너이지만 현재는 기획과 개발까지 함께 맡고 있다고 소개한다.
• 이 소개는 이후 사례들이 단순 툴 사용 팁이 아니라, 디자이너 역할 정의 자체가 바뀌고 있다는 맥락을 깔아 준다.

3. 피그마를 버린 것이 아니라 산출물 중심 프로세스를 버린 선택 [01:09]

• 회사는 한때 피그마를 썼지만, 로고 작업 이후 실질 효용이 낮다고 판단해 계속 유지하지 않았다.
• 포인트는 “피그마 불필요”라는 선언보다, 빠른 제품 조직에서 정적 시안보다 실제 서비스 수정이 더 가치 있다고 본 운영 판단이다.

4. 소스 코드 위에서 일하는 데 적응하는 전환 구간 [02:05]

• 처음에는 익숙한 디자인 툴을 잃는 느낌이 강했고, 하나의 코드베이스 위에서 협업한다는 개념 자체가 낯설었다.
• 그러나 익숙해진 뒤에는 더 빠르게 더 많은 범위를 다룰 수 있게 되면서, 기존 툴 중심 방식보다 자연스럽게 느껴졌다고 말한다.

5. 디자이너가 실제 레포지토리 안에서 일하는 구조 [03:00]

• 작업 환경은 실제 서비스 빅캔드의 코드 전체가 들어 있는 Claude Code 기반 워크스페이스다.
• 디자이너가 정적 화면 캡처나 목업이 아니라 실서비스 코드베이스를 기준으로 판단한다는 점이 이후 모든 데모의 전제다.

6. AI에게 영향 범위를 코드 기준으로 분석시키는 작업법 [04:14]

• 디자이너는 특정 화면을 바꿀 때 어디까지 영향이 퍼지는지 AI에게 먼저 묻고, 자신이 UI 디자이너라는 역할 정보도 함께 준다.
• 그러면 AI는 단순 시각 추정이 아니라 관련 파일, 연결 플로우, 컴포넌트 구조를 분석해 변경 범위를 정리한다.

7. 연결 화면·재사용 컴포넌트·검증 포인트를 함께 뽑아내는 가치 [05:47]

• AI는 프로젝트 생성 페이지가 온보딩이나 조직 생성과 어떻게 연결되는지, 스타일 일관성은 어디를 함께 봐야 하는지까지 제시한다.
• 이는 디자이너가 놓치기 쉬운 연계 화면과 검증 체크리스트를 사전에 확보하게 해, 수정 뒤 발생할 수 있는 부작용을 줄인다.

8. 설명이 아니라 로컬 실행 화면을 보면서 바로 수정하는 흐름 [06:35]

• 텍스트 설명만으로는 감이 떨어질 수 있기 때문에, AI에게 로컬 개발 서버를 띄워 실제 페이지를 보여 달라고 요청한다.
• 그 결과 디자이너는 문서 해석이 아니라 동작하는 인터페이스를 보며 판단하고, 수정 결과를 즉시 검증할 수 있게 된다.

9. CTA 비활성화 문제를 자연어 요청으로 직접 고치는 시연 [07:23]

• 디자이너는 “입력 전까지는 버튼이 disabled 상태로 보이게 해 달라”는 식으로 의도를 전달한다.
• 예전이라면 색상 가이드 전달에서 끝났을 작업이 이제는 구현 반영과 확인까지 한 흐름 안에서 이어지며, 디자이너가 사용자 상태 표현을 직접 책임진다.

10. 수정 확인 뒤 PR 단계까지 이어지는 압축된 협업 구조 [08:40]

• AI가 문제를 요약하고 수정안을 제시한 뒤, 승인하면 브라우저에서 바로 반영된 결과를 확인할 수 있다.
• 이후에는 개발 검토와 배포만 남게 되므로, 시안 제작→개발 재구현→재검수의 반복이 크게 줄어든다.

11. 대시보드 시각화도 코드 맥락 기반으로 재설계하는 사례 [10:17]

• 두 번째 사례에서는 숫자만 나열된 데이터베이스·스토리지·인증 카드를 더 이해하기 쉬운 UI로 바꾸려 한다.
• 여기서도 단순히 예쁜 그래프를 찾는 것이 아니라, 현재 구조에서 어떤 시각화가 현실적으로 구현 가능한지를 AI에게 묻는다.

12. 일반 챗봇과 다른 점은 ‘바깥 관찰’이 아니라 ‘내부 구조 이해’ [11:13]

• 외부 챗봇은 URL과 설명만 보고 조언할 수 있지만, 내부 코드 구조와 제약을 모른다는 한계가 있다.
• 반면 코드와 연결된 AI는 현재 컴포넌트 구조, 데이터 흐름, 구현 난이도를 바탕으로 더 실무적인 제안을 낼 수 있다.

13. 페르소나와 맥락을 준 프롬프트가 제안 품질을 끌어올리는 방식 [11:51]

• 출연자는 “나는 5년 차, 너는 15년 차 시니어 디자이너”처럼 역할과 경력 맥락을 명시해 AI 판단 일관성을 높인다고 설명한다.
• 이는 막연한 요청보다 더 강한 기준점을 제공해, 현재 제품 상황에 맞는 우선순위와 표현 방식을 안정적으로 끌어내는 데 유리하다.

14. AI가 상태별 시나리오까지 나눠 제안하는 확장성 [15:24]

• AI는 단순 시각화 아이디어에 그치지 않고 활성 상태, 용량 부족, 신규 프로젝트, 빈 상태 등 조건별 UI 전략까지 함께 제안한다.
• 과거에는 며칠 걸릴 수 있는 상태별 컴포넌트 설계가 짧은 시간 안에 압축되면서, 예외 케이스 누락으로 인한 뒤늦은 충돌도 줄일 수 있다.

15. 이 방식이 통하려면 필요한 조직 조건 [16:48]

• 출연자는 핵심 조건으로 직군 간 신뢰와 역할 경계의 유연성을 든다.
• 동시에 AI의 한계를 너무 빨리 정하지 않고, 코드·문서·위키·회의 맥락을 충분히 연결해 끝까지 물어보는 태도가 실제 생산성 차이를 만든다고 정리한다.

✅ 액션 아이템

• 현재 제품에서 디자이너 수정 요청이 잦은 화면 1개를 골라, AI에게 관련 파일·연결 플로우·재사용 컴포넌트·회귀 체크 포인트를 코드 기준으로 먼저 뽑게 하고 리뷰 체크리스트로 고정한다.
• 신규 생성 플로우나 온보딩 화면의 CTA 3개를 선정해 입력 전·입력 중·완료 후 상태가 실제 구현에서 어떻게 보이는지 로컬에서 직접 확인하고, 오해를 주는 상태 표현을 수정 후보 PR로 정리한다.
• 숫자 카드 중심 대시보드가 있다면 카드 2~3개를 골라 정상·부족·빈 상태별 시각화 안을 AI에게 현재 코드 구조 기준으로 제안받고, 구현 난이도와 정보 전달력 기준으로 비교한다.
• 디자인 요청 프롬프트에 역할 맥락을 넣어 2주간 A/B 테스트한다. 예를 들어 “나는 프로덕트 디자이너, 너는 시니어 디자이너로서 현재 컴포넌트 구조 안에서 가장 현실적인 안을 제안하라”는 형식과 일반 요청의 결과 차이를 기록한다.
• 기획서·디자인 파일·실서비스가 따로 노는 기능 1개를 골라, 정적 시안 리뷰 대신 실제 배포 가능한 화면 기반 피드백으로 전환하고 리뷰 왕복 횟수와 수정 리드타임 변화를 측정한다.

❓ 열린 질문

• 코드 맥락 기반 AI 제안이 현재 구조에 지나치게 최적화될 때, 장기적으로 더 나은 UX 구조 개편 기회를 놓치지 않으려면 어떤 리디자인 기준선을 별도로 가져가야 할까?
• 디자이너가 직접 코드 변경 흐름에 들어올수록 속도는 빨라지는데, 접근성·디자인 시스템 일관성·회귀 테스트 책임은 어떤 체크포인트로 재설계해야 병목 없이 유지될까?
• 초기 스타트업에서는 개발자 선구현 후 디자이너 후개선이 효율적이지만, 제품이 커진 뒤에도 이 방식이 계속 유효한지 판단하려면 어떤 지표로 UX 부채 누적을 측정해야 할까?
• 조직 신뢰가 낮거나 권한 경계가 강한 팀에서는 이 모델을 부분 도입할 때 어떤 화면·업무부터 시작해야 가장 적은 저항으로 효과를 입증할 수 있을까?