FigJam MCP 연동 공부 정리 | 에이전트도 다이어그램이 필요했나

FigJam 블로그에서 꽤 흥미로운 발표가 올라왔다. 에이전트가 FigJam 보드를 직접 읽고 쓸 수 있게 됐다는 내용이었는데, 처음엔 그냥 플러그인 하나 추가된 거겠지 싶었다.

읽어보니 좀 다른 이야기였다. 에이전트와 팀이 협업할 때 생기는 간극 얘기였다. 에이전트가 코드를 빠르게 바꿔나가는 동안 팀이 그 변화를 따라가기가 어렵다는 문제다. 마크다운이나 텍스트로 설명을 받아도 그림으로 보는 것보다 직관적이지 않고, 그게 쌓이면 팀 전체가 같은 그림을 못 그리게 된다는 맥락이었다.

1️⃣ 이게 뭐냐?

Figma가 새로 공개한 건 FigJam을 위한 MCP 도구 묶음이다. 크게 세 가지인데:

• figma-use-figjam — 에이전트가 FigJam 보드를 읽고 직접 쓸 수 있게 하는 도구
• generate_diagram — 시스템 아키텍처나 ERD 같은 다이어그램을 자동으로 만들어줌
• generate-project-plan — 문서나 코드베이스를 시각적인 보드로 변환해줌

전에는 에이전트가 만든 아키텍처를 팀과 공유하려면 스크린샷을 찍고, 댓글을 요약하고, 변경사항을 수동으로 다시 설명해야 했다. 이제는 에이전트가 보드에 직접 쓰고, 거기에 달린 피드백도 읽어서 구현에 반영하는 구조가 된 거다.

워크플로우를 정리하면 이렇다. 에이전트가 컨텍스트를 수집해서 다이어그램을 만들고, 팀이 FigJam에서 시각적으로 피드백을 남기면, 에이전트가 그 피드백을 다시 읽고 구현하는 흐름이다. 단방향 공유가 아니라 양방향 협업이 된 셈이다.

2️⃣ 내가 든 생각

디자이너로서 봤을 때 흥미로웠던 부분은 “에이전트도 시각적 언어가 필요하다”는 점이었다. 텍스트만으로 복잡한 시스템 구조를 설명하는 건 사람도 어렵다. 에이전트가 써준 마크다운을 보면서 ‘이게 실제로 어떻게 연결되는 건지’ 머릿속으로 그려야 하는 게 비효율적이라는 걸 느낀 적이 있었는데, 그 간격을 줄이려는 시도처럼 보였다.

👉🏻 흥미로운 건, 이게 에이전트→사람 방향만이 아니라 사람→에이전트로도 작동한다는 거다. FigJam에 댓글로 피드백을 남기면 에이전트가 그걸 읽고 반영한다. FigJam이 팀과 에이전트 사이의 공통 작업 공간이 되는 셈이다.

💡 여기서 드는 질문: FigJam 댓글이 개발 협업의 일부가 된다면, “디자인 피드백”과 “개발 피드백”의 경계가 어떻게 달라질까?

FigJam은 지금까지 초기 아이디어 발산이나 워크샵 도구에 가까웠다. 거기서 실제 개발 협업 채널이 된다는 게 낯설기도 하고, 한편으로는 그게 어색하지 않은 시점이 와도 이상하지 않겠다 싶기도 했다.

3️⃣ 앞으로 어떻게 쓸까?

Cursor, VS Code, Claude 같은 MCP 클라이언트에서 바로 쓸 수 있고, 베타 기간엔 무료라고 한다.

솔직히 혼자 작업하는 경우엔 팀 협업 기능의 가치를 체감하기가 어렵다. 그래도 에이전트가 만들어준 아키텍처 다이어그램을 FigJam에서 직접 보고 수정해보는 흐름은 한번 써볼 만하다고 느꼈다. 코드 구조를 텍스트보다 그림으로 먼저 보는 편이 나한테는 더 맞는 방식인 것 같아서.

⭐️ 마지막으로, 디자이너 입장에서 공부하며 느낀 것

정리해보니 이게 “FigJam에 에이전트 기능 추가”라기보다 “협업 도구가 에이전트 워크플로우 안으로 들어온 것”에 가까운 일이었다. 방향이 반대인 셈이다.

---

참고 원문: FigJam is now your coding agent’s whiteboard too