사용 중·공개

Figma MCP Bridge

Figma에서 선택한 요소만 구현에 필요한 정보로 정리해 AI 코드 에디터에 전달하는 도구입니다.

추가 Dev Seat 없이 Figma 선택 노드를 AI 코드 에디터로 보내는 3인 팀 OSS입니다. 아키텍처 논의와 MCP 서버 구현에 참여했고 Codex 연동 조사·설정 커밋·한영일 문서를 담당했습니다. 플러그인 본체와 브리지 전체를 단독 구현한 것은 아닙니다.

링크

팀원 모두가 사용할 수 있는 저비용 디자인 전달 도구

AI 코드 에디터를 사용해도 개발자가 Figma를 보며 색, 여백, 글자, 계층을 매번 설명해야 한다면 팀 전체의 구현 속도는 나아지지 않습니다. 모든 팀원에게 유료 Dev Seat을 제공하는 것도 현실적이지 않았습니다.

그래서 Figma에서 지금 선택한 요소를 AI 코드 에디터로 바로 전달해 누구나 같은 방식으로 사용할 수 있는 팀용 도구를 만들기로 했습니다.

디자인 전달 흐름

선택한 디자인만 코드 에디터로 전달

버튼 하나를 구현할 때도 REST API로 Figma 파일 전체를 가져오면 관련 없는 페이지와 노드까지 응답에 포함됐습니다.

모든 팀원이 추가 유료 Dev Seat 없이 사용하면서, 선택한 노드에서 구현에 필요한 정보만 받아야 했습니다. REST API의 큰 응답을 다른 경로로 그대로 재현해서는 목적을 달성할 수 없었습니다.

팀은 Desktop Plugin API에서 현재 선택 항목만 읽고 MCP 서버와 WebSocket bridge를 거쳐 구현 맥락을 반환하는 방식을 택했습니다. 저는 이 설계 논의와 서버 측 구현·클라이언트 검증에 참여했습니다.

샘플 노드 1개에서 REST 응답은 2,307줄·142KB였습니다. 공개 브리지를 Umaso·Lingding에 사용했지만 공식 Dev Seat과 시간·토큰 비교는 측정하지 않았습니다.

AI에 많은 정보를 넘기기보다 현재 작업에 필요한 맥락을 골라 전달하는 편이 결과를 더 안정적으로 만들었습니다.

MCP 요청은 stdio, WebSocket, Figma 플러그인의 여러 경계를 지납니다. 어느 구간에서 멈춰도 빈 응답이나 일반 오류만 반환하면 사용자는 설정·연결·선택 중 무엇을 고쳐야 하는지 판단할 수 없습니다.

Claude Code, Windsurf, Codex는 MCP 서버 등록 방식과 실행 환경이 다릅니다. Figma 미실행, 선택 없음, 다중 클라이언트 연결처럼 사용자가 직접 고칠 수 있는 상태도 구분해야 했습니다.

팀 구현에서는 전송 실패를 하나로 뭉개지 않고 미연결·선택 없음·다중 연결을 구분했습니다. 저는 각 클라이언트에서 실제 호출을 재현하고 Codex 설정과 확인 절차를 README에 기록했습니다.

Claude Code, Windsurf, Codex에서 실제 도구 호출을 확인하고 재현 절차를 공개 README에 남겼습니다. 연결 실패 시나리오의 자동화 테스트는 아직 추가하지 않았습니다.

연동 도구에서는 성공 응답뿐 아니라 사용자가 다음 조치를 선택할 수 있는 실패 응답도 제품의 일부라는 점을 배웠습니다.

OSS 리포지토리는 공개되어 있습니다. 팀 브리지를 3개 클라이언트에서 검증했고, 제 공개 이력에서는 Codex 설정과 다국어 문서 커밋을 확인할 수 있습니다. Umaso·Lingding 화면 구현에도 사용했습니다.

AI 도구를 만들 때는 먼저 ‘Figma에서 선택한 버튼 구현 시간을 줄인다’처럼 단축할 작업을 하나 정합니다. 그다음 해당 작업에 필요한 선택 노드·레이아웃·텍스트·색상·간격만 전달하고, 클라이언트가 실패 원인을 구분할 수 있는 응답을 설계합니다.

공식 Dev Seat보다 기술적으로 우수하다는 비교 결과나 구현 시간이 몇 배 줄었다는 측정값은 없습니다.