Figma와 Claude Code, 무엇을 어디까지 맡겨야할까요?

Figma와 Claude Code를 경쟁 도구처럼 놓고 고르면 둘 다 좁게 쓰게 됩니다.

둘은 잘하는 질문이 다릅니다. 하나는 여러 가능성을 나란히 놓고 여럿이 같이 보는 데 강하고, 다른 하나는 하나를 실제로 움직여보며 닫는 데 강합니다. 대체가 아니라 왕복입니다.

Figma에는 무엇과 왜를 맡깁니다

Figma가 강한 구간은 아직 답이 없는 단계입니다. 사용자 흐름, 정보 구조, 시각적 위계, 디자인 시스템, 그리고 여러 대안을 나란히 놓고 비교하는 일입니다.

과소평가되는 강점이 하나 더 있습니다. 여럿이 한 화면을 동시에 보며 말할 수 있다는 점입니다. 기획자와 개발자와 마케터가 같은 프레임을 가리키며 "이 사용자에게 무엇을 약속하는가"를 얘기하는 자리는 의외로 대체하기 어렵습니다. 코드로 가면 대화가 금방 구현 얘기로 샙니다.

확산이 필요한 순간에도 캔버스가 유리합니다. 방향을 여럿 그려보고 문장을 고치고 규칙을 만드는 일은 지우기 쉬운 도구에서 더 잘 됩니다.

Claude Code에는 어떻게 움직이는지를 맡깁니다

반대쪽 강점은 수렴입니다. 저장소 안의 컴포넌트와 제약을 읽고, 반복 구현을 맡고, 작동하는 프로토타입을 만들고, 상태를 넓혀 보는 일입니다.

데이터가 비었을 때, 요청이 실패했을 때, 화면이 좁아졌을 때 어떻게 보이는지를 바로 확인할 수 있습니다. 이건 시안으로는 끝내 알 수 없는 정보입니다.

큰 코드베이스를 이해하고 수정하고 문서화하는 일도 여기 속합니다. "이 버튼 스타일이 지금 몇 군데서 쓰이고 있나"는 디자이너가 자주 궁금해하지만 Figma에서는 답할 수 없는 질문입니다.

Figma Make와는 어떻게 갈리나

헷갈리기 쉬운 지점입니다. 둘 다 "말하면 화면이 나오는" 도구로 보이니까요.

기준을 하나로 정리하면 결과물이 어디에 남아야 하는가입니다.

아이디어를 빨리 보여주고 버릴 거라면, 그리고 그 결과물이 다시 캔버스로 돌아갈 거라면 Figma 계열 도구가 자연스럽습니다. 반대로 결과물이 진짜 제품 저장소에 남아야 하고, 기존 컴포넌트를 써야 하고, 나중에 개발자가 이어받아야 한다면 Claude Code 쪽이 맞습니다.

한 줄로 줄이면, 버릴 프로토타입과 남길 프로토타입은 다른 도구로 만드는 게 낫습니다.

가장 잘 돌아가는 왕복 네 단계

1. Figma에서 의도를 정리합니다. 사용자, 과업, 품질 기준, 지켜야 할 토큰을 먼저 둡니다.
2. Claude Code에서 작동시킵니다. 핵심 화면과 함께 정상·오류·빈·모바일 상태를 같이 구현합니다.
3. Figma에서 비교하고 편집합니다. 실제로 움직인 화면을 보며 흐름, 카피, 위계, 톤을 다시 판단합니다.
4. 코드에서 검증합니다. 수정안을 반영한 뒤 브라우저 동작과 접근성을 점검합니다.

순서보다 중요한 건 2번과 3번 사이를 건너뛰지 않는 것입니다. 작동하는 화면을 보고 바로 또 코드를 고치기 시작하면, 그때부터는 어느새 구현 작업이 되고 설계 판단은 생략됩니다.

파일이 준비되지 않으면 전제가 깨집니다

이 왕복은 Figma 파일이 읽힐 때만 성립합니다. 네 가지가 안 돼 있으면 결과 품질이 눈에 띄게 떨어집니다.

• Auto Layout이 적용돼 있을 것
• 레이어 이름이 의미를 가질 것
• 계층이 깊지 않을 것
• 색과 간격이 토큰으로 정의돼 있을 것

재미있는 건 이 네 가지가 사람이 유지보수하기 좋은 파일의 조건과 거의 같다는 점입니다. 지금까지 "나중에 정리하지"로 미뤄둔 부채가 AI를 붙이는 순간 청구서로 돌아옵니다.

