figma-mcp

7 개의 포스트

figma

올바른 방향으로 빠르게 나아가는 방법 | Figma 블로그 (새 탭에서 열림)

AI는 소프트웨어 제작 속도를 크게 높였지만, 빠른 실행이 곧 올바른 제품을 의미하지는 않는다. AI가 만든 결과물을 그대로 받아들이면 기술 부채가 늘고, 평균적인 디자인과 기능에 머물 수 있다. 따라서 좋은 팀은 먼저 무엇을 만들지 충분히 고민하고, 명확한 맥락과 시스템을 제공한 뒤, 자신만의 관점으로 결과물을 다듬어야 한다. ## AI는 실행을 가속하지만 판단을 대신하지 못한다 - AI는 짧은 프롬프트만으로도 완성도 높아 보이는 프로토타입과 코드를 만들어낸다. - 그러나 겉보기의 완성도는 내부 구조, 제약 조건, 시스템 동작 방식까지 올바르다는 뜻이 아니다. - 과거에는 결과물의 세련됨 뒤에 전문가의 의사결정과 트레이드오프가 있었지만, 이제는 AI가 그 빈틈을 임의로 채울 수 있다. - **인지적 항복(cognitive surrender)**은 AI의 출력을 검토 없이 자신의 판단처럼 받아들이는 현상이다. - 첫 번째 결과물이 그럴듯하다는 이유로 바로 출시하지 말고, 문제의 본질과 실제로 만들 가치가 있는 것을 먼저 정의해야 한다. 글에서는 이를 **고려의 의무(consideration imperative)**로 표현한다. ## 맥락과 의도를 먼저 제공해야 한다 - 에이전틱 엔지니어링에서는 개발자의 역할이 코드를 직접 작성하는 것에서 **의도를 명확히 표현하고 검증하는 것**으로 이동한다. - Google의 관련 백서는 다음 요소를 중요한 기반으로 제시한다. - **결정론적 계층**: 테스트, 타입 검사, 검증처럼 매번 동일하게 실행되며 AI의 오류를 잡는 장치 - **고신호 맥락**: 명세, 문서화된 컴포넌트, 설계 원칙 등 에이전트가 의도를 정확히 이해하도록 돕는 정보 - **명확한 인터페이스**: 시스템 각 부분이 어떻게 연결되는지 에이전트가 추측하지 않도록 정의한 계약 - 디자인에서 코드로 전환할 때도 에이전트가 실제 프로덕션 컴포넌트의 구조를 모르면 픽셀을 보고 임의로 재구성할 가능성이 높다. - Figma MCP의 Code Connect처럼 실제 컴포넌트의 코드, props, variants를 제공하면 에이전트가 기존 시스템에 맞는 결과를 만들 수 있다. - 강력한 디자인 시스템은 결정 사항을 재사용 가능한 어휘와 가드레일로 codify해 결과물의 일관성을 높이고 코드와 기술 부채를 줄인다. - 초기에는 명세와 시스템을 준비하는 데 더 많은 시간이 들지만, 장기적으로 유지보수 비용을 낮춘다. ## “괜찮은 결과”는 쉽게 평균이 된다 - AI 모델은 방대한 기존 데이터를 학습했기 때문에 이미 널리 사용된 패턴과 스타일, 즉 **분포 안의 평균적인 결과**를 생성하는 경향이 있다. - 예를 들면 다음과 같은 결과가 반복될 수 있다. - 로고: 단순한 기하학적 형태와 그라디언트 - 발표 자료: 흔한 산세리프 글꼴과 익숙한 레이아웃 - React 컴포넌트: 둥근 모서리의 전형적인 카드 UI - 이런 결과는 틀리지는 않지만 차별성이 부족하다. - AI가 만든 “충분히 좋은” 결과를 반복해서 받아들이면 사용자의 판단 기준이 좁아지고, “무엇이어야 하는가?”보다 “덜 나쁜 선택은 무엇인가?”를 고르게 된다. - AI의 품질이 향상될수록 개인이 과거보다 나은 결과를 만들 수 있지만, 동시에 다른 AI 생성물과 비슷해질 위험도 커진다. ## 제품의 관점은 사람이 결정해야 한다 - AI는 실행과 변형을 빠르게 수행할 수 있지만, 제품의 목적과 차별화된 방향까지 자동으로 결정하게 두어서는 안 된다. - 명확한 의도와 평가 기준이 없으면 모델이 기본값과 평균적인 패턴을 대신 선택한다. - 팀은 AI가 제시한 결과를 출발점으로 활용하되, 왜 이 기능과 디자인이 필요한지, 누구를 위한 것인지, 무엇이 달라야 하는지를 직접 판단해야 한다. - 결국 속도의 핵심은 첫 결과물을 빨리 내는 것이 아니라, 명확한 맥락과 검증 장치를 통해 **올바른 방향으로 빠르게 반복하는 것**이다. AI를 활용할 때는 프롬프트 작성보다 먼저 목표, 제약 조건, 성공 기준을 문서화하는 것이 좋다. 테스트·타입 검사·디자인 시스템·명확한 인터페이스를 갖추고, AI 결과물을 반드시 사람의 관점과 제품 기준으로 검토해야 평균적인 결과와 기술 부채를 피할 수 있다.

