지난 2개월 간 틈틈이 째깍악어 디자인 시스템의 접근성을 개선해왔습니다. 아직 해결해야 할 과제들이 많지만, 이 글을 통해 그간의 여정과 고민을 기록하고자 합니다. 접근성이란 주제에 대한 인식을 조금이나마 높이는 계기가 되길 바랍니다.

• 결과로 먼저 이야기하기
  • 🔗 개인적으로 정리한 개선 기록들
  • 🔗 스토리북
  • 🔗 (구)디자인시스템
  • 🔗 (신)디자인시스템

디자인 시스템이 없다구요?

2023년 11월의 마지막날, 나는 째깍악어의 프론트엔드 팀에 합류했다. 째깍악어의 프론트엔드 코드를 분석하며 적잖이 큰 충격을 받았다. 복잡한 구조와 노후화된 기술은 둘째치고, 조직 내 디자인 시스템이 없다는 것이 제일 황당했다. 기획서와 디자인 시안을 기준 삼아 화면을 직접 구성했었고, 이로 인해 반복되는 UI 구현과 일관성 문제들이 여기저기서 발견되었다. 째깍악어의 긴 업력에 비해서 결과물이 너무 아쉽다는 생각과, 또 그럼에도 지금까지 문제없이 운영되었다는 것이 경이롭기까지 했다.

비슷한 시기에 팀에 합류한 프론트엔드 개발자 한 분도 위클리에서 비슷한 이야기를 했다. 우리는 그날로 자연스럽게 디자인 시스템 구축에 착수했다. 공교롭게도 비슷한 시기에 프론트엔드 리더 자리가 부재 상태로 바뀌었고, 부족하지만 감사하게도 내가 프론트엔드 리드로 낙점되었다. 무거운 책임감을 이고 그렇게 나와 우리 팀은 디자인 팀과 함께 디자인 시스템을 구축해나갔다. 지금 시점에 생각해보면 어쩌면 우리가 구축한 건 디자인 시스템이 아니라 프론트엔드 팀의 개발 방식일지도 모르겠다.

3개월의 프리릴리즈 기간 이후 대망의 7월 중순, 우리의 디자인 시스템 1.0.0이 릴리즈되었다. 어쩌면 당연한 것일지도 모르는 작업과 결과물에 많은 찬사를 받았다. 특히 기획팀과 디자인팀에서 감사하게도 큰 박수를 쳐주셨다.

디자인 시스템 배포를 알리다

외부 의존성도 최소화하고, 트리셰이킹도 지원하고, commonJS와 ESM 양쪽도 모두 대응하고, 빌드-배포 자동화까지 챙겼다만 나는 약간 아쉬운 지점이 하나 있었다. 내가 느끼기에 접근성에 대한 컴포넌트 간 편차가 꽤 존재했다. 구성원간 접근성에 대한 이해도도 달랐고, 무엇보다 접근성 가이드도 없었기 때문이었다. 이후로 서비스의 마이그레이션 작업이 밀려들면서 자연스럽게 접근성에 대한 고민은 깊숙한 곳에 꾹꾹 담아둘 수 밖에 없었다.

접근성이라는 아픈 손가락

디자인 시스템을 우리 서비스에서 사용해나가면서 우리는 확장성과 안정성이라는 개발 방향성을 확고히했다. 실제로 우리는 꽤 많은 성과를 얻을 수 있었다. 마이그레이션은 더 안정적으로 진행됐고, 컴포넌트를 중심으로 팀 내외의 커뮤니케이션 구조도 정비됐다. 하지만 시간이 지날수록 한 가지 생각이 점점 또렷해졌다. ‘이제는 확장성과 안정성만으로는 부족하다’는 생각이었다. 그보다 더 중요한 방향, 즉 ‘사용자 경험’과 ‘사용 가능성’의 영역으로도 시야를 넓혀야 한다는 생각이 맴돌았다. 그리고 그 고민의 중심에는 웹 접근성이 있었다. 그리고 2025년 올해, 나는 다시 접근성이라는 골칫덩이를 끄집어냈다.

1. 이런 생각을 하게 된 데는 나 개인의 경험과 고민도 큰 영향을 줬다. 지난 몇년간 개발자로 일하면서 나는 줄곧 “내가 누구에게 어떤 도움을 주고 있는가”, “나는 어떤 개발자가 되고 싶은가” 라는 질문을 스스로에게 던져왔다. 내 결론은 언제나 같았던 것 같다 — 도움이 되는 개발, 그리고 선한 영향력을 끼치는 개발자가 되고 싶었다. 이 길이 즐겁고 의미 있었기에, 지금까지 개발자로 살아올 수 있었던 것 같다는 생각을 했다.

2. ‘째깍악어’는 ‘아동 복지’라는 사회적 의미를 품은 도메인을 다룬다. 그렇기에 나는 이 조직에서의 개발은 단순한 제품 개발이 아니라, 사회적 기여의 연장선이라고 생각했다. 그리고 프론트엔드 개발자 입장에서 이 사회적 기여를 구체화할 수 있는 실천 중 하나가 바로 웹 접근성 개선이었다.