두 도구 사이에서 끊기는 것

이걸 모르면 계속 헛수고를 합니다. Figma에서 코드 쪽으로 넘어가지 않는 데이터가 있습니다.

이미지의 실제 픽셀은 읽히지 않습니다. 사진과 일러스트는 따로 내보내야 합니다. 프로토타입 연결선으로 짜놓은 화면 전환도 안 넘어갑니다. 코멘트와 버전 히스토리도 마찬가지입니다.

마지막 둘이 의외로 아프게 작용합니다. 코멘트와 버전 히스토리에는 왜 이렇게 됐는지가 들어 있습니다. 그게 안 넘어가니, 제약과 배경은 매번 말로 다시 써줘야 합니다. 파일만 가리키고 "이거 만들어줘"라고 하면 맥락 없는 번역본이 나옵니다.

실전적인 대응은 하나입니다. 캔버스에 적어둔 규칙을 저장소 안에 평문으로도 남기는 겁니다. 사람은 프레임을 보고 에이전트는 문서를 읽게 됩니다.

반론: 결국 캔버스는 사라지는 게 아닌가

나올 만한 질문입니다. 코드가 진짜 결과물이고 시안은 중간산물이니, 중간산물을 없애는 게 효율적이라는 논리죠.

가능성을 부정하지는 않겠습니다. 실제로 단순한 화면은 이미 시안 단계를 건너뛰고 있고, 회사의 43%가 작동하는 프로토타입을 산출물로 기대합니다.

다만 한 가지가 아직 대체되지 않았습니다. 아직 정해지지 않은 것을 여러 명이 같이 보는 일입니다. 코드는 정해진 것을 정확히 표현하는 데 강하지, 세 가지 방향을 나란히 놓고 "이중 어느 걸 약속할까"를 논의하는 데는 약합니다. 누군가는 브랜치 세 개를 띄우면 된다고 하겠지만, 그건 디자이너 한 명의 작업방식이지 팀의 의사결정 방식이 아닙니다.

또 하나. 협업 지표가 실제로 나쁩니다. AI 때문에 협업이 줄었다는 응답은 2025년 5%에서 2026년 20%로 늘었습니다. 각자 빨리 만들어서 각자 끝내면 생산성은 오르고 기준은 분해됩니다. 캔버스를 남겨두는 건 그 분해를 늦추는 장치이기도 합니다.

디자인 시스템의 정본은 어느 쪽에 두나

두 도구를 같이 쓰는 팀에서 가장 자주 분쟁이 나는 지점입니다. 색과 간격의 정본이 Figma 변수인지 저장소의 토큰 파일인지 정해두지 않으면 두 곳이 조용히 어긋납니다. 처음엔 몇 픽셀 차이라 아무도 눈치채지 못하다가, 어느 날 같은 버튼이 화면마다 다르게 보입니다.

그나마 굴러가는 규칙은 방향을 하나로 고정하는 겁니다. 정본은 한쪽에만 두고 나머지는 생성물로 취급합니다. 디자이너가 값을 자주 만지는 팀이면 Figma가 정본이고 코드가 따라갑니다. 엔지니어가 많고 배포가 잦은 팀이면 반대가 낫습니다. 정답이 있는 게 아니라 정해두는 것 자체가 핵심입니다.

어느 쪽이든 양방향 동기화는 피하는 게 좋습니다. 충돌이 나면 사람이 매번 중재해야 하는데, 그 중재를 자기 일이라고 생각하는 사람이 팀에 아무도 없습니다. 결국 아무도 안 고치고 양쪽 다 조금씩 틀린 상태로 남습니다.

AI를 붙이는 순간 이 문제가 몇 배로 커집니다. 에이전트는 무엇이 정본인지 모릅니다. 눈앞에 있는 값을 씁니다. 토큰이 두 벌이면 두 벌 다 씁니다. 그래서 도구를 도입하기 전에 정본부터 정하는 게 순서상 맞습니다. 반대로 하면 어긋난 값이 자동으로 복제되는 속도만 빨라집니다.

핸드오프가 사라지면 리뷰는 어디서 하나

디자이너가 작동하는 화면까지 직접 만들면 "디자인 완료 다음 개발 시작"이라는 경계가 흐려집니다. 대체로 좋은 일인데 부작용이 하나 있습니다. 리뷰 시점이 같이 사라집니다.

