Figma의 댓글 시스템은 캔버스를 중심으로 구축되어 있습니다. 팀이 실제 제품을 출시하고 배포된 결과물을 반복 개선할 때, 그 캔버스는 사라지며, 이로 인해 여러분이 주변에 구축했던 피드백 루프도 함께 사라집니다. 이것이 대부분의 디자인-엔지니어링 팀들이 조용히 부딪히는 간극입니다.

Figma 댓글이 실제로 의존하는 것들

Figma 댓글은 모든 댓글이 정적 프레임 위의 좌표에 고정되기 때문에 작동합니다. 프레임은 변경하지 않는 한 변하지 않습니다. 캔버스가 시간에 고정되어 있기 때문에, 댓글은 자신이 어디에 존재하는지 알고 있습니다.

여러분의 배포된 앱은 이들 중 어느 것도 아닙니다. 그것은 다음을 가지고 있습니다:

• 동적 상태(Dynamic state) — 리뷰어가 고정한 버튼이 다음 세션에서는 같은 상태로 아예 보이지 않을 수도 있습니다.
• 반응형 레이아웃(Responsive layouts) — 데스크톱 좌표에 배치된 댓글은 모바일에서는 의미가 없습니다.
• 움직이는 DOM(Moving DOM) — 콘텐츠 로드, CSS 변경 또는 새 버전을 출시함에 따라 요소의 위치가 변합니다.
• 프레임 부재(No frame) — 라이브 사이트에는 댓글이 첨부할 수 있는 '현재 버전'이 없습니다.

이것은 Figma가 메울 간극이 아닙니다. 이것은 다른 장소에서 발생하는 완전히 다른 문제입니다.

Figma 댓글은 캔버스에 고정됩니다. 여러분의 배포된 앱에는 캔버스가 없습니다.

간극이 나타나는 순간

에이전트에게 프롬프트를 요청하고, 무언가를 출시한 다음, 배포된 제품을 반복 개선하며 디자인하는 팀들에게 이 간극은 처음으로 빌더가 아닌 사람이 피드백을 제공해야 할 때 드러납니다. 클라이언트일 수도 있고, 크리틱(crit)을 하는 팀원일 수도 있으며, 카피에 대한 의견을 가진 PM일 수도 있습니다.

그들은 라이브 사이트를 보고 있습니다. 여러분은 그들이 라이브 사이트에 대해 입력하기를 원합니다. 하지만 그들이 사용할 줄 아는 유일한 도구는 Figma(실제 작동하는 것과 연결되어 있지 않음)와 Slack(모든 메모를 빨간색 원이 있는 스크린샷으로 만드는)뿐입니다.

그래서 그들은 스크린샷을 보냅니다. 여러분은 그것을 해독합니다. 에이전트에게 프롬프트를 작성합니다. 그런데 에이전트는 질문을 합니다. 왜냐하면 스크린샷에는 어떤 요소, 어떤 페이지, 어떤 뷰포트 또는 어떤 상호작용 상태인지 명시되어 있지 않기 때문입니다. 여러분은 자동으로 포착되었어야 할 컨텍스트를 재구성하는 데 10분을 소비합니다.

팀들이 의지하는 것과 각각의 한계점

1. 그래도 Figma에 댓글을 남기기

배포된 앱이 Figma 파일과 매우 유사하다면, 이 방법은 한동안 작동할 수 있습니다. 하지만 '매우 유사함'이라는 상태는 거의 유지되지 않습니다. 실제 제품이 목업(mockup)에서 벗어나는 순간 — 그리고 그렇게 될 것입니다 — Figma 댓글은 더 이상 존재하지 않는 것에 대해 이야기하게 됩니다. 검토자들은 실제 문제가 라이브 사이트에 있을 때, 구식 캔버스에 댓글을 남기게 됩니다.

2. Figma 또는 Loom에 주석이 달린 스크린샷