figma

더 나은 코드, 더 적은 토큰: MCP에서 Code Connect의 이점 | Figma 블로그 (새 탭에서 열림)

코딩 에이전트가 디자인을 코드로 변환할 때 Code Connect를 사용하면 실제 프로덕션 컴포넌트와 디자인 시스템을 더 정확히 활용할 수 있다. Figma MCP와 Code Connect를 함께 사용한 실험에서 작업 시간은 19.6%, 토큰 사용량은 29.5% 감소했고, 코드 품질은 1~4점 척도에서 1점 향상됐다. 즉, 시각적으로 비슷한 코드를 새로 만드는 대신 기존 컴포넌트를 직접 연결하면 더 빠르고 일관된 결과를 얻을 수 있다. ## 코딩 에이전트가 디자인 시스템을 잘못 구현하는 이유 - Figma MCP의 `get_design_context`는 캔버스의 디자인을 React 코드 형태로 설명한다. - Code Connect가 없으면 에이전트는 다음과 같은 문제를 겪을 수 있다. - 기존 컴포넌트 대신 새로운 컴포넌트를 직접 생성한다. - 디자인 시스템에서 잘못된 컴포넌트를 선택한다. - 올바른 컴포넌트를 찾더라도 검색과 수정에 불필요한 토큰과 시간을 사용한다. - 결과물은 시각적으로는 맞아 보여도 프로젝트의 실제 코드 구조나 디자인 시스템 규칙과 어긋날 수 있다. ## Code Connect가 MCP 응답을 보강하는 방식 - Code Connect는 Figma 컴포넌트와 코드베이스의 실제 컴포넌트를 연결한다. - 설정이 완료되면 MCP 응답에 일반적인 React 표현 대신 프로덕션 코드에 가까운 코드 스니펫이 포함된다. - 에이전트는 다음 정보를 직접 전달받는다. - 사용해야 할 컴포넌트의 import 경로 - 컴포넌트에 전달할 정확한 속성값 - 디자인 요소와 코드 컴포넌트 간의 대응 관계 - 예를 들어 Code Connect가 없으면 탭 UI를 여러 `<button>` 요소와 CSS 클래스로 재구성할 수 있다. - Code Connect를 사용하면 다음처럼 기존 디자인 시스템 컴포넌트를 바로 사용한다. ```tsx <SegmentedControl value="design" options={["Design", "Code"]} /> ``` ## Coinbase 사례 - Coinbase Design Systems 팀은 일관된 UI를 위해 핵심 컴포넌트, 디자인 토큰, 인프라를 관리한다. - 에이전트 기반 개발을 도입하면서 Code Connect를 적용해 에이전트가 CDS 컴포넌트를 재사용하도록 했다. - Code Connect가 없을 때는 에이전트가 스테퍼를 프로그레스 바 조합으로 임의 구현하는 등 컴포넌트를 잘못 추측할 수 있었다. - Code Connect를 사용하면 정확한 코드 표현과 실제 CDS 컴포넌트의 import 문을 확인할 수 있어 코드 품질이 향상되고 토큰도 절약됐다. ## Code Connect의 효과를 측정한 실험 - 동일한 디자인, 프롬프트, 모델을 사용해 Code Connect 적용 여부만 달리한 디자인-투-코드 작업을 비교했다. - 총 27개 테스트 케이스에서 다음 항목을 측정했다. - 코드 품질 - 토큰 사용량 - 작업 소요 시간 - React 기반 디자인 시스템 두 가지를 대상으로 했다. - Figma의 예제 디자인 시스템인 Simple Design System(SDS) - 더 규모가 크고 복잡한 내부 시스템인 Figma Pattern Library(FPL) - Code Connect 적용 결과: - 작업 시간 중앙값 19.6% 감소 - 토큰 사용량 중앙값 29.5% 감소 - 코드 품질 1~4점 Likert 척도에서 1점 향상 ## 실용적인 적용 방향 - 디자인 시스템의 핵심 컴포넌트에 Code Connect 템플릿을 우선 설정하는 것이 효과적이다. - 에이전트가 직접 HTML과 스타일을 조합하게 하기보다 실제 컴포넌트와 import 정보를 제공해야 한다. - 디자인 시스템을 사용하는 팀이라면 Code Connect를 단순한 인간 개발자용 문서화 도구가 아니라 에이전트의 코드 생성 품질과 비용을 개선하는 컨텍스트 계층으로 활용할 수 있다.

