이제 더 많은 팀이 캔버스(canvas)가 아닌 프롬프트(prompt)에서 시작하고 있습니다. 무언가를 설명하면, 에이전트(agent)가 이를 구축하고, 당신은 바로 배포(ship)합니다. 더 빠릅니다. 하지만 팀원들이 피드백을 남기던 장소인 Figma 코멘트(Figma comments)는 당신이 방금 건너뛴 그 캔버스에 붙어 있었습니다. 그래서 메모를 남길 곳이 사라졌습니다.

Figma에 실제로 일어나고 있는 일

Figma는 2025년 여름에 상장했습니다. 1년이 지난 지금, 주가는 상장가보다 훨씬 낮은 수준에 머물러 있으며, 첫 달의 고점(2026년 중반)과는 거리가 멉니다. 매출은 여전히 성장하고 있습니다. 이 글은 "Figma가 죽어가고 있다"는 내용이 아닙니다.

이 슬라이드는 한 가지 특정한 우려 사항을 추적합니다. 캔버스를 전혀 열지 않고도 작동하는 UI를 생성할 수 있게 해주는 도구들입니다. Anthropic은 2026년 4월에 Claude Design을 출시했습니다. Cursor에는 디자인 기능이 있습니다. 시장이 걸고 있는 도박은 더 적은 프로젝트가 디자인 파일에서 시작될 것이라는 점입니다. 이는 당신이 프롬프트에서 바로 구축한다면 겪게 될 것과 동일한 변화입니다.

여기 아무도 가격에 반영하지 않은 부분이 있습니다. 캔버스는 단순히 디자인이 머무는 곳이 아니었습니다. 그곳은 _대화(conversation)_가 머무는 곳이었습니다. 캔버스를 건너뛰면 단순히 목업(mockup) 단계를 잃는 것이 아니라, 모두가 피드백을 주고받던 공간을 잃는 것입니다.

Figma 코멘트는 픽셀(pixels)에 관한 것이 아니었습니다. 그것은 팀 전체가 무언가를 가리키며 "이건 좀 이상해요"라고 말할 수 있는 유일한 장소였습니다.

캔버스를 건너뛰면 코멘트도 건너뛰게 됩니다

Figma 코멘트가 실제로 어떤 역할을 했는지 생각해 보십시오. 팀 동료, 클라이언트, 혹은 카피(copy)에 의견이 있는 PM(프로덕트 매니저) 중 그 누구도 IDE를 열지 않았습니다. 그들은 파일을 열고, 요소를 클릭하고, 타이핑했습니다. 빌더(builder)는 정확히 어떤 프레임의 어떤 요소인지, 그리고 그 스레드(thread)가 바로 그곳에 있는 것을 확인했습니다.

작업물이 배포된 앱으로 바로 이동하면, 그 전체 루프(loop)는 거처를 잃게 됩니다. 리뷰어는 라이브 사이트를 보고 있습니다. 당신은 라이브 사이트에 대한 그들의 입력을 원합니다. 하지만 그들이 익숙한 도구는 Figma(배포된 것과 연결되지 않음)와 Slack(모든 메모가 빨간 원이 그려진 스크린샷이 됨)뿐입니다.

그래서 그들은 스크린샷을 보냅니다. 당신은 그것을 해독합니다. 당신은 에이전트(Agent)에게 프롬프트(Prompt)를 작성합니다. 에이전트는 어떤 요소인지, 어떤 페이지인지, 어떤 뷰포트(Viewport)인지 묻습니다. 스크린샷에는 그런 정보가 없기 때문입니다. 당신은 그들이 클릭한 순간에 캡처되었어야 할 컨텍스트(Context)를 재구축하는 데 10분을 소비합니다.

현재 메모가 남는 곳과 각 방식의 한계

어쨌든 Figma에 다시 댓글 달기. 빌드된 앱이 파일과 일치하지 않게 되기 전까지는 잘 작동하지만, 그 시점은 매우 빠르게 찾아옵니다. 그 이후부터 리뷰어(Reviewer)들은 실제 라이브 상태를 더 이상 설명하지 못하는 캔버스(Canvas) 위에 댓글을 달게 됩니다.

