Figma 댓글이 배포된 앱에서 작동하지 않을 때—작동하는 방법
Source: Dev.to
Figma의 댓글 시스템은 캔버스를 중심으로 동작합니다. 팀이 실제 제품을 배포하고 배포된 버전을 반복해서 개선할 때, 그 캔버스는 사라지고, 그에 맞춰 만들었던 피드백 루프도 사라집니다. 이것이 대부분의 디자인‑엔지니어 팀이 조용히 마주치는 격차입니다.
Figma 댓글이 작동하는 이유는 모든 댓글이 정적인 프레임 위의 좌표에 고정돼 있기 때문입니다. 프레임을 바꾸지 않는 한 좌표도 변하지 않으며, 댓글은 캔버스가 시간에 얼어붙어 있기 때문에 자신의 위치를 알 수 있습니다.
배포된 앱은 그 어떤 것도 아닙니다.
- 동적인 상태 – 리뷰어가 고정해 둔 버튼이 다음 세션에서는 전혀 보이지 않을 수도 있습니다.
- 반응형 레이아웃 – 데스크톱 좌표에 달린 댓글은 모바일에서는 의미가 없습니다.
- 변하는 DOM – 콘텐츠가 로드되거나 CSS가 바뀌거나 새 버전을 배포하면 요소 위치가 바뀝니다.
- 프레임이 없음 – 실시간 사이트에는 댓글이 붙일 “현재 버전”이 존재하지 않습니다.
이것은 Figma가 메우려는 격차가 아니라, 전혀 다른 상황에서 발생하는 문제입니다.
Figma 댓글은 캔버스에 고정됩니다. 배포된 앱에는 캔버스가 없습니다.
디자인을 직접 구현하면서—에이전트를 프롬프트하고, 무언가를 배포한 뒤, 배포된 제품을 반복해서 개선하는 팀에게 이 격차는 구현자가 아닌 사람이 피드백을 줘야 할 때 처음 드러납니다. 클라이언트, 비평을 하는 팀원, 카피에 의견을 가진 PM 등 말이죠.
그들은 라이브 사이트를 보고 있습니다. 당신은 그들의 의견을 라이브 사이트에서 받고 싶지만, 그들이 사용할 수 있는 도구는 Figma(실제와 연결되지 않음)와 Slack(스크린샷에 빨간 원을 그려서 전달)뿐입니다.
그래서 스크린샷을 보내고, 당신은 그것을 해석합니다. 에이전트에게 프롬프트를 작성하고, 에이전트는 스크린샷만으로는 어느 요소인지, 어느 페이지인지, 어떤 뷰포트인지, 어떤 인터랙션 상태인지 알 수 없으니 추가 질문을 합니다. 결국 10분 정도를 들여 자동으로 캡처돼야 할 컨텍스트를 재구성하게 됩니다.
배포된 앱이 Figma 파일과 거의 동일하게 보인다면 잠시 동안은 괜찮을 수 있습니다. 하지만 “거의 동일함”은 오래가지 못합니다. 실제품이 목업과 달라지는 순간—그리고 그럴 수밖에 없죠—Figma 댓글은 더 이상 존재하지 않는 무언가에 대해 얘기하고 있는 겁니다. 리뷰어는 오래된 캔버스에 댓글을 달고, 실제 문제는 라이브 사이트에 남아 있습니다.
몇몇 팀은 배포된 앱을 스크린샷으로 찍어 Figma에 붙여놓고 그곳에 댓글을 달기도 합니다. Slack에 직접 스크린샷을 올리는 것보다 나은 선택이지만, 여전히 같은 문제를 안고 있습니다: 주석이 픽셀 좌표에 기반하고, 요소 앵커가 아니며, 컨텍스트(뷰포트, 페이지 상태, DOM)가 사라지고, 실제 배포물에 연결된 스레드가 없습니다.
프리뷰 배포 툴바는 머지 전 리뷰에 정말 유용합니다. 리뷰어가 프로덕션에 가기 전 빌드에 댓글을 달 수 있게 해 주죠. 제한점은 리뷰어가 호스팅 플랫폼 계정을 가져야 하고, 댓글이 프리뷰에만 존재한다는 점, 그리고 출력이 인간이 읽는 댓글일 뿐 코딩 에이전트가 바로 잡을 작업 항목이 아니라는 점입니다.
이 도구들은 QA와 클라이언트 승인용으로 만들어졌습니다: 시각적 버그를 포착하고 티켓으로 전환해 보드에 추적합니다. 그 역할은 훌륭히 수행합니다. 하지만 디자인 비평은 버그 리포팅이 아닙니다. 결함을 제보하는 것이 아니라 리뷰를 진행하는 것이며, 결과물을 칸반 컬럼에 넣는 것은 코딩 에이전트와 함께 작업할 때는 잘못된 목적지입니다.
솔직한 기본 옵션은 설정이 전혀 필요 없고, 모두가 이해한다는 점입니다. 비용은 전적으로 번역 시간에 들어갑니다—스크린샷마다 수동으로 컨텍스트를 재구성해야 하니까요—그리고 리뷰어와 반복 사이클이 늘어날수록 비용은 기하급수적으로 늘어납니다. 작은 팀이 가끔 리뷰를 할 때는 감당 가능한 부담이지만, 빠르게 배포하고 짧은 루프를 도는 팀에게는 큰 걸림돌이 됩니다.
배포된 앱에서 Figma 댓글을 대신할 무언가가 해결해야 할 과제는 Figma 댓글이 잘 해냈던 부분을 새로운 상황에서도 그대로 구현하는 것입니다.
Figma 댓글이 잘한 점
배포된 앱에 필요한 것
1. 특정 요소에 고정 (픽셀 아님)
- CSS 셀렉터 + 페이지 URL 로 고정 → 리로드와 반응형 레이아웃에서도 살아남음
2. 리뷰어에게 설정 필요 없음
- 리뷰어가 설정할 필요 없이 — Figma 파일에 접근할 수 있는 사람이라면 누구든 댓글 달 수 있음
- 리뷰어가 설정할 필요 없음 — 클라이언트와 PM은 개발 툴체인을 설치할 필요가 없음
3. 논의 대상에 스레드가 연결됨
- 스레드가 핀에 남아 있음, Slack 채널에 흩어지지 않음
4. 제작자가 컨텍스트를 파악할 수 있음
- 제작자(또는 에이전트)가 보는 정보: 셀렉터, DOM 스니펫, 스크린샷, 뷰포트, 페이지 URL, 프로젝트 컨텍스트
5. 변경이 배포되면 댓글이 해결됨
- 특정 커밋과 PR에 핀이 해결됨, 필요 시 배포된 사이트에서 검증 가능
Figma가 절대 제공하지 못한 다섯 번째 포인트—“정말 고쳐졌는가?”—는 실제품에서는 자동으로 루프를 닫을 수 있습니다.
Pincushion은 바로 이 순간을 위해 만들어졌습니다—피드백 세션이 캔버스가 아닌 배포된 제품에서 일어나고, 리뷰어가 IDE를 열 필요가 없는 상황을 말이죠.
리뷰어는 아무것도 설치하지 않습니다. 한 번 공유한 브라우저 확장 프로그램을 사용하거나 링크를 클릭하면 됩니다. 배포된 사이트 어디든 클릭하고 메모를 남기면 됩니다. 리뷰어는 자유롭고 무제한입니다.
핀은 Figma가 할 수 없었던 정보를 모두 담습니다: CSS 셀렉터, DOM 스니펫, 스크린샷, 뷰포트 크기, 그리고 전체 스레드—시작부터 에이전트가 바로 작업할 수 있는 패킷 형태로 번들링됩니다.
코딩 에이전트는 MCP를 통해 핀을 읽습니다. implement_approved_pins 를 Cursor, Claude Code, Codex, Windsurf 등에서 한 번 호출하면 전체 컨텍스트를 받아옵니다. 에이전트는 “무엇을 의미하는가?”를 물어볼 필요가 없습니다—이미 요소, 페이지 상태, 스레드가 제공되었으니까요.
루프가 닫힙니다. 에이전트가 핀을 해결하면 브랜치, 커밋, PR을 연결하고, 배포 훅이 프로덕션 URL을 연결합니다. Pincushion AI가 수정 여부를 재검증하고 결과를 핀에 다시 기록합니다—리뷰어는 “PR #47에서 수정, 프로덕션에 배포, 검증 완료” 라는 메시지를 보게 됩니다.
워크플로는 Figma에서 했던 핀 → 논의 → 수정 → 종료와 동일하지만, 실제 배포되는 대상에서 이루어집니다.
이는 Figma를 반대하는 이야기가 아닙니다. 초기 탐색, 컴포넌트 설계, 엔지니어와 디자인 의사결정 공유 단계에서는 Figma 댓글이 충분히 제 역할을 합니다. 핵심은 배포된 제품을 반복할 때 피드백 루프도 그곳에 존재해야 한다는 점—실제와 한 단계 떨어진 파일이 아니라.
몇몇 팀은