figma

Decagon이 AI를 활용해 디자인 시스템을 포화시키는 방법 | Figma 블로그 (새 탭에서 열림)

Decagon은 빠르게 성장하는 AI 고객지원 플랫폼의 품질과 개발 속도를 함께 확보하기 위해 Deco라는 디자인 시스템을 구축했다. Figma 라이브러리, Storybook, 코딩 에이전트, Figma MCP를 연결해 디자인과 코드가 지속적으로 일치하도록 만들었고, 그 결과 반복적인 해석과 수정 작업을 줄였다. 핵심은 디자인 시스템을 단순한 컴포넌트 모음이 아니라 사람과 AI 에이전트가 함께 사용하는 공통 언어로 만든 데 있다. ## 빠른 성장에 대응하는 디자인 시스템 구축 - Decagon은 초기에는 디자인 시스템 없이 빠르게 제품을 개발했지만, 플랫폼과 팀이 커지면서 화면 간 불일치와 완성도 저하가 나타났다. - 기업 고객을 대상으로 제품을 제공하기 위해서는 일관된 UI와 높은 품질이 필요했으며, 디자인과 개발 사이의 반복적인 수정 작업도 줄여야 했다. - 디자이너와 엔지니어가 처음부터 함께 Deco를 설계해 다음과 같은 세부 사항을 미리 정의했다. - 포커스 상태 - 비활성화, 읽기 전용, 오류, 경고 상태 - 플레이스홀더 사용 여부 - 기존 코드에 이미 존재하는 컴포넌트와의 관계 - 현재 Deco는 수백 개의 컴포넌트·스타일·변수를 포함하며, 여러 팀과 제품 영역의 대부분의 사용 사례를 다룬다. - Figma 라이브러리에서 30일 동안 수만 건의 컴포넌트 삽입이 발생해 조직 전반에서 실제로 활용되고 있음을 확인했다. ## 디자인 시스템이 만든 공통 언어 - 디자이너는 기존 컴포넌트로 화면을 조합할 수 있어 매번 UI를 처음부터 만들 필요가 없어졌다. - 개발자는 어떤 버튼이나 테이블을 사용해야 하는지 명확히 알 수 있어 구현상의 판단과 논쟁이 줄었다. - 디자인과 코드가 동일한 프리미티브를 기준으로 소통하면서 제품 흐름과 요구사항을 설명하기 쉬워졌다. - Deco는 조직 전체에 공개된 단일 진실 공급원(single source of truth)으로 작동해 빠른 출시와 일관된 디자인을 동시에 지원한다. ## 디자인과 코드 사이의 반복 작업 줄이기 - 기존 방식에서는 디자이너가 명세를 전달하면 개발자가 해석하고, 리뷰 단계에서 불일치를 발견한 뒤 다시 수정하는 과정이 반복됐다. - 코딩 에이전트는 개발자처럼 암묵적인 의도를 추론하지 않고 제공된 정보만 바탕으로 작업하므로, 디자인 파일과 명세가 불명확하거나 일관되지 않으면 결과물도 부정확해진다. - Decagon은 디자인 시스템 컴포넌트를 Storybook으로 옮겨 코드에서도 동일한 컴포넌트를 확인할 수 있게 했다. - 코딩 에이전트가 구현할 때 정확한 Deco 컴포넌트를 사용하도록 별도의 skill을 만들었다. - 디자이너가 새로운 컴포넌트를 추가할 때 사용하는 skill도 구축해 Figma와 코드의 동기화를 유지했다. ## Figma MCP를 통한 에이전트 활용 - Figma MCP를 사용하면 코딩 에이전트가 Figma의 디자인 문맥과 명세를 직접 읽을 수 있다. - 디자이너는 Figma 링크를 코딩 에이전트에 전달하는 것만으로 다음 작업을 수행할 수 있다. - 디자인의 구조와 세부 명세 파악 - Deco의 적합한 컴포넌트와 매핑 - 디자인에 가까운 고충실도 구현 생성 - 디자인 캔버스, 코드, 컴포넌트 명세가 하나의 작업 흐름으로 연결되어 파일을 내보내고 다시 해석하는 수동 왕복이 줄었다. - 에이전트가 기존 디자인 시스템을 활용하므로 빠른 프로토타이핑과 반복 수정이 가능하면서도 브랜드와 UI 일관성을 유지할 수 있다. ## 실용적인 결론 AI 코딩 도구를 도입할 때는 에이전트의 성능만 높이기보다, 먼저 재사용 가능한 디자인 시스템과 명확한 컴포넌트 문맥을 마련해야 한다. Figma와 Storybook을 연결하고, MCP와 에이전트 skill을 통해 동일한 컴포넌트를 사용하게 하면 디자인-개발 간 불일치를 줄이면서 빠른 개발 속도와 품질을 함께 확보할 수 있다.