Slack에 스크린샷 올리기. 솔직히 말해 가장 기본이 되는 방식입니다. 설정이 필요 없고 누구나 이해할 수 있습니다. 대가는 모두 '번역' 과정에서 발생하며, 리뷰어가 늘어나고 반복(Iteration)이 거듭될수록 그 비용은 복리로 쌓입니다.

프리뷰 배포 툴바(Preview deploy toolbars). Vercel과 Netlify의 프리뷰 댓글 기능은 머지(Merge) 전 리뷰를 위해 진정으로 유용합니다. 함정은 다음과 같습니다: 리뷰어가 호스트(Host) 계정을 가지고 있어야 하며, 댓글은 프로덕션(Production)이 아닌 프리뷰에 남고, 그 결과물은 에이전트가 가져갈 수 있는 작업 항목(Work item)이 아니라 사람이 읽어야 하는 메모라는 점입니다.

누락된 레이어(Layer)가 해야 할 일

빌드된 앱을 위한 Figma 댓글을 대체하는 것이 무엇이든, 기존의 캔버스가 잘 수행했던 기능들을 새로운 환경에서도 수행할 수 있어야 합니다:

마지막 행은 캔버스가 결코 완벽히 해내지 못했던 부분입니다. "이게 실제로 수정되었나요?"라는 질문은 항상 후속 대화로 이어졌습니다. 라이브 제품에서는 이 루프를 자동으로 닫을 수 있습니다.

Pincushion이 간극을 메우는 방법

리뷰는 배포된 제품 위에서 이루어지며, 리뷰하는 사람들은 에디터(Editor)를 열 필요가 없습니다.

1. 리뷰어는 실제로 설치할 것이 없습니다. 한 번 공유하는 확장 프로그램(Extension)이나 링크면 충분합니다. 리뷰어는 라이브 사이트의 무엇이든 클릭하고 타이핑할 수 있습니다. 리뷰어의 수에는 제한이 없으며 자유롭습니다.
2. 핀(Pin)은 스크린샷이 담지 못하는 것을 포착합니다. 셀렉터(Selector), DOM 스니펫(Snippet), 스크린샷, 뷰포트(Viewport), 그리고 전체 스레드(Thread)가 에이전트(Agent)가 즉시 작업할 수 있는 워크 패킷(Work packet) 형태로 묶입니다.
3. 당신의 에이전트가 MCP를 통해 핀을 읽습니다. Cursor, Claude Code, Codex 또는 Windsurf에서의 단 한 번의 호출로 전체 컨텍스트(Context)를 가져옵니다. 에이전트가 의도가 무엇인지 다시 물어볼 필요가 없습니다.
4. 루프(Loop)가 완성됩니다. 핀의 문제가 해결되면 해당 브랜치(Branch), 커밋(Commit), PR(Pull Request) 정보를 함께 전달합니다. 배포 후크(Deploy hook)가 프로덕션 URL을 연결하며, 수정 사항은 라이브 사이트에서 다시 확인됩니다.

Figma에서 했던 것과 동일한 루프—지목하고, 논의하고, 수정하고, 종료하는 과정—를 실제로 배포되는 결과물 위에서 그대로 수행하는 것입니다.

Figma가 악당은 아닙니다

이 글은 Figma를 반대하기 위한 글이 아닙니다. 초기 탐색 단계나 디자인 결정을 엔지니어에게 전달하는 용도로는 여전히 캔버스(Canvas)가 제 역할을 다하고 있습니다. 핵심은 더 좁은 지점에 있습니다. 당신의 진실의 원천(Source of truth)이 배포된 앱이 되는 날, 피드백 루프 또한 그곳으로 이동해야 합니다. 현재 캔버스를 건너뛰는 대부분의 팀에게 피드백은 그저 Slack에 떨어져 사라져 버리고 맙니다.

그것이 바로 우리가 되고자 하는 레이어(Layer)입니다. 캔버스가 아니라, 팀원들이 라이브 앱을 가리키며 "이 부분이 이상해요"라고 말하면 그 메모가 즉시 수정으로 이어지는 공간 말입니다.

Pincushion은 무료로 시작할 수 있습니다: pincushion.io