<div id="readability-page-1" class="page"><div><div><h2 id="6da8" data-testid="storyTitle">(번역) 직접 만들지 마세요</h2><div tabindex="-1"><a rel="noopener follow" href="/?source=post_page---byline--e1962d5e9817---------------------------------------" data-discover="true"><div><p><img alt="한정(Han Jung)" src="https://miro.medium.com/v2/resize:fill:64:64/1*tQfG8hfW5vM4hbRVZucMrg.png" width="32" height="32" loading="lazy" data-testid="authorPhoto"></p></div></a></div></div><blockquote><p id="6e92"><em>원문: </em><a href="https://susam.net/do-not-roll-your-own.html" rel="noopener ugc nofollow" target="_blank"><em>https://susam.net/do-not-roll-your-own.html</em></a></p></blockquote><p id="a274">이 글은 요즘 웹 디자인 관행을 향한 불평입니다. 그 이야기로 들어가기 전에, 암호학 세계의 익숙한 원칙 하나로 시작해 보겠습니다. 소프트웨어 개발자들 사이에서, 특히 보안에 민감한 시스템을 다루는 사람들 사이에서 잘 알려진 격언이 있습니다. 바로 “직접 만든 암호를 쓰지 말라”는 것입니다. 아무도 암호 코드를 작성해서는 안 된다는 뜻이 아닙니다. 누군가는 작성해야 합니다. 사용자의 민감한 데이터를 보호하는 일반적인 프로덕션 소프트웨어라면, 더 넓은 소프트웨어 개발 커뮤니티의 검토와 검증을 거치지 않은 비공개 구현에 의존해서는 안 된다는 뜻입니다. 가능한 한 이미 자리 잡고 검증된 소프트웨어 패키지나 도구를 써야 합니다.</p><p id="8550">다행히 이제는 직접 만든 암호를 피하고, 동료 검토를 거쳐 오랜 시간 검증된 암호 알고리즘과 패키지를 쓰는 것이 업계의 표준 관행입니다. 한 이십 년 전만 해도 그렇지 않았습니다. 저는 경력 초기에 결함이 있는 자체 제작 RC4 구현을 여럿 보았습니다. 초기화 벡터(initialization vector)가 부적절하거나, 키스트림(keystream)을 예측할 수 있거나, 평문이 암호문으로 일부 새어 나가는 등의 문제로 사용자의 민감한 데이터를 위험에 빠뜨렸습니다. 하지만 오늘날 주요 전자상거래 웹사이트나 은행은 대체로 웹 서비스에 자체 제작 암호를 쓰지 않습니다. 사실 결제, 의료, 개인정보 처리처럼 규제가 적용되는 분야에서는 그렇게 했다가 강력한 암호화 요건을 위반해 막대한 벌금을 물 수도 있습니다.</p><p id="4ff7">웹 디자인은 당연히 암호학이 아닙니다. 망가진 스크롤바는 망가진 암호화 방식과 같은 종류의 실패가 아닙니다. 하지만 저는 웹 디자인에도 비슷한 격언이 있었으면 합니다. 웹사이트에는 개발자가 X를 직접 만들지 말아야 한다고 생각하는 측면이 많습니다. 특히 그 X가 브라우저가 이미 잘 해내는 것이고, 사용자가 매일 의존하는 것일 때 그렇습니다. 여기 그런 X의 목록을 소개합니다.</p><ul><li id="a4a7">페이지 스크롤을 직접 만들지 마세요.</li><li id="8314">링크 내비게이션을 직접 만들지 마세요.</li><li id="f55e">텍스트 선택을 직접 만들지 마세요.</li><li id="54c8">컨텍스트 메뉴를 직접 만들지 마세요.</li><li id="fe07">복사와 붙여넣기를 직접 만들지 마세요.</li><li id="8027">비밀번호 입력 필드를 직접 만들지 마세요.</li><li id="a6cc">날짜 선택기를 직접 만들지 마세요.</li></ul><p id="88fd">물론 X를 직접 만들어야 하는 정당한 상황도 있습니다. 하지만 여기서는 X를 직접 만들지 말아야 하는 경우, 그리고 그렇게 했을 때 적어도 제 경험상 사용자 경험이 어떻게 나빠질 수 있는지에 초점을 맞추려 합니다. 아무도 무언가를 직접 만들어서는 안 된다고 말하는 게 아닙니다. 저 역시 창의적인 컴퓨팅을 많이 하고 이따금 재미있는 도구를 만드는 사람으로서, 자기만의 것을 만드는 일을 적극 지지합니다. 하지만 사람들이 일을 처리하려고 꼭 써야 하는 진지한 웹사이트의 사용자 인터페이스 기능을 개발하는 일이라면, 소프트웨어 개발 커뮤니티가 어떤 화려한 기능을 웹사이트에 넣고 어떤 것을 뺄지 결정할 때 좀 더 보수적이었으면 합니다. 제가 사용자 경험 전문가가 아니라는 점은 꼭 기억해 주세요. 전혀 아닙니다. 그러니 여기서 하는 말은 어느 것도 권장 사항으로 받아들이지 마세요. 하지만 저는 웹 사용자이고, 사용자로서 요즘의 몇몇 웹 디자인 패턴이 답답하다고 느꼈습니다. 이 글은 웹 사용자 한 사람의 푸념이지, 디자인 가이드가 아닙니다.</p><p id="dfc5">위에서 언급한 것들 가운데 저를 가장 괴롭히는 것은 웹사이트의 커스텀 스크롤 동작입니다. 저는 페이지 스크롤이 마우스나 터치패드, 키보드 입력에 어떻게 반응하는지에 익숙합니다. 웹 브라우저의 기본 스크롤 동작을 직접 만든 구현으로 덮어쓰면, 제게는 그 페이지가 ‘망가집니다’. 이제 스크롤할 때 페이지가 너무 느리게 움직이거나 너무 빠르게 움직입니다. 키보드 스크롤은 될 수도 있고 안 될 수도 있습니다. 제가 너무 익숙해서 의식조차 하지 않던 것을, 이제 의식해야 하는 낯선 것으로 바꿔 버리는 셈입니다.</p><p id="9633">커스텀 링크 내비게이션도 제가 질색하는 것 중 하나입니다. 웹 브라우저는 이미 링크를 아주 잘 다룹니다. 링크를 잘 다루는 일이야말로 웹 브라우저가 존재하는 바로 그 이유라고 해도 됩니다. 링크를 따라가는 일은 브라우저의 핵심 기능입니다. 그 동작은 전혀 건드릴 필요가 없습니다. 건드려야겠다는 생각이 든다면, 무엇을 이루려는 것인지, 그리고 그것이 정상적인 링크 내비게이션을 방해할 만큼 정말로 중요한 일인지 다시 생각해 보세요. 제가 찾은 가장 심각한 사례는 GitHub입니다. GitHub에서 링크를, 이를테면 파일 링크나 이슈 링크를 클릭하면, 링크 클릭을 대신 처리하는 거대한 자바스크립트 기능 덩어리가 작동합니다. 제 말이 믿기지 않는다면, Firefox나 Chrome으로 좋아하는 프로젝트를 GitHub에서 열고, F12를 눌러 브라우저의 개발자 도구를 연 다음, ‘Debugger’나 ‘Sources’ 탭으로 가서 오른쪽 사이드바에서 ‘Event Listener Breakpoints’를 찾아 ‘Mouse’를 펼치고 ‘click’을 선택해 보세요. 그런 다음 GitHub에서 링크를 클릭해 무슨 일이 일어나는지 보세요.</p></div><div><p id="2822">GitHub에서 클릭한 링크가 가끔 너무 오래 걸려 로드된다는 사실을 눈치챈 사람은 저뿐만이 아닐 겁니다. 역설적이게도, GitHub의 자바스크립트 코드가 현재 탭에서 내비게이션을 처리하기를 기다리는 것보다 링크를 새 탭에서 여는 편이 더 빠를 때가 많습니다.</p><p id="a7c7">커스텀 비밀번호 입력 필드도 그런 위험 요소 중 하나입니다. 다행히 커스텀 비밀번호 입력 필드는 수년에 걸쳐 점점 드물어졌습니다. 웹 브라우저에 기본으로 딸려 오는 비밀번호 입력 필드는 대체로 비밀번호를 잘 처리합니다. 비밀번호 저장을 제안하고, 나중에 자동으로 채워 넣고, 새 계정을 위한 강력한 비밀번호를 생성합니다. 또한 안전하지 않은 HTTP 연결로 비밀번호가 전송될 때 경고하고, 비밀번호 관리자나 자동 완성과 잘 어울리며, 모바일 키보드나 접근성 도구와도 협력합니다. 브라우저의 비밀번호 필드를 직접 만든 가짜 버전으로 바꾸면, 그 모든 기능이 망가질 수 있습니다. 또 평범한 텍스트 필드를 쓰면서 직접 마스킹 처리를 하게 될 수도 있는데, 그러면 브라우저나 운영체제, 보조 도구가 그 비밀번호를 비밀번호가 아니라 평범하게 보이는 텍스트로 취급해, 의도하지 않은 방식으로 비밀번호가 노출될 수 있습니다.</p><p id="5e29">커스텀 날짜 선택기도 흔한 골칫거리입니다. <code>&lt;input type="date"&gt;</code>로는 날짜 범위를 선택할 수 없다는 것을 압니다. 하지만 괜찮습니다. 시작 날짜용과 종료 날짜용으로 날짜 입력 필드 두 개를 제공하면 됩니다. 제가 좋아하는 웹 브라우저로 어디서나 똑같이 달력을 넘기고 날짜를 고를 수 있다면, 날짜 범위를 선택하려고 입력 필드 두 개를 쓰는 작은 대가쯤은 기꺼이 치르겠습니다. 제가 별로 하고 싶지 않은 일은, 열 개의 서로 다른 웹사이트에 걸친 열 개의 서로 다른 구현에서 날짜 선택기를 쓰는 열 가지 방법을 익히는 것입니다. 지금 날짜 선택기 구현은 제각각입니다. 어떤 것은 연도를 고르려면 월 보기에서 축소해 연도 보기로 들어가야 합니다. 그런데 거기 있는 동안에는 월 보기로 돌아오기 전까지 다시 월을 바꿀 수 없습니다. 어떤 것은, 나이가 충분히 많다면, 출생 연도를 고르려고 이전 연도 버튼을 말 그대로 마흔 번이나 클릭해야 합니다. 어떤 것은 날짜를 아예 입력하지도 못하게 합니다. 안 됩니다. 저는 당신의 달력 위젯을 익히고 싶지 않습니다. 그저 제가 좋아하는 브라우저의 날짜 선택기를 쓰고 싶을 뿐입니다. 그 편이 꽤 합리적이거든요. 당신의 커스텀 구현보다 합리적입니다. 네이티브 날짜 선택기 지원이 부족한 브라우저를 지원하려고 달력 위젯이 필요하다면, 그 지원을 네이티브 날짜 선택기를 대체하는 것이 아니라 그 옆에 함께 더하는 방식으로 추가할 수 있을 것입니다. 예를 들어 평범한 <code>&lt;input type="date"&gt;</code> 요소는 그대로 두고, 사용자가 같은 필드를 조작할 수 있도록 커스텀 위젯을 거기에 추가로 제공하는 식입니다.</p><p id="0836">전반적으로, 폼 컨트롤을 그만 좀 건드리세요. 폼 컨트롤은 기존 문제 몇 개를 해결하면서 거의 언제나 새로운 문제를 일으킵니다. 그리고 그러는 김에, 몇 달마다 웹사이트 레이아웃과 인터페이스를 계속 바꾸지 마세요! 저는 새 디자인에 적응할 수 있을지 몰라도, 나이 든 제 친척들은 그러지 못합니다. 그분들에게는 당신이 사용자 인터페이스를 바꿀 때마다 그것이 완전히 새로운 도구를 배우는 일이나 마찬가지입니다. 모든 웹사이트가 몇 달마다 이런 짓을 계속한다면, 그분들은 아무 기능적 이득도 없이 익숙한 것들을 다시 배우는 데 상당한 시간을 써야 합니다. 부디 그분들이 은퇴 생활을 누리게 해 주세요. 리눅스 배포판이 몇 달마다 모든 핵심 명령어와 그 명령줄 옵션을 다시 디자인하기로 한다면 기분이 어떨지 상상해 보세요. 아니면 당신의 세탁기 버튼이 매일 아침 재배치된다면 기분이 어떨지 상상해 보세요. 유쾌하지 않을 겁니다!</p></div></div>