figma

워크플로우 랩: Figma MCP로 캔버스 확장하기 | 피그마 블로그 (새 탭에서 열림)

빠르게 코드를 작성하는 팀에서는 구현 과정에서 새로운 상태와 예외가 생기며 디자인과 실제 제품 사이의 간극이 커질 수 있다. 이 글은 Figma MCP를 사용해 코드에만 존재하던 제품 상태를 Figma 캔버스로 가져오고, 디자이너가 이를 직접 검토·수정하는 워크플로를 소개한다. 결과적으로 캔버스가 초기 화면을 넘어 실제 제품 전체의 상태와 구현 결과를 다루는 공간으로 확장된다. ## 빠른 개발이 만드는 디자인 사각지대 - Astra라는 가상의 AI 영상 제작 플랫폼은 에이전트 코딩 도구를 활용해 매주 기능을 출시한다. - 초기 영상 내보내기 플로우는 다음 네 단계로 시작한다. - 시퀀스 선택 - 포맷 선택 - 설정 확인 - 영상 내보내기 - 실제 코드와 데이터에 연결되면서 다음과 같은 상태가 추가된다. - 인코딩 오류 - 렌더링 진행 중 상태 - 선택 항목이 없는 상태 - 지원하지 않는 포맷 - 이러한 상태는 디자이너가 초기 설계에서 누락한 것이 아니라, 기능이 실제 구현되는 과정에서 새롭게 드러난 디자인 결정 사항이다. - 캔버스가 초기 플로우만 담고 있으면 디자이너 역시 제품의 일부만 보고 작업하게 된다. ## Figma MCP로 캔버스 확장 - Figma MCP를 통해 에이전트가 코드를 읽고 Figma 캔버스에 결과를 작성할 수 있다. - 에이전트는 구현된 내보내기 플로우를 분석해 개발자가 처리한 모든 상태를 식별한다. - 각 상태를 Figma의 편집 가능한 프레임으로 생성하고, Astra의 디자인 시스템 컴포넌트를 적용한다. - 초기에는 4개였던 프레임이 구현된 전체 상태를 반영하며 14개로 늘어난다. - 사용된 주요 도구는 다음과 같다. - Figma Design - Dev Mode - Figma MCP server - `use_figma` - `generate_figma_design` - `/sync-figma-token` 스킬 ## 코드에 드러난 상태를 디자인으로 발전시키기 - 인코딩 오류 화면에는 단순한 빨간색 오류 메시지만 있었지만, 디자이너가 다음 내용을 추가한다. - 오류 원인 - 사용자가 시도할 수 있는 해결 방법 - 이전 단계로 돌아가는 방법 - 렌더링 중 화면에는 스피너만 있었지만, 디자이너가 진행률과 예상 소요 시간을 추가한다. - 선택 항목이 없는 화면은 비어 있었지만, 기능 사용을 유도할 수 있는 안내 문구와 개성을 부여한다. - 이 방식은 작업 티켓이나 요구사항 문서 중심의 피드백보다, 코드와 디자인이 캔버스에서 직접 대화하는 형태에 가깝다. - 구현 후 발견된 예외 상태를 별도의 긴 탐색 세션을 거치지 않고 바로 디자인 대상으로 전환할 수 있다. ## 디자인과 구현 결과 비교 - Figma 캔버스에서 원본 디자인과 코드로 구현된 화면을 나란히 비교할 수 있다. - 시각적 차이를 찾아내는 비교 결과에는 심각도별 불일치가 표시된다. - 예시로 다음과 같은 차이가 발견된다. - 모달 제목 크기 차이 - 구현본에만 추가된 “Post share link” 버튼 - 설정 패널의 배경 또는 표면 스타일 제거 - 설정 헤더의 시각적 우선순위 하락 - 이를 통해 디자인 검토가 “의도한 화면이 구현되었는가”뿐 아니라, 실제 구현 과정에서 추가·변경된 요소까지 포함하도록 확장된다. ## 실용적인 결론 Figma MCP는 코드를 디자인으로 자동 변환하는 도구라기보다, 구현 중 발생한 모든 제품 상태를 디자인 의사결정의 영역으로 되돌리는 연결 장치다. 빠르게 개발하는 팀이라면 에이전트로 코드의 상태를 캔버스에 동기화한 뒤, 디자이너가 오류·로딩·빈 상태·시각적 불일치를 직접 검토하는 절차를 구축하는 것이 유용하다.

