Figma는 이제 출발점에 있지 않아요
입사 3개월 신입 디자이너가 Figma 대신 Claude Code와 마크다운으로 디자인을 시작하게 된 기록. 세일즈맵의 마커·경로 바 작업을 예로, 추상적 시각 언어보다 수치로 지시해야 하는 이유와 코드↔Figma 왕복 워크플로, 그리고 시각화·마감 도구로 위치가 바뀐 Figma를 이야기한다.
안녕하세요. 입사한 지 3개월 된 신입 디자이너입니다.
3개월 동안 업무를 진행하면서 Figma를 활용하는 방식과 순서가 바뀌는 신기한 경험을 하고 있어요. 예전엔 Figma부터 열어서 작업했는데, 지금은 Claude Code와 마크다운(Markdown)이라는 텍스트 문서를 먼저 열어요.
처음엔 저도 이게 뭔가 이상하다고 느꼈는데, 지금은 이게 자연스러워졌어요. 그렇게 생각하게 된 과정과 작업 방식을 공유하고자 합니다.
1 어떤 업무를 했냐면요,
보험 설계사 대상의 고객 관리 지도 서비스 ’세일즈맵‘의 화면 디자인 및 퍼블리싱 업무 보조를 맡게 되었어요. ‘세일즈맵’이라는 서비스는 보험설계사의 현재 위치로부터 고객까지의 거리가 중요하지 않고, 하루에 방문하기로 한 고객 간의 경로와 주변 편의시설을 제공해서 고객이 많은 보험설계사가 고객 관리를 원활히 할 수 있도록 도움을 주는 서비스예요.
주로 Claude Code를 활용해서 작업했는데, 시안 디자인을 요청하고 Figma에서 수정을 거쳐 결정된 시안을 바로 퍼블리싱 하는 방식이었어요. 다음과 같은 순서로 작업했습니다.
Figma에서 디자인 작업을 시작하지 않았어요. 디자인 리드를 맡으신 디자이너 분이 만들어주신 디자인 시스템, 기획자 분들이 공유해주신 노션 기획서, 정책서부터 Claude가 잘 읽을 수 있도록 마크다운 파일로 만든 다음 디자인 작업을 시작했습니다. 디자인 시스템 유지와 보수 그리고 정책서와 기획서를 얼라인 하고 검토하는 시간을 줄이려고 했던 것 같아요. 확실히 일일이 제가 읽고 그에 맞는 화면을 직접 그리는 것보다, Claude가 마크다운을 읽고 판단해주는 게 편하고 정확하더라구요. 단, Claude가 마크다운을 대충 읽을 때도 있기 때문에 제가 직접 눈으로 보거나 다시 질문해서 검증하는 작업이 꼭 필요했어요.
2 글(Text)로 하는 디자인 - Claude Code ↔ Figma
업무 효율이 좋아지고 편해진 만큼, 번거로운 부분도 분명히 있었어요. 저는 Claude에게 시각적인 언어로 UI 디자인의 수정을 요청했는데, 잘 안 됐어요. 예를 들어, 출발과 도착 고객을 지정할 수 있는 경로 요약 필드의 시안 하나를 골라서 적용한 다음,"필드 섹션의 너비를 좀 더 넓혀서 여백을 줘", "텍스트 컬러의 위계가 많이 무너진 것 같아. 조정해줘." 같은 요청을 했는데 제가 원하는 대로 반영되지 않더라고요.
이때 같은 업무를 하고 있는 다른 디자이너 분이 ‘“상하 너비를 3px 넓혀줘”, “지금보다 20% 키워줘” 처럼 직접 수치를 입력해서 수정을 요청하니까 잘 되는데, 이 과정이 많이 비효율적으로 느껴진다’고 말씀해주신 것에 공감했어요. 그렇게 수치를 직접 입력해야 말을 잘 듣는다면, 요청하고 기다리는 시간에 제가 Figma에서 직접 조정하는 편이 훨씬 빠르게 확인할 수 있겠다는 생각이 들었거든요.
그리고 기존의 Figma MCP만으로도 서버에 구현된 컴포넌트를 Figma 파일 내부로 가져오는 것은 가능했어요. 다만 폰트의 경우 제약이 걸려서, 서버에 적용되었던 폰트와 다른 Figma 로컬의 폰트로 적용되는 이슈가 있었죠. 그래서 프론트엔드 개발자 한 분께 도움을 요청했고, Claude가 만든 시안들을 그대로 Figma로 가져올 수 있는 Playwright MCP와 폰트 반영이 가능한 피그마 MCP 공식 도구 generate_figma_design의 사용법이 담긴 마크다운 파일을 공유 받아서 업무에 사용해보기로 했습니다.
작업 했던 것 중 기억나는 사례가 두 가지 있는데, ‘고객 마커’와 ‘경로 선택 바’를 만들던 과정이 인상 깊었어서 기억나요. 저는 마커의 기본적인 형태 ‘핀 모양의 마커 + 마커 하단에 고객명이 적힌 라벨’만 설명한 후 3가지 시안을 만들어 달라고 요청했어요. 미리보기 용도로 .html이나 .tsx파일로 만들어주는데, 저는 시안이 마음에 들지 않았고, 핀의 형태를 직접 수정하고 싶었어요. 그래서 앞서 말했던 Playwright MCP 사용법 마크다운 문서의 경로를 복사해서 붙여넣은 다음, “이 문서를 참고해서 이 시안을 피그마 파일 [링크]에 옮겨줘.”라고 요청한 후, Figma에 잘 옮겨진 걸 확인할 수 있었습니다.
클로드의 3가지 시안 모두 동일한 핀 형태를 제안해줬는데, ‘세일즈맵’의 고객 위치 마커는 고객의 주소지 성격(자택, 회사)이 나뉘어져 있었기 때문에 그게 마커 핀에 표현되길 바랐어요.
그래서 다른 지도 앱을 참고해서 마커 핀 내부에 주소지의 성격을 드러낼 수 있는 아이콘을 추가했고, 디자인에 원형이 많이 쓰였기 때문에 통일감을 주고자 물방울 모양에서 말풍선 느낌으로 원형을 살려 디자인했어요.
고객들의 주소지가 동일 좌표일 때 사용되는 그룹 마커는 기존 시안처럼 원형이 겹치는 형태면 아이콘이 가려질 것 같아 걱정되었어요. 그리고 그룹 마커를 탭하면 해당 좌표에 위치한 고객 주소지의 정보가 뜨도록 기획 되어 있었기 때문에, 주소지의 성격 보단 이 좌표에 위치한 고객 주소지의 개수를 나타내고자 했습니다.
Copy Link to Selection 기능을 사용해서 수정된 디자인의 링크를 복사한 다음, [지도 위 마커 파일명.tsx]에 적용해 달라고 했어요. 그렇게 하면 Claude가 Figma MCP를 사용해서 그대로 잘 적용해주더라고요. 시각 보정과 디자인 시스템이 잘 적용되었는지 서버에서 확인한 다음, 리드 디자이너에게 전달했습니다.
다음으로는, 경로 선택 바 작업 과정을 말씀드릴게요. 같은 방법으로 화면과 UI에 대한 설명을 한 후, 화면 시안을 4가지 버전으로 뽑아달라고 했어요.
Figma로 처음부터 만들었다면 시안을 만드는 데도 시간이 많이 소요되었을 거예요. 하지만 Claude로 시안을 한 번에 원하는 만큼 뽑고, 비교하며 더 나은 시안을 고르는 시간이 많이 줄어들었다는 것을 체감할 수 있었어요. 즉, 생산성이 엄청 높아진 거죠.
하지만 아직 원하는 것의 100%를 부합하는 결과물은 아니었기 때문에, 이 화면 역시 Figma에서 수정 작업을 거치기로 했습니다.
Claude가 시안을 빠르게 만들어주긴 했지만, 시각 보정과 UX를 고려한 완성도 높은 결과물은 아니기 때문에 Figma에서 정밀하게 수정할 필요가 있었어요. Figma에서 직접 컨테이너의 수치와 텍스트의 행간 같은 사소한 것들을 조정하면서 시각 보정 작업을 했고, 컴포넌트 내부 요소의 구성과 배치 그리고 컴포넌트의 위치와 형태 등을 UX 측면에서 고민하며 수정했어요. Figma에 변수 설정이 된 마스터 컴포넌트가 있었다면 설정값을 바꾸기만 하면 되겠지만, Claude가 작성한 코드를 바탕으로 만들어진 프레임이었기 때문에 수치 값과 위치를 일일이 조정해야 했던 번거로움이 있었죠.
그리고 완성된 UI를 동일한 방식으로 Copy Link to Selection과 Figma MCP로 Claude가 읽어왔지만, 100% 그대로 반영하진 않더라구요. 개발 서버와 Claude에게는 토큰 문서와 코드가 존재하지만, Figma에서는 토큰이 정의되지 않은 채였기 때문인지 Figma에서 Claude로 넘어오면서 디자인 시스템이 많이 깨지기도 했어요. 그래서 하드 코딩 된(토큰이 바인딩 되지 않은) 곳이 있는지 파악하고 디자인 시스템을 반영하는 작업이 또 필수였답니다. 이 이슈는 나중에 Figma에 토큰 등록을 해두니 많이 개선되는 것을 확인할 수 있었어요.
3 작업 프로세스에서 Figma의 위치 변화
Claude가 초안을 빠르게 뽑아주니까 전체 작업 시간은 분명히 줄었다는 장점이 확실하게 있었지만, 왕복하는 과정이 조금 번거롭게 느껴지는 게 아쉬웠어요.
이 왕복 과정은 최근에 같이 작업하게 된 개발자 분이 소개해주신 Figma 공식 크롬 확장 프로그램으로 많이 해결됐어요. ‘Copy to Figma’ 라는 이름의 확장 프로그램인데, 서버에서 특정 UI 또는 화면 전체를 복사해서 피그마에 Ctrl+V하면 편집 가능한 형태로 붙여넣기 할 수 있는 도구예요. 지금 업무에서는 MCP 워크플로우 문서를 매번 언급하지 않아도 Claude Code ↔ Figma 왕복 작업을 할 수 있게 됐고, 이 변화를 겪으면서 이런 도구들이 빠르게 발전하고 있다는 걸 체감했어요.
그리고 Claude와 협업하면서 사소해 보이지만 결과물의 정확도를 크게 좌우했던 포인트들이 있었어요.
함께 작업하던 개발자 분이 언젠가 "Claude는 눈이 없는 기계라고 생각하세요.” 라고 말씀해주셨는데, 이 말이 떠오르더라고요. 저는 디자이너니까, 무언가를 설명할 때 당연하다는 듯이 시각적으로 설명하려고 했는데, 오히려 Claude가 이해하기 어려운 추상적인 언어로 소통하려 했기 때문에 제 요청이 만족스럽게 반영되지 않았던 거죠. Claude는 제 의사결정을 도와주는 협업 동료이기 때문에 생각보다 정확하게 지시할 필요가 있고, 디테일한 의사결정은 제가 해야 하는 역할이라는 걸 깨달았어요.
여기서 들었던 생각은, ‘AI가 디자이너를 대체할 것’이라는 의견에 동의하지 않게 되었다는 거예요. 이 말을 처음 들었을 때는 막연하게 “정말 그럴 수도 있지 않을까?” 하고 생각해 본 적도 있고 두렵기도 했죠. 하지만 앞의 작업을 하면서 디자인 의사 결정의 단계는 사람이 직접 작업하는 것이 맞다는 생각이 들었어요. Claude가 생산성을 높여주는 건 확실하지만, 디자이너의 생각을 따라가서 요청 사항을 반영하는 것에는 한계가 분명 있는 것 같아요. Claude는 아무래도 LLM인 만큼 쓰기보단 읽기를 더 잘하는 것 같다는 생각이 들었거든요.
그래서 저는 아직까지 Figma는 필요한 도구라고 생각해요. AI 시대에서 Figma는 눈으로 보면서 디테일을 다듬는 공간이 된 거죠. 즉, 디자인 의사 결정과 마감을 위한 시각화 도구로서 역할과 그 위치가 변화한 거라고 생각해요.
마치며,
처음에는 Figma가 아니라 LLM을 활용한 디자인 & 퍼블리싱은 익숙하지 않은 작업이라서 많이 헤맸던 기억이 나요. 학부생 때까지 화면은 무조건 Figma로 직접 그렸는데, 왜냐하면 제 경험 상 AI가 생성해주는 UI는 러프하고 일관성이 없어서 바로 쓸 수 있는 수준이 아니었거든요. 그런데 기간이 길지 않은 프로젝트에 투입된 만큼, 이 새로운 워크플로우를 빠르게 적용하고 적응할 필요가 있었어요. 프로젝트가 끝나갈 즈음 몇 년 간 굳어진 작업 방식은 온데 간데 없고, 새로운 작업 방식으로 완전히 정착했답니다.
요즘 저는 작업을 시작하기 전에 VS Code에서 마크다운 파일을 먼저 열어요. 나는 디자이너인데, Figma 대신 AI가 읽을 텍스트 문서를 먼저 만들고 찾는다는 게 처음엔 많이 어색했어요. “이게 디자인 업무가 맞나? 나는 이제 개발 업무를 하게 되는 건가?” 라는 고민도 했었죠. 그런데 다시 생각해보면, 제가 하는 일 자체가 바뀐 게 아니라 ‘의사 결정 맥락을 어디에 처음에 담느냐’가 달라진 것 같아요. 시스템의 어떤 컴포넌트를 무슨 맥락에서 어떻게 써야 하는지, 디자인 시스템이 잘 적용되었는지 판단하는 건 여전히 저의 몫이고, 그 판단을 이제 Figma가 아니라 텍스트 파일로 먼저 쓰고 읽게 된 거죠.
최근에 유튜브에서 ‘HOW I AI PODCAST’ 채널의 영상을 우연히 봤는데, 토스에서 근무하셨던 스타트업 ‘Else’의 강영화 대표님이 해주신 말씀이 있어요.“손으로 써야 되는 것들에 가치를 많이 두는 편이다” 이 말이 정말 인상 깊더라고요. 앞으로 제가 키워야 할 능력은 디자인 의사 결정을 글로 풀어내어 전달할 수 있는 능력을 키워야 하는 게 아닐까라는 고민을 하게 되는 것 같아요.