피그마 댓글 기능 사용법: 화면 피드백으로 회의 시간 반으로 줄이는 법
회의 시간이 길어지는 이유는 설명이 부족해서만은 아닙니다. 대부분은 “어느 화면의 어느 부분을 말하는지”가 정확하지 않기 때문입니다. 메신저에는 “버튼 수정 필요”라고 남아 있고, 회의록에는 “문구 재검토”라고 적혀 있고, 피그마 화면은 또 따로 열어봐야 합니다.
이럴 때 피그마 댓글 기능을 잘 쓰면 회의 시간이 줄어듭니다. 화면 위에 바로 피드백을 남길 수 있기 때문입니다. 즉, 피그마 댓글은 단순 메모가 아니라 화면에 붙이는 작은 회의록입니다.
피그마 댓글이 회의 시간을 줄이는 이유
PPT나 메신저로 피드백을 주고받으면 위치가 애매해질 때가 많습니다. “오른쪽 버튼 수정”이라고 했는데, 오른쪽 버튼이 여러 개라면 다시 확인해야 합니다.
피그마 댓글은 화면의 특정 위치에 직접 남길 수 있습니다. 버튼, 문구, 입력창, 팝업, 오류 메시지 근처에 바로 의견을 달 수 있기 때문에 피드백 위치가 명확해집니다.
- 어느 화면의 피드백인지 바로 알 수 있습니다.
- 어느 버튼이나 문구를 말하는지 정확해집니다.
- 디자이너와 개발자가 같은 위치를 보고 대화할 수 있습니다.
- 해결된 댓글과 남은 댓글을 구분할 수 있습니다.
- 회의 전에 쟁점을 미리 정리할 수 있습니다.
피그마 댓글 기능 기본 사용법
피그마에서 댓글은 화면 위에 남기는 피드백입니다. 댓글 모드를 선택한 뒤 의견을 남길 위치를 클릭하고 내용을 작성하면 됩니다. 필요한 경우 담당자를 멘션해 확인을 요청할 수도 있습니다.
| 기능 | 기획자 활용법 |
|---|---|
| 댓글 남기기 | 버튼, 입력창, 문구 옆에 수정 의견을 남깁니다. |
| 멘션 | 디자이너, 개발자, 의사결정자를 지정해 확인을 요청합니다. |
| 답글 | 수정 방향이나 결정 내용을 이어서 정리합니다. |
| 해결 처리 | 반영 완료된 의견을 닫아 남은 이슈만 보이게 합니다. |
기획자가 써야 할 댓글 4가지 유형
피그마 댓글을 잘 쓰려면 모든 의견을 같은 방식으로 남기면 안 됩니다. 기획자는 댓글을 목적별로 구분해서 써야 합니다.
| 댓글 유형 | 사용 상황 | 예시 |
|---|---|---|
| 질문형 댓글 | 정책이나 흐름이 불명확할 때 | 저장 후 목록으로 이동하는 흐름이 맞을까요? |
| 수정 요청형 댓글 | 문구나 화면 요소 변경이 필요할 때 | 버튼명을 ‘저장’보다 ‘등록’으로 변경 검토 부탁드립니다. |
| 결정 기록형 댓글 | 회의에서 확정된 내용을 남길 때 | 이 화면은 권한 없음 케이스에서 공통 오류 화면으로 이동하는 것으로 결정했습니다. |
| 개발 확인형 댓글 | 구현 기준을 개발자와 맞출 때 | 이 버튼의 비활성 조건은 API 응답 기준으로 처리 가능한가요? |
댓글 앞에 [질문], [수정], [결정], [개발확인]처럼 말머리를 붙이면 나중에 댓글을 정리하기 쉽습니다.
좋은 댓글과 나쁜 댓글의 차이
좋은 댓글은 짧지만 기준이 있습니다. 나쁜 댓글은 감정이나 느낌만 남습니다. 기획자의 댓글은 “왜 바꿔야 하는지”와 “무엇으로 바꿀지”가 보여야 합니다.
| 나쁜 댓글 | 좋은 댓글 |
|---|---|
| 이 버튼 이상해요. | [수정] 신규 등록 흐름이므로 버튼명을 ‘저장’보다 ‘등록’으로 변경 검토 부탁드립니다. |
| 문구가 어색합니다. | [수정] 오류 문구를 ‘비밀번호를 다시 확인해 주세요.’로 변경하면 사용자가 원인을 이해하기 쉽습니다. |
| 이 화면 빠진 것 같아요. | [질문] 검색 결과가 0건일 때 빈 화면이 필요합니다. 안내 문구와 다시 검색 버튼을 추가할까요? |
| 개발 가능한가요? | [개발확인] 이 필터 조건은 다중 선택과 초기화 기능이 함께 필요한데, 현재 API 구조에서 가능한가요? |
회의 시간을 줄이는 댓글 운영법
피그마 댓글을 회의 중에만 쓰면 효과가 반쪽입니다. 가장 좋은 방식은 회의 전에 댓글을 먼저 남기고, 회의에서는 남은 쟁점만 확인하는 것입니다.
- 회의 전: 기획자가 화면을 보며 질문과 수정 의견을 댓글로 남깁니다.
- 회의 전: 담당자를 멘션해 미리 확인하게 합니다.
- 회의 중: 모든 화면을 다시 설명하지 않고 댓글이 달린 부분만 봅니다.
- 회의 중: 결정된 내용은 댓글 답글로 남깁니다.
- 회의 후: 반영 완료된 댓글은 해결 처리합니다.
이 방식으로 진행하면 회의는 “전체 설명 시간”이 아니라 “쟁점 결정 시간”으로 바뀝니다. 회의실 책상 위에 널려 있던 포스트잇들이 줄을 맞춰 앉는 느낌입니다.
댓글 사용 시 자주 하는 실수
피그마 댓글도 잘못 쓰면 오히려 혼란을 만듭니다. 특히 댓글을 너무 많이 남기거나, 결정된 내용을 정리하지 않으면 댓글창이 작은 잡초밭이 됩니다.
- 한 댓글에 여러 이슈를 한꺼번에 적지 않습니다.
- 수정 요청에는 이유와 원하는 결과를 함께 적습니다.
- 이미 해결된 댓글은 그대로 방치하지 않습니다.
- 개인 의견과 확정 결정을 구분해서 남깁니다.
- 정책 설명이 길어질 때는 Confluence나 별도 문서로 연결합니다.
결론
피그마 댓글 기능은 단순한 메모 기능이 아닙니다. 화면 위에 피드백을 남기고, 담당자를 지정하고, 결정 내용을 기록하고, 해결 여부를 관리하는 협업 도구입니다.
IT 기획자는 피그마 댓글을 통해 회의 전에 질문을 정리하고, 회의 중에는 쟁점만 확인하며, 회의 후에는 반영 여부를 관리할 수 있습니다.
결국 회의 시간을 줄이는 핵심은 말을 줄이는 것이 아니라, 말해야 할 위치를 정확히 찍는 것입니다. 피그마 댓글은 그 위치를 화면 위에 꽂아두는 작은 깃발입니다.
FAQ
Q1. 피그마 댓글은 누구나 남길 수 있나요?
파일 권한에 따라 댓글 작성 가능 여부가 달라질 수 있습니다. 실무에서는 리뷰 전에 참석자가 댓글을 남길 수 있는 권한인지 먼저 확인하는 것이 좋습니다.
Q2. 댓글에 담당자를 멘션하는 것이 좋나요?
확인이 필요한 사람을 멘션하면 피드백 책임자가 명확해집니다. 다만 모든 댓글에 여러 사람을 멘션하면 알림이 많아지므로 필요한 사람만 지정하는 것이 좋습니다.
Q3. 해결된 댓글은 삭제해야 하나요?
보통은 삭제보다 해결 처리를 권장합니다. 해결 처리를 하면 반영된 이력은 남기면서 현재 남은 이슈를 보기 쉬워집니다.
Q4. 긴 정책 설명도 피그마 댓글에 남기면 되나요?
짧은 기준은 댓글에 남겨도 됩니다. 하지만 조건, 예외, 권한, 데이터 처리처럼 내용이 길어지는 정책은 별도 문서에 정리하고 댓글에는 링크나 요약을 남기는 것이 좋습니다.
참고자료
Figma Help Center - Add comments to files
Figma Help Center - View and manage comments
Figma Help Center - Comment on prototypes
Google Search Central - Meta descriptions