Stories by Jung Han on Medium

한정

원문: https://susam.net/do-not-roll-your-own.html
이 글은 요즘 웹 디자인 관행을 향한 불평입니다. 그 이야기로 들어가기 전에, 암호학 세계의 익숙한 원칙 하나로 시작해 보겠습니다. 소프트웨어 개발자들 사이에서, 특히 보안에 민감한 시스템을 다루는 사람들 사이에서 잘 알려진 격언이 있습니다. 바로 “직접 만든 암호를 쓰지 말라”는 것입니다. 아무도 암호 코드를 작성해서는 안 된다는 뜻이 아닙니다. 누군가는 작성해야 합니다. 사용자의 민감한 데이터를 보호하는 일반적인 프로덕션 소프트웨어라면, 더 넓은 소프트웨어 개발 커뮤니티의 검토와 검증을 거치지 않은 비공개 구현에 의존해서는 안 된다는 뜻입니다. 가능한 한 이미 자리 잡고 검증된 소프트웨어 패키지나 도구를 써야 합니다.
다행히 이제는 직접 만든 암호를 피하고, 동료 검토를 거쳐 오랜 시간 검증된 암호 알고리즘과 패키지를 쓰는 것이 업계의 표준 관행입니다. 한 이십 년 전만 해도 그렇지 않았습니다. 저는 경력 초기에 결함이 있는 자체 제작 RC4 구현을 여럿 보았습니다. 초기화 벡터(initialization vector)가 부적절하거나, 키스트림(keystream)을 예측할 수 있거나, 평문이 암호문으로 일부 새어 나가는 등의 문제로 사용자의 민감한 데이터를 위험에 빠뜨렸습니다. 하지만 오늘날 주요 전자상거래 웹사이트나 은행은 대체로 웹 서비스에 자체 제작 암호를 쓰지 않습니다. 사실 결제, 의료, 개인정보 처리처럼 규제가 적용되는 분야에서는 그렇게 했다가 강력한 암호화 요건을 위반해 막대한 벌금을 물 수도 있습니다.
웹 디자인은 당연히 암호학이 아닙니다. 망가진 스크롤바는 망가진 암호화 방식과 같은 종류의 실패가 아닙니다. 하지만 저는 웹 디자인에도 비슷한 격언이 있었으면 합니다. 웹사이트에는 개발자가 X를 직접 만들지 말아야 한다고 생각하는 측면이 많습니다. 특히 그 X가 브라우저가 이미 잘 해내는 것이고, 사용자가 매일 의존하는 것일 때 그렇습니다. 여기 그런 X의 목록을 소개합니다.
페이지 스크롤을 직접 만들지 마세요.
링크 내비게이션을 직접 만들지 마세요.
텍스트 선택을 직접 만들지 마세요.
컨텍스트 메뉴를 직접 만들지 마세요.
복사와 붙여넣기를 직접 만들지 마세요.
비밀번호 입력 필드를 직접 만들지 마세요.
날짜 선택기를 직접 만들지 마세요.
물론 X를 직접 만들어야 하는 정당한 상황도 있습니다. 하지만 여기서는 X를 직접 만들지 말아야 하는 경우, 그리고 그렇게 했을 때 적어도 제 경험상 사용자 경험이 어떻게 나빠질 수 있는지에 초점을 맞추려 합니다. 아무도 무언가를 직접 만들어서는 안 된다고 말하는 게 아닙니다. 저 역시 창의적인 컴퓨팅을 많이 하고 이따금 재미있는 도구를 만드는 사람으로서, 자기만의 것을 만드는 일을 적극 지지합니다. 하지만 사람들이 일을 처리하려고 꼭 써야 하는 진지한 웹사이트의 사용자 인터페이스 기능을 개발하는 일이라면, 소프트웨어 개발 커뮤니티가 어떤 화려한 기능을 웹사이트에 넣고 어떤 것을 뺄지 결정할 때 좀 더 보수적이었으면 합니다. 제가 사용자 경험 전문가가 아니라는 점은 꼭 기억해 주세요. 전혀 아닙니다. 그러니 여기서 하는 말은 어느 것도 권장 사항으로 받아들이지 마세요. 하지만 저는 웹 사용자이고, 사용자로서 요즘의 몇몇 웹 디자인 패턴이 답답하다고 느꼈습니다. 이 글은 웹 사용자 한 사람의 푸념이지, 디자인 가이드가 아닙니다.
위에서 언급한 것들 가운데 저를 가장 괴롭히는 것은 웹사이트의 커스텀 스크롤 동작입니다. 저는 페이지 스크롤이 마우스나 터치패드, 키보드 입력에 어떻게 반응하는지에 익숙합니다. 웹 브라우저의 기본 스크롤 동작을 직접 만든 구현으로 덮어쓰면, 제게는 그 페이지가 ‘망가집니다’. 이제 스크롤할 때 페이지가 너무 느리게 움직이거나 너무 빠르게 움직입니다. 키보드 스크롤은 될 수도 있고 안 될 수도 있습니다. 제가 너무 익숙해서 의식조차 하지 않던 것을, 이제 의식해야 하는 낯선 것으로 바꿔 버리는 셈입니다.
커스텀 링크 내비게이션도 제가 질색하는 것 중 하나입니다. 웹 브라우저는 이미 링크를 아주 잘 다룹니다. 링크를 잘 다루는 일이야말로 웹 브라우저가 존재하는 바로 그 이유라고 해도 됩니다. 링크를 따라가는 일은 브라우저의 핵심 기능입니다. 그 동작은 전혀 건드릴 필요가 없습니다. 건드려야겠다는 생각이 든다면, 무엇을 이루려는 것인지, 그리고 그것이 정상적인 링크 내비게이션을 방해할 만큼 정말로 중요한 일인지 다시 생각해 보세요. 제가 찾은 가장 심각한 사례는 GitHub입니다. GitHub에서 링크를, 이를테면 파일 링크나 이슈 링크를 클릭하면, 링크 클릭을 대신 처리하는 거대한 자바스크립트 기능 덩어리가 작동합니다. 제 말이 믿기지 않는다면, Firefox나 Chrome으로 좋아하는 프로젝트를 GitHub에서 열고, F12를 눌러 브라우저의 개발자 도구를 연 다음, ‘Debugger’나 ‘Sources’ 탭으로 가서 오른쪽 사이드바에서 ‘Event Listener Breakpoints’를 찾아 ‘Mouse’를 펼치고 ‘click’을 선택해 보세요. 그런 다음 GitHub에서 링크를 클릭해 무슨 일이 일어나는지 보세요.
GitHub에서 클릭한 링크가 가끔 너무 오래 걸려 로드된다는 사실을 눈치챈 사람은 저뿐만이 아닐 겁니다. 역설적이게도, GitHub의 자바스크립트 코드가 현재 탭에서 내비게이션을 처리하기를 기다리는 것보다 링크를 새 탭에서 여는 편이 더 빠를 때가 많습니다.
커스텀 비밀번호 입력 필드도 그런 위험 요소 중 하나입니다. 다행히 커스텀 비밀번호 입력 필드는 수년에 걸쳐 점점 드물어졌습니다. 웹 브라우저에 기본으로 딸려 오는 비밀번호 입력 필드는 대체로 비밀번호를 잘 처리합니다. 비밀번호 저장을 제안하고, 나중에 자동으로 채워 넣고, 새 계정을 위한 강력한 비밀번호를 생성합니다. 또한 안전하지 않은 HTTP 연결로 비밀번호가 전송될 때 경고하고, 비밀번호 관리자나 자동 완성과 잘 어울리며, 모바일 키보드나 접근성 도구와도 협력합니다. 브라우저의 비밀번호 필드를 직접 만든 가짜 버전으로 바꾸면, 그 모든 기능이 망가질 수 있습니다. 또 평범한 텍스트 필드를 쓰면서 직접 마스킹 처리를 하게 될 수도 있는데, 그러면 브라우저나 운영체제, 보조 도구가 그 비밀번호를 비밀번호가 아니라 평범하게 보이는 텍스트로 취급해, 의도하지 않은 방식으로 비밀번호가 노출될 수 있습니다.
커스텀 날짜 선택기도 흔한 골칫거리입니다. <input type="date">로는 날짜 범위를 선택할 수 없다는 것을 압니다. 하지만 괜찮습니다. 시작 날짜용과 종료 날짜용으로 날짜 입력 필드 두 개를 제공하면 됩니다. 제가 좋아하는 웹 브라우저로 어디서나 똑같이 달력을 넘기고 날짜를 고를 수 있다면, 날짜 범위를 선택하려고 입력 필드 두 개를 쓰는 작은 대가쯤은 기꺼이 치르겠습니다. 제가 별로 하고 싶지 않은 일은, 열 개의 서로 다른 웹사이트에 걸친 열 개의 서로 다른 구현에서 날짜 선택기를 쓰는 열 가지 방법을 익히는 것입니다. 지금 날짜 선택기 구현은 제각각입니다. 어떤 것은 연도를 고르려면 월 보기에서 축소해 연도 보기로 들어가야 합니다. 그런데 거기 있는 동안에는 월 보기로 돌아오기 전까지 다시 월을 바꿀 수 없습니다. 어떤 것은, 나이가 충분히 많다면, 출생 연도를 고르려고 이전 연도 버튼을 말 그대로 마흔 번이나 클릭해야 합니다. 어떤 것은 날짜를 아예 입력하지도 못하게 합니다. 안 됩니다. 저는 당신의 달력 위젯을 익히고 싶지 않습니다. 그저 제가 좋아하는 브라우저의 날짜 선택기를 쓰고 싶을 뿐입니다. 그 편이 꽤 합리적이거든요. 당신의 커스텀 구현보다 합리적입니다. 네이티브 날짜 선택기 지원이 부족한 브라우저를 지원하려고 달력 위젯이 필요하다면, 그 지원을 네이티브 날짜 선택기를 대체하는 것이 아니라 그 옆에 함께 더하는 방식으로 추가할 수 있을 것입니다. 예를 들어 평범한 <input type="date"> 요소는 그대로 두고, 사용자가 같은 필드를 조작할 수 있도록 커스텀 위젯을 거기에 추가로 제공하는 식입니다.
전반적으로, 폼 컨트롤을 그만 좀 건드리세요. 폼 컨트롤은 기존 문제 몇 개를 해결하면서 거의 언제나 새로운 문제를 일으킵니다. 그리고 그러는 김에, 몇 달마다 웹사이트 레이아웃과 인터페이스를 계속 바꾸지 마세요! 저는 새 디자인에 적응할 수 있을지 몰라도, 나이 든 제 친척들은 그러지 못합니다. 그분들에게는 당신이 사용자 인터페이스를 바꿀 때마다 그것이 완전히 새로운 도구를 배우는 일이나 마찬가지입니다. 모든 웹사이트가 몇 달마다 이런 짓을 계속한다면, 그분들은 아무 기능적 이득도 없이 익숙한 것들을 다시 배우는 데 상당한 시간을 써야 합니다. 부디 그분들이 은퇴 생활을 누리게 해 주세요. 리눅스 배포판이 몇 달마다 모든 핵심 명령어와 그 명령줄 옵션을 다시 디자인하기로 한다면 기분이 어떨지 상상해 보세요. 아니면 당신의 세탁기 버튼이 매일 아침 재배치된다면 기분이 어떨지 상상해 보세요. 유쾌하지 않을 겁니다!

(번역) 직접 만들지 마세요

댓글