3. 웹 접근성은 단순한 기술의 문제가 아니다. 그것은 제품을 설계하는 철학과 태도, 조직이 사용자를 어떻게 바라보는가에 대한 관점의 문제다. 나는 이를 ‘선택 사항’이 아니라, 프론트엔드 개발의 필수 지점으로 자리 잡게 해야 한다고 느꼈다. 실제로 국내외의 많은 서비스들—심지어는 기술력이 높다고 평가받는 곳들조차—접근성에 대한 고려가 부족한 경우가 많았고, 이는 우리가 차별화할 수 있는 기회이자 의무라고 판단했다.

   이러한 일련의 고민 끝에 나는 한발 물러나 우리 디자인 시스템의 접근성을 다시 챙겨보기로 마음먹었다. 그리고 6월 첫주, 우리 팀이 관리하던 프론트엔드 라이브러리들을 모노레포로 관리하기로 결정하면서 자연스럽게 디자인 시스템 라이브러리도 이관이 필요했고, 이참에 디자인 시스템의 접근성 작업도 같이 챙겨가기로 했다.

개선해 나아가다

우리 팀의 상황에서는 접근성에 대한 전문 지식이나 경험을 보유한 인원이 많지 않았다. 내가 꺼낸 주제이기도 했고, 내가 그나마 관심과 경험이 있었다. 그래서 이 프로젝트는 자연스럽게 프론트엔드 리드인 내가 중심을 잡고 진행하게 되었다. 물론 혼자서 모든 걸 결정한 것은 아니었다. 대신 접근성의 일관성을 확보하는 게 우선이었기에, 내가 직접 모든 컴포넌트를 개선하고 PR을 작성한 뒤 나머지 팀원들이 리뷰와 피드백을 자유롭게 주고받는 구조로 개선 작업을 진행했다. 작업 속도와 코드 품질을 모두 확보할 수 있는 최적의 방식이라고 판단했다.

1. 개발에 앞서 우선 접근성에 대한 기준을 다시 정립했다. 단순히 WCAG의 요약본만 읽고 접근성을 고려한다거나 지침 통과를 목적으로 하는 개선 작업이 아니라 실제 사례와 구현 가이드를 기반으로 제대로 설계하고자 했다. 그래서 🔗WCAG 2.2 가이드라인을 읽어보고, 🔗WAI-ARIA Practices(APG) 를 집중적으로 참고했다. 애플의 🔗HIG(Human Interface Guidelines) 등도 참고 자료로 삼았다. 실무적으로는 MUI(Material UI)의 접근성 구현 방식도 종종 참고했는데, 실제 코드 레벨에서 참고할 수 있는 좋은 예제들이 많았다.

2. 실서비스 사례에서도 영감을 얻고자 했다. 특히 구글과 에어비앤비의 페이지들에서 많은 힌트를 얻었다. 에어비앤비가 접근성에 강하다는 건 알고 있었지만, 키보드 내비게이션, 스크린리더 대응, 명확한 역할 정의 등에서 깊은 수준의 고민이 담겨있는지 몰랐다. 특히 키보드 인터랙션에서 깊은 생각들이 녹아들어 있었는데, 거의 모든 페이지가 키보드만으로도 불편함 없이 탐색과 조작이 가능했다. 실제로 DatePicker 개선 작업에는 에어비앤비의 키보드 인터랙션에서 크게 영감을 받았다(2편에서 기술될 예정!).

3. 디자인 팀의 도움도 많이 받았다. 크로매틱을 통해 지속적으로 배포한 작업물들에 대해 디자인, UX 피드백을 진행해주셨고(내 압박을 못버티신듯!), 특히 적절한 명암비에 대한 기준을 정의하는 데 결정적인 역할을 해주셨다(2편에서 기술될 예정!).

크로매틱 & 웹훅 통해서 피드백 종용하기

젠틀하게 메시지로 피드백 종용하기

4. 기본적인 접근성 검증 도구로는 🔗Storybook의 addon-a11y 애드온을 사용했다. 기본적인 오류들을 잡기에는 충분했다. 내부적으로 axe-core를 사용하니 안정성도 보장되었다. 물론 테스트 자동화를 위해서는 axe-core 이 필요하긴 한데, 접근성 테스트는 아직 시각적 테스트에 크게 의존한다고 생각한다. 스크린리더가 읽어주는 문장까지 테스트를 자동화하는 것이 아직은 불가능하지 않은가!(혹시 가능하면 알려주세요)

5. macOS의 VoiceOver를 직접 켜고 컴포넌트를 하나하나 테스트했다. Window 환경에서는 NVDA 스크린리더도 함께 활용했다. 국내에는 Sense Reader 스크린리더의 사용자가 대다수라고 알고 있는데, 여건상 센스 리더는 활용이 어려웠다.

대부분의 개선 작업은 퇴근 이후나 주말 시간을 활용해 조금씩 꾸준히 이어갔다. 그렇게 약 두 달간 총 36개의 컴포넌트를 접근성 기준에 맞게 수정했고, 개발 도중에 필요성을 느껴 일부 접근성 유틸리티 컴포넌트(예: Menu를 열어주는 MenuButton 등)도 새롭게 추가하게 되었다.

이 글에서는 구체적인 개선점들을 나열하지는 않고, 인상 깊었던 일부 컴포넌트와 작업들에 대해서만 기록해보려고 한다. 혹시 컴포넌트들의 개선점을 확인해보고자 하는 독자를 위해 개인적으로 정리한 🔗노션 링크와 🔗스토리북 링크를 남겨둔다. 실제 서비스에 적용한 형태와 스토리북의 컴포넌트는 다를 수 있으니 참고바란다.

2편에서 계속...
2편에서는 실제 개선 사례와 추후 작업들을 중심으로 이야기를 이어가겠습니다.