직접 만들지 마라

출처: Hacker News

작성자 Susam Pal, 2026년 5월 23일

이 글은 현대 웹 디자인 관행에 대한 불평입니다. 하지만 그 전에 암호학 세계에서 익숙한 원칙 하나를 떠올려 보겠습니다. 소프트웨어 개발자, 특히 보안에 민감한 시스템을 다루는 사람들 사이에는 잘 알려진 격언이 있습니다: 직접 암호를 구현하지 말라. 이는 아무도 암호 코드를 작성하면 안 된다는 뜻이 아니라, 일반적인 프로덕션 소프트웨어가 사용자들의 민감한 데이터를 보호할 때, 널리 검증되지 않은 사적인 구현에 의존해서는 안 된다는 의미입니다. 가능한 한 검증된, 검증된 소프트웨어 패키지나 도구를 사용해야 합니다.

다행히도 오늘날은 직접 암호를 구현하지 않고, 동료 검토를 거쳐 시간의 시험을 통과한 암호 알고리즘과 패키지를 사용하는 것이 표준 산업 관행이 되었습니다. 20년 전만 해도 상황이 달랐습니다. 저는 경력 초기에 초기화 벡터가 잘못되었거나, 예측 가능한 키스트림이 발생하거나, 평문이 암호문에 부분적으로 누출되는 등 결함이 있는 자체 제작 RC4 구현을 여러 차례 보았습니다. 이는 사용자들의 민감한 데이터를 위험에 빠뜨렸습니다. 하지만 오늘날 주요 전자상거래 사이트나 은행은 웹 서비스에 자체 암호를 사용하지 않습니다. 실제로 결제, 의료, 개인 데이터 처리와 같은 규제 분야에서는 강력한 암호화 요구사항을 위반하게 되면 막대한 금전적 벌금을 물게 될 수도 있습니다.

웹사이트 디자인은 분명히 암호학과는 다릅니다. 깨진 스크롤 바는 깨진 암호화 스킴과 같은 종류의 실패가 아닙니다. 하지만 웹 디자인에도 비슷한 격언이 있었으면 좋겠습니다. 브라우저가 이미 잘 해내고 사용자가 매일 의존하는 기능을 직접 구현하는 것은 피해야 한다고 생각합니다. 여기 그런 “X”들의 목록을 제시합니다.

• 직접 페이지 스크롤을 구현하지 마세요.
• 직접 링크 네비게이션을 구현하지 마세요.
• 직접 텍스트 선택을 구현하지 마세요.
• 직접 컨텍스트 메뉴를 구현하지 마세요.
• 직접 복사·붙여넣기를 구현하지 마세요.
• 직접 비밀번호 입력 필드를 구현하지 마세요.
• 직접 날짜 선택기를 구현하지 마세요.

물론 직접 “X”를 구현해야 하는 정당한 상황도 있습니다. 여기서는 여러분이 직접 구현하면 안 되는 경우와, 그렇게 할 경우 사용자 경험이 어떻게 악화될 수 있는지에 초점을 맞추겠습니다. 저는 절대 아무도 스스로 무언가를 만들면 안 된다고 말하는 것이 아닙니다. 저 역시 창의적인 컴퓨팅을 많이 하고 가끔 재미있는 도구를 개발하는 사람으로서, 직접 무언가를 만드는 것을 크게 옹호합니다. 하지만 사람들이 업무를 처리하기 위해 사용해야 하는 진지한 웹사이트의 UI 기능을 개발할 때는, 어떤 화려한 기능을 웹사이트에 넣고 무엇을 배제할지에 대해 소프트웨어 개발 커뮤니티가 좀 더 보수적이었으면 합니다. 저는 UX 전문가가 아니라는 점을 명심해 주세요. 따라서 여기서 하는 말은 어떤 권고도 아닙니다. 다만 저는 웹 사용자이며, 사용자 입장에서 현대 웹 디자인 패턴 중 몇 가지가 답답하다고 느꼈습니다. 이 글은 웹 사용자의 한탄일 뿐, 디자인 가이드가 아닙니다.

위에서 언급한 것들 중 가장 저를 괴롭히는 것은 웹사이트의 맞춤형 스크롤 동작입니다. 저는 마우스, 터치패드, 키보드 입력에 따라 페이지 스크롤이 어떻게 반응하는지에 익숙합니다. 브라우저의 기본 스크롤 동작을 여러분이 만든 구현으로 덮어쓰면 페이지가 ‘깨집니다’. 스크롤 속도가 너무 느리거나 너무 빨라지고, 키보드 스크롤이 작동하지 않을 수도 있습니다. 저는 전혀 생각하지 않던, 익숙한 동작을 전혀 새로운, 생각해야 하는 동작으로 바꾸는 겁니다.

