들어가며: 아코디언 아이콘, 그냥 아무거나 쓰면 안 되는 이유
아코디언(Accordion)은 웹과 앱에서 가장 흔하게 쓰이는 UI 패턴 중 하나입니다. 그런데 정작 "접기/펼치기"를 표시하는 아이콘은 팀마다 제각각입니다. 캐럿(▼), 쉐브론(⌄), 화살표(→), 삼각형(▶), 플러스/마이너스(+/−)… 디자이너마다 선호가 다르고, 개발자는 디자인 시안을 그대로 받아 구현하는 경우가 많죠.
문제는 이 아이콘 선택이 사용자의 기대 행동을 바꾼다는 점입니다. 아이콘이 없으면 사용자는 해당 항목을 "새 페이지로 이동하는 링크"로 인식합니다. 반면 커스텀 아이콘은 "아코디언이 열린다"는 신호를 명확히 주지 못해 혼란을 유발합니다. 이 글에서는 실제 사용성 리서치 결과를 바탕으로, 어떤 아이콘이 가장 안전한 선택인지 정리해 드리겠습니다.
이 글은 Smashing Magazine의 아코디언 아이콘 사용성 연구를 근거자료로 재구성했습니다.
핵심 개념: 아이콘별 사용자 기대 행동 분석
아이콘을 고를 때 가장 중요한 기준은 **"이 아이콘이 사용자에게 어떤 행동을 유도하는가"**입니다. 리서치 결과를 정리하면 다음과 같습니다.
1. 아이콘 없음 = "페이지 이동" 기대
아이콘이 전혀 없으면 사용자는 메뉴 항목을 탭했을 때 새 페이지로 이동할 것이라고 기대합니다. 아코디언이 열릴 것이라고 생각하지 않는다는 뜻이죠. 따라서 아코디언을 쓰려면 아이콘이 반드시 필요합니다.
2. 화살표(▶)와 스플릿 버튼의 함정
오른쪽을 향하는 화살표(▶)는 "새 페이지로 이동"이라는 기대와 연결되지 않습니다. 같은 아이콘이 아래를 향한다고 해서(▼) "아코디언이 열린다"는 의미도 명확하지 않죠.
특히 스플릿 버튼(Split Button) 은 피해야 합니다. 텍스트 라벨은 페이지로 이동하고, 아이콘은 아코디언을 여는 구조인데, 사용자는 이 둘을 구분하지 못하고 오클릭을 반복합니다. 대신 메인 카테고리를 탭하면 아코디언이 열리고, 카테고리 페이지로 가려면 메뉴 내부의 링크를 통해 이동하게 만드는 것이 훨씬 안정적입니다.
3. +/− 와 ↓/↑ : 이해되지만 오해 소지 있음
플러스/마이너스(+/−)와 위아래 화살표(↓/↑)는 직관적으로 이해되지만 의미가 과부하(overloaded) 되어 있습니다.
+: 저장, 장바구니 담기, 확대 등 다양한 의미로 해석될 수 있음↓/↑: 스크롤, 슬라이드, 다음 항목 찾기, 페이지 내 특정 위치로 이동 등으로 오해될 수 있음
특히 다단계 내비게이션에서 여러 레벨이 동시에 열려 있을 때 + 아이콘은 혼란을 가중시킵니다.
4. 캐럿(▼)이 가장 안전한 이유
결론적으로 캐럿(▼, 아래를 향하는 삼각형) 이 기본값으로 가장 안전합니다. 상호작용 시 위를 향하는 캐럿(▲)이나 옆을 향하는 캐럿(▶)으로 바꾸는 방식이 일반적이며, 사용자 기대와 가장 잘 맞습니다.
<!-- 아코디언 기본 구조 예시: 캐럿 아이콘 사용 -->
<button class="accordion-trigger" aria-expanded="false" aria-controls="panel-1">
<span>카테고리 이름</span>
<!-- 캐럿 아이콘: 펼침 상태에 따라 회전 -->
<svg class="caret" viewBox="0 0 24 24" aria-hidden="true">
<path d="M6 9l6 6 6-6" />
</svg>
</button>
<div id="panel-1" class="accordion-panel" hidden>
<a href="/category/page">카테고리 페이지로 이동</a>
</div>
/* 캐럿 회전으로 상태 표시 */
.accordion-trigger[aria-expanded="true"] .caret {
transform: rotate(180deg);
}
.caret {
transition: transform 0.2s ease;
}
위 코드처럼 aria-expanded 속성과 캐럿 회전을 연동하면 접근성과 시각적 피드백을 동시에 확보할 수 있습니다.
주의사항 및 심화 팁
이 접근법의 한계
캐럿이 "가장 안전한" 선택이라는 것은 절대적인 정답이 아니라는 점을 짚고 넘어가야 합니다. 이 결론은 특정 사용성 리서치 맥락에서 도출된 것이며, 다음과 같은 경우에는 다른 선택이 나을 수 있습니다.
- 모바일 네이티브 앱: 플랫폼 가이드라인(iOS HIG, Material Design)을 우선 따르세요. iOS는 쉐브론(›)을, Material은 확장 아이콘을 권장합니다.
- 다크 패턴이 우려되는 커머스:
+아이콘이 "장바구니 담기"로 오해될 수 있는 맥락이라면 캐럿이 더 안전합니다. - 다단계 대형 메뉴: 캐럿만으로는 깊이를 표현하기 어려울 수 있어, 들여쓰기와 조합해야 합니다.
실무 체크리스트
- 링크와 아코디언을 분리하라: 하나의 버튼이 두 가지 일을 하게 만들지 마세요. 스플릿 버튼은 오클릭의 온상입니다.
- 아이콘 없이 링크만 표시하려면 밑줄을 써라: 링크임을 나타내는 가장 확실한 방법은 밑줄입니다. 화살표 아이콘은 오히려 혼란을 줍니다.
- 접근성 속성을 반드시 연결하라:
aria-expanded,aria-controls,hidden속성을 상태와 동기화하세요. - 아이콘은 장식이지 정보가 아니다: 스크린 리더 사용자를 위해
aria-hidden="true"를 붙이고, 상태는aria-expanded로 전달하세요.
한국 개발 생태계에서의 적용 맥락
국내 SI·에이전시 환경에서는 디자이너가 전달한 시안의 아이콘을 그대로 구현하는 경우가 많습니다. 하지만 시안 단계에서 "이 아이콘이 사용자에게 어떤 행동을 유도하는가"를 함께 논의하는 것이 중요합니다. 특히 공공기관·금융권 프로젝트에서는 접근성 인증(KWCAG) 요건 때문에 aria-expanded 동기화가 필수이므로, 아이콘 선택보다 접근성 마크업이 우선입니다. 디자인 리뷰 때 이 글의 체크리스트를 공유해 보세요.
결론: 단순함이 답이다
아코디언 아이콘 선택의 핵심은 "하나의 버튼은 하나의 일만 하게 하라" 는 원칙으로 귀결됩니다.
- 기본값은 캐럿(▼) 을 쓰고, 상태에 따라 회전시키세요.
- 대안이 필요하면 +/− 도 괜찮지만, 의미 과부하를 인지하고 쓰세요.
- 스플릿 버튼은 피하세요. 텍스트와 아이콘이 서로 다른 동작을 하면 사용자는 반드시 실수합니다.
- 링크는 밑줄로 표시하세요. 화살표 아이콘으로 링크를 꾸미지 마세요.
결국 "더 단순한 것이 더 낫다(simpler is better)"는 오래된 격언이 여기서도 통합니다. 아이콘 하나 때문에 사용자가 헤매게 만들지 마세요.
다음 단계 학습 방향
- 접근성 심화: WAI-ARIA Authoring Practices의 Accordion 패턴을 읽어보세요. 키보드 인터랙션(Enter, Space, Arrow keys)까지 다룹니다.
- 디자인 시스템 구축: 캐럿·쉐브론·화살표를 컴포넌트 토큰으로 관리하면 팀 내 일관성을 유지할 수 있습니다.
- 사용성 테스트: 5명만 대상으로 해도 아이콘 오해 여부를 빠르게 검증할 수 있습니다.