JS 토글을 다 짜고 나서야 details 태그를 발견했습니다
FAQ 페이지 작업을 처음 맡았을 때, 저는 JavaScript로 토글 기능을 직접 짰습니다. 기능은 됐지만 코드가 생각보다 많아졌고, 항목이 늘어날 때마다 JS까지 함께 손봐야 했습니다. 그러다 HTML 레퍼런스를 뒤지다 details 태그를 발견했고, 솔직히 처음엔 '이게 진짜 되나?' 싶었습니다. 테스트해보니 JS 한 줄 없이 열리고 닫혔습니다. 그 허탈함이 아직도 기억납니다.
이 글을 쓰면서 동시에 드는 생각이 있습니다. details 태그가 HTML에 이미 있는데 왜 몰랐냐는 자책보다, 왜 이런 기능이 잘 알려져 있지 않은지가 더 흥미로운 질문입니다. HTML 입문 튜토리얼 대부분이 div와 span, 기본 입력 요소에 집중되어 있고 details처럼 인터랙티브한 시맨틱 요소는 후반부에 짧게 지나치거나 아예 다루지 않는 경우가 많습니다. 학습 자료의 구성 방식이 놓치는 것들을 만들어냅니다.
JS 없이 토글이 된다고?
FAQ 페이지 의뢰를 처음 받았을 때, 저는 당연히 ul 태그로 질문과 답변을 쭉 나열했습니다. 결과물을 보니 페이지 스크롤이 끝없이 이어졌고, 클라이언트도 "한눈에 보기 어렵다"고 했습니다. 그래서 querySelector로 요소를 잡고 classList.toggle을 써서 토글 기능을 붙였습니다. querySelector란 CSS 선택자 문법으로 HTML 요소를 찾아오는 DOM API이고, classList.toggle은 클릭할 때마다 특정 CSS 클래스를 켜고 끄는 동작을 반복 실행하는 메서드입니다.
기능은 작동했지만 코드가 생각보다 길어졌고, 항목이 추가될 때마다 JS도 함께 수정해야 하는 번거로움이 따라왔습니다. 그 상태로 몇 달을 쓰다가 HTML 레퍼런스를 뒤지던 중 details 태그를 처음 발견했습니다. 브라우저에서 열어봤더니 summary 앞에 삼각형이 자동으로 생기고, 클릭하니 내용이 열리고 닫혔습니다. JavaScript 한 줄 없이. 그 순간의 허탈함은 뭔가 표현하기 어렵습니다. 기존에 짜둔 토글 코드 전체가 불필요한 수고였다는 기분이랄까요.
이때 드는 비판적인 생각이 있습니다. 웹 개발 학습 경로가 종종 "JavaScript로 해결하라"는 방향으로 먼저 안내하는 경우가 있습니다. 그 결과 HTML 자체에 내장된 기능을 뒤늦게 발견하거나 아예 모르는 채로 넘어가는 일이 생깁니다. JavaScript가 나쁜 게 아니라, HTML 네이티브 기능을 먼저 검토하는 습관이 없었다는 게 문제였습니다.
details 태그는 HTML5 네이티브 요소입니다. 여기서 네이티브 요소란 브라우저가 별도의 JavaScript 없이 자체적으로 동작을 처리하는 기본 내장 기능을 말합니다. 내부에 summary 태그가 필수로 들어가며, summary가 클릭 가능한 제목이 되고 나머지 내용이 토글됩니다. open 속성을 추가하면 페이지 진입 시 기본 펼침 상태로 시작할 수 있어서, "자주 묻는 1번 항목은 처음부터 열어두고 싶다"는 요구사항이 있을 때 CSS나 JS 없이 처리가 됩니다.
아코디언과 SEO, 실제로 어떻게 쓰이나
details 태그에서 가장 실용적인 기능 중 하나가 name 속성을 이용한 배타적 아코디언입니다. 배타적 아코디언이란 여러 항목 중 하나를 열면 나머지가 자동으로 닫히는 방식으로, radio 버튼의 동작 원리와 동일합니다. 동일한 name 값을 여러 details에 지정하면 브라우저가 하나만 열린 상태를 유지해줍니다.
직접 써봤는데, Chromium 계열 브라우저에서는 깔끔하게 작동했습니다. 다만 일부 환경에서 예상과 다르게 동작한 경험이 있어서, 실무 적용 전 반드시 브라우저 호환성 테스트를 먼저 합니다. "네이티브니까 무조건 안전하다"는 생각은 위험합니다. 네이티브 기능도 스펙 버전에 따라 지원 여부가 다릅니다. 특히 name 속성을 이용한 배타적 아코디언 기능은 비교적 최근 스펙이라 레거시 환경이 포함된 프로젝트라면 주의가 필요합니다.
SEO 측면에서도 details 태그는 강점이 있습니다. 접혀 있는 콘텐츠도 검색 엔진이 인덱싱한다는 점이 핵심입니다. 인덱싱이란 검색 엔진 크롤러가 페이지 내용을 읽어 검색 결과 데이터베이스에 등록하는 과정을 말합니다. Google Search Central에 따르면, FAQ 페이지에 구조화 데이터 마크업을 적용하면 검색 결과에 리치 결과로 표시될 수 있습니다. 리치 결과란 일반 파란 링크 대신 질문과 답변이 검색 결과 페이지에서 바로 펼쳐져 보이는 형태로, 클릭률 향상에 직접적인 영향을 줍니다.
접근성 면에서도 details 태그는 기본기가 탄탄합니다. 키보드 Tab, Enter, Space로 조작이 가능하고, 스크린리더가 펼침·접힘 상태를 자동으로 인식합니다. JS로 직접 구현했을 때는 키보드 접근성까지 신경 쓰느라 코드가 더 복잡해졌던 기억이 있어서, 이 부분은 특히 체감 차이가 컸습니다. 키보드 접근성은 따로 챙기려 하면 꽤 번거로운 작업인데, details 태그는 그걸 별도 작업 없이 충족합니다.
실전에서 쓰기 전 반드시 확인할 것들
details 태그가 편리한 건 맞지만, 디자인 자유도 면에서는 한계가 뚜렷합니다. summary 앞에 자동으로 생기는 삼각형 화살표를 제거하거나 커스텀 아이콘으로 교체하려면 결국 CSS를 써야 합니다. 브라우저마다 기본 스타일이 달라서 크로스브라우저 통일 작업도 필요합니다. 디자이너가 세밀하게 디자인을 잡아온 프로젝트라면 오히려 JS 방식보다 손이 더 갈 수도 있습니다.
이 부분에서 제가 겪은 경험을 하나 더 이야기하자면, details 태그를 도입한다고 결정한 후에 디자인 팀에서 기본 삼각형 아이콘 대신 커스텀 아이콘을 요청했습니다. 그 과정에서 브라우저별 기본 스타일 초기화 작업이 생각보다 까다로웠고, 결과적으로 JS 방식보다 CSS 작업이 더 많아지는 아이러니가 생겼습니다. "네이티브를 쓰면 손이 덜 간다"는 기대가 항상 맞지는 않습니다.
실무 적용 전 확인해야 할 사항들을 정리하면 이렇습니다. 타깃 브라우저와 운영 환경을 먼저 파악해야 합니다. 레거시 브라우저가 포함된 프로젝트라면 name 속성 아코디언 기능은 대체 방안을 검토해야 합니다. 디자인 요구사항을 확인해서 summary 기본 스타일을 초기화하고 크로스브라우저 CSS를 별도로 작성해야 하는지 판단해야 합니다. FAQ 리치 결과를 노리는 페이지라면 schema.org의 FAQPage 마크업을 함께 적용하는 것이 유리합니다. 접근성 요건이 있는 프로젝트라면 details 태그의 네이티브 키보드 지원이 오히려 강점이 될 수 있으므로, 이를 명시적으로 활용 근거로 삼을 수 있습니다.
처음 details 태그를 발견했을 때 "이걸 몰랐던 게 부끄럽다"는 생각보다, "이런 기능이 이미 HTML에 있는데 왜 아무도 먼저 얘기해주지 않았지?"라는 생각이 먼저 들었습니다. 네이티브 기능이라고 해서 무조건 최선이라는 건 아닙니다. 프로젝트 환경과 디자인 요구사항, 타깃 브라우저를 먼저 확인한 뒤 적용 여부를 결정하는 것이 맞습니다.
details 태그를 아직 써본 적 없다면, 간단한 테스트 파일 하나만 만들어보시길 권합니다. 특히 FAQ 페이지 작업이 자주 들어오는 분이라면, 한 번만 써봐도 "왜 진작에 안 썼지"라는 생각이 들 가능성이 높습니다. 저처럼 허탈하게요.
참고:
MDN Web Docs – details
MDN Web Docs – summary
Google Search Central – FAQ 리치 결과
Can I Use – details