디자이너가 접근성 문제를 발견합니다. 티켓을 씁니다. 백로그에 들어갑니다. 그리고 묻힙니다. 이번 분기에도, 다음 분기에도요. 피그마가 최근 공개한 사례 하나는 이 익숙한 결말을 뒤집었어요 — 디자이너가 직접 코드에 들어가서, 브랜치를 만들고, 수정하고, PR을 올렸거든요. 그것도 하루 만에요.
왜 그 수정, 아직도 백로그에 있어요?
접근성 이슈는 대부분 사소해 보여요. 대비가 낮은 날짜 선택기, 스크린리더가 못 읽는 버튼, 애매한 네비게이션 라벨. 근데 이게 "사소해서 안 고치는 게" 아니라 "손 댈 사람이 없어서 못 고치는 것"이더라고요. 2026년 2월 WebAIM 조사에서 상위 홈페이지의 95.9%가 WCAG 기준을 통과하지 못했고, 페이지당 평균 오류가 56.1개로 전년보다 10.1% 늘었어요. 6년 만에 처음으로 수치가 나빠진 거예요.
왜 이런 자잘한 수정이 안 밀리고 아예 멈춰버릴까요. 티켓 기반 워크플로우의 구조적 한계 때문이에요. 디자이너가 "이 화면 대비 좀 고쳐주세요"라고 올리면, 엔지니어는 딱 그 화면만 봐요. 근데 실제로는 그 날짜 선택기가 전시 페이지, 이벤트 페이지, 회원가입 페이지 — 세 군데에서 재사용되는 공유 컴포넌트인 경우가 많아요. 한 곳만 고치면 나머지 두 곳은 그대로 깨진 채로 남고, 이 사실을 아는 사람은 코드를 직접 열어본 사람뿐이에요.
접근성 부채는 그냥 쌓이기만 하는 게 아니라 이자가 붙어요. 접근 불가능한 컴포넌트 하나로 만든 화면이 늘어날수록, 나중에 담당자가 바뀌면 맥락을 잃어서 수정이 더 느려지고 위험해져요. 사용자가 늘수록 같은 장벽에 부딪히는 사람도 늘고요. 백로그에 방치된 버그 하나의 비용이 개발 단계에서 잡았을 때보다 2,480달러 더 든다는 분석도 있어요. 방치하는 쪽이 결국 더 비싸다는 얘기예요.
피그마가 실험한 방식 — MOSF 사례
피그마가 소개한 사례는 가상의 박물관 사이트 'Museum of Speculative Futures(MOSF)'예요. 피그마 에이전트가 첫 방문자, 회원, 스크린리더 사용자 같은 합성 페르소나로 사이트를 미리 테스트하면서 문제를 찾아냈어요 — 불명확한 네비게이션 라벨, 대비가 낮은 날짜 선택기, 존재감이 희미한 CTA 버튼.
여기까진 흔한 QA 리포트예요. 다른 건 그다음이었어요. 디자이너가 GitHub 저장소를 Figma Make에 연결하고, 현재 사이트 코드에서 새 브랜치를 만들었어요. 그리고 그 날짜 선택기가 세 페이지에서 쓰이는 공유 컴포넌트라는 걸 코드 레벨에서 직접 확인했고요. 한 곳만 고치는 대신, 컴포넌트 자체를 한 번에 수정했어요.
| 기존 티켓 워크플로우 | Figma Make PR 워크플로우 | |
|---|---|---|
| 문제 범위 파악 | 화면 단위로만 확인 가능 | 코드 레벨에서 공유 컴포넌트까지 발견 |
| 대기 시간 | 분기 단위로 백로그 적체 | 하루 안에 배포 |
| 접근성 명세 | 티켓 텍스트로 설명, 누락 잦음 | aria-label·포커스 순서를 PR에 직접 주석 |
| 변경 기록 | 티켓과 코드가 분리돼 맥락 소실 | PR 하나에 의도·리뷰·결정이 모두 남음 |
수정 자체보다 눈여겨볼 부분은 팀 리뷰 단계에서 붙는 주석이에요. 디자이너가 작업물을 팀에 넘길 때, aria-label을 지정하고, 스크린리더가 읽는 텍스트와 화면에 보이는 텍스트를 일치시키고, CTA까지 도달할 수 있도록 포커스 순서를 고치고, 빈 상태(empty state)에 스크린리더용 공지 문구를 추가했어요. 이 모든 게 코드 옆에 주석으로 남았고요.
그다음이 PR이에요. 디자이너가 Make에서 GitHub로 직접 PR을 올리고, 엔지니어가 승인해서 병합했어요. 피그마 블로그의 표현을 빌리면 "PR은 무엇이 바뀌었는지뿐 아니라 그 변경이 어떻게 일어났는지의 기록이 된다"는 거예요. 원래대로면 한 분기를 백로그에서 버텼을 수정 건이 하루 만에 배포됐어요.
이게 왜 지금 가능해졌나
이 워크플로우는 진공에서 나온 게 아니에요. 피그마는 2026년 6월 Config 콘퍼런스에서 '코드 레이어' 기능을 발표하면서 "코드를 다른 디자인 소재처럼 다룬다"는 방향을 공식화했어요. 디자인 레이어를 클릭 한 번이나 프롬프트로 인터랙티브 코드 레이어로 바꾸고, 기존 GitHub 저장소를 Figma Design으로 가져와 디자인 레이어와 실제 Git 코드를 양방향으로 연동할 수 있게 됐고요. Figma Make 자체는 5월 말 공개돼, 디자이너가 캔버스를 벗어나지 않고도 실제 프로덕션 코드베이스를 시각적으로 편집하고, 브랜치를 만들고, PR을 여는 것까지 지원해요.
다만 이건 "디자이너가 이제 엔지니어가 된다"는 얘기가 아니에요. 피그마 스스로도 디자이너가 엔지니어가 되거나 엔지니어가 디자이너가 될 필요 없이 각자 자리에서 코드에 접근하는 걸 목표로 설명해요. 아키텍처를 다시 짜는 큰 작업은 여전히 엔지니어 몫이고, 디자이너는 이미 있는 컴포넌트 안에서 정제(refinement) 작업을 소유하는 식으로 역할이 나뉘어요. PR을 자동 병합하지 않고 엔지니어 승인을 거치게 한 것도 같은 맥락이고요.
우리 팀에 적용한다면
- 먼저 백로그를 훑어보세요
몇 분기째 안 움직이는 접근성 티켓 중 "화면 단위로 작게 보이지만 공유 컴포넌트일 가능성이 있는" 항목을 골라내세요. 첫 실험 대상으로 적합해요. - 저장소 연결 권한부터 정리하세요
디자이너가 GitHub 브랜치를 만들 수 있게 하려면 리포지토리 접근 권한, 브랜치 보호 규칙, PR 승인 라인을 먼저 팀과 합의해야 해요. 권한 없이 도구만 깔면 못 씁니다. - 디자이너 몫과 엔지니어 몫을 미리 선 그으세요
컴포넌트 재사용 범위를 넘는 아키텍처 변경은 엔지니어가, 스타일·라벨·포커스 순서 같은 정제 작업은 디자이너가 — 이 경계를 워크플로우 시작 전에 문서화하세요. - PR에 접근성 주석을 표준 항목으로 넣으세요
aria-label, 스크린리더 텍스트 일치 여부, 포커스 순서, 빈 상태 안내 문구 — 이 네 가지를 PR 템플릿 체크리스트로 만들면 리뷰가 빨라져요. - 작은 사례로 먼저 검증하세요
전사 롤아웃 전에 MOSF처럼 하나의 제품 영역에서 접근성 수정 한 건을 끝까지 배포해보고, 걸린 시간과 리뷰 부담을 측정한 뒤 확대하세요.