일부 팀은 배포된 앱의 스크린샷을 찍어 Figma에 붙여넣고 거기에 댓글을 답니다. Slack의 원본 스크린샷보다는 낫지만, 대부분 같은 문제점을 물려받습니다: 주석은 요소(element) 고정점이 아니라 픽셀 좌표입니다; 컨텍스트(뷰포트, 페이지 상태, DOM)가 손실됩니다; 실제로 배포하는 대상에 연결된 스레드가 없습니다.

3. Vercel / Netlify 미리보기 댓글

미리보기 배포 도구 모음은 병합 전 검토(pre-merge review)에 정말 유용합니다. 이를 통해 검토자들은 프로덕션으로 가기 전에 빌드에 대해 댓글을 달 수 있습니다. 한계점: 검토자들은 호스팅 플랫폼 계정이 필요하고, 댓글은 미리보기(프로덕션 사이트가 아님)에 생겨나며, 결과물은 코딩 에이전트가 가져와 구현할 작업 항목(work item)이 아니라 사람이 읽을 댓글입니다.

4. 버그 보고 도구 (BugHerd, Marker.io, Userback)

이러한 도구들은 QA 및 클라이언트 승인용으로 구축되었습니다: 시각적 버그를 포착하고, 이를 티켓으로 변환하며, 보드에서 추적합니다. 이 작업에는 확실합니다. 불일치점: 디자인 비평(design crit)은 버그 보고가 아닙니다. 결함을 신고하는 것이 아니라 검토를 수행하는 것이며 — 코딩 에이전트를 이용해 구축할 경우, 칸반 컬럼으로 들어가는 결과물은 잘못된 목적지입니다.

5. 그냥 Slack을 사용하고 그것에 대처하기

솔직한 기본값입니다. 설정이 전혀 필요 없고, 보편적으로 이해됩니다. 비용은 전적으로 번역 시간(every screenshot is a manual reconstruction job)에 달려 있으며 — 검토자 한 명과 반복 주기마다 복합적으로 증가합니다. 가끔씩 검토를 하는 소규모 팀에게는 작동 가능한 세금(tax)이지만; 빠르게 배포하고 짧은 루프로 반복하는 팀에게는 실제적인 장애물입니다.

대안이 실제로 해야 할 일

배포된 앱을 위해 Figma 댓글을 대체하는 것은 Figma 댓글이 잘 해결했던 문제들을 새로운 환경에서 작동시키면서 해결해야 합니다.

Figma 댓글의 장점	배포된 앱에서의 동등한 기능
특정 요소에 고정됨 (픽셀 단위가 아님)	CSS 선택자 + 페이지 URL로 고정 — 새로고침 및 반응형 레이아웃에서도 유지
...
배운 다섯 번째 항목은 Figma가 결코 완벽하게 제공하지 못했던 부분입니다. 즉,

이것은 Figma에 대한 반박이 아닙니다. 초기 탐색(early exploration), 컴포넌트 디자인, 그리고 엔지니어와 디자인 결정을 공유하는 데 있어서 Figma 댓글 기능은 제 역할을 잘 수행합니다. 핵심은 더 좁습니다. 즉, 배포된 제품을 반복적으로 개선(iterating)할 때는 피드백 루프 역시 그곳에 존재해야 한다는 것입니다. 실제 것(real thing)과 한 단계 떨어진 파일 안이 아닙니다.

어떤 팀들은 두 가지를 병행합니다. Figma는 초기 단계 작업용, Pincushion은 라이브 앱에서의 비평 세션(crit sessions)용입니다. 이것은 합리적인 분할입니다. 목표는 단지 피드백이 슬랙(Slack)의 스크린샷 속에 존재하지 않게 하는 것입니다.

저는 Pincushion을 만들었습니다. 이 도구는 팀원들이 라이브 앱에 핀을 고정할 수 있게 해주며, 사용자의 AI 코딩 에이전트(Cursor, Claude Code, Codex 등)가 이를 구현 준비가 된 작업 패킷으로 가져갑니다. 리뷰어에게는 무료입니다. 설정은 2분 만에 완료할 수 있습니다.