figma

Figmates가 Figma AI를 활용해 즐거움의 차원을 한 단계 높인 방법 | Figma 블로그 (새 탭에서 열림)

Figma 팀은 연례 April Fun Day를 위해 Figma Make, Weave, MCP를 활용해 며칠 만에 여섯 개의 미니게임을 제작하고 캔버스에 일주일간 공개했다. 이 과정에서 AI는 아이디어를 빠르게 프로토타이핑하고 시각 요소를 확장하며, 디자인과 코드 사이의 협업을 가속하는 역할을 했다. 글의 결론은 적절한 AI 도구를 사용하면 디자이너와 개발자 모두가 제작 과정에 참여하면서 더 빠르게 실험하고 완성도 높은 결과물을 만들 수 있다는 것이다. ## 놀이를 실험의 장으로 활용한 April Fun Day - Figma의 April Fun Day는 매년 커뮤니티를 위한 이스터 에그와 새로운 경험을 선보이는 행사다. - 올해는 기존의 추억을 불러일으키는 콘텐츠를 넘어, 캔버스 안에서 직접 즐길 수 있는 미니게임 플랫폼 **FigCade**를 제작했다. - 팀은 평소 업무 영역을 벗어나 새로운 도구와 제작 방식을 시험하는 기회로 행사를 활용했다. - FigCade는 단 며칠 만에 완성됐으며, 일주일 동안 사용자에게 제공됐다. ## 빠른 프로토타이핑과 반복 - **Figma Make**를 사용해 아이디어를 즉시 작동하는 프로토타입으로 만들었다. - 예를 들어 `2Fast2Figma` 퀴즈의 초기 아이디어는 일요일 아침에 시작해 그날 오후 작동하는 프로토타입이 됐다. - 아이디어 수만큼 다양한 프로토타입을 만든 뒤, 빠르게 공유하고 반응을 확인하며 방향을 조정했다. - 제작 과정의 기본 원칙은 “먼저 보여주고, 반응하고, 정렬한 뒤, 반복한다”는 방식이었다. - `2Fast2Figma`에서는 사용자가 30초 동안 Figma 관련 질문에 최대한 많이 답하도록 구성했다. ## Figma Weave를 활용한 시각적 탐색 - **Figma Weave**는 게임의 시각적 스타일과 질감 요소를 빠르게 탐색하는 데 사용됐다. - 디자이너 Lesley Moon은 펠트 느낌의 커서 등 FigCade의 질감 있는 그래픽 요소를 몇 시간 만에 제작했다. - AI로 펠트 소재 에셋을 대량 생성하면서 시도할 수 있는 시각적 테마와 질감의 범위가 넓어졌다. - 생성 결과물을 그대로 사용하는 데 그치지 않고, 이를 기반으로 추가 제작과 수정 작업을 이어갔다. ## 하루 만에 제작한 홍보 영상 - Weave는 FigCade의 April Fun Day 트레일러 제작에도 활용됐다. - 제품 관리자 Tara Nadella가 Weave에서 영상 콘셉트를 구상하고 필요한 요소를 생성했다. - 모션 디자이너 Fifi Law는 이를 Lesley의 시각 자료와 결합해 최종 영상을 제작했다. - 스토리보드에 필요한 요소를 빠르게 생성할 수 있었고, 트레일러 전체를 하루 만에 만들었다. ## Figma MCP로 디자인과 코드를 연결 - **Figma MCP 서버**는 디자인 탐색 결과를 실제 코드로 구현하는 데 사용됐다. - 개발자는 Claude와 GitHub Copilot을 Figma MCP에 인증한 뒤, 특정 디자인 컴포넌트 링크를 에이전트에 전달했다. - 에이전트는 해당 디자인 사양을 참고해 UI 변경에 필요한 코드를 생성했다. - 이를 통해 개발자는 디자인 맥락을 직접 확인하면서 시각적 요구사항에 맞는 코드를 작성할 수 있었다. - 프로젝트 전반에서 팀은 디자인과 코드 사이를 반복적으로 오가며 구현 결과를 조정했다. ## 실용적인 결론 - 아이디어 단계에서는 Figma Make로 빠르게 여러 프로토타입을 만들고, 사용자 반응을 기준으로 선별하는 방식이 효과적이다. - 시각적 에셋과 영상은 Figma Weave로 다양한 방향을 먼저 탐색한 뒤 사람이 다듬는 것이 적합하다. - Figma MCP는 디자인 컴포넌트와 코드의 연결을 강화하므로, UI 중심 개발에서 특히 유용하다. - AI를 완성품 자동 생성 도구보다 **빠른 탐색과 협업을 돕는 도구**로 활용할 때 가장 큰 효과를 얻을 수 있다.