예전에는 핸드오프가 강제 체크포인트 역할을 했습니다. 넘기기 전에 한 번은 다 같이 봤습니다. 누가 시켜서가 아니라 넘기려면 설명해야 했으니까요. 그 관문이 없어지면 아무도 제대로 안 본 화면이 그대로 배포되는 일이 생깁니다.

그래서 경계를 없앤 팀일수록 체크포인트를 명시적으로 다시 만들어야 합니다. 프로토타입이 나온 다음 누가 무엇을 언제 보는지 적어두는 식으로요. 도구가 없앤 마찰을 규칙으로 되살리는 셈인데, 번거로워 보여도 결국 이게 빠릅니다.

팀 규모에 따라 답이 달라집니다

혼자 만든다면 캔버스를 건너뛰어도 됩니다. 머릿속에 다 있으니까요. 실제로 1인 개발자들은 Figma를 거의 열지 않고 바로 코드로 갑니다. 게으른 게 아니라 합리적인 선택입니다.

서너 명이 되면 캔버스가 다시 필요해집니다. 말로 맞추던 것이 안 맞기 시작하는 구간입니다. 회의에서 "그거 그렇게 하기로 했잖아요"가 늘어나면 신호로 보면 됩니다.

열 명이 넘어가면 캔버스보다 문서가 중요해집니다. 프레임은 결정을 보여주지만 이유를 담지 못합니다. 이 규모에서 Figma만 믿으면 6개월 뒤에 아무도 왜 이렇게 됐는지 설명하지 못합니다. 그때 남아 있는 건 화면뿐이고, 화면은 자기가 왜 그런지 말해주지 않습니다.

경계에서 자주 막히는 세 가지

첫째, 프로토타입을 버릴 것인가 남길 것인가. 버릴 거라면 품질에 신경 쓰지 말아야 하고, 남길 거라면 처음부터 저장소 규칙을 지켜야 합니다. 애매하게 두면 버리기도 아깝고 쓰기도 위험한 코드가 쌓입니다. 시작할 때 한 문장으로 정해두면 됩니다.

둘째, 토큰을 누가 바꾸나. 디자이너가 코드에서 값을 직접 고칠 수 있게 할지 정해야 합니다. 열어두면 빠르고 막아두면 안전합니다. 정하지 않으면 매번 서로 눈치를 보다가 결국 슬랙으로 부탁하게 되는데, 그게 제일 느립니다.

셋째, 어디까지가 탐색이고 어디부터가 구현인가. 작동하는 화면이 나오는 순간 팀은 그걸 결정으로 받아들입니다. 아직 방향을 보는 중이라면 그렇다고 이름을 붙여둬야 오해가 없습니다. "이건 아직 실험입니다" 한 줄이 회의 한 번을 아낍니다.

도구를 고르기 전에 정할 것

정리하고 보면 이 글의 질문 대부분이 도구 질문이 아닙니다. 정본을 어디 둘지, 언제 다 같이 볼지, 무엇을 남길지에 대한 합의 문제입니다. 합의가 없으면 어떤 조합을 써도 같은 자리에서 막힙니다.

거꾸로 이 셋만 정해두면 도구는 꽤 자유롭게 바꿔도 됩니다. 내년에 더 나은 게 나와도 갈아끼우면 그만입니다. 팀이 무너지는 건 도구가 바뀔 때가 아니라 기준이 없을 때입니다.

그래서 도입을 검토 중이라면 시연 영상을 더 보는 것보다 이 세 문장을 먼저 써보는 편이 낫습니다. 우리 팀의 정본은 여기다, 리뷰는 여기서 한다, 프로토타입은 남긴다 혹은 버린다.

경계를 정하는 두 문장

정리하면 이렇습니다.

Figma에 맡기지 말아야 할 것은 실제 동작을 보지 않은 확신입니다. 시안에서 완벽해 보이는 화면이 3초짜리 로딩과 긴 이름 앞에서 무너지는 일은 흔합니다.

Claude Code에 맡기지 말아야 할 것은 사용자 가치와 최종 미감에 대한 책임입니다. 도구가 내는 건 평균적으로 준수한 결과고, 평균은 정의상 남들과 같습니다.

이 경계가 분명할수록 둘은 더 잘 맞물립니다. 각 단계에서 실제로 무엇을 요청할지는 Claude Code로 UI를 개선하는 워크플로우에 프롬프트까지 적어두었습니다.