Figma 댓글이 많아도 수정이 끝나지 않는 이유는 댓글 수가 아니라 요청의 빈칸에 있습니다. “이 부분 조금 더 눈에 띄게”라는 문장에는 무엇을 바꾸는지, 누가 바꾸는지, 언제 다시 볼지, 어느 화면이면 끝난 것인지가 빠져 있습니다. 그 빈칸을 채우지 않은 댓글은 알림을 받아도 다음 회의의 재논의로 돌아옵니다.
이 글은 Figma 댓글을 대상 위치·변경 내용·담당자·검토 기한·완료 화면이 있는 작은 작업 표준으로 바꾸는 방법을 다룹니다. Figma가 이 다섯 항목을 자동으로 배정한다는 뜻은 아닙니다. 위치 고정, 멘션, 댓글 검색·필터, 해결 상태, 알림 설정 같은 제품 기능 위에 팀이 스스로 올리는 운영 규칙입니다. 개발 전달 방식, 디자인 시스템, 브랜드 전략이나 납기 보장은 여기서 다루지 않습니다.
먼저, 열린 댓글 하나가 다음 행동을 말하게 만듭니다
댓글을 남기기 전 아래 다섯 칸을 한 줄 안에 채웁니다. 처음에는 길어 보이지만, 회의 뒤에 “이 댓글은 누가 처리하기로 했지?”를 다시 묻는 시간보다 짧습니다. 중요한 것은 예쁜 문장이 아니라, 다른 사람이 같은 화면을 보고 같은 끝을 떠올릴 수 있는가입니다.
| 칸 | 댓글에 적을 내용 | 비어 있을 때 생기는 일 |
|---|---|---|
| 대상 위치 | 프레임·섹션·버튼 등 바꿀 곳 | 같은 파일의 다른 화면을 고친다 |
| 변경 내용 | 남길 것, 바꿀 것, 제외할 것 | “더 좋게”라는 해석 싸움이 생긴다 |
| 담당자 | 수정할 사람 또는 확인할 사람 | 모두가 봤지만 아무도 시작하지 않는다 |
| 검토 기한 | 다시 볼 날짜·회의·배포 전 시점 | 우선순위가 밀려 열린 상태로 남는다 |
| 완료 화면 | 어떤 상태를 보면 닫을지 | 수정 뒤에도 해결 표시를 못 한다 |
예를 들어 “CTA가 약해요” 대신 “결제 완료 프레임의 하단 CTA / 문구는 유지하고 대비만 높임 / 민지 수정, 준호 확인 / 목요일 15시 시안에서 재확인 / 모바일 폭 390px에서 버튼과 보조 문구가 함께 읽히면 종료”라고 남깁니다. 이 문장은 디자인 답을 미리 강요하지 않습니다. 다만 수정의 경계와 다시 보는 시점을 남깁니다.
Figma에서는 파일 안의 특정 위치나 영역에 댓글을 붙일 수 있고, 사람을 멘션할 수 있습니다. 위치는 제품 기능으로 고정하고, 나머지 네 칸은 팀의 문장 규칙으로 채우는 편이 안전합니다. 기능의 실제 범위는 Figma 댓글 추가 안내에서 다시 확인할 수 있습니다.
댓글을 세 종류로 나누면 ‘좋아요’와 수정 요청이 섞이지 않습니다
모든 의견을 같은 방식으로 처리하면, 참고 의견이 긴급 수정처럼 보이거나 실제 오류가 취향 토론으로 밀립니다. 댓글을 열 때 먼저 성격을 붙여 보세요. 팀 라벨 기능을 새로 만들 필요는 없습니다. 문장 첫머리에 [수정], [확인], [참고]처럼 표기해도 충분합니다.
| 종류 | 남겨야 할 것 | 해결 표시를 하는 때 | 예시 |
|---|---|---|---|
| 수정 | 바꿀 대상과 완료 화면 | 약속한 화면이 보일 때 | [수정] 가격 표기 줄바꿈 제거 |
| 확인 | 결정이 필요한 질문과 답할 사람 | 답과 선택 근거가 남을 때 | [확인] A/B 중 법무 문구 확인 |
| 참고 | 다음 작업에 쓰일 맥락 | 읽은 사람이 연결 위치를 남겼을 때 | [참고] 이전 캠페인 반응 메모 |
[수정]에는 완료 화면이 반드시 있어야 합니다. [확인]에는 정답을 만들기보다 답할 사람과 판단 재료를 적습니다. [참고]는 지금 고칠 일을 만들지 않는 대신, 연결할 프레임이나 문서를 써 두면 나중에 찾을 수 있습니다. 이 구분은 작업량을 줄인다는 약속이 아니라, 열린 댓글의 의미를 섞지 않기 위한 분류입니다.
대상 위치는 화면 이름보다 ‘보이는 문제’에 붙입니다
“랜딩 페이지 수정”처럼 큰 프레임 이름만 적으면 같은 프레임 안의 여러 요소가 후보가 됩니다. 댓글 핀을 실제 버튼, 문장, 카드 근처에 두고 “첫 화면”, “하단”, “두 번째 카드”처럼 사용자가 볼 순서를 덧붙입니다. Figma 댓글은 프레임·레이어·캔버스 좌표에 연결될 수 있으므로, 위치를 먼저 가리키는 습관이 특히 중요합니다. 이동이나 잘라내기·붙여넣기 뒤에는 연결 상태가 달라질 수 있다는 안내도 댓글 이동·편집 안내에서 확인할 수 있습니다.
| 모호한 표현 | 바꿔 적는 방법 | 피하는 이유 |
|---|---|---|
| 여기 좀 수정 | 가입 프레임의 이메일 오류 문구 | “여기”가 화면을 벗어나면 사라진다 |
| 버튼 강조 | 첫 화면 CTA의 대비만 조정 | 문구·크기·위치까지 바꾸라는 뜻으로 번진다 |
| 모바일 확인 | 390px 프레임의 하단 고정 버튼 | 어느 기기·어느 상태인지 알 수 없다 |
| 문구 다시 보기 | 혜택 카드 2의 보조 문장 | 타이틀과 본문이 섞여 수정 범위가 넓어진다 |
위치를 정한 뒤에는 “무엇을 하지 않을지”도 짧게 적습니다. 예컨대 “CTA 문구는 유지”라고 적으면 대비 조정이 카피 재작성으로 커지는 것을 막습니다. 위치와 제외 범위가 함께 있을 때 수정자는 선택권을 갖고, 검토자는 원래 요청이 변했는지 빠르게 볼 수 있습니다.
담당자는 한 명, 확인자는 별도로 적습니다
한 댓글에 여러 사람이 멘션되면 책임이 분산되기 쉽습니다. 실행 담당자와 확인 담당자를 분리하세요. 둘이 같은 사람일 수도 있지만, 역할을 문장으로 드러내야 합니다. Figma의 멘션과 댓글 알림은 사람에게 알리는 수단이지, 담당자나 마감일을 자동으로 정하는 기능은 아닙니다.
| 상황 | 실행 담당자 | 확인 담당자 | 댓글 끝맺음 예시 |
|---|---|---|---|
| 디자이너가 화면 수정 | 디자인 담당 1명 | 요청자 또는 PO 1명 | 수정: 민지 / 확인: 준호 |
| 카피 사실관계 확인 | 카피 담당 1명 | 정책·상품 담당 1명 | 반영: 서연 / 문구 확인: 태호 |
| 결정 대기 | 결정을 내릴 사람 1명 | 기록을 남길 사람 1명 | 선택: 지수 / 결과 기록: 민지 |
담당자가 휴가이거나 업무 범위 밖이라면 멘션만 남긴 채 기다리지 말고, 댓글 본문에 다음 경로를 남깁니다. “담당자 부재 시 PO가 대체 담당자를 지정”처럼 한 줄이면 충분합니다. 사람을 많이 태그하는 방식보다, 다음에 누가 연결할지 보이는 방식이 낫습니다.
기한은 ‘완료 약속’이 아니라 다시 보는 기준으로 씁니다
댓글에 날짜를 적는 목적은 납기를 보장하는 것이 아닙니다. 다음 검토에서 이 댓글을 다시 열지, 해결 표시를 할지, 범위를 다시 나눌지를 정하는 기준을 남기는 데 있습니다. 그래서 “내일까지”보다 “목요일 15시 시안에서 재확인”이 유용합니다. 시차나 휴일이 있는 팀은 날짜와 시간대를 함께 씁니다.
| 좋지 않은 기한 | 다시 볼 기준으로 바꾼 문장 | 그때 할 일 |
|---|---|---|
| 빨리 부탁 | 7월 30일 리뷰 전 재확인 | 바뀐 화면과 원 요청을 대조 |
| 이번 주 안 | 금요일 배포 후보 프레임에서 확인 | 범위가 남았으면 새 댓글로 분리 |
| 다음 회의 전 | 8월 1일 14시 정기 검토에서 결정 | 결정자 답이 없으면 상태를 갱신 |
| ASAP | 다음 QA 캡처에서 보기 | 캡처에 없는 이유를 기록 |
Figma는 파일별로 모든 댓글, 멘션·답글만, 알림을 받지 않음 등의 댓글 알림 선택지를 제공합니다. 팀의 검토 기준과 제품 알림 설정은 따로 다뤄야 합니다. 실제 알림 옵션은 Figma 댓글 알림 안내에서 확인하고, 민감한 리뷰가 많은 파일이라면 본인이 확인할 수 있는 범위로 설정합니다.
완료 화면을 먼저 합의하면 ‘해결됨’이 숨김이 되지 않습니다
Figma에서 댓글을 해결 처리하면 기본적으로 캔버스와 사이드바에서 보이지 않게 되며, 해결된 댓글을 다시 표시해 되돌아볼 수 있습니다. 그러므로 해결 버튼은 “대충 끝”이라는 뜻이 아니라, 약속한 완료 화면을 확인했다는 기록이어야 합니다. 검색·정렬·필터와 해결된 댓글 표시 방식은 Figma 댓글 관리 안내에 설명되어 있습니다.
| 요청 성격 | 완료 화면의 예 | 해결 처리 전에 보는 것 |
|---|---|---|
| 시각 수정 | 지정한 프레임에서 대비·간격이 보임 | 원래 위치와 제외 범위가 지켜졌는지 |
| 문구 수정 | 승인 문장이 해당 컴포넌트에 반영됨 | 다른 화면의 용어와 충돌하지 않는지 |
| 선택 확인 | 선택한 안과 근거가 댓글에 남음 | 반대안이 왜 보류됐는지 |
| 참고 연결 | 관련 프레임·문서 링크가 남음 | 지금 처리할 일로 오해되지 않는지 |
완료 화면이 아직 없으면 해결 처리를 미루는 대신 상태를 덧붙입니다. 예를 들어 수정 중: 7월 30일 재확인처럼 남깁니다. 해결 댓글을 다시 볼 수 있다는 사실은 점검에 도움이 되지만, 오래된 열린 댓글을 방치해도 된다는 뜻은 아닙니다.
프레임이 움직이거나 버전이 갈라질 때는 새 기준을 남깁니다
파일을 정리하면서 프레임 이름이 바뀌거나 콘텐츠를 잘라 다른 파일로 옮기면, 기존 댓글이 가리키는 위치를 찾기 어려워질 수 있습니다. 이때 해결 표시만 눌러 숨기지 말고, 새 위치 또는 새 댓글의 링크를 원 댓글에 남깁니다. 그래야 이전 맥락을 잃지 않습니다.
| 변경 상황 | 기존 댓글에서 할 일 | 새 댓글에서 할 일 |
|---|---|---|
| 프레임 이름 변경 | 새 이름과 이동 이유를 한 줄 남김 | 같은 다섯 칸을 유지 |
| 화면을 다른 파일로 이동 | 새 파일·프레임 링크를 남김 | 원 요청의 범위를 다시 적음 |
| 요청 범위가 커짐 | 원 댓글의 완료 기준을 지킴 | 커진 일은 별도 댓글로 분리 |
| 결정이 뒤집힘 | 이전 결정과 바뀐 이유를 남김 | 새 결정자·재확인 시점을 적음 |
댓글의 위치 연결을 유지하려고 모든 파일 구조 변경을 피할 필요는 없습니다. 대신 이동이 작업의 의미를 바꾸는 순간만 기록합니다. 이 원칙은 Figma의 기능 설명이 아니라, 나중에 회의 맥락을 복구하기 위한 팀 운영 규칙입니다.
알림을 많이 받는 것과 댓글을 관리하는 것은 다릅니다
알림을 모두 켜면 놓치는 일은 줄어 보이지만, 누가 행동할지 모른 채 읽음만 늘 수 있습니다. 반대로 알림을 꺼도 담당자·기한·완료 화면이 있다면 정기 검토에서 열린 항목을 찾을 수 있습니다. Figma는 댓글을 검색하고 정렬·필터하는 방법을 제공하므로, 알림과 별개로 짧은 점검 시간을 정해 두는 편이 낫습니다.
| 신호 | 먼저 볼 질문 | 다음 처리 |
|---|---|---|
| 멘션 알림 | 내가 실행 담당자인가, 확인 담당자인가 | 역할이 없으면 요청자에게 되묻기 |
| 답글 알림 | 완료 화면이 바뀌었는가 | 기한과 범위도 함께 갱신 |
| 오래 열린 댓글 | 다섯 칸 중 무엇이 비었는가 | 부족한 칸을 채우거나 새 댓글로 분리 |
| 해결된 댓글 | 원 요청과 결과가 이어지는가 | 필요하면 해결된 항목을 다시 표시해 확인 |
주 1회 15분처럼 짧게 열어도 좋습니다. 이 시간의 목적은 모든 댓글을 닫는 것이 아니라, 담당자 없는 댓글과 완료 화면 없는 댓글을 찾아내는 것입니다. 댓글 수를 성과 지표로 삼거나 처리 속도를 약속하는 방식은 피하세요.
팀에 바로 붙일 수 있는 한 줄 형식
처음부터 긴 매뉴얼을 만들기보다 아래 형식을 한 파일에서 시험해 보세요. 복사해서 댓글 첫 줄에 붙이고, 빈 칸이 있으면 요청을 열지 않는 방식입니다.
[수정/확인/참고] 대상 위치 / 바꿀 내용과 제외 범위 / 실행 담당자·확인 담당자 / 다시 볼 시점 / 완료 화면
예시: [수정] 결제 완료 프레임 CTA / 문구 유지, 대비만 조정 / 수정 민지·확인 준호 / 목 15시 시안 / 390px에서 버튼과 보조 문구가 함께 읽히면 종료
이 형식은 도구 설정을 대신하지 않습니다. 파일 권한, 댓글 권한, 개인 알림 선택은 현재 Figma 댓글 기본 안내와 팀의 접근 권한 기준을 따로 확인해야 합니다. 또한 수정 결과가 사용자 반응, 전환, 일정, 검색 노출이나 광고 승인으로 이어진다고 보장하지 않습니다.
완료 화면은 산출물의 역할에 맞춰 더 구체적으로 쓸 수 있습니다. 소셜 카드의 경우에는 어떤 행동을 하나만 남길지부터 정리한 Canva 카드뉴스의 한 장 역할 정하기처럼, 배너라면 대표 상품과 문구 길이를 먼저 정리한 미리캔버스 기획전 배너 우선순위 기준처럼 조건을 적어 두면 좋습니다. 이 링크들은 Figma 기능 설명이 아니라, 댓글의 완료 화면을 산출물별로 좁히는 참고 기준입니다.
자주 묻는 질문
댓글마다 다섯 칸을 전부 써야 하나요?
참고로 남기는 짧은 맥락에는 완료 화면이 간단할 수 있습니다. 다만 실제 수정이나 결정을 요청한다면 다섯 칸 중 무엇이 비었는지 드러나야 합니다. 비어 있는 칸이 있다면 요청을 짧게 나누는 편이 낫습니다.
해결 표시를 했다가 다시 열 수 있나요?
Figma는 해결된 댓글을 다시 표시해 볼 수 있습니다. 그러나 이 기능을 되돌리기 수단으로만 쓰기보다, 해결 전에 완료 화면을 확인하는 습관을 먼저 만드세요.
댓글이 너무 많아 어디부터 봐야 하나요?
검색·정렬·필터로 범위를 좁힌 뒤, 담당자 없는 댓글과 다시 볼 시점이 지난 댓글부터 봅니다. 모든 의견의 우선순위를 한 번에 정하려 하지 말고, 다음 행동이 없는 항목부터 선별합니다.
다음 검수에서 열린 댓글 하나를 골라 다섯 칸이 모두 있는지 살펴보세요. 빈 칸 하나를 채우는 것만으로도 그 댓글이 다음 사람에게 넘길 수 있는 작업이 됩니다.