figma

고정관념에서 벗어나 생각 (새 탭에서 열림)

Claude와 FigJam의 연동으로 텍스트 프롬프트, PRD, PDF, 이미지, 스크린샷, 코드 파일을 편집 가능한 FigJam 다이어그램으로 변환할 수 있다. 이를 통해 AI와의 대화에서 나온 아이디어를 팀이 함께 검토·수정하는 시각적 협업 공간으로 빠르게 옮길 수 있다. Figma는 이 기능이 기획, 디자인, 개발 간의 소통을 줄이고 아이디어를 실행으로 연결하는 데 도움을 준다고 설명한다. ## 대화에서 편집 가능한 다이어그램으로 - Claude의 Figma MCP 앱을 사용하면 작성한 프롬프트나 업로드한 자료를 FigJam 다이어그램으로 만들 수 있다. - PRD를 기반으로 사용자 플로우를 생성해 제품의 전체 여정, 마찰 지점, 예외 상황을 빠르게 파악할 수 있다. - 생성된 결과물은 단순한 이미지가 아니라 FigJam에서 편집 가능한 형태이므로 팀원이 직접 수정하고 확장할 수 있다. - 대화 내용을 복사해 다른 도구로 옮기는 과정과 애플리케이션 간 컨텍스트 전환을 줄인다. ## 시각화로 팀의 사고를 공유 - 다이어그램은 복잡하거나 추상적인 아이디어를 이해하기 쉬운 흐름으로 바꿔 팀의 공통 언어 역할을 한다. - 디자이너는 사용자 여정과 경험 흐름을 시각화할 수 있다. - 제품 관리자는 Gantt 차트로 일정, 의존성, 마일스톤을 정리할 수 있다. - 기획 초기 단계에서 AI가 만든 초안을 바탕으로 문제를 조기에 발견하고 업무 순서를 조정할 수 있다. - FigJam의 공유 캔버스에서 팀원들이 댓글과 반응을 남기며 아이디어를 함께 발전시킬 수 있다. ## 개발 문서와 시스템 구조 시각화 - 엔지니어는 서비스, API, 데이터베이스, 요청·응답 흐름, 의존성을 포함한 시스템 아키텍처를 다이어그램으로 표현할 수 있다. - 기존 기술 문서나 업로드한 코드 파일을 바탕으로 초기 구조를 생성할 수 있다. - 여러 시스템의 패턴을 비교하거나 프런트엔드와 백엔드 간의 공통 맥락을 정리하는 데 활용할 수 있다. - 구현 전에 복잡성과 잠재적 위험을 검토해 개발 과정의 오류를 줄이는 데 도움이 된다. - Claude는 데이터베이스 구조에 적합한 차트 유형과 색상 코드도 제안할 수 있다. ## FigJam을 중심으로 이어지는 작업 흐름 - Claude에서 만든 아이디어를 FigJam으로 옮긴 뒤, Figma Design에서 다듬고 Figma Slides에서 공유할 수 있다. - 필요하면 최종 결과를 코드 구현으로 연결해 아이디어에서 실행까지의 흐름을 이어갈 수 있다. - FigJam은 초기 브레인스토밍뿐 아니라 프로젝트 계획, 시스템 설계, 협업 문서화의 공간으로 활용된다. - Figma는 더 다양한 도형 모음과 커넥터 유형을 추가해 정교한 다이어그램 작성 기능도 개선하고 있다. - Anthropic은 Claude용 MCP 앱을 설계할 수 있는 UI 키트도 제공한다. ## AI가 일회성 도구에서 협업 파트너로 - Claude는 여러 차례의 대화 맥락을 유지하면서 사용자 여정, 우선순위 절충안, 구현 구조를 점진적으로 개선할 수 있다. - 하나의 답만 제시하는 대신 의사결정 트리, Gantt 차트, 시퀀스 다이어그램, 상태 다이어그램 등 목적에 맞는 표현 방식을 제안할 수 있다. - FigJam에 저장된 다이어그램은 팀의 초기 사고 과정과 의사결정을 남기는 공유 자산이 된다. - MCP를 활용하면 시스템 컨텍스트를 다이어그램에 반영해 복잡한 시스템을 함께 이해하는 방식으로 발전할 수 있다. 실무에서는 PRD나 기술 문서를 Claude에 제공해 초안을 만든 뒤, FigJam에서 팀원과 구조·누락·우선순위를 검토하는 방식이 효과적이다. 단, AI가 생성한 흐름과 아키텍처는 초안이므로 실제 요구사항과 시스템 제약을 담당자가 반드시 검증해야 한다.