맞춤형 링크 네비게이션도 저의 또 다른 불만입니다. 웹 브라우저는 이미 링크를 아주 잘 처리합니다. 이것이 바로 웹 브라우저가 존재하는 이유이기도 합니다. 링크를 따라가는 것은 브라우저의 주된 기능이죠. 이 동작을 건드릴 필요가 없습니다. 꼭 필요하다고 생각한다면, 달성하려는 목표와 일반적인 링크 네비게이션을 방해할 정도로 정말 중요한가를 다시 한 번 고민해 보세요. 제가 발견한 가장 큰 문제는 GitHub에서 나타납니다. GitHub에서 파일 링크나 이슈 링크를 클릭하면, 자바스크립트로 구현된 방대한 기능이 작동해 클릭을 처리합니다. 직접 확인하고 싶다면 Firefox나 Chrome에서 GitHub 프로젝트 페이지를 열고 F12로 개발자 도구를 연 뒤, ‘Debugger’ 혹은 ‘Sources’ 탭에서 오른쪽 사이드바의 ‘Event Listener Breakpoints’를 찾아 ‘Mouse’를 펼친 뒤 ‘click’을 선택하세요. 그런 다음 GitHub의 링크를 클릭하면 무슨 일이 일어나는지 확인할 수 있습니다.

저만 그런 것이 아니라, GitHub에서 클릭한 링크가 로드되는 데 너무 오래 걸린다는 것을 느낀 사람도 있을 겁니다. 아이러니하게도 현재 탭에서 GitHub의 자바스크립트가 네비게이션을 처리하도록 기다리는 것보다 새 탭에서 링크를 여는 것이 더 빠른 경우가 많습니다.

맞춤형 비밀번호 입력 필드도 위험 요소 중 하나입니다. 다행히도 맞춤형 비밀번호 필드는 점점 드물어지고 있습니다. 브라우저에 기본으로 제공되는 비밀번호 입력 필드는 비밀번호 관리에 충분히 잘 갖춰져 있습니다. 비밀번호 저장 제안, 자동 입력, 강력한 비밀번호 생성, HTTP가 안전하지 않을 때 경고, 비밀번호 관리자와 자동 완성 연동, 모바일 키보드와 접근성 도구와의 호환 등 다양한 기능을 제공합니다. 브라우저의 비밀번호 필드를 여러분이 만든 가짜 버전으로 교체하면 이러한 모든 기능이 깨질 수 있습니다. 심지어 일반 텍스트 필드를 사용해 직접 마스킹한다면, 브라우저·운영체제·보조 도구가 해당 텍스트를 일반 가시 텍스트로 취급해 비밀번호가 의도치 않게 노출될 수 있습니다.

맞춤형 날짜 선택기도 흔한 불편함 중 하나입니다. 은(는) 날짜 범위를 선택하도록 도와주지는 않지만, 두 개의 날짜 입력 필드(시작일, 종료일)를 제공하면 충분합니다. 저는 한 번에 두 개의 입력을 사용해 날짜 범위를 선택하는 작은 불편을 감수할 수 있습니다. 하지만 열다섯 개의 서로 다른 구현을 가진 웹사이트마다 다른 방식으로 날짜 선택기를 배우는 것은 원하지 않습니다. 현재 날짜 선택기 구현은 제각각입니다. 어떤 것은 연도 보기를 위해 월 보기를 확대해야 하고, 연도를 선택한 뒤에는 다시 월 보기로 돌아가기 전까지 월을 바꿀 수 없습니다. 또 어떤 것은 태어난 연도를 선택하려면 ‘이전 연도’ 버튼을 무려 사십 번이나 눌러야 합니다. 어떤 것은 날짜 입력 자체를 전혀 허용하지도 않습니다. 저는 여러분의 캘린더 위젯을 배우고 싶지 않습니다. 저는 단지 제가 가장 좋아하는 브라우저의 기본 날짜 선택기를 사용하고 싶을 뿐이며, 이는 여러분이 만든 맞춤 구현보다 훨씬 합리적입니다. 만약 네이티브 날짜 선택기 지원이 부족한 브라우저를 위해 캘린더 위젯이 필요하다면, 그 위젯을 기존 네이티브 날짜 선택기와 **함께** 제공하는 것이 대체하는 것보다 나을 것입니다. 예를 들어, 기본 요소는 그대로 두고, 추가적인 맞춤 위젯을 보조 용도로 제공할 수 있습니다.