직접 만들지 말라 …

• Don't Roll Your Own ... 원칙은 암호화뿐 아니라 웹 UI에도 적용되며, 브라우저가 이미 안정적으로 제공하는 기능을 불필요하게 대체하지 않아야 함
• 자체 스크롤, 링크 처리, 텍스트 선택, 복사·붙여넣기 같은 기본 동작 대체는 익숙한 입력 반응을 깨뜨려 사용자가 조작 방식을 다시 신경 쓰게 만듦
• GitHub의 파일·이슈 링크처럼 JavaScript가 링크 탐색을 가로채면, 현재 탭에서 처리되기를 기다리는 것보다 새 탭으로 여는 편이 더 빠를 때가 있음
• 기본 비밀번호 필드와 <input type="date">는 자동완성, 비밀번호 관리자, 접근성 도구, 모바일 키보드와 협력하므로 가짜 UI로 바꾸면 기능이 깨질 수 있음
• 몇 달마다 바뀌는 레이아웃과 폼 컨트롤은 사용자가 업무보다 재학습에 시간을 쓰게 하며, 안정적인 브라우저 기본 동작을 유지하는 편이 바람직함

“직접 만들지 말라” 원칙의 웹 UI 적용

• 암호화 직접 구현 금지는 민감한 데이터를 보호하는 운영 소프트웨어에서 검증되지 않은 사설 구현에 의존하지 말라는 원칙임
• 암호화 코드를 아무도 작성하면 안 된다는 뜻이 아니라, 가능한 한 검토되고 검증된 패키지와 도구를 사용해야 한다는 뜻에 가까움
• 약 20년 전에는 부적절한 초기화 벡터, 예측 가능한 키스트림, 평문 일부 유출 같은 문제가 있는 자체 RC4 구현이 실제로 존재했음
• 현재 주요 전자상거래 사이트나 은행은 일반적으로 웹 서비스에 자체 암호화를 쓰지 않으며, 결제·의료·개인정보 처리 같은 규제 영역에서는 강한 암호화 요건 위반이 큰 벌금으로 이어질 수 있음
• 웹사이트 디자인은 암호화와 같지 않지만, 브라우저가 이미 잘 처리하고 사용자가 매일 의존하는 기능을 다시 구현하면 사용자 경험이 나빠질 수 있음

브라우저 기본 기능을 대체할 때 생기는 문제

• 페이지 스크롤을 직접 구현하면 마우스, 터치패드, 키보드 입력에 대한 익숙한 반응이 깨질 수 있음
• 기본 스크롤 동작을 덮어쓰면 페이지가 너무 느리거나 빠르게 움직이고, 키보드 스크롤이 작동하지 않을 수도 있음
• 사용자가 의식하지 않고 쓰던 동작이 낯선 동작으로 바뀌면, 페이지 조작 자체를 다시 신경 써야 함
• 직접 구현하지 말아야 할 대표 기능에는 링크 탐색, 텍스트 선택, 컨텍스트 메뉴, 복사·붙여넣기, 비밀번호 필드, 날짜 선택기가 포함됨
• 진지한 업무용 웹사이트에 사용자 인터페이스 기능을 넣을 때는 화려한 기능을 추가할지, 브라우저 기본 동작에 맡길지 보수적으로 결정할 필요가 있음

링크 탐색과 GitHub 사례

• 웹브라우저는 링크를 따라가는 일을 이미 잘 처리하며, 링크 탐색은 브라우저의 핵심 기능임
• 정상적인 링크 동작을 방해해야 한다고 느껴진다면, 달성하려는 목표가 일반적인 링크 탐색을 깨뜨릴 만큼 중요한지 다시 검토해야 함
• GitHub에서는 파일 링크나 이슈 링크를 클릭하면 JavaScript로 구현된 큰 기능이 클릭 처리를 대신함
• Firefox나 Chrome에서 F12로 개발자 도구를 열고, Debugger 또는 Sources 탭의 Event Listener Breakpoints에서 Mouse의 click을 선택한 뒤 GitHub 링크를 클릭하면 이 동작을 확인할 수 있음
• GitHub에서 현재 탭의 JavaScript 탐색 처리를 기다리는 것보다 새 탭으로 링크를 여는 편이 더 빠를 때가 있음

비밀번호 입력과 날짜 선택기

• 브라우저의 비밀번호 입력 필드는 비밀번호 저장, 자동 입력, 새 계정용 강한 비밀번호 생성 기능을 제공할 수 있음
• 기본 비밀번호 필드는 안전하지 않은 HTTP 연결로 비밀번호가 제출될 때 경고하고, 비밀번호 관리자·자동완성·모바일 키보드·접근성 도구와도 협력함
• 가짜 비밀번호 필드로 대체하면 이런 기능이 깨질 수 있으며, 일반 텍스트 필드를 직접 마스킹하면 브라우저·운영체제·보조 도구가 비밀번호를 일반 가시 텍스트처럼 다룰 수 있음
• <input type="date">는 날짜 범위 선택을 직접 지원하지 않지만, 시작일과 종료일 입력 필드 2개를 제공하면 브라우저 기본 날짜 선택기를 유지할 수 있음
• 사용자 정의 날짜 선택기는 구현마다 방식이 달라, 연도 보기로 확대해야 하거나 생년을 고르기 위해 이전 연도 버튼을 수십 번 눌러야 하거나 날짜 직접 입력이 막힐 수 있음
• 기본 날짜 선택기 지원이 부족한 브라우저에 달력 위젯이 필요하다면, <input type="date">를 대체하지 말고 같은 필드를 조작하는 보조 위젯으로 추가하는 편이 나음

잦은 UI 변경의 비용

• 폼 컨트롤을 함부로 바꾸면 기존 문제를 해결하는 동시에 새로운 문제를 거의 항상 도입함
• 웹사이트 레이아웃과 인터페이스를 몇 달마다 바꾸면 일부 사용자는 적응하더라도, 나이 든 사용자는 매번 새로운 도구를 배우는 것과 같은 부담을 겪음
• 여러 웹사이트가 계속 인터페이스를 바꾸면 사용자는 기능적 이득 없이 익숙한 것을 다시 배우는 데 상당한 시간을 써야 함
• Linux 배포판이 몇 달마다 핵심 명령과 명령줄 옵션을 모두 다시 설계하거나, 세탁기 버튼 배치가 매일 아침 바뀌는 상황처럼 반복적인 UI 재배치는 불쾌한 경험이 됨
• 웹 UI는 사용자가 업무를 끝내기 위해 쓰는 도구이므로, 브라우저가 이미 제공하는 익숙하고 안정적인 동작을 불필요하게 대체하지 않는 편이 바람직함