figma

ChatGPT 브레인스토밍을 (새 탭에서 열림)

ChatGPT의 새로운 Figma 앱은 대화 중 나온 아이디어와 첨부 파일을 분석해 FigJam 다이어그램으로 변환해준다. 손그림, PDF, PRD, 기술 문서 등을 바탕으로 플로차트·시퀀스 다이어그램·상태 다이어그램·간트 차트 등을 만들고 수정할 수 있어, 개인 브레인스토밍을 팀 협업용 산출물로 빠르게 발전시키는 것이 핵심이다. 이 기능은 Figma MCP 서버를 기반으로 하며, 글 작성 시점에는 EU 외 지역의 로그인한 ChatGPT 사용자에게 제공된다. ## ChatGPT 브레인스토밍을 FigJam으로 변환 - ChatGPT 대화 내용을 바탕으로 적절한 FigJam 다이어그램을 추천하고 자동 생성한다. - 사용자는 프롬프트에 Figma 앱을 직접 언급할 수 있다. - 예: “Figma, 이 스케치로 다이어그램을 만들어줘.” - 사진, 손그림, PDF 등의 파일을 업로드해 다이어그램 생성에 참고시킬 수 있다. - 현재 지원되는 다이어그램 유형은 다음과 같다. - 텍스트 기반 플로차트 - 시퀀스 다이어그램 - 상태 다이어그램 - 간트 차트 - 생성된 결과는 FigJam에서 팀원들과 공유하고 반복적으로 수정할 수 있다. ## 디자인 아이디어를 빠르게 발전시키기 - 냅킨이나 화이트보드에 그린 임시 스케치를 공유 가능한 FigJam 파일로 변환한다. - ChatGPT에 다이어그램 수정, 주제 확장, 다른 시각화 방식 제안을 요청할 수 있다. - 복잡한 문서와 맥락을 업로드하면 ChatGPT가 첫 번째 다이어그램 초안을 작성한다. - 디자이너는 아이디어를 손쉽게 디지털 산출물로 바꾼 뒤 팀 리뷰와 협업을 진행할 수 있다. ## 기술 아키텍처와 시스템 설계 시각화 - 기술 문서와 화면 캡처를 업로드해 소프트웨어 아키텍처 다이어그램을 생성하거나 갱신할 수 있다. - 기술 블로그와 사례 연구를 바탕으로 여러 기술 접근법을 비교하는 구조도를 만들 수 있다. - 웹페이지 스크린샷을 분석해 관련 React 컴포넌트 구조를 다이어그램으로 표현할 수도 있다. - 분산된 코드와 문서, 팀별로 나뉜 지식을 하나의 시각적 모델로 통합해 시스템 설계 논의와 기술 의사결정을 돕는다. - 생성된 다이어그램을 바탕으로 엔지니어들이 실시간으로 협업할 수 있다. ## 제품 기획과 사용자 흐름 정리 - 권한 관리처럼 여러 선택지가 있는 문제를 옵션별 다이어그램으로 만들어 장단점을 비교한다. - PRD를 업로드해 사용자 여정이나 기능 플로차트를 생성한다. - 제품·디자인·엔지니어링 요구사항을 입력해 출시 일정을 간트 차트로 구성한다. - ChatGPT에서 개인적으로 여러 아이디어를 탐색한 뒤 FigJam에서 팀과 함께 우선순위와 실행 계획을 조율할 수 있다. ## Figma MCP 서버 기반 통합 - 이 기능은 Figma MCP 서버를 기반으로 동작한다. - MCP 서버는 원격 접근을 지원하며, 사용자가 작업 중인 맥락을 Figma 작업 환경으로 연결한다. - 따라서 ChatGPT의 분석 능력과 FigJam의 멀티플레이어 협업 기능을 결합할 수 있다. - 글 작성 시점에는 로그인한 ChatGPT 사용자 중 EU 외 지역 사용자에게 제공되며, 향후 더 많은 기능과 다이어그램 유형이 추가될 예정이다. 실무에서는 먼저 ChatGPT에 원문 자료나 스케치를 제공해 초안을 만들고, FigJam에서 사실관계·구조·표현을 검토한 뒤 팀 협업 자료로 다듬는 방식이 가장 효과적이다. AI가 만든 다이어그램은 초안이므로 기술적 정확성과 일정의 현실성은 담당자가 반드시 확인해야 한다.